- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 30 Aug 2010 18:08:10 -0700
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. Regards, Maciej
Received on Monday, 30 August 2010 18:08:10 UTC