Firefox rolls out Total Cookie Protection by default to all users | Hacker News Reader

Firefox rolls out Total Cookie Protection by default to all users

blog.mozilla.org

877 pointsBoumTAC322 comments

Why weren't separate cookie jars the default in the first place? I know that browsers other than Firefox have no real incentive to protect your privacy, but I'm wondering why cookies were designed to be shared among different pages in general

Cookies were invented at Netscape like 25 years ago, nobody considered the current situation.

Yes they did. It was foreseen, look at the sibling comment where the issue was discussed in the spec. They just punted, just like they did with https and CAs. (And Javascript, for that matter, although that's less directly security-related.)

The concern was being first to market, not with solid engineering.

There are legit cross-domain use cases. A good example is how someone here mentioned (comment seems deleted though) account sessions being shared between Atlassian products like JIRA and BitBucket.

The problem with that is domains are a poor way of representing ownership that can be trusted. If the web was rebuilt from scratch, a better approach might be to allow cookies to be shared between secure sites using the same certificate. But that adds more complexity that I'm not sure is worthwhile. The web can absolutely get away with not having shared cookies.

There are also legit use cases for leaving all your doors unlocked. But they usually aren't really worth considering when you are installing your doors/locks.

> allow cookies to be shared between secure sites using the same certificate

Or maybe encrypting cookies using the site certificate, which would still allow cookies to be shared with domains having a different certificate, but the server needs the correct key for decryption.

Ciphertext leaks information via its size and its presence / absence.

yeah and so? how is this information useful? if the actual useful information is encrypted, then size is meaningless as it is just random text until decrypted. presence/absence? you have a cookie or you don't?

You say the size is meaningless. But sometimes it may actually be meaningful. And presence/absence is information also. Not much, but it definitely exists.

In what way? If I'm storing 255 bytes of username/email/credentials/settings/etc, but pad in some fun way to 512 bytes prior to encryption, what in the world does knowing that the cookie is 512 bytes do you? You have no idea what data is stored. You don't know if there are 512 bytes of actual data, 128 bytes with lots of fluff, or anything at all other than 512 bytes. Hell, it could be 0 bytes of data and 512 bytes of random data that I submit to every single person that visits the site just to fuck with people like you! You seem like you need something to do ;-)

If the contents of the cookie is a JSON array of recently viewed items, then the size is correlated to whether I've been actively viewing items recently.

Adding random padding makes it harder to get a signal, but with a high enough sample size, it's still possible to get some information. If you always pad to a fixed size, then there's probably no useful information.

At the moment, I think I have enough to do, but I'll probably be looking for something new in the next few weeks. Got any novel single player video game recommendations?

>If

That's are really big word in that sentence. You have NO idea, like 0, what is stored in an encrypted cookie. To even think you do is just pure folly.

I do have ideas. I can strengthen them by reverse-engineering the behavior using my own account. I participate in follies regularly, so that's not a strong disincentive for me.

This is a very simplistic way of looking at things. A lot of the times in security, having an idea of what's not in there can be almost as valuable as having an idea of what's in there.

I will provide a very simple counterpoint to your argument: say I log in, log out and log in again, dumping my two encrypted session cookies in between. If they are perfectly identical, then knowing nothing else about the environment nor the encryption used, I already know that there's no timestamp value in the cookie acting as a time barrier, nor a challenge-response check, nor a nonce value.

Knowing that, I can focus my attention on stealing session cookies from users for trying replay attacks.

Sounds like it'll make key rotation tricky.

Also it'll likely break javascript access to the cookies.

There’s no technical reason why this has to be hard. If jira was at jira.atlassian.com and bitbucket was bitbucket.atlassian.com, they would have the same origin, plus they would make the relationship between them visible to any moderately savvy user. It’s only complicated because they allow their marketing dept to make it complicated.

You do realize acquisitions occur?

you do realize reorganization occur after acquisitions?

So use a 301 redirect.

Business operation complications are not a valid reason for the violation of the rights of humans.

Cross-domain cookies are a tool that can be used for good or bad. It's a tradeoff to block them or not block them.

I think that’s unfair. By tying things to domains that way, you also make it potentially difficult to change URL structure (look at how long the various go.com domains lasted across all Disney/ABC properties. I know of teams that had very real problems years later b/c the infra was still based on domain stuff that was setup 15 years prior when the parent company thought internet portals were worth spending billions on), not to mention if you want to spin-off or sell an asset. Or if you acquire an asset!

To say nothing of SSOs, where you might not want to carry your login across, but you’d like to have the option of saying “yes, I’d like to use this account here too” and then authenticate.

Also if you sign into Google, notice you bounce through YouTube for what I assume to be similar reasons

Isn't this solved with a login redirect? Just return a signed ID and set up cookies on the other end with that. Granted, it's one more redirect per domain than before per login period, but that's hardly onerous.

Domains that want to collaborate together can still do so.

> allow cookies to be shared between secure sites using the same certificate

In some ways that will be less strict than Firefox's implementation. A CDN might have a certificate with hundreds of unrelated sites in it.

In some ways that will be more strict than Firefox's implementation. A site might want to serve large static files on static.foo.com but a secure login page on login.foo.com , and want to hand over the private key for static.foo.com to a CDN but not hand over the private key for login.foo.com .

While I'm not a friend of tracking via cookies nor tracking in general there is some utility there. For example SSO may be done over cookies, like oauth iirc. I don't know of many other use cases though that couldn't be contained with header etc.

RFC2109, from 1997, had this:

8.3 Unexpected Cookie Sharing

A user agent should make every attempt to prevent the sharing of session information between hosts that are in different domains. Embedded or inlined objects may cause particularly severe privacy problems if they can be used to share cookies between disparate hosts. For example, a malicious server could embed cookie information for host a.com in a URI for a CGI on host b.com. User agent implementors are strongly encouraged to prevent this sort of exchange whenever possible.

It's really weird that they claim there privacy work started in 2015. Netscape Navigator add cross site cookie blocking at some point, and firefox has always (?) had it.

The innovation here seems to be that they further partition by the URL in the address bar.

It's frustrating that browsers have been fighting and losing this war for 25 years. (Presumably they still don't block browser fingerprinting, so sites will just move to that instead...)

It's not possible to block browser fingerprinting since it's a range of techniques and heuristics based on numerous features. There's no "turn off fingerprinting" button you can just press.

Whonix says hello. https://www.whonix.org/

I was planning to use it exclusively when I was working on a system to fight cartels, so I got pretty deep into these kinds of questions. Whonix has its own problems but it's the best solution available.

The communities are interesting too. One fellow was trying to download map data, which confused me initially. Why was he so fixated on maps? It's because if you're in the middle of a warzone, there's obviously no cell service, and it might be a few weeks before you reach an area with wifi. Remarkably prescient given that this was 2013 or so.

But you're right in general that there's no way to do it that isn't a pain in the ass for most people. "I can't resize my browser window? Really?"

I'm sure that the techniques used in Whonix can reduce the number of valuable features used in fingerprinting but you can't "solve" fingerprinting without every single user switching over to something like this.

It is possible to enable obstacles to fingerprinting.

In Firefox, it is configuration entry

  privacy.resistFingerprinting

Some details (the list is not exhaustive):

> * Your timezone is reported to be UTC; * Not all fonts installed on your computer are available to webpages; * The browser window prefers to be set to a specific size; * Your browser reports a specific, common version number and operating system; * Your keyboard layout and language is disguised; * Your webcam and microphone capabilities are disguised; * The Media Statistics Web API reports misleading information; * Any Site-Specific Zoom settings are not applied; * The WebSpeech, Gamepad, Sensors, and Performance Web APIs are disabled, etc.

I’ve got this enabled - the only one that’s been more than a mild pain in the ass is the UTC timezone change. Always takes a minute to remember why a site is telling me my appointment is at 2:30 in the morning.

Is there a way to reset the timezone but have all the other protections? Timezone provides pretty low information relative to the pain it causes me when I show up to my meeting 5 hours later.

I have tried and tried to override this on a site-by-site basis

I tried setting:

privacy.resistFingerprinting.exemptedDomains to the domain

privacy.resistFingerprinting.testGranularityMask -> 4

I still get utc in slack

Just move to London

UK has daylight savings time. Better move to Iceland instead. They're always on UTC.

It's certainly possible to curtail fingerprinting.

Why is my browser reporting my resolution to the server? Why can't you just serve me HTML and let me render it how I damn well please?

Sounds like a really unique, fingerprintable way to browse.

> Why is my browser reporting my resolution to the server

The browser doesn’t need to report anything by default. You can get a reasonable estimate with CSS + JavaScript (e.g. using media queries to modify some observable properties on the basis of the screen width and then report what those properties are via a call to fetch)

It's not binary but it's unfair to say "it can't be done" it absolute can be made significantly better.

