[whatwg] @srcdoc and default @sandbox

[Tab Atkins Jr.]

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.

While I agree with you in general, in this particular case I cannot.
@srcdoc wasn't designed as an orthogonal feature - it was explicitly
built with @sandbox in mind, to allow authors to shove generic content
into the sandbox without incurring a network request.  It has only
niche technical use outside the context of @sandbox.

Further, omitting @sandbox seems like an easy mistake to make, and one
that you won't realize is a mistake until an attack gets through.
Avoiding that sort of security model was precisely why @srcdoc was
designed the way it was - we want to make it hard to fail, and obvious
when you do.

~TJ