44 comments

[ 1.7 ms ] story [ 137 ms ] thread
This is so cool. Makes me wonder why it hadn't been done already. Side note: Could have used something else other than the TCP abbreviation probably, but who cares
There are still sites out there that require third party cookies to function and it was only in the last few years you could consider getting away with this and not breaking a ton of sites.
Not sure I get your point. Total Cookie Protection doesn't get rid of third party cookies.
Consider a third-party cookie login flow where you go to one site to enter your password different from the site you are logging into. The password site sets a cookie which the site you are logging into will use to determine if your password was correct or not. If I follow TPC, this pattern would break because that cookie is now isolated from the site which wants it.

This used to be somewhat common. It is not anymore recently.

It was never great, but Safari's anti-tracking was probably what killed it, rather than anything Firefox does. Safari was certainly the driver of significant similar changes in projects I've worked with.

My recollection is that Firefox has exclusions for requests to third parties where that third-party just redirected the user to the site, in order to allow the login flow you wrote about. Don't ask me for a cite, though. Safari, on the other hand, will (or at one point would) block requests to domains if it's seen more than one domain making third-party requests to that domain and it's not been visited as a first-party.

This is great. I’ve been using multi-account containers for years and have loved the isolation. But I wonder how Total Cookie Protection works with different auth flows, like logging in to Trello using an Atlassian domain. Maybe it’s unaffected; I haven’t really looked at how/if cookies are involved in that process, but I can imagine TCP causing some frustration for users. Definitely will give it a shot, though.
I think third-party cookies should be disabled out of the box but there should be an option to manually allow them for legacy applications (if there are popular legacy applications then Firefox could include some of them by default).
Using what, the legacy app flag?
Which of course wouldn't be abused. Either set willy-nilly, or companies purposefully implementing broken methods to get an exemption so their tracking cookies work /s
Local domain whitelist? Would that work?
Created by the user? Like, who's going to go out of their way to create a whitelist of associated websites so it's okay to share across those sites?

So, I'm totally on board for this! The only other thing would be to just not let cross domain sharing. at. all.

If that frustration means that I have to log in with the same creds to two sites like Atlassian and Trello, then I'm okay with that. In fact, I would really like it if I didn't have to go to Atlassian at all and just be able to log in to Trello itself. But that's a different topic entirely. For the great majority of people it's the same email and password for every site they visit, so it's easy for them. Then there's the other end of the spectrum of people that use password managers and have dedicated credentials for every site, but it's also no big deal for them because they use the password manager to handle it.
Yeah, especially if we’re calling it TCP! :)
It would be nice if this were more obvious to a user without having to read a blog post saying it's doing this.

Example: In Safari private mode, I can open up Facebook and login, then if I open up a new tab or window and try to go to Facebook it's going to prompt me to login.

AFAIK in Firefox you should stay logged in in that case. It's just that if you then visit someothersite.com and that has a Facebook widget embedded, that you'll appear logged out of Facebook there.
That's good. I didn't mean to hint that it wasn't working just that I wish it were more obvious to the user. Logged in vs Not Logged in on a Facebook widget is not that obvious.
This is from 2022.

I learned recently from a Mozilla engineer that Firefox never made samesite=lax the default for cookies set without the samesite= attribute - they went with this Total Cookie Protection strategy instead: https://lobste.rs/s/98rp8f/cors_is_stupid#c_9dtjao

Here’s my exploration of samesite from a few years ago: https://simonwillison.net/2021/Aug/3/samesite/

As before, my frustration with this kind of browser feature is the lack of detailed technical documentation.

As a web developer, what does Total Cookie Protection mean for how I build web applications at the nuts and bolts level?

Show me some set-cookie examples that previously would have behaved differently and explain those differences.

Honestly, I barely understand how Firefox's cookie protection works anymore. It used to have the simple option to block third party cookies that I had running all day and felt good with. That was until they started becoming necessary in certain scenarios (I can't even remember the details of what that was).

And then these days I have no idea if I can just accept a website's advertising cookies and expect Firefox to block them anyways, or if clicking on such a button would disable the browser's tracking protection.

The most common scenario I can think of is needing to login through a third-party gateway on a first-party site. This is now broken with mainstream browsers, and you need to find another way to do the same thing. I'm not sure what people are doing now, because you can't retain state.

I had my clients just enable it on the browser.

