Third Party Cookies Must Be Removed from the Web Platform | Hacker News Reader

Third Party Cookies Must Be Removed from the Web Platform

w3.org

67 pointsVinnl35 comments

The thing is, there are two "webs"

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 google wants to make the world a better place

Someone at... where?

Then let the enterprise world deploy some custom config that allows third party cookies for whatever domains they need. But disable by default.

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:

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.

That's the mystery to me. Cookies are up to the client. I'm always baffled about cookie legislation

Google is the one who does not want to drop third-party cookies.

Google is the one who has spent years and presumably many millions trying to make it happen, and has only recently thrown in the towel

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?

> they are unfortunately a fact of life in the wonderful world of enterprise

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.

Yes indeed that’s by far the best way out, but it requires orgs to do something. Whereas the existing “just works” (badly)

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.

They're being diplomatic by vaugely gesturing that "not all browsers" have dropped third party cookies, but isn't this squarely directed at Google?

The only other two browser engines that matter have already done it.

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:

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)

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.

They link to Google's recent statement so I'd say they're not being vague at all :-)

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

no one is running enterprise software on safari or firefox. it's chrome/edge or IE

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.

Yes, they basically move towards server-side integrations and tracking.

It's that the primary browser vendor is an ad company.

Browsers have the ultimate power here. You can’t make something with the tracking power of third party cookies unless browser APIs let you.

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

not really. as long as you own the domain, you can put a cname to one of their servers and voila… server side tracking with first party cookies.

This is already possible with Google Tag Manager. It was here on HN recently.

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.

> 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

"99% of IDPs in an enterprise setting are configured to refuse being framed (for "security" reasons)"

No need for the quotation around "security". Clickjacks and other forms of attacks involving iframing authentication providers are a real threat.

yes, fair enough

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

Which is what that other example, FedCM, is intended to solve, no?

yes but that requires working on existing integrations, whereas pop-ins would have "just worked"

Reply on news.ycombinator.com