iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://phabricator.wikimedia.org/T344791
⚓ T344791 Get rid of ss0- SameSite cookie prefix hack
Page MenuHomePhabricator

Get rid of ss0- SameSite cookie prefix hack
Closed, ResolvedPublic

Description

The Chrome devs added support for SameSite cookie options before the spec was finalized. Then they changed the spec in an incompatible way and implemented the new spec. Then they updated Chrome again in a way which breaks all sites sending cookies without the SameSite option. The end result is that you can choose to either support old Chrome or new Chrome, there's no way to send a single cookie which will work in both kinds of browser.

So for T252236 we added duplicate cookies prefixed with ss0, which work on old Chrome but not new Chrome, while the unprefixed cookies work on new Chrome.

Removing the cookies would reduce request sizes and would simplify the relevant code.

In T252236#6273311 I reported usage statistics for the affected browsers, which I can now update:

Browser2020-06 page views2023-08 page views
iOS 122.5%0.20%
Chrome 51-660.3%0.18%
Safari on Mac OS 10.140.4%0.04%

How do we feel about breaking login for 0.41% of users?

Event Timeline

Since it is a configuration setting ($wgUseSameSiteLegacyCookies), we may need three steps to remove it:

  1. deprecate it
  2. turn off in production
  3. remove it

Old Chrome interprets unknown SameSite values as Strict; a SameSite=Strict session cookie will break all cross-site features, including central login, and will result in somewhat erratic behavior (when arriving to the wiki from an external link, you get an anonymous page view but upon reload you will be logged in); but local login and all local features should still work. So IMO inflicting that on half percent of our userbase (probably less as I would expect logged-in users to use more modern browsers on average than readers) doesn't seem to me like a big deal.

Hm, https://www.chromium.org/updates/same-site/incompatible-clients/ says that old Safari will interpret SameSite=None/Lax as SameSite=Strict but old Chrome will reject the cookie entirely. So for 0.18% of users we'd properly break login. Still acceptable IMO.

Change 989265 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[operations/mediawiki-config@master] Disable SameSite legacy cookies

https://gerrit.wikimedia.org/r/989265

What's the effect of this in older browser? This may need a user notice. Also, we may want to deprecate (and eventually remove) it from MediaWiki.

Note if user can not log in completely, we may want to remove these browser from Grade C support. However login may be working without $wgCookieSameSite (which is default in MediaWiki installations), just not in Wikimedia wikis.

What's the effect of this in older browser?

In Chrome 51-66, users will not be able to log in. In the other old browsers, users may have to log in to each domain separately.

Note if user can not log in completely, we may want to remove these browser from Grade C support. However login may be working without $wgCookieSameSite (which is default in MediaWiki installations), just not in Wikimedia wikis.

FWIW, Grade C support for Chrome is 31+ (2013 or later). Chrome 67+ would be 2018 or later. That's a bit more recent than most other browsers (usually 2015 or later) but still it's five years old which, given Chrome's aggressive updating, seems like a lot. If one can believe Wikipedia, the only platform where it's not possible to upgrade to 67+ are Windows Vista but you can get to 51 is iOS 9.x.

But yes, even if the functionality is removed from core, it won't affect MediaWiki sites with default settings.

Re: Tech News/user-notice - What wording would you suggest as the content, and When should it be included? Thanks!
My best guess is something like this. If you can simplify/improve this, or fix any errors and then confirm it is good, that'd be appreciated:

Future changes

  • In the future [??], it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016–2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately.

Sounds good to me. @tstarling do you have a target date?

How about January 17?

Changes later this week

  • Starting on January 17, it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016–2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately.

Change 989265 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable SameSite legacy cookies

https://gerrit.wikimedia.org/r/989265

Mentioned in SAL (#wikimedia-operations) [2024-01-16T23:55:48Z] <tstarling@deploy2002> Synchronized wmf-config/CommonSettings.php: Disable wgUseSameSiteLegacyCookies T344791 (duration: 09m 19s)

Mentioned in SAL (#wikimedia-operations) [2024-01-17T00:03:43Z] <tstarling@deploy2002> Synchronized wmf-config: T344791 related cleanup (duration: 06m 22s)

Change 991101 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] Remove $wgUseSameSiteLegacyCookies

https://gerrit.wikimedia.org/r/991101

The next step may be to deprecate the setting in core MediaWiki.

Change 991104 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] Remove $wgUseSameSiteLegacyCookies

https://gerrit.wikimedia.org/r/991104

Per T355596: Prolonging sign-in/login at Wikipedia and Commons no longer possible on Safari 12 via iOS 12 this also reduces the central session lifetime to one day in affected non-Chrome browsers (because CentralAuth has this weird authentication flow where the login mostly happens locally but the "remember me" flag is set in a separate call to loginwiki). They also end up on a Special:CentralLogin error page.

We should probably do some UA sniffing and show a message telling the user to upgrade.

Change 991101 merged by jenkins-bot:

[mediawiki/core@master] Stop using $wgUseSameSiteLegacyCookies

https://gerrit.wikimedia.org/r/991101

We should probably do some UA sniffing and show a message telling the user to upgrade.

On second thought, I don't think it's worth the effort. The code wouldn't be very complicated (Google has some sample code for it here, or in readable form here) but annoying to test (it would require an iOS device or emulator, and two wikis with different registrable domains with CentralAuth set up between them), and it doesn't really make sense to remove the B/C code to actually handle these cookies and then re-add B/C code that tells the user we are not handling them. And all we could do is to say "you need a newer browser", which isn't all that helpful.

The effect would be minimal anyway - there are about 100 central login session losses per day, and the SameSite B/C change had no visible impact on their volume:

Screenshot from 2024-02-06 22-51-57.png (940×3 px, 231 KB)
(graph, the vertical line is the time of deployment), so we are talking about maybe a few logins per day.

Change 991104 merged by jenkins-bot:

[mediawiki/core@master] Remove $wgUseSameSiteLegacyCookies

https://gerrit.wikimedia.org/r/991104

tstarling claimed this task.