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

RE: De-duplicating violation reports?

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC