5 ms·
We now have trackers acting like first-party properties, but where do you draw the line between first-party and third-party? What I mean is, if I build my own i
by teamjimmyy 7y ago
We now have trackers acting like first-party properties, but where do you draw the line between first-party and third-party? What I mean is, if I build my own in-house analytics app that does a lot of what Adobe's product does, should that be blocked too?
I specifically mean for site analytics, like Experience Cloud or GA, not serving ads. Ad block is different IMO.
If this is hosted on a first party subdomain you're already blocking the ability of it to set third-party cookies and track you across sites. So, in practical terms, what's the difference between this CNAME trick and building the same thing in-house to run your own analytics?
- munchbunny 7y agoIt depends on why you care about the distinction. If you're talking from a purely privacy perspective, the important questions are (1) are you taking analytics? (2) what are you doing with them? (3) is that in line with users' expectations? Third party, or third party disguised as first party, is only problematic because of an implied "there's very little keeping the third party from using your data for things that aren't just analytics for the first party." It's the red flag for "this site may not be using your data the way you would want it to." Third party ad trackers disguised as first party cookies specifically violate the general assumption that first party data stays first party, because those third parties have specific mechanisms to track you across multiple first parties.
- x0x0 7y ago> violate the general assumption that first party data stays first party How? Because they can't do that with cookies. I think the most prominent objection to 3rd party cookies is they allow systematic tracking. This seems like they just help eg apple or whomever understand what you're doing on that same site.
- zonidjan 7y agoThere are plenty of other ways to fingerprint a user. https://amiunique.org/ https://amiunique.org/
- x0x0 7y agoThat really doesn't answer the question. Munchberry claims these analytics tools have cross domain tracking and I'm asking how, precisely. In part because of professional interest, and in part because I don't actually think it's true.
- munchbunny 7y agoThanks for getting my username right. ;) You specifically got one detail wrong: it's not just for analytics tools. It's the adtech industry in general using this technique, and Adobe offers its analytics as part of its marketing software suite. From their own site: "What is Adobe Experience Cloud? It's a collection of best-in-class solutions for marketing, analytics, advertising, and commerce."
- x0x0 7y agoApologies Munch bunny, gonna blame that on a need for new glasses. fwiw, Adobe Experience Cloud is generally not the sort of adtech that attempts to sell information.
- munchbunny 7y agoYou're right, Adobe Experience Cloud doesn't sell information, so how problematic you find the product depends on where you draw the line on privacy. Specifically, Adobe Experience Cloud definitely offers retargeting capabilities (ads following you around the internet) and the ability to get statistics on the effectiveness of that advertising. If they're at parity with competing marketing suites, then they also have attribution capabilities to track you with per-user, per-interaction granularity. A site that serves Adobe Experience Cloud cookies in the third-party-disguised-as-first-party way is likely enabling this capability for all marketers that are going through Adobe Experience Cloud. So the interesting question would be whether you, a visitor to Fox.com, consider being watched by marketers who aren't Fox.com to be a privacy problem.
- 7y ago
- munchbunny 7y ago> How? Because they can't do that with cookies. My point is exactly that: they can and are doing it (using first party cookies through CNAME redirects to correlate your identity across multiple independent sites in order to sell a data product to more than just the first party). For an example, see Criteo. > I think the most prominent objection to 3rd party cookies is they allow systematic tracking. And now first party cookies are starting to be used for that too. It's not that important how you specifically want to phrase the general ickiness of third party cookies.
- 3xblah 7y ago"So, in practical terms, what's the difference between this CNAME trick and building the same thing in-house to run your own analytics?" In practical terms, based on what we have seen up to now, few websites will run their own analytics. Thus, focusing on the third party services is effective against most tracking. The "CNAME trick" might be viewed as a good thing because it is putting evolutionary pressure on users to utilise DNS to "block" ads instead of using popular graphical web browsers to do the work. These browsers are written by companies or organisations that derive substantial revenue from online advertising.
- icebraining 7y ago> it is putting evolutionary pressure on users to utilise DNS to "block" ads instead of using popular graphical web browsers to do the work How so? Browser and browser addons are perfectly capable of blocking these subdomains.
- garren 7y agoIt's not that browser add-ons aren't capable of blocking them, it's that a) browser extensions generally don't have access to dns resolution, b) even if they did, cname tracker resolution would increase overall latency due to multiple requests to identify trackers /outside/ of normal resolution, c) it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists. Extensions now have to identify which cnames are a front for which trackers, block the new tracker, and somehow manage to stay below the max rules-per-extension that the browser allows (30k for Chrome[0]). See original nextdns.io post for details [1]. [0] https://www.xda-developers.com/google-chrome-manifest-v3-ad-blocker-extension-api/ https://www.xda-developers.com/google-chrome-manifest-v3-ad-... [1] https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a https://medium.com/nextdns/cname-cloaking-the-dangerous-disg... ( https://outline.com/Y6PKr3 https://outline.com/Y6PKr3 )
- bscphil 7y ago> it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists. This is the part I'm skeptical of. If your site is HTTPS, and a user forbids mixed content, all your ads have to be served over HTTPS. That means whenever you create a new CNAME, the ad server (not run by you) has to generate a new certificate, or else you have to give them a cert for *.yourdomain.com. Both are pretty big asks. Even if the ad server can automatically generate new certs, they're going to show up in a transparency log and can be automatically added to blocklists based on that. So I'm not sure it's going to make much of a difference which blocking method people use. All the Easylist (or whoever) folks have to do is add new subdomains to their blocklist - the exact same thing an ad blocking DNS provider is doing. Edit: the process for obtaining a certificate from Adobe for a new tracking CNAME looks absolutely excruciating, which is good evidence for my point. https://docs.adobe.com/content/help/en/core-services/interface/ec-cookies/cookies-first-party.html https://docs.adobe.com/content/help/en/core-services/interfa...
- egdod 7y agoAll analytics should be blocked.