TL;DR
- Apple's WebKit post of 26 October 2026 lists bug fix 183787115: Safari 27.2 no longer caps cookies set by a site's own page response at seven days when its hostname is CNAMEd to another registrable domain.
- Apple did not say when the bug began, which Safari versions were affected or how many sites were hit; the fix leaves the JavaScript cookie cap and the CNAME-cloaking defence from Safari 14 in place.
- Safari 27.2 ships with iOS, iPadOS, visionOS and macOS 27.2 and as a separate update for macOS Tahoe and Sequoia, so the fix reaches visitors only as they update.
- Digiday reported on 27 October 2026 that Aditude saw eCPMs down 4% on iOS and 11% on Mac, and Permutive put ID-less Safari inventory at a 42% discount to Chrome in August.
Safari 27.2 fixes a bug that capped some first-party cookies at seven days. Apple's WebKit team listed the fix in its WebKit Features for Safari 27.2 post of 26 October 2026: 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. Once visitors update, those cookies should keep the lifetime the site sets.
The fix lands one day before Digiday published figures from several ad-tech vendors on what Safari's separate identity block is costing publishers. This article covers both: what Apple changed in 27.2, how it relates to Safari's long-standing defence against CNAME cloaking, what the Digiday data adds, and what is new compared with Relevant Audience's earlier Safari 27 coverage.
What Apple fixed in Safari 27.2
The WebKit post, written by Jen Simmons and dated 26 October 2026, says Safari 27.2 delivers 20 bug fixes alongside refinements to Customizable Select and a renamed Grid Lanes property. Under the Networking heading it lists one entry: "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. (183787115)". The same line appears under Networking, Resolved Issues, in Apple's Safari 27.2 beta release notes on the Apple Developer site, dated 13 October 2026.
Each part of that sentence matters:
- "A top-level navigation's own response" means the page the visitor actually loaded, not an embedded script, image or tracking request. These are the most first-party cookies a site can set.
- "CNAMEd to a different registrable domain" means the site's hostname, for example www.example.co.th, is a DNS alias for a hostname on another domain.
- "Capped to a seven-day lifetime" means that a cookie the server set to last, say, a year was cut to seven days by Safari.
Apple calls this a fix, which means the cap on these cookies was not intended behaviour. Apple did not say when the bug started, which earlier Safari versions were affected, or how many sites were hit.
Why a seven-day cap existed in the first place
The seven-day figure comes from Safari's defence against CNAME cloaking. In a WebKit post of 12 November 2020, John Wilander described CNAME cloaking as a site owner pointing one of its subdomains at a third-party domain through a CNAME record, so a tracker appears to be part of the first-party site. From Safari 14 (on macOS this enhancement was specific to Big Sur), Intelligent Tracking Prevention began capping the expiry of any cookies set in the HTTP response to such third-party CNAME-cloaked requests at seven days. Wilander's post says this aligns with ITP's existing cap on cookies created by JavaScript.
The 2020 rule was aimed at subresources: requests for scripts, pixels or other files sent to a subdomain that secretly resolves to a tracker. The table in that post shows a host without cloaking getting "No cap." The bug fixed in 27.2 is different. It caught the response to the top-level page itself when the whole site, not a tracking subdomain, sits behind a CNAME to another registrable domain.
Relevant Audience analysis, not Apple's statement: a common reason for a site's own hostname to be CNAMEd to another domain is that the site is served through a content delivery network or a hosted platform, where the provider asks customers to point www at a hostname on the provider's domain. Apple did not name any providers or setups.
What did not change
The release note describes one narrow fix. Nothing in the WebKit post or the release notes changes the seven-day cap on cookies set by JavaScript, the cap on cookies set through cloaked third-party subdomains, or the identity-resolution block Apple explained on 19 October. The 27.2 fix restores the intended behaviour for a site's own page responses; it does not loosen tracking prevention.
| Cookie type in Safari | Status after Safari 27.2 | Source |
|---|---|---|
| Set by the top-level page response on a site whose hostname is CNAMEd to another registrable domain | Seven-day cap removed (bug fix 183787115) | WebKit post, 26 Oct 2026; Safari 27.2 release notes |
| Set in responses to third-party CNAME-cloaked subresource requests | Seven-day cap, in place since Safari 14 | WebKit post, 12 Nov 2020 |
| Created by JavaScript | Seven-day cap that the CNAME rule was aligned with | WebKit post, 12 Nov 2020 |
| Set on a host with no cloaking | No cap from this rule | WebKit post, 12 Nov 2020 |
Who gets the fix, and when
The WebKit post says Safari 27.2 is available on iOS 27.2, iPadOS 27.2, visionOS 27.2, macOS 27.2 Golden Gate, macOS Tahoe and macOS Sequoia. On iOS, iPadOS, visionOS and macOS 27.2 it comes with the operating system update in Settings, General, Software Update. On older macOS versions, people can update Safari alone in Software Update by clicking "more."
That makes the timing depend on how fast visitors update. A visitor still on an older version keeps the old behaviour until they install 27.2. Apple gave no adoption figures.
What the bug may have done to analytics (analysis)
This section is Relevant Audience analysis of the mechanism Apple describes, not data from Apple.
The bug only touched cookies that the server sets in its HTTP response. Cookies written by JavaScript, which is how the standard GA4 tag stores its _ga visitor cookie, sit under the separate seven-day cap for script-set cookies that WebKit described in its 2020 post, and Safari 27.2 does not change that cap. So the analytics effect is limited to setups that set the visitor ID from the server, such as server-side tagging on the site's own hostname. Where that applies and the cookie disappeared after seven days, a Safari visitor who came back on day eight would look like a new user. On an affected site, that would push up new-user counts from Safari, cut the share of returning users, and break any attribution path longer than a week, because the earlier visit can no longer be linked to the later conversion. Cookies set by the server in the page response are also used for login sessions, shopping baskets and stored consent choices, so a Safari visitor on an affected site may have been logged out, lost a basket or seen the consent banner again after a week.
Apple has not quantified any of this, and there is no way to tell from the release note whether a given site was affected. A site owner can check the setup directly.
- Look up the DNS record for the main hostname. If www is a CNAME to a hostname on a different registrable domain, the site matches the condition Apple describes.
- In GA4 or another analytics tool, compare new versus returning users for Safari against other browsers over recent months, and watch whether the gap narrows as visitors update to 27.2. Annotate the 26 October release in reports.
- Check login and consent behaviour on a Safari device older than 27.2 after a week, if a test device is available.
Relevant Audience's GA4 implementation and audit service covers this kind of browser-level reporting check, and online stores can review basket and login persistence as part of e-commerce marketing work.
New data on Safari's identity block, from Digiday
The cookie fix runs in the opposite direction to the other Safari story of the autumn. On 27 October 2026, Digiday published an "In Graphic Detail" piece by Seb Joseph and Krystal Scanlon that gathers vendor data on what Apple's identity block in Safari is costing the ad market. The figures come from ad-tech companies, not from Apple, and cover their own customers and platforms.
Digiday recaps the background: after the latest iPhone software update, The Trade Desk's ads stopped loading in Safari because Apple blocked two web addresses, the Trade Desk ad server and the UID 2.0 identity system. ID5, LiveRamp, Permutive and Audigent were also cut off. In early October Apple partly restored the ad server, which Digiday describes as accidentally caught by the block, while UID 2.0 and the other identity vendors stayed blocked.
The vendor figures Digiday reports:
| Data source | Figure reported by Digiday |
|---|---|
| Aditude | WebKit browsers (Safari everywhere and every browser on iPhone and iPad) carry 30% of ad impressions and 28.5% of ad revenue across its customers |
| Aditude | Only 3.8% of impressions and 3.3% of Prebid revenue have moved to the updated WebKit so far; adoption grew by half in a week |
| Aditude | iOS bid rates fell 14% between 15 September and 8 October and are since down about 8%; Mac bid rates down about 25% |
| Aditude | eCPMs down 4% on iOS and 11% on Mac; revenue per ad opportunity down 6% on iOS and 20% on Mac |
| Permutive | Safari inventory without IDs traded at an average 42% discount to Chrome across more than 10 publishers and 569 million winning bids in August, wider on mobile |
| Permutive | IDs cover about 30% of the bid stream; publishers' own data lifted CPMs 76% on direct-sold deals and 32% on private marketplace deals across more than 80 publishers over 12 months |
| OpenX | US buyers' targeting spend on third-party audience data fell from 78% in 2022 to around 40% in 2025; contextual rose to as much as 35% |
Two cautions apply. Permutive is one of the vendors Safari blocked, and its figures support its own case that publisher first-party data can reach readers that IDs never covered. And none of the data is broken out for Thailand: the OpenX figures cover US buyers, and the Aditude and Permutive figures are not split by country.
What is new versus Relevant Audience's earlier coverage
Relevant Audience has followed Safari 27 through three earlier posts. On 19 July 2026 it reported PPC Land's account of Safari 27 blocking Bing and LinkedIn ad trackers at the IP-address level. On 2 October it covered the block on The Trade Desk's adsrvr.org domain and on identity providers including UID 2.0, ID5, Audigent, LiveRamp and Permutive. On 20 October it reported Apple's WebKit post of 19 October explaining that Safari 27 blocks identity-resolution infrastructure that turns login and newsletter emails into cross-site tracking IDs.
Two things are new here. The first is the 27.2 cookie fix, which none of those posts covered and which helps first-party measurement rather than restricting it. The second is Digiday's vendor data on bid rates, eCPMs and Safari discounts from several named companies. The 2 October post noted that its sources had not quantified lost impressions or spend; Digiday's piece now gives vendor estimates, with the caveats above.
What this means for Thai marketers (analysis)
For advertisers, the two Safari changes pull in different directions. The 27.2 fix should make a site's own first-party cookies more reliable for Safari visitors who update. The identity block keeps third-party identity vendors out. The practical message is the one both stories point to: measurement that runs on a site's own domain and its own customer data holds up in Safari, while cross-site identity does not. Brands buying programmatic media can also ask their partners how Safari and iPhone inventory is being priced and targeted now. For search campaigns, Relevant Audience's Google Ads management includes conversion-tracking checks that cover browser differences.
Frequently asked questions
What did Safari 27.2 fix about cookies?
Safari 27.2 stopped capping cookies set by a site's own page response at seven days when the site's hostname is CNAMEd to a different registrable domain. Apple lists it as bug 183787115 in the WebKit post of 26 October 2026 and in the Safari 27.2 release notes.
Does this weaken Safari's tracking prevention?
No, the WebKit post describes a bug fix for first-party page responses only. Nothing in Apple's notes changes the seven-day cap on JavaScript-set cookies, the cap on cloaked third-party subdomains, or the identity-resolution block.
How do I know if my site was affected?
Check whether your main hostname is a CNAME to a hostname on another registrable domain; if it is, the site matches the condition Apple describes. Apple did not say when the bug began or which versions were affected, so the analytics impact has to be checked in your own data.
Is Safari 27.2 available in Thailand?
Apple's WebKit post lists no regional limits and says Safari 27.2 ships with iOS 27.2, iPadOS 27.2, visionOS 27.2 and macOS 27.2, and as a separate update for macOS Tahoe and Sequoia. Visitors get the fix only after they update.
What does the Digiday data say about Safari ad prices?
Permutive told Digiday that Safari inventory without IDs traded at an average 42% discount to Chrome in August, and Aditude reported eCPMs down 4% on iOS and 11% on Mac. These are vendor figures for their own customers, not Apple data, and they are not broken out for Thailand.
Safari 27.2 is a quiet release, but for sites on a CNAME setup it may end a week-long cookie limit that nobody intended.
