Am I the only one who notices the irony that adding an optional "Do Not Track" header increases the ability of the user to be tracked by adding server-side fingerprinting surface to the HTTP header? Also, if it's off by default, that implies that Firefox is endorsing silent tracking, which seems odd. If such a thing is to be included at all it should be on by default. Full disclosure: I think this "Do Not Track" flag idea is stupid. It's like trying to wear a "Do Not Mug" t-shirt and expecting to be immune to being robbed. It's downright naive to think that all sites will respect such a flag and a bit dishonest to our users to imply that such an option will work fully. Sites will track you if they feel like it, even if you ask nicely or try to pass largely unenforceable non-global laws. Sites do have a right to privacy of their own systems so if they are tracking you, even illegally, nobody is going to be able to know to attempt to stop them. This is not something that can be controlled in this manner. If we want to curb tracking, we need to reduce trackable things.

The feature is optional. Users don't have to turn it on if they are worried about fingerprinting and don't want to broadcast the signal. This feature is intended to address sites that want to play fair; many ad networks already have cookie-based opt-outs for tracking, and it is those web entities this feature is intended to work with. (More reading: http://donottrack.us/) Instead of users installing and reinstalling thousands of opt-out cookies, one single HTTP header signal may be used instead. Users who don't want to add the signal to their HTTP requests can select the opt-out cookies instead if they'd like. You're right though, this won't stop those unfair players -- those silent tracking sites who have no desire to honor user preferences. We should still work towards addressing that issue. But the header is a solution for the segment of web sites who wish to honor users' choices -- not the "muggers" out there. We can't turn the header on by default because that makes the feature meaningless; the point is to convey a user's desire to opt-out of tracking, so they must seek out the option and enable it so that presence of the header indicates user action and not just Mozilla's opinion.

That shady sites won't respect it doesn't mean it is valueless. That it exists doesn't mean it should be the default. I think this bug is based on a false dichotomy, and is probably WONTFIX.

(In reply to comment #1) > The feature is optional. Users don't have to turn it on if they are worried > about fingerprinting and don't want to broadcast the signal. Very few users know what fingerprinting is. All they will see is an option labeled "Tell web sites I do not want to be tracked" which when turned on will be respected by the few sites that might, ignored by the rest, and adds trackability through server-side fingerprinting for any site that wishes to do so. This option fundamentally doesn't do exactly what it implies: stop tracking. Note by the way that one of the few points to come to any sort of consensus in the long and winding fingerprinting debate is that server-side fingerprinting is a larger problem than client-side. Server-side can be mitigated a lot, and the UA string cleanup, namely arbitrary addition banning, has already improved things. Client-side can be improved, but is honestly a lost cause; there will always be something to fingerprint with. In this regard, bug 629535 makes more sense to me than bug 628197. > This feature is intended to address sites that want to play fair; many ad > networks already have cookie-based opt-outs for tracking, and it is those web > entities this feature is intended to work with. I don't think that those who want to curb tracking should be playing the tracker's game, so to speak. Third-party cookies should just be banned by default, with no option to re-enable, and the few legitimate uses for them should get a suitable replacement. (likewise for Flash LSOs, localStore, & etc.) Opt-out systems of this nature are dubious: most people don't know they exist and won't opt-out, but if instead most people did opt-out then the systems would not want to respect the opt-out anymore as that would essentially get rid of their entire opt-out system. > Instead of users installing and reinstalling thousands > of opt-out cookies, one single HTTP header signal may be used instead. Users > who don't want to add the signal to their HTTP requests can select the opt-out > cookies instead if they'd like. This is such an obscure feature that I can't see how it ends up built-in. This is normally the sort of thing that would belong in an addon (possibly even a Mozilla sponsored addon). > You're right though, this won't stop those unfair players -- those silent > tracking sites who have no desire to honor user preferences. We should still > work towards addressing that issue. But the header is a solution for the > segment of web sites who wish to honor users' choices -- not the "muggers" out > there. If it's not 100%, or anywhere close to it, or even a measurable amount, then what's the point? All I see is what is essentially an optional protest header, not a real feature. If a user wants to stop tracking they should be using better cookie policies, not asking an amorphous group of trackers to "play nice" with no way to verify its effect. > We can't turn the header on by default because that makes the feature > meaningless; the point is to convey a user's desire to opt-out of tracking, so > they must seek out the option and enable it so that presence of the header > indicates user action and not just Mozilla's opinion. Given the choice, pretty much every user will choose not to be tracked. Thus, the only way to not have all users opt-out is to bury the option instead of asking up-front, which is not acting in the users' best interest. Mozilla as always needs to consider the users' best interests here, and that means taking an official opinion. As of right now, the official opinion is to not ask users about this new option and instead only let the rare few who know about it use it, which is not consistent with the sentiment of respecting the users' option on the matter. Personally, I think a much better route would be to have a user configurable privacy policy which is exposed via JavaScript and could contain a full set of generic privacy preferences to be used as a starting point for all sites, not just tracking. That could do a lot more for users, but would take a lot more effort than a fairly meaningless HTTP header flag.

I can't tell what this bug is asking for. Seems to be at least two bugs: 1. Set DNT to on by default 2. Replace the HTTP header with some sort of JS thing This bug can't be both things. What are you asking for, here, Dave?

> Am I the only one who notices the irony that adding an optional "Do Not > Track" header increases the ability of the user to be tracked by adding > server-side fingerprinting surface to the HTTP header? You aren't the only one. I noticed it, too. It's less ironic than having to accept a personalized cookie in order to opt out of tracking, though, so I think DNT should stay. > Given the choice, pretty much every user will choose not to be tracked. > Thus, the only way to not have all users opt-out is to bury the option > instead of asking up-front, which is not acting in the users' best > interest. Turning DNT on by default would defeat its whole point. The point is that DNT is proof of *explicit user action* to request not to be tracked. It isn't a technical solution that makes tracking technically impossible. It's input into the court system and policy making where otherwise it could be argued that the users mind about tracking. Explicit user action saying users don't want to be tracked is much stronger policy-making input than a browser vendor deciding on the users' behalf. (OTOH, if all browsers ship the ability to opt to broadcast DNT: 1 and then only a handful of users opt into doing so, we'd end up giving the entities engaging in tracking the lobbying argument that people truly don't care.) DNT won't work against sites that don't care about the law or courts. That may make DNT ineffective against small-time trackers. However, the entities that have the most ability to track users across the Web most likely need to pay attention to courts and policy-making. So that was a long way to say I think this should be WONTFIX.

(In reply to comment #4) > 1. Set DNT to on by default > 2. Replace the HTTP header with some sort of JS thing Either one would be better than the current situation. My point is that the current arrangement is in a weird middle ground where there's an option Mozilla created purportedly to help users resist tracking, that they're probably not going to be aware of, that when turned on might decrease one type of tracking whilst also increase another type of tracking. If people really want to attempt this flag, which is probably not going to do what everyone really wants, I think an in-JS solution (where the tracking scripts often are) is better, and asking the user up-front would be a big step up from a buried option. I think you might actually even be able to get more people to opt-in to the opt-out via a (possibly Mozilla sponsored) addon, maybe even advertized on about:home. On the topic of setting the DNT flag on by default: (in comment #1) > We can't turn the header on by default because that makes the feature > meaningless; the point is to convey a user's desire to opt-out of tracking, so > they must seek out the option and enable it so that presence of the header > indicates user action and not just Mozilla's opinion. (also in comment #1) > (More reading: http://donottrack.us/) The front page of donottrack.us has this under the section "Dig Deeper": "Do Not Track vs. Blocking vs. Opt-Out Cookies. Harlan Yu and Jonathan Mayer explain [...]" and Jonathan Mayer's linked to explanation is: http://cyberlaw.stanford.edu/node/6559 On that page: "Q: Would Do Not Track be enabled by default? Do Not Track could be a default; this is up to browser vendors, legislators, and regulators. Owing to conflicting business interests and engineering demands, we find it unlikely the major browser vendors will voluntarily enable Do Not Track by default. We caution in general, however, against regulation of client software, which has historically proven challenging." So, your own reference references a Q & A which has nothing against turning DNT on by default if a browser vendor believes it's in the best interests of itself and its users. Mozilla's often stated mission is a more open Internet, and the mere fact that this option is being added (late in the Firefox 4.0 game, might I add) is proof that Mozilla wishes to take some sort of a stand here in the users best interests. Thus, based on your own reference materials, Mozilla can and probably should put it on by default if it is to have it.

Dave, please feel free to re-open this bug if you can make it about a single thing - seems from comment 6 you want it to be "Set Do Not Track Header to be on default". Right now, the bug report isn't actionable, as it's unclear what you're asking for. FWIW, I don't think that the best solution for users is to set the header to be on by default. I think that the header is part of a broader solution in which the browser provides information to users about which websites (if any) are tracking their activities, and what actions they can take.

It is about a single thing: not doing what we're doing now. I could file 3 separate bugs for all the possible options to replace the current state, but that wouldn't be very productive and would be a mess to discuss. You could consider this bug either to be meta or in-waiting to be morphed into a bug specifically on a decided upon solution. Any of the following are an improvement: 1) Get rid of this flag entirely (possibly moving it to an addon) 2) Get rid of the HTTP flag and use only a JS flag 3) Turn on DNT by default and allow users to opt-out of the opt-out I prefer #1, but so many people wish this could work that it's probably not wanted, so #2 or #3 would be a more likely choice by whomever gets to make the final decision here. (In reply to comment #7) > I think that the header is part of a broader solution in which > the browser provides information to users about which websites (if any) are > tracking their activities, and what actions they can take. Except that it doesn't do that, at least not yet. Right now, with the current implementation, it doesn't work in the best interests of users, in my opinion. (see paragraph 1 of comment 6) If it _did_ provide real feedback of results it might be more useful, though I'd still prefer it get out of the HTTP header into a JS value as that's still a server-side fingerprinting risk.

