- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Thu, 12 Jun 2014 10:44:24 -0700
- To: Mike West <mkwst@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
- CC: Kevin Hill <khill@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 6/12/2014 12:20 AM, Mike West wrote: > What about 'plugin-types'? What about 'referrer'? What about > 'frame-ancestors'? I can see value in all three. > [...] > It's clearly bad to turn on reporting. Sandboxing is fairly ineffective > once the page has loaded. Sandboxing in a page policy would be hard to implement, especially if the allow-same-origin flag isn't set. If a same-origin parent document managed to grab a reference to something before the policy was encountered do we have to track those down and null them out? Add another level of origin checks to each access "just in case" we hit the rare occurance of a late-set meta policy? I thought we had already specified that sandbox would be ignored in a meta policy, and it should stay that way. I personally would lump frame-ancestors in with sandboxing as a header-only directive. I don't want to have to abort parsing and tear down a document if we encounter one, hoping that whatever the author was trying to protect wasn't in the bit that already existed. I think we _do_ need to think about threats for every new directive we add, just as we have to worry about backwards compatibility. For simplicity the spec language can assume all directives work everywhere and we can explicitly call out the exceptions in each individual directive that's not allowed in a <meta> policy as well as listing them in the description of the <meta> header. -Dan Veditz
Received on Thursday, 12 June 2014 17:44:51 UTC