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

Re: Reducing reporting noise

From: Mike West <mkwst@google.com>
Date: Fri, 20 Jun 2014 10:24:08 +0200
Message-ID: <CAKXHy=d-8FQ-E=_VMKo95BamqDfM8nT52cuE6JjA3KP7DYCpRg@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Jun 19, 2014 at 11:50 PM, Daniel Veditz <dveditz@mozilla.com> 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 <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 Friday, 20 June 2014 08:24:56 UTC

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