Dave, you are right that most users won't know or care about DNT without a lot of user education and awarness. There is an extra level of responsibility to create that awarness after the feature ships. DNT is just about users signalling intentions, to try and get web sites and ad networks to try and understand user preferences. even just 5% of the web population actively taking a step to turn on DNT after firefox 4 ships can be enough of a signal that some top sites and ad neworks could start to wake up and go to work on re-building their web sites and services to offer a DNT option. If DNT is turned on by default then its just mozilla sending a signal to the websites and ad networks on what we think they ought to do. that's not going to be very effect, and will be largely ignored. the part that is missing in the current DNT implementation is the other half of the user vote. some users might prefer targeted ad's that they believe improve their web experience. the current implementation does not offer the choice to send that signal to websites. Without that half of the data I think we leave web sites too much wiggle room to say that the data on site visits is inconclusive which could result in continued in-action. the UI, prefs, and header really need be a voting choice. Don't want to be track by sites and ad networks [X] | [ ] Want targeted Ads And then users need to pick which side of this issue they are on to send the most complete and accurate message to the web sites and ad networks. Which Side Are You On? I know Sid wants to do this kind of thing on the back end, but it seems we can't get UI resources to understand and design something like this in time for firefox 4.

> some users might prefer targeted ad's that they believe improve their web > experience. I'll also add that this is the basic premise that web sites and ad networks are building sites and infrastructure around today. The industry is making the assumption that users want or need this to get the most of of their sites/services. If only a small percent of users actually check the [ ] Want targeted Ads box, that also sends a strong message from users that they don't agree with that design principal that pervades the industry and shows up in quotes from industry leaders like "you don't have privacy on the internet any more, so get over it..."

