Third party cookies must be removed
169 comments
·May 2, 2025growthwtf
IshKebab
Isn't W3C fairly irrelevant these days?
bilekas
It's W3c... They've never been the most coherent with standards ironically.
motorest
...or it's a design by committee thing, and some people in the room are doing their best to preserve current and future tracking technology.
bilekas
It's exactly this, there is a group who come together and never agree on rules, but when they do, they never enforce them. It's I believe the definition of a paper tiger, sadly. A great idea executed horribly.
__alexs
Standards bodies rarely enforce rules themselves.
squigz
Is it really on the W3C to enforce standards? How would that even work?
motorest
> A great idea executed horribly.
No. It's sabotage.
null
null
null
dbushell
The "replacement" is already being penned: https://www.w3.org/TR/privacy-preserving-attribution/
Which is just going to be in additional to 3rd-party cookies. Google's own study concluded removing 3rd-party cookies loses revenue and "privacy-preserving" tracking increases revenue: https://support.google.com/admanager/answer/15189422 So they'll just do both: https://privacysandbox.com/news/privacy-sandbox-next-steps/
surajrmal
There are regulatory agencies which have specifically told Google it is not allowed to remove 3rd party cookies without a replacement as while Google would be able to continue to function fine, their competitors would take a major loss.
JoshTriplett
Sounds like a great argument for running a different browser not developed by an advertising company, and thus not constrained by that.
pas
Do you have links for this? I'm curious about which bodies and what was their argument.
josefx
Another "trusted" third party based tracking system. All I need to know to avoid it even when it is printed on toiletpaper.
red_admiral
I just want someone to explain how I can edit my own privacy preserving attribution database. Is it a local SQLite database or something?
I feel like storing my "preferences" locally without letting me edit them as a stupid move.
jeroenhd
Google's design stores the tracking data locally. Chrome already has a UI to manage topics of interest (chrome://settings/adPrivacy).
freeamz
Feel like all this cookies thing is just white wash, when if you enable JS then they can track you no matter if you have cookies or not!
Nothing is private: https://nothingprivate.gkr.pw
More effort ought to be put into how to make web spec to NOT be able track user even if JS is turned on.
Browser vendor Brave, Firefox suppose to privacy browser are NOT doing anything about it.
At this point, do we need to using JS disabled browser to really get privacy on the web?
littlecranky67
Any other tracking methods are way more obvious, and way harder to implement for the advertising industry. We shouldn't think in black/white here - the more difficult it is to track a user, the less likely it is implemented. It is okay if 30% of tracking sites dissapear as the cost/value ratio don't work for them. We don't have to sit in silence and do nothing, just because we can't have the 100% privacy.
matthewdgreen
I do think there is a point here: any technical means to block tracking is going to be overrun by technical means to overcome the anti-tracking tech. There are simply too many dollars at stake for anything else to happen. If anti-tracking stops some players, that just means the industry will consolidate into a few large and well-resourced players.
While I am all in favor of continuing the technical battle against tracking, it’s time to recognize that the war will only be won with legislation.
idle_zealot
> At this point, do we need to using JS disabled browser to really get privacy on the web?
My thoughts are that we need a distinction between web pages (no JS) which are minimally interactive documents that are safe to view, and web apps (sites as they exist now) which require considerable trust to allow on your device. Of course, looking that the average person's installed app list indicates that we have a long way to go culturally with regards to establishing a good sense of digital hygiene, even for native software.
wtallis
It doesn't help that web browsers aren't even trying to help users make the distinction. They have an ever-growing list of features and permissions that sites can take advantage of, with no attempt to coalesce anything into a manageable user interface. Instead, it takes a hundred clicks to fully trust or distrust a site/app.
freeamz
More UI/UX distinction is needed! Just the green lock for security! The browser should indicate the level of privacy of the page. If the page use no js or any GPU compromising (css I'm looking at you), then it gets a green kind. For every privacy/security compromising feature you add the turns yellow. Once it start to ask for WebUSB, MIDI, then it should be in some kind of Native Mode. More like a UI/UX issue for the major browser makers!
GCUMstlyHarmls
https://nothingprivate.gkr.pw seems to (not) work fine in Firefox... I am running ublock-origin though, no other special things.
Diti
Same here, it’s not just you. Judging by the other comments, it only seems to “work” on Blink-based browsers.
gkbrk
Doesn't work on Brave. It says to check it on private mode, but when I switch to private mode it just asks for my name again.
FridgeSeal
Also doesn’t work on iOS (for me).
brookst
It’s an interesting question: is it possible for JavaScript to be turing complete, able to read/write the DOM, and somehow prevent fingerprinting / tracking?
My gut says no, not possible.
Maybe we need a much lighter way to express logic for UI interactions. Declarative is nice, so maybe CSS grows?
But I don’t see how executing server-controlled JS could ever protect privacy.
Enginerrrd
I've always thought there should be a way to use the browser like a condom. It should obfuscate all the things that make a user uniquely identifiable. Mouse movement/clicks/typing cadence should be randomized and sanitized a bit. And no website should have any authority whatsoever to identify your extensions or other tabs, or even whether or not your tab is open. And it certainly shouldn't allow a website to overrule your right click functionality, or zoom, or other accessibility features.
JSteph22
The obfuscation makes you more easily identifiable.
febusravenga
Yes, it is.
Just create _strict_ content security profile, which doesn't allow any external requests (fetch) and only allow load of resources (css, image, whatever) from predefined manifest.
App cannot exfiltrate any data in that case.
You may add permissions mechanisms of course (local disk, some cloud user controls, etc).
That's a big challenge in standards and not sure if anyone is working on such strongly restricted profile for web/js.
chongli
It’s an interesting question: is it possible for JavaScript to be turing complete, able to read/write the DOM, and somehow prevent fingerprinting / tracking?
Yes, of course: restrict its network access. If JS can't phone home, it can't track you. This obviously lets you continue to write apps that play in a DOM sandbox (such as games) without network access.
You could also have an API whereby users can allow the JS application to connect to a server of the user's choosing. If that API works similarly to an open/save dialog (controlled entirely by the browser) then the app developer has no control over which servers the user connects to, thus cannot track the user unless they deliberately choose to connect to the developer's server.
This is of course how desktop apps worked back in the day. An FTP client couldn't track you. You could connect to whatever FTP server you wanted to. Only the server you chose to connect to has any ability to log your activity.
adrr
There's no point. If you diaable JS. Can track you other ways, fingerprint your dns packets like timestamp clock skew and other things. With IPV6 can assign you unique ip address for a dnslookup that can function like a cookie,
Don't want to be tracked. Don't go on the internet.
waynesonfire
Why does it have to be a technological solution? That's what the media industry tried to do with DRM and it failed. The solution is legislation. We need the equivalent of DMCA for our privacy. Make it illegal to fingerprint.
6510
I don't know what it is called but if you try to open a window from a timeOut it wont work. The user has to click on something then the click even grants the permission.
You could make something similar where fingerprint worthy information cant be posted or used to build an url. For example, you read the screen size then add it to an array. The array is "poisoned" and cant be posted anymore. If you use the screen size for anything those things and everything affected may stay readable but are poisoned too. New fingerprinting methods can be added as they are found. Complex calculations and downloads might make time temporarily into a sensitive value too.
degamad
In the old days, something similar to what you're calling "poisoned" was called "tainted" [0].
In those scenarios, tainted variables were ones which were read from untrusted sources, so could cause unexpected behaviour if made part of SQL strings, shell commands, or used to assemble html pages for users. Taint checking was a way of preventing potentially dangerous variables being sent to vulnerable places.
In your scenario, poisoned variables function similarly, but with "untrusted" and "vulnerable" being replaced with "secret" and "public" respectively. Variables read from privacy-compromising sources (e.g. screen size) become poisoned, and poisoned values can't be written to public locations like urls.
There's still some potential to leak information without using the poisoned variables directly, based on conditional behaviour - some variation on
if posioned_screenwidth < poisoned_screenheight then load(mobile_css) else load(desktop_css)
deadbolt
Just tried this with Brave and it didn't seem to work, assuming the site working means that it can remember me in an incognito browser. I gave the site a name, and then opened it in incognito (still using brave), and it acts as if I visited the site for the first time.
What am I supposed to witness?
cptskippy
It didn't work on Firefox mobile either... Why are all these browser companies breaking the web!
hi_hi
I think this is a bit overblown. Brave and Safari we're both private when I just tested. Chrome not so much, but thats expected.
antihipocrat
Unmodified server request headers contain enough information for tracking even if JS is disabled. If you're keen to modify http headers while browsing, then you could also modify any JS run on your system that snoops system information (or strip the info from any request sent to the server) and continue with JS enabled.
sedatk
If third-party cookies are removed, the tracking parties will just ask web sites to include the script on their web server, so their cookies become "first party" again. I don't understand how this helps the web unless protections against tracking itself, not the methods used, are established.
Dwedit
It's about trust, the third-party ad companies don't trust that the first party will be honest with them, not generating fake impressions or clicks.
thayne
There are also trust issues the other way. I've seen a lot of contention between developers and security teams and marketing about putting third party code or proxying third party domains on the first party site for analytics, tracking, ad attribution, etc.
sedatk
I doubt that. Their script could as well be "fetch that script from that URL and run it". They would have fraud detections already in place on their side regardless of which script runs on the client.
chii
> "fetch that script from that URL and run it"
but if you cannot have a third party cookie, the remote site from the tracker cannot be sure that the script was actually downloaded, nor executed.
blacksmith_tb
That's old hat, the future is server to server calls from sites to vendors, profile the client but don't try to run any tracking js on it.
kstrauser
That's vastly more expensive, though. Now you have to run extra servers to make outbound connections to the ad tracker's API server instead of turfing off all the work to visitors. It would be enough to significantly affect the ad market.
Griffinsauce
Oh no!
ars
I don't think it's that expensive to do. All it takes is one well written package that is easy to install and this will be come standard.
I could even see a data broker centralizing this and distributing tracking to all of their clients. The client would just need to communicate with the central broker, which is not hard at all.
sedatk
That's also quite the possibility, and supports my point.
coffeefirst
This doesn’t actually help. If you consider Prebid, Criteo already has js running on the site serving the ads, but that js has no mechanism to figure out whether the user has something in their cart and is eligible for retargeting.
The workaround is looking more and more like IP, fingerprinting, and AI. I’d argue this is worse than 3p cookies, which were at least dumb and easy to clear.
fiddlerwoaroof
I think many adtech companies (at least in affiliate marketing) use redirects because third party cookies are unreliable and redirects make all the cookies first party. As mentioned elsewhere, they’ve also been switching to proxies and other such techniques to make it even harder to block their tracking endpoints.
parrit
Proxies for analytics are already a thing. E.g. plausable shows you how to set one up. A 3rd party cookie can however be the same value sent again and again from the same browser from different sites to the central server tracking you across the web. The global who you are is in the cookie.
timewizard
> include the script on their web server, so their cookies become "first party" again.
That script would execute with the origin of the server. It's access to resources and /shared state/ would be hampered by this. So as a cross-site tracking strategy I don't think this works.
> I don't understand how this helps the web unless protections against tracking itself, not the methods used, are established.
Which is why I think state partitioning[0] and CHIPs[1] are good technologies. It allows previously existing standards, like cookies, to continue to exist and function mostly as expected, but provides the user a good amount of default security against cross site trackers and other malware.
[0]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...
[1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...
littlecranky67
Your point is pretty useless, as you assume the web server admins want to be more secure. The opposite is the case, usually they deliberately open up their security model to accomodate 3rd party tracking scripts. For example, Content-Security-Policy headers can effectively prevent all sorts of xss attacks, but they will also prevent 3rd party tracking scripts etc.
timewizard
You've misunderstood my point. It's not what the server admins want it's what the security policy will allow. If two sites, on two different domains, both use the same script, served directly from their domains, it creates absolutely no workaround for third party cookies. This is because the two sites have different origins. CSP does not create a bypass in this case.
jeroenhd
Google won't implement this spec. Currently, they're legally not allowed to, because advertisers called in the industry watchdog, asserting that without third party cookies to stalk users, they could not compete. Google extended their privacy sandbox, opened and closed it, talked about it, and eventually backed down from their plan to block third party cookies ASAP.
Maybe Chrome can get away with "the spec says it, sorry advertisers" but I doubt the courts will accept that.
nine_k
That is, Firefox can reject third-party cookies because it's not made by a company that deals in online advertising, but Chrome cannot, because Google is the biggest online ads dealer and thus would have an unfair advantage over other ads dealers, correct?
oliwarner
Sure but this neither makes an attempt to list the valid uses of third party cookies, nor a suggestion of what magic definitely not a third-party cookie unicorn is going to ride in and offer us the safety we need. Pretty fluffy through and through.
I suggest that we do just need to keep third-party cookies but they're explicitly opt-in. That could just be allowing (once) a third party to be present everywhere (like a SSO) and browsers making it known when a third party is accessing data.
RainyDayTmrw
This is kinda hollow while Google controls Chrome, and Chrome has majority market share[1]. And, if regulators get their way, and Google divests Chrome[2], I'm not expecting that the new highest bidder would do any better with it.
[1] The exact figure may depend on which source you use, and there is some indication that ad and tracker blocking may artificially deflate Firefox and friends. https://gs.statcounter.com/browser-market-share [2] https://www.wired.com/story/the-doj-still-wants-google-to-di...
JoshTriplett
As long as the new steward of Chrome is not an advertising company, they will no longer be restricted from removing third-party cookies.
j16sdiz
> Some of the use cases that are important enough to justify the creation of purpose-specific solutions include federated identity, authorizing access to cross-site resources, and fraud mitigation.
Unpopular opinion: There are no privacy-preserving way for "fraud mitigation".
Either you accept fraud as cost to run business, or do away the privacy. Most business owner don't want the fraudulent user to come back, ever. If we value the privacy of user, we need to harm some business.
omeid2
In theory it is by possible by "blind attestations" by a 3rd party, in an indirect way, that is what you get by Cloudflare, where they monitor traffic from an "agent" using their own heuristics for identity, without sharing that identity with you.
xnx
Careful what you wish for. Removing third party cookies without a replacement will make aggressive fingerprinting ubiquitous.
Springtime
I've always assumed fingerprinting was already ubiquitous. I look at the absolute absurdity of tracking/fingerprinting permission dialogs on sites, stating up-front their data sharing with 'trusted partners' in the hundreds ranges (thingiverse.com with over 900, theverge.com on mobile with over 800) and find it more surprising that the default state of all clients shouldn't be to block everything by default.
Edit: for clarity, I believe anything with the ability to analyze the user environment via Javascript/etc on major sites is likely fingerprinting regardless. Blocking, environment isolation and spoofing is already necessary to mitigate this.
deadbolt
Do you believe that while third party cookies exist, tracking companies aren't using other fingerprinting methods?
xenator
I have feeling that it is all related. When use see request to accept cookies with list of over 9000 trackers it doesn't mean that this page will have zillions of javasripts included on the page. It just means that site owners fingerprint user and process user interactions to third parties server side.
Only reason why we see this movement is because advertisers feels confident about removing third party cookies.
bennettnate5
...thus raising the bar for privacy-preserving techniques in client side browsing. Aggressive fingerprinting arrived years ago; if we can move beyond cookies altogether and focus on it as the next issue to tackle, I would think that's a net win. Saying that we should keep 3rd part cookies alive and healthy because it will keep websites using them against users rather than fingerprinting is just throwing the majority of users who don't know to block them under the bus. Plus it still leaves the door open for even privacy-conscious users to be defeated by fingerprinting anyways if a server is keen on tracking particular individuals.
Terr_
Yeah, the only way third-party cookies will block creepier fingerprinting crap is if the creepy stuff is prohibitively more expensive.
But once anyone gets a creepy fingerprinting system working, the barriers drop, and it becomes cheaper to resell the capability as a library or service.
It may offer some minor benefits in terms of enabling companies that "want to be more ethical than the competition", but that too seems like a long-shot. :p
null
johnmiroki
Replacement solutions must be provided before it's mandatory to remove third party cookies. Otherwise, it's doomed to fail.
recursive
Replacement for what use case? The whole point is to eliminate the behavior, not provide another feature that has the same problems. What does failure mean? It's a problem for ad networks, not for regular humans.
svieira
The use case of not having to log in to system A which is being embedded within system B because you already logged in to system A? Without needing to introduce a third party SSO C? That's pretty "regular human", even if it's "medium sized corporation" instead of "Joe Regular" (but even Joe likes it if he doesn't have to log into the comment box on every site that uses THE_COMMENT_SYSTEM_HE_LIKES.)
koolba
This exists already. You can have cookies at higher level of the same domain. So foo.example.com and bar.example.com can share cookies at example.com. You can also use CORS to interact with a truly third party site. None of these require third party cookies.
jfengel
The use case is web sites that want to earn income with as little user overhead as possible. Targeted ads have many downsides but they do pay websites without any money at all from the user, or even having to create an account.
So the problem for regular humans is the disappearance of features that they've grown used to having without paying any money. Finding a better way to support themselves has proven remarkably difficult.
deadbolt
I feel like many people here wouldn't care if those websites simply stopped existing.
int_19h
The viability of their business model shouldn't be everyone's problem.
etchalon
People made money on advertising before the existence of cookies and ubiquitous tracking. Nature will heal.
petesergeant
The article explicitly calls out that there are valid use cases (although doesn’t enumerate them). Federated sign-on and embedded videos seem like obvious examples
p_ing
Google/Chrome just declared that they won't be moving forward with removing 3rd party cookie support.
https://privacysandbox.com/news/privacy-sandbox-next-steps/
> Taking all of these factors into consideration, we’ve made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies.
svieira
Ah, now _that_ makes sense why this go published then. Glad to see that common sense prevailed. The day may come when all the use cases for third-party cookies that aren't "track Joe Regular all around the web" can be satisfied with other widely available web features, but until we have all those features I think taking a page from Linus' book and ensuring "we don't break userland" is important (and something I've always loved about the web and I'm glad to see it continuing).
somenameforme
Which use cases? I use Brave, which has a built in toggle to disable 3rd party cookies, which I have set to default, and at least my experience of 'the entire internet' works fine.
Nevermark
Company whose market cap reflects pervasive surveillance non-requested announces that after serious consideration they won’t be removing technologies that enable pervasive non-requested surreptitious surveillance.”
It is going to be interesting to see if anti-trust enforcement's manages to separate Google from its financial and practical hold on web standards/browsers.
The opportunity to increase ethical norms of web browsing would be welcome to me.
pests
Google wants to remove third party cookies but they can't as the government sees it as anticompetitive to their competition. They dont need third party cookies, everyone else does.
driverdan
We don't need a replacement, they're not needed today. I've been blocking them for years and I can't remember the last time it caused a problem.
jeroenhd
Google has set up a replacement that puts the user in control of their ad interest tracking. It has its upsides and downsides, but I think it's pretty balanced. Anti-tracking features are embedded into the API so the API can't be abused by advertisers.
Of course, ad companies scream bloody murder, and the UK market watchdog had to step in so Google wouldn't turn off third party cookies by default.
hiccuphippo
Do not worry, the ad networks will come up with ways to circumvent it as soon as it becomes mandatory.
tejtm
done. third parties can be replaced with legally culpable first parties.
kgwxd
I've have them turned off since Firefox added the feature. Looks like that was around 2018, though I could have sworn it was much earlier than that. I've never had an issue where I had to make an exception for a site. Is there still some environment where it's common for them to be needed?
g-b-r
I don't recall a browser that didn't let you disable third-party cookies; given how long ago cookies were introduced, I could have forgotten about it, but I'm at least sure that Mozilla always supported it.
Firefox, especially in the first versions, permitted much less control on cookies than Mozilla did, but I think it still always allowed disabling third party cookies.
codeqihan
I have always blocked third-party cookies. The only problem I've encountered (there may be others, but I haven't come across them) is that some embedded videos on certain web pages won't play and prompt me to enable cookies.
badmonster
third-party cookies have done more harm than good, and it's time to fully remove them from the web platform. It is refreshing that their acknowledgment that replacements must not just be privacy-washed clones of the old model — purpose-built alternatives need to prove they don’t recreate the same surveillance infrastructure.
What a weird piece of writing. Is this like just chicken scratch? Or is this seriously some kind of part of the W3C working process?
Section 2: Third party cookies have gotten bad. Ok.
Section 3: There are legitimate use cases that third party cookies currently cover. Also ok. Then they throw in, "Be aware that a set of new technologies which carry minimal risk individually, could be used in combination for tracking or profiling of web users." Yes? Huge scope increase in the document though and all of a sudden we're now talking about tons of tracking technologies in aggregate? The authors move on without further comment.
Section 4: I think the first half is essentially saying that new technology coming online in the web platform will make the third party cookie problem worse, so we should fix it soon. OK, I'm with back with you. Then the document suddenly pivots to proposing general standards for web privacy again, saying that the burden of proof is on the people originating the proposal to, before concluding by saying (apparently without irony?) that justifying the removal of third-party cookies' impact on business is outside of the scope of the document.
I'm missing a ton of cultural context here about how W3C works, so I'm guessing this probably amounts to rough notes that somebody intends to clean up later that I'm being overly critical of, and they didn't expect it to get any traction on hacker news.