Bug 273193 – Safari Intelligent Tracking Prevention is breaking same-site cross-subdomain sync for Transcend Consent Manager

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Website Storage

[Eli Grey (:sephr)]

Safari Intelligent Tracking Prevention is breaking same-site cross-subdomain sync for Transcend Consent Manager customers. Transcend Consent Manager uses same-site iframes and a postMessage protocol to sync consent cross-domain on a site. Transcend Consent Manager does not use cookies to sync consent, as this helps to avoid unnecessary leakage of user choices over the network.

When ITP is disabled, sync works fine such that subdomain1.example.com can sync consent through consent-sync.example.com and subdomain2.example.com can then resolve consent stored at consent-sync.example.com. When ITP is enabled, consent-sync-example.com gets a different storage partition for each subdomain that requests it, which is incorrect behavior.

To reproduce the issue:

- Open two tabs & attach devtools to each tab

1. verizon.com
2. activate.verizon.com

- in tab 1's devtools console, enter:
console.log(airgap.getConsent().purposes)
addEventListener('click', airgap.optOut, {once: true})

- click anywhere in the empty space for tab 1 to set full opt out consent

- in tab 2's devtools console, enter the following JavaScript:

await airgap.sync();
console.log(airgap.getConsent().purposes)

- The return value should be all false values (no `true` or `Auto` values), indicating that the opt out successfully synchronized cross-subdomain.

Other browsers including Firefox and Chrome are not exhibiting this incorrect partitioning behavior for Transcend and its customers.

[Eli Grey (:sephr)]

With ITP debug mode enabled, I see the following logs in my console on verizon.com when Transcend Consent Manager attempts to sync: "[ITP] Applying cross-site tracking restrictions to: [doubleclick.net, rlcdn.com, clickagy.com, crwdcntrl.net, 3rdpartytestwebkit.org, google.com, transcend.io]."

[Radar WebKit Bug Importer]

<rdar://problem/126994753>

[Matthew Finkel]

Hi Eli, thanks for reporting. Which type of storage is being used for caching this information?

[Eli Grey (:sephr)]

The type of storage being used is localStorage.

[John Wilander]

