Apple’s WebKit team published its Safari 27.2 release notes on October 26, and one of the 20 bug fixes in the list changes how long Safari keeps a cookie that a website sets about itself. For any site whose hostname is an alias for another company’s domain, the cookie no longer expires after seven days.
What the 27.2 note says
The post, titled “WebKit Features for Safari 27.2” and written by Jen Simmons, leads with styling work. In its own words:
“Safari 27.2 is here, refining Customizable Select, renaming a Grid Lanes property, and delivering 20 bug fixes across accessibility, media, CSS, and more.”
The marketing-relevant line sits under the Networking heading. It reads: “Fixed 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.” The entry carries the tracker number 183787115 and one sentence of description. The rest of the post never mentions tracking prevention, identity resolution or the ad and data domains that Safari 27 blocks.
The rule that sits behind the fix
Seven days is the cap that Safari’s Intelligent Tracking Prevention, or ITP, began applying to cookies set through CNAME cloaking in Safari 14. A CNAME record points one hostname at another, so a site owner can make a subdomain such as track.blog.example resolve to an outside company’s servers. John Wilander explained the defense on the WebKit blog in November 2020:
“ITP now detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days.”
That post defines third-party CNAME cloaking 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. It also includes a table of cases. In the row for a whole site that sits behind an edge server, where the page host and the subdomain share the same CNAME target, the cookie expiry is not capped. A request to a subdomain that resolves to a tracker’s domain is capped at seven days.
In our reading, the 27.2 entry removes the cap from a case that the 2020 table lists as uncapped: a site whose own page host is CNAMEd to a content delivery network or edge provider, setting a cookie in the response to the page itself. WebKit’s note does not say when the extra cap began, and it does not say which Safari versions had it.
Why the cap existed
The 2020 post gives two reasons for the defense. The first is tracking: it says cross-site trackers had convinced site owners to set up CNAME cloaking to get around ITP’s seven-day cap on cookies created in JavaScript, and it cites a paper from researchers at Sokendai and France’s ANSSI that found 1,762 websites cloaking 56 trackers. The second is security. WebKit wrote that site owners who set up CNAME cloaking risk full website takeovers or customer cookie hijacking if the records are not managed properly, for instance when the setup is not decommissioned after use.
Both reasons concern a third party sitting behind a first-party hostname. The 27.2 entry concerns the case where the whole site is the alias, which the 2020 table lists as the edge-server case.
What the note leaves alone
The fix is scoped to cookies set by a top-level navigation’s own response. The 27.2 post says nothing about cookies that a subdomain sets in a response to a subresource request, which is the case the 2020 post targets. It also says nothing about the separate seven-day expiry that the 2020 post attributes to cookies created through JavaScript. Teams that run a vendor’s tracking endpoint on a subdomain of their own site, such as a server-side tagging endpoint, should not read the 27.2 note as a change for that arrangement. The post does not address it either way.
The note also arrives in a month when Safari’s handling of marketing data has drawn attention. WebKit explained its identity resolution block in a post we covered in Apple Explains Safari’s Identity Resolution Block in a WebKit Post, after the bug-tracker threads in Safari 27 Blocks Ad and Identity Domains, per a WebKit Bug Report. The 27.2 beta also figured in WebKit Marks Trade Desk Domain Bug Resolved After iOS 27.2 Beta. The cookie entry is a separate, smaller change that shares only the version number with those stories.
What it means for the marketing leader
Return-visitor and logged-in rates in Safari can move for reasons unrelated to a campaign. If your site’s page host is an alias for a CDN, cookies your servers set for logins, preferences or visitor IDs may have been resetting after a week for Safari users. Once those users update to 27.2, those cookies keep the lifetime your server set. A rise in Safari repeat visits that starts in the weeks after the update may reflect that, and a dashboard annotation on the release date keeps it from being credited to a promotion.
Four checks take an afternoon. Ask the web team whether the main hostname resolves through a CNAME to a different registrable domain. Open a Safari 27.2 session and read the Set-Cookie headers on a page response to confirm the expiry matches what the server sends. Test any tracking subdomain separately, since the note does not cover it. Then compare Safari cohort retention before and after the update date before changing any attribution window.
Source: WebKit Features for Safari 27.2, WebKit Blog. Background: CNAME Cloaking and Bounce Tracking Defense.
