Re: De-duplicating violation reports?

I've made two changes to the draft based on this thread:

1. User agents _may_ abort sending a report if they've already sent the
same report for a particular resource:
https://dvcs.w3.org/hg/content-security-policy/rev/3f78b10650a9

2. Violation reports are (more) explicitly asynchronous, giving the user
agent more explicit control over when they're sent:
https://dvcs.w3.org/hg/content-security-policy/rev/298a82fd4068

What do you think?

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


On Thu, Aug 1, 2013 at 5:30 PM, Pete Freitag <pete@foundeo.com> wrote:

> On Thu, Aug 1, 2013 at 5:55 AM, Mike West <mkwst@google.com> wrote:
>
>> What do you folks think about going one step further than rate-limiting
>> the reporting by deduplicating the reports so that we send a unique JSON
>> object once and only once per page load?
>>
>
> Great idea!
>
> I think rate limiting the CSP violation reports still adds value as well,
> I've seen some cases where a server side debugging or error template that
> uses inline css or js in a loop can cause thousands of reports to trigger
> on a single page request. If an attacker finds a way to trigger such an
> output they could DOS the report collection servers.
>
>
>> Is there value I'm missing in getting violation reports for each instance
>> of a violation?
>>
>
> I don't see any lost value, as long as the json representation you are
> comparing also includes the source-file, line-number and column-number of
> the violation (a CSP1.1 csp-report) then it could be skipped IMHO.
>
> --
> Pete Freitag
> http://content-security-policy.com/ - CSP Quick Reference
>