(In reply to comment #9) > the UI, prefs, and header really need be a voting choice. > > Don't want to be track by sites and ad networks [X] | [ ] Want targeted Ads > > And then users need to pick which side of this issue they are on to send the > most complete and accurate message to the web sites and ad networks. This I would be in favor of. It's the current implementation, specifically the fact that it uses an HTTP header flag that I am complaining about in this bug. For those who weren't around for all of the long and winding fingerprinting debate (bug 572650 and dependencies), the reason server-side fingerprinting is a bigger problem that client-side fingerprinting is two fold: 1) There is _way_ more to fingerprint on the client side, so much so that it's very hard to minimize and can't really be eliminated to any fully meaningful degree. 2) Server-side fingerprinting using the HTTP header is faster and can be done transparently to the user. At least with client-side fingerprinting you can check the code and see what's being gathered, by and large. If it's all done from the HTTP header, nobody will ever know. The server-side fingerprinting problem has already been improved vastly. Previously, any extension could add whatever junk it wanted to the user agent string in the HTTP header with just a preference addition. This ranged from Megaupload addons to .NET versions, sometimes _many_ at once leading to giant and unique UA strings. This meant the HTTP header alone could be used to identify the user rather accurately. The UA problem was fixed for Firefox 4 (bug 581008) which helps a lot here. Adding a new header line only upon user request makes those few users who do so more identifiable via their HTTP header alone, which is particularly bad for those who are explicitly trying to reduce tracking, not add to it. > Which Side Are You On? Actually, I want targeted ads in general. Theoretically, that would mean fewer ads that are more likely to not be useless, but until that's a reality this isn't helpful yet. As I said above, I would like a full generic privacy policy, including this issue, to be user customizable available via JS. However, that's not what we have here. If you want me to sum up the minimum I want done here, it would be to remove the entropy added to the HTTP request when trying to opt-out of tracking. Turning it on by default would mean entropy would only be added by those opting into tracking, thus not as much of a problem because they asked for it, though probably still not ideal. Removing it from the HTTP header and using a JS value (bug 629535) instead is preferable because tracking scripts are going to want access to this to make a call on what to do anyway.

Well, right now, if I'm honest, my position is to just use Adblock Plus and block all ads as the entire system has long since abused its power to the point of where no sane person can tolerate it. If somehow we got back to a world with a limited number of non-useless and non-Flash (i.e. slow, more annoying, and potentially virus carrying) ads, then maybe I and others wouldn't need ad-blocking anymore. But because one ad group can ruin it for everyone, that's probably not going to happen, at far least not any time soon.

I think that the fingerprinting problem could be solved by using a list of domain patterns to which we want to send the DNT header. This can be used both to send a "track me" signal to some sites, but also to send it just to those sites known to obey it (I expect there would be addons carrying such lists). Sending it to every domain would be equivalent to adding the '*' pattern.

Henri's point in comment #5 is an important one. Default browser actions will never stand up in court as indications of the user's intent. Even if a vanishingly small number of users turn the header on, the ad networks won't be able to make the claim that "nobody cares". But Mozilla does need to do a much better job of explaining to non-technical users what the browser does and how to use features that are now effectively hidden. Anybody want to take bets as to how many users have never opened the preferences dialogs? We also need an outreach program for web content creators (not just web developers) to build buzz on the issue. My blog shows the user whether or not DNT is turned on. Does yours?

(In reply to comment #14) None of this will stand up in court, especially because there's no real way to know if some random site/service is secretly tracking you, thus no way to even bring them to court if you wanted to, let alone were able to. To play the devil's advocate, however, if it were set to on by default that would indicate the wishes of Mozilla picking the default setting in their opinion of what is in the best interest of their users (who would still have the right to opt-in to tracking via the preference). The user did intend to install Firefox, and Mozilla has stated positions with respect to Internet privacy, of which a dislike for secret tracking would generally be in line with. Thus, even if the DNT flag were to be on by default it would _still_ mark user intent indirectly because the user did choose to install Mozilla Firefox, with known policy, and Mozilla did intend to set the DNT flag to be in line with said policy. Besides, if any of this is to have any real legal backing (which I still say is BS), the flag has to be respected always, regardless of who set it. It would be a double standard to say a DNT flag isn't valid because a user who doesn't want to be tracked lacks the technical knowledge to turn it on but their chosen browser starts with it on for them.

Assuming that the user installed it because he likes Mozilla point of view in privacy is really weak. And that kind of users is precisely those that don't need the feature automatically on. The "Firefox is endorsing silent tracking" problem can be by overcome by adding a checkbox to enable it on profile creation/migration. Making it a prominent option shows that Mozilla is serious about it, while still leaving the final decision to the user.

(In reply to comment #16) > Assuming that the user installed it because he likes Mozilla point of view in > privacy is really weak. That's a misinterpretation of what I said. One of the top reasons people install Firefox is for better security and privacy, this is known and an intended selling point (especially in comparison to the still #1 browser, IE). DNT clearly falls under this umbrella, and thus is a reasonable expectation following the same expected policies. Fundamentally, any time anyone installs software on their computer they are trusting the vendor. It's a chain of trust from trusting Firefox to trusting Mozilla to then trust what Mozilla does with Firefox, which includes DNT. It's the same concept that allows a user of Firefox to connect to their bank's site and trust that the EV certificate verifies its identity and that the encryption is valid. There's a chain of trust from the user trusting Firefox to Mozilla (specifically NSS) to trusting the cert chain built into that version to trusting the site verified by that. I don't need to trust the server at the IP returned for the domain I typed in, and I don't need to trust VeriSign or whomever either; I trust that Mozilla trusts VeriSign that trusts the organization that owns the domain on that IP. Almost no Firefox users have any clue as to the complex chain of trust that goes into connecting them to a secure site, and they don't need to. All they need to do is trust Firefox to do it for them, which they are implicitly doing. In the same manner that one trusts Mozilla to only allow good security settings, it is perfectly reasonable to expect to trust Mozilla to only allow good privacy settings. And again, see comment 6; the official reference materials are not against allowing a vendor to have DNT on by default. > The "Firefox is endorsing silent tracking" problem can be by overcome by adding > a checkbox to enable it on profile creation/migration. Making it a prominent > option shows that Mozilla is serious about it, while still leaving the final > decision to the user. As I already stated above, I think this sort of thing might be much better. (though, for it to be a true choice it'd have to be two buttons or a set of radio buttons with no default; a checkbox has a default state, and people usually use defaults)

The sort of case in which I believe it would stand up in court is one where a government entity (e.g. FTC in the US) mandates observance of the header and subsequently brings complaints against egregious violators. Admittedly the history of the email spam problem isn't encouraging, but I don't think that argues against trying.

If someone is secretly tracking people you can't just make a law or regulation and it goes *poof* and away like magic. You won't even be able to tell... it's secret. Unenforceable rules aren't helpful, especially if they do the _opposite_ of the intended effect for those who ignore the rules. At most, it's something you might be able to try to prosecute or sue over after-the-fact or on top of some other charge, which is useless. It won't prevent much; you're kidding yourself if you think the DNT flag is going to curb tracking to any useful degree. This is an idea seized on by people who want a quick and simple fix. There isn't a complete one that's this simple. A real solution would require a more wide range of user privacy settings exposed to sites that would respect them coupled with the banning of all methods by which tracking is done at all for those who won't. It wouldn't actually be hard to do either, but users would have to give up the notion of letting sites remember login or other info indefinitely. The only part requiring much effort would be to fix whatever few things need 3rd-party cookies before removing support for them altogether. (the harder part was getting the ability to clear Flash LSOs with cookies, but we already got that recently)

Another vote for WONTFIX. Policy concerns about Do Not Track are best addressed in a policy forum. Dave: though I largely disagree with your views, I strongly encourage you to continue contributing to the Do Not Track debate.

This like the Catch-22 paradox: https://secure.wikimedia.org/wikipedia/en/wiki/Catch-22_%28logic%29

(In reply to comment #21) > This like the Catch-22 paradox Er... not it's not. Having the do not track flag increase trackability via server-side fingerprinting is standard irony, not a paradox.

Ah yes, now I get it...Fingerprinting is based on the amount of users that have a certain value....and considering that many users still use IE6 to this day http://www.theregister.co.uk/2011/03/04/microsoft_ie6_migration/ (4th march) ...there will be alot more users using other older browsers in general...plus there is still no defined standard...chrome is saying they are going to use another "do not track" header" etc etc.

If Microsoft keeps its current planning, IE10 will have DNT on by default. http://arstechnica.com/information-technology/2012/06/internet-explorer-10-embedded-flash-do-not-track-and-stable-standards/

DNT is not going away, nor do we have any plans (that I know of) to turn it on by default. Gerv

3 years on, and this bug should be reopened. DNT has been a failure for privacy protection The problems: ============== 1) Yahoo, Google and facebook all ignore do not track requests (probably 3 of the biggest companies). http://www.pcworld.com/article/2150981/yahoo-drops-do-not-track-policy-in-favor-of-personalized-experience.html https://support.google.com/chrome/answer/2790761?hl=en http://www.businessinsider.com.au/facebook-will-not-honor-do-not-track-2014-6 2) There is no incentive for advertisers to use this, and yet, they are the ones required to adopt it. The only way this could work is if there were laws to enforce it 3) Some sites which have policies claiming they don't track users, actually do - http://whitehouse.gov http://rt.com/usa/175116-white-house-website-canvas-fingerprinting/ YES, even the American president isn't respecting the DNT. 4) Worse, it adds 1 new source of entropy for fingerprinting. And since it is off by default, turning it on makes it easier to track users. If you turn it on, you are also acknowledging that you are more likely to be a technical user (since nobody would leave this off if they were aware of it). Solutions ======================================== 1) Develop an addon to randomises DNT on internet IP change. This puts us onto offensive, and eliminates its usefulness for tracking. 2) Don't use DNT.. If it isn't on by default, or an intentional choice by users on first run, its basically like waving a flag (if you are only 1 in 10000 people using it). 3) Mozilla should turn it on by default. A large source of funding for Mozilla is Google, and they don't respect it anyway. So from a business decision, it shouldn't matter. For an ethics decision, users should be safe by default, and instead opt out (which makes opted out people easy to track, which they don't care about anyway)