The strongest fingerprinting techniques use a lot of computing (e.g. font, canvas analysis) so they are expensive to use - no one wants to slow down their visitors by several seconds. The weaker fingerprint techniques can be easily patched and mocked it's just that it's a constant effort to keep up with them.

All it would take is 1 major browser to enable it by default to distrubt whole fingerprinting ecosystem to the point where it would be too expensive to effectively fingerprint people.

Internet explorer used to ask the user before saving cookies.

And the server had to declare what cookies would be used for in machine readable form (P3P) which the browser used to decide if it want to allow the cookie (google blatantly lied)

And more recently DNT.

A graveyard of failed attempts at improving privacy

FIrefox used to ask, then it would ask if you set the right preference, and then it stopped asking entirely. I was very disappointed in them.

Why was it disappointing in them? Don't they need to compete with Chrome and Safari's UX, that just allow those cookies?

That's no reason to remove the preference that allowed people to re-enable the dialog box.

Cookies first appeared in Netscape on Oct 13, 1994 [1]. In 1994 the 'web' was a very different place and the current environment of web tracking and invasive advertising companies simply did not exist. And no one saw the privacy invading potential at the time.

[1] https://en.wikipedia.org/wiki/Browser_cookie#History

Yes, but someone here quoted an RFC showing that while people may not have understood this in 1994 they did in 1997. And now 25 years later the privacy issue was fixed.

> And no one saw the privacy invading potential at the time.

Maybe not the privacy invasion potential but ... As we got started building amzn in the fall of 94, it was a no-brainer decision to not use cookies even though they were just arriving. The controversy around the idea was intense and it was far from clear that they would be a success as a technology. It is likely true that there was more attention being paid to the "what? it lets a remote server create a file on my driver?" angle than the privacy one.

How did you manage session information without using cookies?

   http://yourdomain.com/path/to/something?SESSION=af2828c119ae1

and yes, all URLs in every page were rewritten during page generation to include the session ID.

Didn't that break bookmarks?

This was 1994. Web technology was barely even emergent.

Sometimes, but usually not. What it did enable was people accidentally leaking their sessions when sharing links.

What did the company do then? (When their users started accidentally leaking session IDs)

