Posted on by Brendan Eich

C is for Cookie

Mozilla is engaged in a broad, deep conversation about Internet privacy. We believe in putting users in control of their online experience, and we want a healthy, thriving web ecosystem — we do not see a contradiction. However, sometimes a crucial experiment is required to prove it.

To this end, we are testing a patch from Jonathan Mayer. Jonathan’s patch matches how Safari has worked for years, and does the following:

  • Allows cookies from sites you have already visited.
  • Blocks cookies from sites you have not visited yet.

The idea is that if you have not visited a site (including the one to which you are navigating currently) and it wants to put a cookie on your computer, the site is likely not one you have heard of or have any relationship with. But this is only likely, not always true. Two problems arise:

False positives. For example, say you visit a site named foo.com, which embeds cookie-setting content from a site named foocdn.com. With the patch, Firefox sets cookies from foo.com because you visited it, yet blocks cookies from foocdn.com because you never visited foocdn.com directly, even though there is actually just one company behind both sites.

False negatives. Meanwhile, in the other direction, just because you visit a site once does not mean you are ok with it tracking you all over the Internet on unrelated sites, forever more. Suppose you click on an ad by accident, for example. Or a site you trust directly starts setting third-party cookies you do not want.

Our challenge is to find a way to address these sorts of cases. We are looking for more granularity than deciding automatically and exclusively based upon whether you visit a site or not, although that is often a good place to start the decision process.

We plan to ship an evolution of the patch “on” by default, but we want to make refinements first. To make sure we get this right we need more data. Our next engineering task is to add privacy-preserving code to measure how the patch affects real websites. We will also ask some of our Aurora and Beta users to opt-in to a study with deeper data collection.

There are many conflicting claims about how this patch will affect the Internet. Why debate in theory what we can measure in practice? We are going to find out more and adjust course as needed. This is the essence of the release test cycle.

On Tuesday we did two things:

  1. The patch has progressed to the Beta release channel for Firefox 22, but it is not “on” by default there. This allows more people to test the patch via Firefox’s “preferences” (AKA “options”) user interface, and avoids an abrupt change for site owners while we work on handling the hard cases.
  2. The patch remains in the Aurora channel for Firefox, where it is “on” by default. This gives the patch better ongoing test coverage and facilitates A/B testing.

We have heard important feedback from concerned site owners. We are always committed to user privacy, and remain committed to shipping a version of the patch that is “on” by default. We are mindful that this is an important change; we always knew it would take a little longer than most patches as we put it through its paces.

For those who read this as Mozilla softening our stance on protecting privacy and putting users first, in a word: no. False positives break sites that users intentionally visit. (Fortunately, we haven’t seen too many such problems, but greater testing scale is needed.) False negatives enable tracking where it is not wanted. The patch as-is needs more work.

We look forward to continued dialog with colleagues, contributors, fans, and detractors. We will update all of you within six weeks so you can understand our thinking and how we will proceed. Comments welcome.

/be

P.S. Cookies (name history) were originally intended to be ephemeral (Windows 3.1 had so little usable memory with its 64K memory segments that Netscape’s founders had no choice). At first, they held only session state that could be recovered from the server by logging in again.

(Remind me to tell the story some day of Montulli’s aborted “twinkies” idea from the Netscape 2 era. UPDATE: Lou has published a new blog post about cookies.)

How far we have come in the amazing, living system that is the Web! No one planned for what actually happened, but with more work on the cookie policy in Firefox and (I hope) other browsers, I believe that we can evolve to a better space.

