> In some ways, this is a loss—tracking cookies are undeniably terrible, and Google's proposed alternative is better for privacy, at least on paper. However, universal adoption of the Privacy Sandbox could also give Google more power than it already has, and the supposed privacy advantages may never have fully materialized as Google continues to seek higher revenue.
Cookies are much maligned these days, but to defend them a little bit - the alternatives are almost universally worse for user privacy. Persistent session storage? Browser fingerprinting? Locking everything behind a user account with mandatory sign-in? Blegh.
On the other hand, cookies are a pretty transparent interaction. It's a tiny file that sites in your browser. You can look at them. They expire on their own. You as a user can delete, modity, edit, hack them to your heart's content. They contain no PII on their own. They are old-fashioned and limited and that's a good thing.
The real problem here is not the cookie - it's the third party data networks. I would much rather focus our ire on the function rather than the form.
> You as a user can delete, modity, edit, hack them to your heart's content.
This is not true in practice though. Cryptography means they cannot be altered (or even read) if their creator doesn't want them to be altered. Of all the CRUD operations, users can only realiably delete the cookie.
Anything on the ASP.NET stack has it in forms auth tickets and role cookies. You could store additional data in the forms auth one, and it auto-rotates the encryption at half the session length.
One of the best authentication libraries at the time.
Microsoft's developer experience is often world class. If they hadn't burned so much goodwill in the 90s and 2000s through embrace, extend, extinguish, they might have won (or at least stayed relevant) through the Web wars.
It's still hard to trust them today, for me at least.
They used to be the norm in Django, Flask, RoR and ASP.NET, which made up the majority of the non-PHP web. These days database queries are cheap enough that most new sites just use session tokens, but that's also not something you can modify (well, besides transplanting it from a different session).
Many web frameworks like Rails allow you to easily fully encrypt (make unreadable to browser) or sign (make readable but not editable) with a server-side key. Some pen testers will report unsigned or unencrypted cookies so I imagine its quite common.
There's nothing about that that requires JWTs/signed cookies.
You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT.
Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1].
Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies.
It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side.
[1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard.
[2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.
> Of all the CRUD operations, users can only realiably delete the cookie.
I mean, one other operation I can think of is swapping a cookie out for a different one, so you can have two separate sessions managed independently... Which is essentially what Firefox's container tabs are.
But third party cookies are a lot more insidious, because they get sent without any visibility to the user and have generally peripheral relevance to the application they are using. It's like if you go to the supermarket and they ask you if you want to sign up for a loyalty card and you say yes, vs you go to the supermarket and they secretly plant trackers on you so that when you go to other shops they can tell who you are. One is a lot worse than the other.
There is an absurd amount of additional complexity that needs to be centralized in order to avoid third-party cookies.
Any website can add Google Analytics by copy and pasting 1 line of code. To avoid this cookie, you need to have your own analytics web app. This makes sense for medium-size websites, but if you have a small website your host will probably bill it as a separate website.
First-party comments? Now you need your own comment system, which means you have a long list of responsibilities that you simply wouldn't have if you just used Disqus or Facebook comments. All those spam links to virulent sites will be on your servers now.
Honestly, the Internet would be a much more awesome place if 3P cookies were the norm and everyone was okay with embedding everything everywhere. In the past hotlinking was a problem due to bandwidth concerns, but nowadays most of the traffic is bots anyway so it would be a drop in the bucket.
> First-party comments? Now you need your own comment system
This is incorrect. Without 3P cookies widgets like Disqus cannot track (and automatically sign-in) user across different websites, but everything else including posting comments or liking them should work, you just need to sign-in on every website instead of doing it once.
> Any website can add Google Analytics by copy and pasting 1 line of code.
Again incorrect. Google Analytics doesn't need 3P cookies to count the number of visitors. Without 3P cookies it is just harder to correlate visits across different websites, which is what website owners don't really need, why are you supposed to know what competitor sites your users visit? None of your business.
And for cross-site authoriation there are standards like OpenID. So we could disable 3P cookies right now and Internet will work just fine.
>Without 3P cookies widgets like Disqus cannot track (and automatically sign-in) user across different websites, but everything else including posting comments or liking them should work, you just need to sign-in on every website instead of doing it once.
I feel like I don't understand what a 3P cookie is, then. Isn't Disqus a third-party service? Doesn't it use a cookie to know you have signed in?
If you put a Disqus comment form or Google Analytics in your website, wouldn't you need a cookie popup to comply with GDPR and similar regulations that regulate sending user data to third-parties?
Is 3P cookie supposed to be about the domain of the cookie? But then can a script from one domain like GA set a cookie in a different domain like of a website that uses GA? That doesn't sound right, considering you can't do this server side.
Can you help me understand how would it work for it not to be a 3P cookie?
> Isn't Disqus a third-party service? Doesn't it use a cookie to know you have signed in?
Let's say Disqus JS code is embedded on a site A. Then it can set cookies for that domain. So when you enter your Disqus login and password on site A, it can send a request to Disqus server, obtain authorization token and save it in cookies for domain A. This way you will be recognized every time you visit site A.
This means that operators of site A may access those cookies too, but I don't see any problem here - it's their site anyway.
> If you put a Disqus comment form or Google Analytics in your website, wouldn't you need a cookie popup to comply with GDPR and similar regulations that regulate sending user data to third-parties?
Probably you need.
> Is 3P cookie supposed to be about the domain of the cookie?
3P cookie means that when site A includes content from site B (image, iframes) then the browser will send domain B's cookies with the request for that content. This means that if content from site B is included on 100 different websites, site B can track the user across them using cookies.
So when you sign into Disqus, it can recognize (and track your actions) you on any site using Disqus widget.
When 3P cookies are disabled, requests for content embedded from other sites like B, will be anonymous and without cookies. You will have to log into Disqus for every site where you want to leave a comment.
I see. That's a bit ironic. Cookies use useful because you don't need to use URL query parameters all the time. So what they are doing is taking the session token that would be sent in the Disqus domain cookie and storing it as an embedder's cookie, then using Javascript to put the cookie data in URL's / requests. In fact, "cookie" is probably not even a good method to do this since it will get send in embedder's requests. You could just use localstorage for it.
I've always found the negative effects of 3P cookies, the creepiness of being logged in on every site and ads following you around, to be symptoms of other problems (using the same browser profile for everything you do, a culture of not paying for websites so they have to rely on ads for monetization), so I'm not sure if this is a great solution to the actual problems.
But I guess it does make the internet better for the average person.
It's not surprising that there are legit uses like this for 3P cookies, and that the cons probably outweigh the pros. Browsers already stopped allowing cross-site caching for similar reasons years ago, which I'd say comes at a bigger cost.
Yes. My employer uses them to facilitate a widget that site owners can just drop into place. Some of these folks are using platforms they cannot easily change or customize, and/or they cannot manage sophisticated changes.
seamless comment form iframe embeds. Useful for something like blogger, where *.blogspot.com allows user code and thus cannot host the comment form for logged in users
Not anymore since most devices now randomize any Bluetooth identifiers like they do MAC address. Might be a few scenarios it’s possible but it’s been locked down since it made major headlines years ago.
As another user notes above, there are relatively few applications of 3rd party cookies that aren’t a direct privacy violation or that can’t be realized some other way. If the manufacturer installed a special slot on your car that was explicitly designed so that anyone could install a tracking device, the first thing you’d probably do is fill that slot up with epoxy. But when we discuss simply removing that slot as a manufacturer default, everyone on HN is suddenly up in arms: “why are you blaming the third party tracking slot!? The slot itself isn’t what’s tracking you.”
Right. Disabling third party cookies is the first thing I do with any browser (the second being uBlock Origin), and it's caused problems on exactly one site that I can recall over the last several years.
That's because Safari made that default years ago and we've all built workarounds for this anyways. Due to the proliferation of JavaScript and it's being default enabled on all sites or they _will_ break... and the ease of setting up APIs in the cloud.. your privacy settings really don't matter much anymore anyways.
Likewise "autoplay blocking" isn't too hard to overcome. It's more out of politeness that it's ever honored.
I have two browsers on my phone. One is locked down and the other one is vanilla for those rare cases when I absolutely need to experience the internet as intended.
"Sawdust in bread is much maligned these days, but to defend it a little bit, the alternatives are almost universally worse for your health. Sand? Dog poop? Arsenic?"
This article seems to avoid talking about the elephant in the room: Every other browser just blocks third party cookies with no replacement. And Chrome would too if it wasn't owned by an ad company.
This should be the central argument the DOJ uses to separate Chrome from Google: The entire web for a monopoly-size portion of users is massively less secure because the web browser is owned by a company which is very vested in it being less secure.
You have it backwards. Antitrust is the reason Google can't remove cookies. Because it would be anticompetitive toward their competitors in the advertising market. Google has wanted to block third-party cookies for a long time and they can't because they're not allowed to, legally.
The parent commenter is correct: Chrome is blocking third-party cookies if the user chooses that behavior. The only thing that's changed is that they won't be doing it by default, or letting users know about this privacy-protecting option.
From TFA: "Until today, Google was still planning to roll out a dialog in Chrome that would prompt users to turn off third-party cookies in favor of Google's updated solution. […] …Google won't be pushing that cookie dialog to users. You can still choose to disable third-party cookies in Chrome, though."
If the argument is removing third party cookies is detrimental to Google’s competitors then isn’t it just as detrimental after Chrome has been split up?
Google is saying they’re fine with no third party cookies. The rest of the industry needs them.
How do you protect user privacy while also not killing googles competitors? Which need is more important?
If chrome were split out (and subsequently stopped giving Google direct access to user data), Google would need them too. It would impact all ad players equally.
I don't think Google uses data from Chrome this way. I don't think Google actually wants to associate data with people so aggressively. It's obvious when that happens and it feels gross (this is why I stopped using Facebook 10+ years ago, I've never had an equivalent gross-out moment with Google).
I'm guessing the reason google doesn't use third party cookies is because they get higher quality data from people being signed in to Google services, and that is independent of whether they are using Chrome or not.
No, the antitrust argument is Google doesn't need third party tracking because they have a huge amount of first party data and ad inventory from search and YouTube and all their other web products. It's not from Chrome. Their adtech competitors don't have first party inventory or data and would be crushed.
This reminds of how they sorta allow tracking pixels in Gmail, but that's a bit different because Google doesn't benefit from those at all. I'm guessing 3P cookies help Google too.
If Google is successfully forced to divest Chrome, Chrome will no longer be in competition with advertisers. So whether you or I are right about the cause, we should both be able to agree that for privacy reasons, Google must divest Chrome.
I do disagree with your cause and effect though, they have gotten blocked from replacing third party cookies with privacy sandbox because it replaces a standard everyone can use equally with a Google-controlled system. They could have cited the industry standard to block third party cookies in other browsers and done so without a replacement, the reason they are being prohibited from doing so is because they are motivated to maintain data access for themselves via privacy sandbox.
You can read countless statements from the Chrome team about Privacy Sandbox where they state how vital spying on users for ad targeting is, they've never "wanted" to remove doing so.
> They could have cited the industry standard to block third party cookies in other browsers and done so without a replacement, the reason they are being prohibited from doing so is because they are motivated to maintain data access for themselves via privacy sandbox.
This is ignoring the facts. Last summer it was made clear that no privacy-increasing replacement for 3p cookies was going to be acceptable to the CMA.
So Google's announced plan was to make 3p cookies an opt-in feature, with a dialog forcing users to make the choice. That plan was not conditional on any of the privacy sandbox replacement mechanisms. (Your guess is as good as mine for what option the average user would choose when forced to.)
But clearly even informing the users and having them make a choice was unacceptable to the CMA.
And no, they cannot just act unilaterally citing precedence in other browsers like you study. Regulators aren't going around threatening to break up Apple or Mozilla, so they get to do whatever they want. Google does not have that luxury.
(And none of the privacy sandbox projects for ad targeting without 3p cookies was giving Google some additional data source denied from other advertisers, like you claim.)
Chrome is not in competition with advertisers. If Google divests Chrome and Chrome removes third party cookies as a result, Google's adtech competitors will be crushed just as effectively as if Google removed third party cookies themselves. Google would survive just fine because they have lots of first party ad inventory and data, and all their adtech competition would be gone. This is the exact opposite of what the antitrust suit is trying to achieve.
Those statements about tracking you're referencing are legal shielding against antitrust suits from adtech competitors.
This suggestion that they don't need a replacement for third party cookies seems to directly contradict the number of attempts they've made to develop themselves a replacement. How do you square that belief?
The alternatives are designed to replace the function of third party cookies for Google's competitors to address their antitrust concerns and unblock removing third party cookies in Chrome which, as I said, Google wanted to do. Obviously the effort was unsuccessful.
Google was attacked on both sides, on the one hand by adtech who objected to being forced by Google to use something less powerful than third party cookies, and on the other hand by other browser vendors who objected to adding adtech features and certainly didn't have any interest in helping Google avoid their antitrust problem, regardless of the fact that enabling Google to turn off third party cookies would be the better privacy outcome for users of Chrome. They had no interest in helping Chrome users; they preferred to promote alternatives instead.
> Google has wanted to block third-party cookies for a long time and they can't because they're not allowed to, legally.
There's no reason they couldn't allow add-ons to do it: but instead with manifest v3 I think it is impossible to do it in a general way isn't it? Like with the other ad-blocking you have to have a hardcoded number of rules you can define for blocking cookies in the requests as well, at least through the declarativeNetRequest API.
Maybe it is possible for through one of the cookies APIs, but the cookie's API has race conditions where the site can still sometimes see them from what I understand and redirects can activate before your extension gets a chance to respond.
And then of course extensions don't even run on mobile and that isn't an accident.
Another assurance Google made was that the User-Agent HTTP header is being phased out, or at least rendered obsolete. It sure seems like this header is in heavy usage for a variety of online advertising related purposes. Time will tell if anyone should take Google's forecasting of the future seriously.
So basically Google added additional tracking and fingerprinting features (so called "Privacy Sandbox") as a replacement for 3P cookies, but decided not to remove them after all.
I think that independent from Google browser vendors should 1) stop adopting any APIs that extend fingerprinting surface and 2) gradually lock down APIs that allow fingerprinting by putting them behind permissions.
> Google has been heartened to see the advertising industry taking privacy more seriously. As a result, Google won't be pushing that cookie dialog to users.
The advertising industry never ever cared about anyone’s privacy. Quite the opposite.
Same for Google, Google is a company. It cares about money income, that’s all. This change gave them even more control on the web.
They just had too much pushback from the advertising industry and a wrong timeline with the DOJ and the antitrust lawsuit. That’s the reason they canceled their plan, anything else is PR BULLCRAP.
I'm not sure I've ever understood the point of this.
Aren't all cookies trivially "any-party" cookies? Can't any form of persistence be used to track a user? 3rd-party cookies as they exist today just give a path of least resistance so that most of that behavior is implemented the same way. Consistent implementation allows the user a simple way to block that behavior.
The only somewhat good use for third-party cookies is various embeds and comment widgets. It wouldn't be all that much of a loss for the users if third-party cookies were removed without a replacement, but with the developer of the world's most popular web browser and the world's most popular mobile OS also being the world's richest internet advertising company, that's apparently an absolute impossibility ¯\_(ツ)_/¯
> In some ways, this is a loss—tracking cookies are undeniably terrible, and Google's proposed alternative is better for privacy, at least on paper. However, universal adoption of the Privacy Sandbox could also give Google more power than it already has, and the supposed privacy advantages may never have fully materialized as Google continues to seek higher revenue.
Cookies are much maligned these days, but to defend them a little bit - the alternatives are almost universally worse for user privacy. Persistent session storage? Browser fingerprinting? Locking everything behind a user account with mandatory sign-in? Blegh.
On the other hand, cookies are a pretty transparent interaction. It's a tiny file that sites in your browser. You can look at them. They expire on their own. You as a user can delete, modity, edit, hack them to your heart's content. They contain no PII on their own. They are old-fashioned and limited and that's a good thing.
The real problem here is not the cookie - it's the third party data networks. I would much rather focus our ire on the function rather than the form.
> You as a user can delete, modity, edit, hack them to your heart's content.
This is not true in practice though. Cryptography means they cannot be altered (or even read) if their creator doesn't want them to be altered. Of all the CRUD operations, users can only realiably delete the cookie.
I gotta ask: how many cryptographically secure cookies have you encountered? In theory, yes. In practice? That's kind of expensive.
Anything on the ASP.NET stack has it in forms auth tickets and role cookies. You could store additional data in the forms auth one, and it auto-rotates the encryption at half the session length.
One of the best authentication libraries at the time.
ASP.NET is so underrated. It's by far the most comprehensive and adaptable web framework I've ever encountered.
Microsoft's developer experience is often world class. If they hadn't burned so much goodwill in the 90s and 2000s through embrace, extend, extinguish, they might have won (or at least stayed relevant) through the Web wars.
It's still hard to trust them today, for me at least.
The fact that we're both being downvoted without a reply/explanation is a testament to that, it seems :(
I can't imagine anyone who's actually used it responding that way.
Storing JWTs as cookies is not that rare in practice.
As far as preventing editing, but not reading, JWTs are very common.
They used to be the norm in Django, Flask, RoR and ASP.NET, which made up the majority of the non-PHP web. These days database queries are cheap enough that most new sites just use session tokens, but that's also not something you can modify (well, besides transplanting it from a different session).
Many web frameworks like Rails allow you to easily fully encrypt (make unreadable to browser) or sign (make readable but not editable) with a server-side key. Some pen testers will report unsigned or unencrypted cookies so I imagine its quite common.
Rails encrypts them too, or sign them, one of the two. Either way, you cannot tamper them
If you wanna do any kind of restful service securely you need to sign your data.
There's nothing about that that requires JWTs/signed cookies.
You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT.
Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1].
Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies.
It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side.
[1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard.
[2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.
> Of all the CRUD operations, users can only realiably delete the cookie.
I mean, one other operation I can think of is swapping a cookie out for a different one, so you can have two separate sessions managed independently... Which is essentially what Firefox's container tabs are.
first party cookies yes
But third party cookies are a lot more insidious, because they get sent without any visibility to the user and have generally peripheral relevance to the application they are using. It's like if you go to the supermarket and they ask you if you want to sign up for a loyalty card and you say yes, vs you go to the supermarket and they secretly plant trackers on you so that when you go to other shops they can tell who you are. One is a lot worse than the other.
Is there a legitimate use case for 3P cookies?
There is an absurd amount of additional complexity that needs to be centralized in order to avoid third-party cookies.
Any website can add Google Analytics by copy and pasting 1 line of code. To avoid this cookie, you need to have your own analytics web app. This makes sense for medium-size websites, but if you have a small website your host will probably bill it as a separate website.
First-party comments? Now you need your own comment system, which means you have a long list of responsibilities that you simply wouldn't have if you just used Disqus or Facebook comments. All those spam links to virulent sites will be on your servers now.
Honestly, the Internet would be a much more awesome place if 3P cookies were the norm and everyone was okay with embedding everything everywhere. In the past hotlinking was a problem due to bandwidth concerns, but nowadays most of the traffic is bots anyway so it would be a drop in the bucket.
> First-party comments? Now you need your own comment system
This is incorrect. Without 3P cookies widgets like Disqus cannot track (and automatically sign-in) user across different websites, but everything else including posting comments or liking them should work, you just need to sign-in on every website instead of doing it once.
> Any website can add Google Analytics by copy and pasting 1 line of code.
Again incorrect. Google Analytics doesn't need 3P cookies to count the number of visitors. Without 3P cookies it is just harder to correlate visits across different websites, which is what website owners don't really need, why are you supposed to know what competitor sites your users visit? None of your business.
And for cross-site authoriation there are standards like OpenID. So we could disable 3P cookies right now and Internet will work just fine.
>Without 3P cookies widgets like Disqus cannot track (and automatically sign-in) user across different websites, but everything else including posting comments or liking them should work, you just need to sign-in on every website instead of doing it once.
I feel like I don't understand what a 3P cookie is, then. Isn't Disqus a third-party service? Doesn't it use a cookie to know you have signed in?
If you put a Disqus comment form or Google Analytics in your website, wouldn't you need a cookie popup to comply with GDPR and similar regulations that regulate sending user data to third-parties?
Is 3P cookie supposed to be about the domain of the cookie? But then can a script from one domain like GA set a cookie in a different domain like of a website that uses GA? That doesn't sound right, considering you can't do this server side.
Can you help me understand how would it work for it not to be a 3P cookie?
> Isn't Disqus a third-party service? Doesn't it use a cookie to know you have signed in?
Let's say Disqus JS code is embedded on a site A. Then it can set cookies for that domain. So when you enter your Disqus login and password on site A, it can send a request to Disqus server, obtain authorization token and save it in cookies for domain A. This way you will be recognized every time you visit site A.
This means that operators of site A may access those cookies too, but I don't see any problem here - it's their site anyway.
> If you put a Disqus comment form or Google Analytics in your website, wouldn't you need a cookie popup to comply with GDPR and similar regulations that regulate sending user data to third-parties?
Probably you need.
> Is 3P cookie supposed to be about the domain of the cookie?
3P cookie means that when site A includes content from site B (image, iframes) then the browser will send domain B's cookies with the request for that content. This means that if content from site B is included on 100 different websites, site B can track the user across them using cookies.
So when you sign into Disqus, it can recognize (and track your actions) you on any site using Disqus widget.
When 3P cookies are disabled, requests for content embedded from other sites like B, will be anonymous and without cookies. You will have to log into Disqus for every site where you want to leave a comment.
I see. That's a bit ironic. Cookies use useful because you don't need to use URL query parameters all the time. So what they are doing is taking the session token that would be sent in the Disqus domain cookie and storing it as an embedder's cookie, then using Javascript to put the cookie data in URL's / requests. In fact, "cookie" is probably not even a good method to do this since it will get send in embedder's requests. You could just use localstorage for it.
I've always found the negative effects of 3P cookies, the creepiness of being logged in on every site and ads following you around, to be symptoms of other problems (using the same browser profile for everything you do, a culture of not paying for websites so they have to rely on ads for monetization), so I'm not sure if this is a great solution to the actual problems.
But I guess it does make the internet better for the average person.
It's not surprising that there are legit uses like this for 3P cookies, and that the cons probably outweigh the pros. Browsers already stopped allowing cross-site caching for similar reasons years ago, which I'd say comes at a bigger cost.
Disqus hasn't needed third party cookies for a long time.
This was the example I thought of too. Somehow they got around it, I thought using iframes or whatever is the newer replacement for them.
Then again I'm surprised by something broken in iframes every single time I use them, and last time was years ago, so...
Yes. My employer uses them to facilitate a widget that site owners can just drop into place. Some of these folks are using platforms they cannot easily change or customize, and/or they cannot manage sophisticated changes.
Ah, and I'm guessing this could instead be done with an iframe but it would be ugly.
It would still require 3P cookies.
Cross domain same identity authentication, but this has been worked around in most cases.
Only in places where you trust the domains.
seamless comment form iframe embeds. Useful for something like blogger, where *.blogspot.com allows user code and thus cannot host the comment form for logged in users
Lots of the usecases for CORS are also use cases for third party cookies (anytime you set withCredentials = true)
Re the supermarkets - I understand this happens in a limited way already with bluetooth scanning :/
Not anymore since most devices now randomize any Bluetooth identifiers like they do MAC address. Might be a few scenarios it’s possible but it’s been locked down since it made major headlines years ago.
Your phone yes, but I believe there's still issues with peripheral BT devices
And cameras…
Blaming privacy violations on cookies has been an absolute masterclass in public relations and is probably the greatest innovation of FANNG.
As another user notes above, there are relatively few applications of 3rd party cookies that aren’t a direct privacy violation or that can’t be realized some other way. If the manufacturer installed a special slot on your car that was explicitly designed so that anyone could install a tracking device, the first thing you’d probably do is fill that slot up with epoxy. But when we discuss simply removing that slot as a manufacturer default, everyone on HN is suddenly up in arms: “why are you blaming the third party tracking slot!? The slot itself isn’t what’s tracking you.”
Right. Disabling third party cookies is the first thing I do with any browser (the second being uBlock Origin), and it's caused problems on exactly one site that I can recall over the last several years.
That's because Safari made that default years ago and we've all built workarounds for this anyways. Due to the proliferation of JavaScript and it's being default enabled on all sites or they _will_ break... and the ease of setting up APIs in the cloud.. your privacy settings really don't matter much anymore anyways.
Likewise "autoplay blocking" isn't too hard to overcome. It's more out of politeness that it's ever honored.
I have two browsers on my phone. One is locked down and the other one is vanilla for those rare cases when I absolutely need to experience the internet as intended.
[flagged]
Man this reminds me a lot of bank fraud, er… I meant “identity theft”!
> They expire on their own.
I have been looking them and yes, in 50 years…
"Sawdust in bread is much maligned these days, but to defend it a little bit, the alternatives are almost universally worse for your health. Sand? Dog poop? Arsenic?"
well if you want cheap bread, something has got to give.
Related:
Google scraps plan to remove third-party cookies from Chrome (26 points, 9 months ago, 3 comments) https://news.ycombinator.com/item?id=41046637
Chrome is entrenching third-party cookies that will mislead users (511 points, 8 months ago, 311 comments) https://news.ycombinator.com/item?id=41391412
What Google's U-Turn on Third-Party Cookies Means for Chrome Privacy (3 points, 7 months ago) https://news.ycombinator.com/item?id=41788239
This article seems to avoid talking about the elephant in the room: Every other browser just blocks third party cookies with no replacement. And Chrome would too if it wasn't owned by an ad company.
This should be the central argument the DOJ uses to separate Chrome from Google: The entire web for a monopoly-size portion of users is massively less secure because the web browser is owned by a company which is very vested in it being less secure.
You have it backwards. Antitrust is the reason Google can't remove cookies. Because it would be anticompetitive toward their competitors in the advertising market. Google has wanted to block third-party cookies for a long time and they can't because they're not allowed to, legally.
The parent commenter is correct: Chrome is blocking third-party cookies if the user chooses that behavior. The only thing that's changed is that they won't be doing it by default, or letting users know about this privacy-protecting option.
From TFA: "Until today, Google was still planning to roll out a dialog in Chrome that would prompt users to turn off third-party cookies in favor of Google's updated solution. […] …Google won't be pushing that cookie dialog to users. You can still choose to disable third-party cookies in Chrome, though."
Nothing you said is in contradiction with what I said. Antitrust law is what prevents Google from default blocking third party cookies in Chrome.
Then you agree that Chrome should be divorced from Google, so that Google is no longer forced into such a position?
If the argument is removing third party cookies is detrimental to Google’s competitors then isn’t it just as detrimental after Chrome has been split up?
Google is saying they’re fine with no third party cookies. The rest of the industry needs them.
How do you protect user privacy while also not killing googles competitors? Which need is more important?
Killing Google's competitors would be a good thing but only if Google was also killed at the same time. The differential is the problem.
If chrome were split out (and subsequently stopped giving Google direct access to user data), Google would need them too. It would impact all ad players equally.
I don't think Google uses data from Chrome this way. I don't think Google actually wants to associate data with people so aggressively. It's obvious when that happens and it feels gross (this is why I stopped using Facebook 10+ years ago, I've never had an equivalent gross-out moment with Google).
I'm guessing the reason google doesn't use third party cookies is because they get higher quality data from people being signed in to Google services, and that is independent of whether they are using Chrome or not.
Yea correct. They have numerous other ways of identifying you or fingerprinting you that cookies aren't all that important anymore.
No, the antitrust argument is Google doesn't need third party tracking because they have a huge amount of first party data and ad inventory from search and YouTube and all their other web products. It's not from Chrome. Their adtech competitors don't have first party inventory or data and would be crushed.
This reminds of how they sorta allow tracking pixels in Gmail, but that's a bit different because Google doesn't benefit from those at all. I'm guessing 3P cookies help Google too.
They’ve already been found guilty of antitrust, so what do they have to lose?
Honestly I’m surprised Google hasn’t offered to buy Truth Social for a few hundred million just to make this little antitrust problem go away.
If Google is successfully forced to divest Chrome, Chrome will no longer be in competition with advertisers. So whether you or I are right about the cause, we should both be able to agree that for privacy reasons, Google must divest Chrome.
I do disagree with your cause and effect though, they have gotten blocked from replacing third party cookies with privacy sandbox because it replaces a standard everyone can use equally with a Google-controlled system. They could have cited the industry standard to block third party cookies in other browsers and done so without a replacement, the reason they are being prohibited from doing so is because they are motivated to maintain data access for themselves via privacy sandbox.
You can read countless statements from the Chrome team about Privacy Sandbox where they state how vital spying on users for ad targeting is, they've never "wanted" to remove doing so.
> They could have cited the industry standard to block third party cookies in other browsers and done so without a replacement, the reason they are being prohibited from doing so is because they are motivated to maintain data access for themselves via privacy sandbox.
This is ignoring the facts. Last summer it was made clear that no privacy-increasing replacement for 3p cookies was going to be acceptable to the CMA.
So Google's announced plan was to make 3p cookies an opt-in feature, with a dialog forcing users to make the choice. That plan was not conditional on any of the privacy sandbox replacement mechanisms. (Your guess is as good as mine for what option the average user would choose when forced to.)
But clearly even informing the users and having them make a choice was unacceptable to the CMA.
And no, they cannot just act unilaterally citing precedence in other browsers like you study. Regulators aren't going around threatening to break up Apple or Mozilla, so they get to do whatever they want. Google does not have that luxury.
(And none of the privacy sandbox projects for ad targeting without 3p cookies was giving Google some additional data source denied from other advertisers, like you claim.)
Chrome is not in competition with advertisers. If Google divests Chrome and Chrome removes third party cookies as a result, Google's adtech competitors will be crushed just as effectively as if Google removed third party cookies themselves. Google would survive just fine because they have lots of first party ad inventory and data, and all their adtech competition would be gone. This is the exact opposite of what the antitrust suit is trying to achieve.
Those statements about tracking you're referencing are legal shielding against antitrust suits from adtech competitors.
This suggestion that they don't need a replacement for third party cookies seems to directly contradict the number of attempts they've made to develop themselves a replacement. How do you square that belief?
The alternatives are designed to replace the function of third party cookies for Google's competitors to address their antitrust concerns and unblock removing third party cookies in Chrome which, as I said, Google wanted to do. Obviously the effort was unsuccessful.
Google was attacked on both sides, on the one hand by adtech who objected to being forced by Google to use something less powerful than third party cookies, and on the other hand by other browser vendors who objected to adding adtech features and certainly didn't have any interest in helping Google avoid their antitrust problem, regardless of the fact that enabling Google to turn off third party cookies would be the better privacy outcome for users of Chrome. They had no interest in helping Chrome users; they preferred to promote alternatives instead.
> Google has wanted to block third-party cookies for a long time and they can't because they're not allowed to, legally.
There's no reason they couldn't allow add-ons to do it: but instead with manifest v3 I think it is impossible to do it in a general way isn't it? Like with the other ad-blocking you have to have a hardcoded number of rules you can define for blocking cookies in the requests as well, at least through the declarativeNetRequest API.
Maybe it is possible for through one of the cookies APIs, but the cookie's API has race conditions where the site can still sometimes see them from what I understand and redirects can activate before your extension gets a chance to respond.
And then of course extensions don't even run on mobile and that isn't an accident.
Ah.. I was wondering why they would even bother with something like Related Web Sets. https://privacysandbox.google.com/cookies/related-website-se...
I guess that was going to be too insane to actually manage.
FWIW, Edge does not block third party cookies yet, although they are experimenting with it.
https://blogs.windows.com/msedgedev/2024/03/05/new-privacy-p...
Another assurance Google made was that the User-Agent HTTP header is being phased out, or at least rendered obsolete. It sure seems like this header is in heavy usage for a variety of online advertising related purposes. Time will tell if anyone should take Google's forecasting of the future seriously.
Even if Google won't disable third-party cookies in Chrome, you still can!
chrome://settings/cookies
So basically Google added additional tracking and fingerprinting features (so called "Privacy Sandbox") as a replacement for 3P cookies, but decided not to remove them after all.
I think that independent from Google browser vendors should 1) stop adopting any APIs that extend fingerprinting surface and 2) gradually lock down APIs that allow fingerprinting by putting them behind permissions.
> Google has been heartened to see the advertising industry taking privacy more seriously. As a result, Google won't be pushing that cookie dialog to users.
The advertising industry never ever cared about anyone’s privacy. Quite the opposite.
Same for Google, Google is a company. It cares about money income, that’s all. This change gave them even more control on the web.
They just had too much pushback from the advertising industry and a wrong timeline with the DOJ and the antitrust lawsuit. That’s the reason they canceled their plan, anything else is PR BULLCRAP.
Google talking about the advertising industry as something external to itself sure is something.
I'm not sure I've ever understood the point of this.
Aren't all cookies trivially "any-party" cookies? Can't any form of persistence be used to track a user? 3rd-party cookies as they exist today just give a path of least resistance so that most of that behavior is implemented the same way. Consistent implementation allows the user a simple way to block that behavior.
So turn them off by default, and whitelist the ones that are necessary. It was always a stupid idea to get rid of them completely.
[dupe] https://news.ycombinator.com/item?id=43764062
weird stuff happen when an advertising company is making web browsers. Anti-trust should happen faster to stop the monopoly
The only somewhat good use for third-party cookies is various embeds and comment widgets. It wouldn't be all that much of a loss for the users if third-party cookies were removed without a replacement, but with the developer of the world's most popular web browser and the world's most popular mobile OS also being the world's richest internet advertising company, that's apparently an absolute impossibility ¯\_(ツ)_/¯
Not surprising. Chrome is deeply compromised by Google's incentives.