Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Admins and stewards

< Community Wishlist Survey 2017
Community Wishlist Survey 2017
Admins and stewards
13 proposals, 241 contributors



Extend global blocks to named accounts

  • Problem: Currently global locks are enforced as if they were de facto Global bans, this is despite the official policy stating “This list does not include accounts that have been globally locked on charges of cross wiki disruption, spamming, or vandalism. Such users are not globally banned, per se. If they create new accounts and are not disruptive with those accounts, they will not be locked again merely because it is discovered that they were previously globally locked.” Yet in reality they are enforced as global bans with Stewards locking them upon discovery and local admins of projects where there are no active blocks reverting the addition of educational content merely on the accusation of “lock evasion” (which doesn't exist) even if the content is wanted by the community, this inherently doesn't benefit any project. Although officially global locks 🛅 aren't global bans they unofficially are, and stewards also treat them as such. This can most recently been seen with Virajmishra who is globally banned all but in name, the same goes for Diegusjaimes who has requested an unlocking since July 27th, 2017 and still hasn't had their main account unlocked (as of November 8th, 2017), in fact they may believe that they’re globally banned.

Also note 📝 that global locks have always been meant to be a temporary measure until global blocking to named accounts would be implemented, however after (I think) around seven years this still hasn't been enabled.

  • Who would benefit: The communities, as wiki’s would be given local autonomy, the globally “banned” users (“owners” of locked accounts), and probably the Stewards too because then they won't have to deal with unlock requests.
  • Proposed solution: Extend the global blocking tool to named accounts, this would generally be used how global locks are done now, global locking would still be the preferred method for malicious bots (such as spam bots) and accounts with malicious usernames, but all other named accounts would then be automatically blocked on every new Wikimedia project they attempt to edit in, generally talk page access should be allowed unless abuse has proven too severe, then the user should be advised to kindly request talk page access (on wiki's where this hasn't been locally revoked) for wiki’s where the block reason is “Steward Global block-account”. Of course as one can see with my example a certain local admin doesn't want me to edit Dutch Wikipedia regardless of what positive contributions I could do there, so community discussion should be advised for local unblocking or an assumption of good faith where a chance should be given before bad faith is assumed, or that global block appeals should show the intent of what they would do locally rather than appeal based on the behaviour of other wiki’s. After the user has sufficiently proven that they’re not an immediate menace to the projects where they haven’t been blocked as a “Stewardblock-account”, then they could request a global unblock that doesn't override local blocks.

In this scenario User:Example is blocked on German Wikipedia locally and blocked on the German Wiktionary as a global block, if a steward removes their global block the block on German Wikipedia would stand but for the German Wiktionary would be lifted.

  • More comments: The global locking of Graaf Statler prior to their Foundation ban was unnecessary, and the Stewards shouldn't have locked him again after he edited as a good faith user on projects where he wasn't locally blocked, for this reason a global lock 🔒 has proven to be a de facto global ban.

Discussion

edit

Voting

edit

2FA and Huggle

  • Problem: Admins with two-factor authentication (2FA) cannot use Huggle. In wikis with a small number of admins this is a big issue - it means choosing between being very effective doing maintainance or securing admin accounts. A two-velocity system of admins develops, where those who use Huggle end up doing most of the work and others can't keep up.
  • Who would benefit: All admins in projects where Huggle is enabled.
  • Proposed solution: Make 2FA compatible with Huggle.
  • More comments:

Discussion

edit

I'd rather characterize this as "make Huggle support BotPasswords or OAuth". Max Semenik (talk) 19:34, 14 November 2017 (UTC)[reply]

Bot passwords do not require any dedicated support; they are just passwords. You should be able to use Huggle with a bot password even if you have 2FA. --Tgr (WMF) (talk) 00:37, 17 November 2017 (UTC)[reply]

Bot passwords? Raystorm (talk) 18:50, 27 November 2017 (UTC)[reply]
mw:Manual:Bot passwords. In short, an alternate password to log into your account via the API with limited user rights. Anomie (talk) 14:49, 28 November 2017 (UTC)[reply]

Voting

edit

Allow further user block options ("can edit XY" etc.)

  • Problem: Admins can only block users from editing any page at all (the one exception being that user's talk page). If a blocked user is given the right to edit on a specific page or specific pages, the block still has to be lifted completely. This could be confusing, as the community has still decided to block them from other pages.
  • Who would benefit: Administrators and blocked users.
  • Proposed solution: Create options for users to edit pages to appeal the block, edit or not edit certain pages or namespaces, or do certain actions such as registering an account, use email or upload files.
  • More comments:

Discussion

edit

Voting

edit

U2F support for 2FA

  • Problem: Admins and people with higher rights constantly are under attack by hackers trying to guess or steal their passwords. Having two-factor authentication (2FA) protects against this, but it is vulnerable to phishing and hacking of mobile phones, and confusing for some non-technical users.
  • Who would benefit: Admins/Checkusers/People who have access to sensitive data and all other people whose data they have access to
  • Proposed solution: Enable Universal 2nd Factor (U2F) support for Wikimedia projects. U2F is a more modern 2FA mechanism with several advantages:
    • it's self-contained, no need to install any software - just plug it into an USB slot / touch it to your phone and it works;
    • it is hardware-based, thus unhackable (the secret key never leaves the device and there is no way to tamper with the software);
    • keys are bound to the website domain so it is immune to phishing.
  • More comments:

Discussion

edit

I expanded the description; feel free to change or revert. --Tgr (talk) 08:07, 20 November 2017 (UTC)[reply]

One of the biggest downsides to U2F compared to 2FA is the need for dedicated hardware. Most people have mobile phones to install authenticators on, whereas people may not have the hardware required for this. Some staff use YubiKeys. Is specialised hardware required, or could one theoretically use a generic USB stick? I'm wondering if this wish could be coupled with an initiative to distribute the relevant hardware to people. If preconfigured devices were brought by staff to public Wikimedia events (hackathons, Wikimania, etc.) then the only added costs would be staff time to set up the devices and the cost of small-capacity USB sticks. (This is just an idle thought I had, I have no control over any budget to do this.) --Dan Garry, Wikimedia Foundation (talk) 15:09, 20 November 2017 (UTC)[reply]

@Deskana (WMF): Custom hardware is required. Part of the security guarantee of U2F is that your secret keys never leave the device so all the encryption, certificate verification etc. has to be done by the firmware. Cheap options are around $15 (U2F Zero is $9 but very barebones). High-end ones are $50-ish. I don't think they require any setup typically (Yubikey definitely doesn't; it supports a bunch of other authentication methods, like the OTP-based one used for WMF VPN access, and that requires some configuration, but the U2F functionality works out of the box). --Tgr (talk) 05:47, 28 November 2017 (UTC)[reply]
  • I believe this proposal should clarify that U2F support is going to supplement, not replace the currently existing 2FA mechanism (which may as well be made more user-friendly, but that's the topic of Make 2FA easier to use). It is my impression that people like L736E vote against the proposal based on the (I believe) wrong assumption that U2F will be the only supported 2FA method. Amir, Tgr?
    — Luchesar • T/C 17:19, 1 December 2017 (UTC)[reply]
    That's correct. What this proposal wants is to make it add the support, people can choose between these two options. Amir (talk) 23:50, 1 December 2017 (UTC)[reply]

Voting

edit

Allow protection of multiple pages (from the same Category)

  • Problem: Currently pages have to be protected one-by one. If there is a specific topic that is being vandalized or anything else to warrant protection, it would be nice if all the articles in that topic (or Category) could all be protected by one click.
  • Who would benefit: Administrators who need to protect various pages from the same topic by doing one at a time
  • Proposed solution: Add an option to allow administrators to be able to protect all pages from the same Category (or another criteria)
  • More comments:
  • Phabricator tickets:

Discussion

edit

English Wikipedia has a tool called Twinkle; a quick test shows that the "p-batch" option does the job for a category. עוד מישהו Od Mishehu 16:22, 7 November 2017 (UTC)[reply]

Voting

edit

Bring Special:Undelete to feature parity with live page histories

Discussion

edit

Voting

edit

Merging files will include merging in file history too

  • Problem:

Today if we use the merging function on two files (two page in file-namespace) the merge include only the history of the description but not the history of the file itself (file history change only when we use "Upload a new version of this file")

  • Who would benefit:

All users group who have the permission to merge (admins, bureaucrats)

  • Proposed solution:

two possibility:

    • using the merge existing today to include the file merging
    • creat a new tool to merge pages.
  • More comments:
  • Phabricator tickets:

Discussion

edit

Old image revisions are indexed by filename + timestamp so a merge would change links to old versions (and be generally a pain to implement as timestamps can conflict). Not a huge deal but this would be a lot easier to implement after phab:T28741 is fixed. --Tgr (WMF) (talk) 00:45, 17 November 2017 (UTC)[reply]

Voting

edit

Allow Special:Nuke to delete imported pages

  • Problem: Currently, Special:Nuke does not list imported pages, and therefore these cannot be nuked.
  • Who would benefit: Administrators and Bureaucrats
  • Proposed solution: Special:Nuke should be able to allow mass deletion of imported pages as well.
  • More comments: If an administrator and/or bureaucrat makes a mistake, and accidentally imports pages that they did not want to, it would be good if Special:Nuke could mass delete those pages, so that the administrator/bureaucrat does not have to delete them all manually.

Discussion

edit

Voting

edit

Make 2FA easier to use

  • Problem:

We've had Two-factor authentication enabled for admins (and other functionaries) for some time. But MediaWiki's implementation of 2FA is rather clumsy at the moment: the secret and the scratch codes are only shown once, which means a user cannot use multiple token-generating devices (unless the user sets them up all at the same time) and cannot change devices without disabling all existing devices and scratch codes. The common option to remember a device, so that future log-ins only require password but not an authenticator token, is also noticeably absent.

  • Who would benefit:

Everybody who wants to use two-factor authentication

  • Proposed solution:
    • Change the OATH interface to allow further devices to be added without revoking existing devices and scratch codes.
    • Add a "remember this device" option so that future logins from the same device requires only password.
  • More comments:

Discussion

edit
  • The latter point, that there is no 'remember' option, is the primary reason I don't use 2FA. I'd love to, but I switch between accounts too often for it to be useful. Samwalton9 (talk) 23:06, 9 November 2017 (UTC)[reply]
  • This would certainly be a useful change for 2FA. We should also require that users have an email attached to their account to use 2FA, and allow for 2FA to be removed from an account after confirming in an email rather than using the scratch codes. With that done, the extension could be more widely rolled out. – Ajraddatz (talk) 23:08, 9 November 2017 (UTC)[reply]
  • Provided that the account could be recovered by confirming ones password and receiving an email, I think this is fine. Strongly worded setup instructions to encourage the use of a committed identity would be a good idea from the outset. I would like to use 2FA, however I know many people don't, and it will of course be optional. A Den Jentyl Ettien Avel Dysklyver (talk) 14:57, 11 November 2017 (UTC)[reply]
  • Only showing 2FA keys once is a standard security feature. It means your 2FA identity cannot be compromised if the attacker gains temporary access to your account (steals your cookies or opens your preferences while you turn your back on your laptop). Changing that seems like a bad idea. Maybe we could allow multiple different keys (with notification emails and everything). For more modern 2FA methods like U2F that will be a requirement anyway.
    Remembering the device is less problematic but with 1-year login durations how much difference does it make? --Tgr (WMF) (talk) 00:53, 17 November 2017 (UTC)[reply]
    How about showing them again, as an elevated action, where you have to enter your existing 2FA again. —TheDJ (talk • contribs) 13:45, 18 November 2017 (UTC)[reply]
    That could work. --Tgr (WMF) (talk) 22:46, 18 November 2017 (UTC)[reply]
    We could also add it to password resets (if it isn't already). Some sites are already doing this. Github calls it sudo mode, Phabricator calls it high security mode. 😂 (talk) 07:52, 6 December 2017 (UTC)[reply]
    We do (for Special:ChangePassword, not Special:PasswordReset of course). Although there's no UI to indicate the "elevated" mode and no way to deactivate it besides waiting for it to expire in (by default) 5 minutes. On the code level, see AuthManager::securitySensitiveOperationStatus() (and also SpecialPage::getLoginSecurityLevel()/SpecialPage::checkLoginSecurityLevel()). Anomie (talk) 15:27, 6 December 2017 (UTC)[reply]
  • It's important to improve this, but I don't want to specify specific technical functionality -- one definite need is for easier account recovery. I've also been informed there is no way of setting up 2FA from a Mac interface. DGG (talk) 01:59, 20 November 2017 (UTC)[reply]
  • U2F support would indeed be very welcome, as I think it's going to be easier for many less technically inclined people (apart from the need for a physical key, of course). Overall, if several 2FA methods could be supported (including more than one of a type, e.g. registering two U2F keys), that would be ideal and—especially if plain backup codes are supported as well—would also automatically solve the problem with account recovery (besides committed identity, but that may again be too much for some people). The option to remember the device should also help to convince more people that 2FA isn't going to be an unbearable burden (and it's still going to be more secure than using no 2FA whatsoever).
    — Luchesar • T/C 20:24, 28 November 2017 (UTC)[reply]

Voting

edit

Create a global whitelist for global autoblocks

  • Problem:

Many subnets belonging to colo/hosting service are globally blocked in order to stop spam or per NOP. Several legit users/organisation may be affected if they use private VPN, private proxies which are caught by these blocks. Currently the only way to unblock a single IP is chunking the relevant rangeblock in 32-blocked prefix lenght blocks (for IPv4).

  • Who would benefit:

Legit users caught by proxyblock, stewards saving complains to give answers and administrative overhead in managing the block of many smaller subnets.

  • Proposed solution:

Allow a global whitelisting of IPs (or even ranges) included in a globally blocked subnet.

  • More comments:
  • Phabricator tickets:

Discussion

edit

Is Global IP block exemptions insufficient? Anomie (talk) 14:58, 9 November 2017 (UTC)[reply]

Nope, GIPBE is a big deal since it allows an user to edit from *any* blocked connection, also it obviously only works for registered users. --Vituzzu (talk) 10:49, 14 November 2017 (UTC)[reply]
Not at all, there are 900 wikis where it would be potentially needed. An example, I just got an email from a local US government which offers a free wifi service. The service uses a captive portal hosted in a colocation facility. Colocation subnet is blocked because it also hosts several open proxies. How would you solve this? --Vituzzu (talk) 10:49, 14 November 2017 (UTC)[reply]
By not blocking entire subnets because they include "several open proxies"? --Tgr (WMF) (talk) 00:55, 17 November 2017 (UTC)[reply]
Did you ever dealt with spambots floods or our loyal LTAs? --Vituzzu (talk) 10:07, 17 November 2017 (UTC)[reply]
Yes, although no doubt on a smaller scale than large wiki / crosswiki antiabuse people. My point (made in a flippant tone that was uncalled for; sorry about that) was that if a block is sweeping enough to include important institutions that we notice we don't want to block, then it's probably also going to include lots of "unimportant" well-intentioned users whom we won't notice. It would be better to think about improving block targeting instead of issuing wide blocks and whitelisting a lucky few. --Tgr (WMF) (talk) 06:34, 19 November 2017 (UTC)[reply]
Well, I made just an example, but most of complains are from single users, usually those using their own VPNs. Rangeblocks are not indiscriminate, I usually don't block transit while I usually block webhosting. Also, a significant percentage of users caught are actually affected by some fancy malware.
What I am proposing here is not meant to be a general purpose solution, but another tool to ease the handling of the big burden of crosswiki issues. A tool which would be, in my experience, the "cheapest" way to solve a variety of problems. --Vituzzu (talk) 20:51, 19 November 2017 (UTC)[reply]

Voting

edit

Make AbuseFilter easy to use for nontechnical admins by making filter editing more visual

  • Problem: AbuseFilter is very powerful and flexible. There are plenty of situations where it could be a more appropriate tool than blocking or page protection (see e.g. all the proposals about limited blocks of problem users), and can handle spammers and sockpuppeteers who can defeat all other tools. Unfortunately it was written by tech people for tech people. Most admins are effectively excluded from using it because it's presented like a programming language, even though its concept is not that difficult (simple statements using "and" and "or").
  • Who would benefit: Admins and the communities they work for.
  • Proposed solution: Make AbuseFilter intuitive and easy to use for everyone by
    • replacing (or, preferably, complementing) the programming-language-like interface with some kind of visual condition editor (Blockly would be one good candidate);
    • integrating a decent regex editor (good example: regex101);
    • merging the filter editing / creation interface and the filter testing interface: show what the filter would match as it's being edited.
  • More comments:
  • Phabricator tickets:

Discussion

edit

Tgr: Good proposal, but at the moment it's very broad – making the tool easier to use, and then a number of different things we could potentially do. I'm worried that if people vote for this, hope for something and the team then does some of the potential proposals but not what people were hoping for, they'll be disappointed. Could we narrow it down a bit, make it more specific? /Johan (WMF) (talk) 17:22, 20 November 2017 (UTC)[reply]

@Johan (WMF): do you mean changing the title to better match the three specific things proposed, or removing (splitting up? if that's OK to do past the proposal deadline) the proposed solutions so there is one technical task per proposal? Tgr (talk) 20:55, 20 November 2017 (UTC)[reply]

I think there could be a number of ways to go about that – either splitting it up, rephrasing it, or focusing more on specific solutions (e.g. "here are the things I think should be done" instead of "some potential solutions") or problems. Just so we don't end up in the situation where everyone who wants something done about the AbuseFilter think this is the task and then the Community Tech team ends up focusing on something else than they were hoping for. /Johan (WMF) (talk) 21:22, 20 November 2017 (UTC)[reply]
The "proposed solutions" section seems pretty specific to me: it lists the three things which IMO should be done - make a visual condition editor, integrate a regex visualisation/testing tool, live-update the list of matches as the filter is being edited (or at least make it easy to update them, without having to context-switch and copy-paste between the filter edit page and the filter test page). I only mentioned the specific technologies/tools I had in mind as examples because I haven't done the investigation needed to be sure they are viable. --Tgr (talk) 21:36, 20 November 2017 (UTC)[reply]
And the three features are interdependent (at least in my mind) - they visualize different aspects of the filter (logical structure, regular expressions, actual effect on edits) that a non-technical person would have a hard time understanding from the current interface. --Tgr (talk) 21:38, 20 November 2017 (UTC)[reply]
Tgr: Reading through this again, I'm wondering if I didn't read "situations" as "solutions" first. Mea culpa. But I think a more specific title would be a good idea. (: /Johan (WMF) (talk) 14:41, 22 November 2017 (UTC)[reply]
Renamed. --Tgr (talk) 19:31, 22 November 2017 (UTC)[reply]
I see the third feature as the critical one. If it's easy for non-technical people to edit abuse filters, it must be easy for them to see what their filters will do. For an example of what happens without this feedback, see the history of the Enwiki titleblacklist from around 2008, where a user without a good understanding of regex managed to do things like block all pagemoves to titles containing the letter "p", or block a randomly-selected quarter of all pagemoves. --Carnildo (talk) 23:58, 28 November 2017 (UTC)[reply]

Voting

edit

Implement delete and move warning for associated talk pages

  • Problem: When moving a page over another page (available only for sysops) the talk page is not moved if the talk page of the second page exists and an error message appears saying that the talk page was not moved. This results in talk pages often being 'left behind' at the old title.
  • Who would benefit: Administrators who move pages. Other editors and readers who wouldn't find missing/disjointed talk pages.
  • Proposed solution: The delete and move warning should be displayed another time (first time for the page itself, second time for the talk page) for the talk page making it possible to move the page and its talk page together.
  • More comments: This has been a bug since at least 2007.

Discussion

edit

Voting

edit

Automatic detection of admin candidates

  • Problem: There is a persistent shortage of admins. We need a better process for recruiting new admins.
  • Who would benefit: Everyone.
  • Proposed solution: More of less the reverse of an anti-vandal bot. Run a bot which examines editors' history: contributions, talk page activity, warnings, block logs, etc. etc., and use appropriate algorithms (to be determined) to detect accounts that might be potential good admins. (This might, for example, be a neural network trained on the contributions of current admins before they were made admins.) Make this list public, and send those accounts messages suggesting they put themselves forward for adminship.

    It's also possible that this automatic pre-review might also offer communities the possibility of shortening the current lengthy review/interview process for admin candidates selected this way.

  • More comments:
  • Phabricator tickets:

Discussion

edit

Voting

edit
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Admins_and_stewards&oldid=23947706"