[16:05:17] TimStarling: I'm thinking about the Googlebot exclusion we have for m-dot routing, - whether to convert it to the unified mobile router sooner (i.e. shorten the special period during which Google sees desktop layout and find out issues) or later (trailing behind the other changes and isolate it). I'm leaning toward the latter for the integrity of the experiment, but curious what you think [19:39:01] "two recent-ish deploys look related: disable $wgPHPSessionHandling, and SUL3: Use metawiki as central wiki", cc from #mediawiki-core-bots https://phabricator.wikimedia.org/T403519#11140947 [19:51:38] Lucas_WMDE: I suspect you may be mixing the hmac-encoded timestamp for the underlying cookie and secret in session data [19:52:16] It's normal that each time you ask for a token it looks different. view-source is sufficient to observe that in the user.tokens.set call. [19:52:46] It's not a new cookie, or new session, or new secret. [19:53:26] csrf token = hmac(secret, rand, timestamp) [19:54:04] validate = decode() && time-timestamp< maxage [19:54:49] The minted token isn't stored anywhere (not a nonce). [19:55:33] re Googlebot, so after the change you're referring to, Googlebot will see the mobile website through the non-mobile domain? [19:55:44] Krinkle: Lucas_WMDE is afk until tomorrow. please leave those comments on the task, it’ll be a big improvement compared to my confused flailing :) [19:56:20] TimStarling: yeah, that is, if/when we remove the temporary varnish condition we added. [19:56:36] Then mobile googlebot will see mobile variant indeed [19:57:35] As it presumably has been seeing outside commons for a year or so already, via redirect (which for whatever reason Google seems to tolerate on Wikipedia's but not commons) [19:59:11] I think it would be better to do that sooner, since it hasn't even finished crawling the whole desktop website yet [19:59:32] the time scale of any experimental period has to be ridiculously long, like months [20:00:58] I was going to say that Google is not loving our desktop website due to cumulative layout shift, but that was apparently fixed around August 19, some CentralNotice banner I guess [20:02:36] but in any case, when it takes months to crawl and reindex a site, it makes sense to try to make things as good and stable as possible so that users will see those benefits [20:10:18] Krinkle: fyi I copied your comments into the task [20:10:40] currently trying to figure out where the salt comes from (I’m assuming it’s relatively static but the call chain is tricky to follow so far) [20:11:22] hey. let me look [20:12:21] ok yeah the token salts seem pretty static (e.g. ApiQueryTokens::getTokenTypeSalts()) [20:12:48] regarding the recent deploys: "disable $wgPHPSessionHandling on group1" should only affect group1, so not wikidata. "SUL3: Use metawiki as central wiki" should also be a no-op for wikidata, as the code using that config is new in wmf.17 [20:13:04] wikidatawiki is group1… [20:13:43] actually, let me just test if I can reproduce the quickcategories issue on enwiki [20:13:52] oh. hmm [20:14:18] yeah, let's compare to enwiki [20:14:55] anyway, wmf.17 is not on wikidata yet, so that second deploy should still be a no-op. the first one is suspicious [20:15:01] enwiki still works https://en.wikipedia.org/w/index.php?oldid=1251769135&diff=1309218088 [20:16:00] i tried your apisandbox test on enwiki: https://phabricator.wikimedia.org/T403519#11141031 and it also gives me different tokens every time [20:16:43] i feel like they used to be more stable... but this can't be the reason for the problem then [20:17:12] that’s to some extent expected according to Krinkle [20:17:24] although, if I’m fast enough, sometimes I get the same token on enwiki [20:17:25] anyway. https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1183741 ("Set $wgPHPSessionHandling to 'disable' on group1 wikis") is safe to revert. if the timing matches up, we could just do that first and see what happens [20:17:29] (before the timestamp ticks, I think) [20:17:35] ok sure [20:17:49] oh hey there’s a backport window right now [20:17:51] unfortunately it looks quite full [20:17:58] * lucaswerkmeister saunters over to #wikimedia-operations [21:25:59] (FTR, reverting that config change indeed fixed the issue on group1. see further discussion in -operations) [23:23:07] I've drawn up the next m-dot phase in a bit more detail meanwhile [23:23:23] at https://phabricator.wikimedia.org/T403510 [23:24:13] The main factors I considered are: cache invalidation cost, and likelihood of gadget issues people find and ask for help with [23:31:26] I went roughly in order of monthly edits, ie activity/size of the family and canaries to do earlier, noting that Wikidata and Commons feel like they have most potential for gadgets and stuff hitting something unexpected, although gadgets on mobile are much less of a thing still [23:31:45] Thoughts/ideas welcome :) [23:32:45] would you want to drop a note about that in our team (slack) channel as well, for visibility to those folks? Krinkle