Re: De-duplicating violation reports?

The spec currently strongly implies (at least) that a report must be fired
for each violation. I think we can soften that with some "may" language
along the lines you outline. Given that one job of the spec is to enable
interoperation, I'd prefer to err on the side of being overly clear about
what's allowed.

-mike
On Aug 1, 2013 7:20 PM, "Devdatta Akhawe" <dev.akhawe@gmail.com> wrote:

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