- From: Neil Matatall <neilm@twitter.com>
- Date: Thu, 1 Aug 2013 10:01:05 -0700
- To: Brad Hill <bhill@paypal-inc.com>
- Cc: public-webappsec@w3.org, Mike West <mkwst@google.com>
- Message-ID: <CAOFLtbgtGmYAt20Hczv_JfOnax0XVi1Z91FGuwcGO1rKME3DtQ@mail.gmail.com>
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:01:33 UTC