Safari 27.2, released on October 26, fixes cookies set by a top-level navigation’s own response being “capped to a seven-day lifetime when the site’s hostname is CNAMEd to a different registrable domain”, according to WebKit’s feature post for the release. This Safari 27.2 CNAME cookie fix is the only networking item among the 20 bug fixes listed, and the post says nothing about The Trade Desk. The public record on that question did move, though, after our October 9 report on Safari’s block of The Trade Desk’s ad domain.
What did the Safari 27.2 CNAME cookie fix change?
Safari 27.2 fixed one cookie behavior, listed under Networking in WebKit’s October 26 post (item 183787115): cookies set by a top-level navigation’s own response were being capped to a seven-day lifetime when the site’s hostname is CNAMEd to a different registrable domain. WebKit files it as a bug fix, one of 20, not as a policy change. The post does not say when the bug began, which versions had it, how many sites were affected, or what happens to cookies already stored with the shortened expiry.
Which seven-day cookie caps sit next to the 27.2 fix?
Two documented seven-day cookie caps sit next to the bug that 27.2 fixed. The table shows what each covers and whether the 27.2 post mentions it.
| Case | What WebKit describes | Where WebKit described it | In the 27.2 post? |
|---|---|---|---|
| JavaScript cookies | “all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry” | ITP 2.1 post, February 2019 | Not mentioned |
| Third-party CNAME cloaking | Cookies set in third-party CNAME-cloaked HTTP responses, capped to 7 days | Safari 14 post, November 2020 | Not mentioned |
| Page response on a CNAMEd hostname | Cookies set by a top-level navigation’s own response when the hostname is CNAMEd to a different registrable domain (capped by a bug) | 27.2 post, October 2026; start date not stated | Fixed |
“Not mentioned” is not the same as “unchanged”. The post is silent on the first two rows, and we do not read more into that.
Where does PPC Land’s reading fit?
PPC Land (Luis Rijo, October 27) made several points first. It reads the bug, and says so as its own reading, as sitting outside WebKit’s 2020 definition, which was written for subresources and allowed for the top frame host’s own CNAME. WebKit’s 2020 post defines the case as “a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host’s CNAME, if one exists”, and also says: “Yes, the whole site can be CNAME cloaked, when it uses so called edge servers.” The 27.2 post does not say how the bug relates to that definition.
PPC Land also noted that CNAMEing a www hostname to a provider’s domain is routine for CDNs and hosted platforms, and that page responses commonly set sessions, baskets and consent records, with some server-side measurement setups writing visitor IDs there as well. It observed that the post does not mention cloaked tracking subdomains, and that any effect would show up as a shift in Safari return rates. The post offers no figures.
What happened to the Trade Desk bug?
Our October 9 piece reported WebKit bug 324771, “Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list”, as NEW. That was correct at publication. At 21:40 PDT that night (04:40 UTC on October 10), John Wilander changed the status to RESOLVED and the resolution to FIXED, with the comment “Confirmed resolved.”
The bug does not say what changed, which domains remain blocked, or which public release carries the change. It does not mention the public 27.2 release; its only 27.2 reference is a beta. Earlier, on October 5, Wilander noted that a new iOS 27.2 beta had gone out, and reporter Ian Meyers acknowledged he saw the changes in build 24B5099f.
Digiday’s account is that “In early October, Apple partly restored The Trade Desk’s ad server”, and that UID 2.0 and the other identity vendors stayed blocked. That is Digiday’s reporting, not an Apple statement. Whether production Safari 27.2 still blocks requests to adsrvr.org is not answered by any source we have.
Does a Safari blocklist change need a release note?
On September 25 WebKit committed “Block requests with a WebPrivacy provided content rule list instead of a network process check” (bug 324589, Charlie Wolfe). The message says: “This patch replaces the static domain list in the network process with a content rule list that WebPrivacy provides.” It adds that the UI process caches the list and “reloads it when WebPrivacy posts an update.”
The commit message names no domains, does not say which release carries it, and does not link itself to the cookie fix. WebPrivacy is Apple’s framework, so the list contents are not public. Our reading: on the main branch, WebPrivacy supplies and updates the list, so changing it need not involve a WebKit code change. Release notes cannot be the only place to look. On WebKit’s main branch, at least, that settles one open question from our October 9 piece: whether the list is fixed. WebKit’s October 19 post says its block on identity resolution infrastructure “is done on the domain level” and names no vendors. What is blocked on a given device remains a device test.
How can analysts check whether their site was affected?
- Resolve the hostname that serves your pages:
dig +short CNAME www.example.com. The 27.2 wording concerns a hostname CNAMEd to a different registrable domain. WebKit does not address flattened or ALIAS setups, so assume nothing either way. - Look at the
Set-Cookieheaders on the document response itself, in the browser’s network panel or withcurl -s -o /dev/null -D - https://www.example.com/, which makes a GET request like a page load (curl -Isends HEAD, and not every server sets the same cookies on HEAD). Note which cookies matter: sessions, baskets, consent records, server-set visitor IDs. - If both answers are yes, annotate October 26. Compare the returning-visitor share of Safari on iOS 27.2 against earlier iOS 27 versions from that date. WebKit does not say which versions had the bug or whether cookies already stored with the short expiry are extended, so treat a gap as a lead, not proof.
- On macOS, segment by Safari version, not OS version. Tahoe and Sequoia receive Safari 27.2 as an update, so the OS number is not a proxy.
Your own Safari segment is the place to look. Google’s CrUX collects only desktop Chrome and Android Chrome, as our look at the Cloudflare BEACON dataset noted, so WebKit traffic was never in it.