The Mozilla community has debated third-party tracking countermeasures for years. I've opened this meta bug to centralize efforts and discussion. I should begin by noting how tracking countermeasures complement Do Not Track (Bug 628197 and others). In theory, Do Not Track provides a polite and tailored solution to web tracking: users express a preference, and websites adjust their behavior to honor that preference. I share the view that Do Not Track is the best long-term direction for user control over third-party web tracking. At present, however, negotiations about the Do Not Track protocol and compliance policy have nearly stalled in the W3C Tracking Protection Working Group. Moreover, even once Do Not Track is settled, there will be some websites that decline to comply; effective countermeasures are needed to protect users against those websites. Here's a rough snapshot of what the Mozilla community has worked on so far: -Third-party cookie blocking (Bug 421494 and many others). Landed as a user preference, disabled by default. Firefox always prevents both setting and getting third-party cookies, so the current implementation breaks just about any stateful first-party-as-a-third-party UX (e.g. Facebook social integration widgets). -Session-only third-party cookies (Bug 565475 and Bug 570630). Landed as a user preference, disabled by default. The current implementation breaks the stateful UX for websites that are both first-party and third-party. A Google user, for example, will usually have to re-login with every launch of Firefox. -Double-keyed third-party cookies (Bug 565965). A work in progress for > 2.5 years. I'm uncertain what the present status is. -Reduced browser fingerprinting surface (Bug 572650 and others). Many small tasks, lots of progress under the hood. -Link HTML 5 storage APIs to third-party cookie blocking (Bug 536509). Reported about 3 years ago, still not fixed. I hope the Mozilla community will be able to settle on a long-term plan for effective and usable tracking countermeasures. But, in the interim, users are left in the lurch. As a near-term step, I'd propose adopting a version of Safari's longstanding third-party cookie blocking model. It's far from comprehensive in its effectiveness, but it does appear to provide a significant privacy improvement without breaking much UX. I'll open a new bug on the issue shortly.

Added Bug 818340 on Safari-like cookie blocking.

Hi Jonathan, Thanks for starting the bug, it's great to have a roundup of work that's been done and/or promised, especially for new people like me. Taking a step back, this meta bug seems to concentrate heavily on features without much analysis on how to triage them. As far as I know, we have basically zero data on what the distribution of cookies looks like (e.g., how many are first party vs third party, if it's long tail, if it's long tail pair-wise, how many are associated with ads vs. social widgets vs. SSO). More importantly, we don't have great insight into what kinds of tracking users want to prevent most, whom they want to avoid, how much effort they are willing to put into avoiding tracking, how many users really use social widgets and when, etc. There are a couple of ways that I can think of to gather some of this information. One is TestPilot (https://testpilot.mozillalabs.com/), which is installed by default on Aurora and Beta and runs studies approximately every 6 weeks. The studies can include surveys in addition to silent in-browser measurements. I have a test pilot study going out to measure security and privacy prefs exposed in about:config in the next couple of weeks. The other, more nascent effort is the Collusion data sharing API. The API has yet to be specified, but the goal is to be able to share cookie graphs in order to track the trackers. This work is being done primarily by Dethe Elza in collaboration with a bunch of design students and faculty at Emily Carr. Without more data on what users want and understand, implementing any changes to cookie management functionality is going to be a shot in the dark at best. I brought up safari-like blocking in the security eng meeting yesterday, and the general feeling in the room was that it was not an obvious win. For example, if a person wants to use Facebook, but not Facebook widgets, Safari-style isn't going to help. Per-site 3rd party cookies, which is launching in FF 18, will. This is just anecdata, of course, but I think it illustrates that in order to make our efforts have the most impact, we really need to understand our users better. Thanks, Monica

Monica, I certainly agree that a priority-setting discussion would be beneficial. The current set of Firefox options offers a lot to advanced users, and extensions enable even greater control over tracking. It seems uncontroversial to observe, however, that most users presently do not—and cannot—configure Firefox to conform to their privacy preferences. Any effective solution will have to grapple with issues of substantive countermeasures, user interface, and defaults. On the question of user preferences, I would firmly reject the premise that we do not know enough to begin taking action. There's a veritable cottage industry of tracking preference surveys, with nearly all pointing to the same conclusion: a majority of users don't want to be followed around the web. Here's a sample. http://ssrn.com/abstract=2152135 http://pewinternet.org/Reports/2012/Search-Engine-Use-2012.aspx http://truste.com/ad-privacy/TRUSTe-2011-Consumer-Behavioral-Advertising-Survey-Results.pdf http://gallup.com/poll/File/145334/Internet_Ads_Dec_21_2010.pdf http://aleecia.com/authors-drafts/tprc-behav-AV.pdf http://ssrn.com/abstract=1478214 There is also compelling evidence that current tracking control options are inadequate for ordinary users. http://lorrie.cranor.org/pubs/msp2012020093.pdf http://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab11017.pdf http://aleecia.com/authors-drafts/wpes-behav-AV.pdf As to questions about the prevalence of tracking companies, technologies, and countermeasures—I have research on these very topics coming soon. The results generally confirm conventional wisdom in the computer privacy field. In thinking through next steps, it seems important to bear in mind that imperfect countermeasures can still substantially benefit users. Consider this version of your hypothetical: a user wants to stop all third-party tracking, including by Facebook. Safari-like cookie blocking certainly will not help the user with Facebook. But it will give the user some protection against the rest of the tracking they object to—a significant improvement over the status quo. Apple came to this recognition with Safari 1. Microsoft did with Internet Explorer 6. It's about time by Firefox 18. Best, Jonathan

