[whatwg] @srcdoc and default @sandbox
mjs at apple.com
Mon Aug 30 18:08:10 PDT 2010
On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote:
> On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth <w3c at adambarth.com> wrote:
>> On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> Should @seamless imply @sandbox too, then?
>> I think there lots of use cases for seamless that don't require
>> sandbox. For example, suppose a site wants to show a login form on
>> many pages by only wants to implement the login logic once. It's
>> entirely reasonable to wish to place the login form in a seamless
>> iframe. If we required @sandbox for seamless, that would interfere
>> with the login form working properly with password managers.
> Precisely; @seamless was *not* designed with the intention of always
> being used with @sandbox. It's just a nice feature to have for
> <iframe>s in general. So there's no real connection between @seamless
> and @sandbox like there is between @srcdoc and @sandbox.
@seamless was in fact designed to help @sandbox meet more use cases (in particular ones where embedding untrusted content in a fixed rect is not sufficient). But it can be used without @sandbox, and has some plausible uses along those lines, though they were not the initial use cases considered. LIkewise for @srcdoc. Indeed, many use cases are well-served by using all three in tandem.
My point being, don't mix up orthogonal features in arbitrary ways. If @srcdoc implies @sandbox, but @seamless does not, someone reviewing for security has to remember exactly which set of similar-sounding attributes cause sandboxing, instead of following the simple rule "just look for @sandbox". Things are clearer when security policy is explicit, and not implied by non-security behaviors.
More information about the whatwg