Wikipedia talk:Arbitration Committee/Noticeboard/Archive 40

Archive 35

←

Archive 38

Archive 39

Archive 40

Archive 41

Archive 42

→

Archive 45

Return of permissions for compromised administrator accounts

Original announcement

• Should have happened long ago, Glad ArbCom have finally stated that a resysop is not automatic if you don't meet security standards and that leads to harm to the encyclopedia. Hopefully, WMF will introduce a feature to verify it that arbs can access soon. RhinosF1^(chat)_{(status)(contribs)} 15:16, 10 April 2019 (UTC)

  @RhinosF1: "it" being "are you secure"? What would you want such a tool to do? — xaosflux ^Talk 15:23, 10 April 2019 (UTC)

  Xaosflux, Yes, It being whether accounts are secure. I'd expect it to at least state 'This accounts meets the minimum standards for Account security' with it maybe revealing which points failed. I'd expect data to be kept for at least a week or so in case of compromise so it can be checked if they met standards at the time of compromise. Potentially, Stating which point fails if the Account does. I'd even support the software treating it as if the Account didn't have rights that require certain security standards (although excluding 2FA from this as some people have issues with it (I've had no issues since enabling it last night)). RhinosF1^(chat)_{(status)(contribs)} 15:32, 10 April 2019 (UTC)

  @RhinosF1: You may be interested in following phab:T209749 (see the later comments about adding a general yes/no check for this user has met all technical requirements for access to advanced permissions). — xaosflux ^Talk 15:35, 10 April 2019 (UTC)

  Xaosflux,  Commented at T209749 RhinosF1^(chat)_{(status)(contribs)} 15:42, 10 April 2019 (UTC)

  Surely it's impossible to check that this user has met all technical requirements for access to advanced permissions isn't it? Wikipedia password not reused on other sites, email password strong, email password not reused on other sites? You can't check any of those. Not even sure if it's possible to check if a Wikipedia password is strong, as the plaintext password is not stored (not if it's implemented competently) and you can't reverse the stored encrypted password to check the plaintext password strength. As far as I can see, a strong password check can only be done when the password is initially set or changed, or at the point it's used to log in - it shouldn't be available to be inspected anywhere outside of those events. Boing! said Zebedee (talk) 16:52, 10 April 2019 (UTC)

  Boing! said Zebedee, As you've said. Password checks on login/password change would really be the only time it needed to be checked. Obviously, there's somethings it's impossible to check but things like password strength, not on common passwords list, 2FA enabled, checking bot passwords as well etc. RhinosF1^(chat)_{(status)(contribs)} 17:15, 10 April 2019 (UTC)

Stupid question. I have a long enough password which is not used for any other website anywhere else, never has been, and which I change on a semi-regular basis, plus I have 2FA enabled. Same goes for my email, different password, not used anywhere else. Am I considered "safe" from this? Ritchie333 ^{(talk) (cont)} 16:00, 10 April 2019 (UTC)

Hmm. Do you have a sticker over your webcam? Natureium (talk) 16:03, 10 April 2019 (UTC)

What webcam? And should I change the chubb lock on the front door? Ritchie333 ^{(talk) (cont)} 16:04, 10 April 2019 (UTC)

Ritchie333, As long as it isn't listed on https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials (I think it's the 10K list) and you don't have a bot password on your main account set up then I'd say yes but it's up to Arbs. RhinosF1^(chat)_{(status)(contribs)} 16:22, 10 April 2019 (UTC)

It isn't, but I've watched this and as you can see, any password is crackable if you throw enough brute force at it. Ritchie333 ^{(talk) (cont)} 16:28, 10 April 2019 (UTC)

Ritchie333, I'll watch that later but on paper with enough computing power any password is crackable but I suppose it depends on whether the people taking over accounts have the power. If it's just a kid in their bedroom it might not be worth the effort to crack extremely secure passwords and they'd have to trick you into giving a 2FA code over. RhinosF1^(chat)_{(status)(contribs)} 16:43, 10 April 2019 (UTC)

Yes, any password can be cracked with enough computer power - but it's relatively easy to make a password strong enough so that such an effort would on average take hundreds of thousands of years even with today's best computers. The mooted kid in their bedroom doesn't have a realistic chance against anything other than weak passwords. Boing! said Zebedee (talk) 17:03, 10 April 2019 (UTC)

Ummm ... how is Arbcom going to know what passwords were in use, and whether they are strong enough? AFAICS, that only be determined by either asking the user to declare what passwords were used (which would be a v v bad idea), or by asking a bunch of questions about the nature of the passwords. Those questions would need to be very carefully framed to cover potential issues without revealing the methodology by which a password is built. And even so, the answers are unverifiable. --BrownHairedGirl (talk) • (contribs) 16:08, 10 April 2019 (UTC)

BrownHairedGirl, See phab:T209749, hopefully the software will handle it RhinosF1^(chat)_{(status)(contribs)} 16:19, 10 April 2019 (UTC)

No it won't, @RhinosF1. At least not if its is anything like as described there, which is a tool to say whether 2FA is enabled. That won't answer any questions about the nature of passwords.

However, it might be relevant if Arbcom was proposing to require 2FA as a recondition for re-enabling compromised accounts. I hope it isn't, but have I missed something? --BrownHairedGirl (talk) • (contribs) 16:28, 10 April 2019 (UTC)

BrownHairedGirl, I believe it's possible for WMF Trust & Saftey to check whether 2FA is enabled but it's likely that value will be shown that confirms they meet standards. RhinosF1^(chat)_{(status)(contribs)} 16:40, 10 April 2019 (UTC)

BrownHairedGirl, Regarding password checks it's the most recent comments RhinosF1^(chat)_{(status)(contribs)} 16:49, 10 April 2019 (UTC)

I hadn't read all the way down here when I made my first comment above, but it seems relevant. Boing! said Zebedee (talk) 16:59, 10 April 2019 (UTC)

Boing! said Zebedee, No, completely relevant. I'm working on the assumption most compromised accounts are Compromised by kids in their bedroom so weak passwords are the issue. It's been suggested both earlier at Phab by Xaosflux and by me at Phab and above that restricted actions be disabled if passwords aren't strong enough / 2FA is disabled until issues are rectified. RhinosF1^(chat)_{(status)(contribs)} 17:11, 10 April 2019 (UTC)

But how do you tell if a password is strong enough? Presumably at the point the editor actually enters it? Boing! said Zebedee (talk) 17:13, 10 April 2019 (UTC)

Boing! said Zebedee, When changed I guess it would be checked. I'd use X characters and includes numbers & symbols etc. RhinosF1^(chat)_{(status)(contribs)} 17:16, 10 April 2019 (UTC)

When changed or entered. That does add complexity though. I can't remember the last time I had to log in and enter my password, as the system just keeps me logged in (on my secure home computer). So people who stay logged in like I do would have to be force logged out in order to make them re-enter a password. And it's not something that could be answered by an "Is the password strong enough?" tool on demand. Also, it's actually far from trivial to check if a password is strong - the "X chars plus numbers plus symbols" approach is not sufficient - there are plenty of horribly weak passwords that can pass that test. There are password strength checkers out there that properly analyse passwords in terms of probability, likely time to crack, etc, but they're done on a number of checks - including dictionary lookup checks, common password checks, etc. Wikipedia couldn't use those services directly as that would involve disclosing real passwords to them, so an in-house version would have to be developed. And I don't know what the likelihood of getting one of those developed might be. Boing! said Zebedee (talk) 17:25, 10 April 2019 (UTC)

Boing! said Zebedee, I guess someone would have to make a decision on what the rules should be regarding minimum password complexity and when a password is changed have it checked against them rules and the result stored in the database with a forced check every so often to comfirm it's not in the common passwords list. RhinosF1^(chat)_{(status)(contribs)} 17:35, 10 April 2019 (UTC)

The typical approach, used by GitHub and the like (from my own experience of using a weak password there) is that when you log in, they check your password against a list of compromised passwords, and against a strength checker, and they store the results. So, they would only store a flag stating that the user's password had been seen in a password compromise. Of course, that means you're now flagging all of the weak accounts in your database for any hacker to see... ST47 (talk) 17:39, 10 April 2019 (UTC)

(edit conflict) Or they could skip all these things because the accounts that have been compromised recently were compromised a while ago, and administrators have had months of warnings to change their password if they use it anywhere else. If future compromises fit the current pattern, they will have the same inexcusable cause. Natureium (talk) 17:40, 10 April 2019 (UTC)

Yes indeed, you'd need to do the check when the password is entered (either to log in or to change it) and store the result, but you can't do additional forced checks without requiring the password to be entered again. Boing! said Zebedee (talk) 18:42, 10 April 2019 (UTC)

The WMF provided assistance to the committee during the last compromised admin account with useful information. It included how many times the password was guessed before the account was accessed, whether 2FA was enabled, and their best assessment on how the password was obtained. As for the actual minimum security requirements for the password itself, these are outlined at WP:STRONGPASS and m:Password policy. Passwords must not be in the 100,000 most popular passwords among other listed requirements. Compliance is outlined at m:Password policy#Compliance. The process will always involve discussion with the individual about the incident and whether their password was unique to Wikipedia. It is impossible to fully verify some of this information, but when taking everything under consideration, it led to the decision that in this case, 2FA was the best solution to address concerns of the committee that another strong password would not be sufficient to reasonably prevent the account from being compromised again. I suspect enabling 2FA will be an option consistently considered when a request to return the tools is made from a previously compromised account. It should be noted that enabling 2FA is not a mandatory requirement for sysops (until a time should the community decide otherwise). So, if someone can demonstrate reasonable security measures were taken prior to their account being compromised and doing so again would provide reasonable grounds that the account will be secure again, then 2FA might not be a condition of the committee to return the tools. I cannot think of too many likely scenarios where this would be true, but life has a tendency to surprise you; e.g. an open laptop is forcibly stolen mid-editing during an edit-a-thon. Mkdw ^talk 18:13, 10 April 2019 (UTC)

Yes, I think enforcing 2FA is about the only practical thing to do. Checking password strength really only goes so far, and it seems that the recent breaches have been from re-used passwords obtained from hacked sites (which says something about the security of the hacked sites, which presumably must have stored plaintext passwords) and there's nothing that password checking can do about that. Even with strong password checking, email passwords can't be checked - and if a hacker gains access to an email password, they can simply request a Wikipedia password reset and they're in. Boing! said Zebedee (talk) 18:42, 10 April 2019 (UTC)

As an aside, it seems absurd that we're still needing to have these conversations about password security in 2019 - I first got involved in such things nearly 40 years ago (involving standalone mainframe computers, long before the Internet), and the same thing has come up with monotonous regularity ever since. Boing! said Zebedee (talk) 18:48, 10 April 2019 (UTC)

Boing! said Zebedee, 100% agree that it's slightly ridiculous that we are having these conversations in 2019 regarding compromised accounts due to password reuse as has been said above my multiple users on login the password should be checked against the 100K common passwords list and the ability to edit/use of advanced permission suspended by the software until the user changes to a less common password. RhinosF1^(chat)_{(status)(contribs)} 22:43, 10 April 2019 (UTC)

Yes, we should do that as a minimum - and wasn't it only fairly recently that the minimum allowed password was lengthened to eight characters from one? Another aside - my favourite example was some time ago when a colleague's account was compromised. He'd set his password to his surname, and his surname, ironically, was "Hack". Boing! said Zebedee (talk) 22:52, 10 April 2019 (UTC)

• Would there be any appetite to update WP:SECUREADMIN so admins must be compliant with m:Password policy/Wikipedia:Password strength requirements#Requirements? Right now, the only consequences for admins not being compliant with the password policy is that you may be asked to change it (unless your password is on the 10,000 most common list), or if your account is compromised you may not get the tools back. Admins are already expected to not violate policies and the security policy seems like an important one... I am not sure if it is technically feasible, but have the WMF Security team run the 1,178 admin accounts through the list of 100,000 most common passwords and force a password change for accounts not-compliant. The policy would be enforced thereafter -- but as others have said above, a technical solution to simply prevent those passwords from being able to be used at all would be best. Mkdw ^talk 23:34, 10 April 2019 (UTC)

  Re: "have the WMF Security team run the 1,178 admin accounts through the list of 100,000 most common passwords": They can't really have done that, because they have no way of knowing what our passwords are - they are not stored anywhere in plain text. The best they could do is try to log in to each admin account by trying the entire 100,000 passwords against each one, and I seriously doubt they will have tried that. Boing! said Zebedee (talk) 23:46, 10 April 2019 (UTC)

I meant 'have' and 'force' as a future tense instruction, not a past tense question if they had already done it. I am sure it would be very time consuming without an automated process and a powerful enough system. Mkdw ^talk 00:04, 11 April 2019 (UTC)

Ah, you mean we should have them do it rather than "have they done it?". They would still have to do it by attempting to crack all admin accounts by trying all 100,000 common passwords against each one - and that brings ethics into it too. Boing! said Zebedee (talk) 00:19, 11 April 2019 (UTC)

Passwords are stored in hashes, and since we know the 10k known insecure passwords, (in theory,) we can make a hash of 10k insecure stuff and compare with the admins password hash. If it matches, they are using the 10k proven insecure PW. Not that WMF is doing that (disclaimer: I'm not WMF Security folk.) — regards, Revi 08:37, 11 April 2019 (UTC)

That could be done, providing the hashing algorithm is not prone to collisions. Does anyone know what algorithm is used? Boing! said Zebedee (talk) 08:47, 11 April 2019 (UTC)

It wouldn't be quite that straightforward. Assuming that a unique salt is being used for each user, we'd need to hash each of the 10k insecure passwords for each admin. So not just 10,000 hashes, but 11,780,000 hashes to check all admins against the 10k list. Mojoworker (talk) 20:54, 11 April 2019 (UTC)

Ah yes, good point. Boing! said Zebedee (talk) 20:59, 11 April 2019 (UTC)

Mojoworker, Right, but there's a method. Otherwise you wouldn't be able to log in. It really wouldn't take very long to run 12 million hashes locally, especially once you take web response time, as well as much of the overhead out of the equation. I would honestly be surprised if it would take more than a few hours. SQL^{Query me!} 02:24, 12 April 2019 (UTC)

I was just pointing out the complexity of password hashing wasn't quite that simple (and would also depend on the number of hashing rounds being used). No quibble with your time estimate, and, in this case, the task can easily be partitioned into smaller processes run in parallel on multiple processors against multiple DB subsets to cut down the time. Mojoworker (talk) 07:05, 12 April 2019 (UTC)

• For anyone interested in the techie details of cryptographic hashing (ie how passwords are stored), this seems good. Boing! said Zebedee (talk) 08:58, 11 April 2019 (UTC)
• Just to clarify the context of interaction with WMF, let me give this example. I have an interface admin flag on three WMF projects. When 2FA was mandatory for interface admins, I was not sure whether I want to enable 2FA or stop being an interface admin, and I decided to wait until I get officially notified (either by sending me a Wikimail, or leaving a message at my talk page, or even leaving a message at the dedicated noticeboard which I can reasonably expected to read - for example, administrator noticeboard) of the policy change. This never happened. Nobody ever complained either that I did not enable 2FA and this is not compliant with the policy. In the end of the day, I enabled 2FA a couple of weeks ago, but I am pretty sure nobody would ever notice if I did. I think WMF security team can be reactive, and can provide useful info if an account has been compromised, but I have difficulties seeing them being proactive and making even random checks of passwords, not speaking of any systematic checks.--Ymblanter (talk) 09:40, 11 April 2019 (UTC)

  @Ymblanter: FWIW, I did get a "activate 2FA" notice via email from WMF on another project when this was rolling out (even though I already had 2FA). It's an ad-hoc process they are using right now. — xaosflux ^Talk 11:41, 11 April 2019 (UTC)

  I just checked - I do not have anything relevant in my mailbox. I could have deleted it if it was a generic mail, but I am pretty sure I have never got anything saying "You are an interface administrator, and it is now mandatory for interface administrators to enable 2FA".--Ymblanter (talk) 11:46, 11 April 2019 (UTC)

• Usually these break-ins come from re-used passwords found in breach dumps, rather than easily guessable passwords. Last time I looked, mediawiki's password hash was a single salted md5, so checking 100k passwords against 1k admin accounts seems pretty doable, but it would be better to also check them against available breach dumps (see HIBP). Preferred practice back in the day was to assign people random passwords (or phrases[1]) rather than having them set their own. This seems like an ok compromise (vs. 2fa) if the password is not re-used. Note that if the threat model is password guessing over the network, it's perfectly fine to write down your password on a piece of paper and put it in your pocket. Until some fool invents cloud-connected paper, of course. 173.228.123.166 (talk) 21:33, 11 April 2019 (UTC)
  • Hi 173.228...., WMF wiki's have used PBKDF2 for almost 5 years, see phab:T70766. Of course if some other site uses MD5 and passwords are reused it all falls to the weakest link. — xaosflux ^Talk 03:12, 12 April 2019 (UTC)

• To address a couple of the questions above regarding the whole "Am I safe?" idea: It's difficult to answer this because it genuinely will be case-by-case based on all evidence available to the Committee. What the admin tells us, what the WMF tells us, any identifiable cause of the breach, etc. On the "definitely not safe" side, I wouldn't vote for resysopping in any case where the evidence strongly indicated a password was re-used. On the "definitely safe" side, I can't imagine a plausible scenario where I would vote against resysopping if 2FA was enabled. There's then a wide range of possible cases in between those where we would need to have a tough discussion. For instance, say an admin used a unique, secure password, did not have 2FA enabled, and fell victim to a keylogger which has been identified and definitively removed from the admin's computer. Did that admin practice appropriate security practices? That's tough to say, and I'm not terribly concerned about expending a lot of time thinking about it now. It's never happened before, and we can have that discussion if it ever does happen. It would probably depend on a lot of particulars - was the admin opening .exe files sent by suspicious email addresses, or did the keylogger spread across a network they happened to connect to?

  The best advice right now is to ensure your password is secure and unique, enable 2FA if you can, and practice common sense on the internet. ~ Rob₁₃^Talk 21:43, 11 April 2019 (UTC)

• Part of the motivation for having a separate bureaucrat layer to enable sysop bits is that mere admins aren't supposed to be able to do anything too irreversible. That is, an admin going berserk or a takeover of an admin account shouldn't be that much worse than one of a normal user account. They'd get blocked and whatever they did would be reverted, while if they could also create more admin accounts it could spread like a virus. This is still at least partly true, so we shouldn't freak out too much. Anyway (like file backups against disk crashes) lots of people don't see account takeovers as a real threat until it happens to them. So imho it's fine to restore the bit to someone after they have put good practices in place, even if their practices before the takeover weren't so good. The experience stays with you. 173.228.123.166 (talk) 22:10, 11 April 2019 (UTC)

• Good call. This is pretty much, 100% exactly in line with what I suggested here in a related discussion about a day prior. --Jayron32 15:07, 12 April 2019 (UTC)

• Suggestion if people are finding 2fa inconvenient, could it be possible to add a feature to admin accounts so that you can enable 2fa but then bypass it when logging in, and bypassing it means you can't perform admin actions (or some other functions like changing your password or email, seeing your own email address, or sending email through the web interface) for that session? Would this make life easier for admins who don't like using 2fa? I know some admins use separate accounts for non-admin stuff but that sounds annoying in its own way. 173.228.123.166 (talk) 05:46, 13 April 2019 (UTC)

  See phab:T201784 Galobtter (pingó mió) 06:10, 13 April 2019 (UTC)

Jehochman’s comments

• Arbcom aren’t meant to be experts on cyber security. They seem to have a partial understanding of the issues. First of all, anybody can get hacked. Don’t blame the victims. Second, our 2FA implementation is lousy because you will definitely lose access if you change your Authenticator device. There is no procedure to recover access if you have a hardware failure or lose the device. You literally need to corner a developer and get them to manually fiddle with the system. This is not scalable without a strong process for restoring access when 2FA fails. Jehochman ^Talk 05:56, 13 April 2019 (UTC)

• A better approach is to run the k-anonymity test provided by [2] for each admin password currently in use. Whichever ones have been exposed, disable them immediately. Force a password reset. That will create a measure of security and help prevent breaches. Jehochman ^Talk 06:07, 13 April 2019 (UTC)
  • Perhaps, but that could only be done at the time each admin logs in because that is the only time when the password is available to be hashed and checked in the needed format. Johnuniq (talk) 08:10, 13 April 2019 (UTC)
    • One possible way to get round that would be to implement it on log in and then force log out all admins as a one-off security measure. As for loss of a 2FA device, it's true that you do need a dev to help, but if you've retained your original scratch codes somewhere safe they can get you back in. It's far from ideal, but it's not "no procedure to recover access". Boing! said Zebedee (talk) 10:06, 13 April 2019 (UTC)
    • Oh, and I can see one possibly serious objection to using https://haveibeenpwned.com/ to check if passwords have been "pwned". It means the WMF handing our unencrypted passwords over to a third party, and I don't think I'd be too happy about that. Boing! said Zebedee (talk) 10:12, 13 April 2019 (UTC)
      • No, the "k-anonymity test" mentioned above means no password is revealed. I explained the method here. However, there is no way the WMF would bulk test passwords like that. They might get a copy of the hacked passwords and test from that, but I doubt they would do that either. Johnuniq (talk) 01:32, 14 April 2019 (UTC)
        • So long as you have your scratch/backup codes, losing or changing your authenticator device isn't a problem.[3] Doug Weller talk 15:44, 14 April 2019 (UTC)

Arbitration Policy - Community Ratification

Original announcement

Would it be possible to hold such ratification votes open for a bit longer in future (or maybe state in the notifications of the vote what period the vote will be held open for)? I had been intending to get round to participating in this, but left it a bit too long (I think there was a 'weekend effect' where lots of votes came in on the final two days). I had assumed it would be held open for longer than a week (and that it would take longer to get to 100 supports), but those assumptions were clearly incorrect! There are bits in the current policy that give links to past ratification votes and amendments (the previous one was open for about two weeks and got to 134 in support before being closed, so wasn't closed as quickly) - this addition of links to the ratification vote should be done for this change as well (the 'notes' and 'see also' are a hodge-podge of citations for the changes made), but who should do that sort of administrative/historical note? I am glad to see Iridescent got this in before it closed. :-) Carcharoth (talk) 12:11, 16 April 2019 (UTC)

The arbitration policy dictates that it passes the second that it crosses 100 supports with a majority supporting, so we don't have much control over the time period. It completely depends on how long it takes to hit 100 supports. A watchlist message was added yesterday to alert people to the ratification process, which is why we got a large burst of votes all at once. I agree a minimum of two weeks would be a good idea, but ironically, that would require ratification under the old procedures to add to ARBPOL. That's probably not worth the effort until we have an expectation we're going to use the amendment procedure again. ~ Rob₁₃^Talk 14:21, 16 April 2019 (UTC)

Hmmm. The policy seems to suggest that an amendment passes the instant it hits 100 supports, even if it has 99 opposes and there’s a vigorous discussion underway. That is a problem. Newyorkbrad (talk) 15:01, 16 April 2019 (UTC)

The policy seems to suggest that 100 votes is the minimum requirement for closing the discussion, but prudent admins will not close discussions without clear consensus. Most such proposals end up something like 100-5, which is usually a clear enough consensus to act on, but if we're at 100-99, then I would expect any prudent admin to wait until a more clear consensus emerges, or if one never does, to eventually close it as "no consensus". That's how most of the rest of Wikipedia runs, and I see no evidence that this kind of thing has run any differently in the past. --Jayron32 15:17, 16 April 2019 (UTC)

Ratification is not based on consensus and doesn’t require closure, per ARBPOL. The exact language indicates the new policy takes effect the instant the criteria to pass are met. I agree that’s not great. ~ Rob₁₃^Talk 17:49, 16 April 2019 (UTC)

I think a 2 week minimum is a reasonable time frame for something like this. –xeno^talk 16:40, 18 April 2019 (UTC)

What about a 48-hour waiting period after the threshold is crossed? —pythoncoder (talk | contribs) 17:39, 18 April 2019 (UTC)

The whole idea is to ensure that a significant period of time is allowed for the community to digest the suggested change and make an informed comment. Not to have to rush to comment because they're concerned about it being pushed through by early adopters. –xeno^talk 17:58, 18 April 2019 (UTC)

Indeed. As it's a vote and we're not dropping ballots in a box, we have the option of changing our vote down the line. Two weeks seems a good mark. ~ Amory (u • t • c) 10:31, 19 April 2019 (UTC)

I agree. We have very little discretion over this given the wording of ARBPOL, however. I'm hesitant to propose another amendment to ARBPOL so soon after this one, just to prevent community apathy toward the referendum process, but I would be interested to hear if y'all think it worth it to hold another just to add a two week minimum time on future referendums. ~ Rob₁₃^Talk 14:19, 19 April 2019 (UTC)

I think it'd certainly be good to do it before the next change comes up, but I don't see a rush at the moment. There's been good feedback already, and it might be worth going through ARBPOL for similarly un- or ill-defined. Maybe revisit once the circular goes out, as that may distract? ~ Amory (u • t • c) 18:05, 19 April 2019 (UTC)

Perhaps just hold it in parallel with the next amendment to the policy. That amendment can contain a one-time special clause that delays the effect of the amendment until a minimum of two weeks after the start of the ratification process, so the need for a two-week period will be effective immediately. isaacl (talk) 18:10, 19 April 2019 (UTC)

@Isaacl: I would consider it an ARBPOL violation to alter the ratification process at all during a ratification. While obviously doing what you suggested isn't anything egregious, imagine if we instead said something like "For this one time only, only 50 editors are required to ratify this amendment." I doubt the Committee would ever try that, but I think such an example illustrates why the current ratification procedures must be effective until they are modified by the existing amendment process.

There are a couple things in ARBPOL that might be worth a quick amendment. MedCom is still referenced even though it no longer exists. A reference to an outdated confidentiality agreement persisted for years until it was changed per WP:IAR this past week. Reference to an appeal to Jimbo still exists in the policy even though he has stated that he would not exercise that power in basically any circumstances. I could see an amendment to just go through and fix all of these small idiosyncrasies that have emerged over time, but let's give it a few months first to prevent "RfC fatigue" after this latest amendment. ~ Rob₁₃^Talk 18:33, 19 April 2019 (UTC)

I don't think it is an issue to set a higher standard to bring an amendment into effect. The current lower standard would enact the amendment, but it would not take effect until the higher standard is met. So your example of trying to change the standard to 50 editors would not succeed. However if a number of cleanup amendments can be bundled together, so much the better. isaacl (talk) 18:39, 19 April 2019 (UTC)

Eh. "Enact" and "take effect" are the same in arb-speak, and I think trying to draw a semantical difference between the two would be dangerous. I generally don't like to open the doors on splitting hairs with definitions on things as serious as ARBPOL, the CU policy, etc., especially since those policies can have privacy implications. Even if this case wouldn't be dangerous, it opens a door I'd rather keep closed. ~ Rob₁₃^Talk 20:27, 19 April 2019 (UTC)

All the same, personally I wouldn't remove the option of having a higher standard required for a new change to be in force, for special cases. (Perhaps a big structural change will only get support from the arbitration committee if there is a net 30 votes in favour, for example.) However I agree for this particular scenario it's not necessary. isaacl (talk) 21:45, 19 April 2019 (UTC)

Once put up for ratification, the Arbitration Committee's stance on the change is basically irrelevant. We can't stop a ratification from occurring if it meets the criteria in policy once set into motion. ~ Rob₁₃^Talk 22:29, 19 April 2019 (UTC)

Yes, of course. Once ratified, the change will be part of policy. isaacl (talk) 00:53, 20 April 2019 (UTC)

Flooded with them hundreds unblocked following successful appeal

Original announcement

• Total waste of time. The indefinite block, community ban and slew of checkuser blocks have been kicked down the road, but they're coming. Nick (talk) 20:48, 14 April 2019 (UTC)
• I agree with Nick and I'd like to ask why we're going down this road again. This editor has shown time and time again, per the many discussions, block log on multiple accounts and egregious personal attacks, they either lack the maturity or competence to edit in a collaborative environment.Praxidicae (talk) 20:59, 14 April 2019 (UTC)

  This was a bit of an odd circumstance, in that FWTH was blocked because what they were viewing as a cleanstart (with User:Offend) was viewed as sockpuppetry by the blocking admin. In my opinion it's a bit of an edge case, in that they have no "sanctions" that would clearly prevent a cleanstart, but they also are not really "in good standing" with the community. I personally wanted to unblock with the one account restriction since I view this largely as a misunderstanding around the cleanstart—if they are being disruptive to the community in general then that can probably be handled by the community at AN, but it seems unfair to me to leave them indefblocked over a misunderstanding like this. GorillaWarfare (talk) 23:14, 14 April 2019 (UTC)

The fact that they thought it was okay to cleanstart is a problem itself in my opinion and against the spirit of CS and if they're actually being truthful about believing a clean start to be okay, makes me wonder about their competency. This user is a massive time sink and the fact that were still continuing to discuss it really just shows that in my opinion, especially given all the socking, PA and the lack of transparency as it pertains to their sock farm. Praxidicae (talk) 23:28, 14 April 2019 (UTC)

• IMO the community has grown very exasperated with this user and a wider community discussion is probably in order sooner rather than later. At the very least it would be helpful to get all the facts out in the open because this has clearly been going on for some time. —pythoncoder (talk | contribs) 22:07, 14 April 2019 (UTC)

  @Pythoncoder: Just to clarify, are you saying that there are facts that you feel you're still missing? GorillaWarfare (talk) 23:11, 14 April 2019 (UTC)

  I mean, like everything on Wikipedia, it's all spread across a bunch of pages. It's probably easier to find facts when you know where to look. —pythoncoder (talk | contribs) 00:33, 15 April 2019 (UTC)

• The logs summaries do not seem to align here - extended user groups were removed with the reason of "not trusted" however GorillaWarfare decided to add all the groups back. While admins are given discretion to issue these groups, the reason listed was "unblock request" - to GW: was this a discretionary admin action on your part, on behalf of the arbitration committee, or something else? — xaosflux ^Talk 22:12, 14 April 2019 (UTC)
  • The Arbitration Committee has taken no position on whether this editor should be in these user groups. I assume GW restored them because they were removed while the editor was blocked, as is normal for blocked editors. ~ Rob₁₃^Talk 23:02, 14 April 2019 (UTC)
    • Per WP:INDEFRIGHTS, removing rights is not what is normal for blocked editors. Are jokes about rogue admins allowed at ACN? Natureium (talk) 23:11, 14 April 2019 (UTC)
      • Perhaps I should have said "as is normal for CU blocked editors". When an editor is found socking, it's very typical to remove user rights obtained when the socking wasn't known, since they weren't granted based on a complete understanding of the user's contributions. ~ Rob₁₃^Talk 00:39, 15 April 2019 (UTC)

• @Xaosflux:My understanding was that the user groups were removed as a result of the block, not because of some other issue or discussion. I restored them since the block was addressed. If that's not the case and there was some discussion I missed, please let me know and I'll undo my action.

However, if you are concerned that FWTH should not have these userrights then it's my opinion that that should be addressed in a separate discussion, and they shouldn't lose their userrights as a weird artifact of a block/unblock cycle with no discussion.

It wasn't really an "on behalf of the Arbitration Committee" in the sense that we didn't discuss it as a part of the unblock request, so I guess you could consider it my individual admin action. GorillaWarfare (talk) 23:09, 14 April 2019 (UTC)

The removals were not noted as "per blocking" - perhaps @Lourdes: can expand on this as they performed the "not trusted" removal. — xaosflux ^Talk 23:30, 14 April 2019 (UTC)

Thanks for the reply GorillaWarfare - so this is just your admin reversal of Lourdes' action - and this could all be just fine; just that a reading of the right log is not giving a clear picture. — xaosflux ^Talk 23:33, 14 April 2019 (UTC)

Yeah, it would be helpful if Lourdes would weigh in on why she removed the rights. If it wasn't just because of the block then I misunderstood and will happily undo my action. GorillaWarfare (talk) 23:35, 14 April 2019 (UTC)

No issues in the rights being added back. GW is right in her understanding. Lourdes 02:27, 15 April 2019 (UTC)

• I’ve opened a discussion at Wikipedia_talk:Clean_start#Multiple_clean_starts to try to address this in policy so such misunderstandings don’t occur again in the future. TonyBallioni (talk) 23:59, 14 April 2019 (UTC)
• Sorry to somewhat necro-post. FWTH is asking me (permalink) to unblock some of their alt accounts which were blocked following the CU block. I have no issue with changing the block reason itself, but should these accounts be unblocked if they cannot use them anyway? I asked them why and they gave reasons, but since this did go through AC I thought I should check here first. Primefac (talk) 11:35, 21 April 2019 (UTC) (please ping on reply)
  • I don't think you should unblock those accounts. Any single-account restriction will be enforced by blocking all alts, under Wikipedia:Blocking policy#Enforcing bans, and I see little good reason to make an exception at this early stage. AGK ■ 12:17, 21 April 2019 (UTC)
    • He's taking the piss with his request, and frankly, ArbCom is taking the piss by allowing Flooded with them hundreds to continue fucking about on this site. I suggest we just re-block Flooded with them hundreds, then we can close this section and archive it. Nick (talk) 13:58, 21 April 2019 (UTC)
  • "It would be nice to not... see their usernames striked out"—This is a garbage reason. Just disable the gadget, FWTH. —pythoncoder (talk | contribs) 20:35, 21 April 2019 (UTC)
    • What Nick and Pythoncoder said. This kind of petty obnoxiousness and constantly demanding special treatment is exactly what what made FWTH and his army of socks so thoroughly unpleasant to anyone who had the misfortune to encounter him (quite why we're wasting any time at all earnestly discussing the terms for the return for the guy who gave us Fucking cunt, that's all you can do you lifeless pussy. I demand you delete my user page as well you son of a bitch. Lifeless faggot, you have nothing else to do in your life that's why you're being a bully on this useless Wikimedia site which I don't even use other than for uploading shit. Fuck you faggot. I don't need to upload any dumb shit images. I don't know), and if he's still doing it in an unblock request that speaks volumes. ‑ Iridescent 21:00, 21 April 2019 (UTC)
    • it would be nice... yeah, it would be nice to not have this discussion twice a year about FWTH's (or whatever iteration they go by at the time) disruption. Praxidicae (talk) 21:29, 21 April 2019 (UTC)
• As it has been suggested multiple times here, and I agree that the latest request is just the most recent move in a series of actions designed to game the system and abuse our good faith going back years, I have opened a discussion at WP:AN about site banning Flooded with them hundreds as a community sanction. Notifying this thread since it is where the discussion originated. TonyBallioni (talk) 21:50, 21 April 2019 (UTC)

  Thanks for leaving a note here. GorillaWarfare (talk) 23:23, 21 April 2019 (UTC)

  Closed with snow consensus to siteban. —pythoncoder (talk | contribs) 00:47, 23 April 2019 (UTC)

Bradv appointed as clerk

Original announcement

• Congrats @Bradv: Dusti^{*Let's talk!*} 17:59, 23 April 2019 (UTC)

• • And from me. Doug Weller talk 18:34, 23 April 2019 (UTC)

Also me. Best, Barkeep49 (talk) 21:44, 23 April 2019 (UTC)

Change to CheckUser team

Original announcement

• Welcome back. —pythoncoder (talk | contribs) 21:23, 29 April 2019 (UTC)
• Nice! ~Swarm~ ^{sting} 01:14, 30 April 2019 (UTC)
• ”He’s come about the reaping? I don’t think we need any at the moment.... Newyorkbrad (talk) 11:41, 3 May 2019 (UTC)

Thanks! Reaper Eternal (talk) 01:05, 4 May 2019 (UTC)

Little late to the party, but welcome back Reaper Eternal! . --TheSandDoctor ^Talk 07:15, 4 May 2019 (UTC)

Motion: Amendment to the standard provision for appeals and modifications (April 2019)

Original announcement

Are these "arbitration enforcement actions alleged to be out of process or against existing policy", considered to be sanctions, page restrictions, or something not covered under WP:Arbitration Committee/Procedures#Appeals by sanctioned editors? Under this amendment, who has standing to appeal a page deletion, or other enforcement action alleged to be out of process or against existing policy? Mojoworker (talk) 02:25, 19 April 2019 (UTC)

@Mojoworker: I would consider it a page restriction. Since it does not _target any particular editor, any editor has standing to appeal. ~ Rob₁₃^Talk 03:28, 19 April 2019 (UTC)

Please correct me if I am wrong, but does this change to procedures effectively prevent review of a page deletion as an AE action so long as a discussion at AE by uninvolved editors administrators concludes that the action was within the boundaries of discretion? It appears to me that we now allow:

• Admin X deletes page Y as an action under DS and marks it as an AE action.
• There need not be an AE discussion but presumably it would need to relate to some other action action under DS.
• The page creator or significant contributor (Z, say) may well also have been blocked for a time up to 1 year.
• Opening an appeal to question whether X was authorised to delete Y at AE may be refused for lack of standing with Z blocked. If not, the decision will look at X's discretion and not need to consider whether Y was deletable under policy. If the action is judged to be within X's discretion, the only permissable action would be via ARCA.
• Taken to ARCA, the deletion would still be considered on "allowable discretion" grounds, not on the policy basis for deleting Y. This could languish unresolved for weeks to months.
• If a DRV were opened, an admin following WP:RESTORE could be blocked at AE or be desysopped by case. The same fate could await any admin undeleting even if DRV was unanimous that there was no policy-based justification for deletion except the argument that ARBPOL give ArbCom the right to delete anything whether there is a deletion policy basis or not and that ArbCom DS granted this same discretion to administrators acting in DS areas.
• The only way the policy justification / rationale for a deletion becomes significant is at DRV and that can only be started once AE or ARCA has found that X acted outside allowed discretion and after any appeal to ARCA is completed.

Am I misunderstanding, because this situation looks ridiculous and would justify clarification of ARBPOL about ArbCom's authority to delete and what can be delegate on to admins looking at DS areas and imposing AE sanctions. EdChem (talk) 01:37, 21 April 2019 (UTC)

I don't entirely understand everything that EdChem has written, but my understanding of the situations regarding page deletion are:

• Admin X deletes page Y as an action under DS and marks it as an AE action.
• The page deletion may be appealed by any editor at AE (after discussion with admin X).
• Discussion at AE may conclude that (i) the deletion was an appropriate action in the circumstances and the page should remain deleted; (ii) the deletion was not an appropriate action in the cirucmstances and should be restored; (iii) the deletion was not an appropriate AE action in the circumstances but it was ok as a normal admin action (this would leave the page deleted but without prejudice to a DRV).
• An admin reverting the deletion:
  • without the permission of admin X prior to the conclusion of the AE appeal or after conclusion (i) would be subject to sanction or desysopping in the same way they would be for reverting any other AE action.
  • after conclusion (ii) is implementing the consensus of the AE discussion and so acting correctly
  • after conclusion (iii) is not reverting an AE action and so policies regarding arbitration enforcement do not apply.
• Whether the creator or significant contributor is blocked I see as completely independent. It should have no bearing on the discussion regarding page deletion, and any discussion about the page deletion should have bearing on any appeal that editor may make.

Personally, I cannot imagine endorsing the deletion of any page in circumstances not permitted by the speedy deletion policy. Indeed, I would like it explicitly written into policy that under no circumstances may any admin delete any page as an AE action if the speedy deletion policy would not permit that deletion as an ordinary admin action and that deletions contrary to that policy may be grounds for desysopping. Thryduulf (talk) 12:48, 21 April 2019 (UTC)

I agree with Thryduulf. This is a step too far in the exercise of the powers the community has granted to ArbCom. Admin actions are normally subject to checks and balances in that they may be reversed on the considered judgement of any other admin, and that has worked reasonably well (albeit not perfectly) for most of Wikipedia's existence.

The reason that AE actions were created was to remove second-mover advantage in the case of blocking certain editors, who would otherwise be unblockable. It was never designed to reinforce first-mover advantage to the extent that it can become a shield to defend abusive or mistaken administrative actions. Taking an action as ArbCom Enforcement should not be taken lightly, for these very reasons, and in order to maintain the necessary checks and balances there must be consequences for admins who misuse or mistakenly use the label of ArbCom enforcement for their actions. Either ArbCom or the community needs to spell out very clearly what areas should not normally (i.e. excepting only IAR) be within the purview of AE actions, and the consequences to admins who persistently display poor judgement in applying AE actions.

Finally, the community needs to make clear that it retains the final say in making policy. Where an ArbCom procedure conflicts with (or in this case, attempts to override) existing established policy and practice, then ArbCom really ought to be seeking community approval to vary the relevant policy through RfC, not through fiat. --RexxS (talk) 15:08, 21 April 2019 (UTC)

• Thryduulf, your summary lists three possible conclusions at AE: (i) the deletion was an appropriate action in the circumstances and the page should remain deleted; (ii) the deletion was not an appropriate action in the cirucmstances and should be restored; (iii) the deletion was not an appropriate AE action in the circumstances but it was ok as a normal admin action (this would leave the page deleted but without prejudice to a DRV). Take a look at the view expressed by current Arb BU Rob13 that begins I would 'decline this. I think it is within administrator discretion to consider this a violation of WP:POLEMIC. As I pointed out above, this is not a comment on whether the action was appropriate, it is an argument (common at AE) that the administrator acted within their discretion. It allows unilateral deletion without a consideration of the merits under the deletion policy and it would prevent a DRV (which has already demonstrated a strong consensus that the deletion should be overturned) from even being opened. Take a look at the comment from Timotheus Canens that says Having considered the comments at the DRV to the extent they addressed POLEMIC (as opposed to the process issue), and after independently reviewing the page, I cannot say that GoldenRing's interpretation and application of that guideline is outside reasonable admin discretion, and that's all that is needed to sustain a discretionary sanction. Here is a former Arbitrator stating clearly that sustaining GoldenRing's action and preventing review of deletion under policy by DRV is allowed so long as the action was within admin discretion. Neither Rob's nor TC's conclusions fit under Thryduulf's three possibilities, they fit into "it doesn't matter if a deletion action is appropriate, in line with deletion policy, fitting a CSD criterion, essentially a content ruling, or anything else, so long as it is tangentially connected to a DS area sufficiently to be arguably within admin discretion." Whether all the present members of ArbCom intended to or not, the effect of this procedural modification is to make any action, no matter what it is, protected if it is labelled as an AE action, and that has clear implications for policy. An admin like Bishonen could be desysopped (as was suggested / ?threatened) by GoldenRing and Sandstein) for undoing an AE action where the justification for that action and its basis in policy is questionable, at best, and where the standard community process was being invoked. We now have a situation where review of an alleged AE deletion is only possible by first getting AE, AN, or ArbCom at ARCA to agree to remove the AE protection – only then can a DRV occur. Further, it empowers these venues to skip DRV and make what can be a de facto content ruling. This procedural change allows a deletion to be endorsed as "within discretion" for an individual admin despite no CSD criterion being met and without looking at the merits of deletion, instead only considering the breadth of discretion available. It is, in my view, fatally flawed and must be fixed by the Committee or the community will need to take action under ARBPOL. I can see no reason for allowing AE deletions at all. Such deletions should be regular admin actions under CSD or MfD, etc, and if they can't be so justified, they should not occur. Carving out a power for ArbCom to delete as a non-delegable power for rare cases that Rob has alluded to makes sense to me, however. EdChem (talk) 01:24, 22 April 2019 (UTC)

  1) My position would have been very different if the deletion actually presented a case of what you call a "de facto content ruling" (which neither arbcom nor AE can do). As I noted immediately prior to the sentence you quoted, I do not believe this one does. 2) That AE review generally recognizes admin discretion hardly means it is not considering the merits of the deletion (or block, or topic ban, or whatever). DRV also recognizes closer's discretion, especially for contentious or difficult XfDs, but that doesn't mean that DRV is not reviewing the close on the merits. The merits being the substantive correctness of the deletion, not whether it followed the standard CSD/MfD process. 3) Yes, this means that a handful of borderline pages may be deleted that wouldn't have been otherwise (given how rare AE deletions have been, I think even "a handful" is a generous estimate), but that's no different from every other aspect of the DS system. T. Canens (talk) 02:23, 22 April 2019 (UTC)

  • I really think everyone should pay attention to the first sentence of T. Canens just said. Editors keep talking about content with relation to this specific page. This page was not content. It is a wholly reasonable view for the community to reject 100% of AE deletions in mainspace as outside administrator discretion, for instance. I think it's tremendously unhelpful to conflate deleting a userpage being used to store diffs of alleged misconduct with the deletion of encyclopedic content. Those are two extremely different things. The former relates to behavior, which is an area within which ArbCom may act. ~ Rob₁₃^Talk 05:57, 22 April 2019 (UTC)
    • And EdChem, that is a poor understanding of "administrator discretion". The existing discretionary sanctions procedures prohibit actions that are grossly disproportionate. Merely being in a topic area with DS is not a license for an admin to do whatever they like. It is a license for them to act decisively if the disruption warrants it, with the benefit of the doubt given unless a consensus of admins disagrees with their action. ~ Rob₁₃^Talk 05:59, 22 April 2019 (UTC)
      • BU Rob13, an admin decided to delete a page (yes, non-article space) as a DS / AE action. There was no consensus that deletions of that type are authorised, and a strong consensus at DRV that they are not. The admin who recommended DRV was told they may face a desysop by two prominent admins at AE. ArbCom took ages to fail to reach consensus that AE deletions are allowed, but added to procedures to further protect AE / DS actions from community action. And you want me to accept that DS is not a license to do whatever an admin can get away with, if not quite whatever they like? You yourself posted at the AE thread arguing that the action was within discretion and thereby protected from DRV by the community, despite knowing that the DRV as concluded the deletion is unjustified. Former Arb TC has argued similarly. I note you did not go against the DRV conclusion that POLEMIC does not apply, instead arguing that GR's view that POLEMIC did apply was within admin discretion ("it is within administrator discretion to consider this a violation of WP:POLEMIC"). Deletions should not be single-admin judgements with no means of community review and endorsable as "within discretion" without necessarily concluding reasonable / correct / supported by consensus. AE has evolved over time to utterly disregard non-admins and to become a law unto itself. ArbCom has failed to check this trend, and in the present case, have taken a step to show just how flawed this area has become. ArbCom could have said that deletions should be guided by policy, in line with CSD etc, quietly accepted and recognised the DRV, and issued a statement that GR had acted in good faith but beyond established bounds. Things would have quietened down, AE could have stumbled on, nothing would have changed. Instead, internal ArbCom disagreements prevented such an approach, and you (collectively) coalesced around a strengthening of AE-related procedure, apparently hoping to avoid future DRVs causing embarrassment to community-unsupported AE deletions. That decision has had consequences, visible here and with Cunard's AN proposals. I hope they go somewhere and AE and ArbCom get reined in a bit. EdChem (talk) 06:58, 22 April 2019 (UTC)
      • I'm sorry, BU Rob13, but that's not how AE actions should be working on Wikipedia. If a userpage contains diffs of alleged misconduct, and they are not going to be used soon, then all our precedent shows that they can be deleted, either by CSD#G10 or by MfD. There is no reason whatsoever why such a deletion needs to protected from second-mover advantage. Nor is there any sensible reason why the normal community process of DRV should not be used to review that deletion if challenged. ArbCom has no mandate to alter or override the community's policy and needs to alter course away from attempting to shape policy to suit its fancy. --RexxS (talk) 13:01, 22 April 2019 (UTC)
• @EdChem: this is not a comment on whether the action was appropriate, it is an argument (common at AE) that the administrator acted within their discretion. If AE decides that the action was within discretion then it has decided that the action was appropriate for the circumstances. I disagree that it was appropriate, but that was the consensus of the discussion. Thryduulf (talk) 09:14, 22 April 2019 (UTC)
  • Thryduulf, I disagree. "Within discretion" and "appropriate" are not synonyms. "Within discretion" is much closer to "allowed" than it is to "appropriate." An action can be technically permissible while at the same time being unwise and even inappropriate. The AE archives show plenty of cases where an appeal has failed despite multiple admins expressing disagreement with a decision because the decision was deemed as "within discretion"... and let's not even get into the routine disregarding of the opinions of any non-admin editors, who are viewed as irrelevant for determining consensus at AE (much like the DRV is being treated in the present case). AE decisions regularly turn on whether an action is permissible / within discretion without actually addressing whether the decision was wise or appropriate. EdChem (talk) 13:28, 22 April 2019 (UTC)
• The recent amendment hasn't changed existing position or policy; it has simply clarified that if there is concern regarding an ArbCom Enforcement action, that it should first be discussed under AE procedures. The question regarding if a deletion outside of policy is allowable has not been answered as the Committee were unable to reach agreement on that. My own view is that any action within policy done in order to enforce an ArbCom sanction is and should be allowable. So, a mainpage deletion done under G5 to enforce an ArbCom sanction would be allowable. If the article can be deleted under policy it can be deleted under ArbCom protection to prevent it being undeleted in order for it to be discussed in several conflicting places. SilkTork (talk) 18:37, 22 April 2019 (UTC)

  @SilkTork: Claiming that the "amendment hasn't changed existing position or policy" doesn't make it so. It seems abundantly clear that ArbCom has now amended our deletion policies and guidelines to include an additional, compulsory step that requires an administrator's action to first be submitted for determination by other admins alone, whenever an administrator chooses to label a page deletion as an "AE action". That is not "clarification"; that is amendment. In the case of page deletions of any kind, ArbCom has not submitted any grounds for removing either the check of another administrator's judgement, or the scrutiny of the community in general over the action of deletion. You need to make clear to the community what benefit to the encyclopedia accrues from ArbCom's unilateral change to our current policies and practices, and submit your change to the community for its approval. --RexxS (talk) 19:29, 22 April 2019 (UTC)

What we are seeing here is exactly what I feared. An arbitrary different standard for deletion that has a) a different standard of reasonableness than other deletion and b) excludes the vast majority of the community from reviewing. There is a clear consensus this deletion was outside our policy and you have created a set up to.allow admins to side step it and two fingers to the community. So are you going to think again or are we going to have to take other steps to overturn this? By the way, can we appeal this AS decline to ARCA? Spartaz ^Humbug! 21:03, 22 April 2019 (UTC)

@RexxS and Spartaz: Your claim that AE deletions can only be reviewed by admins is not true; the clear and substantial consensus of ... uninvolved editors at AN (quote from Wikipedia:Arbitration Committee/Procedures#appeals.note is a permissible method of overturning an AE action. * Pppery * _{has returned} 03:13, 23 April 2019 (UTC)

@Pppery: please see this Arbcom resolution from last week "All actions designated as arbitration enforcement actions, including those alleged to be out of process or against existing policy, must first be appealed following arbitration enforcement procedures to establish if such enforcement is inappropriate before the action may be reversed or formally discussed at another venue." and a sitting Arb's statement at the Adminstrator's noticeboard: "Clarity ... What the motion that did pass say is that if there is again a deletion made under authority of ArbCom, the matter needs to come first to AE. The motion was merely clarifying where the discussion should first take place. At AE only admins can review the question. So I don't think ArbCom shares your interpretation, sadly. And that's why I'm so concerned. --RexxS (talk) 13:28, 23 April 2019 (UTC)

Where do you see that only admins may comment at WP:AE? When I read the giant red instruction box at WP:AE it says "All users are welcome to comment on requests." All users. Every one. Not just admins. --Jayron32 14:57, 23 April 2019 (UTC)

(1) The decisions at AE are made by admins only, not by consensus among all commentators. Each question has a section "Result of the ..." with the italic print below: "This section is to be edited only by uninvolved administrators. Comments by others will be moved to the sections above". You only have to read the "Results" sections to see clearly how decisions are made. Secondly, and rather more importantly for this issue, how would you expect an ordinary editor to comment on whether the page should be deleted or not, when only admins can see the deleted page? Sure. everybody is welcome to comment, but we're going to ensure that you don't know what you're commenting on, and we'll happily ignore you if you do. That's not my idea of how to do a DRV. --RexxS (talk) 15:12, 23 April 2019 (UTC)

Well, that's only broadly true because the results of such discussions are implemented by admins; non-admins cannot block someone! Admins base their actions, as always, on the input from users who comment on the discussion. This is exactly like everywhere else that admins implement decisions. Non-admins cannot protect pages which are under discussion at WP:RFPP, they cannot delete articles which are up for discussion at WP:AFD, they cannot block users who are reported at WP:ANEW. This is not a unique thing. That doesn't mean that admins are not supposed to take input from the community in such discussions. Community input from non-admins is explicitly encouraged and requested at WP:AE in exactly the same way it is in all admin-involved processes. You seem to have made this thing a precious thing where it is not. It doesn't have anything particularly special about it; indeed the process you are attempting to change is merely a simple means to avoid splitting discussions among different fora and nothing more; when an AE decision is made, it should be appealed here; but that appeal is open to the input of the community in the exact same way it would be at any other forum. --Jayron32 18:27, 23 April 2019 (UTC)

It would be nice if you were right about that, but a skim though the history of AE shows that you're not. Community discussion has never influenced decisions at AE. In fact, the process there allows a single admin who decides to impose a block to do so, even when a majority of other admins disagree. The entire setup at AE is not a suitable mechanism for reviewing out-of-process deletions. You still haven't addressed the point about how non-admins are supposed to comment when they can't even see the content that they are commenting on. --RexxS (talk) 18:52, 23 April 2019 (UTC)

That's also true of deletions by other methods: if an admin deletes anything, non-admins cannot read the page during appeals at WP:DRV. This is true even if it was deleted via AFD, PROD, or CSD processes. You're not making arguments that aren't applicable to other deletions. --Jayron32 12:50, 24 April 2019 (UTC)

On the contrary, standard practice at DRV is for an uninvolved admin to undelete the page in question so that non-admins can see the content and discuss whether the deletion was correct (the only absolute exceptions being if the page contains copyvios or BLP violations). This ArbCom-created amendment to our practice threatens to de-sysop any admin who carries out standard practice. Now do you understand what the problem is? --RexxS (talk) 13:42, 24 April 2019 (UTC)

@RexxS: following arbitration enforcement procedures and "at AE" do not mean the same thing. As I understand it, arbitration enforcement procedures refers to the Wikipedia:Arbitration_Committee/Procedures#Modifications by administrators (although I would likewise appreciate an arb clarifying), which, as I said earlier, allows appeals at AN in which non-admins' voices count toward the determination of consensus. You are, of course, right that non-admins cannot see the deleted content. * Pppery * _{has returned} 19:12, 23 April 2019 (UTC)

This is correct. Arbitration enforcement actions have always been appealable to AE, AN and ARCA. The motion reinforces that these are the allowed methods of appeal. The choice of venue is up to the appealing user; the only restriction is that once something is appealed to AN, an appeal to AE is unavailable; once something is appealed to ARCA, appeals to AE and AN are then unavailable. The standard of review is different at each. This is set out clearly in WP:Arbitration_Committee/Procedures#appeals.notes and this is hardly the first time it has been pointed out in this whole kerfuffle. GoldenRing (talk) 13:54, 24 April 2019 (UTC)

Then how do you square that with "Clarity ... What the motion that did pass say is that if there is again a deletion made under authority of ArbCom, the matter needs to come first to AE. The motion was merely clarifying where the discussion should first take place"[4]? And you still haven't answered how non-admins can be expected to comment on content that they can't see even if it were to go to AN or ARCA. --RexxS (talk) 15:17, 24 April 2019 (UTC)

• All community processes, including arbitration, are a servant of community consensus, not a master of it with any right to overrule it. If the community does not agree that a page should be deleted, that page should not be deleted, period. Whether administrators or ArbCom, no one ever has the authority to overrule a genuine consensus of the Wikipedia community. Seraphimblade ^{Talk to me} 21:19, 4 May 2019 (UTC)

Checkuser resignation

Per my comments in the section above, I am voluntarily resigning from the checkuser team. Accordingly, please remove the checkuser permission from my account. Ivanvector (^Talk/_Edits) 15:36, 4 May 2019 (UTC)

Ivanvector, I’m very sad to see this, but if you want to resign, you’ll need to make the request at m:Steward_requests/Permissions#Removal_of_access. TonyBallioni (talk) 15:41, 4 May 2019 (UTC)

Thanks, I had no idea where to actually make the request. Ivanvector (^Talk/_Edits) 16:11, 4 May 2019 (UTC)

Tony knows everything.--Bbb23 (talk) 17:26, 4 May 2019 (UTC)

Bbb23 it's lovely to see the humorous you back. Lourdes 03:05, 5 May 2019 (UTC)

Everyone knows that DoRD is the CheckUser who knows all. TonyBallioni (talk) 03:08, 5 May 2019 (UTC)

Administrator account security

Original announcement

• There are still some issues I have (see above) but I’m glad to see the ArbCom acknowledging their mistake. —pythoncoder (talk | contribs) 21:23, 4 May 2019 (UTC)

• I also am thankful that the 2FA requirement has been softened. Risker speaks my mind upthread. The WMF implementation of 2FA, and support for it, are awful. At a minimum, there has to be a well-defined, well-supported way for people who get locked out of their accounts to regain access, and there has to be a way to generate additional one-time codes without un-enrolling and re-enrolling as some users are in situations where they have to use them rather than a device. There are other problems particularly internationally with users who do not or can not have a cellular phone or cannot install security software without receiving unwanted state scrutiny. These have been well-covered elsewhere. I believe that the best way forward is for ENWP to pressure WMF to do something about the implementation, so that it can be fixed, rather than force adoption --- which will push the issue to the back burner. UninvitedCompany 23:18, 4 May 2019 (UTC)
  • @UninvitedCompany: I just want to be clear that this isn't a reversal by ArbCom. There was never a 2FA requirement. There was a poorly-worded mass message. That is all. ~ Rob₁₃^Talk 01:07, 5 May 2019 (UTC)
• I indicated in the original thread that I intended to protest this directive and would publish a statement to that effect; it's here. I find the "apology" insufficient, and in response to that I am disabling 2FA on my account, in solidarity with those who do not wish to or cannot enable it and are thus oppressed by this threat by the Committee. Ivanvector (^Talk/_Edits) 23:33, 4 May 2019 (UTC)

  We have explicitly clarified that The choice not to enable 2FA will not be considered when deciding to restore sysop privileges to administrator accounts that were compromised. GorillaWarfare (talk) 02:35, 5 May 2019 (UTC)

Arbitrators have specified elsewhere (in this discussion, I believe) that use of 2FA will be taken into account in determining a compromised account's security, and recent LEVEL1 actions suggest the Committee is already acting on this modification. Sorry, GorillaWarfare, you're either lying, or being fleeced by your colleagues. Ivanvector (^Talk/_Edits) 10:38, 5 May 2019 (UTC)

@Ivanvector: Diff, please. I don't believe any of us think that and yesterday we unanimously approved the statement that GW has just quoted. – Joe (talk) 11:04, 5 May 2019 (UTC)

Please don't accuse me of lying. As Joe said, I'm quoting the clarification that you received, that was approved by my colleagues on the Committee. GorillaWarfare (talk) 16:43, 5 May 2019 (UTC)

• In support of Ivan, I wish to note here that I have specifically chosen not to enable 2FA for my account, and I wish to mention here that the 19th character of my password is 7. Thank you. MPS1992 (talk) 02:33, 5 May 2019 (UTC)

•  Comment: I totally disagree, the post and the whole discussion is totally out of order, what are you even thinking going to the discussion, let alone sending any post. 2FA and administration policy are not yours. The Arbitration Committee has a very set scope "binding dispute resolution panel of editors", and it is not to set policy for administrators, as that falls totally within the scope of the broader community and by consensus. Just get back in your boxes and do the tasks for which you nominated and were elected, you are not elected as de facto rulers. — billinghurst sDrewth 03:16, 5 May 2019 (UTC)

@Billinghurst: In addition to arbitration, we are and always have been responsible for enforcing the community's admin policy, as the only body that is allowed to desysop in most circumstances. See point 3 of Wikipedia:Arbitration/Policy#Scope and responsibilities. – Joe (talk) 07:18, 5 May 2019 (UTC)

@Joe Roe: The rules that you implement are community's rules that are developed by consensus of the community, not imposed by AC autocratically. If you want administrators to do something, then put it before the community. Yes, the AC will put into place the community's consensus, not define it for us. AC does not set policy for administrators. — billinghurst sDrewth 09:16, 5 May 2019 (UTC)

@Billinghurst: That's right. That's what we're doing; enforcing the community's expectations on admin account security. They have been the consensus for years (WP:SECUREADMIN, WP:STRONGPASS, etc.) – Joe (talk) 10:15, 5 May 2019 (UTC)

@Joe Roe: it should be obvious to you by now, given the widespread anger that this notice has generated, that the community's expectations and the process you've decided to implement are not the same thing, at least as far as the "enforcing" part of it goes. I've heard of bunker mentality, but this is getting a bit ridiculous now. The correct course of action now would be to go to an RFC and determine if there is any appetite in the community for desysopping for cause if a password is hacked, and nailing down the exact circumstances under which that might happen. Because right now, the only mention of this is a rather vague "under certain circumstances". Thanks  — Amakuru (talk) 10:27, 5 May 2019 (UTC)

No it's not obvious. I see anger but have not been able to understand where it is coming from. Some of it seems related to the original poor wording, some to quite frankly seems to have nothing to do with this reminder about account security. I've asked several questions above to try to understand what policy we are supposed to have changed but have not got any answers. I can ask some more: what new process have we created, bearing in mind that we already desysop when accounts are compromised and the crats ask us to approve before resysopping? What would the RfC actually ask that isn't already the status quo? Do we have to hold an RfC to have the community explicitly tell us how to enforce every part of the admin policy, or is there something special about WP:SECUREADMIN?

Also worth mentioning that we've primarily heard from (a subset) of admins in this discussion, many of whom apparently didn't know that they were required to secure their account and are angry at the threat of losing their tools. When we discussed and passed the motion that prompted this message, the response from a wider section of the community was strongly supportive. Every time an admin account is compromised, there are calls from many people to be stricter at enforcing the rules, which is what we are now going to do. – Joe (talk) 10:40, 5 May 2019 (UTC)

(e/c) Per the above, I'm a bit confused. Under WP:SECUREADMIN it states: "Discretion on resysopping temporarily desysopped administrators is left to bureaucrats, who will consider whether the rightful owner has been correctly identified, and their view on the incident and the management and security (including likely future security) of the account". Does this mean that ArbCom has unilaterally decided to remove that discretion from bureaucrats? - Bilby (talk) 10:30, 5 May 2019 (UTC)

@Bilby: This was discussed at some length above and at User talk:BU Rob13. The short version as I understand it is that in practice, every time an account has been emergency desysopped ArbCom has passed a motion before resysopping, often with the crats explicitly asking for us to sign off on it before they act (e.g.). The change to our procedure was based on this status quo, and is simply saying that we will be applying some scrutiny before passing resysop motions in future. The text in WP:SECUREADMIN is not necessarily inconsistent with this. Theoretically the crats could decide they don't need a motion from us; or conversely, they could have a reason for declining to resysop even if we pass one. Neither situation is likely to happen, though. Personally I think that text is just very outdated: it was added in 2008, before ArbCom started handling emergency desysops (in 2009), and until recently this happened so rarely it attracted very little attention. I've not heard from any crats that they actually want this responsibility. – Joe (talk) 10:50, 5 May 2019 (UTC)

My reading of the motion is based on two lines:

In cases where an administrator account was compromised, the committee will review all available information to determine whether the administrator followed "appropriate personal security practices" before restoring permissions.

That seems to say that restoration is at the discretion of ArbCom, not the bureaucrats. Then we have:

If the Committee determines the administrator failed to secure their account adequately, the administrator will not be resysopped automatically. Unless otherwise provided by the committee, the administrator may regain their administrative permissions through a successful request for adminship.

Which says that if ArbCom decides not to return permissions, the decision goes to RfA, not the bureaucrats. This does not seem to be compatible with existing policy.

From what you are saying you can see the possibility that bureaucrats could decline a resysop or override ArbCom's decision not to return rights, but the wording doesn't make any suggestion that this is the case. If it was to be the case, then the wording should be about ArbCom making a recommendation to resysop or not to restore rights, rather than ArbCom restoring permissions or requiring an RFA to get them back. Given that, it seems that policy needs to be changed to match this motion, which would normally involve community discussion. - Bilby (talk) 11:12, 5 May 2019 (UTC)

I think this discussion really needs some input from crats, rather than people getting angry on their behalf, because I actually have no idea under what circumstances they'd be comfortable resysopping without instruction from ArbCom or RfA. I like the "recommendation to resysop" wording; that more closely matches my understanding of ArbCom's role at least. I'll see about amending the procedure again. Lourdes has opened a discussion about changing WP:SECUREADMIN to reflect current practice at Wikipedia talk:Administrators. – Joe (talk) 11:23, 5 May 2019 (UTC)

Briefly, because I am on time crunch: bureaucrats are not an investigative body; except where they have multiple hats they do not have access to checkUser and as far as I know, no special access to information from T&S, so having the committee make recommendations based on their findings seems most prudent. –xeno^talk 11:46, 5 May 2019 (UTC)

I'm ok with the principal, but I disagree with the reading that ArbCom making these decisions instead of bureaucrats is compatible with existing policy. I'd like to see the policy changed rather than overridden, and that's ultimately a community decision. Otherwise, I'm not worried as to who makes what recommendation. :) - Bilby (talk) 12:39, 5 May 2019 (UTC)

• This is not the first time, "you won't be automatically resysopped for failing to secure your account" was iterated by an AC member, though. I believe there was a conversation about the fact that we should not resysop administrators who fail to do so and an AC member reiterated that as well. Maybe no one got to know then. Either way, I think it should not be that difficult to have a proper 2FA implementation or even something like SSO/Social Login. Federated identity is increasingly easier to use than traditional email/password and saves you from having to remember too many, just keep one and make it difficult and hard to guess. --qedk (t 桜 c) 04:36, 5 May 2019 (UTC)
• The problem isn't WP:SECUREADMIN, it is WP:ARBPOL, which gives zero authority to ArbCom over resysopping. I think the existing practice makes sense, but for the fact that it is clearly inconsistent with policy. An update to SECUREADMIN will be needed, but first a change to ARBPOL needs to be proposed and put to the community. It should be coupled with a change to ratification to make it 100 net supports, and ideally one to include deletion as an ArbCom-permitted action under constrained circumstances, and one not delegable... though I doubt ArbCom will propose the deletion parts themselves. EdChem (talk) 13:55, 6 May 2019 (UTC)

See the related discussion at Wikipedia:Bureaucrats' noticeboard#Discussions concerning bureaucrats and dealing with compromised administrator accounts, where the consensus from the crats so far is that they won't resysop without an ArbCom motion. If people are going to insist that we don't have the authority to pass such motions, this means no accounts desysopped under WP:LEVEL1 will be able to regain the tools without a fresh RfA. I think that this is the opposite of what you want. – Joe (talk) 14:00, 6 May 2019 (UTC)

No, it means ArbCom have taken on dealing with something for which they have neither authority nor mandate. It amounts to applying IAR to ARBPOL which logically means ArbCom has no limits except those that it imposes on itself. ArbCom having a role in resysops makes sense and I doubt anyone thinks that only a fresh RfA is a sensible solution (and bureaucrats acting unilaterally or RfA is a false dichotomy)... so fix it properly by fixing ARBPOL, and make some other sensible updates at the same time. EdChem (talk) 14:15, 6 May 2019 (UTC)

I think the major point of contention is that the committee does not really have the authority to grant administrative permissions- the final job to decide when/if to resysop really lies with bureaucrats. The committee should instead be recommending the permissions be restored (following their investigation of the breach and receiving satisfactory assurances, etc.), or, in the case of gross negligence of account security practices, passing an explicit motion permanently revoking the administrative privileges of the user involved (which would be binding on bureaucrats and look less like a backdoor desysyop). [x-post from WT:ADMIN] –xeno^talk 15:22, 6 May 2019 (UTC)

As the arbitration committee has the ability to direct the removal of administrative privileges, it makes sense for bureaucrats to co-ordinate with the arbitration committee on these situations, so we don't get a case of a bureaucrat restoring privileges and the arbitration committee directing their removal shortly afterwards. It seems reasonable though for the arbitration committee to explicitly record their decision to permanently revoke privileges, as you suggest. isaacl (talk) 16:50, 6 May 2019 (UTC)

Yeah this seems to be something which is IMO missed in a lot of this discussion. While it may be true that arbcom has no role in resysoping, they do have a role in de-sysopping. So sure, bureaucrats could simply resysop regardless of what arbcom says, but arbcom could then easily open a case or pass a motion deciding to desysop the person who was just resysoped and the bureaucrats would I presume take action. Maybe people prefer it's done like that even if it seems somewhat bureaucratic and there are reasonable discussions to be had about in what conditions are arbcom allowed to de-sysop, but we should remember how arbcom is effectively involved. IMO one possible solution, is there's any reason for arbcom to wait until someone is resysoped? If they feel they have sufficient grounds for a desysop in accordance with community norms and the areas arbcom is allowed to act, and if a desysop is only intended to be temporary, I don't see why they can't decide to desysop someone who is not currently an admin due to a temporary security related de-sysop. And frankly, I also don't see why bureaucrats can't just say to arbcom "is there any resonable chance you will ask for a desysop in the next ~10 days, because if you do it's a waste of our time to resysop"? Nil Einne (talk) 19:15, 6 May 2019 (UTC)

Why?

Why is the current ArbCom so good in ignoring established community consensus (the 2FA rfc which just ended), and so wary of bringing their own wanted changes or clarifications to a binding community discussion (the AE deletions, the "new RFA after compromised account" and ruling out the role of the bureaucrats stuff)? It may well be that some of this is already current and good practice and will have no trouble getting accepted (in which case, there should be no problem with an RfC, it should be a walk in the park), and it may also be the case that other aspects will not get community support (in which case they shouldn't be arbcom policy or practices surely?), or needs rewording to get accepted. Please, if you want to restore some confidence in this ArbCom instead of being seen as tonedeaf powergrabbers, retract the statement (and the AE deletions stuff), and bring changes you feel are warranted, even if you think it is uncontroversial, to the proper community discussion boards instead. Fram (talk) 08:37, 6 May 2019 (UTC)

Well I'm going to stick my nose in this one, too.

1. There is a "best practice", but it is not being widely adopted. Some think the best practice is too new and unproven; others think it's long past time it was made mandatory. You think if more people tried it, they would see it's worth doing. How do you get more people to adopt it?
2. There is a confusing rule. It involves overlapping areas of authority. Nobody is entirely sure what the correct interpretation of the rule is, and where one area of authority ends and another begins. Opinion is divided on "what is" and "what should be", and various groups have a stake in the outcome. How do you get everybody to agree on where the boundary is?
3. A new rule was adopted, but it was communicated poorly. The language used in the announcement of the rule didn't accurately reflect what the rule is. People are responding to the announcement rather than to the rule itself, and as a result, negative opinion is snowballing–and for no good actual reason. How do you put that cat back in the bag?
4. Management missteps have decreased confidence in management. How can it be restored?

These problems are not unique to Arbcom or Wikipedia. These are perennial problems faced by all sorts of organizations (like WMF for example). There are "dos" and "don'ts" for each of these common situations. Arbcom has been providing some textbook examples of the don'ts lately. It's a hallmark sign of people making managerial decisions without enough prior managerial experience. So, for example, no attempts were made to obtain buy-in from stakeholders prior to making changes. No "listening tour" was held. No attempt was made at making changes gradually rather than all at once. When people complained, those receiving the complaints bickered, nitpicked the format of the complaints, and questioned the reality of the people complaining (tried to convince them that what they were seeing was not actually happening). A victim/thankless-volunteer mentality was adopted by some in response to the complaints, an attempt at "turning the tables" between aggrieved and aggriever. The result has been a marked decrease in confidence, and # 4 above, where we are now, has "dos" and "don'ts" as well. I hope Arbcom gets it together here and adopts best practices for crisis management. I imagine there are some members of Arbcom who have prior real life experience dealing with situations like # 4, and some who don't. Those who don't should be listening to those who do. There are many books and articles written about how to handle this exact situation; members may want to consult them before deciding on next steps. (The preceding 2¢ are free of charge.) Leviv ich 16:04, 6 May 2019 (UTC)

​But Arbcom aren't "management", and the reasons we have the enormous walls of text above and every admin has a big spam message on their userpage ultimately stem from the fact that this incarnation of the committee seem to be under the impression that they are. They have five clearly specified responsibilities, none of which are anything to do with "managing Wikipedia", and nothing else. ‑ Iridescent 16:12, 6 May 2019 (UTC)

It's an analogy. They're in a position of authority/responsibility/prominence/figureheadship/whatever you want to call it, let's not split hairs about the wording. Tell me you disagree with the substance of my comment–i.e., how they should be handling these situations v. how they have been handling these situations, and that these are situations faced by other committees/people-in-positions-of-whatever, etc.? (And if we are splitting hairs, Arbcom is management. They manage a number of things, like the five you linked to, Arbcom itself, discretionary sanctions, conduct disputes, desysoping for cause, etc. Leviv ich 16:15, 6 May 2019 (UTC)

1 & 2 aren't in their remit so they shouldn't be trying to handle them in the first place; 3 is a by-product of their attempts to address 1 so wouldn't have arisen if they'd stayed within their remit; 4 is irrelevant as they're not management, leadership, etc. They're a group of people appointed to perform a specific task; calling Arbcom "Wikipedia's management" is no more accurate than calling the holders of the TemplateEditor userright, or the members of the Bot Approvals Group, the "leadership" because they manage the specific tasks within their area. ‑ Iridescent 16:20, 6 May 2019 (UTC)

Woah! Nobody said "Wikipedia's management". That's a bit of a straw man; no one has ever made that claim, have they? But I think you're kidding yourself if you think they're not in a position of authority. They have the authority to desysop; that's huge. They are the final arbiters of that. They are the final arbiters of discretionary sanctions, which is also huge. 1 & 2 may not be in their remit to change, but it is in their remit to enforce. (And if they had done the listening tour thing, they'd have learned that changing 1 & 2 isn't considered by the community to be in their remit, which would have avoided 3 & 4.) They are elected officials, and like all elected officials, they have certain powers and duties by virtue of their office. That doesn't include setting policy (in the sense of WP:PAGs), but it does include setting "procedures" (a type of "policy" in the sense of the English word). The difference between policy and procedure is an example of # 2. Every elected official has to deal with the boundaries of their authority; it's a perennial issue for anyone in their position. Leviv ich 16:36, 6 May 2019 (UTC)

I'm just glad there's yet another thread about this, seems like a great idea. Beeblebrox (talk) 19:27, 6 May 2019 (UTC)

In a way, all the recent activity on this page and elsewhere is somewhat comforting. There are still people who are very passionate about this project, which is nice to see. Even if, quite plainly, none of this matters and none of it is of any real importance or significance. There's a simple beauty in the inescapable fact that there's little way to know whether the person posting under the "MZMcBride" or the "Iridescent" or the "SlimVirgin" account today is the same person who was posting under it in 2017 or in 2013 or in 2008. We're left to evaluate edits and other actions themselves, in the current context. --MZMcBride (talk) 05:46, 7 May 2019 (UTC)

Discussion started at Wikipedia:Village pump (policy)#Permanent desysop of compromised admin accounts, feel free to add pointers to relevant policy pages and discussions, or to notify other editors. A list of previously compromised admin accounts may perhaps be useful as well. Fram (talk) 08:40, 7 May 2019 (UTC)

Some thoughts on 2FA for admins

I'm going to skip the whole ArbCom bashing thing, partly because other people have done a good job of that, and partly because I don't think ArbCom deserves most of the bashing they've gotten. But, I do want to address a couple of points.

First, the oft-quoted idea that being a sysop is not a big deal. That may have been true when it was first said, 16 years ago. Things have changed since then. What was an interesting idea in 2003, has become one the world's top five sites. As such, it's a constant _target of attack, subject to everythingthing from random vandalism, to pay-to-play SEO companies, to well-organized sockfarms. I can only assume we're subject to covert operations by governments as well. It's very much a big deal.

Being entrusted with admin tools requires that in return, the admin takes reasonable precautions to safeguard access to their account. Admin accounts being hacked is no longer a theoretical problem. It's something that's happening on a regular basis. It's clear that admins, as a group, need to be doing a better job of securing their accounts.

People have raised some legitimate reasons why 2FA may not be usable by some admins. They may not be able to afford a device to run the token generation software on. They may be prohibited from downloading the software by the security procedures of their school or employer, from whose hardware they access wikipedia. They may access wikipedia from a public access location, such as a library, where they can't load any software on the machine they're using. I'm guessing the number of admins who fall into this group is fairly small, and WMF could just give or lend them a hardware security token, at no charge. The cost would be trivial.

There have also been complaints that WMF does not provide sufficient support for 2FA infrastructure to depend on it as a production service. On this one, I agree with the bashers. It's something WMF really should make a priority. I assume they're already using 2FA to control access to their production server farms. At least I hope they are. So, extending this production-level support to admins (and the even smaller set of functionaries) seems like a no-brainer.

-- RoySmith (talk) 23:38, 4 May 2019 (UTC)

Hi@RoySmith:, and thank you for commenting. One of the core issues here is that 2FA is intended to be a global Wikimedia solution; it's not just for us on English Wikipedia, there is a plan to require it for every single admin on every single project, in addition to several other groups of users. We're talking somewhere between 5000 and 6000 users just to cover the admins and people with access to private WMF-owned wikis. Many of these people live in places where a hardware token generator would be either illegal to have in their possession, or it would be a violation of US law for the WMF to send it to their country. This isn't a small issue, and it was a very major stumbling block during the earliest 2FA discussions many years ago. The reality is that we, as a broad global community, *know* that there are currently administrators who live in countries where even uploading the 2FA software could result in reprisals against the individual administrator. For all we know, some of those are administrators on English Wikipedia; in fact, I'm pretty sure there are a few who fit into this category. We're a global movement with a stated goal of having a broad, diverse community; we need to work hard to ensure that barriers related to geography, economic well-being and employment do not prevent our editors from reaching their full potential.

To the best of my knowledge (and I've been following the account compromise issue very closely), every single enwiki account compromise was directly related to poor password hygiene. There were other breaches outside of our own project as well, but they happened using another vector and it was acknowledged after investigation that 2FA would not have prevented those breaches (the issue was resolved and verified to have been corrected). It's still possible for people to get their account hijacked even if they have 2FA; even though the average Wikipedian is probably more aware of internet security than the average consumer, we've seen indications that accounts have been taken over through other types of malicious software over the years, and in some cases 2FA would not have prevented that either.

I support Arbcom reinforcing the importance of excellent password security. Several months ago, I proposed to the functionary group that we champion having administrators sign off on a statement that confirms they meet the password requirements; that they have never used the same password anywhere else; that they have a different also-unique password on the email account attached to their admin account; and acknowledging that if they do not have a durable email address attached to their admin account, there is a very high chance that the account cannot be recovered, and their permissions will not be returned. I still think this would be a good idea, and I've already spoken to the WMF to obtain access to the LegalPad software for the signoffs (it's the same software that CU/OS/Arbs and others use to sign off on the confidentiality agreements), so this is quite possible if the community feels it would be useful. It would certainly remind administrators of their own personal responsibility with respect to their account. I'd suggest it be voluntary at first, and see how things go. Risker (talk) 01:16, 5 May 2019 (UTC)

I assume the issues with hardware tokens are related to crypto. What about biometrics? Does that suffer from the same export/possession problems? Biometrics are not as good as time-based token generators, but a password plus biometric is certainly better than a password alone. In any case, even if we only required 2FA from admins who reside in places where there's no legal barriers to employing crypto-based technologies, that would be an improvement. And the fact that there may exist attacks which 2FA would not prevent, doesn't mean that 2FA is useless. -- RoySmith (talk) 01:52, 5 May 2019 (UTC)

Are you seriously suggesting that admins should have to have a fingerprint or retina scan to sign in to Wikipedia? ♠PMC♠ (talk) 02:09, 5 May 2019 (UTC)

Don't be ridiculous. Iris scans are much more accessible than retina scans. Natureium (talk) 02:19, 5 May 2019 (UTC)

@Premeditated Chaos: no, that's not what I meant. What I meant was that it should be available as one possible way to implement 2FA. Thus, a user could elect to use "password + TOTP token". Or, if that's not possible for them, they might elect to use "password + fingerprint". And, the gist of my question was whether doing that would significantly expand the population of admins who could use 2FA of some kind. -- RoySmith (talk) 11:58, 5 May 2019 (UTC)

I really don't feel like it would. The kind of people who don't have easy access to things that make 2FA workable, like spare cell phones, are hardly going to have easy access to fingerprint scanners. ♠PMC♠ (talk) 12:06, 5 May 2019 (UTC)

Oh my, @RoySmith:. The MediaWiki Extension:OATHAuth (the 2FA extension) is a very simplistic extension built in 2012; it is my understanding that it was built to respond to a specific type of breach occurring on accounts that have much higher access than Wikimedia admins. It hasn't been significantly improved since its inception, and is not what anyone would call state-of-the-art. It was not designed for use by a global community; it was designed for use by WMF staff and a limited number of developers and a few select others who all live in large Western countries. Simply put, it's not built for the purpose that is now being pushed. The WMF doesn't own it, manage it, improve it, or provide user support for it; it doesn't appear on any WMF department's software management program. If you're well-connected technically and high-level WMF tech or Trust & Safety staff know you, you'll probably be okay if you have a problem. If, however, you don't know a senior developer personally or you haven't got an established relationship with the "right" staff people, it's going to be very hard to get support. The problem isn't 2FA per se; it's that the only acceptable 2FA supported in MediaWiki is not an appropriate product for a diverse, inclusive, global organization. Risker (talk) 02:29, 5 May 2019 (UTC)

@RoySmith: If the idea "being an admin is no big deal" is outdated I think the prominence of the quote by Jimbo Wales on Wikipedia:Administrators#History should be re-evaluated. The page even says: "Stated simply, while the correct use of the tools and appropriate conduct should be considered important, merely "being an administrator" should not be." WhisperToMe (talk) 07:26, 5 May 2019 (UTC)

Risker, do you know if there have been incidents of admin accounts being compromised through the route of an emailed password reset reaching a compromised email account, rather than the admin wikipedia password itself being compromised? Thanks. 67.164.113.165 (talk) 03:39, 5 May 2019 (UTC)

I agree with Roy's comments above. While the current implementation of 2FA is better than nothing, it's clunky and outdated and raises the risk of admins being locked out of their accounts. While I take the points Risker notes around solutions like a token being unworkable or even actively harmful for some admins due to legal issues, I imagine that almost all the admins of this Wikipedia live in countries where they'd be entirely fine. I'd also encourage the WMF to prioritise this kind of support for admins, and it would be helpful if ArbCom could communicate this to them. Nick-D (talk) 07:49, 5 May 2019 (UTC)

Do we actually have a slightest idea in which countries our admins reside?--Ymblanter (talk) 10:57, 5 May 2019 (UTC)

Considering ENwiki's international nature, admins can come from all over. I reside in the PRC right now, though I was born and raised in the US (I only started working long term in China in 2014). WhisperToMe (talk) 16:37, 5 May 2019 (UTC)

There are a few countries that we cannot provide certain types of encryption to (under US law) and a few other countries that won't let certain types of encryption in (without paperwork/license, or at all). I think that is another part of the problem. --Rschen7754 21:05, 5 May 2019 (UTC) (Edit: It appears that we even have an article on this: Restrictions on the import of cryptography, Export of cryptography from the United States). --Rschen7754 21:17, 5 May 2019 (UTC)

Jehochman's somewhat informed comments

• To make 2FA usable, Wikimedia needs to provide support. For instance, if you lose your authenticator, you need to get two or three other trusted, logged in users to vouch for you, and then 2FA is briefly turned off so you can then login. Sending people tokens and asking them to write them down violates several principles of cybersecurity. First, the paper tokens don't expire until used, unlike authenticator tokens that expire after 30 seconds. Second, we should never write down passwords (yeah, everybody does, but this shouldn't be encouraged). Third, a typed security token can be phished just as easily as a typed in password.
• If I wanted to hack administrator accounts, I would spear phish admins with a phony message that triggers them to login to a fake Wikipedia page where I'd harvest their password and authenticator token. This sort of attack also works against 2FA, which is why 2FA isn't really the answer. It's just another layer of duct tape on a broken user authentication system. For real security we'd need a PKI solution, which presently does not exist in a form that is economical and convenient for ordinary users. Until that system exists, I recommend letting people use their passwords and password lockers, and provide support for the account that occasionally gets hacked, rather than sanctimoniously blaming the victim.
• Tracked in Phabricator
  Task T189641
  
  One excellent way Wikipedia could reduce password risk would be to scan all passwords to see if they are listed on https://haveibeenpwned.com/Passwords. Then, automatically disable any that have been exposed, and force the user to choose a new one that hasn't been exposed.
• ArbCom: please stop trying to make cybersecurity policy. You are breaching the limits of your competency. Jehochman ^Talk 13:10, 5 May 2019 (UTC)

• To piggy-back on second-last point, why can't ask the developers to make every admin change their password You enforce a minimum character count and you check if the password has been previously exposed with haveibeenpwned. That would solve some of the issues, no? You'll have some pissed off admins but I think it would a lesser sin than what we have had this weekend. Now, some things might slip through the cracks; for example, if an admin changes password form "monkey1" to "monkey2" (or any common word), perhaps it does not guard against certain kinds of dictionary attacks, but at as long as the password is unique and the WMF maintains proper password hygiene from their end, perhaps it's not as a dire as it may seem at first? Maxim_(talk) 13:27, 5 May 2019 (UTC)

  Thank you. It's better not to require any minimum length. That's already taken care of by restricting exposed passwords. Any common password or short password is already on the list of 500 million. Jehochman ^Talk 11:21, 6 May 2019 (UTC)

  That phabricator request is hopelessly tangled. There are fewer than 2000 admin accounts. They should write a loop that tests each account using the k-anonymity interface provided by HIBP. Here is a list of code they could reuse: https://haveibeenpwned.com/API/Consumers. Jehochman ^Talk 11:35, 6 May 2019 (UTC)

That's effectively what I proposed back in (was it November?) when the current wave of compromises began (here-ish). Without giving away too much about the noise that was generated on the functionaries list, I was basically told to shut up. Ivanvector (^Talk/_Edits) 13:41, 5 May 2019 (UTC)

You can replace or move your authenticator provided that you have your secret key or your scratch codes. . Obviously these should be somewhere secure, although the random burglar is hardly going to know what they are. You can have more than one authenticator. Doug Weller talk 16:16, 5 May 2019 (UTC)

I still think trying tricks with authenticators can confuse some technically less savvy people. I have assisted with Wikipedia tutorials and encountered people who had trouble identifying Wikicode. WhisperToMe (talk) 16:39, 5 May 2019 (UTC)

@WhisperToMe: are you replying to me? Because there's no trick to having two authenticators. An authenticator is easy to use, and I'm sure all active Admins can identify Wikicode. I'm no whiz and avoid certain bits, but authenticators are just simple apps. Doug Weller talk 17:32, 5 May 2019 (UTC)

Yes, my message was a reply to that comment. Earlier admins like my generation (2003) should all know how to identify Wikicode but I'm not aware of the proficiency of more recent admins (after the time Visual Editor became more popular). Anyhow, I still think there is a tendency of those using technology to assume that the public in general (remember in theory any average Joe is supposed to have a good chance at adminship so long as he/she is in good standing at Wikipedia) is more proficient and/or careful with technology than they really are. Smartphones can be easier to use than desktops, but things like theft and damage still happen, and people make mistakes :( WhisperToMe (talk) 18:25, 5 May 2019 (UTC)

Oh, I don't think we're that incompetent (or maybe we are, but I don't think we're guilty of the particular incompetence described here :) Unique passwords and 2FA are security approaches that will mitigate the specific problem most likely responsible for recent compromises. Other risks, like phishing, are certainly worth being aware of - especially because _targeted attacks are more likely to involve people familiar with the community, who might do something worse than put dumb stuff on the main page for a few seconds - but those risks at least aren't known to be sources of current problems.

For anyone who only really reads ACN when they see there's drama llamas out, the important part here is: make sure the password for your Wikipedia account is unique. Really unique, not "I used password123Wikipedia and that's different from password123MinecraftForumThatDefinitelyDidntGetLeaked". There's a lot of hubbub about 2FA and yes, it's true that MediaWiki's implementation isn't great and there are circumstances in which it's not usable, but it's not true that it requires any different or better internet access than normal Wikipedia usage does. If you are primarily editing from your own personal devices, and you have good enough internet to download a TOTP app on your computer or smartphone, you can probably use 2FA without incident. (As for the drama llamas, as usual the problem is "somebody wrote a confusingly worded post", not "arbcom is full of evil bees").

On the password audit idea, that would be useful, but I/we don't have the impression there's bandwidth available for that. Opabinia regalis (talk) 08:11, 6 May 2019 (UTC)

One of the challenges of not being competent is that you don't know what you don't know. I'm sure we have the bandwidth to complete steps that will prevent a majority of the admin account takeover incidents. Whatever other thing the developers are doing can be set aside briefly to accomplish this. Second, I recommend that administrators not use the beta test 2FA implementation unless they don't mind losing their entire account history. Third, administrators should be given advice on how to avoid phishing attacks; at least they should learn what a phishing attack is by reading our article and be encouraged to report any attempts to harvest their credentials. Jehochman ^Talk 11:21, 6 May 2019 (UTC)

@Jehochman: has anyone actually ever lost their account history? I thought that the few problems that have occurred were fixed, although that takes effort and wouldn't scale up well if a very large number of people adopted 2fa and had problems. Doug Weller talk 14:17, 6 May 2019 (UTC)

I think so. When I had to recover my account it was very inconvenient and the developers only helped me because I had such a long history and knew how to work the system. An ordinary user would probably just get frustrated and give up. Systems should be built considering the impact on everyone not just the elite users. Jehochman ^Talk 21:23, 6 May 2019 (UTC)

What seems to be going on here is a major case of "Perfect is the enemy of good". Is 2FA perfect? No. Is what we've got implemented now the best current practice? No. Is the current implementation unusable by every admin on enwiki? No. Are there attacks which can result in an account being compromised even though 2FA is being used? Yes. But, for most admins, 2FA is usable today and significantly decreases the risk of your account being compromised. From what I can see, it would have prevented every one of the recent bunch of admin account compromises. It's just plain dumb not to be using it if you can. And, yes, WMF should be devoting resources to improving the system, but until that happens, admins shouldn't just be wringing their hands and doing nothing. -- RoySmith (talk) 16:53, 6 May 2019 (UTC)

Aside from the merits of 2FA, is there community consensus that there's even a real problem that needs solving? We have over 1,000 administrator accounts. How many have been compromised in the past year? Is it less than one percent? Is that too many, such that Something Needs To Be Done? And who decides whether or not Something Needs To Be Done? The recent 2FA RFC answered these questions, didn't it? I thought this comment by a steward pointing out that compromised accounts don't need to have rights removed at all was quite persuasive. Is there consensus that compromised admin accounts should be de-sysoped at all (as opposed to just locked until they can be restored to their owner)? And who decides that? Leviv ich 19:06, 6 May 2019 (UTC)

I, for one, don't get the logic behind the emergency level 1 de-sysops passed in these circumstances. A compromised account is locked, which prevents any login and so, it does not matter an iota, if some advanced rights are attached or not. And, AFAIH, it's near-entirely WMF T&S that plays the role in unlocking the accounts, after confirming that the account is in hands of the real owner.

Once, the owner gets back control, you can open a private case, as to ascertaining whether he breached the policy about securing his account by rational means. If you decide that he was careless and did not abide by it, de-sysop for cause. Otherwise, it stays. Most importantly, the admin right stays with him/her for the length of the proceedings, unless you reach an agreement and it's precisely what happens with nearly all other cases of admin conduct, brought before you. ∯WBG^converse 19:22, 6 May 2019 (UTC)

I have no problem with the emergency desysoping. When faced with a security breach, the first step is to contain the damage, and err on the side of caution. Uou're working in an environment of incomplete information. Once you're sure you understand what happened and have things under control, then you can start to put stuff back together again. The primary goal is to prevent further damage to the production system. Minimizing inconvenience for a single user isn't even on the radar. -- RoySmith (talk) 00:33, 7 May 2019 (UTC)

• @Joe Roe: - this seems a calmer thread, so I'll use this. You noted ARBCOM have little push with WMF, others disagreed, specifically citing your regular communication with Trust & Safety. There are some good lists of issues in the discussions above, that I'm sure can be sorted in some fashion (either a couple of experts or an RfC at VPT) into "Must have, Should have, Could have". Raise the fact that the biggest community (somewhat key to an extended 2-factor extended rollout) had major concerns, here was a helpful list - what could they say about them either then or in a month? You may or may not get anywhere, but the WMF has had major issues picking out community concerns before - if nothing else, it would make them clear. If ARBCOM wants to encourage 2-factor, then it would be logical for them to help settle some of the concerns, so far as is practical. TL;DR: Don't tell, don't get Nosebagbear (talk) 13:55, 7 May 2019 (UTC)

@Nosebagbear: We have a monthly meeting with the WMF Trust & Safety team; I'll make sure this is on the agenda for the next one. – Joe (talk) 14:28, 7 May 2019 (UTC)

@Joe Roe: - cheers, greatly appreciated. Both that and your other participation in the threads above, without your involvement I suspect the irritation and anger would escalated even further. Nosebagbear (talk) 14:31, 7 May 2019 (UTC)

As a side note, Nosebagbear, this is something I've raised as an individual with T+S in the past, including in-person at a conference. My understanding is that some fixes to address at least some of these issues (but not all) are actively being worked on. I would definitely not say ArbCom as a whole or as individuals have wiped out hands of these legitimate issues. I think several of us share the desire to see a better 2FA extension and have advocated for that when we could. ~ Rob₁₃^Talk 20:21, 7 May 2019 (UTC)

Wikipedia:Arbitration/Requests/Case/Enigmaman closed

Original announcement

• Thank you for your quick action on this, I felt that this was an open-and-shut case and it seems you all agreed. Beeblebrox (talk) 17:29, 6 May 2019 (UTC)
• I concur with Beeblebrox, it did seem a straight-forward case but it still needed to be handled, and it has been. I read the PD page yesterday and I was impressed with the comments in the Proposed remedies section particularly, the Arbitrators have clearly considered not only the evidence but the editor behind the account name. They commented to recognise the contributions that Enigmaman has made, explained how they interpreted the evidence as examples of mistakes rather than malice, and also how and why they concluded that alternative actions to desysopping were not appropriate. I hope that arbitrators can move on to having ArbCom as a body express similar comments in future cases, as these useful observations and explanations are not evident in the final decision itself. In any case, as one of those who is criticising arbitrators and ArbCom above, I wanted to express my view that this is an example of the Committee and its members carrying out their responsibilities diligently, respectfully, and compassionately – and I encourage all those who haven't looked at that section to read it and see if you agree with me that ArbCom and its members deserve thanks for their handling of that decision. Thank you not only for handling the case, but for doing it well. EdChem (talk) 00:34, 7 May 2019 (UTC)
  • ^ Couldn't agree more. —pythoncoder (talk | contribs) 00:54, 7 May 2019 (UTC)

  (+1). ∯WBG^converse 04:56, 7 May 2019 (UTC)

• Thanks to Oshwah and Beeblebrox for stepping up to see this through and to the committee for their careful consideration of the evidence, particularly the mass of diffs I submitted. Well handled. ~Swarm~ ^{sting} 23:31, 13 May 2019 (UTC)

Return of permissions to administrators notice

I see that this notice to administrators came out so delayed that the arbitration committee notice has already been archived on this noticeboard.

Was this notice (see User talk:Liz#ArbCom 2019 special circular) really necessary? Who came up with this wording? It is one thing to ask administrators or functionaries to be careful with their login and passwords but threatening them with having to have an additional RfA if they don't go for certain types of internet security? That seems like a step too far. There's encouraging change and then there is leveling threats and in this message ArbCom's frustration clearly came through. Liz ^{Read! Talk!} 02:50, 4 May 2019 (UTC)

How does the Committee intend to learn "whether the administrator used a strong password on both their Wikipedia account and associated email account"? The passwords are stored hashed and salted. Not even the sysops and developers can recover their plaintext, supposedly. Also, "whether the administrator had reused passwords across Wikipedia or the associated email account and other systems," seems similarly unknowable with any certainty. EllenCT (talk) 03:45, 4 May 2019 (UTC)

• Repeating something that I posted on my own talk page in response to this mass message:

When it comes to 2FA, people need to understand what Mediawiki is offering. Right now, it's not anywhere near state-of-the-art; it was written by a former WMF employee and is now maintained by a mix of staff and volunteers, none of whom are responsible for the long-range development of the extension. The WMF is already taking steps to make it *required* usage without taking any responsibility for it. That's well below the standard any of us should expect for security software. In order for it to be a proper fit for the worldwide, diverse movement it is intended to support, the following steps can and should be taken:

1. A WMF department needs to take ownership of the extension, and take responsibility for its ongoing development, improvement, maintenance and user support.
2. It needs to be modified so that it stands alone, without any upload of software or use of specific hardware. That is, it shouldn't be dependent on using the right computer or having two pieces of electronics such as a computer and a smartphone.
3. The WMF needs to commit resources to ensuring that there is 24/7, easily reached user support. Right now, there is no clear pathway to obtaining support. This becomes increasingly important as more and more users with limited technical proficiency and/or who don't have a personal point of contact high up in the WMF technical support system are pushed to use 2FA. It should be assigned to people who can see a user through the entire process, all the way from communicating with users to resetting passwords/2FA.
4. Generation of scratch codes needs to be easy and able to be done without disabling 2FA, as is necessary with the current software. After all, if 2FA is mandatory, the user can't disable it in order to generate new scratch codes.
5. It needs to work in a simple and streamlined way for users who do most of their work from phones.
6. It needs to be a no-cost solution. Any user should be able to use it anywhere in the world without worrying about hardware costs, software costs, or data/texting/SMS costs. They need to be able to use it on any computer at any time, anywhere, provided they have an internet connection. It needs to not be dependent in any way on mobile phone networks.

These things are all possible. They are, however, entirely dependent on the WMF taking the bull by the horns and redesigning the 2FA system so that it is streamlined, cost-free, easy to use and well-supported. When the WMF has over 100 software developers on staff, and their own Security department is urging the use of 2FA, there's really no excuse not to do this.

And frankly...I don't really see much point in requiring admins to have 2FA when we don't even require them to have a durable email address attached to their account.

If Arbcom is serious about this, then they need to use their influence to get the WMF to do the right thing. This message makes it sound as though Arbcom is requiring that all admins take potentially quite costly steps in order to hold onto their bits. Risker (talk) 03:49, 4 May 2019 (UTC)

• Comment: Previously the mantra was that being an admin was not a big deal and that it was nothing special to be one, but the increasing difficulty of going through RFA and now the suggestion of two-factor authentication are increasingly differentiating being an admin. On top of that some people live in countries where access to Wikimedia projects is already shaky: Turkey and China have had issues with internet blocks. If someone blocks the authentication app on a smartphone, how will a user who doesn't have a VPN on the smartphone authenticate into an admin account? WhisperToMe (talk) 05:29, 4 May 2019 (UTC)

  TOTP (the algorithm which generates the code) does not require a connection. Assuming you can get hold of an app (which is likely) the only other Internet access which may be required is something to make sure your clock is reasonably accurate (which is also likely). Internet access is not required to generate the 2FA code being entered. -- zzuuzz ^(talk) 05:54, 4 May 2019 (UTC)

  Come on, zzuuzz. One needs to be able to upload software onto some piece of electronic equipment in order to use the "app", which fails #2 above. After all, we already have admins logging in from military bases, libraries, and employer-owned equipment, most of which restrict uploading of software. And you need internet access to log into your account; whether or not 2FA also needs internet connection is immaterial, and many 2FA generators require either internet connection or send an SMS. Risker (talk) 06:39, 4 May 2019 (UTC)

  Any respectable TOTP generator is not going to use SMS or the Internet. My main point, in reply to the main point, is that the Great Firewall makes no difference to 2FA. I'm more than happy to agree that 2FA is not for everyone. -- zzuuzz ^(talk) 06:49, 4 May 2019 (UTC)

  In which case, why do I have a large spam message purporting to be from Arbcom claiming that Administrators must … Enable two-factor authentication now for improved security on my talk page? ‑ Iridescent 07:03, 4 May 2019 (UTC)

  I'll leave that for others, as I don't speak for them, nor them for me. I believe someone has already pointed out that the wording may not be ideal. -- zzuuzz ^(talk) 07:06, 4 May 2019 (UTC)

  It isn't fake news; the message was from ArbCom. Well, the message was sent because while you or I may have secured our accounts, a number of sysops haven't. They reuse passwords from other sites, their passwords are insecure, or they attach the account to email addresses with the same issues. This advice was always obvious to some, but the message is not reaching everyone at an equal rate. Obviously, the message is an attempt to say, in simple words and without legalese, what these sysops need to learn in order for the community to stop wasting time dealing with breached user account security. I think it's overdue. AGK ■ 07:12, 4 May 2019 (UTC)

  And how did Arbcom give themselves the authority to demand this, given that every time mandatory 2FA has ever been discussed (the most recent RFC was only two weeks ago) it's been resoundingly rejected? ‑ Iridescent 07:16, 4 May 2019 (UTC)

  What do you think ArbCom has demanded? You can't mean it demanded sysops enable 2FA, because the motion says no such thing. And while the message advises that as one method of securing an account, it does not make that a requirement in itself. AGK ■ 07:31, 4 May 2019 (UTC)

  AGK, Administrators must … Enable two-factor authentication now for improved security (my emphasis) is a direct quote from the mass message you've just sent out. ‑ Iridescent 07:33, 4 May 2019 (UTC)

  The mass message does say "Enable Two-factor authentication (2FA), if you can, to create a second hurdle for attackers.", if it's not clear in the bullet points that 2FA is not being imposed as a requirement. GorillaWarfare (talk) 07:45, 4 May 2019 (UTC)

  Certainly not the one I received; the text in full is Administrators must secure their accounts The Arbitration Committee may require a new RfA if your account is compromised. Use strong, unique passwords for your Wikipedia account and associated email. Change your password now if your Wikipedia account password or email password is reused on another website, exposed, or weak. Enable two-factor authentication now for improved security. ‑ Iridescent 07:48, 4 May 2019 (UTC)

  It's collapsed under the "View additional information" button in yours and all the other messages. GorillaWarfare (talk) 07:49, 4 May 2019 (UTC)

  Who worded and designed this banner, FWIW? ∯WBG^converse 07:36, 4 May 2019 (UTC)

  It’s very poorly worded. The use of the word “must” gives the impression that admins must follow the three bullet points, but that’s clearly not true as 2FA is not mandatory. Pawnkingthree (talk) 07:52, 4 May 2019 (UTC)

  And, the design is horrible. It's pathetic that 13 folks can't write a decent notice. ∯WBG^converse 07:54, 4 May 2019 (UTC)

  Its 'design' seems to be the same as every other notice on Wikipedia. AGK ■ 07:57, 4 May 2019 (UTC)

  Example, please. ∯WBG^converse 08:08, 4 May 2019 (UTC)

  13 folks can't write a notice? Seems usual, see, 'design by committee'. Alanscottwalker (talk) 17:29, 4 May 2019 (UTC)

  Alanscottwalker, if you wish to say that the current committee has no unifying vision cum technical knowledge, I certainly agree. ∯WBG^converse 17:43, 4 May 2019 (UTC)

Fuck ArbCom which doesn't even understand their own messages and again give themselves powers they don't have. First it was deletions, then it was mandatory 2FA, inbetween it is loads of evidence of utter incompetence in many of its members (witness the statement by AGK above, but also some of the comments at e.g. the Rama case request). Just crawl into a corner and shut up until the community asks you to do something within your remit, but don't try to rule enwiki as if you have the right and the competence to do so. Or collectively resign. But don't give us any more of this bullshit. Fram (talk) 07:39, 4 May 2019 (UTC)

Isn't the role of ArbCom intended to be to arbitrate? What is being arbitrated in this diktat? I know the definition drifts a bit but this seems like a lot, not a bit. - Sitush (talk) 07:46, 4 May 2019 (UTC)

The role of ArbCom includes handling desysoppings, for better or for worse. GorillaWarfare (talk) 07:51, 4 May 2019 (UTC)

"Handling" desysoppings, not inventing new rules around it. But inventing new rules seems to be something the current Arbcom is fond of. Fram (talk) 08:10, 4 May 2019 (UTC)

By that logic I would think you would be opposed to the ArbCom having been reinstating tools without requiring a new RfA. GorillaWarfare (talk) 15:47, 4 May 2019 (UTC)

This is a good notice. Given the number of admins who've been hacked recently, it's sensible for ArbCom to tighten up the rules around when they will re-issue the tools, and it's obviously necessary to advise admins of this. Nick-D (talk) 08:12, 4 May 2019 (UTC)

I believe it's the bureaucrats who have that authority, right? Did Arbcom talk with them first? WhisperToMe (talk) 09:04, 4 May 2019 (UTC)

Scope and responsibilities

The Arbitration Committee of the English Wikipedia has the following duties and responsibilities:

   To act as a final binding decision-maker primarily for serious conduct disputes the community has been unable to resolve;
   To hear appeals from blocked, banned, or otherwise restricted users;[note 1]
   To handle requests (other than self-requests) for removal of administrative tools;[note 2]
   To resolve matters unsuitable for public discussion for privacy, legal, or similar reasons;
   To approve and remove access to (i) CheckUser and Oversight tools and (ii) mailing lists maintained by the Arbitration Committee.

This set of requirements (just like the AE deletions saga) is not within the policy defined scope of what ArbCom is for. Fram (talk) 08:25, 4 May 2019 (UTC)

Fram have you read the above? No rules are being invented. 2FA is still optional-but-encouraged. We are simply reminding admins of expectations that have existed for years at WP:SECUREADMIN and WP:STRONGPASS. The fact that they are apparently news to some just shows the need for the circular. – Joe (talk) 08:33, 4 May 2019 (UTC)

Joe Roe, wrong. Apart from the "optional" thing you MUST do, there is also "The Arbitration Committee may require a new RfA if your account is compromised.", which is not within their remit at all. You are usurping policy powers from the bureaucrats: " Discretion on resysopping temporarily desysopped administrators is left to bureaucrats, who will consider whether the rightful owner has been correctly identified, and their view on the incident and the management and security (including likely future security) of the account. " (from Wikipedia:Administrators, which is linked to from the top of your arbcom message). The ArbCom doesn't have the authority to mandate a new RfA for compromised accounts at all unless they go through the proper channels to change policy and take this responsability away from the bureaucrats. Fram (talk) 08:39, 4 May 2019 (UTC)

@Fram: This was discussed extensively in response to Necrothesp's compromise. We found the written policy to be inconsistent. But if ArbCom is allowed to desysop, it's incoherent to say that we don't also have discretion to decide if we want to resysop. If we aren't prepared to give the tools back to someone, then as a matter of course they would have to ask the community at RfA. Or yeah, I suppose they could try to convince a bureaucrat to sysop them without instruction from either ArbCom or the community. I doubt it would work though. – Joe (talk) 08:59, 4 May 2019 (UTC)

"But if ArbCom is allowed to desysop, it's incoherent to say that we don't also have discretion to decide if we want to resysop." Joe Roe; ARBCOM HAS NO AUTHORITY TO DECIDE ON RESYSOPS at all. Just like Bureaucrats have no authority to decide on desysops. These things have been explicitly and deliberately separated since, well, ever? "If we aren't prepared to give the tools back to someone, then as a matter of course they would have to ask the community at RfA. " It doesn't matter one bit if you are "prepared" to give the tools back, you don't have the authority, the policy backing, to decide on this. That you find the policy to be inconsistent may be yrue, and the way to change this is to get an RfC so THE COMMUNITY can decide to change the policy. But you have just rather explicitly acknowledged that ArbCom has, on its own, decide to set policy, which it is not allowed to do. Fram (talk) 09:07, 4 May 2019 (UTC)

I think you need to tell the crats that, because we pass resysop motions on a semi-regular basis with no complaint. I'm also curious how you see ArbCom's responsibility for admin oversight functioning at all with this distinction. If we desysop someone in a case, can they just go to the crats and ask for it back? – Joe (talk) 09:17, 4 May 2019 (UTC)

For conduct reasons yes, for technical reasons no. If you pass "resysop motions" after a compromised account desysop, then the crats should ignore these. And ArbCom's role is "de"sysoping, the crats role is "re"sysoping, it can't get much clearer than this. In a case, you have the authority to impose sanctions. In a compromised account situation, you don't. And you certainly don't have the authority to decide on "inconsistent" or ambiguous policy by simply deciding by fiat that it is your responsability, not theirs. For that, you need to start an RfC, preferably at the VPP. Just like you should have done for ArbCom / AE deletions which can't be overruled at DRV. Fram (talk) 09:52, 4 May 2019 (UTC)

I still don't see how we're creating policy. We modified our procedures, based on what has been the accepted process (policy describes consensus not vice versa etc.): ArbCom is asked to authorise desysops of compromised accounts, and then we pass a motion when we're satisfied the situation is over. As far as I know neither the crats nor anyone else has ever objected to this. Do you have a substantial objection to it, beyond it maybe not being within the wikiletter of the wikilaw? It sounds like you would be happy if we opened a case to decide whether or not to return tools (which is actually an outcome mentioned in our procedures)? Would that achieve anything other than introducing time-wasting bureaucracy for the same outcome? – Joe (talk) 11:02, 4 May 2019 (UTC)

The planets must be aligned or something, but... I agree with Fram. Whether it's a good idea or not, this is basically just writing policy by fiat, not that that's anything new. GMG^talk 13:35, 4 May 2019 (UTC)

ARBPOL allows us to "act as a final binding decision-maker primarily for serious conduct disputes" and to "handle requests ... for removal of administrative tools". This falls under both of them, since WP:ADMIN, a policy, requires admins engage in good account security practices. If admins fail to do so, this is a serious conduct issue, and it speaks to removal of administrative tools. In my view, ArbCom is finally enforcing existing policy rather than blatantly ignoring it to protect admins who fail to practice appropriate account security. ~ Rob₁₃^Talk 14:54, 4 May 2019 (UTC)

You have the authority to decide when permissions are removed. You don't have, and never have had, the authority to decide when permissions are restored, and the number of arbs lining up in this thread to claim that they do—despite being unable to point at where they were ever given this authority—is a sign of a serious collective competence issue. We have powers separated between the committee and the bureaucrats for a reason. ‑ Iridescent 15:02, 4 May 2019 (UTC)

Don't be coy Iri. ArbCom has, and always has had as far as I am aware, the ability to interpret the boundaries of its own remit, and to claim an exemption from community oversight in doing so. There is a reason most modern democracies have some variance of separate co-equal powers, so that the body exercising authority is not the same body determining the extent of that authority. Here, on one of the most visited websites in the history of the world, and one of the broadest collaborative projects in human history, we have a single body tasked with doing both. This is why they routinely make policy by fiat while claiming not to do so, and at the same time claiming that their decisions are above community review. GMG^talk 18:10, 4 May 2019 (UTC)

@Nick-D: Yeah, but that doesn't make it a well-worded notice. The message on my page for sure contains a direct order: "Enable two-factor authentification now for improved security." User:GorillaWarfare, your response to complaints about this is that the reader is supposed to click through to additional information "if it's not clear in the bullet points that 2FA is not being imposed as a requirement". There's no if about it. Clear? Clear? No, it's clear in the bullet points that 2FA is being imposed as a requirement. Why don't you guys simply admit that the main message on my page, the one that I get without clicking through to something additional (and that made me choke on my breakfast), is wrong? Instead of suggesting that it's the admins that can't read? Bishonen | talk 08:31, 4 May 2019 (UTC).

I agree. The wording is poor. We went through several iterations and I think what we were trying to say got lost in the effort to make it as concise as possible. I'll talk to the rest of the committee about sending round a correction: is there anything else that's unclear, apart from the 2FA bullet? – Joe (talk) 08:36, 4 May 2019 (UTC)

Thanks, Joe. No, the rest seems fine. Of course I went on to check the additional info + the motion itself, and was reassured, but for a moment there I had time to think "OK, if they require that 2FA now, I'll just hand in my tools." IMO 2FA is more likely to shut out me, a technically ignorant admin, than to protect me from any would-be encroacher. (I have a very strong password, never used elsewhere.) Technically skilled admins with 2FA have been known to be locked out from their accounts when they got a new mobile phone or whatever it was. (Paging User:Jehochman.) @Fram: I think you need to stop with the personal stuff. Bishonen | talk 10:48, 4 May 2019 (UTC).

What personal stuff? That Arbcom has once again bungled things? That once again they have to correct things and retract their statements? That AGK has written most of the text, and that it isn't the first time his writing and approach has caused problems and embarassment? That arbcom likes to set policy to their hand? Anything else? If arbs can't handle such criticism, then they should stop making a mess of things. Fram (talk) 11:37, 4 May 2019 (UTC)

I agree that recipients of the message should not have to click through to understand that 2FA remains optional. I said "if" because to me it did not read as a mandate (as is probably clear by the fact that I didn't ask for it to be reworded), but I do understand that it can and has been read that way. We could potentially do another AWB pass at the mass-message to clarify the above-the-fold wording. GorillaWarfare (talk) 16:00, 4 May 2019 (UTC)

Oops, just read Joe's message above more closely and see that he's suggested the same. GorillaWarfare (talk) 16:03, 4 May 2019 (UTC)

Ah, AGK wrote >90% of the notice I see. Cheers, ——SerialNumber54129 08:39, 4 May 2019 (UTC)

Why does the ArbCom still let AGK write anything? It has caused enough problems in the past that they should have learned their lesson by now... Fram (talk) 09:52, 4 May 2019 (UTC)

You are making a personal attack and engaging in the sort of conduct for which you have been warned many times before. Stop it. AGK ■ 10:01, 4 May 2019 (UTC)

That's a chilling threat to deflect legitimate criticism of your shoddy writing skills. ∯WBG^converse 10:03, 4 May 2019 (UTC)

The notice was written on a public wiki page by several editors. Fram is overlooking that fact in order to take unwarranted shots at an editor who is on Fram's "blacklist". It's something Fram does with shocking regularity and we need to increase how frequently and quickly we call it out. AGK ■ 10:08, 4 May 2019 (UTC)

Then you could e.g. have pointed out that you had not written most of it? And if you had actually read my message (no need even to open any "additional information to rectify the errors in it), you would have seen that I criticize ArbCom for letting you write it, instead of taking it into their own hands and improve things. It's a collective responsability, yours for producing such shoddy writing once again, theirs for letting it be published as is. But feel free to try to silence me, not much will surpsirse me from this arbcom anymore. Fram (talk) 10:13, 4 May 2019 (UTC)

Looking at that "public wiki page", it seems only one non-arb found this unannounced template page at first sight (and that editor is actually topic banned from policy and guideline discussions...), and the talk page makes it clear that the actual text was decided through off-wiki discussion. The criticism remains: the text is seriously deficient, you wrote most of it, and the other arbs were happy with it and agreed to send it out. It's their responsability to let an arb who has caused problems in the past with shoddy writing in arb-related matters again write their texts. I see you are also one of the two drafting arbs on the Rama case. Fram (talk) 10:27, 4 May 2019 (UTC)

Actually Fram I found it and brought it to attention at Signpost's newsroom on April 17, prior to the April 30 issue. Unfortunately, it didn't really get traction. Bri.public (talk) 23:04, 6 May 2019 (UTC)

Thanks, I hadn't seen that. Fram (talk) 04:25, 7 May 2019 (UTC)

(ec)Yeah, an Arb who doesn't know the difference between a personal attack and criticism of their edits is ... well, not surprising, but still disapppointing. Fram (talk) 10:13, 4 May 2019 (UTC)

• Also, there are 1177 sysops but Z152 is transcluded upon 1143 pages. That's a deficit of 34. Any explanations or am I counting wrong? ∯WBG^converse 10:15, 4 May 2019 (UTC)

  Most adminbots were not sent the notice. Some admins are opted out of MassMessage[5], and others have removed the notice. Those opted out should probably get the notice hand delivered. — JJMC89 (T·C) 10:31, 4 May 2019 (UTC)

  Thanks, 9 admin bots + 11 opt-outs leaves us with 14, who have removed the notice :-) ∯WBG^converse 11:16, 4 May 2019 (UTC)

A couple of weeks ago, I had a premonition that something like this was likely to happen, so I wrote a short essay on why the current 2FA is a poorer solution than having a decent password at User:RexxS/2FA. Nobody ought to be forcing 2FA on anybody until the system for recovery is properly thought out and documented in a way that allows anyone to use it confidently. --RexxS (talk) 10:45, 4 May 2019 (UTC)

It's sounding increasingly like the committee is encouraging less than best practice. True? ——SerialNumber54129 10:51, 4 May 2019 (UTC)

RexxS' essay appears to be about how he believes 2FA in the absence of a good password may cause problems, as well as how a truly good password is truly good. Having both is indeed best practice, individual complications aside. ~ Amory (u • t • c) 11:01, 4 May 2019 (UTC)

• The wording may have been imperfect, but the decision is sound. Risker, as always, makes good points, but at the end of the day 2FA is hopefully not too much of a burden for most sysops and is still not required. ArbCom said it would determine whether the administrator followed "appropriate personal security practices". If 2FA isn't appropriate for you, so be it, but they didn't say if you're hacked and don't have 2FA, you're gone. And imperfect though it may be, sysops should not be scared to re-run RfA. ~ Amory (u • t • c) 11:01, 4 May 2019 (UTC)
• It's certainly the case that Risker and Rexxs make wholly convincing arguments, I agree. ——SerialNumber54129 11:10, 4 May 2019 (UTC)

"The Arbitration Committee may require a new RfA if your account is compromised" is not, as some have implied, a threat to Admins. to change their authentication method or else. But things have changed in 15 years and old-style Admins. in particular, using 123456 as their generic password for everything, need to get up to date with modern-day threats and vulnerabilities. That said, if the WMF 2FA is crap then I can well see the issue with using it. Leaky caldron (talk) 12:04, 4 May 2019 (UTC)

That may well be the case, but that's a spectacular bit of selective quotation, given that you've left out Administrators must enable two-factor authentication now which is the actual part that's causing concerns. Nobody has an issue with "don't use 'password' as your password" or "don't use the same password on Wikipedia that you use on Encyclopedia Dramatica". ‑ Iridescent 13:00, 4 May 2019 (UTC)

• My home has state-of-the-art dead bolts on every door. I have a state-of-the-art burglar system. I have an electric fence that surrounds my property. I have individual guards who patrol the perimeter with specially-trained guard dogs. A friend suggested I change all the outside doors on my home to be solid steel. I asked why? They said it would be "best practice".--Bbb23 (talk) 13:25, 4 May 2019 (UTC)

@Bbb23: Your house being, of course, Fort Knox  :) ——SerialNumber54129 14:01, 4 May 2019 (UTC)

• Arbs, my first reaction to reading the message was “Wow, that reads like mandatory 2FA and there are going to be a lot of confused people.” The only reason I didn’t think that is because I follow ArbCom close enough that I knew which motion it was talking about and knew that wasn’t actually the case. I’m not up in arms, but my point being: the reason everyone is mad is because the way you worded it gave the very strong impression it was mandatory. TonyBallioni (talk) 13:28, 4 May 2019 (UTC)

• It was poorly worded for sure. However, I didn't read it to mean we must use 2FA, but I did read it to be a threat as to what would happen if we didn't use 2FA and our account was compromised.--Bbb23 (talk) 13:32, 4 May 2019 (UTC)

• I think that your reading was the intent behind it, but I also think Enable two-factor authentication now for improved security could easily be read as an imperative. TonyBallioni (talk) 13:37, 4 May 2019 (UTC)

• It absolutely is a notice of what will happen if an admin does not enable 2FA, uses a weak password, and their account is compromised. I certainly apologize if the message came across as a requirement. Admins are not required to have 2FA enabled, to be clear. But if an admin fails to practice basic account security measures, keep 2FA disabled, and then their account is compromised, that's a serious conduct issue that will warrant a new RfA. ~ Rob₁₃^Talk 14:48, 4 May 2019 (UTC)

• Yes, I’m not a part of the pitchforks here, I’m just saying that as someone who typically cuts the committee a lot of slack because of how thankless the job is, I get why people read it this way. TonyBallioni (talk) 15:10, 4 May 2019 (UTC)

• Once somebody comes out with another whizz-bang security feature, it's tempting to say "you should/must/ought to use that feature", but using 2FA to improve security on Wikipedia comes with a price to the user. Take a look at Help:Two-factor authentication. You'll probably be able to follow the instructions to enrol in 2FA, but it gets a little murkier when you consider what you need to do to recover your account if you no longer have your phone (or other authenticator). What you need is set of scratch codes that you're asked to write down, because if you lose your phone these tokens are the only way to rescue your account. So the security of the 2FA part of your login is now reduced to how secure you can keep a piece of paper with some writing on it (while having it always accessible to yourself). There is also automatically a tension between keeping more than one copy in case you lose one of them, and the increased risk of exposure by keeping multiple copies. Students at university, shared dorms, working away from home, etc. all raise immediate issues about using physical security. Why do we tell everybody never to write down their password, and then instruct them to do the analogous action with their 2FA scratch tokens? --RexxS (talk) 13:50, 4 May 2019 (UTC)
  • Without 2FA, you only need your password to access your account, so writing it down means a physical security compromise would compromise your account. With 2FA, you need both your password and the 2FA code to access your account, so a physical security compromise would not compromise your account. Further, the WMF does have ways to get you back into your account if you lose access, theoretically, even if you do not have a scratch code. It isn't very scalable at the moment, which is why 2FA is limited to admins, to prevent scaling problems. The WMF is actively working on better solutions so that 2FA can scale more easily. ~ Rob₁₃^Talk 14:48, 4 May 2019 (UTC)
    • The danger of that, of course, is thinking that having 2FA allows you get away with a poor password. It doesn't. And thinking that "a physical security compromise would not compromise your account" is precisely as erroneous as the weakness of your password. Cracking time is now potentially 2 minutes for a 9-character alphanumeric password. If you have an "uncrackable" password/pass-phrase, then 2FA is irrelevant for security and problematic for recovery. We can revisit this when WMF has finished "working on better solutions". --RexxS (talk) 15:08, 4 May 2019 (UTC)
      • I don't think I have ever said that a password is irrelevant with 2FA enabled. I certainly don't think that. Our notice certainly doesn't say that. It leads with "use a secure password". 2FA is most useful in preventing breaches from keyloggers and phishing attempts, where the security of the password is actually irrelevant to the attack vector. A secure password remains the method to defeat the most common attack vector - attempting to identify administrator accounts with reused passwords known from other data breaches. ~ Rob₁₃^Talk 15:19, 4 May 2019 (UTC)
• It's incredibly rare that Fram and I agree on anything, but I endorse every word that they've written here. This is yet another in a series of totalitarian actions by this Committee imposing their own pseudo-policy that conflicts with the community's policies, doing so without being asked, doing so without consulting with the community at all, and doing so in conflict with the consensus of recent community discussions. The fact that they communicated their directive so poorly as to be misunderstood by so many is just an added bonus at this point, as is the fact that this is also yet another empty statement passing the blame for compromised accounts to individual administrators instead of actually doing anything meaningful about the problem at all. Forcing admins to re-run the gauntlet at RfA because of third-party actions completely outside their control is plainly a threat to administrators, as with the current adversarial nature of RfA and the panic about account security, it's highly unlikely that any administrator desysopped in this way would pass a reconfirmation. It's bewildering to presume that the current members of the Committee, themselves all administrators, would not have known this when drafting this directive.

In response, I am protesting the directive, and this Committee. Until every member of this Committee resigns and/or new elections are held, I decline to use administrative tools in any area of Wikipedia subject to an Arbitration directive of any kind, including discretionary sanctions and arbitration enforcement, and including the use of the checkuser tool. I'll draft a statement to this effect shortly. I'm intending not to comment on any replies to this, but if anyone has input I suggest you email me rather than posting a comment on Wikipedia. Ivanvector (^Talk/_Edits) 14:53, 4 May 2019 (UTC)

Existing community policy requires admins practice good account security. Literally all this notice is saying is that you need to actually follow that community policy or you could be desysopped. You call it a threat. I disagree. It's a notice that ArbCom will finally begin enforcing community policy in this area. If the community wants to change that policy, of course they can, and ArbCom would adjust. In particular, feel free to start an RfC stating that administrators do not need to practice appropriate account security or that, even when administrators re-use passwords across sites, allowing vandalism to land across the Main Page and damaging the credibility of the entire project, we'll welcome them back with zero oversight, zero accountability to the community, and zero questions asked. If such an RfC passes, we would adjust our procedures to follow that new directive from the community. Until then, I'm very satisfied with enforcing the existing community policy, which states that administrators are required to "have strong passwords and follow appropriate personal security practices", that "a compromised admin account will be blocked and its privileges removed on grounds of site security", and that "the revocation of privileges may be permanent". ~ Rob₁₃^Talk 15:04, 4 May 2019 (UTC)

That would be the RFC we literally just had. ‑ Iridescent 15:08, 4 May 2019 (UTC)

I've also only just noticed that when Necrothesp's account was compromised recently, the Committee required them to enable 2FA before restoring their permissions. There is no policy which gives that power to the Committee, and the community has repeatedly rejected mandatory 2FA. Enough is enough. Ivanvector (^Talk/_Edits) 15:27, 4 May 2019 (UTC)

@Ivanvector: We asked if they would be willing. They explicitly responded in the affirmative, at which point we incorporated it into our motion. I will not go into specifics per WP:BEANS, but based on the statements of the WMF and Necrothesp privately to ArbCom, we had very real concerns that the account could be immediately recompromised after resysopping if 2FA was not enabled. If this were not even an option for us, I would have voted against the resysop outright because I wouldn't have considered the account secure. ~ Rob₁₃^Talk 15:30, 4 May 2019 (UTC)

(edit conflict) That RfC asked whether policy should recommend 2FA. It was rejected largely because policies don't do recommendations, they do requirements. We have sent out a reminder that admins need to follow existing community policy that requires they practice good account security. We have provided some specific suggestions that may (or may not) help. We have stated that, in the future, we will make an assessment of whether the admin practiced appropriate account security if their account is compromised, as required by the WP:ADMIN policy if it were to have any effect. If we were not to do such a review, we would be invalidating WP:ADMIN#Security by fiat, since we are the only group that could theoretically ask the question of whether the admin breached that section. I don't think anyone on ArbCom is coming anywhere close to suggesting "enable 2FA or you risk desysop". It's more like "if you don't do anything to secure your account - bad password, re-used password, no 2FA - and then you face the obvious consequence of being compromised, we will consider whether the desysopping should be permanent". ~ Rob₁₃^Talk 15:30, 4 May 2019 (UTC)

• Sorry, but this argument 'Arbcom can remove tools but cannot keep tools removed' is silly. Not only per Consensus policy may Arbcom bind any user, it's a dumb pro forma argument, so Crats restore, Arbcom desysopes for poor judgement, there is nothing in policy that would even suggest that user's with poor judgement can't be desyssoped (this is apart from, the advisory is poorly worded argument, which is easy to correct, just revise the advisory). -- Alanscottwalker (talk) 15:15, 4 May 2019 (UTC)

• I agree with Fram, Iri and several others. I think this motion should be converted to a proposal and submitted to the community for thoughts, further refinement and confirmation via an RfC.
  Now, I have a more serious concern, I know it may well be a case of WP:BEANS but...
  This policy now makes compromising an administrator's account particularly attractive, forcing a desysop and removing someone who may be working in a controversial and troublesome subject area.
  Oh, and we don't actually know how many accounts are actually compromised right now - how many are being used discreetly, looking at deleted content and the like. This motion doesn't begin to address that issue, it only really deals with admin accounts which are compromised and which cause deliberate disruption. I'd say the whole security of accounts needs a serious rethink, and that's firmly WMF territory. Nick (talk) 15:16, 4 May 2019 (UTC)

• In light of a recent comment from an arb elsewhere that I see this notice to be a faithful restatement of WP:ADMIN#Security, which was written by the community., I'll put the actual policy here for the record: Discretion on resysopping temporarily desysopped administrators is left to bureaucrats, who will consider whether the rightful owner has been correctly identified, and their view on the incident and the management and security (including likely future security) of the account. The decision in these circumstances is purely a matter for the 'crats to determine whether or not to restore permissions, and as far as I am aware Arbcom has never had authority either to grant or to re-grant permissions of any kind. ‑ Iridescent 15:26, 4 May 2019 (UTC)
  • So? The advisory does not concern temporary desyssop, which is a pull the switch function in emergency, the advisory concerns the usual order desyysop which Arbcom does. Alanscottwalker (talk) 15:34, 4 May 2019 (UTC)

I'm going to comment in two phases: one with my bureaucrat hat on, and one without. Starting with the part without the bureaucrat hat, I wholly agree with the substance of Fram's comment although I may not have phrased it the same way. Speaking with bureaucrat hat on, the policy as written says that an admin desysoped for compromised account should appeal to the bureaucrats, whereas the arbitration policy (WP:RETURN) would at least imply that granting a resysop is the Committee's prerogative. Now, one may say that usurps the determination of a "cloud" from the bureaucrats. Also to note is that we as bureaucrats don't have access to confidential information like Arbcom or checkusers or oversighters have - unless we have those memberships, all we see is the same as a rank-and-file sysop. Once a user has been allowed access back to his or her account (Trust and Safety and Stewards make that call with respect to password reset and unlocking the global account), in principle, that satisfies that the requirement that the correct individual is again in control of the account. We have not historically treated loss of +sysop due to account comporomise as "under a cloud", so theoretically if you find a willing bureaucrat to resysop, it might stick? Frankly it would depend on Committee composition at the time; the more arbs we have that propose desysops (or in this case, de-crattings) for every time an administrator or bureaucrat happens to be named in a case, the more likely it is that it wouldn't stick. In the past, bureaucrats would not overturn a desysop (distinct from resignation) by request at WP:BN if and only if the desysop was for cause, specifically misconduct as found per motion or full case. In this case, saying that an account compromise is comparable to misconduct that leads to desysop is at odds with community practices, if anything because it is not neccesarily obvious is an admin was clearly negligent. In particular, mandatory 2FA was not something endorsed at a community level. In conclusion, I think arbcom appears to be reinterpreting existing policy and practice in a way where effectively new policy has been created, which is outside their scope. Whether that was intentional or not (wording in the notice aside), the result is what it is. However, while I'm speaking merely as one single bureaucrat, my impression is that the bureaucrat corps is a whole likely too conservative and too drama-shy to attempt resysop a previously compromised account without the consent of the committee. I hope that committee would reverse their position to err on the side of giving a break to long-term productive volunteers on this project, but I am not optimistic that there is much of a chance of it, at least before the next elections. Maxim_(talk) 15:31, 4 May 2019 (UTC)

• Has anyone ever taken the ArbCom...to ArbCom before? There is, as they say, always a first... ——SerialNumber54129 15:33, 4 May 2019 (UTC)
  • You'd have to take them to Jimbo: "I reserve the right of executive clemency and indeed even to dissolve the whole thing if it turns out to be a disaster" —Jimbo Wales, 2004. —pythoncoder (talk | contribs) 19:33, 4 May 2019 (UTC)
    • Jimmy Wales creating a constitutional crisis on Wikipedia and definitively spouting pronouncements on account security (not exactly a great source considering his history) is the absolute last thing we need right now. TonyBallioni (talk) 19:36, 4 May 2019 (UTC)
      • That was intended mainly as a statement about current policy; not by any means an endorsement. (insert comment about whether Jimbo would pass RfA here) —pythoncoder (talk | contribs) 19:43, 4 May 2019 (UTC)
• Largely my thoughts are the same as Liz, Ellen and Risker at the top of the thread. I have actually just updated my password and will update my linked-email password just to be on the safe side, so the message has had some positive effect on me. But I am not going to use 2FA until it's possible to recover lost 2FA details, because at present enabling 2FA creates a risk that I will permanently lose access to my Wikipedia account, which is... not great. Also, I really am scratching my head about what mandate Arbcom has to effectively de-admin people for not using a non-compulsory security tool. The Land (talk) 15:40, 4 May 2019 (UTC)
  • No problem – the English Wikipedia policy requires you merely to secure your account. You decide whether to use 2FA or not. Nobody will be desysopped for not enabling 2FA; ArbCom simply "may require a new RfA if your account is compromised". AGK ■ 16:24, 4 May 2019 (UTC)

(outdent for threading)... So you're saying that it's not compulsory, but if you don't, there are potential consequences for not doing it? This makes no sense to me. It's like saying you don't HAVE to pay your taxes, but if you don't, you just might end up in prison. In fact your message is saying you're expecting all admins to use 2FA, but have no ability or intention to enforce that unless their account is compromised. What I'm saying is a) I think this step should only be taken if it reflects the overall policy on 2FA, rather than Arbcom deciding the policy doesn't go far enough and extending it unilaterally; and b) I don't think it's a good idea, at least not with the 2FA tool as it is at present. The Land (talk) 17:48, 4 May 2019 (UTC)

What you can't seem to get through your ignorant skull here is that "require a new RfA if your account is compromised" is a trial by ordeal. Nobody who is subjected to a reconfirmation RfA after being desysopped for cause in this way is ever going to get the bit back. It makes us all _targets, especially anyone who's ever made any kind of controversial action or been in any kind of dispute with anyone, and that also puts our security at greater risk outside of Wikipedia as malicious persons have greater incentive to discover our personal information to attack our accounts. I'm sorry if you find this comment to be personally directed, but I cannot fathom how someone sitting on Arbcom does not realize that "require a new RfA at Arbcom's order" is effectively blacklisting compromised administrators, unless you really are ignorant to how Wikipedia works. This is me assuming good faith that you really are just ignorant, and not trying to create a backdoor security theatre desysop, which is what this really looks like to be honest. Ivanvector (^Talk/_Edits) 17:01, 4 May 2019 (UTC)

I think your (and Nick's) point about making individuals _targets for hacking is fair, but I really disagree with the rest of this. RfA is bad, we can all agree on that, but I think the emotion showed here since the circular shows that poor account security is not a deal breaker for many of our fellow editors and sysops; I include myself in that category, and I supported this change. Choosing who should be granted sysop permissions is the prerogative solely of RfA. ArbCom has now applied to themselves what is essentially the policy for Bureaucrats: removed permissions may not be automatically restored if there is a cloud, and the community should have the say. Our sysop permissions are a privilege and a responsibility, not an immutable right. RfA sucks, but, by definition, nobody else gets to say who gets the perms. As unintentionally suggested above, the easiest solution would be ArbCom desysopping compromised accounts per usual, and neither ArbCom nor bureaucrats regranting the permissions, making every sysop compromised go through RfA rather than just some. If not being able to convince ArbCom of proper account security is a consensus deal breaker at RfA, then, tautologically, it's a deal breaker for being made a sysop. ~ Amory (u • t • c) 17:24, 4 May 2019 (UTC)

• Honestly I'm very surprised at the vociferous response here. ArbCom has been handling compromised admin accounts for a decade with community approval. Multiple motions to resysop these accounts have been passed over the years with (correct me if I'm wrong) not a peep from the crats or any of the people who now seem to be incensed by that idea. In response to the increase in the rate of compromised accounts, and the community's consistently expressed view that admins need to stop letting this happen, we've decided to stop making these motions as a matter of course. We did this using existing longstanding policy (WP:SECUREADMIN and WP:STRONGPASS) and a minor modification to our internal procedures. The main reaction to that modification from the community was "good, about time". I'm struggling to understand what policy could have changed in that sequence of events.

I don't mind if people want to reassign responsibility for compromised admin accounts to the crats alone. But I don't understand how this ArbCom desysops/crats resysop idea would work in practice (or for that matter where it came from). Say we desysop a compromised account under our WP:LEVEL1 procedure. We don't think it's a good idea to give the tools back due to ongoing security concerns, but the user convinces a crat to do it anyway. Because ArbCom has responsibility for removal of administrative tools, we then use our WP:LEVEL2 procedure to desysop them again by motion. Of course, we'd have to ask a crat to action that, so why not just skip the wheel warring and stick with the status quo of "crats don't resysop unless there's an ArbCom motion"? Or are you contending that the crats could again resysop the desysopped resysopped desysopped sysop? How long does the cycle go on for? Can it also happen with accounts we desysop as part of a case? Isn't the obvious solution to this (highly hypothetical) disagreement between ArbCom and the crats to ask the community... in an RfA, exactly what would happen under our current procedure? – Joe (talk) 15:43, 4 May 2019 (UTC)

Indeed. It's actually bizarre or odd-hand-wringing to have this speculate about a remote 'stand-off' fear, because it's not like you people are aliens to each-other. -- Alanscottwalker (talk) 15:55, 4 May 2019 (UTC)

Nobody is required to do anything. Not even the stewards will know if you are using 2FA (see phab:T209749 for the status on that - currently that requires developer intervention). But if you get hacked and it is determined that you did nothing, well then ArbCom might not give you the sysop tools back. That's all that is being said here. --Rschen7754 16:04, 4 May 2019 (UTC)

Arbcom do yourselves and others a favor, and just send out, "The prior advisory does not require 2FA" Alanscottwalker (talk) 16:09, 4 May 2019 (UTC)

Yep, we're discussing that right now. GorillaWarfare (talk) 16:15, 4 May 2019 (UTC)

Before this goes off on too many tangents, again it is important to reiterate the key points:

1. There are serious issues with the MediaWiki 2FA software
2. Arbcom is (at minimum) recommending that administrators use MediaWiki 2FA
3. Arbcom has not indicated in any way that they understand the limitations of the 2FA extension, nor has it indicated that it is willing to actively work to influence the WMF to take control of the software, improve it, support it, and manage it in a professional manner.

I don't know why Arbcom doesn't see the contradiction between "use best security practices" and "you ought to use this imperfect and poorly supported software to secure your account." Heck, anyone can use Google 2FA, and it's more secure, better supported, and can do most of the things I mention in my original post. MediaWiki 2FA has a long way to go to be that good. Arbcom shouldn't be recommending specific security software for admins to use, even if it's MediaWiki software.

Incidentally, the communication method being used here is pretty common. First make an activity seem like the "preferred course". Then suggest that it should be the required course. Then imply that it *is* the required course. Then let others pick up the torch and they'll start enforcing the non-mandatory activity as though it is mandatory. I know this, and in fact described this method of communication and management of behaviour change pretty explicitly to Arbcom a few months ago, ironically when discussing other aspects of account compromise. Risker (talk) 16:17, 4 May 2019 (UTC)

@Risker: I agree that MediaWiki's 2FA is not good. Several other arbs said much the same thing when we discussed this. But it's not in ArbCom's remit to give account security advice, nor are we qualified to do so. We simply followed what's said in WP:STRONGPASS (Users with advanced permissions, and indeed all users, should be taking steps above and beyond these requirements to insure the security of their accounts. Two-factor authentication is now available to administrators...), WP:SECURITY (Wikimedia's implementation of two-factor authentication (2FA) is a way of strengthening the security of your account) and WP:SECUREADMIN (Two-factor authentication is available to administrators to further secure accounts from unauthorized use). If you disagree with that advice, I'd start there. I'm also sorry to say that I don't think we have nearly as much influence over the WMF as you imply. – Joe (talk) 16:47, 4 May 2019 (UTC)

@Joe Roe:, Arbcom has the direct ear of the WMF; you have monthly teleconferences with someone from Trust & Safety, which is one of the WMF departments that is pushing very, very hard to get MediaWiki 2FA accepted by the global community. While I do not believe Arbcom itself will make the difference, it's up to you whether or not you will advocate the use of shoddy software, which is pretty much what happened in this message. I've used what contacts I have, and if you use what leverage you have, and others use what leverage they have, then the multi-front approach has a chance of getting done what needs to be done. After all, it worked with VisualEditor - we eventually had so much leverage that the necessary changes were made. Arbcom's voice as a particularly strong one amongst many will be useful and will help move the dial. I'm not saying the concept of 2FA is horrible. I just don't think it is okay for Arbcom to take a supportive position in favour of software that doesn't meet the grade. Just leave 2FA out of any future statement until the WMF actually fixes it and takes full responsibility for its improvement, management and support. That's well within Arbcom's power. Risker (talk) 17:15, 4 May 2019 (UTC)

• Exactly. I certainly won't be using Mediawiki 2FA while it's as shoddy as it is at the moment. However, I use a unique email address for Wikipedia and have a very strong unique password, so I'm not particularly worried. It's nothing against 2FA as such - we use 2FA which sends an SMS to a mobile for our high-permission accounts in my workplace and haven't had an issue with it yet (well, apart from people leaving their phones at home, and there are ways round that). Black Kite (talk) 16:25, 4 May 2019 (UTC)

  However, if you are using even a very strong password, you still have a password recovery option via e-mail, which means that the e-mail muat be secure enough as well, and there is presumably a recovery option for an e-mail password, which also needs to be secure etc. I am not a 2FA fan, but the situation is not as simple.--Ymblanter (talk) 17:08, 4 May 2019 (UTC)

Sure, but why would it not be "best practice" to think about 2FA, the response is 'I thought about it and it does not fit, or is not fit.' Not only that but the more people thinking about 2FA, the more likely it can be improved, or use their ingenuity and suggest other methods. -- Alanscottwalker (talk) 16:31, 4 May 2019 (UTC)

• @Black Kite: You might want to point your workplace security folks to the NIST recommendations that prohibit using SMS for 2FA. There's a quick summary at https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ --RexxS (talk) 17:27, 4 May 2019 (UTC)

• Have you ever tried talking to network technicians? ;) Seriously though, I'm no expert on such things and was really talking about the simplicity of use of any 2FA system. Black Kite (talk) 17:40, 4 May 2019 (UTC)

• Rexx beat me to it but I had started mentally composing such a response before seeing this and strongly endorse his message here on all fronts. Best, Barkeep49 (talk) 17:38, 4 May 2019 (UTC)

• The Arbitration Committee, very much including myself, owe the community, and especially those who received the message, our sincere apology.

The communication was crafted with good intentions, but somewhere along the way, the message was lost. Some members on the committee expressed concerns about the tone and unclear instructions, particularly about 2FA. Unfortunately, those opinions were overlooked and the message was sent out. Nonetheless, the Arbitration Committee must take full responsibility for everything conducted under its name. The community deserves better and I believe we can be better. We can listen more carefully to one another when individual members raise concerns, especially on matters that affect the community. When mass messages are being drafted, we should be seeking input from the community in the form of comments and feedback to ensure that everything we send out is clear and most importantly respectful of the individuals who will be receiving it. And finally, when the community lets us know we have made a mistake, we need to be willing to sit down at the table and hear those concerns and find possible solutions and ways forward together.

Mkdw ^talk 16:38, 4 May 2019 (UTC)

Have you told your colleagues, who after bombarding everyone here with variations on "it's your fault for being too stupid to understand what we meant" have now moved on to outright lying? ‑ Iridescent 16:43, 4 May 2019 (UTC)

(edit conflict) @Mkdw: thank you, I'm glad to finally see at least one of the committee apologising and understanding why people are annoyed by this. I too was none too happy to wake up to this treatening message on my talk page this morning, and it is highly disappointing to see other members of the committee doubling down on this in the threads above, instead of being humble and apologising for what is ultimately an inaccurate representation of community policy. Thanks  — Amakuru (talk) 16:47, 4 May 2019 (UTC)

Thanks. No reason not to include that apology in your revised advisory. Alanscottwalker (talk) 16:53, 4 May 2019 (UTC)

An apology is certainly owed and I hope (and believe) that of the rest of the committee feels the same way. I do not always agree with the comments or positions of others on the committee and we often have diverse opinions on matters. It is one of our strengths but has also failed us in the past. The community had previously made it abundantly clear that 2FA is not a mandatory requirement and I deeply regret that the final version of the mass message was not more clear on that point. I have suggested retracting the mass-message. Any positive intentions by the message have been lost and we have frustrated and lowered the trust the community has in the current committee. Mkdw ^talk 17:18, 4 May 2019 (UTC)

• Agree with all of the above. The message is clearly worded as a threat to punitively desysop victims of security breaches, and it's probably the most threatening message I've ever received. "Required to run a new RfA" is a euphemism for "formally desysopped and thrown to the wolves", and everyone knows it. Also, it's worded as a highly overstepping authoritarian mandate that is not optional. Arbcom obviously doesn't have the authority to dictate what administrators "must" do. And, of course, it falsely suggests that admins must enable 2FA or at least are formally encouraged to, which the community has literally rejected for plenty of common sense reasons. This unprecedented mass message is so blatantly authoritarian and intimidating that I'm completely shocked that it came from the members of this Arbcom, whose current membership should be beyond repute. I'm truly shocked you guys all signed on to this and somehow saw nothing wrong with it. ~Swarm~ ^{sting} 16:42, 4 May 2019 (UTC)

To tweak that^^^ slightly: "whose current membership" contains admins who would themselves not pass the re-RfA they blithely advise others to undertake... ——SerialNumber54129 17:02, 4 May 2019 (UTC)

I do not think we have current Arbcom members who would fail an RFA, if this is what you mean.--Ymblanter (talk) 17:13, 4 May 2019 (UTC)

They almost certainly would fail, if the entire reason they're running a new RfA is because their account was compromised and they failed to convince the Arbitration Committee of the security of their account. Ivanvector (^Talk/_Edits) 17:18, 4 May 2019 (UTC)

I know it's probably comparing apples with oranges, and I am inferring no conclusions from this observation, but if we look at the results of last year's ArbCom election, all six of those elected were in what would be the "crat chat" percentage range if they were running for RfA. And all had more than 250 Wikipedians oppose their candidacy. I guess one of the reasons why arbs and existing admins aren't asked to re-run is because naturally you start making more enemies once in you're in those mopping positions, as you piss people off by pulling them up for breaking the rules.  — Amakuru (talk) 17:32, 4 May 2019 (UTC)

An Arb's office is two years (occasionally less), so yes, they have to re-run, if they want a new mandate. Alanscottwalker (talk) 17:42, 4 May 2019 (UTC)

I, for one, opposed the candidatures of most of the current arbitrators, but I would (as of now) support all of them at RfA.--Ymblanter (talk) 17:46, 4 May 2019 (UTC)

Briefly, I feel that, in this case, the Committee has overstepped their remit. Frankly, I just don't think they have the mandate to codify this as, for all intents and purposes, policy. The whole thing does not sit well with me. (Disclaimer: I'm one of the 14 admins who immediately removed the circular from their talk page.) El_C 17:28, 4 May 2019 (UTC)

