Meta:Requests for comment/Enable 2FA on meta for all users

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
The following request for comments is closed. There is no consensus to do this. Meta:Requests for comment/Create a 2FA tester local meta usergroup remains open. --MF-W 08:55, 14 August 2020 (UTC)

Statement of the issue[edit]

Basically just what it says on the tin. This will enable any user that purposefully comes here to meta: to activate two-factor authentication. While this is still "experimental" in practice anyone that comes here is getting rubber stamped by stewards and having this enabled. This should eliminate having to have stewards manage the "global testers" group as well. While 2FA is still in beta, people want it. We can include all the warnings etc we want on the sign up page. By enabling this only locally, it should prevent most clueless people from activating it on other projects (compared to if it were enabled globally).


  • Support Support as proposer. — xaosflux Talk 18:39, 29 November 2018 (UTC)
  • I don't think this is sustainable as long there is no scalable process for people to recover their account. Already with the recent push for two-factor authentication for privileged accounts we keep seeing users who lose access to their account and flood IRC or various support channels to get ad hoc support. Nemo 18:51, 29 November 2018 (UTC)
  • Support Support I see benefits and no drawbacks. This should reduce overhead per the proposal and increase security. Slam dunk. Edit conflict: Hm. Maybe there wouldn't be a reduction in overhead...Justin (koavf)TCM 18:51, 29 November 2018 (UTC)
  • I think security folks for now prefer not to allow all users access the 2FA feature IIRC. It is experimental and there's no way to self-recover your account if you happen to loose the 2FA device and the scratch codes (which has surprisingly happened to a lot of experienced people) without having to issue commands directly to the database. If we happen to enable this for all now, I expect the number of requests for 2FA reset to increase a lot, which is a process by itself very sensitive to social engineering. That'd strenghten even more the checks Trust and Safety do before removing 2FA from any account, and I fear many users will effectively loose their accounts (and yes, if they didn't read the instructions it's their problem, still it'd be a problem for us all). I can not oppose because asking people to consider having their accounts more secure is good, but I cannot support now for the above mentioned reasons. Regards, —MarcoAurelio (talk) 18:54, 29 November 2018 (UTC)
    @MarcoAurelio and Nemo bis: - I agree that there is a support problem here - but unless the stewards stop approving anyone who asks what do you see is the difference? — xaosflux Talk 18:56, 29 November 2018 (UTC)
    I cannot reply on behalf of my colleagues, but I do look at CentralAuth data about the user before giving the permission. If the account is too new, I reject the request as it is highly likelly that the user won't know how to use the feature nor what a committed identity is, etc. I think my fellow stewards do the same. Thanks. —MarcoAurelio (talk) 19:02, 29 November 2018 (UTC)
  • @Rschen7754: All users? Even 0-edit users? --Rschen7754 19:18, 29 November 2018 (UTC)
    Perhaps auto-confirmed (which another RfC is looking to change to 4days/5 edits here). — xaosflux Talk 19:30, 29 November 2018 (UTC)
  • I think we should find a middle ground between allowing everyone to access it and requiring people to request it on SRGP. Losing scratch codes is still a serious limitation and would exponentially increase dev time if it was introduced to the general public. What about making a sub-page of SRGP for 2FA access requests, where users just need to read a documentation page and sign their name on a list? We could even have some fancy JS to help them do it, and get them to leave a reason for the request and maybe even have some minimum standards (500 edits across Wikimedia for example). That might be a bit less daunting than an ambiguous request on the big SRGP page. – Ajraddatz (talk) 19:28, 29 November 2018 (UTC)
    @Ajraddatz: "everyone" is a bit much, this would at least require someone to purposefully come here to meta to enable it. (And perhaps require auto-confirmed?). For reference, the last user approved at SRGP had 140 global edits. — xaosflux Talk 19:33, 29 November 2018 (UTC)
    I would be more OK with autoconfirmed. And fair point, I just pulled 500 out of the air. – Ajraddatz (talk) 19:37, 29 November 2018 (UTC)
    @MarcoAurelio and Ajraddatz: if the hold back is because WMF says they can't deal with recovery requests - why are people still being added? Have they given any specific thresholds for number of testers, amount of effort they will commit? — xaosflux Talk 19:41, 29 November 2018 (UTC)
    Under the current system, non-admins need to understand what 2FA is and understand where to request it before being granted access. This means that in practice very few people are added each year, and those that are added generally know what it is and the risks of losing their scratch codes. This means that they do not take up dev time, because they know to save their codes in a secure place. Introducing it more publicly would allow less informed users to activate 2FA, leading to possible issues with forgetting scratch codes and dev time being taken up with account recovery. Or so is the concern. TL;DR there are minimal recovery requests generated under the status quo – Ajraddatz (talk) 19:44, 29 November 2018 (UTC)
    Thanks, If this is a WMF resource issue, I'm OK to shut down this RfC since even if community approved it will get denied. — xaosflux Talk 19:46, 29 November 2018 (UTC)
    We don't need to shut down discussion right away. This shows that there is significant community desire for 2FA to be more accessible, so it's worth us doing something to make life easier on people who want to secure their account. I'll make a table below that shows the various options that have been presented here, and how they would relate to the problem of recovery time. – Ajraddatz (talk) 19:50, 29 November 2018 (UTC)
    "Purposefully come" as 22 million registered users on Meta-Wiki? :) Accounts are global, it doesn't matter much where you enable 2FA. I can't see an automatic threshold as being useful. Even someone with 100k edits may not have a committed identity or any user able to confirm their identity. Nemo 21:53, 29 November 2018 (UTC)
    @Nemo bis: I'd look more at that 4,419 figure one line down. People have "accounts here" that never COME here. Many project editors have never ever heard of meta. If you are a dewiki editor or a fywikt editor, you may usually only use your own project or some others in your language. — xaosflux Talk 00:39, 30 November 2018 (UTC)
  • Neutral Neutral I think there is a non insignificant drawback that needs to be kept in mind. I think 5 scratch codes is too little - considering that at most 2 are needed to remove 2FA. The risk of running out of codes is high - considering that scratch codes are meant for those times when you don't have access to the device - and that one needs to disable and re-enable 2FA to generate another set of scratch codes. I think that concern needs to be resolved before it can be widely deployed. Leaderboard (talk) 12:16, 1 December 2018 (UTC)
  • Support Support. If two-factor authentication is available in the settings, but not advertised elsewhere in the site interface, editors who are familiar with the feature would be able to find it in the same location as most other 2FA-protected applications, while editors who are unfamiliar with the feature would simply not touch it. For editors who aren't aware of 2FA being available through SRGP, this is an increase in security for those who would opt in to 2FA, and doesn't affect those who wouldn't. — Newslinger talk 10:20, 3 December 2018 (UTC)
  • Support Support -- I think should have minimum 50 or 100 edits on Mete. Regards, ZI Jony (Talk) 17:48, 23 December 2018 (UTC)
  • I support Ajraddatz's idea with requirement like IRC/Cloaks#Obtaining a cloak. (TLDR: email verified, 250 edits globally, account older than 3 months, no current block.) (And also another note: "We can include all the warnings etc we want on the sign up page." @ Statement: People don't read the warnings, just like nobody reading Terms of Use.) — regards, Revi 14:06, 19 January 2019 (UTC)
    @-revi: have you changed your position on this recently - appears that you are making editors with much lower contributions testers since this response. Examples: 1, 2. Same for @Ajraddatz: - a more recent example from you. — xaosflux Talk 15:52, 23 July 2019 (UTC)
    The current consensus (not here, but broadly speaking) is that 2FA should be as widely available as possible, so I am responding to requests in a very inclusive way. My personal preference would be to further limit 2FA access behind an edit count but make requesting access easier. As always, I argue for what I think should happen and implement what previous community consensus and best practices suggest. – Ajraddatz (talk) 16:12, 23 July 2019 (UTC)
  • Comment Comment I'm still not sure. But autoconfirmed has to be the minimum requirement if the answer ends up as yes. StevenJ81 (talk) 14:56, 23 January 2019 (UTC)
  • Comment Comment recently there are quite many user with admin access can't recover their account because they lost their scratch codes, this reflect well to most people from our community, if admins can make mistake like this, most likely many user will also get these kind of trouble, so I agree with what Nemo bis said.--AldNonymousBicara? 10:56, 4 March 2019 (UTC)
    After thinking about it for so long, and seeing already 5 admins got their account compromised, I decided to Support Support this idea.--AldNonymousBicara? 17:32, 25 March 2019 (UTC)
  • Support Support --Novak Watchmen (talk) 11:17, 4 March 2019 (UTC)
  • Support Support implementation as soon as possible. Vermont (talk) 17:35, 25 March 2019 (UTC)
  • Comment Comment This should be a global RfC not just a Meta RfC. Zppix (talk) 17:51, 25 March 2019 (UTC)
  • Oppose Oppose Problem with 2fa as i have said repeatedly in the past is if you need it reset and have lost scratch codes you have to contact wikimedia operations which then takes a team member off what they are doing to reset it for you Zppix (talk) 17:51, 25 March 2019 (UTC)
    When you made the same objection at Community Wishlist Survey 2019/Bots and gadgets/2FA available for all concerned editors, a WMF staff member said "No it doesn't require Ops." Perhaps Reedy can clarify. — Newslinger talk 06:19, 30 March 2019 (UTC)
    "Ops" traditionally means "SRE", it still doesn't require them (yes, they can do it, but they generally wouldn't be). Anyone with shell access (people who can deploy MW code), along with Trust and Safety (who have been fielding most of the requests anyway). The group of people that can do it is increasing, but they are still relatively limited. Policies and procedures aren't completely in place. TruSa would be best placed to comment whether they have the capacity to support more requests. It's technically easy to solve (removing 2FA - it's just a simple maintenance script to run), but potentially time consuming to field the requests, especially if/when users don't have a confirmed email addresses on their account (or even one at all). The burden of proof gets interesting Reedy (talk) 17:55, 30 March 2019 (UTC)
  • Oppose Oppose until the WMF have sufficient capacity to support the expected volume of support requests. Thryduulf (talk: meta · en.wp · wikidata) 11:20, 27 March 2019 (UTC)
  • Support Support I'm not a 2FA zealot, and for most non-functionary accounts it is overkill (even for the majority of sysops), but if people want it, sure. The fact that people can find meta show that they're informed enough about the Wikimedia movement that we can presume they are aware of the risks. TonyBallioni (talk) 20:31, 10 July 2019 (UTC)
  • Support Support although this involves a lot of work. Znotch190711 (talk) 06:49, 23 July 2019 (UTC)
  • Oppose Oppose There are users who never edit here who have to come here for one-time concerns (they run into some kind of block, or need to solve a local issue on their home wiki). For that, they need to jump through the 2FA hoop first? --Dirk Beetstra T C (en: U, T) 09:55, 23 July 2019 (UTC)
    @Beetstra: can you explain a bit more about why you think people that come here should not be able to enroll in 2FA? The current "hoop" is go post at SRGP, the proposed "hoop" would be to navigate through Special:Manage_Two-factor_authentication (including possibly a big warning banner as demonstrated below). — xaosflux Talk 15:55, 23 July 2019 (UTC)
  • Support Support We have people on their first edit asking for permission, and since it's a low risk right (I don't see any risk), why not. One suggestion is that when auto-granted, before they can click the enable 2FA button, let there have a pop up that say "Have you read the help documents, keep safe the scratch codes and etc". --Cohaf (talk) 11:50, 23 July 2019 (UTC)
