Codex automatically focuses the first focusable element in a dialog when the dialog opens (OOUI does the same). This makes sense for inputs, but maybe not for links.

I've separated the implementation of the mechanism into a subtask (T400579), so that we can later add additional subtasks under here for the rollout itself (increasing the percentage of users who have 2FA enabled from 0% to 10%, probably with steps in between).

As discussed in the parent task (T399664), I think the best way to do this would be a UserGetRights hook listener that adds the oathauth-enable right based on the last two digits of the user's central user ID.

In T399665#11037015, @Tgr wrote:

Wrt accidentally locking yourself out, this will help in the situation where the user sets up 2FA on a desktop computer and then needs to log in on a different desktop computer. What happens if the user sets things up on a desktop, chooses their phone as a roaming device (as most people probably will), and then needs to log in on the phone? Can the mobile browser use its current platform as a roaming authenticator?
What about the opposite direction (I want to set it up on the phone and will need it elsewhere)?

I tested this a little bit today, and at least on Android, it creates a passkey on my phone that it then stores in the Google Password Manager, which then syncs to my desktop machine (since I'm logged into the same Google account on both, and have sync set up), so both devices can log in fine. I tried storing my passkey in a different Google account without sync set up, and that almost locked me out in that the only way I could get in was by logging in from the phone that had the passkey on it. I think that's weird and dangerous (it means you can no longer log in on the device where you completed the setup flow), but I'm not sure if there's anything we can do to prevent Chrome from presenting this option.

Retitled because the same thing happens when you enter a TOTP code. It's a little bit less bad there because the user did type the code and press Enter or click the button, but we should still have a progress indication there too.

In T400300#11029631, @Volker_E wrote:

@DTorsani-WMF has already been asked for feedback and agrees with the architecture logic this task is asking for. Want to put this in front of you @Catrope as well for visibility/feedback.

In T396941#10993384, @Reedy wrote:

reedy@ubuntu64-web-esxi:~$ sudo docker image pull docker-registry.wikimedia.org/dev/bookworm-php83-fpm:1.0.0

We should also consider what we want to do with the existing translations of this message (it's been translated to 16 languages besides English already). If we just update the English version of the message and don't do anything else, users in those 16 languages will continue to see the old version referring to ca@, until a translator comes along and re-translates the message. If that is undesirable and we want to funnel people into the new form faster, we could consider deleting the existing translations (or creating a new message with a new name), so that users will instead see the correct link but in English (until someone translates it).

I've attempted to clarify the task description. I would also suggest that it might be easier not to add the randomly selected users to the oathauth-tester group, but instead to use a UserGetRights hook that just adds the oathauth-enable right directly if the last two digits of the user ID are less than 05 or whatever.

I proposed this as a temporary step after talking to @EMill-WMF (but to be clear I didn't run this exact proposal by him yet, so he should weigh in). @EMill-WMF said that we should discourage people from setting up non-portable passkeys (ones that are only in one browser / on one device and are not in a password manager or similar), because the risk of getting locked out is too high, especially while we don't support multiple authenticators and don't provide recovery keys when a passkey is set up. Once we support multiple authenticators, we could then allow non-portable authenticators to be set up as long as the user already has a portable auth method (either a portable passkey, or a hardware key, or a TOTP-based method).

Sorry for the delay in closing this but this is done, I tweaked the dashboards last week.

Closing this task because Codex-PHP has been added to MW core and MW vendor. Announcing it (and the additional work we need to do before we can do that) is tracked separately as T399523.

I suggest that we decline this task, and instead just suppress/ignore the dependency on Intuition when loading Codex PHP in MediaWiki. See my latest updates to the vendor patch and the MW core patch. H/T to @Reedy for pointing me to replace and how it can be used to ignore packages.

Thank you @SomeRandomDeveloper for fixing this so quickly!

New task: T397786