Wikipedia:Arbitration/Requests/Motions
- recent changes
- purge this page
- view or discuss this template
Currently, there are no requests for arbitration.
Request name | Motions | Case | Posted |
---|---|---|---|
Amendment request: World War II and the history of Jews in Poland | Motion | (orig. case) | 21 June 2024 |
Amendment request: Suspension of Beeblebrox | Motion | none | 10 July 2024 |
Clarification request: Desysoppings | none | none | 12 July 2024 |
Motion name | Date posted |
---|---|
Proposed amendment to the arbitration policy | 8 April 2019 |
Restoration of sysop privileges to Necrothesp | 10 April 2019 |
Motions
This page can be used by arbitrators to propose motions not related to any existing case or request. Motions are archived at Wikipedia:Arbitration/Index/Motions. Only arbitrators may propose or vote on motions on this page. You may visit WP:ARC or WP:ARCA for potential alternatives. You can make comments in the sections called "community discussion" or in some cases only in your own section. Arbitrators or clerks may summarily remove or refactor any comment. |
Proposed amendment to the arbitration policy
Motion adopted (version 2) Bradv🍁 23:04, 8 April 2019 (UTC) |
---|
The following discussion has been closed. Please do not modify it. |
Version 1Pursuant to the arbitration policy's section on "Ratification and amendment", the Arbitration Committee resolves that the following change to the arbitration policy will be submitted for formal ratification by community referendum: The "Conduct of arbitrators" section of the arbitration policy is amended to add the following underlined text:
This amendment to the arbitration policy will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this amendment is ratified, the existing arbitration policy remains in effect.
Version 2Pursuant to the arbitration policy's section on "Ratification and amendment", the Arbitration Committee resolves that the following change to the arbitration policy will be submitted for formal ratification by community referendum: The final paragraph of the "Conduct of arbitrators" section of the arbitration policy is amended as follows:
This amendment to the arbitration policy will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this amendment is ratified, the existing arbitration policy remains in effect. Enacted – Bradv🍁 22:58, 8 April 2019 (UTC)
Discussion and comments
|
Restoration of sysop privileges to Necrothesp
Version 1 (Necrothesp)
On March 14, 2019, the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) were temporarily removed as a suspected compromised account under the Level 1 desysopping procedures.
Following discussion concerning account security, and pursuant to the procedures for return of revoked permissions, the Arbitration Committee resolves the following:
The administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) are restored, provided he enables two-factor authentication on his account.
Enacted – bradv🍁 02:50, 10 April 2019 (UTC)
- For this motion there are 11 active arbitrators. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.
- Support
- As proposer. Assuming he makes the request to the Stewards and we receive confirmation of the 2FA being activated before the bit is flipped back on. ♠PMC♠ (talk) 21:22, 7 April 2019 (UTC)
- Second choice. Katietalk 21:45, 7 April 2019 (UTC)
- I can support this while pondering the wording of procedures moving forward. And perhaps it would be more appropriate to have a separate motion on procedures rather than tangle up the voting of a resysop with the voting of procedures because if some Arbs are not happy with the wording of the procedures motion, that could hold up Necrothesp's resysopping further. Provided Necrothesp enables 2FA, he can have the tools back while we jiggle with the procedures motion. SilkTork (talk) 22:42, 7 April 2019 (UTC)
- Sympathetic to the view espoused by Joe, but I think enabling 2FA mitigates the risk well enough for me. AGK ■ 14:08, 8 April 2019 (UTC)
- It gets lost sometimes in the rhetoric around account security, but admin accounts do not actually have access to the nuclear codes. We do not now have evidence that Necrothesp's account is any less secure than any other active admin's, and indeed just-breached accounts are probably the safest :) Even though everyone who plausibly can use 2FA really should, I'm very hesitant about this as a general practice - "if you get compromised, you'll be required to enable 2FA after" - because of the possibility that it will end up excluding people whose circumstances don't fit with MediaWiki's somewhat clunky implementation. But for this case I think it's reasonable. (In general, we'll get more bang for the security buck yelling from the rooftops at every opportunity that Thou Shalt Not Reuse Passwords, not even once, not even if you used password123Reddit and password123Wikipedia and now think it's unique, not even if the recycled password is "correct horse battery staple", just no. Are you reading this post and unsure if you might have used your Wikipedia password on dodgy-downl0adz.com? Go change it, right now before you forget, I'll give you a cookie after.) Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)
- Necrothesp has enabled 2FA and therefore has, in my opinion based upon the available information regarding the situation, adequately secured their account from being compromised again and should have the tools returned to them. Mkdw talk 21:36, 8 April 2019 (UTC)
- Oppose
- In favor of version 2, which also addresses how we should handle these situations going forward. ~ Rob13Talk 21:41, 7 April 2019 (UTC)
I will switch to support if 3 passes.~ Rob13Talk 15:12, 8 April 2019 (UTC)
- In favor of version 2. RickinBaltimore (talk) 22:54, 7 April 2019 (UTC)
- I am not convinced that Necrothesp adequately secures his account. By community policy, this is admin misconduct. In this instance, his negligence allowed a focused attacker to seriously vandalise the main page and a template used on almost every other Wikipedia page. Enabling 2FA is not going to solve the underlying lack of attention to basic security (it would also be impossible for us to monitor in the long term), so unfortunately I must come to the conclusion that Necrothesp can no longer be trusted with the tools. – Joe (talk) 05:27, 8 April 2019 (UTC)
- Abstain/Recuse
- Arbitrator comments/discussion
- @BU Rob13: How would it be Necrothesp's fault if motion 2 or 3 did not pass? It would not, so more importantly, why should Necrothesp's fate be tied to these two motions if you have reasonable confidence that their account will be secure (with 2FA enabled)? We are discussing and voting on increasing our security standards below, but I think it is unethical to hold someone hostage for effectively a political and policy position. They should be assessed fairly against our current enacted policies and protections, even if the ultimate decision is to deny their request to return their tools. Mkdw talk 16:03, 8 April 2019 (UTC)
- I absolutely agree. I want to reiterate that I think it is incredibly underhanded to suggest this kind of package motion where the handling of issues related to one person are combined with, and therefore made hostage to, a broader policy discussion. I sincerely hope that I don't see this kind of thing becoming a common practice. ♠PMC♠ (talk) 16:26, 8 April 2019 (UTC)
- +1 to PMC. This is a shabby way to treat a volunteer who made a mistake. We have plenty of other places to argue about internal wikipolitics. Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)
- Our current policy on administrators states that administrators must secure their account. Necrothesp fell short of that standard in a way that puts me squarely on the fence when it comes to restoring permissions. The problem is that we haven't enforced our current policy for quite some time, which may have created an expectation we would not enforce it going forward. While certain administrators have lagged behind in their security standards and their understanding of relevant policies, so too has the Arbitration Committee when it came to enforcing those standards and policies. I believe opposing this motion is justified by our current policy, and the motions proposed below merely state that we will be enforcing existing community policy going forward. If, as a Committee, we decide that it's worthwhile to clarify that we will begin enforcing the current policy going forward, I am willing to support this resysop due to the expectations our shoddy enforcement caused. If we decide such a clarification is unnecessary, then there is no reason not to enforce the current policy now, which leads me to oppose resysopping. ~ Rob13Talk 17:52, 8 April 2019 (UTC)
- You are opposing Necrothesp to make a point. Your vote is completely contingent on whether the committee will vote in alignment with your own agenda to amend the policy. Such strategic voting with ulterior motives should not be a practice on the Arbitration Committee. Your view that the committee is not appropriately enforcing the policy is a valid argument, but conditionally voting with the express purpose of trying to influence votes is immoral. Oppose if in your fair assessment you believe Necrothesp does not meet the policy. Support if you do. But specifically voting because your policy amendment did not pass is an irresponsible tactic. We reach these decisions as a committee majority and ultimately to the frustration of some when the vote does not go their way. If you think conditional voting is the way to address or influence the process, that is in my opinion an error in judgement and a much more problematic issue than the one it is trying to solve. Mkdw talk 00:31, 9 April 2019 (UTC)
- I both object to and take offense to quite a bit of what you said, but frankly, I don't have the energy or drive to respond to an arbitrator calling me immoral in response to an attempt to compromise. I will simply oppose. ~ Rob13Talk 03:25, 9 April 2019 (UTC)
- You are opposing Necrothesp to make a point. Your vote is completely contingent on whether the committee will vote in alignment with your own agenda to amend the policy. Such strategic voting with ulterior motives should not be a practice on the Arbitration Committee. Your view that the committee is not appropriately enforcing the policy is a valid argument, but conditionally voting with the express purpose of trying to influence votes is immoral. Oppose if in your fair assessment you believe Necrothesp does not meet the policy. Support if you do. But specifically voting because your policy amendment did not pass is an irresponsible tactic. We reach these decisions as a committee majority and ultimately to the frustration of some when the vote does not go their way. If you think conditional voting is the way to address or influence the process, that is in my opinion an error in judgement and a much more problematic issue than the one it is trying to solve. Mkdw talk 00:31, 9 April 2019 (UTC)
- Our current policy on administrators states that administrators must secure their account. Necrothesp fell short of that standard in a way that puts me squarely on the fence when it comes to restoring permissions. The problem is that we haven't enforced our current policy for quite some time, which may have created an expectation we would not enforce it going forward. While certain administrators have lagged behind in their security standards and their understanding of relevant policies, so too has the Arbitration Committee when it came to enforcing those standards and policies. I believe opposing this motion is justified by our current policy, and the motions proposed below merely state that we will be enforcing existing community policy going forward. If, as a Committee, we decide that it's worthwhile to clarify that we will begin enforcing the current policy going forward, I am willing to support this resysop due to the expectations our shoddy enforcement caused. If we decide such a clarification is unnecessary, then there is no reason not to enforce the current policy now, which leads me to oppose resysopping. ~ Rob13Talk 17:52, 8 April 2019 (UTC)
- @Opabinia regalis: It's also sometimes lost in the WP:NOBIGDEAL rhetoric that Wikipedia admins are, amongst other things, entrusted with sysop privileges on the world's fifth most visited website. That includes some very risky buttons. Can you imagine the front pages of YouTube or Amazon being replaced with "hacked by <some kid with tor>", even for a couple of minutes? That we are a volunteer project shouldn't stop us aspiring to the same level of professionalism. It's not the nuclear codes, but all we ask of admins is to adhere the most basic of security practices. Things that, for example, have been technically enforced in every workplace I've been at, despite me rarely being trusted with much more than the coffee machine. The evidence that Necrothesp's account is a continuing vulnerability is the fact that it has already been compromised once, and in his public and private responses to this incident. – Joe (talk) 18:10, 8 April 2019 (UTC)
- I agree with Joe, but there's also just generally a myth that compromised admin accounts don't cause real world harm. For instance, imagine a compromised admin account edits the main page to include a violent or extremely sexual picture, which is not an uncommon type of vandalism. How many traumatized children whose parents rightfully expected a clean main page are acceptable to us? I'm not all too bothered by "hacked by <some kid with tor>". I'm very bothered with putting hundreds of children around the world into therapy. And don't even get me started on the possibility for compromised CU accounts. ~ Rob13Talk 20:16, 8 April 2019 (UTC)
- I'm not saying it's optimal for that kind of thing to happen, but suggesting that a single instance of accidentally viewing an inappropriate image would put "hundreds of children around the world into therapy" is a bit of an overstatement. ♠PMC♠ (talk) 22:23, 8 April 2019 (UTC)
- It depends what image. Someone who had been beheaded or something similarly gory? If viewed by a young enough child, that could certainly cause non-trivial issues for the parents to deal with, at the very least. ~ Rob13Talk 22:25, 8 April 2019 (UTC)
- I'm not saying it's optimal for that kind of thing to happen, but suggesting that a single instance of accidentally viewing an inappropriate image would put "hundreds of children around the world into therapy" is a bit of an overstatement. ♠PMC♠ (talk) 22:23, 8 April 2019 (UTC)
- Well, yes, I can imagine perfectly respectable websites (and debatably respectable ones, and not-respectable ones) getting hacked, sometimes in hilarious ways. (While looking for examples I checked our own list of security hacking incidents, which I'm tickled to discover begins with a telegraph demo in 1903 :) We don't need to resort to hyperbolic "but won't someone think of the children?" what-iffery to not want crap on our front (or any other) page, and to expect people to take reasonable precautions to avoid it, but IMO a lot of hyperbole and drama around account security is actually a perverse incentive - it makes the whole thing sound Big and Scary and like exactly the kind of thing people mean to pay attention to when they have time, sometime next week, after work, after this TV show is over, maybe in the morning, etc. It's anxiety-inducing! If you get it wrong, you might send hundreds of children into therapy! Better to just not worry about it. (This is exactly the approach I take to my taxes every year, and every April 14 I regret it, but as of, say, April 9? Feels great, man.) In fact the best thing anyone can do for their own security is use a strong, unique password. You only have to take one single action, one time, to be absolutely sure there's no risk of having forgotten that you reused the same password when you signed up for that Warcraft forum that one time in 2011. Opabinia regalis (talk) 05:50, 9 April 2019 (UTC)
- I agree with Joe, but there's also just generally a myth that compromised admin accounts don't cause real world harm. For instance, imagine a compromised admin account edits the main page to include a violent or extremely sexual picture, which is not an uncommon type of vandalism. How many traumatized children whose parents rightfully expected a clean main page are acceptable to us? I'm not all too bothered by "hacked by <some kid with tor>". I'm very bothered with putting hundreds of children around the world into therapy. And don't even get me started on the possibility for compromised CU accounts. ~ Rob13Talk 20:16, 8 April 2019 (UTC)
Version 2 (Necrothesp)
On March 14, 2019, the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) were temporarily removed as a suspected compromised account under the Level 1 desysopping procedures. The Arbitration Committee has verified that Necrothesp is back in control of their account via multiple methods. The administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) are restored, provided he enables two-factor authentication on his account for as long as he retains the sysop flag.
Since November 2018, six accounts have been desysopped under the Level I desysopping procedures as compromised administrator accounts. The Arbitration Committee would like to remind administrators that they are required to "have strong passwords and follow appropriate personal security practices." The current policy on security of administrator accounts provides that "a compromised admin account will be blocked and its privileges removed on grounds of site security" and "in certain circumstances, the revocation of privileges may be permanent."
The Arbitration Committee resolves that the return of administrator privileges to a compromised account is not automatic, in line with this policy. The Arbitration Committee will review all available information to determine whether the administrator followed "appropriate personal security practices." Factors the Arbitration Committee may use to make this determination include, but are not limited to, whether the administrator used a strong, unique password on both their Wikipedia account and associated email account, whether the administrator enabled two-factor authentication, and how the account was compromised. If the Committee determines the administrator failed to secure their account adequately, the administrator will not be resysopped automatically. Unless otherwise stated, they may regain their administrative permissions through a successful request for adminship.
- For this motion there are 11 active arbitrators. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.
- Support
- We need to start actually enforcing the community policy on the security of administrator accounts. The existing policy states admins must at least try to secure their accounts. Where we determine that they declined to do so and it resulted in damage to the encyclopedia, we should not be resysopping automatically. This alternate motion simply makes clear that we will be following existing community policy surrounding account security going forward. ~ Rob13Talk 21:41, 7 April 2019 (UTC)
- Second choice to Motion 3. ~ Rob13Talk 15:12, 8 April 2019 (UTC)
- First choice. It is not exactly fair to Necrothesp to change the rules midstream, but I am heartily tired of dealing with these compromised admin accounts. Now everyone is on notice that resysop is no longer automatic in these situations. Katietalk 21:45, 7 April 2019 (UTC)
- RickinBaltimore (talk) 22:54, 7 April 2019 (UTC)
- Oppose
- Oppose on principle; restoring Necrothesp's privileges should not be contingent on altering our existing procedures. They're two separate discussions. ♠PMC♠ (talk) 21:44, 7 April 2019 (UTC)
- I support the warning about enforcement from now on, but oppose resysopping Necrothesp, per above. If this doesn't pass, we should vote on a standalone motion with just the second two paragraphs. – Joe (talk) 05:30, 8 April 2019 (UTC)
- Unhelpfully, this motion conflates two different issues (our procedures for the future – and what to do with Necrothesp). AGK ■ 13:52, 8 April 2019 (UTC)
- On principle. Mkdw talk 16:04, 8 April 2019 (UTC)
- Now we have separated the resysopping from the procedure, this motion is no longer appropriate. SilkTork (talk) 17:07, 8 April 2019 (UTC)
- Per PMC and Mkdw. Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)
- Abstain/Recuse
- Arbitrator comments/discussion
- Has it been confirmed by us that Necrothesp is back in control of their account? The question was raised on the email list, and it was thought that the Foundation did the confirmation. I don't wish to change the wording as I don't actually know who did confirm it. SilkTork (talk) 22:33, 7 April 2019 (UTC)
- Per the Global log, T&S verified this and unblocked him. ♠PMC♠ (talk) 22:56, 7 April 2019 (UTC)
- We've also verified it via the WMF. A WMF staff member assured me that the person who is currently in control of the account is definitively the original account holder. This matches the language of past motions on resysopping previously-compromised admin accounts. ~ Rob13Talk 23:14, 7 April 2019 (UTC)
- Per the Global log, T&S verified this and unblocked him. ♠PMC♠ (talk) 22:56, 7 April 2019 (UTC)
Motion 3: Return of permissions
Since November 2018, six accounts have been desysopped under the Level I desysopping procedures as compromised administrator accounts. The Arbitration Committee reminds administrators that they are required to "have strong passwords and follow appropriate personal security practices." The current policy on security of administrator accounts provides that "a compromised admin account will be blocked and its privileges removed on grounds of site security" and "in certain circumstances, the revocation of privileges may be permanent."
The Arbitration Committee resolves that the return of administrator privileges to a compromised account is not automatic. The committee's procedure at Wikipedia:Arbitration Committee/Procedures § Removal of permissions, subsection Return of permissions, is replaced by the following:
Removal is protective, intended to prevent harm to the encyclopedia while investigations take place, and the advanced permissions will normally be reinstated
onceif a satisfactory explanation is provided or the issues are satisfactorily resolved. If the editor in question requests it, or if the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances.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. Factors used to make this determination include: whether the administrator used a strong password on both their Wikipedia account and associated email account; whether the administrator had reused passwords across Wikipedia or the associated email account and other systems; whether the administrator had enabled two-factor authentication; and how the account was compromised.
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.
- For this motion there are 10 active arbitrators, not counting 1 recused. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.
- Support
- Proposed; splitting this from Motion 2 per our earlier discussions. In the wording for a new procedure, I have separated the requirement for a 'strong password' and for a 'unique password' to drive home the point: reusing passwords across systems is unsafe. AGK ■ 14:21, 8 April 2019 (UTC)
- Support as 2nd choice. RickinBaltimore (talk) 14:53, 8 April 2019 (UTC)
- Fully happy with this. First choice, since it puts it into our procedures directly. ~ Rob13Talk 15:11, 8 April 2019 (UTC)
- Explicitly adding it to our procedures is a good idea. – Joe (talk) 18:13, 8 April 2019 (UTC)
- Katietalk 02:33, 9 April 2019 (UTC)
- Well, the path that got to this wasn't very good - let's not try this particular style of attempted compromise anymore. But I think the substance is reasonable. I agree with PMC that there's some fuzziness here, but normally I'd expect that to be a good thing that allows us to be clear with the community about expectations while also allowing room for case-by-case evaluations. It does also allow room for implausible speculation and motivated reasoning, but I think it's like a lot of things arbcom-related - everyone gets it wrong sometimes, but we don't all get it wrong the same way all at once very often. Opabinia regalis (talk) 07:15, 9 April 2019 (UTC)
- I also support the suggestion for a mass-message to be sent out to administrators to inform them about this change to WP:RETURN once it has been implemented. The issue of compromised admin accounts should be taken more seriously by the committee and the community-at-large. I think these changes also leave the door open to future amendments and improvements to address a wider number of issues should they arise. Mkdw talk 16:00, 9 April 2019 (UTC)
- Oppose
- Abstain/Recuse
- I'm going to abstain on this, although I support it in principle. I have to point out that although we can confirm some information about an editor's Wikipedia password and their use of 2FA, we have no way of actually confirming whether someone had a unique, strong password for their Wikipedia-associated email address, if they reused their password on other sites, and how the compromise occurred. At best all we have is the editor's word and (particularly with the last point) our best guess. I'm not sure it's fair for us to enshrine those points in policy as reasons not to return someone's permissions when we have no way of confirming the information. ♠PMC♠ (talk) 17:29, 8 April 2019 (UTC)
- Arbitrator comments/discussion
- I'm in favour of making clear moving forward that compromised accounts will not automatically have the admin tools restored. Where I am unsure is if this is the procedure we wish to adopt, as it amounts to us asking (as we have done in this case): "Did you have a strong and unique password?" and the admin saying (as they have done in this case) "Yes". But in this case, despite assurances that the password was strong and unique, the admin account was still compromised, which is why we have taken a long time to even get as far as this on-Wiki discussion, why we are insisting on 2FA, and why Joe is opposing a resysopping. I'm not sure a simple assertion that "Yes of course my password was safe" is quite enough, because if someone's admin account became compromised there was a flaw somewhere in that user's security which they didn't know about, and are possibly still not aware of. I think the procedure should be that if an admin's account was compromised and they didn't have 2FA, then they need to enable 2FA to get the tools back. SilkTork (talk) 17:34, 8 April 2019 (UTC)
- I have to strongly disagree with the premise that all we can do is ask the admin. Here, the WMF made a public statement in which they noted that the password was likely reused due to specific, credible information. We can ask the WMF for similar information in any future cases of a compromise and base our decision on that information as well as what the admin tells us. If an account is compromised on the first try and there is no indication of any type of attack perpetrated through Wikipedia itself (e.g. with site JS on smaller wikis), it's fairly clear it was from a reused password, phishing, or a keylogger. ~ Rob13Talk 17:56, 8 April 2019 (UTC)
Discussion and comments (Necrothesp)
I don't wish to beat up on this particualr admin (since that's already been done to the point where I'm sure the message has been received) but I would urge the committee to go with version 2, and to consider it a sort of final warning that admins are expected to secure their accounts and ignorance of the last 5-6 years (at least) of evolving policy on this matter is no excuse as we expect admins to be up to speed on important policies. And reports about this hae been in the monthly admin newsletter how many times now? I've lost count. Kinda a big part of the job, and if you can't be bothered to keep up you should be big enough to hand in the tools. Beeblebrox (talk) 01:18, 8 April 2019 (UTC)
- Should this pass, I hope that a MassMessage will be sent to all admins, active or not (and signed "On behalf of the Arbitration Committee" so they don't think it's just a newsletter that can be ignored). --Rschen7754 05:20, 8 April 2019 (UTC)
- @Rschen7754: We can certainly do that. ~ Rob13Talk 05:42, 8 April 2019 (UTC)
- @BU Rob13 and Rschen7754: would you want this for all users that are currently admins, or also those that are not currently admins but may be eligible for re-sysoping? --DannyS712 (talk) 06:00, 8 April 2019 (UTC)
- @Rschen7754: We can certainly do that. ~ Rob13Talk 05:42, 8 April 2019 (UTC)
- Likewise, although I'm sympathetic to both the optics and voting implications of splitting version 2 into two separate motions. ~ Amory (u • t • c) 10:16, 8 April 2019 (UTC)
- Don't the current policy wordings leave discretion with the bureaucrats and not mention ArbCom? EdChem (talk) 13:48, 8 April 2019 (UTC)
- We are dealing in this motion with scenarios where there is a removal due to a security breach. The policy wording you mention was added to deal with security concerns that arise in passing after an administrator requests restoration of rights removed due to inactivity. In the latter scenario, the bureaucrats are the first assessors of the security issues. In the former scenario, ArbCom deals with the security issues and votes to reinstate where it knows the issues are resolved. It would not make sense for the bureaucrats to duplicate ArbCom's work in cases of compromised accounts. This illustrates an issue with some language at WP:ADMIN: we keep adding sentences to deal with edge cases that then mislead readers, through the illusion of comprehensiveness, when a different edge case arises. AGK ■ 14:05, 8 April 2019 (UTC)
- AGK, I am aware that ArbCom can and does desysop for security reasons, it is the reason that I was surprised by the wording. WP:SECUREADMIN states that "[d]iscretion on resysopping temporarily desysopped administrators is left to bureaucrats," which appears to me to empower bureaucrats to duplicate ArbCom work and even resysop after a Level 1 desysop unilaterally provided the 'crat is convinced security issues are addressed so long as a leel 1 desysop can be placed into the "temporary" camp. Wikipedia:User account security#Privileged editors states that
Administrators, bureaucrats, checkusers, stewards and oversighters discovered to have weak passwords, or to have had their accounts compromised by a malicious person, may have their accounts blocked and their privileges removed on grounds of site security. In certain circumstances, the revocation of privileges may be permanent. Discretion on resysopping temporarily desysopped administrators is left to the bureaucrats, provided they can determine that the administrator is back in control of the previously compromised account.
This mentions nothing about ArbCom. It asserts desysopping or other rights revocations may be permanent under "certain circumstances," but gives no clue as to what those might be, nor does it define who makes the decision. For sysop permissions, the discretion could be argued to be held only by the 'crats. - I agree with you that duplication is unhelpful, and that in practice ArbCom has the decision-making role... but I am surprised to see nothing in policy that supports that this is the case. I know that ArbCom gets to design its own procedures but cannot make policy. Arguably, above attempts to codify the desysopping being permanent falls into the former case rather than the latter, but that argument becomes much weaker when the policy basis for security breaches leading to permanent action is vague, does not mention ArbCom, and (I suspect) may not have been subject to community endorsement as policy. It may come from WMF actions / directions, but then that should be explicitly stated. Before codifying procedures, the basis for ArbCom authority should be clearly found in policy that is WMF mandated and / or community endorsed. I get that there is something about this particular case and the mishandling of security that has ArbCom annoyed. Perhaps it is a particularly egregious case, or just the latest in a series of cases that should never have arisen. Privacy concerns mean that can't be disclosed in detail, but those motivations don't justify acting as if policy support for ArbCom's authority in this area is clear when the policy documentation does not bear that out. The language on removals becoming permanent goes back at least a decade, so perhaps merely codifying that the decision-maker is ArbCom is needed, along with clarifying when bureaucrats can exercise the discretion that they have under the policy? EdChem (talk) 14:52, 8 April 2019 (UTC)
- I think the functional part here though is that since the removal was authorized under WP:LEVEL1 the return is only authorized under WP:RETURN. That is, as ArbCom has explicitly removed the permission, only ArbCom may explicitly return it. If the user group is not returned by ArbCom, WP:RfA still exists. WP:SECUREADMIN seems to specifically refer to things such as password requirements; if WMF ever did one of the promised audits, they could presumably pass that on to bureaucrats for action. ~ Amory (u • t • c) 15:08, 8 April 2019 (UTC)
- Our authority to act here is solid. There are several ancillary policies and procedures we could cite (see above), but ultimately it comes down to the fact that WP:ARBPOL gives ArbCom the responsibility for removing the admin permissions. It necessarily follows that we can decide if/when to give back bits we remove, and impose conditions (analogous to topic bans imposed by individual admins as unblock conditions). It would be helpful to amend WP:SECUREADMIN to note that this eventuality exists. – Joe (talk) 18:29, 8 April 2019 (UTC)
- AGK, I am aware that ArbCom can and does desysop for security reasons, it is the reason that I was surprised by the wording. WP:SECUREADMIN states that "[d]iscretion on resysopping temporarily desysopped administrators is left to bureaucrats," which appears to me to empower bureaucrats to duplicate ArbCom work and even resysop after a Level 1 desysop unilaterally provided the 'crat is convinced security issues are addressed so long as a leel 1 desysop can be placed into the "temporary" camp. Wikipedia:User account security#Privileged editors states that
- Please keep in mind that there is no mechanism available to stewards or bureaucrats to validate if a user has enabled 2FA, nor do they have a mechanism that can be used to determine if 2FA is deactivated at a future time. (WMF staff and certain developers can access this user-level data only). There is some consideration for building this functionality (see phab:T209749) however the last notes from the foundation suggest it is unlikely to be made available to project volunteers. To this end, I don't think ArbCom should be creating a user restriction ("account X requires 2FA") that has no mechanism to validate or audit, thus no means to enforce. — xaosflux Talk 14:30, 8 April 2019 (UTC)
- @Xaosflux: This specific concern was discussed quite a bit internally. We can get this data from the WMF, and have in the past. ~ Rob13Talk 15:14, 8 April 2019 (UTC)
- @BU Rob13: thanks for the note. From my reading of the first proposals above, once enacted this motion completes correct? That is, ArbCom is not creating a continuing requirement that this specific user must maintain 2FA as an ongoing condition of maintaining their administrator access correct? — xaosflux Talk 15:54, 8 April 2019 (UTC)
- For the second proposal, it seems to be missing a few things: (1) Under what authority is ArbCom creating a new account restriction, (2) What are the mechanics for enforcement? — xaosflux Talk 15:56, 8 April 2019 (UTC)
- I am not the best person to address the first question as a broad question, because I raised the same concern myself at one point and am not fully satisfied with the answer. Having said that, Necrothesp has noted privately to the Committee that he is willing to enable 2FA going forward. I would say our authority in this case is consent of the editor. In terms of enforcement, theoretically, the Arbitration Committee can request a list of editors with 2FA enabled from the Foundation. We've been provided with such information as it relates to the functionary team in the past. As a practical matter, I am more than happy to AGF that Necrothesp wouldn't blatantly lie to us about enabling 2FA and keeping it enabled. ~ Rob13Talk 18:02, 8 April 2019 (UTC)
- We already have a password strength policy that is supposed to be binding on all admins, it has just never been enforced even one single time. And now there is also a global policy. We asked the WMF for password auditing in 2015 but as far as I kno wthat's never been done either, but I seem to recall seeing somewhere recently that that is close to being a reality as well. Beeblebrox (talk) 17:34, 8 April 2019 (UTC)
- Discussed at phab:T121186, the "regular audits" and "password strength bar" have, obviously, not been implemented. ~ Amory (u • t • c) 17:50, 8 April 2019 (UTC)
- @Xaosflux: This specific concern was discussed quite a bit internally. We can get this data from the WMF, and have in the past. ~ Rob13Talk 15:14, 8 April 2019 (UTC)
- In Version 3 by AGK et al. the unchanged text from the current policy at WP:RETURN appears to proscribe a case if ArbCom doesn't return the perms, is that a fair assessment? Would it be worth indicating that a case is not required in all cases (such as this), perhaps simply by changing shall be opened to may be opened? ~ Amory (u • t • c) 15:26, 8 April 2019 (UTC)
- Given the typically private nature of discussions regarding an individual account's security, I would argue we're already opening "normal arbitration proceedings" when an account is compromised by seeking evidence regarding the account's security privately. The normal proceedings in such a situation would be a private case, not a public one. I would consider the new language on our procedures for compromised accounts as descriptive of "normal arbitration proceedings" in that situation. ~ Rob13Talk 18:06, 8 April 2019 (UTC)
- Please note that Necrothesp has enabled 2FA on his account. See here. Thank you for taking that step. ~ Rob13Talk 18:57, 8 April 2019 (UTC)
- I've been informed that log is noting he got oauth-tester, which allows him to enable 2FA. Either way, thanks for taking a step toward 2FA. ~ Rob13Talk 19:01, 8 April 2019 (UTC)