[whatwg] @srcdoc and default @sandbox

[Justin Schuh]

On Mon, Aug 30, 2010 at 6:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> 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.

But @seamless has a general utility that isn't served in any other
capacity. That's not the case for @srcdoc.

> 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.

As someone who spends the majority of his time doing security
assessments and code audits, I disagree. I'd happily accept an easily
reducible false positive over a feature that simply fails open with no
security whatsoever. My reasoning here is that the vast majority of
software doesn't get security reviews, which is why secure defaults
are generally far more effective. This is particularly true when you
consider that misuse of @seamless or @srcdoc will fail obviously and
quickly in nearly all applications. However, a missing @sandbox is
just the kind of thing that's very likely to go undetected.

Regards,
-j