Reporting should be explicitly optional (was Re: CSP formal objection.)

Hey Fred. I'm forking this out to a separate thread, since it sounds like
your objection is quite distinct from Cox's.

On Sun, Feb 9, 2014 at 12:00 AM, Fred Andrews <fredandw@live.com> wrote:

> The original dispute was not just about 'fingerprinting'.  The dispute was
> hijacked, and misrepresented as just being about fingerprinting, and then
> the argument was made the fingerprinting is inevitable and thus CSP leaking
> more state is not significant.  Please do not attempt such strategies
> again, I find it offensive, and are wiser to the strategies used.  Please
> focus on the use cases and requirements, and the technical design of the
> specification for a conforming web browser.
>

In the interests of reducing misunderstanding this time around, would you
be willing to propose specific changes to the spec text? It might be more
productive to discuss a specific pull request to
https://github.com/w3c/webappsec/blob/master/specs/content-security-policy/csp-specification.dev.htmlthan
to go back and forth about the extent of the dispute in more general
terms.


> I do not believe there is a valid technical case for making reporting a
> requirement for a conforming user agent.
>
> * A desire by some service providers that reporting should be ubiquitous
> is not a valid use case or requirement and thus not a valid input into the
> design process.  The user is always free to opt-in if the reporting is in
> their best interests.
>

I don't understand why an author's use case is prima facie invalid.


> * The claim was made that the UA is still free to do as it wishes and thus
> websites could not depend on reporting.  However the CSP is a specification
> for a conforming UA, hopefully a common default that we endorse as being in
> the best interests of users, and a web site discriminating against
> conforming UAs will have much less standing.
>

What is the impact of this claim? In particular, what are you talking about
when referring to "discriminating against conforming UAs"? I don't
understand the concern.


> * The claim was made that the UA could just not implement CSP.  However
> this excludes the UA from much of the benefits of the CSP.  There is no
> valid reason to link a UA benefiting from CSP to a requirement that the UA
> report in a particular manner.
>

User agents don't directly benefit from CSP. The policies we're discussing
enable authors to mitigate the risk that their sites fall prey to content
injection attacks. Reporting makes it possible for authors a) to roll out a
policy without risking breakage on their sites (report only mode), b)
detect and close attack vectors used in the wild.

This protects both authors and users, and is a fairly critical part of the
feedback loop CSP is specced to provide.

* A lot of claims were made that securing the UA state was not a valid
> requirement, that the UA is already leaky.  I dispute this.  It depends on
> the environment that the UA connects to and there are many basic cases in
> which a UA controlling reporting would be effective.  It also ignores
> further defenses that the UA could take.
>

I don't understand this point.

If you're referring to the discussion we had a few months ago around the
impact of reporting on user privacy, then I'd reassert the claim that CSP
reporting doesn't make anything possible that isn't already possible via
existing DOM APIs (MutationObserver, event listeners, delayed measurement
via setTimeout, etc). We can have that discussion again, if you like.


> I believe there is a good technical case to make for reporting to be
> opt-in - a recognition that the user trusts the web site and wishes to
> report a violation to help the web site improve its CSP, but that in
> general users would be better not to be exposed to the risks of reporting.
> Enabling reporting should be the exception not the default.
>
> * I would like to see the CSP specification framed in a manner that makes
> it absolutely clear that the CSP is advisory information supplied by the
> web site to the UA with the intention that it defines constraints under
> which the web site will operate and that a conforming UA could choose to
> selectively enforce these constraints for the benefit of the user.
>

Under what scenario do you expect a user agent to choose to refuse to
enforce some aspect of a site's CSP?


> * The CSP specification should make it absolutely clear that reporting is
> feedback that could help a web site detect problems with these constraints.
>

This sounds uncontroversial. What text would you like to see added to the
spec to make this clear?

* It should be absolutely clear that the CSP is not intended to move
> security from the UA to the cloud via reporting.  That a web site is not
> expected to be able to depend on reporting or to use the reporting to
> provide a security service.
>

Authors can't depend on a user agent supporting CSP, and the spec
explicitly positions the feature as defense-in-depth. What text would you
like to see added to the spec to make this point more clear?


> * It should make it absolutely clear that reporting could be used to
> monitor or discriminate against the user and thus reporting is opt-in and
> not the default, and that a UA may need to implement further defenses.
> Some mention of extensions would be relevant in this context.
>

1. What text would you like to see added to the spec to make this clear?
2. What reporting do you believe CSP uniquely makes possible that poses
discriminatory risk to users?

Give recent actions by the Director of the W3C, making wild disputed
> interpretations of the principles of the web, it is no longer possible to
> just assume an interpretation and it will be necessary detail the
> interpretations being applied in the specification.
>

I'm not entirely sure what relevance this has to the discussion. Is there
anything in particular this implies that isn't covered in one of your
points above?

Thanks!

--
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.)