Re: Reducing reporting noise

On Thu, Jun 19, 2014 at 11:50 PM, Daniel Veditz <> wrote:

> Capping reports per page

The danger here would be that an attacker could simply generate more than X
uninteresting reports before probing in more interesting places. I'm not
sure that's a huge risk, and some randomization scheme (reservoir
sampling?) would mitigate this risk, I suppose. Something to think about...

> 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.

This seems like a reasonable addition for 1.2.

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'd agree with Neil that this is probably something best left to the
collector, for the reasons he outlined.

Mike West <>
Google+:, 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 Friday, 20 June 2014 08:24:56 UTC