- From: Justin Schuh <jschuh@chromium.org>
- Date: Mon, 30 Aug 2010 11:27:10 -0700
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. 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. -j
Received on Monday, 30 August 2010 11:27:10 UTC