W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [CSP] violation reports for sandbox

From: Mike West <mkwst@google.com>
Date: Tue, 20 Jan 2015 11:45:54 +0100
Message-ID: <CAKXHy=ei2yceMFEY4bwCcO7c992N3fuH39bOd5bh-Mc-Rsag0g@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Jan 19, 2015 at 11:07 PM, Brian Smith <brian@briansmith.org> wrote:

> Looks good. I think it would be good to also list the things that
> aren't supported in <meta> in a note in section 3.3, which specifies
> the <meta> element. This way, the limitations of the <meta> element
> become clearer

We have this in step 5 of the algorithm. I don't think that duplicating it
in a note would be terribly helpful.

> Additionally, I think there should be a suggestion
> that the user agent should issue a warning when a directive is
> detected in a <meta> element that isn't supported in the meta element.

Added this in
(which has the nice side-effect of highlighting step 5 :) ).

Also, is it still intended that Content-Security-Policy-Report-Only
> isn't allowed in <meta>? I thought that this restriction was included
> back when <meta>- and header-field- specified policies were mutually
> exclusive, but now that those rules have changed, does it still make
> sense to prohibit <meta
> http-equiv=Content-Security-Policy-Report-Only>?

This goes along with the `report-uri` restriction; it doesn't make sense to
allow a report-only policy if we're not allowing a reporting endpoint, does


Mike West <mkwst@google.com>, @mikewest

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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 20 January 2015 10:46:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC