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

Arg. Sorry, I didn't realize Dan posted to the other thread. Copy/pasting
my response here; let's keep this discussion on this thread. :)

Everything else to the side, we do currently call out the 'referer'
header explicitly as something the user agent can restrict above and beyond
what
the 'referrer' directive implies. Would it sufficiently address
your concerns to add a note along the lines of "Note: This specification
should not be interpreted as limiting user agents' ability to apply
other restrictions to limit data leakage via violation reports." to
the 'report-uri' section of the spec?

On Tue, Feb 11, 2014 at 11:05 PM, Bjoern Hoehrmann <derhoermi@gmx.net>wrote:

> I find it rather inappropriate to ask reviewers to edit the HTML for
>  you, it should be entirely sufficient to ask them to sketch out some
> of the text or to sketch out changes that would remove their concern.
>

Sure, forking the repo and editing the HTML is above and beyond. My intent
was simply to avoid the misinterpretation that the previous iteration of
this thread suffered from, not to farm out the work of editing the spec.
Looking at specific proposals rather than arguing about whose use case is
"valid" seems like a clear way to focus the discussion on things that we
can agree that we're talking about. :)


> >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.
>
> That is never an acceptable response to privacy concerns.
>

I disagree. "X is already available." is a pretty reasonable response to
"If we do Y, X will be available."

That said, I'd certainly agree that it doesn't absolve this WG of privacy
concerns. In the context of my understanding of the previous conversations
I participated in, however, I do believe the response is sufficient.

>Authors can't depend on a user agent supporting CSP, and the spec
> >explicitly positions the feature as defense-in-depth.
>
> It seems entirely possible to write code that breaks when CSP is not
> supported or only selectively enforced/reported.
>

1. This is possible with any feature, isn't it?

2. I don't understand the impact of the claim. My response was to the
specific question as to whether "CSP is not intended to move security from
the UA to the cloud via reporting." Explicitly positioning CSP as a
defense-in-depth seems exactly on point.

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