Third-party cookies are a set of cookie-based mechanisms for sharing information between websites which are on different domains. Adware and web analytics vendors use third-party cookies to track people's internet activity across many different websites; this has long been criticized by privacy advocates. All major browser vendors have committed to prevent such tracking, and for several years have been in a slow process of rolling out increasingly stringent limitations on third-party cookie use.

Wikimedia properties span many different domains, and while our use case is not objectionable (the privacy objections are about websites operated by different organizations sharing personally-identifiable information about their visitors, not different websites run by the same organization sharing it), our mechanisms are the same as used by the adtech industry; we aren't being internally targeted, but we are very much being affected by the restrictions nevertheless. We need to map how we will be affected, and mitigate negative effects; this will probably take significant effort.

Affected functionality

• CentralAuth autologin
• probably CentralNotice banners?
• ???

Browser restrictions

(As of 2023 August; they are changing over time. Also, they are influenced by use of incognito mode and other, browser-specific configuration options such as "" in Chrome or "Enhanced Tracking Protection" in Firefox; and the exact effect of those settings / modes also changes over time.)

The main mitigation is either fully blocking or state partitioning third-party cookies. Browser vendors today define third-party cookies as cookies which belong to a different eTLD+1 / registrable domain than the page the user is visiting, but a resource (such as an image, script or iframe) from that different domain is embedded in the current page. State partitioned cookies (Privacy CG explainer) are only accessible within the context of the same top-level page, so e.g. login.wikimedia.org when visited directly and login.wikimedia.org when embedded as an invisible pixel in en.wikipedia.org see completely different cookies.

• Chrome:
  • Doesn't limit third-party cookies currently by default.
  • With the "Block third-party cookies" user preference enabled, fully blocks third-party, and state-partitions cookies which indicate support via CHIPS.
  • Plans to make that default by mid-2024, with 1% rollout in 2024 Q1
  • When third-party cookie blocking is enabled, plans to prevent reading/writing cross-domain cookies via top-level redirect ("bounce tracking mitigation") unless the user has directly interacted with the other website in the last 45 days. Planned to land in Chrome in 2023 Q3.
• Safari:
  • Blocks third-party cookies by default since 13.1 / 2020 March. Before that it had a feature called Intelligent Tracking Prevention which used a set of complex heuristics (including some machine learning) to dynamically classify domains as trackers.
  • Intelligent Tracking Prevention logic is still used to detect bounce trackers, in which case cookie lifetime is reduced to 24 hours.
• Firefox:
  • Uses state partitioning (sometimes referred to in FF docs as dynamic first-party isolation or Total Cookie Protection) for third-party cookies by default since FF 112 / 2023 April. (Earlier it was enabled for the "Strict" setting of the "Enhanced Tracking Protection" user preference in FF 86 / 2021 February, in private browsing mode in FF 89 / 2021 June, via a prompt in FF103 / 2022 July, and default on Android only in FF 107 / 2022 November.) Users can opt out per-site. There are exceptions such as popups.
  • Blocks tracking domains listed by disconnect.me ("Enhanced Tracking Protection").
  • Redirect tracking protections is similar to bounce tracking mitigations in Chrome and Safari, but mostly limited to known trackers. Starting with FF 133, in strict Enhanced Tracking Protection mode, it's applied to all domains. (source docs, MDN docs.)
• Edge: not much documentation; it has a "Block third party cookies" setting, which seems to be off by default, but allegedly on in private mode since Edge 86. A manual test confirms this.
• Opera: also not much documentation; it has a "Block third-party cookies" user preference, some random forum threads claim it's off by default but on in private mode. A manual test confirms this.

Testing / debugging browser restrictions

• Chrome: instructions, more instructions
• Firefox: instructions, user instructions

Mitigation options

• First-party sets (spec, WICG explainer, chromedev explainer and developer guide) allow a set-of domains to indicate that they have the same owner. Browsers might use this to allow cross-domain cookie access between such domains. This would be a very low-effort means of mitigation, if it happens.
  • status: behind a feature flag in Chrome, but Firefox and Safari are opposed. Also, in the fairly similar case of storage partitioning it was explicitly rejected by Chrome as well - not sure what's the exact difference between the "security boundary" concept cited as the reason for that, and domain boundaries in general.
• CHIPS (Cookies Having Independent Partitioned State) (Privacy CG explainer, chromedev): enables state partitioning on browsers which don't support it by default (and would just reject third-party cookies instead). This is useful for data sharing between two specific domains, but not useful for sharing between a larger set of domains so probably not useful for us.
  • status: (caniuse, chromestatus) available in Chrome and Edge, other browser vendors are supportive
• Use the requestStorageAccess() or requestStorageAccessFor() API, which allow access to third-party cookies. (requestStorageAccess is better supported, but needs to be called by the embedded resource, so it's only usable for iframes; requestStorageAccessFor is called by the embedder.) These would probably be part of using first-party sets, but can be used without those as well; however, then they would require explicit user opt-in (and separately for each domain), making them less practical. Also, they can only be called after user interaction.
  • support: requestStorageAccess (caniuse) is supported in Firefox and Safari, supported but requires first-party sets in Edge, behind a feature flag in Chrome. requestStorageAccessFor is Chrome-only (chromestatus).
• SameParty cookie attribute (spec): this seems quite dead, listing for completeness only as it's sometimes referenced by other specs.
• There might be other web APIs that can replace third-party cookies for some specific use-case but not generally, to be discussed in subtasks.
• We could also just reimplement affected features to not use third-party cookies anymore. This probably requires significant infrastructure changes - anything that can support a workflow that's similar to third-party cookies is itself a candidate for ad tracker tech and as such a target of similar mitigations.
  • Specifically, using a top-level redirect instead of a subresource can be a relatively lightweight change, and browser are currently somewhat more permissive with third-party cookie access in that case; but that is unlikely to last long.

See also

• T255366: SameSite cookie issues is another browser behavior change with somewhat similar effects, but it has different objectives and is relatively easy for us to mitigate.
• T295073: <Org-Wide Impact> Google Chrome User-Agent Deprecation Impact is another browser behavior change with similar objectives, but different effects; mainly a problem for anti-abuse.