[whatwg] Comments on @sandbox
whatwg at adambarth.com
Thu Nov 5 21:26:24 PST 2009
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
> (We could resolve this by making 'allow-scripts' not be live.)
>> 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:
> 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.
More information about the whatwg