Browsers are mobilizing to combat the use of DNS CNAME records to bypass anti-tracking tech they have built in to their browsers. November is looking to be a triple whammy of developments in this area.
iOS and Safari
I first wrote about this in September, and now the time is here. On November 5th 2020 Apple released iOS 14.2 and iPad 14.2. With these updates now in play, any device running these new versions will have CNAME Cloaking Mitigation enabled by default. This change was not listed in any patch notes and as of the time of writing Apple has also not updated Webkit’s blog to announce the change.
Safari vs iOS (present state)
An example to show what I am talking about may be in order.
Using Mac OS Safari – Let’s look at Apple.com which based on their Network traffic you can tell is leveraging Adobe’s CNAME solution by calling their subdomain securemetrics.apple.com
If we run a DNS record lookup on this subdomain we can see it points to appleglobal.102.112.2o7.net. The 2o7.net domain is used by Adobe for Adobe Analytics data collection.
How this works is JavaScript on the page would call (in this case) securemetrics.apple.com which forwards the request to appleglobal.102.112.2o7.net. which would proceed to set a s_vi cookie (containing the Adobe Analytics visitor ID) for a period of two years via the response header.
Response Header:
set-cookie: s_vi=[CS]v1|2EAFF145852CC4DD-400009B360002651[CE]; Path=/; Domain=apple.com; Max-Age=63072000; Expires=Sun, 06 Nov 2022 10:07:07 GMT; SameSite=None; Secure
Then if we look at the cookies set by the domain we can see that cookie does indeed last for two years.
iOS
Now let’s see how this is different on the recent iOS upgrade.
Using Mobile Safari we repeat the above steps and use a Macbook to see what is going on. So we navigate to apple.com and call securemetrics.apple.com
We can see that indeed, the response header says the s_vi cookie should last for two years. So we move on to check the cookie storage.
We can see indeed that the cookie’s duration is lowered to 7 days. This is a sizable change as many vendors (not just Adobe) use CNAME redirection for a number of reasons (not just tracking). The Webkit feature does not care however, and only looks at if apple.com is the same as 2o7.net, which it clearly isn’t – and so applies the restrictions.
This means as adoption of iOS 14.2 and iPad 14.2 continue to rise – this will become a common scenario. Since Webkit is the foundation of all browsers on iOS, I strongly suspect that it will apply to all browsers on the platform. I have reached out to Apple and will update if they confirm this is not the case.
In North America iOS accounts for 53% of all mobile web traffic. This should become noticeable in data pulls over the next few weeks for any site with notable iPhone / iPad traffic.
What about Mac OS?
The change is present in Safari builds for the upcoming Mac OS Big Sur. At the time of writing Apple has an event planned for November 10th, and so details about the release date could be announced at that time. I fully expect it to be present in Safari on the new operating system version.
Brave
Brave announced on November 17th their browser will also combat CNAME cloaking in a different manner. Rather than just lower the duration of cookies set via this method, Brave will block the request entirely.
So what’s this mean?
The door has closed on using CNAMEs to set cookies and expecting them to have long durations. This is a change in web architecture that developers need to now account for.
From the business point of view, any service using CNAMEs for cookie setting will either see that traffic disappear entirely (Brave) or have sizable reductions in lookback windows (iOS/iPadOS/Safari Big Sur).
This includes (but is not limited to) 7 days of lookback window for campaign measurement, possible increase in new users, possible loss of retention identification, and possible resegmentation of A/B testing cell assignments in scenarios where CNAME was used to set cookies.
What can be done?
It’s going to be interesting.
The clearest answer is transitioning from CNAME usage to use A / AAAA DNS records. Which may be easier said than done. Otherwise you’d need to leverage some sort of server cookie issuance / persistence layer. Both of these can be tricky as I am sure this change is going to blindside a number of vendors.
The best advice I have is to in scenarios where you where using CNAME for Analytics or Measurement is to reach out to the vendor(s) involved and see what they say then discuss the answers with your dev team/agency.
Since many brands are now going into code freeze for the shopping season, this is likely to be exceptionally rough on the analytics front as adoption of the upgrade takes hold. The only advice I have for that is to keep this in mind when analyzing or reporting results.
Thanks for this article, very insightful. I was wondering about the A/AAAA DNS record workaround. For Safari, that would probably be a small step to add to their ITP logic? If all vendors would go for the A/AAAA record alternative, that would certainly cause ITP to follow suite. Or do you think it’s inherently more difficult to match the IP address of the A record for the same-origin check?
It’s just not as trivial of a check. Currently they resolve the DNS chain for CNAMEs and just evaluate if that is the matching the Top Level Domain Name. If they wanted to check the IP, they’d have to also pull a WHOIS record of both domains and compare them on top of the DNS checks. Seems like a lot of additional overhead, and so given how fragile using A/AAAA records can be with vendors I am skeptical the effort is justified.