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

[whatwg] @srcdoc and default @sandbox

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 31 Aug 2010 16:24:55 -0700
Message-ID: <6B68720A-8D23-45A5-967B-9FC2C5E97703@apple.com>

On Aug 31, 2010, at 4:16 PM, Kornel Lesi?ski wrote:

> On 31.08.2010, at 23:39, Tab Atkins Jr. wrote:
>>>>> At least as currently drafted, srcdoc is not a security feature. It's a
>>>>> convenience feature. It is also designed to work well in tandem with a
>>>>> particular security feature (sandbox). But by itself, it is not a security
>>>>> feature.
>>>> Data URLs already provide this.
>>> What about existing UAs that implement data: URIs, but not sandbox?
>> What about them?
>> (Remember, the context of the "use data urls" suggestion was to solve
>> the minority use-case of wanting to fill an <iframe> without a network
>> request, without triggering sandboxing.)
> Yes, it's OK for data without sandboxing. However, "inline data without sandboxing" does not cover all use cases of srcdoc. There's another use case of "inline data _with_ sandboxing and fallback for HTML4 UAs", for which data: URI currently cannot provide.
> My point is that data: URIs provide only half of srcdoc functionality, and if srcdoc is supposed to be dropped in favor of data: URI, then the other use case needs to be taken into account as well.

You can use sandboxing with a data: URI by also specifying the "sandbox" attribute. As currently specified, srcdoc is almost entirely syntactic sugar.

Received on Tuesday, 31 August 2010 16:24:55 UTC

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