The policy addition regarding the temporary removal of administrative privileges and a subsequent restoration was enacted in April 2009. The community has had a decade to raise any concerns if the restoration should be handled by the bureaucrats rather than the arbitration committee. At this point, for better or worse, this is the generally accepted practice. All the same, I agree the mass message was poorly worded. The committee was fully aware of the recent discussions on two-factor authentications, the consensus results, and the scalability issues that have been raised repeatedly. To write a message that implies all arbitrators should be enabling two-factor authentication, in spite of the practical deployment problems, is a severe failure to take responsibility for the consequences of your statements. isaacl (talk) 18:04, 4 May 2019 (UTC)

Isaacl, don't just take their word for it but actually read the policies you're linking. The policy adopted in 2009 was about Arbcom having the ability to remove permissions, which nobody here is disputing. The language granting them the supposed ability to restore permissions was added less than a month ago. ‑ Iridescent 19:31, 4 May 2019 (UTC)

Of course I read the link, which I dug out and located myself. It has a section "Return of permissions" where the committee asserted a role in determining if administrative permissions should be restored. isaacl (talk) 22:18, 4 May 2019 (UTC)

• Thanks User:Risker for continuing to lead the cause that WMF needs to take ownership of MediaWiki 2FA properly and make it conform to best practices, before placing a burden on advanced right-holders on WMF sites to use it. I came to this noticeboard wanting to make this point and am very happy that Risker has done it already. I agree that the ArbCom notice is generally quite well-written, except for the 2FA part. Instead of placing pressure on admins to use MediaWiki 2FA, Arbs should use their clout to pressure WMF devs to improve MediaWiki 2FA first. Deryck C. 18:25, 4 May 2019 (UTC)

