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

Re: [CSP] Additional report field: report-only: "true|false"

From: Neil Matatall <neilm@twitter.com>
Date: Thu, 26 Jun 2014 09:49:45 -0700
Message-ID: <CAOFLtbg8O2ejRBtig6sUHbxQDQefXx9W5cTdF5L8atDPpgsDkQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
This request was motivated by getting more metrics. Metrics for this
purpose certainly do not align with your basic value concept, and I
can only think of one far-fetched example of where this might help in
changing how I act on reports.


On Thu, Jun 26, 2014 at 12:13 AM, Mike West <mkwst@google.com> wrote:
> What would you do with this information?
>
> The basic value of the reporting functionality is to find places where
> unexpected requests for resources are being made. What would knowing whether
> the request went through or not change in the way that you deal with the
> report?
>
> -mike
>
> --
> 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.)
>
>
> On Thu, Jun 26, 2014 at 4:14 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>>
>> I think the separate report URIs (via extra params or different end
>> points) is the easier option here.
>>
>>
>> On 25 June 2014 20:33, Neil Matatall <neilm@twitter.com> wrote:
>>>
>>> I'd like to propose adding a new field to the CSP reports: report-only.
>>>
>>> It's [arguably] valuable to know whether or not the policy was
>>> enforced when a given violation report is generated. Sometimes
>>> policies are enforced for a percentage or defined subset of users (or
>>> not at all), but there is no way to determine this from the report
>>> without "smuggling" params in the report-uri.
>>>
>>> As you can probably tell, I'm not entirely convinced this is even
>>> worth while (like my status code proposal).
>>>
>>
>
Received on Thursday, 26 June 2014 16:50:16 UTC

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