Re: Reducing reporting noise

Any plans to share this specification? I assume it's the same non-public
spec that you've mentioned before? :)

-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 Fri, Jun 20, 2014 at 12:35 AM, Glenn Adams <glenn@skynav.com> wrote:

> At least one derived specification (that makes normative use of CSP)
> restricts reporting for add-on/extension violations to directives specified
> in a Content-Security-Policy-Report-Only header.
>
>
> On Thu, Jun 19, 2014 at 3:50 PM, Daniel Veditz <dveditz@mozilla.com>
> wrote:
>
>> One roadblock for us in convincing our web devs to roll out CSP is the
>> amount of noise in the reports they get. Firefox could do a much better job
>> playing nice with add-ons, but we won't be able to completely suppress what
>> they're doing and add-ons aren't the only source of content injection.
>>
>> When creating a CSP-protected website you would normally adjust the
>> policy and fix bugs in the site until CSP reports no violations in normal
>> operation. After that point any CSP reports should indicate either an
>> attack or a bug in your site. However, in the real world people have
>> modified user-agents that trigger tons of spurious reports an it would be
>> nice if the policy could specify a way to suppress some of this reporting.
>>
>> There are several approaches that could be taken. These all address the
>> problem in different ways and could potentially be combined, or we could
>> decide only one (or none!) of these is interesting.
>>
>> Capping reports per page
>> ------------------------
>> If normal unmodified browsers have zero reports then any reports at all
>> should indicate a real attack. Modified add-on laden browsers generating
>> tons of inline script warnings don't tell you much, they are just noise and
>> load on the system. Therefore capping the reports at a small number is good
>> enough to diagnose real problems assuming you have a way to filter out the
>> noisy modified browsers.
>>
>> Syntax (new directive): max-reports 5;
>>
>> alternate keyword in report-uri directive:
>>    report-uri 'max-5' http://mysite.com/cspreports;
>>
>> The keyword is more compact and /should/ be backward compatible with old
>> implementations, but if it's not in practice then we'll have to use the
>> additional directive approach.
>>
>>
>> Throttling reports
>> ------------------
>> If sites are not staffed to investigate and respond to individual CSP
>> reported attacks (and I expect very few are) then for a high-traffic site a
>> sampling approach would work to catch non-targeted mass attacks. Today
>> sites could manually simulate this by randomly adding the report-uri
>> directive X% of the time and serving the policy without the rest of the
>> time, but it may be useful to off-load that to the UA.
>>
>> keyword approach: report-uri 'freq-XX' http://mysite/reports;
>>   (where XX is an integer 1-99 representing a percentage)
>>
>> directive approach: report-frequency 0.10;
>>   (where the number is the odds of sending 0-1)
>>
>> there's obviously not much point in setting the odds to 0 or 100%, just
>> use or don't use report-uri to get those states.
>>
>>
>> Selective reporting
>> -------------------
>> Sometimes you'd just like to reduce the noise in reporting but you don't
>> want to go so far as to allow the injected content or give up on reporting.
>> It would be nice to be able to suppress reports you already know about but
>> aren't going away any time soon (e.g. attempts by an ISP to inject a
>> tracker or ad).
>>
>> I'm afraid people will want extreme flexibility with this (e.g. suppress
>> reports of flickr being loaded as an image but still warn if it shows up
>> elsewhere) but that would make the "suppress" directive exactly as complex
>> as the whole rest of the syntax. For now I'm proposing simply to suppress
>> reporting about sites no matter where they were used
>>
>> dont-report flickr.com data: googleapis.com/some/path/ 'unsafe-eval';
>>
>> I'm not convinced letting people suppress reports of unsafe-eval and
>> unsafe-inline is a good idea, just raising the possibility. We might want
>> to invent new keywords to distinguish 'script-inline' from 'style-inline'
>> if we take this approach.
>>
>> -Dan Veditz
>>
>>
>