> You are right that leaving everything alone means that no browser changes > will break the web. However, by now I think it is clear that a substantial > minority (11%) of users do care about tracking [1],
I agree that a minority has set the DNT-1 signal, based on the information provided by the DNT Dashboard. It would be interesting if the DNT Dashboard also showed the number of signals received for DNT-0, DNT-unset (missing), and DNT-other (if any). For example, what would it mean if DNT-0 was also 11%? Those numbers could be interesting. Small aside: does the DNT Dashboard count raw requests, that is, could someone just ping the blocklist endpoint repeatedly to up-vote their favorite DNT signal? Expressing one's preference for DNT is not the same as "voting" for third-party cookie blocking. A better metric is to count how many people have actually enabled third-party cookie blocking, at least you'll be comparing apples to apples (i.e. counting people who have enabled cookie blocking to determine if the default should be cookie blocking). The weakness in this method is that for myself, although I have a variety of custom settings, I wouldn't expect Mozilla to make those the defaults for everyone, that is, I wouldn't want my custom setting used by Mozilla as a vote to make it the default. > and further more hardly > any users (< 1%), even technological enthusiasts, know about or can manage > their cookie settings effectively [2]. Going back to the CA analogy, > accepting all CA authorities by default would certainly not break the web in > the sense that pages will render effectively, but I am willing to bet that > most people on this list would think that enabling all CA authorities by > default is not a good idea [3]. I think the point of this effort was to move > the ecosystem so that all users benefit, not just technology enthusiasts and > privacy geeks. > > [1] https://dnt-dashboard.mozilla.org/ > [2] http://monica-at-mozilla.blogspot.com/2013/02/writing-for-98.html > [3] https://www.google.com/search?q=diginotar+revoke I think this illustrates that the UI needs to be reworked if users can't find or configure the cookie policy settings. I personally had to lookup where the setting was at, despite being a Firefox user for many years. It's definitely non-obvious that it's under "History", which I equate with browsing history, not cookies. But let's say you're right, the DNT-1 setting is a cry for help from 11% of users who can't figure out how to enable blocking third-party cookies, and they are representative of most users, who can't even set the DNT signal. If this is sufficient to enable cookie blocking by default, then surely it's sufficient to enable the DNT-1 signal by default? Or put another way, if 11% of users with DNT-1 enabled is sufficient proof that users don't want to be tracked, then why not default to DNT-1 "so that all users benefit"? > > I know the thought is to block advertisers from tracking users, but > > there's two problems with this approach, 1) there are non-advertising > > use cases that this breaks, and 2) advertisers are already moving to > > other state mechanisms, which leaves only the non-advertising use > > cases to bear the brunt of this feature. > > Granted, the Cookie Clearinghouse will help to some extent, but it's > > reactive and the earliest we'll see it in Firefox is toward the end of > > the year. > > The current, experimental policy is only on by default in Nightly and Aurora > users (0.1%), and so does not break the web for the vast majority of Firefox > users who are on stable or slightly behind [4]. From my reading of Brendan's > blog post the plan is to try out the Cookie Clearinghouse before progressing > the new policy, so there shouldn't be a time when the false positive case you > mention breaks the web for stable Firefox users. > > [4] http://en.wikipedia.org/wiki/Template:Firefox_usage_share I read Brendan's blog post, you're right, it appears this feature is on hold until CCH is available: "The CCH proposal is at an early stage, so we crave feedback. This means we will hold the visited-based cookie-blocking patch in Firefox Aurora while we bring up CCH and its Firefox integration, and test them." (source: https://brendaneich.com/2013/06/the-cookie-clearinghouse/) I guess that explains why Jonathan Mayer is seeing that this feature is being delayed: (https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c103) > > > We shouldn't let fear prevent us from experimentation, even if that > > > experiment fails > > > > Can you share the criteria of what constitutes failure for this > > feature? > > I think that some reasonable success criteria would include: > > - Cookie Clearinghouse is able to come up with well-defined criteria for the > lists and a reasonable way to maintain them > - Firefox is able to consume the lists with negligible performance overhead > - The lists function as intended (< x% for some small x false positives or > negatives for stable Firefox users) > - To your point about user confusion, in the case of false positives or false > negatives, the UI is sufficiently enlightening for enough people to report > the false positive or negative into Cookie Clearinghouse Thanks for clarifying. - Bil _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