• There will be a further more "official" message coming from ArbCom to clarify this, hopefully in the very near future, but I want to say unequivocally: ArbCom will not desysop or decline to resysop a single administrator, in any circumstance, for failing to use 2FA. That would be in violation of WP:ARBPOL, because admins are not required (or even recommended) to enable 2FA in WP:ADMIN. I've been on the inactive list throughout the drafting of the mass message and have been participating only in on-wiki matters, not matters being handled primarily on the mailing list, during that time. Still, my original message to arbcom-en when I read the initial draft of the mass message was "I'd rather not participate in this further, but can we please make this way less alarmist before it gets sent out?" That is a direct quote. I removed some of what I considered to be the worst excesses immediately afterwards, and I expected further edits to be made. I largely walked away from the discussion about the mass message at that point, because the past few weeks have been a busy and difficult period for me off-wiki.

  The messaging here was terrible, and I apologize for that, both on behalf of the Committee and on behalf of myself as an individual. It was meant to say "Hey, go secure your account. If you fail to meet the policies surrounding account security, you could be subject to a new RfA, just like if you violate any other policies and are desysopped for cause. Also, here's some tips from the Committee that may help you secure your account." It was not meant to imply that not following all of those tips would be in violation of WP:ADMIN#Security. In particular, enabling 2FA goes beyond the requirements of WP:ADMIN#Security. I consider it to be a good idea, but it is not required and would not factor into our decision-making about desysopping. This was not clear in the mass message, which I think has led to much of this kerfuffle.

  I further apologize for responding defensively in various places. I responded to the various accusations leveled against the Committee from a place of considering the motion we actually passed, not the motion that this mass message made it sound like we passed. ~ Rob₁₃^Talk 18:40, 4 May 2019 (UTC)

