W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Header Policy Vs. Meta tag policy

From: Daniel Veditz <dveditz@mozilla.com>
Date: Thu, 12 Jun 2014 10:44:24 -0700
Message-ID: <5399E6F8.5080802@mozilla.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC