The death of CNAME records in analytics?

I believe it may be. As for why…

Today I finally had the time to sit down with the recent Safari Technology preview and do some testing against the previously mentioned issue of CNAME Cloaking Mitigation.

What is CNAME Cloaking Mitigation?

Per the bug ticket CNAME Cloaking is defined as:

3rd-party CNAME cloaking is used as a way to circumvent ITP’s 7-day expiry cap on client-side cookies. …… Third-party CNAME cloaking means a first-party subdomain resolves to a third-party domain which does not match the resolution for the top frame host.

https://bugs.webkit.org/show_bug.cgi?id=215201

Which means that for some reason (which may include tracking) a top level domain (sitea.com) has a dedicated DNS entry pointing to a different site so for example:

metrics.sitea.com points to tracker.siteb.com

Which is a legitimate thing to be doing with Domain Name Service rules. However, since the roll out of Intelligent Tracking Prevention blocking 3rd party cookies, a number of tracking and measurement companies have issued guidance for their customers to instead issue what is known as a CNAME record in order to allow the 3rd party vendor to ‘hide’ behind a 1st party URL, and set cookies without being subject to Intelligent Tracking Prevention client side restrictions. This can have major impacts to the security of a website, which Simo Ahava goes into detail on in this blog post.

Safari is also clear how they feel about policy circumvention. As they state on their tracking prevention policy:

We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities.

If a party attempts to circumvent our tracking prevention methods, we may add additional restrictions without prior notice. These restrictions may apply universally; to algorithmically classified targets; or to specific parties engaging in circumvention.

https://webkit.org/tracking-prevention-policy/

And so, with this being what I can only assume is being seen as a violation of their policy as the user is not given choice to allow the 3rd party (which can’t see in the Network calls) to track them, they intend to limit the damage such a system can do.

What will this affect?

Any domain which Safari identifies as a tracker may have the cookie expiry reduced even if shielded by a CNAME record so that it appears as 1st party. In my personal tests this was shown to affect notable systems such as Adobe’s Enterprise Cloud ID. Not that they are the only ones affected. Vendors of all sizes use this tactic for both valid reasons, as well as tracking reasons. However the valid reasons may be caught in the cross fire to prevent cross site tracking, as is typically the case with Intelligent Tracking Prevention updates.

Should this update make it to stable channel (and I fully expect it will) those solutions will cease working as intended as soon as the remote (destination) domain is identified by the device to have tracking capability as determined by the on device machine learning model.

The business impact, should this go live, is the things those solutions depend on may have different behavior. For example:

• Analytic platforms may see surges of ‘New’ users which are really retention.
• Analytic platforms may see drop offs in Retention users which are really still there.
• Optimization platforms may generate a user on the same device in to multiple experiences of a experiment if their reoccurring visits have a long enough gap between them.
• Campaign performance measurement may see decreased look back windows.
• Campaign performance may see increased risk of attribution errors where the campaign does not get credit for driving the sale.

How does it work?

On August 10th 2020, a change was issued to the Safari development channel behind a feature flag which would check for the following conditions and cap the cookies set by the Network call to 7 days in the following scenarios:

 The cases for capping expiry look like this (and are backed by test cases):
+
+        First-party host  | First-party subdomain      | Capped expiry
+        ------------------|----------------------------|--------------
+        No CNAME cloaking | No CNAME cloaking          | No
+        No CNAME cloaking | First-party CNAME cloaking | No
+        No CNAME cloaking | Third-party CNAME cloaking | Yes
+        CNAME cloaking    | No CNAME cloaking          | No
+        CNAME cloaking    | Matching CNAME cloaking    | No
+        CNAME cloaking    | First-party CNAME cloaking | No
+        CNAME cloaking    | Third-party CNAME cloaking | Yes

However, in a changeset on August 27th, 2020 the feature flag was removed, which effectively means it will automatically be enabled once released and the relevant Safari upgrade is installed by end users.

Update: Discussions between Simo Ahava and the patch author has yielded new information which I was incorrect about:

Got some clarification – so this applies/will apply to *all* 3P cloaking, and not just those classified by ITP (nor does it impact ITP’s classifier either). So it’s more far-reaching than just flagged domains.

https://twitter.com/SimoAhava/status/1304147874532524033?s=20

Which as mentioned, makes this apply more universally and thus applies to all sites encountered by the browser.

What is still unknown?

What may be a bug, was the mitigation didn’t seem to shorten the life of cookies set by CNAME records of known trackers if the cookie was already present and valid in my tests. I would expect it to shorten the duration, and I so I do not know if this a bug, or intended.

While I have talking about Safari, it’s important to remember that all of iOS 14 / iPad OS 14 will be subject to Intelligent Tracking Prevention. This means there is a very good chance that this change will affect all browsers on those operating systems post upgrade.

When will it be deployed publicly?

This is still unknown, but a very real possibly is in conjunction with the iOS14 rollout set for this fall. At the time of writing, Apple has a media event set for September 15th, so it’s possible we’ll get a better estimation at that event as the change is likely to be in place when the new devices launch or shortly thereafter.

The current Technology Preview (v113) still has the feature locked behind a flag, but the next preview (if there is one) should see it enabled by default for all users as a standard feature.

Short of something catastrophic, I fully expect this to reach public release in the coming weeks / months. Which does not give brands and vendors much time to adjust.

Do I expect other browsers to follow suit?

In short – maybe.

• Firefox already has the APIs coded to do the Lookahead DNS CNAME record resolution, and so could in theory easily bake that into their Enhanced Tracking Protection.
• Edge could elect to develop the feature, as they already have Anti-Tracking features built into the browser. I consider this less likely / further out, if it happens.
• Chrome on the other hand I do not consider likely to deploy such a feature in the near future.

What can be done to prepare?

I suggest brands work with their developers, vendors and agencies to determine what, if anything, is dependent on CNAME records and attempt to determine if the destination is 3rd party, and if the odds of the destination domain being classified as a tracker are high.

I would advise paying attention to the Technology Previews and possible release window by following news such as the Webkit blog.

I would seek to understand the the market share of the brands iOS traffic, as all of that traffic may be subject to the change post upgrade (see above) in order to assess level of impact. This would be the worst case scenario for Mobile Traffic. For Desktop / Tablet, I’d measure the Safari market share for the domain excluding mobile traffic to get a rough approximation.

Should sizable impact be determined the options may be limited, and likely involve a mix of setting the ID to be passed to the remote vendors in the 1st party via a Set-Cookie header, and some sort of server side tag management / data forwarding solution which may not be viable for all brands or easily available in all existing infrastructure models.

This can be a complex scenario involving multiple vendors and internal teams and so I would advise brands to speak to their vendors / agencies early on, rather than in the post release rush which I expect to happen in order to get a plan in place to minimize disruption to existing business / marketing plans.

9/10/2020 4:15 PM EST – Update Added new details about how the detection works, removed incorrect information. Credit to Simo Ahava.