33 Replies to “C is for Cookie”

  1. Hi Brendan,

    is there a way to block linked elements even before they are pre-cached by the browser? I tried it in Safari with the onbeforeload event but when this event fires, Safari already made a HTTP request.

    The basic idea is to write an extension for whatever browser which blocks ALL content which does not have the same origin. This will block all facebook likes, all 1×1 pixel images etc. from 3rd party websites. I know that many users would not like this drastic approach but when I compared with the approach you described above, I WANT to visit face book but I do NOT WANT their ‘like’ buttons and thus their tracking of my web visits.

    I’d appreciate any input

    Thanks

    Pete

  3. There is a third problem in that some people enjoy the status quo and really buy-in to the whole tracking and personalised ads stuff. These people probably appreciate the new DNT setting of “tell websites that I’m happy to be tracked”. They might not appreciate this though.

  5. Is there any work being done to clean up the existing opt-in/opt-out of cookies UI? The setting to “ask me every time” is seriously buried now, under “Use custom settings for history” and then “Keep until”. But it’s still there and despite being very clumsy, does kind of work. The list of per-site rules is incredibly clumsy to navigate, though. There’s no search, and it sorts by the raw domain name so that http://www.example.com and example.com are in completely different places in a very long list. And there’s no way once you’ve chosen to block a cookie to tell which site in that humungous list is the one that’s blocking the site you’re looking at now. Oh, and using a modal-ish dialog to ask what you want to do about cookies is very ’90s…

    I like the idea of having smart defaults… but if you’re going to continue to include the option of making per-site choices, it’d be really nice if the UI for it wasn’t so awful.

    What I’d really like is something like: turn ALL cookies into session cookies, but limit the meaning of “session” so that a session is limited to tabs spawned from the original and considered to expire when for all tabs that were part of the session either (a) the tab is closed, or (b) a new TLD is entered in the url bar by the user. And then use a notification like the “inactive plugins” notification when the site is trying to set cookies that will persist beyond the session, so the user can enable it if they desire.

    The underlying principle here is that if the site had control over what URL the user is going to, they could just put the “cookie” information into the URL, so letting them use a cookie for it is not giving them any power they didn’t already have. Allowing the site to persist the cookie beyond what they could do by throwing it into the querystring is giving sites more power, and users should be able to choose to opt in to that.

  6. @be: Just a heads-up, you link to the mobile version of Wikipedia in “P.S. Cookies (name history)…”.

    Thanks for all the awesome work on JavaScript and freedom and whatnot!

    @Dan: It’s the _default_ behavior that’s changing. If you switch to “Use custom settings for history”, you can still change your 3rd Party Cookie policy to “Always”.

  7. Hi Brendan,

    Right now I use custom settings and have not checked “accept third-party cookies.” I understand this to mean that all third party cookies are blocked. Am I correct?

    Will this functionality continue with the patch that blocks cookies from sites I have not visited?

    Thank you,
    John

  8. Dan: two thoughts: 1) they can change the third-party cookie pref to “never block”; 2) there are ways to personalize with greater privacy, and we’re working on them.

    Stuart: definitely need UX work. I think Larissa Co (https://twitter.com/lyco1) is on the case.

    Andy: thanks, fixed. Not sure how I got those en.m.wikipedia.org URLs, I was not editing on a mobile device.

    /be

  9. John: are you running Firefox Nightly/Aurora, Beta, or release? As stated here, Beta and release do not block unvisited cookies, so do not block 3rd party cookies. Beta now has the option jmayer added, it’s just not the default.

    /be

  10. Brendan,

    Right now I am running Firefox v. 20. I use the customize settings and have not checked “accept third party cookies.” Sorry if I am not clear.

    My questions:

    This setting blocks ALL 3rd party cookies, correct?

    My understanding is that the Mayer option — whether on by default or enabled by the user — blocks most 3rd party cookies, but not all. It allows them if the user has visited the site. You are concerned about false positives and false negatives, correct?

    My final question is this: Assuming you deal adequately with the false positive and negative issue and implement the Mayer patch (whether by default or not), will you still give users the additional option to block ALL third party cookies?

    Thanks,
    John

  11. Brendan,

    I am sorry, but could you please answer my questions:

    1. I’m running Firefox v. 20. I don’t have “accept 3rd party cookies” checked, so I am currently blocking ALL third party cookies, correct?

    2. In the future, whether the Mayer patch is on or off by default, it will if enabled block cookies from sites I have not visited. (This assumes the false positive and negative issue is solved.) It would not block all third party cookies. Will I have the option to either block cookies from sites I have not visited OR to block cookies from ALL third party sites.

    Thank you.

  12. What about localstorage? Until bug 536509 is fixed tracking scripts can just use that instead and bypass the mechanism with only minimal changes, in effect making the whole effort null and void.

  13. John: sorry, super-busy — support is not my best job right now, but here are some answers:

    1. Since you do have “Firefox will: Use custom settings for history” selected in order to see that “Accept third-party cookies” checkbox, then yes: if you uncheck, you won’t accept third-party cookies. Just like it says :-|.

    2. Yes, we will always give you the option to never accept, always accept, or selectively (selectively in Aurora now based on “visited” status, and in Release in the future with necessary fixes) accept third-party cookies.

    /be

  14. Ferongr: not null and void, as tracking is currently done using cookies to cover all browsers. Trackers switching to local storage imposes costs on those trackers because they must deal with old browsers that lack LS. They may switch in the future, but we can fix that bug later too. Right now we’re focusing on cookies.

    The point about avoiding an arms race is good, though. This does not just mean blocking everything — there are tons of ways to store tracking state in browsers. It also means policy, self-reg, even (in the EU) some regulatory pressure. And IMHO avoiding an arms race means not breaking the world all at once, then proposing to fix it.

    /be

  15. Why can’t we just complain to that small number of sites that don’t work with third-party cookies and get them fixed and then disable third-party cookies by default ?

    And when complaining to sites we should talk about: how sites needs to be privacy enabled.

    How about it ? 🙂

    Obviously the technical barriers that are possible are limited, this is just raising the bar. Just look at evercookie or cookie-information in GET-requests. So DNT and legislation are needed.

  17. Lennie: first, it’s not a “small number of sites” that don’t work with*out* (you meant) third-party cookies. The number is larger than “small”, and Apple’s docs tell people to enable third party cookies if they hit trouble. I’ve heard a large minority cohort of iOS and Mac OS X users have done just that: enabled third-party cookies from every site.

    Second, your comment seems to ignore the false negative problem. Very powerful first parties already can track you in many ways (e.g., Like buttons); giving them a pass to track you on other sites just because you have a first-party cookie for them just empowers these incumbents more and unbalances the ecosystem further.

    /be

  18. I don’t think foo.com and foocdn.com creates a false positive its just poor implementation of the CDN.

    All cookie setting should happen from *.domain.com period as this is the best way to ensure privacy and PERFORMANCE.

    Now I have to read all these articles claiming Mozilla put their tails between their legs.

    All publishers should look forward to this change because they have content and networks will be reliant on them now instead of the other way. Publishers reliant on networks should know that they are devaluing their inventory and more importantly the audience they worked so hard to build.

    If we care so much about Mozilla making this change then there should be a bigger push at Apple/iOS considering they command a larger percentage of total traffic.

    I value Mozilla for making the right decisions for the user delaying this doesn’t show that.

  19. Brodle: Consider this list: facebook.com, facebook.net, fbcdn.net. Note the different eTLD+1 domain names. Social Widgets, I’m told, depend on third-party cookies.

    This kind of domain architecture is not unique to Facebook.

    See my reply to Lennie about Safari users in significant numbers enabling *all* third-party cookies to overcome breakage.

    We have much more desktop share than Safari does. On mobile, people use an FB app or the “m” site. We’re not going to break desktop Facebook. You want us to survive and even thrive in order to help the web? Then don’t ask us to take bigger product risks than competitors with our share or greater share can stand. If we go out of business, you will be asking Google instead.

    Don’t worry about junk journalism. Keep the faith. We’re working on a better version of the default, selective third-party-cookie block. Using “Visited” is not good enough, for both false positive and false negative reasons.

    /be

  21. Although I am a healthcare professional by trade, I also got a minor in Computer Science back in the day. I like to follow current business that revolves around Tech. I have been using FF as my browser of choice and I applaud Mozilla about being concerned about user privacy.

  22. I work for a company that licenses an order capturing web platforms to various well known retailers and is hosted on our end (ie: other domains). Many of our clients opt to embed our platform into their web sites using an iFrame as it makes it much easier for them to control the appearance of the site.

    We’re using session cookies to keep track of the user’s transaction, and nobody would fault someone for doing that as it’s the norm for transaction oriented sites.

    This, and the recent similar Safari change, has brought a bit of headache to us as there are very few options to resolve. Some of the solutions feel more like hacks that, if this movement to block third party cookies becomes the norm, will also be patched over in the future. As it stands, we’ll probably have to coordinate changes with our clients at not an insignificant expense to address this – hopefully for the long term.

    As a “trusted third party” providing features to our clients, and I’m glad to see Mozilla is taking the efforts to try and correctly implement this rather than fire-bomb a solution as Apple did with Safari. It would also be nice if Mozilla used it weight in the browser market to provide guidance to developers and the W3C on a long-term solution that closed the privacy loophole but allowed for trusted sites to function correctly.

  23. Brendan, while I’m entirely in favour of this move, I think it would be a good idea to more prominently promote the concept of “permanent” cookies vs. forcing cookies to act as session cookies.

    Currently, it’s possible in Firefox to retain cookies “Until I close Firefox” – essentially forcing all cookies to be lost when the browser is closed, unless the sites are added to the list of “Exceptions”.

    This confers a few benefits:
    – It’s more difficult to track browsing habits, as most cookies are lost at the end of the session
    – Less unwanted cookies cluttering up Firefox beyond the browsing session
    – Easily tracked opt-in for staying logged in to certain websites
    – Nothing ever breaks (as far as I can tell) as all cookies get set as expected

  24. As a person that works in help desk support for a large educational organization, this change, once enacted, will likely cause a huge support issue. Many colleges use Blackboard as their main “course” software. Blackboard has a lot of plug-ins that are, in effect, third-parties, such as SafeAssign, which allows students to upload their papers to be analyzed for plagiarism.

    If third-party cookies are blocked, plug-ins such as SafeAssign do not function until the setting is changed. These plug-ins are often used school-wide, so this means that students, the majority of which we’ve been pushing towards Firefox, as it is most compatible with Blackboard, will have their experience broken.

    We have students that insist on using Safari, and we have to instruct them to enable third-party cookies in Safari, or use a different browser. It’s a quick enough fix, but I can see it becoming a huge issue when a large number of users have their experience break in Firefox, which many of them have come to trust as the “one that works”.

    I’m not saying I disagree with this change at some point, because from a security perspective, I actually like the idea. But while the idea of third-party cookies being blocked by default is great on paper, it can be troublesome in practice due to the way the web often works.

  25. As software developers, we produced a tool for website owners to offer visitors the ability to signal a wish to allow/block different types of cookies, based on a categorisation of purpose.

    https://www.cookielaw.org/

    This was design to help site owners comply with the so-called EU cookie laws. Site owners can then code their sites to respond to the wishes. Its essentially a finer grained approach to a DNT preference expression.

    However, if the browser could take care of the blocking aspects, it would be easier for site owners, and better for visitors.

    You could then see a shift towards declaring cookie purpose in page meta-tags, read and acted on by the browser according to user preferences, possibly with the browser also indicating what actions it is taking to enable the fine tuning of the preference.

    A move towards standardisation by W3C would naturally follow.

    This approach also stops big advertising trackers simply moving into first party cookies to avoid third party blocking.

    Is this something Mozilla might consider exploring?

  26. I’m sorry but that patch is bullshit and Safari’s behaviour is too. Define “visited” if we are talking about a page navigation then fair enough but I doubt that’s the case. If by “visited” you mean a url has been accessed then this makes 3rd party cookies work for the big players because we have all “visited” their sites.

    Blocking 3rd party cookies is just that there is no in-between to protect privacy. Having these half measures do not protect privacy and in fact are even worse because the user assumes their privacy is protected which is not the case at all.

  27. Brendan, is there any proposal to allow sites to whitelist domains for these cookie purposes? Something like (or its HTTP header equivalent, obviously).

    That way, this trust would be more explicit and you could even rank sites according to who they trust (e.g. if they cookie-trust a known spammer or something like that). We would need to extend SpamHaus or something like that (a Public-Suffix-List–like inititative?) to rank them though.

    Then the user may choose:

    * to happily cookie-trust everyone (that would be the current behavior),
    * trust noone (just what Jonathan’s patch does) or
    * just trust the white-lists (I think this could be the default)

    and if a site trusts someone shady show the scary red page telling the user this is a bad site or at least an icon in the URL bar.

    Would be a nice way to pressure advertisers into keeping themselves honest…

    — nachokb

  28. Your concern about user privacy is blown out of proportion. A tracking cookie just isn’t that big a deal. I’m a webmaster. I can sell targeted ads. Untargeted ads are almost worthless. Now you are proposing to make all Firefox users nearly revenue worthless by default. That is heavy handed beyond the pale.

    You guys at Mozilla are gonna protect the public right out the the webs they enjoy. I only get a nickel or a dime for your visit, but I need the dime to keep the lights on.

    Let’s bash those bad, old ad companies right out of business and take 90% of the webs people devour down with them.

    Your politics don’t belong in a web browser.

  29. There is another use case that need to be considered:
    Using 3rd Party Cookies (in iFrames) to achieve SSO between company.com and company.co.uk. Like: you have the shop running under a country DNS name (company.co.uk) and global services under company.com. Under company.com you have also you SSO system. If you connect the login page of the company.com inside an iframe of company.co.uk you will have no SSO more working between the sites. So there is the need also of a rule stating to allow cookies for *.company.* domains (limiting the second * to one level) cookies. Similar use case as CDN but easier to implement.

  30. where I said “Something like” I wrote:

    >meta https-equiv=’cookie-trust’ content=’foocdn.com,foocdn2.com’ /<

    I mean a ‘cookie-trust’ meta https-equiv with values ‘foocdn.com,foocdn2.com’

  32. In Facebook apps (and a lot of other gaming websites), every game is a third party because they’re in an iframe. Instead of whitelisting all the third parties, it would be nice to be able to whitelist first-party domains where third-party cookies are allowed, without whitelisting that domain when it is a third party.

    For example, I would allow any third-party cookies to be set while the parent domain is facebook.com (so all my Facebook apps would still work), but I wouldn’t allow facebook.com to set cookies as a third party on others sites (so they couldn’t track me every time I visit a site with a like button).

Comments are closed.