In October of last year, an Apple engineer issued a pull request for Apple’s WebKit repository on GitHub, drawing attention to the fact that websites can use their A/AAAA DNS records to cloak the true origins of the cookies they store. This is done to make these cookies appear to be delivered by the website a user is currently browsing (first-party) when they are really delivered by some unrelated service (third-party). The solution proposed in the pull request was integrated into Apple’s Safari browser, resulting in third-party cookies served via A/AAAA DNS record mapping being deleted after seven days.
The history of Apple’s Intelligent Tracking Prevention (ITP) initiative is critical to understand in interpreting this change:
- ITP was introduced in September 2017 and originally allowed third-party cookies to be stored on a user’s device for 24 hours before being deleted;
- This was changed in ITP 2.0, announced in June 2018: the 24-hour cookie storage period was discontinued, with the Safari Storage Access API, introduced in February 2018, used to set and store cookies through explicit user opt-in;
- In February 2019, through ITP 2.1, first-party cookies stored on the client using the JavaScript
document.cookieproperty were forced to expire after seven days; - In April 2019, this restriction was sharpened through ITP 2.2, with Javascript cookies set by domains known to have tracking capabilities resulting from links that utilize “link decoration” — or UTM parameters or hashed identifiers included in the link’s URL — being deleted after one day;
- In ITP 2.3, announced in September 2019, the WebKit team introduced further restrictions to prevent the practice of link decoration;
- In March 2020, ITP was updated to block third-party cookies completely and to create a (somewhat complex) timer system to regulate how long cookies set using script-writable storage could persist (at most, seven days of non-continuous browser use without meaningful interaction with the site that stored the cookie).
Across these updates, no hard limit was imposed on first-party cookies set through the HTTP response header: these continue to be available to websites in a first-party context with no browser-imposed expiry. In November 2020, Apple’s WebKit team announced its intention to disrupt the practice of CNAME cloaking, wherein a website uses a CNAME DNS record to resolve a sub-domain to a third-party domain without the user or the browser recognizing that context deviation. Using CNAME cloaking, websites could set cookies from third-party services in a first-party context, allowing those cookies to bypass the expiration rules that ITP had imposed. In November 2020, the WebKit team announced that it had enhanced ITP to detect CNAME cloaking and to force the expiration of cookies set that way within seven days.
The pull request referenced above relates to a workaround utilized by vendors after the CNAME cloaking restriction was introduced: using another type of DNS record, the A/AAAA record, to map a domain to an IP address instead of another domain (an A record is the more common form and maps a domain to an IPv4 IP address; an AAAA record maps a domain to an IPv6 IP address). Now, following this enhancement, when ITP detects that a cookie is being set by a third party via an A/AAAA record, it enforces the same seven-day expiration limitation on it that applies to CNAME cloaking.
The implications of these limitations for advertising measurement are consequential:
- The shorter the attribution window provided to observe conversions after ad clicks, the less scope and visibility an ad platform has in assessing the performance of campaigns run on behalf of advertisers;
- Most modern ad platforms use conversion signals to optimize campaigns in real-time, and when signal is limited, these platforms cannot attribute conversions that take place outside of the prescribed window to those campaigns for the purposes of optimizing them (eg. increasing their delivery or adjusting their audience targeting);
- Some platforms have begun modeling conversions to fill this visibility gap, which comes with its own set of attendant problems.
The WebKit team’s introduction of the A/AAAA DNS restriction seems aimed at a number of advertising measurement intermediaries, mostly specific to eCommerce / DTC advertising, that utilize “server-side tracking” to preserve transparency into post-click behaviors via A/AAAA name records coupled with UTM matching. Unsurprisingly, public documentation around this practice is difficult to ferret out, although it’s conceptually similar in terms of integration to CNAME cloaking (references here and here). Note that CNAME and A/AAAA cloaking are not exclusively utilized for tracking purposes — they support other use cases, too, which has caused some concern related to this policy change.
Soon after Apple’s App Tracking Transparency (ATT) privacy policy was unveiled in June 2020, Meta (then, Facebook) published guidance that implied that ATT would only restrict use of the unique advertising identifier on iOS devices, the IDFA. At that time, Meta declared that it would simply stop accessing the IDFA in its own apps in order to be compliant with the new policy. A few months later, in December 2020, Meta revised its operational guidance in recognition that ATT did not exclusively apply to use of the IDFA, but to all ads displayed in mobile apps on iOS (ie. ads that lead to app or web destinations). It was in this updated guidance that Meta introduced a new measurement framework called Aggregated Event Measurement (AEM), which allows anonymized, campaign-level data to be transmitted from an advertiser’s website back to Meta’s servers on a 7-day click / 1-day view attribution window. Meta’s early documentation for AEM stated that this solution is analogous to WebKit’s Private Click Measurement (PCM) framework, which governs the same and can be thought of as a spiritual equivalent to Apple’s SKAdNetwork framework for mobile app advertising measurement.
But Meta offers advertisers another conversion measurement solution: the Conversions API, or CAPI, which allows advertisers to instrument specific conversion events and to transmit them to Meta through a server-to-server transmission process. This server integration sits entirely outside of the purview of a browser or mobile operating system. And Meta isn’t alone in offering a Conversions API: Google operates a similar product, Enhanced Conversions, via API, as does Snap (Advanced Conversions, which the company sees as one of the core pillars of its post-ATT advertising infrastructure) and Pinterest (the Pinterest API for Conversions, which I cover here). The transmission of this data takes place between servers and can only be regulated by credible fear of platform policy being enforced or law. Note that my understanding is that these conversion measurement solutions are compliant with ATT.
ITP’s history serves as a testament to the idea that the project of moderating data usage in digital advertising is a relentless game of whack-a-mole. Outside of starving the ecosystem of unique identifiers that can be used for user-level attribution and identity — as Apple did with ATT — or of regulating that use through legal standards, there is no effective path to utterly inhibiting it. Like a sapling on the forest floor contorting itself to meet an improbable ray of sunshine evading the canopy above, ad tech finds a way: be it through link decoration, CNAME cloaking, A/AAAA record masking, or server-to-server implementations of conversion tracking. To my mind, the only credible path to moderating this flow of data with clear, enforceable standards is through legal restrictions.