OAuth. You open the login page in a new window with a callback URL. The third party service adds a token to the callback URL, which authorizes you to retrieve the real auth token from that service.
(comment deleted)
I've never seen OAuth replace the scenario of a first-party site allowing user generated content that can embed a third-party site authentication flow. Are people using OAuth for that?

I've only ever seen it for explicitly supported authentication flows by the first-party site.

The flow is supported by the first party, but the login goes through a third party gateway which sends a token to the callback uri.

I think the previous poster was responding to this:

“I'm not sure what people are doing now, because you can't retain state.”

They do OAuth.

That's not what I'm talking about. I'm talking about scenarios where the authentication flow is not explicitly supported by the first party. It just exists through an iframe.

There is no replacement. It's just not possible anymore. OAuth doesn't address this.

Yes, that's right. You can't steal credentials from another site without their permission.
No... that's not how that mechanism was ever used. The authentication flow I'm describing was used by companies to embed login flows for functionality that was delivered by iframe as companion behavior next to the first-party site.
OAuth. If you take Google as example, You let them sign in with Google through OAuth and then query the user data through the APIs. On-behalf-of/authorization code grant flow.

You can’t do an iframe, but you can still get the data if it’s supported by their api and yours.

Which is the way it should be, imo.

For a long while, google drive on the web would simply refuse to do anything unless you had 3rd party cookies enabled. I'm sure on purpose.
You were on drive.google.com but any files you wanted to download were on googleusercontent.com which needed auth cookies. So downloads didn't work, and neither did playing videos.

You could dodge around that with 'open in new window' but it was a pain in the ass. I think they've fixed it recently.

IIUC the main difference is that third-party cookies are not blocked, but scoped to the top-level domain.

So if you visit games.example which loads tracker.example it can set cookies. However these cookies are only used while you are on games.example. If you start browsing comics.example which also loads tracker.example it will start with no cookies, but can set cookies that only affect comics.example.

This way cross-site cookies can still be used for auth, experiments, spam protection or whatever else. But you can't do cross-site tracking as each top-level site had a separate cookie jar.

For clarity, I think this was posted because it was just updated. I think just the following was added:

> And starting in 2024, all our users can look forward to Firefox blocking even more third party cookies. That’s right; we are taking big swings to adopt new cookie partitioning and clearing mechanisms so that users can browse with fewer cookies that won’t stick around as long and will result in an even better browsing experience. Just another step on our road towards creating a better internet where your privacy is not optional.

Doesn't everyone set Firefox to delete cookies at shutdown? (with exceptions for a small number of frequently-used trusted sites)
This would be useful if I closed my browser regularly, but I haven't closed my browser in months.
I shut my computer down to a cold power-off every night, or whenever it goes into my shoulder bag (laptop).
(comment deleted)
It says Updated Aug. 28, 2024 - what is the update?

That they're expanding the deprecation of third-party cookies that they blogged about in December?

Edit: yes, looks like that last paragraph is the addition

I switched from long time chrome using to Firefox 2 weeks ago. I also installed the android app. It seems rather slow and the android app is horribly buggy. I gave up and switched to Brave. Now Brave on Android isn't great either but it works.

I don't quite understand the appeal of Firefox other than it maybe having the same appeal as Linux Desktop or LibreOffice(being free and an open alternative).

I'm curious what extensions you installed and what your hardware looks like. I've found firefox to be faster than chrome, but I know others have run into issues like you describe.
I should probably say that performance was certainly not the number one reason, as benchmark numbers are irrelevant for human users, but I was running it on M3 Pro MacBook Pro and on Galaxy S24+ each with ublock origin and dark reader.
I have used Firefox on android since 2018. I have never encountered a bug. Not a UI hiccup, not something doing something unexpected, not slowdowns, not crashing, not anything.

I routinely open links in the default android browser (chrome now), and it literally crumbles under the weight of ads in your average article, and then open it in firefox and uBlock means it runs great and any issue I was having disappears.

>I don't quite understand the appeal of Firefox

It's not chromium based, so Google can't force it to grow in the direction that only benefits their infrastructure like they do so much with chrome, and uBlock is a strictly better ad blocking system than anything I have ever used. I don't think Brave is independent, as they are beholden to the Chrome team's architectural decisions and design goals. It attempts to send less tracking information to people tracking me (with a caveat that Mozilla themselves do a little first party tracking and advertising, which I consider morally less wrong than Google's entire business), and is not incentivized to make the web a worse place for the sole purpose of increasing Google's share price.