Good enough for me. Chrome's implementation of partitioned cookies does not work for our use-case, though Firefox's implementation works well. Google has still got some work to do before they go ahead and break everyone's web apps, in my opinion: https://github.com/privacycg/CHIPS/issues/82
Google delays third-party cookie demise yet again
101–110 of 112 posts
Re: Google delays third-party cookie demise yet again
#102Dear CMA, Can you please let Google do the right thing and disable third party cookies like every other browser vendor.
Re: Google delays third-party cookie demise yet again
#103I am not convinced this is ever going to actually happen. Google won't roll this out until they are sure that their new solution basically has the same effect for advertisers as cookies, but with a new fancy name with "privacy" in it (when its anything but). Google needs to be forced to spin out Chrome to someone else, it is a clear conflict of interest when nearly every (or every? are there any that haven't?) other…
Google actually has interest for new solution having weak performance, since it will shift Ads funds from 3p sites to their own properties(search, youtube, maps) where 3p are not as critical.
Re: Google delays third-party cookie demise yet again
#104If they had just not added this tracking vector in the first place this would not be something to debate.
Re: Google delays third-party cookie demise yet again
#105All Google had to do was not enable 3rd party cookies in chrome. Safari and WebKit by default have always blocked 3rd party cookies by default - literally from day 1 - but google added support for them and enabled them by default because their business model requires spying on users. If they had just not added this tracking vector in the first place this would not be something to debate.
Did Safari also originally enable third party cookies by default for the purpose of enabling spying on its users?
Re: Google delays third-party cookie demise yet again
#106All Google had to do was not enable 3rd party cookies in chrome. Safari and WebKit by default have always blocked 3rd party cookies by default - literally from day 1 - but google added support for them and enabled them by default because their business model requires spying on users. If they had just not added this tracking vector in the first place this would not be something to debate.
Literally from day 6,286: https://webkit.org/blog/10218/full-third-party-cookie-blocki... Did Safari also originally enable third party cookies by default for the purpose of enabling spying on its users?
3rd party cookies are the original way advertising companies spied on users, and the only way the vast majority of companies can spy on you. What they do is make is so that when you request a resource you can attach cookies to the request that are not from the domain making the request, so that if you have multiple unrelated sites requesting https://advertiser.com/resource they will share the same cookies and allow the operator of advertiser.com to uniquely identify the same user regardless of the site actually being visited. Wikipedia has a big page on this specific technical concept: https://en.wikipedia.org/wiki/Third-party_cookies
This is what a "3rd party cookie" is in the context of blocking "3rd party cookies", and this is what more or less every browser other than chrome now does (except maybe edge?). Safari has had blocking 3rd party cookies be the default behavior since the very first betas. It was the first browser to do this by years, to this day I'm not sure why Firefox didn't immediately follow suit, but that's something best answered by someone from Mozilla of the era.
The article you're pointing to is discussing a further hardening of the restrictions, ITP, and origin based cookie segregation. These are all increases in the degree to which cookies are blocked, and these are necessary specifically to deal with privacy invasive tracking that companies like google and Facebook are able to do.
For the overwhelming majority of tracking networks simply blocking 3rd party cookies is sufficient. But over the last decade or so companies like Google have aggressively introduced new mechanisms to promote their 3rd party cookies into the sets that can be shared. Google has been very aggressive in this by working extremely hard to get as many webdevs as possible to add spyware to their pages to get "metrics".
There are numerous steps they take - redirect loops were in vogue for a while, i'm not sure what they're doing now - basically trying to either link a cookie from the domain embedding the tracking code to a cookie on the advertisers domain, or promote the "3rd party" domain into being part of the primary site. Defeating that requires cookie segregation (so that every site you visit has a different cookie vault for every different origin it contacts), and things like "tracking protection" which tries to detect sites that are being pinged from many different origins (implying they're for tracking rather than site content) and severely curtailing any cookies for those origins.
The post you linked to is talking about that, and it sounds like an end game step which is that loads to any resource from a different origin gets no cookie state at all, which historically didn't seem possible due to many weird ways sites managed account login and the like but maybe things have changed since then.
This world of cookie segregation and tracking prevention is _significantly_ stricter and more powerful protection, and is far beyond the "3rd party cookie blocking" that google is still delaying to this day, and has been something safari and Firefox have been doing for years, but it came after, and in response to, companies like google trying to circumvent the privacy provided by 3rd party cookie blocking.
This is also why google is now talking about blocking 3rd party cookies - they've spent more than a decade come up with ways to track people in spite of 3rd party cookie blocking, and they have no implemented any of the privacy protections Firefox and safari have been shipping for years (nor is chrome likely to implement anything of the kind). Google (and FB, etc) are in a position where they can do this, but smaller advertising networks can't (google has tracking code on almost every page as part of their "we'll provide you with analytics/metrics" scam).
Re: Google delays third-party cookie demise yet again
#107I pay for Youtube Premium, which uses third-party cookies to not show ads on embedded videos. https://privacysandbox.com talks about advertising, but not "logged in elsewhere" functionality. Does Youtube or Google have something ready, or will all Youtube Premium subscribers see ads on embedded videos?
> Youtube Premium, which uses third-party cookies to not show ads on embedded videos The third party cookies don't control ads in embedded videos, there are currently no ads in embedded videos whether you have paid for premium or not. I have a bookmarklet that converts a youtube page to an embed for this reason, for when I get sick of seeing the same couple of adverts on a loop.
https://support.google.com/youtube/answer/132596
>Ads appear on brand safe sites: YouTube works diligently so that our advertisers' brands appear on sites that reflect our respective core values. Our systems closely evaluate websites and their content against various factors when finding out whether to turn on In-stream ads on YouTube embeds. These factors include a strict set of guidelines on content like adult imagery, violence, inappropriate and hateful language, and sites that promote infringement.
Re: Google delays third-party cookie demise yet again
#108Earlier quoted context omitted.
Pure speculation, but maybe there's more to this. If Teams refuses to work in Chrome, it might drive run of the mill employees to Edge?
That seems a bit too conspiracy theorist, especially considering most people have 3rd party cookies on and teams has been around for a long time now (I assume before Google announced removing 3rd party cookies) I think the answer is more banal in that some of their oauth flow runs in a different domain from the main application. I think this is tied to wanting to reuse part of oauth flow in the desktop application.
Remember "DOS Isn’t Done Until Lotus Won’t Run"?
That large companies do self-serving underhanded tricks is not a conspiracy, just yet another Monday in the office.
Re: Google delays third-party cookie demise yet again
#109Earlier quoted context omitted.
Literally from day 6,286: https://webkit.org/blog/10218/full-third-party-cookie-blocki... Did Safari also originally enable third party cookies by default for the purpose of enabling spying on its users?
I was going to make a snarky comment, but I realized it's possible you just don't know how cookies, 3rd party or otherwise, work. 3rd party cookies are the original way advertising companies spied on users, and the only way the vast majority of companies can spy on you. What they do is make is so that when you request a resource you can attach cookies to the request that are not from the domain making the request, so…
In Safari, if you loaded a pixel from https://advertiser.com/resource that was referenced on different sites, advertiser.com would get the same cookie. This is still true. What blocking third party cookies means is that advertiser.com can't set a cookie when its pixel is loaded from another website. Safari didn't even think to implement it until Chrome announced that they would do it and worked with web publishers to migrate away. As far as sending cookies to a different origin, Safari didn't even support the SameSite attribute until 2019, three years after Chrome and one year after Firefox. It's not for nothing that Safari gained its reputation for being slow at adopting web standards.
Re: Google delays third-party cookie demise yet again
#110Earlier quoted context omitted.
Defaults matter. 95% of people don't change defaults.
Chrome is not the default on anything other than android and ChromeOS. Yet it's quite popular to use chrome on Mac, Windows, Linux, and iOS.