I'm glad you've accepted the poor wording of the mass message, and the reasons why it was poorly received. However, the part about "If you fail to meet the policies surrounding account security, you could be subject to a new RfA, just like if you violate any other policies and are desysopped for cause" needs to retracted too. We've already established above, through linked policy, that the committee doesn't have a veto over resysopping compromised accounts once it's determined that the account is no longer compromised. The idea that you could have to go through RfA again, just because your account was hacked, is not supported by any community consensus and is frankly quite worrying because not everyone has the same level of tech savviness to be able to come up with strong passwords. And on a more practical level, even if it's established that you do have that power, would you ever really use it? It seems to me that the message about strong passwords could be made without needing to issue any threats at all. Thanks  — Amakuru (talk) 20:53, 4 May 2019 (UTC)

It is admin misconduct to fail to abide by WP:ADMIN#Security, which is a community policy every admin should be familiar with. We have a mandate from the community to consider desysopping admins for cause when the evidence supports that, per ARBPOL. As I have noted above, if the community wishes to remove account security requirements from administrators or change the policy to note that the current requirements are merely suggestions, not requirements, they can do that. ~ Rob₁₃^Talk 20:57, 4 May 2019 (UTC)

Amakuru: It's really easy to come up with a strong password, though. I mean, I can do it. As a sysop without tech savviness, I advise this method: think of a quotation of twenty words or so that you like and know well, but that isn't generally known or quoted. Take the first letter of each word. There's your password. You can remember it, but it would take decades or centuries to bruteforce it. Personally I like verse quotations, because to me they're easier to remember with precision. Bishonen | talk 21:16, 4 May 2019 (UTC).

