Community Wishlist Survey 2017/Admins and stewards

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Community Wishlist Survey 2017
Admins and stewards
13 proposals, 241 contributors



Extend global blocks to named accounts

Edit proposal/discussion
  • 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]

  • The reason why global blocking for named accounts does not exist is because it has no advantages over global locking. That's because almost all global locks are for troublemakers that aren't usually worth a second chance, such as spammers, LTA sockpuppets, globally banned users and the like. I also don't think that block evasion is usually tolerated. Everything else you are pointing out here seems like a policy question especially since you were in fact unlocked. Jo-Jo Eumerus (talk, contributions) 17:27, 9 November 2017 (UTC)Reply[reply]
    The one benefit would be a global autoblock of the IP(s), saving us a couple of seconds running CheckUser on loginwiki (and being more effective than that). – Ajraddatz (talk) 17:30, 9 November 2017 (UTC)Reply[reply]
    phab:T19929 seems like a task for making autoblocks be triggered by locking, although it's apparently not so simple? Jo-Jo Eumerus (talk, contributions) 19:29, 9 November 2017 (UTC)Reply[reply]
    It's an absolute nightmare. An autoblock feature would need to be purpose built for global account blocking anyway, so it could be easier to just include it with locking instead. I think that's what past me was thinking anyway :P – Ajraddatz (talk) 20:45, 9 November 2017 (UTC)Reply[reply]
  • phab:T17294. MER-C (talk) 04:00, 13 November 2017 (UTC)Reply[reply]

Voting[edit]

2FA and Huggle

Edit proposal/discussion
  • 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[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[reply]

Bot passwords? Raystorm (talk) 18:50, 27 November 2017 (UTC)Reply[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[reply]

Voting[edit]

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

Edit proposal/discussion
  • 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]

  • good idea. maybe add a possibility to block only specific namespace. For example block the main namespace but not draft namespace. - yona B. (D) 13:26, 15 November 2017 (UTC)Reply[reply]
  • For some of my research into blocking tools, I've found several other requests for similar functionality to add extra levels of granularity into blocking tools. Here's a list of what I've found so far. I think this would be a very beneficial feature to explore/build. We'll need to decide how all of this is logged and stored appropriately. — Trevor Bolliger, WMF Product Manager 🗨 18:56, 15 November 2017 (UTC)Reply[reply]
  • We Steward often have problems with abusive uploads by accounts in specific ranges, for example filesharing on Wikimedia Commons through Wikipedia Zero. If we could disallow uploads for IPs or IP ranges, that would help a lot.
  • Further, we have trolls which only create abusive user names but rarely edit. At the moment, we can only full-block ranges when it would be more useful to only disallow account creations while users could still edit. Can you add that to this proposal, should I ask at #Specialised blocks, or should I create another proposal, Man77? —DerHexer (Talk) 13:12, 18 November 2017 (UTC)Reply[reply]
    • DerHexer: Please feel free to add further options to the list above, if you think it fits in here. For my part, I think that IP range block options could also be dealt with separately. However, the better strategy could also be not to atomize the proposals in order to get all the votes her ;) → «« Man77 »» [de] 14:00, 18 November 2017 (UTC)Reply[reply]
      • I tried to make the change as little as possible. Are you okay with that? Best, —DerHexer (Talk) 11:34, 19 November 2017 (UTC)Reply[reply]
  • The Community Tech team would like to merge this and Community Wishlist Survey 2017/Admins and stewards/Specialised blocks. Are you fine with us doing that? /Johan (WMF) (talk) 17:47, 20 November 2017 (UTC)Reply[reply]
  • Endorse I really don't want Wikimedia Commons to miss good quality images because a user misbehaves outside of uploading such as here. And for Wikipedia's this would be largely beneficial for the encyclopedia as most of the time content creators get banned not for bad edits in the mainspace but for insults and hot-headed debates in talk pages. --Donald Trung (Talk 🤳🏻) 09:20, 24 November 2017 (UTC)Reply[reply]
  • Also with this idea 💡 topic bans and interaction bans can finally be enforced. --Donald Trung (Talk 🤳🏻) 09:21, 24 November 2017 (UTC)Reply[reply]
  • I think that you can do this all using the abuse filter (called as edit filter somewhere), though it's not so easy for non technical users. Stryn (talk) 19:02, 27 November 2017 (UTC)Reply[reply]
  • Can the reverse of this happen? For example, X is blocked due to BLP issues, but their edits on dinosaurs are sound. So in other words, can X be blocked from editing all articles in Category:Living people, but edit other articles? Lugnuts (talk) 18:44, 4 December 2017 (UTC)Reply[reply]
  • Hello all — This item did not make the Top 10 for the 2017 Wishlist, but the Wikimedia Foundation's Anti-Harassment Tools team is already looking into building better blocking tools in early 2018. Support for this proposal and the comments are already being taken into account. Read more and participate in the discussion at Community health initiative/Blocking tools and improvements. Thank you, and I hope to see you there! — Trevor Bolliger, WMF Product Manager 🗨 23:07, 14 December 2017 (UTC)Reply[reply]

