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

[whatwg] @srcdoc and default @sandbox

From: Justin Schuh <jschuh@chromium.org>
Date: Mon, 30 Aug 2010 15:13:04 -0700
Message-ID: <AANLkTi=vnhd0yfKy0K-p1BS5QhqVRYS_pEnr0cm6dORy@mail.gmail.com>
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?

Received on Monday, 30 August 2010 15:13:04 UTC

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