Re: Reducing reporting noise


I am not sure we need a new "dont-report" or "freq-xxx" directives. I
agree with Neil that it is easy for the server to filter these out. If
this "server-side" filtering is too painful, relying on the JavaScript
interface (say an event for each violation) makes more sense to me. A
declarative mechanism like "dont-report" or "freq-xxx", imho, won't be
flexible enough.

It seems to me that such a JS mechanism can be achieved via a
CSP-report-only header that has no report-uri. The
SecurityPolicyViolationEvent listener can then filter and aggregate as
needed and send the data to the server (modulo being pwned by XSS).

I agree that, per priority of constituencies, capping reports to
conserve bandwidth makes sense. But, I think this should just be left
to the browser with the spec only saying some sort of MAY wording
about capping reports.


On 20 June 2014 13:56, Daniel Veditz <> wrote:
> On 6/19/2014 7:00 PM, Neil Matatall wrote:
>> I feel it's the job of the reporting endpoint to make the decision to
>> drop a report on the floor. I realize this is not consistent with the
>> goal of reducing the number of reports sent, but hey.
> It is considerate of the user's bandwidth to avoid sending reports that
> the content author knows are just going to get dropped anyway.
> -Dan Veditz

Received on Friday, 20 June 2014 21:16:49 UTC