Voting[edit]

U2F support for 2FA

Edit proposal/discussion
  • 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[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[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[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[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[reply]

Voting[edit]

  • Support Support Tgr (talk) 05:48, 28 November 2017 (UTC)Reply[reply]
  • Oppose Oppose Many good password managers are available for free, like PasswordSafe or LastPass, and they can create unlimited number of passwords of any length. For instance, I connect to Wikimedia projects with a 24-character password, composed of lowercase letters, uppercase letters, numbers, and non-alphanumeric characters. Don't ask me what it is, only my browsers and my password manager do. If you try to log in to my account, you will need to solve CAPTCHAs after some failed attempts. LoginNotify runs on all projects. You can only read Wikimedia projects using w:HSTS and w:HTTPS. All exchanges are done using "PKCS #1 SHA-256 With RSA Encryption". If you ever have a chance to read on w:Kevin Mitnick and social engineering, you will learn that the weak point in security is the human, very seldom the machine. For these reasons, we don't need further connection protection, but users must use a good password manager. U2F cannot correct erratic or weak human behavior. Cantons-de-l'Est (talk) 12:37, 28 November 2017 (UTC)Reply[reply]
    • (One of) the points of U2F is that your credentials are tied to a specific origin (domain). Thus it intends to reduce social engineering attacks like you describe above, as the human is no longer responsible for determining if the site in question is actually Wikipedia or not. Thus I don't think this oppose makes sense. BWolff (WMF) (talk) 22:07, 28 November 2017 (UTC)Reply[reply]
  • Oppose Oppose per above, SHA-256 is too long for external users who hates English to understand. --Liuxinyu970226 (talk) 12:43, 28 November 2017 (UTC)Reply[reply]
    • This definitely doesn't make sense, as users of U2F don't have to know anything about SHA-256 to use it. In the same way visiting this page doesn't require you to understand SHA-256 despite the fact your web browser has to in order to connect to Wikipedia (depending on cipher selection for TLS). BWolff (WMF) (talk) 22:07, 28 November 2017 (UTC)Reply[reply]
  • Support Support Combining something you know with something you have is a very well established security practice that stops a large number of attacks. It is true that users must still choose strong passwords and keep them safe, and that they should be encouraged to use password managers. But saying that 2FA is redundant once the users are doing the above is at best a gross underestimation of the security problems involved if not a sign of incompetence. I'm sorry if I sound rude, but this is exactly an example of how the human link is indeed the weakest one: when humans rely too much on certain technology, be it HTTPS, password strength or something else. This is also connected with one more reason why 2FA is very much desirable— the multi-layer approach to security, which is another basic security principle. HTTPS, HSTS and everything else (including U2F, for that matter) can and will fail one day. But when you have multiple layers of protection, the probability that all of them will fail at the same time is much lower. Therefore, I strongly endorse the U2F support, although I'm not sure why there's a separate suggestion, as U2F is already mentioned in Make 2FA easier to use. — Luchesar • T/C 20:48, 28 November 2017 (UTC)Reply[reply]
  • Support Support Thomas Obermair 4 (talk) 21:35, 28 November 2017 (UTC)Reply[reply]
  • Support Support 𝔊 (Gradzeichen Diſk✉Talk) 06:45, 29 November 2017 (UTC)Reply[reply]
  • Support Support I'd love to have this as an option for those who'd want to use it. —TheDJ (talk • contribs) 10:01, 29 November 2017 (UTC)Reply[reply]
  • Oppose Oppose if it's meant as a forced choice; neutral if an option. --g (talk) 00:16, 30 November 2017 (UTC)Reply[reply]
    • 2FA is an option as of now and I don't think it will be forced anyway for now. — regards, Revi 06:15, 30 November 2017 (UTC)Reply[reply]
  • Support Support Yes. Please. That oppose reasons doesn't make sense. That password manager oppose doesn't make sense as per BWolff. — regards, Revi 06:15, 30 November 2017 (UTC)Reply[reply]
  • Oppose Oppose Who will provide/handle/maintain the list of compatible hardware devices? Who will grant that all admins in all countries may have easy access to buy those devices (think about commercial restrictions, restrictive local laws on security devices and so on)? Did you consider that a "cheap 15US$" may sound not so "cheap" in many countries of the world (in Bangladesh, the average wage is 17US$ per month, so your "cheap 15US$" would mean "one month of salary" for them)? "Forcing" this device may discourage users in such conditions to candidate for adminships or other "sensitive" roles. And yes, I see that this goes "against" the mantra "we need more admin, we need to encourage admin candidatures": it introduces a physical and economical barreer: unnecessary, not in the spirit of a "Free Encyclopedia". Especially considering that 2FA is already there, for free, for all. --L736Etell me 07:48, 30 November 2017 (UTC)Reply[reply]
  • Support Support Winston Spencer (talk) 13:11, 30 November 2017 (UTC)Reply[reply]
  • Support Support WQL (talk) 09:51, 1 December 2017 (UTC)Reply[reply]
  • Support Support Eug (talk) 11:58, 1 December 2017 (UTC)Reply[reply]
  • Support Support Jacob Robertson (talk) 13:58, 1 December 2017 (UTC)Reply[reply]
  • Support Support Terra ❤ (talk) 06:39, 2 December 2017 (UTC)Reply[reply]
  • Support Support Emir of Wikipedia (talk) 15:41, 2 December 2017 (UTC)Reply[reply]
  • Support Support, and those opposes based on a misunderstanding that U2F would be a forced replacement for the existing 2FA need to be disregarded. Boing! said Zebedee (talk) 21:32, 2 December 2017 (UTC)Reply[reply]
  • Support Support This definitely should be as an alternative to OATH for those who don't have a hardware device, but U2F should definitely be an option for those of us who do. [stwalkerster|talk] 22:42, 2 December 2017 (UTC)Reply[reply]
  • Support Support I don't see why the option should not exist: it's only if we were coercing people to implement this instead of 2FA that we'd have a problem, and that seems to be no part of the proposal Vanamonde93 (talk) 06:15, 3 December 2017 (UTC)Reply[reply]
  • Support Support Tiputini (talk) 07:13, 4 December 2017 (UTC)Reply[reply]
  • Support Support with low priority. I have no problem adding this as an option, but I have doubts about the number of users who would adopt this as a solution. Aervanath (talk) 00:26, 5 December 2017 (UTC)Reply[reply]
  • Support Support —Alvaro Molina (✉ - ✔) 01:35, 5 December 2017 (UTC)Reply[reply]
  • Support Support as an alternative method. the wub "?!" 00:30, 6 December 2017 (UTC)Reply[reply]
  • Support Support with low priority.. Yohannvt (talk) 11:56, 6 December 2017 (UTC)Reply[reply]
  • Support Support Zppix (talk) 14:19, 7 December 2017 (UTC)Reply[reply]
  • Support Support Ahm masum (talk) 21:13, 7 December 2017 (UTC)Reply[reply]
  • Oppose Oppose, probably too costly for very limited impact. I think quite few users would prefer U2F over 2FA, and on the other side having a U2F that would fit all users would be rather costly to develop. U2F imposes very significant limits (e.g. it relies on only two browsers, it might not be available in certain countries etc.) which probably make investment in it not that cost-efficient — NickK (talk) 20:32, 8 December 2017 (UTC)Reply[reply]
  • Support Support -- as optional of course NaBUru38 (talk) 22:34, 9 December 2017 (UTC)Reply[reply]

Allow protection of multiple pages (from the same Category)

Edit proposal/discussion
  • 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[reply]

Voting[edit]

  • Support Support David1010 (talk) 07:34, 28 November 2017 (UTC)Reply[reply]
  • Support Support --Liuxinyu970226 (talk) 12:42, 28 November 2017 (UTC)Reply[reply]
  • Oppose Oppose No nuke buttons in a collaborative environment, please. --TMg 12:53, 28 November 2017 (UTC)Reply[reply]
  • Oppose Oppose There is no reason to replace ban with bulk protection.--YFdyh000 (talk) 13:21, 28 November 2017 (UTC)Reply[reply]
  • Support Support although this would probably only be suited for Commons and Wikidata. Jc86035 (talk) 14:44, 28 November 2017 (UTC)Reply[reply]
  • Support Support Gripweed (talk) 21:27, 28 November 2017 (UTC)Reply[reply]
  • Support Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)Reply[reply]
  • Support Support Shizhao (talk) 02:48, 29 November 2017 (UTC)Reply[reply]
  • Oppose Oppose protection, just like block, is always an exceptional solution, better to suggest a cautious case-specific approach to these tools. --g (talk) 00:21, 30 November 2017 (UTC)Reply[reply]
  • Oppose Oppose "Bulk protection" may only make sense in case of "massive" trolling or vandalic operations made by several unregistered users all together at a time. Never faced this kind of issue so far. Categories may encompass hundreds of articles: this tool would potentially block any cooperative actions on large parts of the project in one shot. Too strong and too much against the "Free Encyclopedia" principle.--L736Etell me 07:40, 30 November 2017 (UTC)Reply[reply]
  • Support Support Laurel Lodged (talk) 19:39, 30 November 2017 (UTC)Reply[reply]
  • Support Support Daniel Case (talk) 00:33, 1 December 2017 (UTC)Reply[reply]
  • Oppose Oppose per g and L736E. --Superchilum(talk to me!) 16:11, 1 December 2017 (UTC)Reply[reply]
  • Oppose Oppose There is no reason for protecting a whole section of Wikipedia. -Theklan (talk) 18:31, 1 December 2017 (UTC)Reply[reply]
  • Oppose Oppose per g. Wostr (talk) 10:12, 2 December 2017 (UTC)Reply[reply]
  • Oppose Oppose ~Cybularny Speak? 12:09, 2 December 2017 (UTC)Reply[reply]
  • Oppose Oppose Ented (talk) 12:27, 2 December 2017 (UTC)Reply[reply]
  • Oppose Oppose Could be very dangerous if works also for subcategories. --Termininja (talk) 15:28, 2 December 2017 (UTC)Reply[reply]
  • Oppose Oppose per g. —Tacsipacsi (talk) 17:00, 2 December 2017 (UTC)Reply[reply]
  • Oppose Oppose Protecting an entire category would usually be massive overkill. And as categorization frequently changes, it might be impossible to undo once it's no longer needed. Boing! said Zebedee (talk) 21:37, 2 December 2017 (UTC)Reply[reply]
  • Support Support Ciao • Bestoernesto • ✉ 02:29, 4 December 2017 (UTC)Reply[reply]
  • Oppose Oppose overkill --OlEnglish (Talk) 06:18, 4 December 2017 (UTC)Reply[reply]
  • Oppose Oppose as is overkill - Instead of protecting every article in that category we can just block the idiot vandalising .... this way has worked for 10 years .... no need to change it now. –Davey2010Talk 15:19, 4 December 2017 (UTC)Reply[reply]
  • Support Support but with caution and after another admin has "signed it off" for want of a better term. Lugnuts (talk) 18:46, 4 December 2017 (UTC)Reply[reply]
  • Support Support Zppix (talk) 14:19, 7 December 2017 (UTC)Reply[reply]

Bring Special:Undelete to feature parity with live page histories

Edit proposal/discussion

Discussion[edit]

  • A tool [1]: Query deleted page history on zhwiki--Shizhao (talk) 02:37, 8 November 2017 (UTC)Reply[reply]
  • This would be so useful. TonyBallioni (talk) 23:29, 14 November 2017 (UTC)Reply[reply]
  • Agreed, the current Undelete page is so frustrating to use. Premeditated Chaos (talk) 23:31, 14 November 2017 (UTC)Reply[reply]
  • Yes, we definitely need this. I work a lot in this area, and the current limitations make it very time-consuming. This is one of the features that should have been available many years ago. DGG (talk) 01:15, 20 November 2017 (UTC)Reply[reply]
  • From the Community Tech team: This is a good proposal, as long as folks are aware that we'd probably take an iterative approach to this -- taking one piece at a time, and not necessarily doing all of the requested steps on this proposal. -- DannyH (WMF) (talk) 17:25, 20 November 2017 (UTC)Reply[reply]
    I think the deletion mechanism should be more similar to revdelete than current deletion, though it would need a non-trivial amount of software rewriting. --Vituzzu (talk) 14:41, 23 November 2017 (UTC)Reply[reply]

Voting[edit]

Merging files will include merging in file history too

Edit proposal/discussion
  • 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[reply]

Voting[edit]

Allow Special:Nuke to delete imported pages

Edit proposal/discussion
  • 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

Edit proposal/discussion
  • 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[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[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[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[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[reply]
    That could work. --Tgr (WMF) (talk) 22:46, 18 November 2017 (UTC)Reply[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[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[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[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[reply]

Voting[edit]

Create a global whitelist for global autoblocks

Edit proposal/discussion
  • 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[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[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[reply]
By not blocking entire subnets because they include "several open proxies"? --Tgr (WMF) (talk) 00:55, 17 November 2017 (UTC)Reply[reply]
Did you ever dealt with spambots floods or our loyal LTAs? --Vituzzu (talk) 10:07, 17 November 2017 (UTC)Reply[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[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[reply]

Voting[edit]

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

Edit proposal/discussion
  • 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[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[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[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[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[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[reply]
Renamed. --Tgr (talk) 19:31, 22 November 2017 (UTC)Reply[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[reply]

Voting[edit]