Re: CSP formal objection.

Dan wrote:
> On 2/8/2014 3:00 PM, Fred Andrews wrote:
> > * 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
> 
> Isn't that implicit in any spec? The HTML spec is advisory information
> on how the site would like the document to look/behave, and UAs do make
> differing choices on how or whether to implement parts of it.

While it's true that all Recommendations are voluntary and that user agents frequently implement only some of the features of a specification, we still think it makes a difference which features are marked optional and which aren't. For one thing, user agents may wish to develop fully conforming implementations to aid interoperability. Put another way, sites may wish to rely on or start to expect implementation of mandatory features from user agents that claim to be conforming -- where we know a feature is likely not to be implemented in a certain way for reasons we support, it makes sense to explicitly mark that feature optional in the spec.

> > and that a conforming UA could
> > choose to selectively enforce these constraints for the benefit of the user.
> 
> I haven't seen other specs include that kind of language, but it's
> effectively true in practice.
> 
> > * 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.
> 
> The spec should not declare reporting as opt-in or opt-out. It should
> define a syntax for how sites can make their reporting URL known, and
> define the structure of those reports so sites can parse them. We can
> include non-normative notes on these tradeoffs and concerns, but it's up
> to each UA to decide if they want to default to sending reports or not,
> or whether they'd ask users each time (like the geolocation prompt, for
> example).

The way I read the February 11th Working Draft, reporting is a mandatory feature of enforcing or monitoring a policy. For example, to implement the script-src directive: 
> • Whenever the user agent would execute an inline script from a script element that lacks a valid nonce and lacks a valid hash for the allowed script sources, instead the user agent MUST NOT execute script, and MUST report a violation.
And to report a violation:
> To report a violation, the user agent MUST:
> 	• Fire a violation event at the protected resource's Document, and
> 	• If the set of report URIs is non-empty, send violation reports to each.

That suggests not only that a conforming implementation doesn't have flexibility on defaults but that no option is provided to the end user. (That is at least how I understand Fred's concern.) It may be that the note Mike added in the editors' draft [0] addresses that concern, and if so, great! (Another alternative would be to change instances of "MUST report a violation" to "MAY report a violation".)

—Nick

[0] https://github.com/w3c/webappsec/commit/767017aae225d980624b2c5962f460d332a2fcf6