Under Privacy -> Website tracking, the toggle option for "Prevent cross-site tracking" implies that 'site' is the partition boundary, and that this checkbox will only 'prevent cross-site tracking'. Instead, this on-by-default privacy setting prevents cross-domain tracking as well as cross-site tracking. I was genuinely confused by this setting myself. Please adjust your partitioning model to reflect the expected user assumptions for storage partitioning given this option title. Most storage mechanisms should be partitioned using site instead of origin; not just cookies. This cookie-preferential partitioning policy may have had a negative impact on the privacy practices implemented in practice for web applications developed in the past 13 years. Developers that want to implement the easiest cross-browser solutions may simply expose data over the network using cookies. In Firefox and Chrome, they can also use postMessage + non-cookie-storage solutions to privately share state across subdomains. ( Related to but not a dupe of https://bugs.webkit.org/show_bug.cgi?id=168631 )
WebKit is the open source web engine in several applications. For Safari application feedback, please use Apple's Feedback Assistant. There are at least two ways to prevent cross-site tracking, either partition or block cross-site website data and cache. Since the least strict tracking prevention WebKit has is at the site level, specifically blocking cross-site cookies, it is correct to call the over all protection prevention of cross-site tracking. The fact that WebKit has more strict preventions such as cross-origin partitioning doesn't change the fact that the prevention is only effective at the site level. WebKit does not partition cookies. There is the CHIPS standards proposal which may result in a future where WebKit partitions cookies. postMessage to share cross-origin same-site state, i.e. across subdomains, works with WebKit too. Let us know if that's not the case.
> postMessage to share cross-origin same-site state, i.e. across subdomains, works with WebKit too. Let us know if that's not the case. The lack of persistence is what I'm referring to here. https://bugs.webkit.org/show_bug.cgi?id=273193 is about Transcend Consent Manager not being able to sync consent data privately *same-site*. Is syncing data privately same-site without cookies a supported use case of WebKit, or do I have to use cookies? When configured appropriately, Transcend Consent Manager uses a same-site iframe to sync consent using postMessage and localStorage. It works perfectly fine in Firefox and Chrome.
John: If there are no plans to adjust the partitioning model, I think the proper solution to this issue is two-part: 1. Rename "Prevent cross-site tracking" to "Prevent cross-domain tracking" or "Prevent cross-site and cross-domain tracking" to correctly convey the effect of this privacy feature to users. 2. Split out ITP as its own toggle. Binding it together with this toggle is very confusing to developers.
It's also pretty confusing to have such a prominent user-facing toggle that entirely disables the partitioning model without any click-through warnings, making Safari significantly less private than Firefox and Chrome when disabled. It would make much more sense in terms of supported use cases to have a feature that simply relaxes Safari's partitioning model in parity with other browsers, instead of a dangerous 'allow all cross-site tracking' feature. Is this toggle actually used by any common user workflows? It seems very dangerous and 'overkill' tbh.
(In reply to Eli Grey (:sephr) from comment #3) > John: If there are no plans to adjust the partitioning model, I think the > proper solution to this issue is two-part: As mentioned, we don't discuss plans or non-existing plans here. > 1. Rename "Prevent cross-site tracking" to "Prevent cross-domain tracking" > or "Prevent cross-site and cross-domain tracking" to correctly convey the > effect of this privacy feature to users. I already explained why "prevent cross-site tracking" is correct above, at 2024-04-29 17:07:47 PDT. > 2. Split out ITP as its own toggle. Binding it together with this toggle is > very confusing to developers. This is not a WebKit request but a Safari request. Please use Apple's Feedback Assistant if you want to pitch a change to Safari. Resolving since there is nothing more to do here.