(In reply to Eli Grey (:sephr) from comment #4)
> The type of storage being used is localStorage.

I believe our storage partitioning is based on origin, not site, and that it always has been. If so, that’s since 2013, long before any other browsers partitioned storage.

[Matthew Finkel]

And I don't believe we provide a way to disable that localstorage partitioning, so I'm confused as to why disabling ITP fixes this. I want to look into that. But overall, as John indicated, I suspect this has never worked and it was designed in a way that is incompatible with Safari.

[John Wilander]

”Prevent cross-site tracking” is not an ITP switch. It enables/disables all tracking protections, including ITP, partitioning, and the cookie policy. That’s at least my understanding. But Matthew has worked on our partitioning much more recently so he’ll get to the bottom of it.

[Eli Grey (:sephr)]

Thanks for the clarifying what the "Prevent cross-site tracking" option does.

If this is intentional, what is the recommended solution to sync data from subdomain1 to subdomain2 through an intermediary sync subdomain, all on the same site, without the data leaving the browser.

We don't want to leak user data over the network with cookies. It should be possible to sync data across a site 'offline' without sending that data over the network.

[Eli Grey (:sephr)]

I would also like to note that this sync system previously worked in Safari as of a few months ago, at least in Safari 16.x iirc

[Matthew Finkel]

Hi Eli,

Thanks again for these details. I refreshed my memory on how we partition localstorage, and we do disable partitioning when Safari's "Prevent cross-site tracking" setting is disabled. This explains why the data is available within the same site.

I also tested this in Safari 16.4 and 16.1, and I do not see this syncing behavior working there, either.

As John mentioned, Safari/WebKit have partitioned by origin since 2013, so it is incorrect to say that Safari is exhibiting incorrect behavior, later Firefox and Chrome chose a different and more relaxed site boundary.

We're still investigating ways to help developers safely share data within the same site. Using postMessage may be one alternative in the mean time.

[Eli Grey (:sephr)]

Thanks for the follow-up. How would postMessage help two subdomains of one site share data if each subdomain gets a different partition?

[Eli Grey (:sephr)]

Also, if the design intention of WebKit's partitioning system is to partition by origin,  shouldn't the wording of the "Prevent cross-site tracking" toggle be "Prevent cross-domain tracking" to imply to users cross-domain (and not just cross-site) tracking is being prevented?

[Eli Grey (:sephr)]

> it is incorrect to say that Safari is exhibiting incorrect behavior

I posit that it's incorrect to incentivize the use of cookies by partitioning them more preferably than other storage mechanisms.

I understand that this may be outside the scope of this issue, but I genuinely want to understand the reasoning that justifies the preference of storage mechanisms that cause network emissions over those that do not.

Currently, Firefox and Chrome allow same-site subdomains to share state without additional network calls or the use of cookies.

Every non-WebKit browser's cross-site tracker blocking features block cross-site tracking, but not all cross-domain tracking.

I'll file a separate bug report for your toggle that supposedly toggles cross-site tracking to be modified to either be renamed to "Prevent cross-domain tracking" or for the partitioning model to be corrected.

[John Wilander]

We started partitioning HTML storage when the feature was new to the web (implementation in 2012, shipped 2013). The main reason for storage and cache partitioning was to not further compound the problem of tracking on the web. The natural security boundary for the web is origin and so it was used for partitioning. It would be great for web security and privacy if origin was the consistent boundary.

However, cookies are much older, dating back to the 90s. The cookie attribute "domain" combined with the advent of the Public Suffix List established website, or registrable domain, as the boundary for cookies. Thus it has never been considered web compatible to restrict cookies to origins.

The current belief in the web community is instead that we'd have to replace cookies with something else to get what's called origin-bound session identifiers. That's where Mike West's now obsolete "HTTP State Tokens" proposal came from: https://datatracker.ietf.org/doc/html/draft-west-http-state-tokens-00

As you can see, we ended up here by trying to make the best decisions for the web as the platform evolved.

[Eli Grey (:sephr)]

John, is syncing data privately same-site without cookies a currently supported or planned use case of WebKit?

[Eli Grey (:sephr)]

If the answer is no, and if WebKit has no immediate plans to replace cookies or change how they work, then the net effect is a loss of privacy on the web as developers end up using cookies to fill this gap.

I believe that, barring a declaration to partition/replace/deprecate cookies, WebKit's current storage partitioning model effectively encourages privacy-harmful behavior among site owners by incentivizing the use of cookies to share state across subdomains.

[John Wilander]

(In reply to Eli Grey (:sephr) from comment #15)
> John, is syncing data privately same-site without cookies a currently
> supported or planned use case of WebKit?

As already mentioned above, you can use postMessage for this. I know you've mentioned persistence of partitioned data but that's not what you're asking about here.

We do not make commitments to changes or plan in open source. However, your feedback has been well received and we always take developers' input into account.

> If the answer is no, and if WebKit has no immediate plans to replace cookies or
> change how they work, then the net effect is a loss of privacy on the web as
> developers end up using cookies to fill this gap.

You can use postMessage, as mentioned.

> I believe that, barring a declaration to partition/replace/deprecate cookies,
> WebKit's current storage partitioning model effectively encourages privacy-harmful
> behavior among site owners by incentivizing the use of cookies to share state across
> subdomains.

Feedback noted. As mentioned, the origin boundary is typically favored by browsers, not in the least to decrease the pressure on the Public Suffix List. A good way forward may be to see if other browsers can partition by origin rather than site. I believe they have expressed a desire to do so but have not looked for supporting statements in standards issues.

The historical mistakes around how cookies work are well-known. They are rarely a good guide for how to develop modern web features.

[Eli Grey (:sephr)]

Clarification: I was using 'sync' to mean 'share and persist'.