- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 21 Jan 2011 14:37:41 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- CC: Michal Zalewski <lcamtuf@coredump.cx>, gaz Heyes <gazheyes@gmail.com>, Giorgio Maone <g.maone@informaction.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
On 1/21/11 1:47 PM, Devdatta Akhawe wrote: > Michal Zalweski wrote: >> I think we're splitting hairs here. Both approaches could be safely >> combined by allowing HTTP headers to specify policy, in which case >> meta is ignored (which rules out injection woes completely); or meta >> to be interpreted if HTTP header is not present (in cases where site >> owner can't manipulate server settings). But either way, with minimal >> diligence and properly defined parsing rules, the risk in both cases >> is pretty low. > > How about instead allowing the meta tag policy to only make the policy > more restrictive than the one defined in HTTP headers? (following my > previous suggestion). In an earlier draft when we allowed both headers and <meta> tags this is exactly what we did. We removed <meta> to simplify the proposal and more strongly separate policy from document but I don't think we feel all that strongly about it. The <meta> tag raises the issue of what to do if the policy is found after something that should have been covered by the policy. Ignore the policy (too late!), ignore the violation (injected scripts win), maybe reparse the document from the beginning and hope there weren't earlier violations that matter? Not insurmountable, but definitely will add to the complexity of the spec. -Dan Veditz
Received on Friday, 21 January 2011 22:38:47 UTC