- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Wed, 12 Feb 2014 00:22:03 -0800
- To: Fred Andrews <fredandw@live.com>, Mike West <mkwst@google.com>
- CC: Web Application Security Working Group <public-webappsec@w3.org>
On 2/8/2014 3:00 PM, Fred Andrews wrote: > The original dispute was not just about 'fingerprinting'. The dispute > was hijacked, and misrepresented as just being about fingerprinting I never understood what you were getting at. I apologize if I helped hijack it by trying to understand it in terms of a scenario that made sense. I still do not clearly understand. > I do not believe there is a valid technical case for making reporting a > requirement for a conforming user agent. Browser vendors (some at least, Mozilla & Google) think reporting will help sites detect attacks and protect their users. Some site devs seem to agree, others have found it to be too much noise. > * 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. Who are you to say anyone's desires are "not valid"? Specs are forged by people with different interests and emphases, and balancing competing interests is hard. It doesn't help to simply dismiss others as invalid. [I haven't heard anyone express a desire for ubiquitous reporting so that's a strawman to begin with. And if anything it's been browser vendors preaching the benefits of reporting, not service providers demanding it.] > 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. That's not a "technical" case, but it's a perfectly valid opinion. Thank you. > * 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. > 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). -Dan Veditz
Received on Wednesday, 12 February 2014 08:22:31 UTC