- From: Mike West <mkwst@google.com>
- Date: Tue, 10 Jun 2014 06:50:32 +0200
- To: Kevin Hill <khill@microsoft.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=d1RgYhFxC1oojj7joZb+nT_4Vf4T4BUQj2VdFPv8EoBA@mail.gmail.com>
On Fri, Jun 6, 2014 at 3:39 PM, Kevin Hill <khill@microsoft.com> wrote: > Looking at section 3.1.3 HTML meta Element of the 1.1 spec. > > Content security policy (http-equiv="content-security-policy") > 1. If the user agent is already enforcing a policy for the document, abort > these steps. > > Is the intent that if a server policy is supplied that any meta elements > would be ignored? > Yes. When I took a first read I skimmed over this part and had thought that meta > Element tags would be added to the policies coming from the server. This > seems to be how this 1.1 option is implemented in Chrome currently. > That is how things are implemented in Chrome at the moment. Chrome's implementation of <meta> predates the spec, and I'll bring it into line with whatever the group ends up publishing. > Or is this trying to capture the potential race condition depending on > where a developer places the meta Element in their page? > The concerns aren't regarding race conditions, but potential attack surface. Folks are concerned about attackers being able to modify the CSP a page expects. I'd prefer to maintain the ability to tighten a page's policy, as I think there are totally valid use cases for such a thing, but so far I've been the only one in favor of that, and the spec reflects my understanding of the group's consensus. -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 10 June 2014 04:51:20 UTC