- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Thu, 1 Aug 2013 10:19:54 -0700
- To: Neil Matatall <neilm@twitter.com>
- Cc: Brad Hill <bhill@paypal-inc.com>, public-webappsec@w3.org, Mike West <mkwst@google.com>
I think it is useful to have, but I am not sure what the advantage of spec'ing it would be. Maybe just leave it as a suggestion (non-normative?) in the spec? UAs can either implement dedup, or a throttle, or bunch up multiple reports into a single request. The spec is better off leaving it to the UA and its developers. On 1 August 2013 10:01, Neil Matatall <neilm@twitter.com> wrote: > Agree, although I have yet to come across this. This would also save on the > number of connections used, which are more limited on mobile devices w/o > spdy. > > On Aug 1, 2013 9:36 AM, "Hill, Brad" <bhill@paypal-inc.com> wrote: >> >> <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++) >> eval(...); >> >> 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>, 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 17:20:42 UTC