W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2013

RE: De-duplicating violation reports?

From: Hill, Brad <bhill@paypal-inc.com>
Date: Thu, 1 Aug 2013 16:35:23 +0000
To: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27B9A8CF@DEN-EXDDA-S12.corp.ebay.com>
<hat = website operator>

I agree it is much more valuable to receive reports that are de-duplicated for each instantiation of a resource.
From: Mike West [mkwst@google.com]
Sent: Thursday, August 01, 2013 2:55 AM
To: public-webappsec@w3.org
Subject: De-duplicating violation reports?

While poking at a bug in Blink's support of 'eval()' in report-only mode[1], Adam suggested rate-limiting the reporting to avoid a tight loop sending a great number of violation reports. That is, given a report-only policy that doesn't whitelist 'eval()', the following code will generate the same JSON object 1,000 times.

    for (i=0; i<1000; i++)

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? I could imagine changing the "send violation reports" steps to compare the JSON object against a list of the objects we've already sent, and abort if there's an exact match.

Is there value I'm missing in getting violation reports for each instance of a violation?

[1]: https://codereview.chromium.org/19787002/

Mike West <mkwst@google.com<mailto:mkwst@google.com>>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Received on Thursday, 1 August 2013 16:36:04 UTC

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