Hacker News Reader

Comment by SkyMarshal | Hacker News Reader

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.

View on HN

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”).

Actually fingerprinting is pretty reliable:

https://amiunique.org/fingerprint

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

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

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.

> 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.

> 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.

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.

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

Publishers don't get access to chrome login info without explicit consent.

my point was that google does.

it tries to whitewash how they moneyize it with the "cohort" traffic...

Reply on news.ycombinator.com