Intelligent Tracking Prevention

The following discussion on Intelligent Tracking Prevention (ITP) 2.2 took place on Monday, April 24.

rickdronkers [Apr 24th at 11:58 AM] So ITP 2.2 is here - link decoration trickery gets eliminated. Thoughts? https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/ WebKit Intelligent Tracking Prevention 2.2 Apr 24th

rickdronkers [6 days ago] afaik this influences ?gclid= and ?fbclid= link appendixes right? Thus resulting in weakening the device graphs of advertising networks because they can no longer rely on their own first party cookie data that got set during first visit when entering with that link decoration.

simoahava [6 days ago] Beautiful. Finally a targeted approach against FB rather than a blanket solution against all tracking domains :)

Cory Underwood [6 days ago] it affects most ad-server solutions, not just Facebook.

simoahava [6 days ago] I think they’re pretty vague about ad click attribution. Per the WebKit patch spec, they’re provisioning exceptions for ad clicks

simoahava [6 days ago] fbclid is blatant cross-site tracking so this targets that specifically

Cory Underwood [6 days ago] Right, but what if the ad, is on Facebook :wink:

simoahava [6 days ago] Who gives a shit? FB has dug their own hole with repurposing their ad parameters for tracking the user across the sites. Reap what they sow now :)

simoahava [6 days ago] I wonder if they’ll get rid of document.cookie before the year is out :)

rickdronkers [6 days ago] with the speed this is going: probably :smile:

rickdronkers [6 days ago] keen to see if this targets gclid just as hard as fbclid

simoahava [6 days ago] We’ll see - gclid only passed info about the ad that was clicked and not the user (I’m assuming this to be the case), so per the patch spec and the blog post it should be safe (or should be able to be qualified as safe) but I’m not sure how the particulars work

simoahava [6 days ago] Perhaps Conversion Linker could start using localStorage? :)

simoahava [6 days ago] Kinda sucks if one of your domains is classified for cross-site tracking capabilities and you want to do cross-domain tracking in GA

rickdronkers [6 days ago] re: localStorage: at this speed that might be out before end of the year too :smile:

simoahava [6 days ago] True!

simoahava [6 days ago] I’m still waiting for more SaaS services to pop up that offer cookie rewriting with a CNAME

simoahava [6 days ago] I’d be tempted to start a service myself if I had the time to do so, just as a fun exercise

simoahava [6 days ago] Heck, maybe I’ll do it - something simple running on GCP

simoahava [6 days ago] Takes all the cookies from HTTP header and rewrites them with Set-Cookie. Then the site just needs to reverse proxy or CNAME that endpoint and boom - Intelligent Tracking Prevention Prevention (ITPP)

simoahava [6 days ago] https://twitter.com/johnwilander/status/1121136222649192448 John Wilander@johnwilander @SimoAhava There is currently no way to know if a click is an ad click or some other kind of navigation. There is also no way to know what the data carried in query parameters represents. Thus, all decorated cross-site navigations from classified domains are subjected to ITP 2.2. TwitterApr 24th

Cory Underwood [6 days ago] Pretty much - doesn't know what's good or bad, so you err on the side that it's bad.

simoahava [6 days ago] Yeah

simoahava [6 days ago] As was ITP 2.1

Wouter Nieuwerth [5 days ago] So, if I understand correctly, this does NOT impact standard Google Analytics cross domain tracking (through ?_ga=1234567.1234567), since your own domain will probably not be classified domains? Can anyone confirm?

simoahava [5 days ago] Confirmed

simoahava [5 days ago] It will impact it if your domain is classified as a tracking domain. Probably not that common

rickdronkers [5 days ago] is there a list of classified tracking domains somewhere? Google didn't help me out

rickdronkers [5 days ago] ah, it uses client side in browser ML?

simoahava [5 days ago] Yeah: https://twitter.com/SimoAhava/status/1121319529211150336 Simo Ahava@SimoAhava @ffflutur @timdechau See https://twitter.com/johnwilander/status/1121113578709250048

and

https://webkit.org/blog/7675/intelligent-tracking-prevention/

So there’s no way to identify it a priori - you need to look at the “symptoms” (cookie expiry, inability to use third-party cookies even if enabled). TwitterApr 25th John Wilander@johnwilander @phillipvs They are detected on-device as you browse the web. We have no central list. ITP captures statistics on all loads and has a model for when a particular domain has shown the capability to track the user cross-site. TwitterApr 24th

simoahava [5 days ago] You can also use the ITP Debug tool while browsing yourself - it will tell you details about the domains

simoahava [5 days ago] https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62/ WebKit ITP Debug Mode in Safari Technology Preview 62 Aug 5th, 2018

rickdronkers [5 days ago] I thought I was blind but you need to download safari tech preview mode :smile: thanks!

Fredric Lundgren [5 days ago] I’ve been bugging the google account rep about them not offering a CNAME solution since ITP 2.1 hit, so if you want to you could probably make a quick buck out of such a solution @simoahava…

rickdronkers [5 days ago] simoITPhack.com

