- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Fri, 20 Jun 2014 16:16:02 -0500
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: Neil Matatall <neilm@twitter.com>, Glenn Adams <glenn@skynav.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi I am not sure we need a new "dont-report" or "freq-xxx" directives. I agree with Neil that it is easy for the server to filter these out. If this "server-side" filtering is too painful, relying on the JavaScript interface (say an event for each violation) makes more sense to me. A declarative mechanism like "dont-report" or "freq-xxx", imho, won't be flexible enough. It seems to me that such a JS mechanism can be achieved via a CSP-report-only header that has no report-uri. The SecurityPolicyViolationEvent listener can then filter and aggregate as needed and send the data to the server (modulo being pwned by XSS). I agree that, per priority of constituencies, capping reports to conserve bandwidth makes sense. But, I think this should just be left to the browser with the spec only saying some sort of MAY wording about capping reports. cheers Dev On 20 June 2014 13:56, Daniel Veditz <dveditz@mozilla.com> wrote: > On 6/19/2014 7:00 PM, Neil Matatall wrote: >> I feel it's the job of the reporting endpoint to make the decision to >> drop a report on the floor. I realize this is not consistent with the >> goal of reducing the number of reports sent, but hey. > > It is considerate of the user's bandwidth to avoid sending reports that > the content author knows are just going to get dropped anyway. > > -Dan Veditz >
Received on Friday, 20 June 2014 21:16:49 UTC