One key countermeasure is not loading all those beacons. IE9 has support for blocking resources built in. Firefox outsources it to Adblock Plus.

I don't think it is useful for tracking protection that we introduce safari-like 3rd party cookie policy. If user have visited an advertising network domain once, this policy sends its 3rd party cookie. This model don't allow that user dislike tracking by advertising network but he sometimes click it. This model only allow that user will *never* click any advertising network. Its assumption is unreasonable. And, this model cannot protect from the fear of tracking by big domain which provides general services (e.g. Search engine, SNS, etc). This is unfair judgment. I think that implement per-domain DNT signal is better than this approach. (Of course, I understand that DNT is not a perfect protection model.)

This policy is a good step in the right direction. Personally, I think after this is done and on by default we should consider forcing expiration of 3rd party cookies after some moderate time period to clear out the ones users don't need. (not exactly sure how you'd decide which ones to expire, however)

Firefox alead(In reply to Dave Garrett from comment #6) > This policy is a good step in the right direction. Personally, I think after > this is done and on by default we should consider forcing expiration of 3rd > party cookies after some moderate time period to clear out the ones users > don't need. (not exactly sure how you'd decide which ones to expire, however) Firefox already has a (hidden) "network.cookie.lifetimePolicy" pref to auto-expire cookies after "network.cookie.lifetime.days": http://kb.mozillazine.org/Network.cookie.lifetimePolicy Is there any user-friendly reason to allow cookies to live for years or decades? I think this pref should be enabled by default with a 3 or 6 month lifetime.

(In reply to Chris Peterson (:cpeterson) from comment #7) > Is there any user-friendly reason to allow cookies to live for years or > decades? I think this pref should be enabled by default with a 3 or 6 month > lifetime. That certainly sounds useful. I'd prefer something closer to 1 month or a week rather than drawing it out. The worst case scenario would generally be that the user would have to log back into a site they use rarely, which is not a big deal. For 3rd party cookies, however, I was thinking something like bug 818340, but instead of just blocking cookies from sites the user hasn't visited it would also block cookies from sites not visited recently. > Is there any user-friendly reason to allow cookies to live for years or > decades? Even if there is, I don't see how it would be worth it. I don't particularly like the idea of having sites the user has forgotten about staying logged for near forever. > Firefox already has a (hidden) "network.cookie.lifetimePolicy" pref to > auto-expire cookies after "network.cookie.lifetime.days": Does this set a fixed or a maximum lifetime? It would be nice to add a separate always-active "network.coolie.maxlifetime.days" and set it to 1-3 months or so. (as I said, I like the low end better, but the best UX might want 2 or 3) It would be better to be separate so this and the existing options could coexist, though as has been said elsewhere, the existing options are overdue for gutting. The whole cookie prompting system is technically an unsupported feature that isn't supposed to be available to users. (I don't remember which bug that was said in offhand)

I think that blocking 3rd party cookie is __MEANINGLESS__ for protection user from tracking. 3rd party cookie model is not the only way to track user. They (government, SNS company, or ad-network) can track user with using other finger print information which is UA strings, IP address, or the timezone his primary access to their contents. If they rely on the beacon IDs embedded in 3rd party cookie to track user, User can control a little it with removing their cookies. But If trackers uses other finger print information I said above, It will be difficult that user control their tracking ID because UA strings, or IP addresses are lower than 3rd cookies from the viewpoint of modifying possibility by users. This is not undoubted future. But it's possible future. In such world, someone may say "All internet user should use Tor for protect their privacy!". It's not make sence! So blocking 3rd party cookies has no meaning for restricting tracking. And maybe it get more difficult world, I think that. 3rd party cookies has an evil factor. Some SNS company or search engine one may track user browsing history via their widget parts. But this root problem is that they uses same domain as their normal services. For internet democracy & freedom of user, I think that "Do Not Track" model is better than changing the policy of 3rd party cookie. Of course, I agree that DNT model is incomplete for tracking protection. However, DNT model respects user decisions. This is important things. Blocking 3rd party cookie model provides only a fake way to protect tracking. The interest matching advertisement which is provided with tracking information has some certain merits for some users. We should keep their merit for their users. I think that It's a regular manner for internet democracy & freedom of user. All users don't want advertisement based on tracking. But also all users don't want blocking tracking for very restriction privacy. The important thing is user decisions. Therefore, I propose that we should implement DNT signal preference per-domain, and backout this policy change.

Depends on bug 598925 (Evercookie) and bug 231852 (ETag tracking).

The cookie expiration I mentioned is now in bug 844623.

Bug 939327 aims at providing the necessary tools for defending effectively against third party tracking by binding third party content to the URL bar domain. Once this lands bug 939354 can get resolved by the various URL bar binding patches (e.g. for DOM storage/cache identifiers) the Tor Browser already deploys plus the ones that still need to get written (e.g. for cookie handling).