Preparing for the end of third-party cookies

https://developer.chrome.com/blog/cookie-countdown-2023oct/

by mooreds • 3 years ago

67 57 3 years ago

developer.chrome.com

ivanjermakov• 3 years ago

Will this make annoying cookie banners go away?

7734128• 3 years ago

We'll probably either be forced to agree to be tracked by Google's systems or forced to sign in to every page.

There's no chance that anything positive will ever happen with the web again, it has gotten worse at every step for more than a decade. Especially when Google has any involvement with it.

parineum• 3 years ago

All the things that led to getting rid of flash player have been pretty great. CSS is pretty incredible compared to what it used to be. JavaScript is still a train wreck but web assembly holds some promise there. WebGL is also pretty great.

dangus2• 3 years ago

I’m confused at where we jump to the conclusion that we’ll be forced to sign in to Google’s systems or sign in to every page. How specifically does that come about?

underdeserver2• 3 years ago

I don't think so - those would be first-party cookies.

jeroenhd• 3 years ago

Most cookies in those popups are third-party cookies, at least for websites with giant lists of third party cookies that require Consent-O-Matic to properly disable. Website relying on first-party cookies are usually rather unobtrusive,

0x073• 3 years ago

wilde• 3 years ago

Nope. Those are permanently part of the internet now, even if the reason for their existence goes away.

jefftk3• 3 years ago

No. Cookie banners cover any use of client size storage. That includes things like shopping carts and personalization (purely first party), analytics ("first party"), and ads (usually "third party").

Part of what's confusing here is that "first party" and "third party" are being used in a technical sense to mean which domain the cookies are set on. If on an example.com page JS from example.net causes a cookie to be set on example.com that's "first party", while if the cookie is set on any other domain that's "third party".

Nextgrid3• 3 years ago

Shopping carts (and other purely-functional, essential purposes) do not require a consent popup.

janosd• 3 years ago

No. The cookie banners have nothing to do with cookies per se, they are a consent / information popup required if companies want to store and use personal data beyond what's required to serve you with the website content (GDPR) or they want to store non-essential identifiers on your device (ePrivacy directive).

In other words, you are seeing these because marketing departments need BS metrics that measure nothing and are based on some personal data. The internet can happily exist without them as proven by Github[1].

[1] https://github.blog/2020-12-17-no-cookie-for-you/

Sytten• 3 years ago

This will break so many things, that's not even funny. I can already hear customers complain their bank doesn't work on chrome. Maybe this will drive Firefox adoption? (Let me dream please)

infotogivenm2• 3 years ago

I believe third-party cookies have been blocked on Safari and FF by default for many years

cpeterso• 3 years ago

Safari blocks third-party cookies by default and introduced a new Storage Access SPI so third-party sites that do need cookies can request explicit user permission. This is all part of Safari’s Intelligent Tracking Protection.

Firefox doesn’t block third-party cookies by default because that can break sites that haven’t been updated to use the Storage Access API. Instead Firefox’s Enhanced Tracking Protection blocks cookies from a blocklist of known trackers and all other third-party cookies (e.g. new trackers or legitimate use cases) are isolated using Total Cookie Protection (which has the inconvenient acronym TCP).

Total Cookie Protection uses double-keyed cookie jars, so cookies from analytics.example included in an example.com page are placed in a separate cookie jar from analytics.example cookies included in an example.org page. This allows both sites to use the same third-party analytics service, but the analytics service sees different cookies for each site and can’t link the cookies to one user’s browsing behavior.

https://blog.mozilla.org/en/products/firefox/firefox-rolls-o...

BertoldVdb• 3 years ago

It only covers third party cookies, not cookies in general. They aren't used that much except for ad tracking. For the few other use cases that exist the offered workarounds are pretty good and more secure than a general wide cookie.

kevin_thibedeau• 3 years ago

Google uses them to be able to download anything from Drive. Looking forward to that being fixed.

SkyMarshal• 3 years ago

The article lists numerous alternatives to replace functionality that 3rd party cookies currently provide. But is there anything that prevents third-party analytics and similar services from creating libraries or services that are deployed under their clients' domain, and then transmit the collected data from client site to third-party service's own database?

For example, instead of an embed link like:

https://allurdataarebelongtous.xyz/collectitall

collecting visitor data on:

https://myhometownnewspaper.com/

It's replaced by:

https://myhometownnewspaper.com/allurdataarebelongtous/colle...

Is that possibility going away too, or is it still a loophole? I ask b/c if it remains, it may be easier to implement than some of the alternatives, and it may become more difficult for browser plugins like uMatrix, NoScript, etc. to identify and block these services, especially if they allow the client to customize or obfuscate the embed link.

infotogivenm2• 3 years ago

The point of killing third party cookies is to prevent a tracking identifier cookie that uniquely identifies your browser from being reused across different sites.

So you can of course host your own scripts and run them on your own origin, lets call it site1.com. But when your site1.com includes a third party iframe to e.g. googleanalytics.com, and that frame sets a cookie on itself, the cookie is now silently dropped. Then when site2.com later includes the googleanalytics.com frame, the frame cannot immediately link the two browsers. There are other ways to “link” browsers across origins, like browser fingerprinting or in many cases just IP, but they are not usually guaranteed to be 100% reliable.