@Bishonen: Yes, that's a very nice method - and perhaps I might adopt it myself elsewhere, because although my Wiki password is strong and unique I do myself struggle with having different ones for all the myriad different places that require sign-up these days. And just to be clear, I'm not condoning anyone who might have a weak password or suggesting that it's an acceptable state of affairs. I'm just sceptical that it would ever be a reason for ArbCom to desysop for cause, at least for a first time "offender". A strong WP:TROUT, yes. And obtain assurances that the newly minted password is a strong one. But requiring an RfA to regain the tools? I don't see the Arbitration committee actually doing that in practice. Cheers  — Amakuru (talk) 21:28, 4 May 2019 (UTC)

Administrator account security (Correction to Arbcom 2019 special circular)

I'd like to thank the Committee for the correction. Sensible and reflective. I appreciate that. El_C 21:08, 4 May 2019 (UTC)

Without comment on the content itself, the last line, For the Arbitration Committee, -[[User:Cameron11598|Cameron11598]] 21:04, 4 May 2019 (UTC)</small> has an extra "/small" tag. Similar to the addition of a missing small tag to the original mass message (discussion) and adding a missing timestamp (discussion), should I do a bot run to remove the tag? --DannyS712 (talk) 21:12, 4 May 2019 (UTC)

I would recommend against. In the vast majority of cases, that tag will not change how the HTML renders on the page, so removing it with a bot edit would be a cosmetic-only change. An unclosed small tag is a major issue. And extra small tag close really isn't. ~ Rob₁₃^Talk 21:26, 4 May 2019 (UTC)

