Meta talk:Interface administrators
Add topicLatest comment: 1 year ago by John in topic Amending Meta:Interface administrators policy page
Amending Meta:Interface administrators policy page[edit source]
- No, Stewards aren't required to have 2FA, this RfC wants to have just local interface-admins with 2FA, making this already absurd RFC even more absurd. Naleksuh (talk) 23:10, 16 April 2022 (UTC)
- As I stated already above, Stewards, together with SRE and Trust and Safety, have, by convention, unanimously agreed to have two-factor authentication enabled. I assumed that when SRE implemented the more stringent password length requirements, they also made a technical change, with the support of Stewards, SRE, and Trust and Safety, that made this long-standing convention a technical reality. If that is not the case, I would have no objections to SRE also implementing that for any of the aforementioned groups upon the closing of this community discussion. Dmehus (talk) 23:36, 16 April 2022 (UTC)
Neutral/Abstain[edit source]
Oppose[edit source]
- This is not okay. First of all, there is very little if not zero conceivable benefit to this change. I already use a secure password which will take 500 quadrillion years to crack. Two-factor authentication is designed to handle a scenario in which someone steals this password but doesn't steal 2FA. 2FA on Discord is widely criticized for doing absolutely, and while it is less of he case on MediaWiki it's still absolutely problematic, and the security benefit is not only negligible, but not the responsibility of others. And more importantly, since I do not carry a smartphone, this change would essentially force me to resign as an interface admin. While interface admins are responsible for protecting their account and are free to enable it, it is absolutely unacceptable to try to be forcing other editors to enable it. User:Reception123, it is extremely concerning that you "can see no good argument" against forcing editors to enable a specific feature, much less one that requires carrying a smartphone and identifying yourself. This is unacceptable. Naleksuh (talk) 20:50, 16 April 2022 (UTC)
- It does not require a smartphone at all. You develop bots so I'm sure you can find a simple programming function for TOTP functions. I'm sure at least one website has a function for storing 2FA tokens. ~ RhinosF1 - (chat)· acc· c - (on) 20:54, 16 April 2022 (UTC)
- As RhinosF1 said above, it does not require a smartphone. I don't use a smartphone either, and have the non-Google Authy app installed, for free, on two computers, allowing my two-factor authentication credentials to be synced on both devices, so that portion of your argument is moot/void. Dmehus (talk) 20:56, 16 April 2022 (UTC)
- It's the responsibility of the user to keep their account secure. If there had been multiple occasions of interface administrators accounts being compromised, all of which could have been stopped by 2FA (so no phishing, no server-side breach, no device malware, etc), then maybe. But this RfC is a solution looking for a problem. And one that is also very disruptive. Naleksuh (talk) 21:17, 16 April 2022 (UTC)
- It's not about seeking a solution for a problem; rather, it's about implementing a measure proactively as a preventative measure (just as Phabricator ticket #T9071 illustrates, or will illustrate, when/if it is made public), rather than having to potentially act reactively, which would be far more damaging and potentially catastrophic. Given the low barrier to the obtaining the
interface-admin
permission (i.e., it's a sub-delegated role granted by a Meta bureaucrat to users upon their request and apparent trustworthiness with a valid need) and as the views of the community have expressed thus far, Meta Wiki is a special wiki, this is quite prudent. Dmehus (talk) 21:25, 16 April 2022 (UTC)- If it's such a low barrier then there would be no reason to protect it so stringently. Even more reason to oppose this RfC. Naleksuh (talk) 21:27, 16 April 2022 (UTC)
- Low barrier in the sense of that was the idea behind the original RfC, to allow users to request the permission without requiring a community election, as is the case of the sysop permission. The idea was to allow trusted users to assist Meta administrators and Stewards in fulfilling certain requests. That's not to say it's not a sensitive position; it is. It's just one that doesn't require a community election. Dmehus (talk) 21:31, 16 April 2022 (UTC)
- If it's such a low barrier then there would be no reason to protect it so stringently. Even more reason to oppose this RfC. Naleksuh (talk) 21:27, 16 April 2022 (UTC)
- This is to prevent any events happening with compromised accounts. Also, this change is not disruptive. I'm afraid that it's just needed to protect the site from any events in the future. -- Cheers, Justin Aves (talk • contribs • global • rights) 01:11, 17 April 2022 (UTC)
- It's not about seeking a solution for a problem; rather, it's about implementing a measure proactively as a preventative measure (just as Phabricator ticket #T9071 illustrates, or will illustrate, when/if it is made public), rather than having to potentially act reactively, which would be far more damaging and potentially catastrophic. Given the low barrier to the obtaining the
- It's the responsibility of the user to keep their account secure. If there had been multiple occasions of interface administrators accounts being compromised, all of which could have been stopped by 2FA (so no phishing, no server-side breach, no device malware, etc), then maybe. But this RfC is a solution looking for a problem. And one that is also very disruptive. Naleksuh (talk) 21:17, 16 April 2022 (UTC)
- You could have 2FA on a smart fridge if you wanted to, it's available on pretty much anything that can connect to the internet. -- Cheers, Justin Aves (talk • contribs • global • rights) 01:13, 17 April 2022 (UTC)
- I think that takes things a bit to far. It is indeed available on tablets, smartphones, and PCs, but I wouldnt go that far, and that is a bit misleading. User:Universal Omega/Sig 01:16, 17 April 2022 (UTC)
- Agreed. While I wouldn't necessarily want my health insurance company snooping on what I eat, I also wouldn't enable two-factor authentication on a smart fridge (nor would I buy a smart fridge). Dmehus (talk) 01:19, 17 April 2022 (UTC)
- I mean it certainly is possible to install 2FA on it, I agree that that takes things too far. -- Cheers, Justin Aves (talk • contribs • global • rights) 01:35, 17 April 2022 (UTC)
- I think that takes things a bit to far. It is indeed available on tablets, smartphones, and PCs, but I wouldnt go that far, and that is a bit misleading. User:Universal Omega/Sig 01:16, 17 April 2022 (UTC)
- As RhinosF1 said above, it does not require a smartphone. I don't use a smartphone either, and have the non-Google Authy app installed, for free, on two computers, allowing my two-factor authentication credentials to be synced on both devices, so that portion of your argument is moot/void. Dmehus (talk) 20:56, 16 April 2022 (UTC)
- It does not require a smartphone at all. You develop bots so I'm sure you can find a simple programming function for TOTP functions. I'm sure at least one website has a function for storing 2FA tokens. ~ RhinosF1 - (chat)· acc· c - (on) 20:54, 16 April 2022 (UTC)
Discussion[edit source]
- As a general point I would like to mention that if we are imposing 2FA for interface administrators I think there should be more clarity as to whether this is imposed for Stewards, SRE and Trust and Safety or whether this is simply done by agreement because the people in those groups are clearly responsible and know that they should secure the accounts. If there is no requirement and in theory someone in these groups could refuse to enable 2FA I believe there would be a bit of a bizarre situation created if only interface administrators are required to enable 2FA. I do acknowledge that on the other hand there is the argument that those three groups are already trusted enough to enable 2FA while interface administrators require less trust to be appointed. --DeeM28 (talk) 11:26, 18 April 2022 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section