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

Re: Reducing reporting noise

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 25 Jun 2014 09:39:05 -0600
Message-ID: <CACQ=j+dUnskw34fsmZTmUE9R8GQVvoDABdPejOEbXJw5nfStvQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 25, 2014 at 3:10 AM, Mike West <mkwst@google.com> wrote:

> Thanks Glenn!
>
> On Wed, Jun 25, 2014 at 12:14 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>> On Fri, Jun 20, 2014 at 7:58 AM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>> 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.
>>>
>>
>> The proposed (draft) DLNA guideline requirements related to CSP are
>> essentially as follows:
>>
>> [Guideline] RUI-H User Agent of a CVP-2 Client MUST implement and
>> conform to the Content Security Policy [CSP] reference as defined by W3C
>> HTML5 Specification.
>>
>
> Sounds good!
>
>   [Guideline] If a RUI-H User Agent of a CVP-2 Client allows installation
>> of third-party extensions or add-ons that permits the injection of
>> third-party content (of any form) into a Web page, then the RUI-H User
>> Agent MUST apply [CSP] policy directives to the third party content when
>> those policy directives are sourced from a RUI-H Transport Server using
>> HTTPS.
>>
>
> It will surprise no one to hear that I think this is a bad idea, for all
> the reasons that we've discussed on the list.
>

Understood. I should also add that a note follows this guideline that
states:

[COMMENT] This guideline ensures that service provider or web application
CSP policies are not ignored by a RUI-H User Agent when processing
potential content injection by third-party extensions or add-ons. In
particular, this guideline mitigates vulnerabilities that may be introduced
through malfunctioning or malicious third-party extensions or add-ons. For
valid cases of user add-ons and extensions to support user control of
accessibility, security, diagnostics, key mappings, privacy and parental
control, the user and/or client manufacturer will need to inform the
service providers so that these extensions can be unblocked in the CSP
policy.

It is unclear whether this last sentence will be practical to implement or
not.


>  What constitutes a "RUI-H User Agent of a CVP-2 Client"?
>

Effectively the browser component of a smart TV (or device operating in
that capacity) when it is talking to a CVP-2 Server, e.g., for obtaining a
electronic program guide application (implemented with HTML5 et al), for
playback of media exposed from that guide, etc.


>
> Also: it's not entirely clear which policy directives the user agent is
> obligated to apply. Those of the protected resource, I imagine?
>

Correct, "when those policy directives are sourced from a RUI-H Transport
Server using HTTPS". In other words, the CVP-2 Server that serves up the
protected resource (e.g., electronic program guide application).


> "Third-party content" is also a bit poorly defined: do you mean
> "third-party" in the sense of cross-origin? Or any content at all (inline
> script, for instance)?
>

Here, "third-party content" would mean any content associated with or
sourced by a "third-party extension or add-on", e.g., script content of a
third-party extension.


>
>
>>  [Guideline] When applying CSP to a third-party extension or add-on, the
>> RUI-H User Agent MUST NOT report policy violations unless the violated
>> policy directive was specified in a Content-Security-Policy-Report-Only
>> header.
>>
>
> What problem is this solving? I don't understand the advantage of
> reporting blocked extension activity only in report-only mode.
>

This is an attempt to reduce reporting noise for violations by third-party
extensions and add-ons by limiting that reporting to the case where the
protected resource wishes to experimentally determine potential violations
by such extensions and add-ons. Otherwise, this is saying that violations
should not be reported during normal enforcement, i.e., when using
Content-Security-Policy header rather than
Content-Security-Policy-Report-Only header. Note that this reporting
reduction applies only for third-party extensions and add-ons.


>
>
> -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.)
>
>
>
Received on Wednesday, 25 June 2014 15:39:54 UTC

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