Was just about to note that the message went out, but I guess I'm too slow :) Anyway, linking it here for reference or for any non-administrators following this conversation who wouldn't have received it. GorillaWarfare (talk) 21:12, 4 May 2019 (UTC)

I should add, however, that I'm still not sure about the crux: the RfA clause — whether this goes outside the Committee's mandate I just don't know, but I tend to suspect that it does. El_C 21:17, 4 May 2019 (UTC)

To be honest that's another aspect of the wording I wasn't happy with and wish we'd talked more about. I would have preferred to have said, "we won't automatically resysop". What happens after that... go to RfA, go to the crats, move on, is outside ArbCom's concern. But we can't be expected to explicitly pass a motion returning the admin toolset to someone who we don't think should have it. And for those who believe we can't pass resysop motions at all, it should be especially uncontroversial. – Joe (talk) 21:23, 4 May 2019 (UTC)

• I have always used a strong password on my account and email, and use two factor authentication on both. I cannot see any valid reason for any admin failing to use 2FA. It's very easy to set up and substantially enhances account security. Even if I put my password in this very message, it would be useless to anyone who does not have my authentication device. Seraphimblade ^{Talk to me} 21:22, 4 May 2019 (UTC)

  I don't think it's true, there are valid reasons. Like unsuitable devices. Not to mention the apparent wonkiness of 2FA on Wikipedia is a factor to many. El_C 21:31, 4 May 2019 (UTC)

  Seraphimblade, do you think that all admins edit from their home PCs (or carry a phone with them), whenever and wherever they edit WP? There are many sysops, (I believe), who don't have phones and edit from random public PCs or edit from high-security installations, where downloading of external software is strictly prohibited along with a prohibition on bringing certain devices. And, not to mention the absolutely shoddy state of affairs that prevails, once you manage to successfully lose your authenticator as well as scratch codes. ∯WBG^converse 21:38, 4 May 2019 (UTC)

  • I use 2FA as well, but I strongly disagree with requiring it for all admins without a) solving some issues with the MW implementation that have already been raised here and elsewhere, and b) having some way to ensure that it places no undue burden on the admin. It's unreasonable to say "in order to be an admin on Wikipedia you must purchase a cell phone and keep it with you", for example. GorillaWarfare (talk) 21:42, 4 May 2019 (UTC)
    • 2FA does not require a cell phone. [6] But regardless, if an admin does not or cannot use 2FA, they should at least be held accountable for using an exceptionally strong password. An admin account on Wikipedia isn't some fuckaround thing; it can disrupt one of the most major websites on Earth. If you hold an admin account here, you should be expected to keep it secure and to know how to do so. 2FA is one of the most simple steps to do that. We should never tolerate administrators being lackadaisical about security of their account; that in itself indicates unfitness to be an admin. Seraphimblade ^{Talk to me} 21:48, 4 May 2019 (UTC)
    • And by the way, 2FA does provide backup one-time codes. I printed those out and have them where I know where they are. When my cell phone unexpectedly got broken, I used a backup code to generate a new 2FA with the new one. It's not terribly difficult. Seraphimblade ^{Talk to me} 21:52, 4 May 2019 (UTC)
      • Those ones can never be regenerated, and don't forget how un-savvy some people are. My sister had a coworker who, when asked on how to remove a file, she said "Just print it out and shred it" (not accounting that the file is on the PC). I know we need some competence in being an admin, but are admins now required to be technically capable and avoiding the "I lost my codes and devices because my house burned down/flooded" issue ? WhisperToMe (talk) 07:31, 5 May 2019 (UTC)
      • For the record, I think this is basically the right description of what we were going for. Secure your account as best you can. The policy requires a strong password at minimum. That's what we were trying to say. ~ Rob₁₃^Talk 22:34, 4 May 2019 (UTC)
      • Yeah I don't get WTF people keep talking nonsense. There is no need for a smart phone to use TOTP. There are plenty of programs including browser plugins for desktop computers. The device with 2FA does not need to be seperate from the device you use to access WMF sites. You're free to use the same device if the device has some software capable of generating TOTP tokens. Technically it doesn't even need to be software on the device, I mean you could generate the codes on a remote device if you wanted to. (Although this is a bit of an obscure and risky use case so I don't think it's something that is easily done by the average user.) Note also the device generating the codes never needs internet access. (The device logging in obviously does.) Sorry for being so harsh but IMO there are limitations with the WMF's 2FA implementation and serious discussions to be had about them, so nonsense which isn't actually part of the WMF's implementation is harmful to everyone. And this has been discussed often enough that anyone wanting to take part in a serious discussion should at least know want aren't actually limitations. Nil Einne (talk) 04:56, 5 May 2019 (UTC)
        • Who said that phone was necessary? How do you plan to use 2FA, comfortably, if you edit from random public PCs, other than being compelled to purchase a portable device that will carry the authenticator? There are many, who operates from military installations. AFAIK, they seriously object to downloading browser plugins or random software whilst often disallowing users to bring in mobile et al, (where they might have installed their authenticator). What do they do? I, personally use 2FA but to say thay it creates no accessibility issues is weird. ∯WBG^converse 05:20, 5 May 2019 (UTC)

          • Well if you follow the thread, you will see I replied to a post which pointed out phones weren't necessary. This post did so in response to a post which said 'It's unreasonable to say "in order to be an admin on Wikipedia you must purchase a cell phone and keep it with you", for example' (emphasis added). I don't see the purpose of this comment except to claim that our current implication means you need a cell phone especially in light of what was said earlier in that reply.

            If I am mistaken, I apologise, but I've definitely seen people who think you need a phone elsewhere in recent discussions on our 2FA. And IMO whatever that comment meant, it was at a minimum unnecessarily confusing since there's no reason to bring cell phones and the need to purchase them into it when it isn't a required part of our 2FA in any way.

            My follow up to you, who said 2FA "creates no accessibility issues"? I mean I'm sure someone has somewhere said that, but as far as I can tell, no one in this thread ever did so I'm not sure the relevance of your comment to this thread. I specifically said "there are limitations with the WMF's 2FA implementation and serious discussions to be had about them". And indeed talked about the limitations in IMO more detail than you did in a post here Wikipedia:Administrators' noticeboard#Query about sudden need for new security. I did so before I posted here so I presume before you replied to me. (No I don't expect you to have read what I said there, my point is to emphasise even more I'm clearly not suggesting there are no issues with our 2FA.)

            The whole point of my post both there and here is that there are issues with the implementation and legitimate discussion to be had especially in how they affect our diverse range of users. But we need to be clear on what the actual limitations are. My view is that comments which ascribe limitations which aren't actually part of the system help no one. They actually make it far more difficult to have a proper discussion about the limitations. In addition, I also feel that 2FA has been discussed often enough that there is really no excuse to be so majorly misinformed as to think TOTP requires a phone when you are taking part in a serious discussion about 2FA (rather than just asking for information/help).

            Nil Einne (talk) 18:50, 6 May 2019 (UTC)

            • P.S. There are some issues with our 2FA I missed in my reply linked above. I didn't intend it to be an extensive list. I did do my best to ensure nothing I said was incorrect since it really irks me what that happens both on a personal level but also as I've said because I think it's important we do our best to ensure we don't incorrectly ascribe stuff whether limitations or possibilities with our 2FA since it's harmful to the discussion. I admit I probably shouldn't have gotten involved since I'm not particularly well informed. (I only did because of my annoyance with stuff which was IMO inaccurate.) I've barely participated in discussion about our 2FA at all, and my reply was largely based on some quick searches along with vague memories of previous discussions and my existing understand of TOTP again supplemented by some quick research perhaps over 2 hours or so while I composed that post. I didn't come across [7] which would have been helpful. Nil Einne (talk) 19:00, 6 May 2019 (UTC)

