Re: Reducing reporting noise

On Fri, Jun 20, 2014 at 2:24 AM, Mike West <mkwst@google.com> wrote:

> Any plans to share this specification? I assume it's the same non-public
> spec that you've mentioned before? :)
>

DLNA has very recently made their specifications ("guidelines") available
to non-members at [1]. The specific guideline I refer to is the CVP-2
device profile found in Part 5: Device Profiles. However, the requirement I
refer to below regarding CSP is in the process of being added to this
guideline via the DLNA General Maintenance process. I will check if I can
disclose the exact proposed text of the change to this group before it is
added to the published guideline.

[1] http://www.dlna.org/dlna-for-industry/guidelines


>
> -mike
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
>
> On Fri, Jun 20, 2014 at 12:35 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>> At least one derived specification (that makes normative use of CSP)
>> restricts reporting for add-on/extension violations to directives specified
>> in a Content-Security-Policy-Report-Only header.
>>
>>
>> On Thu, Jun 19, 2014 at 3:50 PM, Daniel Veditz <dveditz@mozilla.com>
>> wrote:
>>
>>> One roadblock for us in convincing our web devs to roll out CSP is the
>>> amount of noise in the reports they get. Firefox could do a much better job
>>> playing nice with add-ons, but we won't be able to completely suppress what
>>> they're doing and add-ons aren't the only source of content injection.
>>>
>>> When creating a CSP-protected website you would normally adjust the
>>> policy and fix bugs in the site until CSP reports no violations in normal
>>> operation. After that point any CSP reports should indicate either an
>>> attack or a bug in your site. However, in the real world people have
>>> modified user-agents that trigger tons of spurious reports an it would be
>>> nice if the policy could specify a way to suppress some of this reporting.
>>>
>>> There are several approaches that could be taken. These all address the
>>> problem in different ways and could potentially be combined, or we could
>>> decide only one (or none!) of these is interesting.
>>>
>>> Capping reports per page
>>> ------------------------
>>> If normal unmodified browsers have zero reports then any reports at all
>>> should indicate a real attack. Modified add-on laden browsers generating
>>> tons of inline script warnings don't tell you much, they are just noise and
>>> load on the system. Therefore capping the reports at a small number is good
>>> enough to diagnose real problems assuming you have a way to filter out the
>>> noisy modified browsers.
>>>
>>> Syntax (new directive): max-reports 5;
>>>
>>> alternate keyword in report-uri directive:
>>>    report-uri 'max-5' http://mysite.com/cspreports;
>>>
>>> The keyword is more compact and /should/ be backward compatible with old
>>> implementations, but if it's not in practice then we'll have to use the
>>> additional directive approach.
>>>
>>>
>>> Throttling reports
>>> ------------------
>>> If sites are not staffed to investigate and respond to individual CSP
>>> reported attacks (and I expect very few are) then for a high-traffic site a
>>> sampling approach would work to catch non-targeted mass attacks. Today
>>> sites could manually simulate this by randomly adding the report-uri
>>> directive X% of the time and serving the policy without the rest of the
>>> time, but it may be useful to off-load that to the UA.
>>>
>>> keyword approach: report-uri 'freq-XX' http://mysite/reports;
>>>   (where XX is an integer 1-99 representing a percentage)
>>>
>>> directive approach: report-frequency 0.10;
>>>   (where the number is the odds of sending 0-1)
>>>
>>> there's obviously not much point in setting the odds to 0 or 100%, just
>>> use or don't use report-uri to get those states.
>>>
>>>
>>> Selective reporting
>>> -------------------
>>> Sometimes you'd just like to reduce the noise in reporting but you don't
>>> want to go so far as to allow the injected content or give up on reporting.
>>> It would be nice to be able to suppress reports you already know about but
>>> aren't going away any time soon (e.g. attempts by an ISP to inject a
>>> tracker or ad).
>>>
>>> I'm afraid people will want extreme flexibility with this (e.g. suppress
>>> reports of flickr being loaded as an image but still warn if it shows up
>>> elsewhere) but that would make the "suppress" directive exactly as complex
>>> as the whole rest of the syntax. For now I'm proposing simply to suppress
>>> reporting about sites no matter where they were used
>>>
>>> dont-report flickr.com data: googleapis.com/some/path/ 'unsafe-eval';
>>>
>>> I'm not convinced letting people suppress reports of unsafe-eval and
>>> unsafe-inline is a good idea, just raising the possibility. We might want
>>> to invent new keywords to distinguish 'script-inline' from 'style-inline'
>>> if we take this approach.
>>>
>>> -Dan Veditz
>>>
>>>
>>
>