(Hmm but you're a different person :-))

The web was designed to be highly interconnected. Deep linking is a feature. Cookies are set via headers. If you load an image from another domain, the headers from that domain could set their own cookies, and your browser will give each domain every cookie it has set.

That is, cookies aren't shared, they're locked down to the domain that set them. It's just that some domains have content loaded by millions of pages. This change won't protect you much if you have a relatively stable IP address without many users on it, because your IP is still in the third party domains logs. This welcome change makes it harder to differentiate people on the same IP, or to track a browser as it changes IPs.

As I'm typing this, I'm remembering how helpful IPv6 is for people who want to track everyone.

If you need Onion Routing then you need Onion Routing. IPv6 Privacy Addressing gives you roughly the same properties you had with IPv4 NAT except now when you did want a stable address you've got one.

Multi address is much healthier in IPv6, so it's reasonable for your browser to even spin up an address associated with a Porn tab, and then destroy it again when you close that tab, while still using your other IPv6 address for a post you make meanwhile to Hacker News. It's also reasonable (while it was often likely to cause mysterious problems in IPv4) to give your local web server a long-lived IPv6 address while your web browser's address changes every hour.

Hmm... I think IPv6 might be actually better. Apple for example will generate and use a temporary IPv6 which changes every few hours to protect your privacy.

Can't one look at the first parts of an IPv6 and roughly know anyway who it is? I've read that one can only control the last parts of ones IPv6 space -- the first, one gets from ones ISP?, can they be enough to know who one is?

> Why weren’t separate cookie jars the default in the first place?

Tracking today is an interaction between cookies and pages, not really because cookies were designed to be shared between domains. Because of that, ads on web pages are a reason that information gets shared across sites. Any ad or other iFramed content that’s served on a site can get the domain name of where it’s be served from and then access the iFrame domain’s cookies, which enables tracking.

The cookie jar language might be a tiny bit oversimplifying/confusing in the sense that cookies are already separated from each other according to the cookie’s domain - they’re already in separate jars in a way, and this feature is changing how they partition the jars. Assuming even the most strict privacy settings, tracking cookies and scripts are often in iFrames and may not have the ability to directly read other cookies from the web site in your URL bar, and the web site might not be able read the tracking cookies. It’s not that cookies themselves are being shared per se. It’s that (say) Facebook is allowed to put an iFramed tracker on some site, and Facebook can then get a tracking blip when you visit that site and add it to a Facebook-only cookie. Total Cookie Protection is going to put cookies that only Facebook can see in a different jar for each separate site you visit, making it so that Facebook can’t read it’s own cookies across different sites.

The solution still seems to be to:

1. Use Firefox, block .js by default, and selectively allow.

2. Set browser to block cross-site cookies, and to purge all cookies when closing browser.

3. Avoid tabbed browsing, and restart browser after using a website.

I've been doing this since about 2006. It's inconvenient, but gives some peace of mind.

That’d certainly prevent most tracking, yeah. This new Firefox feature should make #2 and #3 unnecessary.

I think this feature by Firefox is great, and privacy options are getting objectively better, if slowly. But the cynic in me guessing that server side tracking methods are going to start getting secretly better, if they haven’t already.

I'm not sure about #3. there's still sessions, localstorage, indexDB, etc

I didn't mention #4 of also purging all that other stuff when the browser closes.

Honestly, try it with me - it's not so bad. 1, 2, 3, everybody now!

I don't really need to. With the extensions I use, every new tab I open is like a private windows, it has its own isolated environment.

And I can still keep sessions opened where I really need to

The solution is political action. You're describing a workaround that only a few of the most concerned people will be willing to use.

Agreed, the solution is to work with others toward a solution.

In my defense, I don't see it as a workaround - I wouldn't use it any other way.

There was a time when one didn't need to do this, but the internet has become more cumbersome to use. Easy-breezy... just make it muscle memory, and don't look back!

I'd replace 3 with self-destructing cookies.

To reduce the burden use extension Temporary containers, so each tab opens into a clean environment.

And use Firefox container to auto-open domains on specific containers where you want to keep sessions or have a shared profile among various domains

2 and 3 are "browse in private mode", to make thing simple.

How about just using the "Delete Cookies" -feature of the browser? And maybe there's a plugin that would make that one-click process?

I just by default use private mode. Pretty sure in Safari that helps.

> Total Cookie Protection is going to put cookies that only Facebook can see in a different jar for each separate site you visit, making it so that Facebook can’t read it’s own cookies across different sites.

Won't this break some basic features like being logged in to Facebook (or similar services, e.g. Disqus) for the purpose of embedded comment sections on other sites? They don't use cookies only for tracking buttons after all. It would be… annoying… for every site to require a separate login.

Yes, it might break embedded features like comments unless you whitelist the allowed uses. I would assume Firefox handles this thoughtfully, but I haven’t tried the new cookie jars yet, so I don’t know what the UI looks like or allows.

Elsewhere they mentioned that there are exceptions for "popular" SSO systems, but I have a hard time imagining any exception that would allow a shared login for Facebook comments while blocking Facebook tracking across sites. These are essentially the same mechanism.

Why can't the browser can handle the login?

They tried https://en.m.wikipedia.org/wiki/Mozilla_Persona

Yes. Hope so. What a bad idea that is.

They handle it gracefully. As per their write-up[1]:

> In addition, Total Cookie Protection makes a limited exception for cross-site cookies when they are needed for non-tracking purposes, such as those used by popular third-party login providers. Only when Total Cookie Protection detects that you intend to use a provider, will it give that provider permission to use a cross-site cookie specifically for the site you’re currently visiting. Such momentary exceptions allow for strong privacy protection without affecting your browsing experience.

[1] https://blog.mozilla.org/security/2021/02/23/total-cookie-pr...

The site owners place the Facebook crap on their site...therefore enabling Facebook to track you across any and all sites that embed the tracker. Facebook and other tracking companies are so ubiquitous (most sites have multiple trackers) that they end up getting a feed of Sally's activity across the web...via the cookie loophole.

Cookies need restricted to the URL in the address bar. Anything else is like a side effect or unintended and woefully non-transparent consequence of sneaky fucks harvesting your information (clicks, keystrokes, and metadata) via JavaScript and cookies.

the web was directly bolted on top of the classic client-server network model. there was no concept of a website, just a bunch of requests needed to render whatever the markup (and the dynamic scripting stuff) wanted.

the interaction of those is completely left as an exercise to the (standards) readers. initially only remote code execution was a problem (eg. cross-site scripting), then the usual cross-site request forgery problems. and sure, there was all the usual gimmicks with list of sites you probably visited because it was possible to fingerprint by CSS plus exploiting cache timings.

initially framesets were all the jazz. you got free hosting and the provider just put your stuff inside a FRAME and the ad went above in a different frame.

serious sites had money to pay for hosting and SSL certs. and even if someone stole some credit card numbers the solution was easy, just use paypal!

privacy was seen as something to think about only when someone asked you a/s/l (age, sex, location), so basically when interacting with other humans in chat rooms (or on forums).

...

of course slowly but surely software (more exactly the Internet) is eating the world. being online is the default. Alphabet, the 8th on the Fortune 500 list doesn't even have brick and mortar stores (oh well, there's one in NYC and during this year's Google I/O they announced the second, also in NYC).

Why didn’t cars have safety belts in the first place?

The cookie jar was already partitioned by domain. It's non-obvious that the correct design is to partition it by 2 domains (the domain in the HTTP request and the domain in the URL bar).

Does this obviate the need for [Facebook Container](https://addons.mozilla.org/en-US/firefox/addon/facebook-cont...)?

Facebook Container is a stricter form of protection for Facebook specifically, so no, you should continue using it if you're interested in isolating Facebook.

Total Cookie Protection is about isolating third party cookies/web storage, without breaking as much of the web as simply blocking third party cookies does.

What kind of protection does Facebook Container have other than deleting cookies outside of the container?

For my case Total Cookie Protection is enough, but if you want the same protection of Facebook Container for every website (i.e. session cookies which are deleted each time you restart the browser) you can install Cookie AutoDelete or use the built-in option to delete cookies at restart (whitelisting websites where you need permanent cookies).

It also blocks network requests made by third-party sites to FB. So unless you're already running ETP with the content blocker on (strict mode, private browsing mode) or another ad blocker kind of addon that also blocks FB strictly, then that's an additional measure.

In which way is Facebook Container "stricter"? Are you aware of any potential third-party tracking vectors that Firefox does not currently mitigate, but Facebook Container does? The only possible difference I can see is that Facebook Container keeps sites "shared" via Facebook inside of the Facebook Container, so if you navigate from e.g. Facebook -> CNN, facebook can only see the history of CNN pages you've visited inside of the Facebook container. Otherwise, clicking on a share link from Facebook (with, e.g., a unique query parameter) would allow Facebook to correlate their CNN.com facebook cookie with their Facebook.com cookie, getting (retroactive) access to all of your CNN history. So maybe that's one reason to continue to use Facebook Container

Yeah, its not really stricter but its different / complementary. Together Facebook Container and Total Cookie will stop more cookies.

I'm not sure if it offers any stricter cookie-specific behavior, but it also blocks network requests Facebook makes on third party pages. So unless you're running in ETP strict/custom mode with the content blocker on, or in private browsing, or maybe an ad blocker that also blocks FB in general, that's probably worth noting.

You asked what I was wondering except I was thinking of the [Multi-Account Containers](https://addons.mozilla.org/en-US/firefox/addon/multi-account...)

I think Cookie Protection does solve the problem that I used the containers for. I wasn't really using it to keep accounts separate, per se, but more to keep companies like Google from snooping and sneaking peeks at my other cookies.

I wonder if there's anyone from any advertising/ad-targeting companies on HN who can shed some light on if/how much this change may affect their "product".

Asking this since I know friends working at companies that were DRASTICALLY affected by the Apple advertising changes in terms of user targetability (and hence revenue) and I'm wondering if this change will be similar.

Firefox has a sub 8% market share, so I doubt this will make a drastic change to how they operate.

Surprised it's even that high, I tried to switch to Firefox the other month for privacy but gave up because it crashed on me it-least once a day.

Edit: thanks for the downvotes, I would have preferred if it worked but it didn't. I tried basic troubleshooting, disabling extensions etc. but didn't find it usable on macOs Monterey, think it doesn't play well with youtube.

Strange...it's been rock solid for me for years, across multiple devices and OS's. I cannot remember the last time FF crashed.

I have used Firefox for 7 years and never had it crash once.

I used it for a similar time if not longer and I think it crashed < 10 times. In the last years it was mostly just single tabs failing and probably was just another website with some endless js loop anyway.

Extremely stable compared to almost any other software. Perhaps the parent means the mobile version. If not I would expect something is wrong with the system, even if visiting the worst pages of the internet.

Not even Firefox Android crashes for me.

I have also used Firefox for a similar time and although I can't say it has never crashed for me, it has at least proven to be a bit more stable than my experience with Chrome.

I don't think I've ever used another browser for as long as Firefox has existed. I think I can count crashes on one hand.

I switched to ff a month or two ago for the integrated tree-style tabs extension that you can't get on chromium-based browsers

I didn't really have any huge problem with firefox specifically, but Brave just feels a bit slicker, the adblocker is in-built and stronger, and it manages multiple windows better, so I've slowly switched back to brave for general use, and use ff for work and projects

care to share what sites were causing your "crashing"?

no? then hello downvote for just making unsubstantiated claims that goes totally against the grain of typical experience.

Been using firefox for multiple years now with no crashing issues, pretty much ever.

Probably you were downvoted because your comment took the thread on a generic tangent - indeed into one of the most-trodden areas on HN. Generic tangents are easy to fall into (of course) but make threads less interesting, which is why the site guidelines ask people to avoid them. https://news.ycombinator.com/newsguidelines.html

Unpredictable/whimsical/curious tangents are still ok. Just not the predictable ones.

More explanations here if anyone wants them:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Not in an ad targeting company, but given Firefox current marketshare and their previous anti tracking measures, I doubt this will make a that much of a difference. But if the feature attracts loads of Chrome users then at least the ad companies relying on third-party cookies will feel it. Obviously if you are currently targeting Firefox users and your company is not in the current tracker list then I assume you will see significant drop

Cookies are the easiest way to shore and share information but far from the only way. If it affects someone's product, it is not hard to fingerprint browsers.

It does seem relatively more difficult to fingerprint Safari on iOS which at least takes a sizeable % of web browsing out of the equation.

I work in advertising. this change is nothing compared to what Apple did. Edit : It's better than ETP.

Better? For who? The trackers? Or the trackees?

Most ad agencies don't know anything about targeting. It's something in the platform they have, but they don't know how it works and if it works at all. Had worked on both sides, providing ads and using them in pages. Would be much easier if the default becomes context sensitive ads. Showing an ad next to some news - give the platform some keywords and pick an ad based on that. No tracking or user targeting needed at all.

Is this better or worse than Safari's "Prevent cross-site tracking" feature?

https://support.apple.com/guide/safari/prevent-cross-site-tr...

It appears Safari is just blocking the cookies, while Firefox is isolating the cookies. I guess Safari has to keep track of who to block while Firefox just isolates everybody. Are there other benefits to the Firefox approach?

Frankly, I have a hard time understanding why this Cookie Sandbox approach wasn't implemented a long time ago. I get that 25 years ago we weren't concerned about privacy, but there has been plenty of time to fix this. Advertiser influence?

Sites that use cross site resource will still work. Except the cross domain resource provider will always see the same domain coming to get resource.

For example, if you are on Site A and use cross site resource from Site C. The site C will get a cookie C('A)

And in another day, you visited a Site B that also use resource from Site C. The site C get a cookie C('B).

And C('A) != C('B)

Although these cookie are both issued by Site C. They are associated to different first party domain and can't be connected directly.

It's just like you open a private browser session for every site you visit.

I think it is a extension usage from Firefox's container technology.

Thanks. In case anyone is interested, I looked around a bit more and found these descriptions of Safari's (Webkit) intelligent tracking prevention starting from 2017 (in reverse chronological order):

Safari Tracking Prevention background:

https://webkit.org/tracking-prevention/#intelligent-tracking...

Blog posts about tracking prevention updates:

https://webkit.org/blog/11545/updates-to-the-storage-access-...

https://webkit.org/blog/10218/full-third-party-cookie-blocki...

https://webkit.org/blog/9521/intelligent-tracking-prevention...

https://webkit.org/blog/8613/intelligent-tracking-prevention...

https://webkit.org/blog/8311/intelligent-tracking-prevention...

https://webkit.org/blog/8142/intelligent-tracking-prevention...

https://webkit.org/blog/7675/intelligent-tracking-prevention...

Here is their tracking prevention policy definition:

https://webkit.org/tracking-prevention-policy/

I believe this is part of the "Prevent cross-site tracking" feature. I do know that Webkit/Safari has had this feature for a while now, under the name "Partitioned storage." Safari has a handful of other policies under the "Intelligent Tracking Prevention" banner, like blocked or ephemeral cookies for non-first-party domains.

Firefox is playing catch-up with this feature. The announcement says "...making Firefox the most private and secure major browser available across Windows and Mac." Note the part that I've emphasized.

3 hours later it says "... across Windows, Mac and Linux."

There has been first party isolation from Tor Browser in Firefox for a while.

https://addons.mozilla.org/en-US/firefox/addon/first-party-i...

That addon has links with info and just twiddles an about:config setting. It can break things (for example some ways Paypal is used by websites, although other ways work fine). There has also been the ability to block third party cookies for a very long time, possibly as long as there have been cookies, but it can also break things. As I understand it Total Cookie Protection is similar to these but with some exceptions so that not much breaks that users would notice.

It would be nice to allow users to create "trusted tuples" to list small groups of domains that are allowed to share their cookies. For instance: Zendesk, Asana, Jira, etc.

But have each tuple listed still be isolated from the other, only domains listed together in a single list could share a cookie container.

Probably that is the use-case for the official multi-account containers plugin.

I tend to agree, but as someone who uses this plugin a LOT, I have some complaints.

If I decide I want, say, an Azure Portal container then I cannot have login.microsoftonline.com assigned to a different container -and- configured to automatically open in that container.

If I do that, I need to have a combined Azure + Office 365 + anything-I-need-to-authenticate-to-Azure-AD-for container.

It’s a good solution but with its lack of flexibility I find it’s too far in the direction of security versus convenience.

I use multi-account containers too, and I like it. This is exactly my point, instead of mapping each domain into a single container, any domain could exist in one or more "trusted tuples"

Maybe another way to think of it is like a one-to-many join. A domain would not "belong" to a single container, but have tags to associate with 1+ containers.

...as opposed to 'nested tuplets'? /fz

> small groups of domains that are allowed to share their cookies

Could you explain how this could be beneficial to the user?

for non-dark pattern use cases where it is beneficial from a usability standpoint to share cookies across domains

Well, what are those use-cases? That is what I asked.

SSO across multi-domain, Github logins, using Youtube.com and Gmail.com with the same G account. Assuming this is done the same way as existing Multi-containers feature

Yes, I think there are some cases where a user might want to opt-in and allow cookies to be shared across a specific set of domains. The main reason I could think of it to allow cross-site business integration to continue to work as (currently) designed.

Little bit of an aside, but what's the use-case for Asana here?

Very cool to see more privacy by default in Firefox.

It is still a lot of effort to have clear separations in every browsern...

I am using Firefox containers with the temporary containers plugins (with history deletion enabled) as well as cookies auto delete plugin (which supports containers).

Therefore, everything is usually isolated in a container inside a tab and only white listed cookies are kept in the named containers.

I've never understood the thinking that went behind allowing one site to see the existence of another site's cookie in the first place. I don't think I'm even coming at this with the security hindsight of decades, it's just common sense, isn't it?

A site isn't allowed to see another site's cookies, common sense doesn't fail you.

No, but I said see the _existence_ of. Or am I wrong there? Ha, I should really know this :P

I'm not a front end guy, but AFAIK no, even the existence of. Apart from various hacks, of course.

It's not that one site is seeing another site.

It's that multiple sites will serve content (ads, Javascript libraries, like buttons) from a common site (eg an ad network) that uses its own domain. That domain is allowed to get the cookie for itself because it is referenced by multiple site, that's how this type of tracking works.

If you go to bbc.com, it still won't be able to see cookies from cnn.com, but say if advert.com is included by both sites, then it will see that you visited them both. That's the power and great danger that things like facebook and google sense represent.

The owner of the sites get some stats for free by using these services, but the biggest benefit is for google and facebook to be able to track what users are looking at accross the web. And you just need to be identifiable on one site that you visit (say, FB or gmail) for them to know exactly who you are.

From what I understand, Firefox will only allow advert.com to get the cookie it created when being loaded as part of bbc.com, but it won't be able to read its own cookie from cnn.com, it will have to create a new, separate one, thus breaking the link tracking you between sites, or at least making it harder to connect the dots.

Everyone should use FF.

> Everyone should use FF.

Wouldn't simply installing an ad/tracking blocker like uBlock Origin be just as effective, if not moreso?

uBlock Origin works best on Firefox anyway: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

Isn't it better to remove the different root problems isntead of having plugins working around?

Personally, I use uBlock Origin more to block obnoxious ads than to block the tracking.

I'm not sure I really care that much about tracking, honestly. So what if reddit knows I bought a toaster on Amazon recently? What are they going to do with that data, show me toaster ads? I'm going to be blocking that ad. Sell the fact that I bought a toaster? Whatever. It's all going to be so advertisers can personalize ads...which I will be blocking.

There's some overlap, but ads aren't the only thing using this. Google Fonts is the classic example of something that does add value (nice fonts) to a webpage, and as such isn't blocked by most adblockers (including uBO) by default, but is still able to use this for tracking because the same domain serves the font files on every website using them.

Very insightful response. The tendency is to look at the cookie problem as an advertising problem. Whereas, there are other cross-origin use cases that are not adverts but pose the same tracking threat. Anything on a CDN (like common javascript libraries) share this trait.

Not with Google hamstringing extensions w/ Manifest v3, no.

Thankfully we have Brave (and I think Vivaldi too). When the blocker isn't an extension, Manifest v3 doesn't matter much. Brave does CNAME uncloaking too, even though Chromium doesn't provide an extension API for it the way Firefox does.

Thanks man! I misunderstood the whole thing!

It's a legit usecase for Single-Sign On providers. However this functionality has been mainly abused by ad trackers, and has thus been curtailed.

Can you elaborate how? From what I know, the two most popular implementations - SAML and OIDC don't rely on 3rd party cookies. They rely purely on HTTP redirects.

I never understood it (third party cookies getting external information) either. Same thing with the referer request header, or user agents, or disabling the right-click menu, or editing the browser history, or opening new windows, or changing scroll behavior, or replacing the cursor icon, or autoplaying videos. There are reasons to want to do these things. In some cases it's difficult for the browser to prevent them. But I'd sure like it if the standards and browsers were on my side, not the side of those nefarious web developers.

Sites can't see the existence of other sites' cookies. They can, however, request resources from other sites. Those requests, in turn, would send third-party cookies, if any, to the third-party server _and_ save new third-party cookies in response. "Tracking beacons" abuse this behavior to correlate user behavior across many web sites.

Sites A and B both include content from the spying website S, which sets some cookies. Now S can correlate your visits to A and B because it's able to read its own cookies.

This change makes it so that requests A -> S (requests from A to S) and B -> S are treated as A -> S1 and B -> S2 instead.

Now S1 cannot read cookies from S2 and vice versa, even though they are the same site.

Cool. Just a heads' up that I had to disable it on Zendesk and Asana so they could talk to each other - you might experience similar issues.

Can concur, this broke Zendesk integration with Jira so I had to disable it for our Jira setup.

When I was blocking 3rd-party cookies on Chrome, I couldn't log into the IRS site. I figure that might happen here, too.

EDIT: Nvm, I found it. Thank you.

https://pbs.twimg.com/media/DzSc4mhX4AAi1Bz?format=png&name=...

Zendesk has been like this for me since forever. Every time I need to use it to talk to a vendor, I roll my eyes for 2 seconds and open my backup browser which does not have 3rd party cookie restriction.

That's not ideal! Could you please file a bug and provide steps to reproduce the issue? I'm happy to take a look. You can file it here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp...

Could you please file a bug and provide steps to reproduce the issue? I'm happy to take a look. You can file it here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp...

Privacy wins aside, can anyone please help educate if third party single sign ons will still continue to work?

I don't think they rely on third party cookies. You are redirected to the SSO provider which then issues a token which it transports back to the requesting site through other means than cookies (i.e. post body / query string)

Depends on the specific implementation, but in theory this doesn't limit any functionality for SSO. Data can be shared via mechanisms other than cookies.

Single sign on doesn't need cookies. The data is passed in the URL when redirecting back and forth between the website and the SSO provider.

This feature protects domains, not sessions. SSO relies on passing tokens over redirects, not cookies. As long as your redirected, the SSO uses their own first party cookies. You would be logged in to the SSO provider no matter who redirected you there.

It depends on the specific third party login service. Some rely on third party storage-sharing, and there are web compatibility measures built into Total Cookie Protection to allow those to keep working.

One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place.

In these cases, specific third parties can be granted access to allow the login. There are some more details here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...

And can someone explain how I'm supposed to implement SSO? We have a bunch of subdomains that support SSO by communicating with an iframe that has the logon status stored, but it appears that the iframe wouldn't have access to its own data anymore. Is that right?

Subdomains shouldn't be a problem unless your base domain is in the Public Suffix List.

According to MDN:

> More specifically, Firefox double-keys all client-side state by the origin of the resource being loaded and by the top-level site. [1]

They linked the definition of a "site" to the HTML5 spec, which says this:

> To obtain a site, given an origin origin, run these steps: [2]

> 1. If origin is an opaque origin, then return origin.

> 2. If origin's host's registrable domain is null, then return (origin's scheme, origin's host).

> 3. Return (origin's scheme, origin's host's registrable domain).

The HTML5 spec refers to the site's registrable domain according to the URL spec:

> A host’s registrable domain is a domain formed by the most specific public suffix, along with the domain label immediately preceding it, if any. [3]

Public Suffixes are defined according to a database that you have to explicitly register in [4]. If you aren't sure whether your base domain is registered as a public suffix, then it probably isn't.

[1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...

[2]: https://html.spec.whatwg.org/multipage/origin.html#site

[3]: https://url.spec.whatwg.org/#host-registrable-domain

[4]: https://publicsuffix.org/

Thanks! I actually got as far as your [1], but incorrectly assumed that 'site' meant 'origin', so thank you for explaining.

> making Firefox the most private and secure major browser available across Windows and Mac.

Which one do they think is the most private and secure browser for Linux?

Maybe they figure most linux users can tweak the settings, install & configure plugins on whatever browser they're using to harden things up with the hassle overhead they can live with..?

Shoutout for firefox's cross OS, cross device syncing. "I found that and I have that it open in a tab on my desktop" and now it's open on my phone. Send another tab from phone to laptop where it's easier to work on. Really good stuff.

Lynx probably

You'll be happy to see they've edited the announcement to include Linux now, likely in response to this or the other comment like it. :)

I've had third party cookies blocked for ten years. Some sites don't work. I don't use those sites.

What has become very annoying is so many sites are using "third party cookies" for whatever asinine "single sign on" product they've been sold. The number of redirects my browser undergoes when I log into my health insurance portal is mind boggling.

Maybe I am getting this wrong, but I think the reason you're being redirected through so many sites is because they're not using third-party cookies. They have to redirect you through each domain so that they can all set their own first-party cookies.

I wonder why Microsoft doesn't make Edge a privacy-oriented browser. I'm surprised they think they can make more from the data economy than they would gain by seriously hurting Google et al.

They have a private experience setup available(not private mode).I don't remember name but as soon as you install edge, it asks what level privacy you want to manage. That I guess should be fine.

Microsoft went all-in on "growth & engagement" since Windows 8.

Why sell OSes for money when you can get "engagement" instead?

Because Microsoft has had a history of caring about privacy?

I'd expect something like this from Apple with Safari, but not Microsoft. M$ can't even give its own developer base privacy by allowing all telemetry to be disabled.

Companies don't care about jack shit. Tim Cook doesn't "believe in" privacy, he thinks it helps sell devices (and that lack of privacy could lead to scandal that would hurt sales).

Whether one company is effectively more private than the other has nothing to do with what the company actually believes. It doesn't really matter what they believe. When you compare the two companies, Microsoft arguably has a greater history of embedding tracking in its products than Apple. This isn't to say that Apple doesn't track anything. As far as I'm aware, Apple didn't help the NSA bypass encryption or build backdoors into its OS.

There's too much money to be made foisting payday loans on the dwindling userbase. https://www.howtogeek.com/769427/microsoft-edge-wants-to-giv...

Those aren't payday loans, but interesting nonetheless.

Since when does Microsoft care about privacy?

How is this different from the old privacy.firstparty.isolate, and do I still need that/should I keep that enabled?

I've been blocking cookies actively for a long time, and except some technical embeds (for example STEP file viewer on misumi) I had zero issue.

This is great news. I really hope we will not lose firefox. I'm not saying it is better than chromium, but I think it is important that it exists.

How does this relate to the existing tracking protection settings - should I turn off "block all third party cookies"?

That setting breaks a few things, but mostly works OK. I'm confused which protection level this new capability corellates to.

This might help:

>Total Cookie Protection offers additional privacy protections beyond those provided by our existing anti-tracking features. Enhanced Tracking Protection (ETP), which we launched in 2018, works by blocking trackers based on a maintained list. If a party is on that list, they lose the ability to use third-party cookies. ETP was a huge privacy win for Firefox users, but we’ve known this approach has some shortcomings. If a tracker for some reason isn’t on that list, they can still track users and violate their privacy. And if an attacker wants to thwart ETP, they can set up a new tracking domain that isn’t on the list. Total Cookie Protection avoids these problems by restricting the functionality for all cookies, not just for those on a defined list.

This is strictly in-between allowing third-party cookies and blocking them. They are allowed, but isolated to prevent data sharing.

Previously: Site A has a facebook Like button, which iframes in facebook.com and sets a third-party cookie for facebook.com. Site B does the same. Site B can see that you previously visited Site A, and if you have a Facebook account, then Facebook can connect your browsing activity on both A and B to that account.

New feature: Site A's Facebook Like button iframes in Facebook, and sets a cookie on facebook.com. This is a different cookie than the one Site B sets for facebook.com. The cookies cannot tell that you're the same person. If you have a Facebook account, your browsing activity on A and B is not connected to your Facebook account.

This seems to be a middle-ground.

You can more confidently allow third-party cookies, which means that certain features that broke with the blocking of all third-party cookies will now be able to work, but you maintain most of the protections that you gained when you used to block them.

So.. Standard? or Off? Ever since this has been announced, I understand how it works, but the browser does not communicate at all which setting level it maps to, or if I even need ETP on at all and it's just always on.

ETP Strict

It appears that cookie isolation is always on.

If you want to further mitigate risk, you adjust your settings block all third-party cookies.

Total Cookie Protection is already on by default in private browsing mode, or strict ETP. Also Firefox Focus on Android. It's being rolled out to everyone in the standard ETP mode now.

It's currently controlled by setting `network.cookie.cookieBehavior` to `5`. (There is also a similar setting for private browsing mode which is already 5 by default).

Total Cookie Protection is the same as the Tor Browser's first-party isolation sandboxing - third-party cookies can't be used to track you across sites because they're only accessible within the domain they were created on. So you don't have to block 3rd-party cookies anymore, since they'll be sandboxed and unable to be used for tracking.

To be precise, it's third party cookie/storage partitioning, with web compatibility fixes to keep sites working.

I remember losing a bet a while back, because I was naive enough to think that was how cookies worked in the first place. Why did other sites ever have access to cookies they didn’t create was beyond me.

You don't need access to cookies you didn't create to do cross-site tracking.

Think: Disqus or Facebook comments at the end of articles, which used to be pretty ubiquitous. You'd be logged in and able to comment on any website using a cookie set by Disqus or Facebook, so you wouldn't have to log in or register on each individual website.

This Total Cookie Protection will break that. Your Disqus-set login cookie set on site A won't be visible when you're on site B, so you won't be logged in to Disqus there.

> Why did other sites ever have access to cookies they didn’t create was beyond me.

They don't.

If you go to example.com, and it loads an ad on tracker.com, then tracker.com will create a cookie. example.com WILL NOT be able to see that cookie. Likewise, if you were to log into example.com, tracker.com WILL NOT see the example.com cookie.

What happens (Without third party cookie blocking or FF's TCP) is if you then go to anothersite.com, and it also loads an ad from tracker.com, then the same cookie sent to it while visiting example.com will be sent, resulting in tracker.com knowing that you visited both sites. The admins of both example.com and anothersite.com will then be able to look at analytics and see that the visitors of their site also visit the other.

At no point is one site ever able to see a cookie they didn't create. Otherwise, this would be a MASSIVE security hole as it would make session stealing trivial.

However, a site is able to see a cookie they created while visiting another site.

Maybe this is what you meant, but it wasn't entirely clear.

Thanks; this is a more clear explanation than I've seen elsewhere.

If anyone wonders how bad the situation RE cookies is there is a local newspaper owner in the UK called reach PLC who own 100+ newspaper websites.

Their cookie allow dialog has over 700 data share partners, not including their own "legitimate interest" cookies. The dialog looks like this [1] and cannot be resized and is lazy loaded (i.e. you have to manually scroll to have the page load all of them with a few visible each scroll). And its slow so it takes a while and doesn't play well with the mouse in the iframe. There are even ones not in english or latin characters [2]

[1] https://imgur.com/a/ciuRWSx [2] https://i.imgur.com/4yc6Flo.png

Anyway i lazy loaded all of them and there are 753 (the html just to display it is > 1 megabyte

    $ xmllint --format reach2.html | grep qc-cmp2-list-item-header | tail && xmllint --format reach2.html | grep qc-cmp2-list-item-header | wc -l
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="Yieldmo, Inc." aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="YOC AG" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="YouGov" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="ZAM Network LLC dba Fanbyte" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="Zemanta, Inc." aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="zeotap GmbH" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="Zeta Global" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="Ziff Davis LLC" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="zillian sa" aria-live="polite">
        <button role="listitem" class="qc-cmp2-list-item-header" aria-label="Zoomd Ltd." aria-live="polite">
    753

It's crazy

Does this affect single-sign-on implementations?

It shouldn't. SSO doesn't typically work by sharing cookies, which have always been limited to a single domain in the first place.

I'm not sure about that. It depends on where the boundaries of the "cookie jar" are (through redirects and such). And I suspect it will effect it, in order to accomplish it's purpose. After all, what is tracking but a sort of "SSO" you don't know about.

(OK, technically tracking is less powerful than SSO, since only the third-party needs to know your "single" identity, the first-party website doesn't actually know it, where in SSO it does)

I mean, to be clear -- I mean the new thing might make you enter your username and password to SSO login on each site, whereas ordinarily if you have an active SSO session you don't need to re-enter username and password to login with SSO on a new site. Will it break SSO even if you are fine re-entering username and password every time you SSO login? I am not sure, but I definitely wouldn't be confident 'no' without more details/testing.

Those work by redirect you on top level domain (the url you see in url bar) shouldn't be affected. They don't even share cookie directly anyway. (Which is just.... standard oauth)

Those work by enbedded into pages (iframe) or popups may.

The biggest offender of this kind of usage is probably facebook comment / disqus comment.

Makes sense.

The difference will be (I predict) that when you are redirected to the SSO, you will _always_ have to enter your username/password, or at least once per "first party" site you are logging into.

Whereas right now, sometimes when you get redirected to the SSO/oath, it already knows who you are, and you don't need to log in again -- you just get invisibly redirected back, and/or just have to click a button saying "yeah, it's cool". But with the cookie sandboxes, you'll always have to actually enter username and password to your SSO. Because the cookies that would have told the SSO(/oauth provider) that you have an active auth session, from when you logged in earlier today or whatever -- won't make it.

Or maybe not, depending on how it's implemented -- but if a redirect is enough to defeat it and make it think you're in a different sandbox, then I expect all the trackers will be able to defeat the sandboxing with careful use of redirects. So.

Ad don't redirect you on top level domain anyway (except for some malicious ad). And silent popup these days don't even work.

If the site is willing to redirect you directly to another site. I guess they can share data by themselves anyway?

I think sabotage of silent tracking pixel/ajax tracking is enough for most usage without breaking the web.

It would break things like medium.com's constant prompt to login with this list of google accounts, but it wouldn't break SSO - SSO itself is typically handled by a series of redirections, and at the time you're redirected _to_ the SSO server, you're giving your cookies to _them_, then you're redirected back with a signed response and get cookies for the _destination_ domain - at no time during the exchange does the SSO server need to directly talk to the relying party.

Implementations may of course vary.

It shouldn't. "Exceptions are made for cross-site cookies when they're needed for non-tracking purposes, such as those used by popular third-party login providers."[1]

[1] https://blog.mozilla.org/security/2021/02/23/total-cookie-pr...

So only the popular third-party login providers are excused?

That feels worrying for competition, does it not entrench the current login providers?

Probably yes, but it shouldn't be difficult to get an exception by posting a request to the Firefox bug tracker. In the meantime users can disable Enhanced Tracking Protection on the specific site with the new SSO provider.

Total** Cookie Protection

**: Not total

It sounds like the "Full Self Driving"** from Tesla... got to love the new-speak.

**: Not fully self-driving....

SSO, probably not - embedding, possibly.

If you're just worried about logging in through sso.coolcorp.com to third-party.corp using any of the normal methods (OAuth, SAML, Kerberos, etc.) then you're probably fine.

If you're worried about composing a page made up of lots of custom embedded components and those components _don't_ use SSO (or if they do, but they authenticate invisibly using an iframe instead of authenticating entirely server-side) then you may have some things to switch up.

with mozilla's 2% browser market share, as a developer you don't need to worry at all

Given the number of Firefox users that block Google Analytics, I wouldn’t be convinced about a 2% figure.

It also depends who the users are... given that Firefox tends to be used by many technically-inclined users, sysadmins, etc. (at least according to what I observe around me), it might be users you might want to consider, depending on what you're offering...

You can block Google Analytics all you want. Unless you're spoofing your User-Agent, servers still know what browser you're using.

The question isn't whether the server logs are there. It's whether anyone looks at them instead of GA for browser information.

But GA, statcounter et al don’t use server logs. They use JavaScript.

> You may have some things to switch up.

Or rather a large logo that says "Please use a supported browser."

I know Firefox has a small market share, but this is the sort of feature other browsers may adopt. Maybe not the big boys like Chrome or Edge, but I could see all the niche privacy focused browsers implementing it and maybe even Safari given Apples claims to support user privacy. If a certain percentage of browsers started to use similar functionality I could tracking companies starting to develop countermeasures.

In fact I've already encountered one site that gave me a popup telling me to enable third party cookies. It was one of those dodgy sites that scrapes and copies Stack Overflow content and the JavaScript that enabled it was very clunky - but it worked. I'm surprised there aren't more websites already doing something similar.

> Maybe not the big boys like Chrome or Edge

Firefox has essentially the same market share as Edge.

Safari and Brave have been doing it already. Notice Mozilla's wording: "MAJOR browser available on Windows, Mac and Linux" to exclude the competition that got storage partitioning shipped before Mozilla did.

Does anyone know if this covers network-layer state like keep-alive or TLS session reuse?

Why not abolish third-party cookies altogether? There are very few good uses for them.

You can turn them off. However, most single-sign-on stuff will break without them :/

(at least MS accounts just don't work)

Single-sign-on stuff can be fixed by redirecting through the authenticator domain and passing the token or whatever back as a url parameter.

> You can turn them off.

Of course I did, long ago. The issue is that they're on by default. And defaults matter a lot because most people don't change them.

That would have to get fixed by the corporate maintaining that SSO. I even tried whitelisting domains, but it's also PITA since MS redirects you through 10 domains or so. Now I'm using cookie autoeater almost everywhere... so feel free to save your cookies, as soon as I close the tab they are all gone. I have to login every time, but saved passwords solve it reasonably well.

Chrome has on the roadmap to do exactly this. [1]

Turns out, Getting rid of 3rd party cookies concentrates power in the ad world in the hands of those with the most 1st party data (and active session cookies). Google, Facebook, Amazon and Apple. [2]

The tracking debate is contentious and has a lot of folks on here who are privacy maximalists, and I'm not trying to debate the ethics of ads.

But in terms of utility, 3rd party cookies are the backbone of ad-tech auctions and targeting, and currently give the non-Goog/FB/Amazon ad providers a way to compete on performance advertising.

Digital ad markets are expected to be nearly $565b this year, and the Tri-opoly of Google/FB/Amazon have 68% of the market. 32% of the market depends on 3rd party cookies to have a chance at competing. [3]

1 - https://privacysandbox.com/intl/en_us/open-web/#how-works-on... 2 - https://www.siliconrepublic.com/business/googles-privacy-san... 3 - https://www.emarketer.com/content/google-facebook-amazon-acc...

How does the tri-opoli keep traking users when there are no 3rd party cookies? Do they mean to implement an explicit exception/a different tracking protocolol?

Those big companies can simply rely on the amount of informations they get from their own services.

Google has a service for almost everything, Amazon knows exactly what you want to buy and like google is extending to all the aspects of your life with digital services and Facebook as well has apps people spend enough time in to obtain informations about their interests. So their ad networks could work without cookies. But they also rely on fingerprinting that’s done through the ads themselves and the analytics tools almost every website has.

It's nice, but is that so hard for Mozilla to tell in which version it will appear? Is it the current version or is it the next 102 version (which releases in 2 weeks, but then why they say it "rolls out"?)

Mozilla occasionally rolls out features in the current release via remote mechanisms. So it's rolling out to existing v101 installs now. I would assume that v102 will also ship with it on by default.

If you want to enable it early, I believe you can go to about:config and set network.cookie.cookieBehavior to 5

Likewise you can keep enhanced tracking protection in general but disable partitioning (total cookie protection) by setting it to 4

https://support.mozilla.org/en-US/kb/total-cookie-protection...

Looks like it's already in v101.0.1. It's under the Settings | Privacy and Security tab with a new checkbox to allow you to "Test Pilot our newest..." It is not automatically checked for me.

I think the change might just be they will be setting that checkbox to on now? Although I don't remember seeing this option until now.

When will the browsers take care of handling the cookie options for all the sites, so I can declare my preferences once and everyone stops putting up a popup? Surely this is already in the works?

Right, the consent window should have been a browser thing so that it is always the same and so that it follows the laws and cant involve dark patterns.

By reading this message you agree with it.

The answer is similar to the DNT (do not track) debacle.

When you give users a clear, informed, singular choice that would be sticky across their entire web/app experience, the choice in itself essentially becomes obsolete. Since pretty much nobody opts-in.

You saw the effect with Apple's new "do you want to be tracked" permission, which has a disastrous impact on Facebook. Consider that this is still a per-app permission, imagine the impact when its a single permission across all apps.

As users we may say "good" and "this is what we want", but I don't think we can truly oversee what impact that would have.

Facebook neither needs or deserves my pity.

If person A wants to do something to B that we can assume B does not approve of then A can ask if its okay. If A would never approve it doesn't magically become okay to do it. The thing could only happen if A has authority over B. As FB is not ur mum, not the government and not your employer they should ask the question or shut up.

Does someone have a link about the technical details for developers that it might affect (SSO, cookies for subdomains, etc). This is just a marketing post.

Also keen to see something like this. Firefox surely (hopefully!!) isn't going to block cookies across subdomains, or a whole bunch of things are going to break. Would love to see confirmation though...

There is some detail here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...

Ok, is this just a more complicated (and less private) version of the 3rd party cookie blocking that’s been in safari for more than 15 years?

If it is better - which seems surprising given it still seems to result in 3rd party cookies continuing to exist - how does it compare to safari’s domain partitioning from what seems like 5 years back, or the newer aayyyy iiiii tracker detecting stuff?

please someone fix the internet... I don't want to see any cookie popups on each site and accept / decline each cooke first only so I can see the content I want. I don't care about all these cookies and this should be managed by a browser. I hope what Firefox did is the beginning of such a fix.

Yes. Browsers should be required to show a cookie settings dialog once and then send the selected answer to all websites in a header. And websites should be required to read the header and behave according to it. The problem would be solved quickly that way...

Is that basically the PrivacyBadger plugin integrated into Firefox? Can I uninstall it now?

Hi, Privacy Badger dev here.

Total Cookie Protection helps by keeping all third-party cookies isolated to the site they were set on. This means tracker domains will no longer get their cookie identifiers persisted across different sites.

However, tracking isn't limited to cookies. If unblocked, trackers can still use techniques like browser fingerprinting and cookie syncing. They could also just track you via your IP address, or, most likely, via some combination of different techniques.

Trackers can also collect sensitive information such as your email address, or even become vectors for delivering malware.

Outside of privacy/security concerns, unblocked trackers can slow down websites and waste your bandwidth.

To learn about how Privacy Badger works, visit https://privacybadger.org/#faq

given that Electron is really just a featureless browser shouldn't it be straightforward to make your own browser now? An address bar, navigation, and bookmarks ought to be enough to get you there. Seems like you should be able to make a browser for your specific needs/wants pretty easily these days. I'm not suggesting some sort of money making venture where you're beholden to investors to try and turn revenue with it but more just like a utility. Like a script or something... maybe that's the way to think about it, something cobbled together quickly to read websites.

given that Electron is really just a featureless browser shouldn't it be straightforward to make your own browser now?

That's not what Electron is but there are piles of fork-ish browser projects out there statistically nobody uses. This also answers the second question in the negative - it is not straightforward to make your own browser that's as useful as the browser you're likely using.

> > given that Electron is really just a featureless browser [...]

> That's not what Electron is

I mean...isn't it?

Forget the idea of what it's used for and just look at how it works. It's a framework for making apps that uses Chromium for rendering and a Node backend. Strip off the Node backend and you're left with Chromium.

And Chromium on its own is a web browser. Electron just doesn't show the controls for it.

As far as I'm concerned, Electron is a featureless web browser with a backend added to do things a browser normally can't do on its own, like reading local files without presenting a dialog.

a backend added

That's a huge change which allows for things like turning XSS into RCEs. It's a bit like 'why can't you make your own street legal sports car by removing the rear spoiler and replacing it with a jet engine'.

When Mozilla comes out with a feature like this it usually whitelists google, microsoft and similar big sites so people can still log in across their network. Anybody know the current list for this feature?

Yes, you can follow the meta-bug here to see the current issues we're working on resolving in a better way: https://bugzilla.mozilla.org/show_bug.cgi?id=1537702

Perhaps unsurprisingly, Microsoft logins are the most glaring exceptions right now (Teams, Logins, Office, Live), and we're working with MS to see if we can find an acceptable fix (or work-around while it's fixed). There are also exceptions for github.dev and history.com right now.

It's worth mentioning that these aren't simply exceptions which blanket enable tracking for those sites, it's just to work around specific breakage.

We're also working around some other specific site logins or features breaking, which would not break if sites called the new requestStorageAccess API appropritately. We're using SmartBlock to shim those cases until the sites can fix it themselves.

What is the "better way" here?

There is a legitimate use case for having login/identity stuff on a different domain - many of the largest companies in the world are doing this.

How can this issue be solved without either confusing users through the requestStorageAccess API, or forcing everyone to use a single domain for everything?

Right, Total Cookie Protection has been baking for a while to try to minimize that kind of breakage, and we're already in discussions with other browser vendors and companies to get everyone onboard on the Privacy CG.

In a nutshell, adding new case-specific web APIs seems to be the likely way forward here. There are proposals floating around like an "is logged in" API, the Federated Credential Management API, and so on.

I'm not sure there's ever going to be a perfect solution for everything, but I would certainly rather have users more informed and empowered about their privacy than they currently are (even if some folks prefer to just "allow all").

I guess we'll just have to wait and see which proposals win out, and in the meantime rely on heuristic-based solutions like Total Cookie Protection to iteratively get us to a better place.

Reminds me of what Google Chrome (and others browsers) did for cache. That's clever, not 100% sure this will prevent tracking, but at least it makes tracker's life a bit harder.

Yes these are each subsets of State Partitioning[1], of which cache has also been partioned in Firefox for some time now.

[1] https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...

So what about things besides cookies and cache? Is there anything else that might be shared between 3rd party sites?

Probably best to say “Safari (and other browsers)” given that they were seven years ahead of the competition on this one.

I really want to enable resist fingerprinting, unfortunately it disables dark theming on github, ddg and other websites.

I wish I could add an exception rule to this...

I guess you could set up custom stylesheets, at least for sites you commonly browse.

The time-based light/dark mode setting requires the current time. It is not currently accessible from CSS and is blocked by resistFingerprinting

Does that for extensions like Dark Reader Pro too?

I've had it on a for a while and I don't seem to have any issues getting dark theming to stick.

For GH you can set your theme preference in your account settings.

Dark Reader extension has made me never notice this was a thing.

You could always step out of the cave and join the rest of humanity in the light.

I think OS Telemetry will see to it that its not private!

However this will make it easier than it currently is, to work out who is data sharing illegally.

This will only further entrench the big players (google, facebook, etc) while making it impossible for new & small players to compete. All of the services the big players offer effectively make working without universal cookies trivial.

For the small players though, without massive ad-supported service offerings like Gmail, Facebook (as a platform), etc, this will screw them completely.

Mind you, I'm a HUGE privacy advocate, so I like the new Firefox functionality... but the unintended side effects cannot be ignored.

Do we want anyone tracking us? I don't really care about the size of something that is tracking me - I care about the tracking itself.

Firefox really needs to implement two features:

1. Cookie Auto-Delete (see https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/wiki/...), where cookies and local data are automatically deleted some time after closing the tab. You can, of course, whitelist Websites to exclude them.

2. Firefox multi-container extension, to assign some websites (domains and subdomains) to a container by default so that you can visit some specific Google sites without being logged in (e.g Web search, News, Maps…) but still open Gmail and be connected to your account.

You can make this more intuitive and combine that in a single button: "Do not forget. Optionally, open website in <container>".

This would drastically level the playing field, as one can continue to use some Google/Apple services for work (e.g Play developers console, Google calendar…) but all visit to other properties would not be tracked. No need to switch between browsers, profiles or containers, this is automatic.

I've been using this set up for years now, and it works perfectly – just add uBlock and I don't care about cookies, and you'll ever see an ad or a cookie prompt ever again. Perfect.

(1) totally exists, that's always how I configure all my FF installs. You also can add exceptions, although I don't use this feature.

Unless I'm missing something, this only triggers on browser close. I sort of agree with the proposed tab closer with timer trigger idea, since I almost never close the browser on my main machine.

This is a fantastic way to do this. I wish Safari worked the same way instead of just completely blocking third-party cookies.

Can you explain why? Apple did this two years ago and I haven't personally seen any side effects, but Safari's also not my primary browser.

It makes my life harder as a developer. I've got some widgets (hosted by me) that are embedded on my customer's websites, and because of Safari I can't use cookies for things like a shopping cart. I have no need for the cookies to be accessible from another website, even if it's got the same widget embedded, so this implementation by Firefox fits my use case perfectly. Unfortunately that doesn't change what Safari does, so it doesn't help me.

Ah! I can see how that’d be a PITA, thanks for explaining.

I see this and I ask why it hasn't been this way since the beginning? why it took so long to have it?

UIs there a dashboard of somesort where I can see all the tracking/cookies bullshit affecting me?

Can someone help me understand how this is different from blocking third party cookies?

Firefox + ublock origin is my trusted porn browser.

I hope you add Incognito Mode to that.

Would love for Safari / iOS to follow suit.

Wish there was a feature or extension to auto accept cookie banners on websites

Cool but this product naming sounds like some scummy antivirus from 2001

Before anyone jumps to why Chrome doesn't block third-party cookies, some context:

Regulators did warn Google NOT TO block third-party cookies before they provide a replacement, UK CMA accepted the latest proposal from Google: https://www.gov.uk/government/news/cma-to-keep-close-eye-on-...

Apple's tracking rules also raised a lot of anti-trust concerns, giving advertisement in App Store unfair advantages among other ad platforms. Latest from German Government: https://www.bundeskartellamt.de/SharedDocs/Publikation/EN/Pr...

Banning third-party cookies will increase the gap between Google, Microsoft, Apple and other ad platforms, because they can still track you based on your account (e.g. Gmail, Hotmail, iCloud). It's a huge red flag for antitrust cases they are facing (especially Google).

Just to clarify, Total Cookie Protection in Firefox is not the same as blocking third-party cookies. Firefox will accept third-party cookies and send them back, but only on this particular site. So third parties (read ad networks) will be able to track you on any site, but not across sites (without some other means of tracking).

Yeah, which is why sites are all requiring logins nowdays, so they can use server-side ID syncs.

> so they can use server-side ID syncs

Does this only work if you use the same email across multiple sites?

If so it's yet another reason to use a different email address with every site you sign up at.

Which incidentally Mozilla also has a product for: https://relay.firefox.com

(Disclosure: I work on Firefox Relay :) And yes, I know some people also have their own domain with unlimited email addresses.)

Is there any plans to support naming my different relay addresses? :)

The service is awesome but it's quite confusing to know which one to use on which websites and which one to delete etc

There is already! However, depending on how long you've been a user, you might not see it yet; there's an option to allow us to store that data on our servers that we didn't turn on for people who were using Relay before that setting was introduced. You can enable it here ("Allow ⁨Relay⁩ to collect data showing the sites on which your masks are created and used"): https://relay.firefox.com/accounts/settings/

If you use the extension [1] [2], it can also store them locally if you want, and it will automatically track where you used the addresses, rather than you having to manually label them.

And finally, if you have Relay Premium, you can claim your own subdomain, and come up with an arbitrary address name (e.g. "hackernews@yourdomain.mozmail.com"), but since that's less anonymous than a random address, we recommend only using that if you need to come up with an address on the spot in the real world.

[1] https://addons.mozilla.org/firefox/addon/private-relay/

[2] https://chrome.google.com/webstore/detail/firefox-relay/lknp...

I've been following Firefox Relay features for a bit now. Is there a difference between the service offered by Firefox Relay premium to the free DuckDuckGo Email Protection?

Do you believe DDG will also eventually move to the subscription model for these features (unlimited aliases, reply to sender)?

I'm not super familiar with DDG's offering (and of course can't predict what they will do in the future), but some differences that I see on first glance:

- You need to use their app or browser extension to use it. (You can use Relay using just the website at https://relay.firefox.com.)

- Mozilla is a non-profit, whereas DDG is a for-profit company. (Though I should add that I'm a happy user of DDG search, and that I think they're pretty great.)

- There might still be a waitlist?

- Relay Premium has features like your own custom subdomain so you can come up with new addresses on the fly, the ability to reply to forwarded emails without revealing your address, unlimited addresses, of which I don't know whether DDG's service has them.

- On the other hand, Relay doesn't block trackers yet (but incidentally, that's the feature I'm working on right now).

- And of course, by subscribing to Relay Premium, you can support Mozilla and make it less reliant on Google :)

So yeah, not a particularly helpful comparison, since I'm not too familiar with their offering, sorry.

I'm sorry to bother you (and rest of HN) about your product in an off-topic thread, but I noticed ⁨Relay Premium⁩ is available in limited countries. Considering some countries in that list are part of EU, what are the limitations why I'm not able to subscribe to the premium service? Or is there a way to join Relay Premium while not in listed countries (for example, having credit card issued by a listed country)?

I'm not entirely sure, actually, but I think it mostly has to do with legal clearance (but might be wrong here). Your country is autodetected from your IP, so a different credit card won't work, I think.

I did recently build a waitlist, so you can sign up to be notified when it becomes available in your country. We're not linking to it from anywhere yet, but if you promise not to tell (just kidding), you can already find it at https://relay.firefox.com/premium/waitlist/.

> I know some people also have their own domain with unlimited email addresses

A friend of mine does it the hardcore way, through DNS. He adds MX records for subdomains corresponding to the name of the site he's signing up for. Lets say his domain name is example.com:

bob@hilton.example.com bob@ycombinator.example.com bob@firefox.example.com and so on

He also does it for friends(!) meaning when he gives you "his" email, it's always of the form bob@<yourname>.example.com

If he tires of you or your comms get too spammy, he just bins the relevant DNS record. No more mail from you!

Woah, I did not know that, but that is indeed hardcore!

> Does this only work if you use the same email across multiple sites? At a huge risk of EU regulars cracking on, it is quite possible to track a user across multiple accounts by simply using a cookie that lives long enough (say, 30 days) to establish the connections between multiple accounts.

For a server-side ID sync, you don't even need user accounts. Just a unique ID set in a cookie will do.

How would this work when the cookie ID is different for every different embedding (first-party) context? That's the whole point of total cookie isolation.

If you don’t want Firefox to do even that, you can go to Settings, click on Privacy & Security, then choose the Strict option. It’ll warn you that it might break sites, but you can always turn it off on a site-specific level by clicking on the shield in the address bar and turning off the toggle.

Be aware though that this will make firefox tell sites that you want a light color scheme instead of doing the more sensible thing and indicating no preference.

Though IIRC from some bugginess I was noticing a while ago, only to the JS API, it will still obey the dark color scheme media query (but sometimes inconsistently, I would load the same page in multiple tabs and sometimes get dark or light schemes).

This chain of replies containing only pertinent facts to inform the reader exemplifies what's so great about Hacker News. :-)

Interesting. I’m a light mode user, so hadn’t seen that.

    they can still track you based on your
    account (e.g. Gmail, Hotmail, iCloud)

Really? I don't think so. How would that work? If you visit www.somesite.com - how would javascript on that site identify you via Gmail?

What application are you using to visit that site?

Because Google's, Apple's and Microsoft's accounts specifically are tied to their particular browser and/or OS, not just the websites you're on.

So are Firefox accounts but they probably don't have the numbers to engage in any particularly egregious behavior.

What kind of mechanic are you describing? Are you saying the browser is phoning home, telling Google which sites you visit?

Yes. You can turn it off, though, if you take Google at its word.

https://support.google.com/websearch/answer/54068?hl=en&co=G...

Well, Chrome obviously does if you’re ‘signed in’ to Google and haven’t turned off their sync settings… which I imagine is the most common end user path, and chrome is the most popular browser. https://www.google.com/chrome/privacy/

Are you saying that Google is using their control of the user agent to specifically tie a Google auth cookie to an individual third-party-context web request even when third party cookies are blocked? If so, that would be a major scandal. What evidence do you have that this is the case?

Okay:

1) you visit to www.somesite.com

2) it serves an ad <iframe src="www.google.com/givemeanad?userforme=waps&hespent=500"

3) your browser does a request to google. It sends:

a) your login cookie from your gmail session (or ...)

b) the referrer header tells it which site to serve the ad on

c) any information the site itself wants to attach to the request

4) Google/Microsoft/Apple store this information and can provide advertisers with your identity, all sites you visit that have their ads, the "flow" (what you visited in what order, e.g. how far did you get in an ordering funnel) and any information those sites share about your account on their site.

Okay, but: a) is blocked by site partitioning, b) doesn't have per-user tracking information, and c) only works (of course) if you've explicitly signed in with Google on that site. I don't think Google supports third-party tracking for ads via that personalization path yet, but plenty of non-Google advertisers do: they take your hashed email address and use that to replace their third-party tracking cookies. This is what the ad community is hailing as their "privacy first" approach that breaks Google's "monopoly"—sending your email address to every single advertiser who they partner with.

Ah that’s very interesting. This really goes to show how powerful companies get when they have decent market share in the browser space while they have products on the web that have decent market share in other spaces, when there are grave concerns about what they do on either side of a decision. Chrome has been damn convenient from a dev perspective, and damn good, but the list of reasons I should be reaching for Firefox more often seems to be growing.

Yet another reason that we need to ensure that third party browsers are being used and in active development.

>Total Cookie Protection creates a separate cookie jar for each website you visit.

Means third parties win't be able to identify you qccriss sites through cookies. Means the Google Ads cookie or Floc ID will be different for each site you visit.

About 90% of Mozilla's income comes from Google.

If this would prevent tracking, Google would not allow Mozilla to release it.

Google would still have to fund Mozilla to prevent more anticompetition charges being levied their way regardless. uBlock Origin is a far greater threat since it blocks the more powerful JavaScript-based tracking, and you can see exactly how that's being managed with the move to Manifest v3.

Google's income will not change if they don't track.

If they can't track, then each ad has less value. But then the advertiser has more budget available to spend on advertising.

Net result is no change for advertisers, or Google. But they users will see more, less targeted ad.

So that's my prediction as the result of this: We'll have more ads, but each will be less personalized.

Reply on news.ycombinator.com