Tracked in Phabricator
Task T172079

• Wikipedia’s 2FA implementation is defective. If you lose your Authenticator device or it has a sudden technical failure you will be locked out with no way to ever get back in. (This happened to me. I had to go outside of all process and get a developer to twiddle the database, a really bad practice.) A proper implementation would allow registration of at least two trusted devices so that if one fails the other is still usable. Additionally there should be a manual process to ask a bureaucrat to let a user back in if they somehow lose all their trusted devices. Keep in mind that many users can’t afford to buy multiple devices. Feel free to contact me for more information. Jehochman ^Talk 10:09, 5 May 2019 (UTC)
  • And on top of that, a lot of people will have trouble juggling two authenticators as they may not be technically adept. WhisperToMe (talk) 17:09, 5 May 2019 (UTC)

• Thanks ArbCom for the update about the fact that 2FA remains optional; that is much appreciated and shows that the ArbCom is positively responsive to criticism. @Jehochman: There's an open (but pretty stale) Phab task about allowing multiple devices. Deryck C. 12:37, 6 May 2019 (UTC)

  I am sad. People debate paint colors all day long, but nobody is willing to paint the bikeshed. We need less talk and more action. Jehochman ^Talk 13:37, 6 May 2019 (UTC)

• Why is this committee assuming the role of project manager? What is the policy basis for password rules? Is there a Wikipedia password policy, or a Wikimedia password policy? Is this the result of an arbitration? Does the committee's arbitration mandate extend to those not involved in the dispute? --SmokeyJoe (talk) 03:37, 15 May 2019 (UTC)

