The goal of T348388: SUL3: Use a dedicated domain for login and account creation is to end up with a login/signup flow that provides unfettered access (as much as possible) to cookies on the central login domain. The more straightforward part of that is ensuring that users interact with the central domain (which is done my moving the login form over there), but there are a number of choices beyond that will influence cookie access limits on various browsers. This task is about pinning down the details of the login and signup flows that are relevant in terms of browsers' third-party cookie blocking policies. (This might end up needing no work, if the user interaction pattern is enough in itself to enable cookie access, or maybe something like Storage Access API calls. At the very least it involves testing the login and signup flow with aggressive cookie blocking settings, including behavior that's still feature-flagged in Chrome.)
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T345245 Mitigate phase-out of third-party cookies in Wikimedia production | |||
| Resolved | Tgr | T345249 Mitigate phase-out of third-party cookies in CentralAuth | |||
| Resolved | OWresch-WMF | T348388 SUL3: Use a dedicated domain for login and account creation | |||
| Declined | None | T364867 Determine SUL3 cookie exchange mechanism | |||
| Resolved | JTweed-WMF | T359926 Test cross-domain cookie access with the Storage Access API and Related Website Sets | |||
| Declined | None | T360104 Test cross-domain cookie access with OAuth-style popup + redirect workflow |
Event Timeline
Chrome rolled out HTTP header support for the Storage Access API in 133. Previously getting access to cross-domain cookies (that didn't meet one of the other conditions such as past user interaction or redirect heuristics) required a JS call, which meant you'd have to show some kind of interstitial for e.g. autologin, since you can't run JS during a redirect chain. Now, in some cases, you can just slap Activate-Storage-Access: retry on the response instead.
If I understand the spec currently, it's still not quite useful for us in its current form, because it requires showing the user a permission popup at some initial point. You can use RWS + requestStoreAccessFor() to avoid that, but the header only replaces requestStoreAccess(), not requestStoreAccessFor(). Hopefully that will change in the future.