5 ms·

The article lists numerous alternatives to replace functionality that 3rd party cookies currently provide. But is there anything that prevents third-party anal

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 https://allurdataarebelongtous.xyz/collectitall collecting visitor data on: https://myhometownnewspaper.com/ https://myhometownnewspaper.com/ It's replaced by: https://myhometownnewspaper.com/allurdataarebelongtous/collectitall 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.

infotogivenm 3y 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 3y ago
  What do you mean, anti trust people immediately went after Google for removing 3rd party cookies. Can't win...
- lucaspiller 3y ago
  Actually fingerprinting is pretty reliable: https://amiunique.org/fingerprint https://amiunique.org/fingerprint
flower-giraffe 3y ago
That’s exactly what meta/facebook have been facilitating https://developers.facebook.com/docs/marketing-api/conversions-api/guides/gateway/ https://developers.facebook.com/docs/marketing-api/conversio...
hn_throwaway_99 3y 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.
- amf12 3y 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.
justrealist 3y 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.
- fyokdrigd 3y ago
  that's why chrome have that nice little picture of your google profile on there ui. you're always logged at google.
  - justrealist 3y ago
    Publishers don't get access to chrome login info without explicit consent.
    - fyokdrigd 3y ago
      my point was that google does. it tries to whitewash how they moneyize it with the "cohort" traffic...
1vuio0pswjnm7 3y 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.

infotogivenm 3y 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 3y ago
What do you mean, anti trust people immediately went after Google for removing 3rd party cookies. Can't win...
lucaspiller 3y ago
Actually fingerprinting is pretty reliable: https://amiunique.org/fingerprint https://amiunique.org/fingerprint

flower-giraffe 3y ago

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

hn_throwaway_99 3y 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.

amf12 3y 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.

justrealist 3y 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.

fyokdrigd 3y ago
that's why chrome have that nice little picture of your google profile on there ui. you're always logged at google.
- justrealist 3y ago
  Publishers don't get access to chrome login info without explicit consent.
  - fyokdrigd 3y ago
    my point was that google does. it tries to whitewash how they moneyize it with the "cohort" traffic...

1vuio0pswjnm7 3y 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.