Creation of an AfD by a non-ECP editor in the ARBPIA area

I've just discovered that a new editor created an AfD for an article in the ARBPIA area. They can't even use talk pages outside of article space, so I assume this is forbidden. For articles we say "Editors who are not eligible to be extended-confirmed may not create new articles, but administrators may exercise discretion when deciding how to enforce this remedy on article creations. Deletion of new articles by editors who do not meet the criteria is permitted but not required." But what do we do when a new editor creates an AfD? Doug Weller talk 12:09, 16 May 2019 (UTC)

The present Wikipedia:Arbitration/Requests/Case/Palestine-Israel articles 3#Prohibition already covers this as:

1. "prohibited from editing any page"
2. Sole carve outs:
   1. "Editors who are not eligible to be extended-confirmed may use the Talk: namespace..."
   2. "Editors who are not eligible to be extended-confirmed may not create new articles, but administrators may exercise discretion ...".

Creating an AfD normally requires placing a notice on the article itself. Furthermore the AfD itself is in the Wikipedia namespace - therefore editing it is prohibited per the current General prohibition (and in fact, non-ECP accounts are regularly struck as !votes in such AfDs). Icewhiz (talk) 12:16, 16 May 2019 (UTC)

@Icewhiz: I know, but the article didn't have any type of ARBPIA notice nor did the editor. And even the DS alert says nothing about these restrictions - and it should. Doug Weller talk 14:46, 16 May 2019 (UTC)

The DS alert is separate from the General prohibition or 1RR - both of those fall outside of the standard DS remit. Rulings in AE (and I think ARBCOM too - there was an ARCA or ARCA appeal on this, I think - over how to notify editors of the General Prohibition) - have generally required editors to be aware of the General Prohibition (DS alert not sufficient - I generally copy over the text from ARBPIA3 after AE (or ARCA) ruled that a friendlier notification was insufficient). It would be nice if we had a DS++ alert containing all these things (1RR in the topic area, 500/30) - but it doesn't. Icewhiz (talk) 14:52, 16 May 2019 (UTC)

• That sounds like something that should be forbidden if it's not already forbidden in the tangle of words that we have for ARBPIA. In this case, would WP:Speedy keep apply, or was the AfD done in good faith? SilkTork (talk) 16:20, 16 May 2019 (UTC)

  Wikipedia:Articles for deletion/Just Future For Palestine Flotilla (2nd nomination). It's a good faith AfD, started by an editor who wasn't aware of the General Prohibition. It is mostly sourced to the organization itself and it lists every single BLP (mostly non-notable, 1 does have an article) that were on the two boats. Icewhiz (talk) 16:31, 16 May 2019 (UTC)

• If it ain't broke, don't fix it. There's no point debating rules for their own sake when there nothing disruptive happening. GMG^talk 16:51, 16 May 2019 (UTC)
  • @GreenMeansGo: of course he can't edit his AfD anymore. And the DS alert needs improving. Doug Weller talk 19:20, 16 May 2019 (UTC)
    • I really don't see why not. The ECP decision is probably one of the least enforced and most derided things ArbCom has ever done, and users who request preemptive ECP at RFPP according to the "letter of the law" where there is no active disruption are often turned out, at least from what I've seen. Any admin who actively sought to ECP a dozen thousand pages under this ruling would find a short road to a noticeboard. At any rate, in no way is it worth BITING a new editor who hasn't caused any real trouble by all accounts. If a rule prevents you from improving or maintaining Wikipedia, ignore it. GMG^talk 19:29, 16 May 2019 (UTC)
      • @GreenMeansGo: there's ordinary ECP and there's ARBPIA ECP for articles reasonably (not broadly) construed. The article in question is clearly reasonably construed and thus the AfD is. I'd be very surprised if Admins at RPP refused to add ECP to reasonably construed articles, that would undercut the ArbCom decision, which may be revisited in any case. I don't think the new editor is bitten by being alerted, that's exactly what we are trying to avoid and in fact discussing right now. DS alerts should be routine, not just used where there are problems with an editor. Doug Weller talk 10:35, 17 May 2019 (UTC)
        • Yes, I understand the difference, and yes that would undercut the ArbCom decision, and that doesn't seem to have a pronounced effect on whether individual admins are willing to preemptively protect pages in contravention of normal practices based on an ArbCom ruling. When I was referring to BITING, I was referring to effectively topic banning someone from and AfD they opened in good faith when they're not being disruptive. (Keeping in mind that a new editor with less than 300 contributions on any project, who takes the time to actually read our policy on notability, and manages to figure out that AfD exists in the first place should generally be given all the barnstars for their patience and attention to detail.) But yes, now that you mention it, the DS notices are fairly bitey in and of themselves. GMG^talk 10:47, 17 May 2019 (UTC)
          • @GreenMeansGo: did you take part in the attempt to rewrite them recently? I'm not sure how they can be improved, they already make it explicit that they don't imply any problems with the editors. I just noticed your edit summary, where do you get 12,000 reasonably construed articles? As for the editor, I can't tell him that he can't edit reasonably construed pages and then give him an exception and in any case ECP stops him. I added ECP not to stop him but because it seems daft to ECP and article but not the AfD. I don't think you edit much in the area and those that don't, including Committee members, probably don't have much of a feel for the problems those of us who do encounter. Doug Weller talk 10:56, 17 May 2019 (UTC)
            • Well, this is all probably just turning out to be the latest season of GMG Complains About ArbCom (new episodes Thursday nights on NBC). I'll be the first to admit I edit lots of things, and don't specialize in any one topic, or any one project for that matter. No, I was not aware that such a discussion took place (it doesn't seem to have been effective) and doubt my opinion would be terribly welcome if I had been (8:00pm on NBC). The number is just rough back-of-the-envelope math I did ages ago based on articles within the scope of related WikiProjects, and "a dozen thousand" seemed like a particularly effective rhetorical formulation.
              Yes, it's probably entirely too late, and would just be more confusing to try to undo the steps taken in this particular situation. Just a reminder that no one is compelled to take any action, and least of all when most of what it seems to accomplish is merely a greater sense of bureaucratic consistency. GMG^talk 11:34, 17 May 2019 (UTC)

Preventative action can have little to do with bureaucratic consistency. El_C 11:40, 17 May 2019 (UTC)

And that comes off a bit too much like a truism. GMG^talk 12:19, 17 May 2019 (UTC)

I don't know what you're trying to say. El_C 12:21, 17 May 2019 (UTC)

Anyway, the editor in question has come to me for advice about something else, so that's ok. Doug Weller talk 18:56, 17 May 2019 (UTC)

Probably of little interest to anyone

Preventative action can have little to do with bureaucratic consistency. It's a truism that begs the original question. He'd be an honest man if he weren't such a liar. ... The sun will still rise in the morning. Honest men are those who don't lie, and the morning is the time when the sun rises. In other words, by implying that page protection in the absence of current disruption has more to do with a sense of bureaucratic consistency, I am commenting exactly on whether it is a means of prevention to begin with, because there seems to be little disagreement about whether the AfD was done in good faith, with a reasonable rationale, in a way that is not overtly disruptive. Your statement seems to contradict mine, but doesn't actually, because it's very nearly a tautology. It merely restates the definition of preventative, without addressing the issue being raised, which is whether it is in fact preventative and what exactly it is supposed to be preventing. GMGtalk 12:58, 17 May 2019 (UTC)