Re: Reducing reporting noise

<hat=individual>

+1.

I think there's only so much we should clutter the declarative interface before it makes sense to expose an imperative one for advanced users and scenarios.

On Jun 20, 2014, at 2:16 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:

> 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 22:01:55 UTC