W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] Comments on @sandbox

From: Adam Barth <whatwg@adambarth.com>
Date: Thu, 5 Nov 2009 21:26:24 -0800
Message-ID: <7789133a0911052126w2890ebf2nd7816b131fc90689@mail.gmail.com>
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
Received on Thursday, 5 November 2009 21:26:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC