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

[whatwg] @srcdoc and default @sandbox

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Aug 2010 13:58:48 -0700
Message-ID: <38959E36-72DB-40C1-B498-DE928D175DF0@apple.com>

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?

Received on Monday, 30 August 2010 13:58:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC