Archive 35 ← Archive 38 Archive 39 Archive 40 Archive 41 Archive 42 → Archive 45

Return of permissions for compromised administrator accounts

Original announcement
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)
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. SQLQuery 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)
Jehochman’s comments

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. ~ Rob13Talk 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. ~ Rob13Talk 17:49, 16 April 2019 (UTC)
I think a 2 week minimum is a reasonable time frame for something like this. –xenotalk 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. –xenotalk 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. ~ Rob13Talk 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. ~ Rob13Talk 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. ~ Rob13Talk 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. ~ Rob13Talk 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
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)
  • @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)

Bradv appointed as clerk

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

Change to CheckUser team

Original announcement

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. ~ Rob13Talk 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:

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)
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)

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
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)
@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. –xenotalk 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)
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] –xenotalk 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 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. ∯WBGconverse 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)
@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. ~ Rob13Talk 20:21, 7 May 2019 (UTC)

Wikipedia:Arbitration/Requests/Case/Enigmaman closed

Original announcement

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)

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)

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. GMGtalk 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. ~ Rob13Talk 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. GMGtalk 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. ∯WBGconverse 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)
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 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)
@Bbb23: Your house being, of course, Fort Knox  :) ——SerialNumber54129 14:01, 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. ~ Rob13Talk 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)
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". ~ Rob13Talk 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. ~ Rob13Talk 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". ~ Rob13Talk 15:30, 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)

(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)
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)
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)
  • 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)
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)
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)
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. ~ Rob13Talk 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. ~ Rob13Talk 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)
Tracked in Phabricator
Task T172079

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)
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. GMGtalk 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)
More