[whatwg] @srcdoc and default @sandbox

Justin Schuh jschuh at chromium.org
Mon Aug 30 15:13:04 PDT 2010

On Mon, Aug 30, 2010 at 1:57 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote:
>> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> 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.
>> Security features are typically effective only when deployed in
>> concert and when they default to their most restrictive state. As I
>> understand, srcdoc is intended primarily as a security feature
>> (because non-security use cases already have solutions). So, srcdoc
>> should behave like a well-spec'd security feature and provide it's
>> strongest level of protection by default, requiring the author to
>> scale it back if needed. Otherwise we'll end up with common vulnerable
>> cases because many people will expect secure default behavior,
>> regardless of whether or not we spec it.
> 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. And if convenience is the primary
goal, it seems like there are much better ways to implement the same

However, maybe I'm missing something. Could you give a scenario where
the convenience factor is significant, and not already served by
another feature?


More information about the whatwg mailing list