Aurélie [5 days ago] "Intelligent Tracking Prevention Prevention" reminds me of when Peter Swire wrote about escalation wars. Version how many is this now? And I got into web analytics to make the world a better, more accountable, place, silly naïve person :woman-facepalming: https://www.wired.com/2013/04/do-not-track/ WIRED How to Prevent the 'Do Not Track' Arms Race The advertising industry claims this is a "nuclear first strike" against their industry. And so begins the arms race, whereby the digital cookies currently used to track user habits are blocked by the browsers -- only to have the advertisers respond with even more sophisticated tracking methods like digital fingerprinting. Browsers are gearing up to disable or reduce the effectiveness of such fingerprinting ... leading to yet another round of aggressive tracking tools by advertisers followed by blocking tools on the user side. And so on.

Barry [5 days ago] Does anyone know of a sensible / workable solution for persisting the Adobe Analytics ECID across multiple domains that my organisation owns in the face of ITP?

I can't think that we're the only organisation that has companyname.com & companyname.co.uk & companyname.fr & so on and wants to be able to join up our traffic across all of them.

I've tried Adobe Customer Care, but their sole suggestion is the *appendVisitorID* query string parameter; this only helps (in an ugly way, I might add) if we programmatically add it to all organisation-internal links *and* we never have traffic that visits .com and .co.uk independently.

We're setting up CNAME entries for each of the domains with Adobe's Managed Certificate Program, but that doesn't help us cross-domain.

I'm wondering whether there's a version of your proposal, @simoahava, that could be made to work for this scenario.

In the interests of fairness, I'd also be interested to know if anyone thinks that what I'm describing goes against users' expectations of privacy / what ITP is trying to prevent.

Michael Parmley [5 days ago] Also curious about @Barry’s question, specifically as it relates to tracking view-through impact of offsite display and video ads. Seems like localStorage is the recommended solution, but I haven't wrapped my head around this yet.

rickdronkers [5 days ago] Little cautionary advice re: localStorage, to me it seems totally plausible this will be blocked next. I'm not sure this is a race worth racing for a lot of companies. Perhaps analyzing what the impact of this will be and how much action the company is taking on the data that will be distorted should be the first step.

simoahava [5 days ago] I don’t think any type of cross-domain without actually visiting via links is feasible without having persistent authentication via a backend

simoahava [5 days ago] It hasn’t been really solved in any analytics platform

Cory Underwood [5 days ago]

point_up:

yuhui [5 days ago] the WebKit page states that link decoration _that identifies a user_ will fall under ITP2.2.

since AA’s campaign tracking parameter (and also GA’s UTM parameters) cannot identify the user at the publisher’s end, then i assume that it is safe from ITP2.2.

simoahava [5 days ago] No, I clarified this from Wilander in the tweet I quoted above

simoahava [5 days ago] ITP doesn’t differentiate between query parameters. If it’s a tracking domain then ANY query parameter will trigger the short expiry.

Cory Underwood [5 days ago] Doesn't make sense to scan everything and it'd be impossible to keep up with - while I think it's a bit heavy handed, that's how I'd solve it too - figure out the thing that doesn't change as easy and block based on that.

yuhui [4 days ago] according to the graphic in in https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/, my understanding is that the originating domain needs to have its own system of tracking users which is tied to the query parameters that are added to clickthrough links. if so, then ITP2.2 kicks in.

but with campaign tracking, the originating domain (i.e. the place where the ads show) don’t (can’t?) use campaign tracking to track users to that level. so i would assume that campaign tracking is exempt from ITP2.2 (edited) WebKit Intelligent Tracking Prevention 2.2 Apr 24th

simoahava [4 days ago] @yuhui did you read John’s tweet? There’s absolutely no way for Safari to know what an ad service is doing with the query parameters which is why all query parameters trigger the cookie expiry. He also replied in other tweets that GCLID is just as impacted as FBCLID when only the latter tracks users

simoahava [4 days ago] I mean, Safari can’t know if a logged in Google user’s login details are encoded into the GCLID parameter hashed. Neither can we, for that matter..

yuhui [4 days ago] @simoahava no, i hadn’t, but now i did. i get what he means, so i re-read the webkit blog articles again.

according to ITP 2.2: > 1. The website social.example has been classified by ITP as having cross-site tracking capabilities.

also: > You might recall from our original ITP blog post that we mentioned link decoration as a way to achieve ad attribution in navigations. Such attribution should serve the destination site information about what ad was clicked and on which site, not information about who the user is.

in https://webkit.org/blog/7675/intelligent-tracking-prevention/: > A machine learning model is used to classify which top privately-controlled domains have the ability to track the user cross-site, based on the collected statistics.

so social networks, adwords would fall under ITP2.2

but if i have a blog and i link to another blog with AA’s CID / GA’s UTM tags, i don’t think ITP2.2 would kick in, cos i think that should fall under “ad click attribution” WebKit Intelligent Tracking Prevention Jun 5th, 2017

simoahava [4 days ago] That’s because your blog most likely isn’t a classified domain

simoahava [4 days ago] As always, ITP only affects domains classified as having cross-site tracking capabilities

Cory Underwood [4 days ago] @simoahava Clearly Safari should attempt brute force hash collisions in order to determine if the query string is hostile.

simoahava [4 days ago] Sorry if I misunderstood your point

simoahava [4 days ago] @Cory Underwood or just write letters to ad tech vendors asking them pretty please to say if they are misusing first party storage :)

Cory Underwood [4 days ago] Because companies _never_ lie about shady things, esp such upstanding ones such as Facebook who have _excellent_ track records on such matters.

simoahava [4 days ago] Of course! Humans are good. Deep, deep, *deep* down