W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Reducing reporting noise

From: Chris Palmer <palmer@google.com>
Date: Fri, 20 Jun 2014 16:23:58 -0700
Message-ID: <CAOuvq22d9PbqbdvEA_Fy7UB9KXRnUncZBJz17hVGgmYsdg5RnA@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: "Hill, Brad" <bhill@paypal.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, "Daniel Veditz <dveditz@mozilla. com>" <dveditz@mozilla.com>, Neil Matatall <neilm@twitter.com>, Glenn Adams <glenn@skynav.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
How complicated does this need to be? Not very.

http://tools.ietf.org/html/draft-ietf-websec-key-pinning-15#section-2.5

"""UAs SHOULD make a best effort not to inundate report-uris with
redundant reports.""" Especially if they know they are on an expensive
data plan vs. (potentially not expensive) wifi and if they know the
battery is low.

On Fri, Jun 20, 2014 at 3:55 PM, Joel Weinberger <jww@chromium.org> wrote:
> I have very mixed feelings about this, although I lean towards the "let the
> collector deal with it." I guess I don't know how much bandwidth we're
> expecting these reports to take up, but I have trouble imagining it would be
> worth the trouble/danger of dropping reports.
> --Joel
>
>
> On Fri, Jun 20, 2014 at 3:01 PM, Hill, Brad <bhill@paypal.com> wrote:
>>
>> <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 23:24:25 UTC

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