W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] @srcdoc and default @sandbox

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 30 Aug 2010 14:08:28 -0700
Message-ID: <AANLkTinp3_xh3P_yQU3v7sY-q8-GG1M7Wws+k5U-XHCr@mail.gmail.com>
On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote:
>
>> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
>>>
>>>> While talking with the implementor of @srcdoc in Webkit, it came up
>>>> that, though @srcdoc is *designed* for use with @sandbox, the author
>>>> still has to explicitly add @sandbox to the <iframe> or else they
>>>> don't get the sandbox security model.
>>>>
>>>> Can we make this automatic? ?Specifically, when <iframe
>>>> srcdoc=foo></iframe> is specified (without @sandbox), it drops into
>>>> the sandbox security model as if <iframe sandbox srcdoc=foo></iframe>
>>>> was used. ?If @sandbox is explicitly added, its value is instead used,
>>>> so the author can set the sandbox security flags if desired.
>>>>
>>>> This would mean that there is no way for an author to use @srcdoc
>>>> *without* sandboxing. ?This appears to be a minority use-case in the
>>>> first place (as far as I can tell, it's pretty much just useful for
>>>> testing purposes), but the author can always use a data: url in that
>>>> case.
>>>
>>> I think it's better to let these remain orthogonal features. In general I think it is a net negative to usability when Feature A implicitly turns on Feature B. Implicit relationships like this make the Web platform more confusing.
>>
>> While I agree with you in general, in this particular case I cannot.
>> @srcdoc wasn't designed as an orthogonal feature - it was explicitly
>> built with @sandbox in mind, to allow authors to shove generic content
>> into the sandbox without incurring a network request. ?It has only
>> niche technical use outside the context of @sandbox.
>
> 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.

Adam
Received on Monday, 30 August 2010 14:08:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC