Wikipedia:Arbitration/Requests/Motions
- recent changes
- purge this page
- view or discuss this template
Request name | Motions | Initiated | Votes |
---|---|---|---|
Covert canvassing and proxying in the Israel-Arab conflict topic area | 6 November 2024 | 0/5/0 |
Currently, no requests for clarification or amendment are open.
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
Motion adopted (Version 1) – bradv🍁 02:57, 10 April 2019 (UTC) |
---|
The following discussion has been closed. Please do not modify it. |
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)
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.
|
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.
Enacted – bradv🍁 14:50, 10 April 2019 (UTC)
- 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)