Example of using a warning banner on enroll
  • @Cohaf: I'm not sure about extra "clicks" but we can insert a banner before the click such as in the screen shot to the right. — xaosflux Talk 15:44, 23 July 2019 (UTC)
    @Xaosflux: I am thinking on something along the lines of the rollback confirmation prompt. Yours looks fine too. --Cohaf (talk) 16:22, 23 July 2019 (UTC)
    @Cohaf: for reference the current process for those allowed to enroll is basically:
  1. Go to Special:Preferences
  2. Follow the link in to Special:Manage_Two-factor_authentication
  3. See any banners such as the one above
  4. Follow the link in to the enrollment page
  5. See all the descriptions on that page
  6. Do the enrollment
    1. Install a 2FA application
    2. Install the secret to your application
    3. Compute a response
    4. Enter the response
  • You can't do it by accident. — xaosflux Talk 17:41, 23 July 2019 (UTC)
    @Xaosflux:. Noted with thanks. I think it will be good for a prompt at the Special:Manage_Two-factor_authentication that what stewards will ask typically at SRGP such as what I mentioned above (i.e. When you click on the confirm button, you acknowledge you had read XXX YYY). A banner is fine as an alternative. Regards,--Cohaf (talk)17:54, 23 July 2019 (UTC)
  • Oppose Oppose Based on personal experience, I feel that this extension is not reliable enough for widespread use.  — FR (mobileUndo) 17:13, 23 July 2019 (UTC)
  • Neutral Neutral Perhaps something like an admin bot that automatically approve request from experienced user would already do the job without sacrificing too much flexibility. Viztor (talk) 17:35, 23 July 2019 (UTC)
  • Oppose Oppose Per all the concerns about unreliability and the maintenance status of the 2FA extension. Jo-Jo Eumerus (talk, contributions) 07:36, 24 July 2019 (UTC)
  • Support Support Allowing use of 2FA is only going to let people who go looking for it access it - this is not making it mandatory. Allowing people to appropriately secure their accounts is simply a rational step Nate1481 (talk) 14:21, 22 August 2019 (UTC)
  • BA candidate.svg Weak oppose Be warned that currently, there is no way to reset 2FA without the help of system administrators, should you lose your scratch codes. That is the reason why only privileged groups and users aware of the risks are 2FA-enabled. Also, it's next to impossible to prove your identity to a sysadmin if you're a new user. This should be a global RFC, 2FA is global, since accounts are global. --Martin Urbanec (talk) 17:22, 14 September 2019 (UTC)
    @Martin Urbanec: I agree with you in principal, however do you realize that stewards rubber-stamp basically anyone who asks for this to be turned on? I think I've recently seen an editor get this enabled when the request for 2FA was their only global edit. It seems like an outcome for this should be to change the requirements for "testers" and stop having stewards just hand out the access on demand? — xaosflux Talk 00:17, 9 December 2019 (UTC)
    @Xaosflux: There's a difference between someone who intentionally requested the feature to be enabled on their account after claiming they've read the help page [1], [2] and someone who did not request the feature but only enabled it because it's readily available on their preferences setting page. People are naturally curious, so when a new option appears, a user seeing it for the first time will be inclined to "test" it (without knowing the implication, and nothing technically preventing them).
    1. If you deliberately ask for it (Tester group) and claim to have read help pages (that clearly warns about the implications), and then got locked out, then that's your fault.
    2. If you did not ask for it, but just woke up to a new feature option on your settings page and (as curious as we are), you enabled it to test (since, presumably any new settings option means it's vetted by Wikimedia Foundation to be okay for production wiki) and then got locked out, then that's the fault of Wikimedia Foundation, for rolling out unstable feature on production environment.
    So these two scenarios should not be conflated. They are different. – Ammarpad (talk) 07:35, 9 December 2019 (UTC)
  • Neutral Neutral Don't care much, but it appears the cons are convincing. Should be approached globally. --Krd 11:34, 15 October 2019 (UTC)
  • Oppose Oppose Should be a global conversation, concerns with the cons outlined above. ~riley (talk) 19:30, 8 December 2019 (UTC)
  • Support Support global rfc? Aνδρέας talk | contributions 22:53, 2 January 2020 (UTC)
  • Comment. Instead of giving this right to all users of meta, it would be more practical to convert the current global group into a local meta group and give meta sysops (and stewards) ability to assign users to it. This would relieve stewards from the boring work of rubber stamping those requests while keeping the number of 2FA enabled users manageable. Ruslik (talk) 16:47, 18 February 2020 (UTC)
@Ruslik0: if this was a local group, it could be managed by local users for sure, but the members would only be able to activate here. This would not need to be exclusive, we can simply create another local group and not change the global group. — xaosflux Talk 14:14, 19 February 2020 (UTC)
The global group would become redundant. In addition the main goal of this proposal is free stewards from this task. Ruslik (talk) 18:56, 19 February 2020 (UTC)
And because users will need to request this right on Meta in any case, it is logical that they should activate 2FA here. Ruslik (talk) 18:58, 19 February 2020 (UTC)