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

[whatwg] @srcdoc and default @sandbox

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 31 Aug 2010 17:03:16 -0700
Message-ID: <AANLkTinfiFHVjpoEwW0Hh3Nt8P+LMWmvaqQ_Q-kZfHw1@mail.gmail.com>
2010/8/31 Kornel Lesi?ski <kornel at geekhood.net>:
> 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.

Ok.

> However, "inline data without sandboxing" does not cover all use cases of srcdoc.

It covers very few use-cases, actually.  @srcdoc is meant to address
the case of "inline data *with* sandboxing".

> There's another use case of "inline data _with_ sandboxing and fallback for HTML4 UAs", for which data: URI currently cannot provide.

Indeed; that's what @srcdoc is for.

Could you be clearer about what point you're trying to make?  What
use-case are you trying to address that you think the suggestion in
this thread (make @srcdoc imply @sandbox) is incompatible with?  At
the moment it appears that you're confused about the goal of the
change I'm suggesting, but I could just be missing something.

~TJ
Received on Tuesday, 31 August 2010 17:03:16 UTC

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