Web Policy

Consumers neither expect nor approve of web tracking.¹ Mozilla has been a frequent advocate for its users, advancing technologies that signal preferences (Do Not Track), lend transparency (Collusion), and facilitate privacy-friendly web services (Persona and Social API). Last fall, the Mozilla community began a concerted effort in a new direction: technical countermeasures against tracking.² One of our first projects has been a revision of the Firefox cookie policy.³

Cookie policies are inherently imprecise. Some unwanted tracking cookies might slip through, compromising user privacy (“underblocking”). And some non-tracking cookies might get blocked, breaking the web experience (“overblocking”). The challenge in designing a cookie policy is calibrating the tradeoff between underblocking and overblocking.⁴

The patch that I developed is an intentionally cautious first step: it aims to substantially reduce underblocking with little (if any) overblocking. The revised policy is so cautious, it isn’t even new: it’s drawn directly from Safari.⁵ Almost every iPhone, iPad, and iPod Touch user is already running the revised Firefox cookie policy. Web engineers are already familiar with designing to accomodate the policy. The notion is simple: start by raising Firefox to the present best practice among competing browsers, then iteratively innovate improvements.

Firefox’s revised cookie policy landed in the pre-alpha build in late February. Since then, Mozillans and I have carefully monitored bug reports. It appears that we achieved our aim: there are only two confirmations of inadvertent breakage.⁶ We did not hear any novel concerns when the patch advanced to alpha in early April. This past week, Mozilla’s CTO requested a hold on the revised policy for an extra release cycle to measure its performance. At the same time, he reaffirmed that Mozilla is “committed to user privacy” and “committed to shipping a version of the patch that is ‘on’ by default.”

I agree that we should be quantitatively rigorous in our approach to iterating the Firefox cookie policy. An extra six-week release cycle will allow us to further validate our hypothesis that the patch delivers improved privacy without breakage,⁷ as well as lay the groundwork for future updates. Going forwards, our challenge will be to understand and improve the underblocking and overblocking properties of the Firefox cookie policy.

Underblocking and Overblocking

There are at least three substantial areas of underblocking that we know we need to address with future improvements.

• Old cookies. The revised policy does not limit preexisting tracking cookies. Firefox users who update to the revised policy will not fully benefit until they clear their cookies.
• Temporary visits. Sometimes a user temporarily visits a tracking website, such as after clicking an advertisement (intentionally or inadvertently). The revised policy indefinitely allows tracking cookies from a website after just one temporary visit.
• Dual-use domains. Several popular websites use the same domain for both consumer services and tracking. Yahoo!, for example, operates both its homepage and advertisement tracking from yahoo.com. If a user visits the Yahoo! homepage, the company will be able to track the user across other websites. Google, on the other hand, largely hosts search on google.com but advertising tracking on doubleclick.net. If a user runs a query with Google, they will still be protected against Google ad tracking.

As for overblocking, again, I am not aware of any significant shortcomings with the revised cookie policy.⁸

Next Steps

We have a number of tools at our disposal for improving our understanding of the Firefox cookie policy, including feedback solicitations, user surveys, browser measurements, web crawls, and much more. There are many possible directions for product innovation, including heuristics, machine learning, community reporting, manually-curated lists, mechanisms for confirming user preferences, new user interfaces, new APIs, and new institutions.

I look forward to continuing collaboration with Mozilla and its community on web privacy and security. I’m excited to get the revised cookie policy into users’ hands. And I’m even more excited about building what comes next.

All views, errors, and omissions are solely my own. I do not speak for Mozilla or the Mozilla community.

1. See the survey paper Third-Party Web Tracking: Policy and Technology for background. In the context of this post, “tracking” means the collection of a user’s browsing history by a third-party website.

2. For an overview of Mozilla’s open-source community model, see MozillaWiki » Community and Mozilla.org » Governance. Many members of the Mozilla community have now contributed to the tracking countermeasures effort.

3. Apple and Microsoft have both automatically limited tracking cookies for a decade. There was an effort to block tracking cookies by default in Firefox three years ago, but it was withdrawn under contested circumstances (1, 2, 3, 4).

4. Other considerations could include types of underblocking and overblocking, as well as possible reactions to the policy. Future posts might address these topics, depending on reader interest.

5. In the interest of precision: the revised Firefox cookie policy is slightly more permissive than the Safari policy owing to implementation specifics. Additional details are in an earlier post.

6. The sites are dayonecenter.com (Alexa rank > 1M) and western.org (Alexa rank ≈ 200K).

7. As I understand our release conditions, the patch will move forward unless there’s confirmed breakage, the breakage is so substantial as to outweigh longstanding user demand for privacy, and the breakage cannot be ameliorated through outreach, mitigation measures, or rapid iteration. Under present circumstances, the patch plainly satisfies these release conditions.

8. We may wish to relatedly take steps to accommodate websites (if any) that have a third-party domain, do not compromise consumer privacy, do not break the consumer web experience without cookies, cannot deploy an accommodation for the revised cookie policy, require cookies for functionality, and have lost that functionality on account of the revised policy.