- From: Brandon Sterne <bsterne@mozilla.com>
- Date: Fri, 04 Nov 2011 14:01:48 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: "public-web-security@w3.org" <public-web-security@w3.org>
On 11/04/2011 10:18 AM, Adam Barth wrote: > Ok. That's something self-consistent that I can spec. I'm not sure > there are actually use cases for all the sandbox tokens in that model, > but there are definitely use cases for some of them and there's a lot > of value in aligning the list of tokens with the HTML5 sandbox > attribute. > > To summarize: > > 1) The sandbox bits in HTML5 are stored in two places: (a) the sandbox > attribute itself, and (b) associated with the document. When a > document gets created, the bits are copied from (a) to (b) so that > they're frozen for the lifetime of the document, even if the iframe's > attributes change. > > 2) For CSP, the sandbox directive will cause the bits to be set on (b) > only. That means the bits will apply to the current document but not > to future documents that occupy the same frame (top-level or > otherwise). > > 4) If both CSP and the sandbox attribute supply a sandbox policies, > they'll be merged using the algorithm in the HTML5 spec (which is > currently used to merge sandbox bits for nested iframes). > > Does that sound reasonable to everyone? > > Adam Good summary and, yes, that sounds reasonable. Thanks, Brandon
Received on Friday, 4 November 2011 21:02:41 UTC