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

Re: Reducing reporting noise

From: Joel Weinberger <jww@chromium.org>
Date: Fri, 20 Jun 2014 15:55:28 -0700
Message-ID: <CAHQV2KmG7tWfYG7+c0+uiuWOtYhZz5yPOadaXOLwC0Ou8=j7FQ@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal.com>
Cc: 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>
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 22:55:56 UTC

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