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).
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. Nemo18:51, 29 November 2018 (UTC)[reply]
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)❤T☮C☺M☯18:51, 29 November 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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? — xaosfluxTalk19:41, 29 November 2018 (UTC)[reply]
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)[reply]
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)[reply]
"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. Nemo21:53, 29 November 2018 (UTC)[reply]
@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. — xaosfluxTalk00:39, 30 November 2018 (UTC)[reply]
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)[reply]
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. — Newslingertalk10:20, 3 December 2018 (UTC)[reply]
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, Revi14:06, 19 January 2019 (UTC)[reply]
@-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. — xaosfluxTalk15:52, 23 July 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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 BeetstraTC (en: U, T) 09:55, 23 July 2019 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
SupportAllowing 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)[reply]
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)[reply]
@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? — xaosfluxTalk00:17, 9 December 2019 (UTC)[reply]
@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.
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)[reply]
@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. — xaosfluxTalk14:14, 19 February 2020 (UTC)[reply]
Support I too find this beneficial, at least as an intermediate measure. I'm not entirely clear how to best request this, so I will simply do so here: I hereby request that 2FA be enabled for my account. Coby.Viner (talk)
Support as proposer. — xaosflux Talk 18:39, 29 November 2018 (UTC)
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)
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)
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)
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)
