Yes. This comes very shortly after Google announced (in very “our incredible journey” style) that they’re dropping their plans to deprecate third party cookies:
I’m very happy to see this being called out. Reading between the lines it would seem Google’s ad arm has seen the effects of other browsers banning third party cookies and said “no way you’re doing this, Chrome”. I’m sure the Chrome engineers are livid about it (but that’s the deal they make by working there, I suppose)
There's been a lot of speculation that it's the other way around; removing third party cookies doesn't hurt Google's ad tracking but it does hurt the other advertisers who don't control the dominant browser, so they got spooked on antitrust grounds.
to be fair, google knew that if they continued, edge would immediately announce that they're not going to do it (at least when in an enterprise setting) and immediately gobble up all the ground they have lost to google on corporate deployments
> Some recent good examples of the designed-for-purpose approach include:
> FedCM. Third-party cookies have been used to support single sign-on. FedCM is a set of technologies built to support identity federation, without replicating all functionality of third-party cookies.
>CHIPS. The goal of CHIPS is to allow state, without supporting correlation or tracking between web sites which don't know they are collaborating, for example, when embedding third-party services like customer service webchat.
I've not heard of these two approaches. Can anyone vouch for their efficacy?
CHIPS is a nice solution, the problem is how it interacts with SSO IDP login pages.
99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons). What does this mean? That any embedded component that needs to log the user in needs to trigger a popup window - but wait, a popup window isn't in the same cookie partition as the iframe!
Some clever people at Google did come up with a solution for this, "pop-ins": https://github.com/explainers-by-googlers/partitioned-popins , which would have allowed cookie partitioning without breaking every enterprise integration out there
To explain CHIPS very simply: In the Internet of yore, if you loaded example.com and it had facebook.com embedded, then facebook.com would be able to access all of the facebook.com cookies. This is fine on paper, but Facebook encouraged well-meaning website owners to add a "Share" button to encourage organic sharing of their website. When users loaded a page with this button, that embed would get access to all of the facebook.com cookies, thus being able to know who you are, and the site you were visiting from. They'd record this and use it for advertisements.
With CHIPS, you can login to Facebook.com and your cookies are stored in the "cookie jar" labelled "facebook.com." Then, when you go to example.com, the "cookie jar" that the Facebook embed can use is "example.com->facebook.com." This means that Facebook cannot use cookies to track you across every website.
Unlike outright blocking cookies, however, CHIPS still allow well-behaved embeds to function. This allows customer service chatrooms to retain history, videos to remember where you last stopped, and so forth, even on subsequent refreshes, since they can read and write to their own "example.com->[embedded site domain]" cookie jar.
This compromise perfectly breaks cross-site tracking, while allowing useful third-party embeds to still operate.
> while allowing useful third-party embeds to still operate
the problem is that it breaks third-party embeds that want to provide SSO login, see my other comment. if google had released their "pop-in" suggestion it could have worked
If the browsers dump third party cookies, isn’t there just going to be some other technology to get around it and use first party cookies the same way we use third party cookies?
Is it really the technology that is the problem or is it the fact that companies have entire business models on tracking and surveillance that appears to be very profitable.
you can but it's several orders of magnitude more expensive. ad networks would have to propose backend integrations to each website, it just wouldn't be profitable unless the sites are huge
third party cookies track you across the web, on every site you visit, so long as the third party is in common. first party cookies are categorically different. I don't think the proposal is even the removal of third party cookies per se, rather that they be partitioned into silos based on the first party site. So there's no need for a workaround using first party cookies, but the capabilities exposed by cookies become categorically different.
Dumping third-party cookies is going to cause people's privacy to end up in a way worse position.
Almost all of ad tech is moving towards identifiers like hashed normalized emails (e.g. removing +'s from gmail), phone numbers, names, etc. for personalized ads.
As much as third party cookies are dangerous and unnecessary in a personal browsing setting, they are unfortunately a fact of life in the wonderful world of enterprise. that embedded Salesforce widget inside the SAP module of the Atlassian tool runs on a toxic mix of iframes and single-sign-on, and no-one in the company wants to have to go and rewrite it because someone at google wants to make the world a better place
it's possible using group policies, but imagine the complexity of getting the IT empires of a megacorp to approve and deploy this kind of stuff - it would be a nightmare.
Then microsoft come in and say "hey, just use Edge, we're Enterprisey just like you - we understand you guys. we'll disable this crap by default"
It’s been a long time but IIRC something akin to this already happened. There’s a group policy letting you open specific sites in “IE mode” in Edge, typically for old intranet systems that require IE and aren’t going to be updated:
i don't know if Google was primarily responsible for pushing for it before (after all Firefox has ALREADY gone further than Chrome on this?), but I'm no expert in the history.
When w3.org wrote that statement after they threw in the towel, it seems bizarre to me to suggest they wrote that statement only to do Google's bidding?
Everyone else just shipped some level of removing 3rd party cookies, but did so in a non specified way, with arbitrary carve outs & limitations & workarounds.
Google has been extremely busy trying to find ways to get login flows to keep working adequately well. In a specified, standardized manner. Look at what explainers they have, and note how many deal with 3rd party cookies or storage bucket access, https://github.com/orgs/explainers-by-googlers/repositories?...
Also compounding the difficulty is that we added storage isolation to the web, making even more of a fractal maze of problems, before figuring out how we were going to get rid of 3rd party cookies. That's probably fine, it's been a progressive layering of pretty good privacy/security, but it's more specced out complexity that has to be tangled with.
37 comments
[ 3.2 ms ] story [ 83.3 ms ] threadThe only other two browser engines that matter have already done it.
https://privacysandbox.com/news/privacy-sandbox-update
I’m very happy to see this being called out. Reading between the lines it would seem Google’s ad arm has seen the effects of other browsers banning third party cookies and said “no way you’re doing this, Chrome”. I’m sure the Chrome engineers are livid about it (but that’s the deal they make by working there, I suppose)
> FedCM. Third-party cookies have been used to support single sign-on. FedCM is a set of technologies built to support identity federation, without replicating all functionality of third-party cookies.
>CHIPS. The goal of CHIPS is to allow state, without supporting correlation or tracking between web sites which don't know they are collaborating, for example, when embedding third-party services like customer service webchat.
I've not heard of these two approaches. Can anyone vouch for their efficacy?
99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons). What does this mean? That any embedded component that needs to log the user in needs to trigger a popup window - but wait, a popup window isn't in the same cookie partition as the iframe!
Some clever people at Google did come up with a solution for this, "pop-ins": https://github.com/explainers-by-googlers/partitioned-popins , which would have allowed cookie partitioning without breaking every enterprise integration out there
No need for the quotation around "security". Clickjacks and other forms of attacks involving iframing authentication providers are a real threat.
With CHIPS, you can login to Facebook.com and your cookies are stored in the "cookie jar" labelled "facebook.com." Then, when you go to example.com, the "cookie jar" that the Facebook embed can use is "example.com->facebook.com." This means that Facebook cannot use cookies to track you across every website.
Unlike outright blocking cookies, however, CHIPS still allow well-behaved embeds to function. This allows customer service chatrooms to retain history, videos to remember where you last stopped, and so forth, even on subsequent refreshes, since they can read and write to their own "example.com->[embedded site domain]" cookie jar.
This compromise perfectly breaks cross-site tracking, while allowing useful third-party embeds to still operate.
the problem is that it breaks third-party embeds that want to provide SSO login, see my other comment. if google had released their "pop-in" suggestion it could have worked
Is it really the technology that is the problem or is it the fact that companies have entire business models on tracking and surveillance that appears to be very profitable.
Almost all of ad tech is moving towards identifiers like hashed normalized emails (e.g. removing +'s from gmail), phone numbers, names, etc. for personalized ads.
As much as third party cookies are dangerous and unnecessary in a personal browsing setting, they are unfortunately a fact of life in the wonderful world of enterprise. that embedded Salesforce widget inside the SAP module of the Atlassian tool runs on a toxic mix of iframes and single-sign-on, and no-one in the company wants to have to go and rewrite it because someone at google wants to make the world a better place
Someone at... where?
Then microsoft come in and say "hey, just use Edge, we're Enterprisey just like you - we understand you guys. we'll disable this crap by default"
https://learn.microsoft.com/en-us/deployedge/edge-ie-mode-po...
So yeah, it’s not simple, but it’s been done before and the concept works.
When w3.org wrote that statement after they threw in the towel, it seems bizarre to me to suggest they wrote that statement only to do Google's bidding?
This is not the only way. The SSO framework can be built into the browser or the OS, shifting it from third party to zeroth party.
And, in fact, foundational OS framework SSO is now available in current major releases of both Windows and MacOS.
Google has been extremely busy trying to find ways to get login flows to keep working adequately well. In a specified, standardized manner. Look at what explainers they have, and note how many deal with 3rd party cookies or storage bucket access, https://github.com/orgs/explainers-by-googlers/repositories?...
Also compounding the difficulty is that we added storage isolation to the web, making even more of a fractal maze of problems, before figuring out how we were going to get rid of 3rd party cookies. That's probably fine, it's been a progressive layering of pretty good privacy/security, but it's more specced out complexity that has to be tangled with.