[whatwg] Comments on @sandbox

[Adam Barth]

On Thu, Nov 5, 2009 at 9:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> I'll respond in more depth later, but some quick notes since you're
> reviewing a patch:

Thanks.  The plan is to implement the spec as currently written and
then track changes to the spec.

> On Thu, 5 Nov 2009, Adam Barth wrote:
> It's actually more dangerous than you describe, because, per spec,
> 'allow-same-origin' only takes effect when the nested page is loaded,
> whereas the allow-scripts value is live, so if it is set initially, then
> removed (which has no effect) and replaced with 'allow-scripts' (which
> does), the nested frame is same-origin with scripts enabled.
>
> There's currently a red warning in the spec about this.

I see.  It seems confusing to have some of the attributes be live and
others not.

> (We could resolve this by making 'allow-scripts' not be live.)

Yes.

>> I recommend letting servers deliver the sandbox policy both via the
>> sandbox attribute and via an HTTP header.  The value of the HTTP header
>> approach is that the document will be sandboxed in whatever context the
>> user agent loads the document.  For various esoteric reasons, I wrote up
>> a description of how this might work on Mozilla's Wiki:
>> <https://wiki.mozilla.org/Security/CSP/Sandbox>.
>
> I agree, but I didn't want to get ahead of ourselves -- in particular
> given the work on CSP. We wouldn't want to end up with both. Also, some of
> the requirements may be a little different (e.g. CSP probably wants to
> disallow inline scripts but not external scripts, whereas here we're not
> worried about XSS within the sandboxed frame, so it doesn't make much
> sense to do that).

I agree.  This certainly doesn't block implementing @sandbox.  I just
wanted to include everything that was on my mind.

Adam