Blocking third party cookies is standard obvious privacy functionality, but google has held out because it affects their bottom line. So IIUIC they had to wait until they implemented something that protects their bottom line (the chrome-only “privacy sandbox”).

google234123• 3 years ago

What do you mean, anti trust people immediately went after Google for removing 3rd party cookies. Can't win...

lucaspiller• 3 years ago

Actually fingerprinting is pretty reliable:

https://amiunique.org/fingerprint

flower-giraffe• 3 years ago

That’s exactly what meta/facebook have been facilitating https://developers.facebook.com/docs/marketing-api/conversio...

hn_throwaway_99• 3 years ago

But is there anything that prevents third-party analytics and similar services from creating libraries or services that are deployed under their clients' domain, and then transmit the collected data from client site to third-party service's own database?

No, because to do this unambiguously is simply impossible. It is fundamentally always technically possible for your own site to track user behavior of people on your site (what's to say what's "tracking" versus simply serving site page data), and there is no technical way to prevent a site owner from simply sharing their own tracking data with data aggregators. There are of course some heuristics that tracking blockers could use (e.g. "Even though this script is served from somesite.com, it looks like the Facebook tracking code"), but that just becomes a cat-and-mouse game to obfuscate the script.

That's a big reason I feel this "third party cookie blocking" was just oversold. Adding third party cookies was just technically easy because it just involved adding a simple JS snippet to a page, but serving that snippet from one's own domain is still pretty trivial, and indeed what most of the big ad brokers are moving toward.

amf122• 3 years ago

serving that snippet from one's own domain is still pretty trivial, and indeed what most of the big ad brokers are moving toward

But in this case it's not as trivial to link usage across two domains. Sure, each domain can serve the snippet from its own domain, but the analytics snippet can't cross reference data from other sites which use the same script (unless of course the domain builds some data sharing mechanism - not trivial for non tech companies).

In which case why even serve the snippet form your domain when you can use the container mechanism.

justrealist2• 3 years ago

Yeah all adtech players are going this way but it's only useful when the publisher has primarily logged-in users. Otherwise there's still no way to link you across sites.

fyokdrigd3• 3 years ago

that's why chrome have that nice little picture of your google profile on there ui. you're always logged at google.

1vuio0pswjnm7• 3 years ago

If I understand correctly this requires a shift from avoiding certain domains to avoiding certain URLs.

At present myhometownnewspaper.com, i.e., newspapers, generally have a robots.txt which lists a "sitemap.xml". The sitemap should list all the articles but will not list /allurdatabelongtous.

Ads and analytics URLs do not appear in "sitemap.xml". Maybe some of the ads domains are in ads.txt if it exists. In any event, it's easy to avoid the garabage URLs. IMHO, a web browser that auto-loads resources is not the best software for retrieving the URLs in a sitemap.

LordShredda• 3 years ago

So is google singlehandedly choosing which technologies get implemented and deprecated? What if my website depends on third party cookies to function? Aren't they an IETF standard and so I can expect them to be supported?

I get that third party cookies are just used for tracking nowadays, but shouldn't there be a less monopolistic way of doing so?

dangus2• 3 years ago

I think it’s pretty well established that third-party cookies are a bad idea. They’ve been turned off by default on Firefox and probably most other browsers for a while now. I can’t see when I would recommend turning them on for any user.

Just because something is standard doesn’t mean it never gets deprecated.

xg15• 3 years ago

So is google singlehandedly choosing which technologies get implemented and deprecated?

With Chrome's global market share at 60% (not even including other Chomium-based browsers), basically yes.

chatmasta• 3 years ago

In this instance, Google is actually the last browser to deprecate third-party cookies. Apple and Mozilla disabled them in their browsers over two years ago.

paulryanrogers• 3 years ago

IIRC, Firefox still enables them by default, albeit with some isolation added not long ago.

viraptor2• 3 years ago

What if my website depends on third party cookies to function?

You have alternatives. Login, oauth tokens, other site-specific API keys, ...

Aren't they an IETF standard

I don't think they are required to work the way tracking worked (across sites).

mediumsmart• 3 years ago

“We Are Preparing To Think About Contemplating Preliminary Work On Plans To Develop A Schedule For Replacing third party cookies with chocolate chips cookies”

yawn

Animats• 3 years ago

Well, for Chrome users.

I've had third party cookies turned off in Firefox for over a decade now. So have many Firefox users.

Voultapher• 3 years ago

Someone I know that uses Chrome has had them turned off for years and they say it has been mostly fine.

The conflict of interest is obvious for Google though.

zlg_codes• 3 years ago

I have nothing to prepare for, I don't build things that betray trust, Google.

mooreds• 3 years ago

Some federated identity protocols, including SAML, depend on third party cookies. I've been watching the Federated Identity W3C community group work through some of the issues for a couple of years.

You all might be interested in checking out their GH repo: https://github.com/fedidcg/FedCM

Preparing for the end of third-party cookies

Related Stories