This ship has sailed. The deprecation of 3rd party cookies will impact only the small ad-companies (the few that are still afloat)
The behemoths of the industry (GOOG, FB, MSFT, AMZN) have moved beyond cookies to tracking users at an ID level.
And with data sharing agreements in place [1] the big guys can track users across the spectrum.
Personal anecdote: Couple of days back me and a buddy were chatting over WhatsApp about a particular college. Neither of us had any affiliation to this college, and the college had come up in passing.
Couple of hours later, I began receiving ads on my Gmail about that _very same college_
Naysayers might refute and put it down to recency bias.
But this is just one example. I have noticed many others where my data has moved between GOOG n FB products in almost real time.
The deprecation of 3rd party cookies will make the small time companies scramble to figure out alternatives, which will invariably be super expensive. Thereby leading to further deaths of the independent entities.
So who is going to benefit from this deprecation?
GOOG/FB/MSFT/AMZN again. Yay!
So not only are you alleging that Meta scans your whatsapp messages for advertising purposes (which they strongly claim they don't do), you are also alleging that they are selling your whatsapp messages to Google?
That's some serious accusations. Without strong proof I don't believe it.
I assumed they were saying that they'd received an email ad, not that google served an ad. I could be wrong though. I wouldn't trust what meta says here considering their past history, but there are reasonable alternate sources in this case. Keyboard replacements on phones are notorious for logging, or either participant could have an app logging screenshots.
In Antonio Garcia Martinez's 2016 book "Chaos Monkeys: Inside the Silicon Valley Money Machine", he talks about a deal done between Google and Facebook to exchange data. So I'm pretty sure that would be happening.
Not so sure about Facebook analyzing your WhatsApp traffic, because they make such a big thing in their advertising about the secure end-to-end encryption and privacy. Surely they would get roasted if it was found not to be true. Of course it's always possible with a closed source app.
The technique discussed in Darknet Diaries episode 146 (about the ANOM phone) involved duplicating the message to [an] archive endpoint. It mentions Google providing text archival as a service for company phones, and it seems this also happens for WhatsApp. However, are Facebook also purloining your private WhatsApps? Are they using them to target you? Who can say?
On reflection, I think a more likely explanation is that Facebook just harvested, used and shared your WhatsApp metadata. Metadata analysis doesn't seem to count as an invasion of privacy in the modern world.
So while you and your friend chatted about this college, perhaps your friend googled it.
FB might then share with Google that you connected with your fiend at that particular time, and Google connected your exchange with the search.
Of course this assumes there is some way to tie your FB and Google accounts together - like matching up shared FB & Google tracker journeys across the internet.
The idea of third party cookies being bad is a reflection of the current state, not a methodology.
What happens if third party cookies are blocked?
Websites will just add a CNAME entry that points to whatever service they were using before. Then it's a second party (subdomain) cookie.
We need a different methodology how to keep cookies but limit their lifetime, reach, and damage they can do for its users, and a better unified authentication method that can also be spoofed/faked if websites become hostile. They need to be sandboxed, per URL scopes, not per domain.
We need to change the way of thinking of trust. Don't trust any website by default, only trust it once the user regularly visits it, or maybe set an allowed cookie lifetime per website after the user logs in.
But the current way of thinking about this problem led to the shithole that is XSS, session stealing and everything related to it.
Source: attempted to build my own browser that wanted to fix this and eventually had to give up
> Websites will just add a CNAME entry that points to whatever service they were using before. Then it's a second party (subdomain) cookie.
That doesn't cause the same problem as a third-party cookie, because it's not shared with other services that use the same third party. A subdomain doesn't let you get tracked across other sites.
> Websites will just add a CNAME entry that points to whatever service they were using before. Then it's a second party (subdomain) cookie.
A lot of tracking prevention mechanisms have started baking in CNAME uncloaking in the last few years precisely for that reason. Safari/WebKit[1], Brave[2], uBlock Origin (on Firefox only)[3], and NextDNS[4] just to name a few.
At this point the industry has moved onto straight up reverse proxying so it's all first party context. In milder instances it's in the form of server-side tagging[5] (which isn't a true reverse proxy, but can easily be used as one). But at least in those instances the website operators are the ones that typically own the server-side tagging process and have oversight/control/visibility into what they're putting in place.
But that has a high bar for implementation and relatively few companies have the resources or competence for that sort of thing. So it's much easier to persuade website operators to put a pure, dumb reverse proxy in place that gives them an endpoint under the first party domain to load resources from and send hits through[6]. Including being able to use HTTP set-cookie headers in the responses, while they're at it. Which is coincidentally the only long-lived cookie that still exists in Safari/WebKit, since things like "Keep me logged in" functionality would break if they started auto-purging those too.
If it's written in javascript, it's gone in 7 days even if it's first party. And if it's an HTTP header from a CNAME, it's also gone in 7 days. Only cookies set with an HTTP set-cookie header from a first party context are durable anymore. So that's exactly where advertisers are going into as an end-run in the game of cat and mouse - with surprisingly willing adoption from website operators, who are desperate to get their attribution back and don't quite understand the risk profile it exposes them to when they approve letting a third party operator masquarade so deeply as the website operator itself.
If you replace a cookie for eviladcompany.com with one for eviladcompany.domain1.com, there is still an advantage: that this is not shared with eviladcompany.domain2.com, so eviladcompany cannot know that it's the same person visiting both websites.
Sure there are browser fingerprinting techniques, but at least you're making privacy invasion harder.
I agree that we need to change the way of thinking about this, but I disagree with your particular proposal.
The change we need is to realise that this is not a technical problem and it can't be solved by technical means.
On the one hand, some of the largest US corporations are interested in subverting people's privacy. Some of those corporations directly control our computers and software running on them. They also spend billions to keep ahead of any non-megacorp competition (there's a business reason why Google keeps extending Chrome at breakneck speed).
On the other, the underlying problem is a kind of a prisoner dilemma. Spying-driven advertising is ultimately zero (or negative) sum for society [1], but any "defecting" company will be punished by relative sales underperformance. It's a coordination problem and it requires disincentives for defectors, which is not something we can engineer our way out of.
The solution has to be well enforced privacy protecting laws. Think GDPR, but with actual teeth and antitrust action, not letting companies get away with malicious compliance like sham "consent" forms directly violating GDPR [2].
Unfortunately, even on this forum there is very little understanding of the necessity of regulation, and I doubt things will change much. It pays very well to destroy privacy and open web (remember AMP?), and there is very little financial gain in going the other way. In fact, it's professionally harmful, since enablers are more likely to gain and hold power over those who object.
My only hope is relative outsiders in the EU legislature.
[1]: We haven't seen an explosion of productivity attributable to FAANG, so ultimately customers have the same pool of disposable money that businesses are competing for. The businesses haven't shrunk their marketing budgets either, so if you step back and look at the before/after state of the system as a whole, nothing changed except the big shift of ad money from old platforms (including print media) towards FAANG.
[2]: GDPR requires consent to be informed and specific. Ask yourself, do you really understand what precisely your data will be used for when you look at a typical "cookie banner"? Have you ever received a notification asking you if you consent to your data being used in a new way, which is absolutely necessary under GDPR if a data controller (i.e., a business collecting your data) decides to onboard a new marketing SaaS? Have you ever heard of a substantial fine for a company collecting consent in a way that is not specific enough?
> The unfortunate climb-down will also have secondary effects, as it is likely to delay cross-browser work on effective alternatives to third-party cookies.
We don't need "effective" alternatives to third-party cookies. The only reason that's even considered is because the advertising industry has captured the browser market and are using that control to ensure their continued ability to track users.
In fact, blocking third-party cookies is not nearly enough. We need to make sure most users have the capability to block all online ads.
I agree with you. But I also work on Keycloak and there are legitimate reasons why 3rd-party cookies are needed, they are essential for silent authentication flows and session management, which are part of the OpenID Connect standard.
Browser vendors have not yet provided APIs to both block cookies and allow for user consent to let these flows work. The Chrome team seems to be re-inventing the wheel with the Federated Credential Management API, which is not even close to done or feature complete with OAuth/OpenID Connect. This is why their end-of-year deadline was never a realistic.
All APIs introduced around the cookie phase-out are either fundamentally broken, or only serve to give established players such as Google more control over the user data.
For example, first-party sets are an allowlist curated by Google to determine who gets to set cookies in a third-party context, the FedCM API is barely implemented by a single vendor, the CHIPS API still breaks the most common cross domain authentication flows, and the Storage Access API is an inconsistent mess between vendors.
Worth noting that Apple and Mozilla both have some third party cookie deprecation, but significant unspecified carve outs and exceptions. It feels like Google's kind of had to go it alone with figuring out how this all really is going to work, what the specs really should do. And yeah, it's a much bigger project than the original times were set for.
> Worth noting that Apple and Mozilla both have some third party cookie deprecation, but significant unspecified carve outs and exceptions
Yep - the fact that there are hard-coded carve outs in webkit's source code for "theonion.com" and other such websites (and a bucket of heuristics which no one likes but which allow third-party cookies as first party in some scenarios) is why the web hasn't been more broken by this ... yet.
Can you give some pointers or what to search for regarding OIDC and 3rd party cookies?
I've implemented both OIDC SSO and SLO between a lot of varying services and identity providers and have never needed 3rd party cookies so I'm curious.
Only place I've seen it are some really old SAML implementations and even those could be reworked to not use 3rd party cookies.
This is specific to when you run a deployment where a user is authenticated cross domain with a authentication server.
If a user wants to sign in to foo.com through auth.com it is not possible for foo.com to know if the user has a session, so it needs to redirect the user to auth.com to understand if the user has a session. Previously this could be handled by embedding an iframe into foo.com with auth.com that can read the session cookie, this is no longer possible due to cookie protection.
Also if a user is signed into auth.com and foo.com, and then signs out of auth.com it is not possible to detect the user has signed out, as foo.com cannot access cookies set on auth.com.
I have third party cookies blocked, and have done so for at least a few years. The vast majority of sites, including SSO providers, function just fine. There shouldn't be a need for third party cookies to enable auth flow when you can pass data back to the originating site in a number of other ways outside of the cookies.
You can only pass data back to the originating site in one other way with GET and three other ways with any method that is expecting to have a body. But URL parameters are not a reasonable place to put sensitive information (even short-term authentication tokens) so that leaves us with body elements and headers. Headers can't be added programmatically in a redirect that needs to involve the client so you're left with POST-POST-POST and other fun. This doesn't _break_ the web, just makes it slower.
That said, once you introduce embedding (A embeds B, both A and B want to delegate the user's identity through SSO-C) you find the real pain points of lacking ambient authentication on the web. But even this case is possible if the websites cooperate ... which unfortunately means that techniques that enable cooperating websites can be used for cross-site tracking as well.
> there are legitimate reasons why 3rd-party cookies are needed
There are indeed. But given that 3rd party cookies are most commonly used for nefarious purposes, dispensing with them strikes me as the lesser of two evils. I do that myself with my browser settings.
When browsers finally step up and start managing cookies properly for once, can we finally get rid of the silly cookie banners?
I still find it odd how I'm constantly being asked if I'm fine with a website storing information in a place I have full control over. In theory it's the perfect method, privacy wise, it's just the user-agents who have dropped the ball massively.
California is suing Sephora for noncompliance, more will follow when the word gets out. I don’t know why the EU is dragging its feet incorporating GPC into GDPR.
Even if all cookies were completely disabled in all browsers, current privacy laws like GDPR would still require consent for all the tracking and sharing of private information that companies do through other means, and so websites would probably still display banners to remain in compliance.
Even that wouldn't change too much about the status quo for websites. Already a large part of third-party cookies is just you using a "free" (or paid) service by adding their tracking code to your website.
Why? I get that you don't like having your personal information traded, neither do I, but seemingly enough people like it that they give this information freely.
You don't need to disable cookies, just make sure that users are aware of what they're doing (which I'd argue is the browser's job, not the website's). If you send people a ticket number do you need to ask their permission for them to remember the number? No. Tracking cookies work the exact same way.
We're in the weird situation where we're banning what is by far the best and most privacy preserving solution in the name of privacy.
I mean can you come up with a way that is better than letting a user store data locally in their full control?
We need to bring back the do not track header as the legal means of giving consent. It’s a standard, its browser controlled and implementation is easier than the cookie banners.
Just make users make the choice, once, and for every website up front when they setup their browser.
It's one of the best marketing moves corporate has done in a long while that people think the banners are due to GDPR or the EU cookie law — they're not. They're only there because companies want to track you in as many ways as possible and they legally cannot without showing you a banner. You can set cookies which are required to use the main functionality without any kind of a banner, you only need a banner to track and hoard data.
Legally they can't even with a typical banner, since consent has to be specific and informed. There can be no informed consent when the banner presents 100+ data processors. The problem is that it's not enforced in any way.
I mean that's basically the same as saying it's because of the GPDR. People had these grand aspirations that the law would make companies change their behavior to not have the banner but that was daft. It just became another compliance checklist item.
The mistake was assuming companies can feel shame.
Why aren't people responding to the law in the way I want them to?! lol
The point is that the blame for those banners should be placed squarely on the websites that use them. If people are mad about them, they should be made at the website, not the GDPR.
That section in the GPDR didn't reduce tracking, it just added banners, and its removal would make the banners go away.
Legislate the behavior you want to see, not the behavior you hope will be a side-effect. You can't say, "the law is fine, it's the children that are wrong" when sites responded to the incentives they were placed under. The system finds an equilibrium at "everyone keeps doing exactly what they were doing before, just with a banner" and that's entirely the fault of the law. The incentives even go to far as to punish defectors because anyone who does right by their users loses money.
One side has money and power over changing the browser behaviour (Google and advertisers). They can use money for lobbying almost anything they need in all contries. They own almost all levels in the web tech stack.
Another side has nothing (users). No power, no comparable money.
> They can be helpful for use cases like login and single sign-on, or putting shopping choices into a cart
this doesn't make sense. if you're just solving oauth without cookies, solve oauth without cookies. make an oauth spec. (isn't passkeys supposed to solve oauth?)
also oauth uses redirects and query params I thought. I wonder if by 'single sign on' they mean 'tracking by google but not rando 3rd parties'
let's say SSO is an actual exceptional case where 3p cookies are useful. oauth + similar flows are miserable and nonstandard. make everyone happy with you one time in your life W3 group and standardize oauth. literally take whatever oauthlib and passport support today and encode them into a standard
not sure why shopping carts need to be third party; in the shopify case, shopify is hosting the store and the cart. if a cart legit needs to be shared across sites ... use oauth
They are already gone on Firefox. I had to reengineer one system to make it work. So if you’re care about compatibility, third party cookies are already effectively gone.
Isn't it the opposite? Most of Google's competitors in the ad space are very dependent on third party cookies but Google itself can get browsing information from Chrome directly.
AFAIK this is why the UK's competition authorities were hostile to Google removing third party cookies.
It’s unclear - competitors rely on 3p cookies, but abuse them. Google getting rid of them in theory levels some of the playing field - smaller companies can compete with larger ones because larger ones can no longer track users across every site where they have a pixel installed (IE fb’s massive advantage of having a pixel on virtually every website means only they know every single site you visit).
But in practice, the engineering lift and complexity of the solutions is absolutely massive, so many companies simply will not be able to play ball. Additionally, because the internet will be more private the sketchy companies doing things like fingerprinting will cease to exist. Google has never said they will kill off competing solutions that are not privacy safe (UID2), but have explicitly said they will stop any fingerprinting, cross site tracking, etc.
The behemoths of the industry (GOOG, FB, MSFT, AMZN) have moved beyond cookies to tracking users at an ID level. And with data sharing agreements in place [1] the big guys can track users across the spectrum.
Personal anecdote: Couple of days back me and a buddy were chatting over WhatsApp about a particular college. Neither of us had any affiliation to this college, and the college had come up in passing. Couple of hours later, I began receiving ads on my Gmail about that _very same college_
Naysayers might refute and put it down to recency bias. But this is just one example. I have noticed many others where my data has moved between GOOG n FB products in almost real time.
The deprecation of 3rd party cookies will make the small time companies scramble to figure out alternatives, which will invariably be super expensive. Thereby leading to further deaths of the independent entities.
So who is going to benefit from this deprecation? GOOG/FB/MSFT/AMZN again. Yay!
[1] https://www.reuters.com/article/technology/google-secretly-g...