Please don't edit this site, instead go participate in the discussions in our dev-privacy forum.

Block cookies from sites I haven't visited

bug 818340 calls for blocking cookies for all third parties that haven't been a first-party. The idea is that individuals don't quite expect third parties to be able to remember them (or that the third parties exist at all). But in some cases, a third party may be trusted -- like Facebook comments, customized once you've logged into Facebook. So instead of blocking all third-party cookies, what if we block third party cookies for sites that haven't previously set cookies?

This brings up a number of concerns to work through, and we should document them here.

Site-encouraged Abandonment

What if sites start telling Firefox users they don't support the browser (and to use another one)?

• Lucas brought this up, though I'm not aware of any live sites that are currently doing this. We need someone to find a few examples of sites that do this to one of the major browsers due to cookie handling. Personally, I think the best way to test whether this will happen or not is to land the feature in nightly, socialize it, and get some feedback from web devs.

Reported breakage:

• Western Federal Credit Union bill-pay doesn't work
• Redstone Federal Credit Union (broken with full third party blocking; uncertain of the effects with limited blocking: http://www.reddit.com/r/firefox/comments/197jpf/firefox_to_autoblock_thirdparty_ad_cookies_by/c8lk4h4)
• Day One Center reservation system is broken

Arms-Race for Tracking

Won't landing this patch and changing the default accelerate an "arms race" for third-party state storage?

• Yes, this is a risk, so as Brendan pointed out we must also be working on other "peaceful alternatives". This is accelerant. We also need flame retardant. The Tracking Protection Working Group at W3C is proposing a "site-based-exception" API for DNT; perhaps we can do something similar for third-party cookies so sites can ask for them back. We have the plumbing to permit third party cookies per-site, but the UI isn't accessible. I don't intend to stop with this patch.
• What are the use cases this change will break?

Repeating History

We tried things like this before, and they were reversed. Why is this different?

• Double-keying cookies (bug 565965) was a bigger change; it changed the cookie model in a more fundamental way. It's elegant, but try explaining double-keyed cookies to a non-technical person. It's more complicated to understand.
• Previously, we tried to block all third party cookies (not just those for unvisited sites). See {{bug|324397}. This breaks much more than only partially blocking third-party cookies, and I suspect single sign-on is one of those things.

Bake Time and Testing

Will nightly/aurora be enough time to test this out?

• This is standard for features with a full cycle in nightly.
• Monitor and adjust. support.mozilla.org is listening, discussing breakage in dev-privacy, and taking input.
• Might hold it back if we can't measure telemetry, but the current target is 22; gives us 6 weeks on each channel.

King Making

Won't this disadvantage the small guys and give the upper hand to big entities like Google and Facebook who have first-party relationships with users too?

• Sid says: Possibly, but it will also encourage the small players to cooperate with their first parties for cookies. This is what Google does for analytics (stores the cookies in the first party domain and uses JavaScript to transfer the cookie data into their domain). I don't think this cooperation is a bad thing since IMO the first parties have a duty to pick third parties that are in their users' best interest; requiring them to cooperate more closely means they will probably spend more time considering the effect of using those third parties.

EverCookies

What about localStorage and friends?

• Brian brought up the idea that we should fix *all* state tools and cookies in one fell swoop. I think that, while we should get to it

eventually, we should chomp off one bite at first and then consider doing the others next or we risk scope creep and never shipping anything.

Stale Cookies

Won't this be ineffective since most Firefox users already have these third-party cookies in their profile?

Options to mitigate:

• bug 844623 - expire cookies when they've not been updated in a first-party context for some time.
• erase cookies on upgrade
• tag cookies, untag as used, after some time delete tagged cookies (similar to first option)
• wait for users to clear cookies (depends on how often cookies are cleared -- need to measure)

Studies related to users clearing cookies:

• McDonald & Cranor - 53% within a month (survey)
• Need study that measures (not asks)

Projected Effect

How will this affect the web? Do we know how many cookies this will block?

We need to measure a bit and figure out how much effect we expect this to have. First we need to identify questions that need answering. Second, we need to figure out what to measure in a way that will answer them. Finally, we should publish the results!

Questions that need answering (and how to answer them):

1. How many sites will be impacted?
   • Collection proposal
2. What are the cookie-use patterns of sites that will be impacted?
   • Collection proposal
3. What kind of sites will not be able to set cookies?
   • Collection Proposal: use Alexa categorization of top 10000 sites; build two histograms (blocked by category and allowed by category). Buckets can be site categories, and we can count number of cookies blocked/allowed per category to get an idea of what breaks.
4. How often do people clear cookies?
   • Collection Proposal: via telemetry, collect timestamp on oldest set-cookie operation. This should estimate the upper bound of deletion frequency. Problem is, many of these old cookies are updated daily with normal browsing. Maybe we can gut-check it with some measurement of how people have configured their "remember history" settings.

Also see bug 837326

Also, see the telemetry design work on projected effect: here

CORS and JSONP interaction

How will CORS and JSONP implementations fare? Will we block third party cookies in those requests too?

We need to decide if CORS requests using withCredentials (see bug 844622) and JSONP (see bug 848437) are subject to this new limit_third_party policy or not.