Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Anti-harassment

< Community Wishlist Survey 2017
Community Wishlist Survey 2017
Anti-harassment
3 proposals, 152 contributors



Per-page user blocking

  • Problem:

On EN wikipedia we go through four levels of warnings before we block vandals, but we have a hair trigger for blocking edit warrers. This is crazy, we rarely turn vandals in to useful editors (OK some come back when they've grown up) but almost all edit warrers are useful members of the community who just get over enthusiastic.

  • Who would benefit:

Everyone who gets into editing disputes, everyone who tries to resolve such disputes and those who wish we could resolve things without always first going to a block.

  • Proposed solution:

A new level of page protection - protect v named individuals. Admins would be able to resolve edit warring incidents by protecting the page where the edit war was taking place against editing by particular named accounts. This would need to be independent of whether the page was also under pending changes, semi protection or extended confirmed protection. Blocking would still be an option, but we would now have an option to resolve things with less grief.

The edit warrers would then be free to edit elsewhere.

This tool would also be useful for some cases where interaction bans apply.

  • More comments:
  • Phabricator tickets:

Discussion

edit

"almost all edit warrers are useful members of the community who just get over enthusiastic"

That doesn't make it ok. Edit wars are counterproductive, antagonistic, and stressful, and drive people away from editing. Needlessly aggressive behavior like edit warring should be heavily discouraged. — Omegatron (talk) 02:24, 11 November 2017 (UTC)[reply]
Agreed, and stopping people from editing that page would still be heavy discouragement. But why continue the current system where we deal much more harshly with edit warring than we do with vandalism? Even with this proposal most vandals get a warning on first, second, third and fourth offences, whilst an edit warrer would currently get a block on first offence and under this proposal instead of a series of four warnings would start with the page being protected against them with escalation to a block. Both edit warring and vandalism are wrong, why do you want us to treat edit warring so much more harshly? WereSpielChequers (talk) 09:46, 11 November 2017 (UTC)[reply]
WereSpielChequers, would it be okay if we retitled this proposal "Per-user page blocking"? It's not as eye-catching as "Edit Warring - a better solution", but it's a more neutral point of view. :) -- DannyH (WMF) (talk) 21:53, 13 November 2017 (UTC)[reply]
Hi Danny, how about "page protection v specified accounts" as I'm keen to have this considered a form of page protection rather than a type of user blocking. WereSpielChequers (talk) 22:20, 13 November 2017 (UTC)[reply]
I have encountered few Edit wars in my time on wikipedia, but I did encounter problematic editors who reverted my edits on sight. My usual reaction was to walk away because of the hassle involved in reporting edit-wars to the "authorities". If this proposal will simplify the process and not be prone to abuse, it may save a whole lot of cumulative editing time. Ottawahitech (talk) 14:29, 14 November 2017 (UTC) Please ping me[reply]
This Addition makes a lot of sense, while it may not be easy to implement. Anyhow, let's put it on the wishlist. --Bernd.Brincken (talk) 19:11, 14 November 2017 (UTC)[reply]
Definitely makes sense.--Ymblanter (talk) 20:15, 18 November 2017 (UTC)[reply]

This has already been proposed in the Admin section (which is probably a better place for protection/blocking proposals):

Those frame it as blocking, not protection, but it's essentially the same thing. --Tgr (WMF) (talk) 04:08, 19 November 2017 (UTC)[reply]

The three proposals are all slightly different.
Anomie (talk) 23:22, 19 November 2017 (UTC)[reply]
  • I think this is a coercive calm design that avoids excessive useless disputes that arise in the editing or discussion of a specific entry. This should not appear to young editors. This may be more suitable to an injunction policy, but apply a policy may be more controversial than the feature. It should not be long-term, just a few days/weeks to calm down and alert this to affect others. This does not apply if this is bound to cause disruption. 1/2 support, I suspect that this bring a problem, the parties may continue to see other people doing similar controversial edits and can not intervene, it brings a negative perception, unless also prevent the parties contact (including activity and view) the particular page.--YFdyh000 (talk) 09:01, 28 November 2017 (UTC)[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]

Voting

edit

Allow a second email address

 
The user can be protected from account creation on, without knowing about preferences.
  • Problem: The email address associated with a wiki user account gets exposed, if the user accepts wikimail and sends answers to received mail. This creates two risks: with the knowledge of the mail address a hacker can try to take over an account, and a stalker can get knowledge of the private email address of a user and then harrass this user outside of wikipedia.
For password recovery an address with a secure mail provider is a good choice. For wikimail on the other hand a throw-away-mail-address, that can be easily replaced, if it becomes known to a stalker or the public, makes more sense.
  • Who would benefit: every user of wikimail.
  • Proposed solution: Add the option to specify a second email address in the preferences for all users.
    Add the following global preferences (email and password are already global):
    • checkboxes to select what email address to use with wikimail or none at all
    • checkboxes to select what email address to use for password recovery or none at all
      • if both boxes are checked, different temporary passwords are sent to both addresses and both are needed to login
    • checkboxes to select what email address to use for echo and other notifications
    • in a more ambitious additional approach the local echo preferences could allow the configuration of every notification type to be sent onwiki, to first address, to second address
    In a given time frame only one email address can be changed. A confirm message is sent to the new address and additionally a "cancel the change" message is sent to the other unchanged address.
    The option of two addresses would allow the use of a throw-away-email-address for wikimail. So if this address becomes known to a stalker, you can simply change this address, while keeping your secret secure email address for all other uses.
  •  
    signup
  •  
    preferences page
  •  
    notfications preferences
  •  
    change a mail address
  •  
    change a mail address
  • More comments: Nothing changes for any user who does not specify an email address or stays with one address.
Last year's wishlist survey contained four proposals to address this type of problem. Among these, this proposal got the most votes. One of the other three has been adopted by the anti-harrasment team and is now being implemented. This proposal has in the meantime been added to the workboard of the anti-harrasment team as a topic of interest. The combined votes of last year's four proposals would have been enough to put it into the top ten.

Discussion

edit

For the records, https://phabricator.wikimedia.org/T129747#2777853 offers some concerns about the proposed approach. --AKlapper (WMF) (talk) 12:34, 7 November 2017 (UTC)[reply]

  • This seems like an overly complex solution, compared to just giving everyone their own temporary email alias every time a message is sent.. Nor am I a particular fan of the UX parts of this proposal. But if we reword the proposal to "Do more to avoid disclosing the email address of users", then I'm on board. —TheDJ (talk • contribs) 15:14, 7 November 2017 (UTC)[reply]
  • We could use Structured Discussions for private messaging. You would get a nice interface to follow threads, built-in customized messaging (including an option to not receive emails) and most of the code is already here. Max Semenik (talk) 19:49, 7 November 2017 (UTC)[reply]
    That proposal seems like a similar interface to what reddit currently does with private messages, which isn't crazy to me. --Izno (talk) 19:51, 7 November 2017 (UTC)[reply]
  • The no same domain thing doesn't seem like a good idea imo, since while it sounds good with personal domains, if you use something like gmail for example, then you have to create another account at another provider rather than just use another gmail account. --Terra ❤ (talk) 06:48, 9 November 2017 (UTC)[reply]
  • the basic idea of having a "Dysklyver@editor-en-wikipedia.org" email address to use instead of my normal email would be good, no comment on the general approach above though. I already reply via a different email account to the one which receives emails. A Den Jentyl Ettien Avel Dysklyver (talk) 16:32, 9 November 2017 (UTC)[reply]
  • I mean, although I do have an account without my name on it, I don't consider that insufficient protection, so every time I want to send a wikipedia email (except to a few people I trust), I have to go to a temporary disposable email site, get a temporary email, change my wikipedia email to that, send the email, then set my email back. It's a hassle and I seldom send emails because of that. Also the person can't auto-reply but has to send a separate email to me. A fix for this would be nice. Herostratus (talk) 05:41, 10 November 2017 (UTC)[reply]
  • The root problem is definitely an issue, would be good to fix it. Raystorm (talk) 17:18, 14 November 2017 (UTC)[reply]

@TBolliger (WMF): et al. incl. phab-discussion: I actually thought some time about retitling the proposal and decided against it for the simple reason, that I used this title last year and on phab, so it might confuse people, if I changed it. However the mockups are just that: A visualization to help people see what could be and start a discussion what should be. My intention is, that a good email address shall not be exposed. If this is picked up, the tech team is absolutly free to do two email addresses, or temporary addresses provided by wikipedia, or an internal message system that replaces wikimail, or anything else, if it addresses and solves the underlaying problem. I do not expect, that the implemented solution looks anything like my mockups. But I do hope that the proposal gets picked up by people. --𝔊 (Gradzeichen Diſk✉Talk) 17:53, 14 November 2017 (UTC)[reply]

  • OK, that's fair. I'm looking forward to seeing how people discuss this proposal, I think it's definitely a hole we should look into plugging. — Trevor Bolliger, WMF Product Manager 🗨 00:20, 15 November 2017 (UTC)[reply]
  • IMO 1) educating people about email security is a better investment (Google supports second factor via TOTP, U2F and all kinds of other things; if set up properly, an email account at a decent provider is hard to steal) 2) a simple workaround is to set up a mail filter to forward user mail to your secondary email account. Again educating people about that seems like an easier path. We should make sure the sender of wikimail and security mail is different, if we don't already. 3) there should be an Echo notification when you request a password reminder. (Not that useful now, will be a lot more useful when Echo gets push notification support.) --Tgr (WMF) (talk) 01:10, 17 November 2017 (UTC)[reply]
    • "Educating about security is better": You cannot educate people who do not want to be educated. Wiki authors are not tech people. German admins have publically protested against being forced to update their years-old 6-byte password to this terrible overlong 8-byte password. They are also alienated by the idea to have to carry a smartphone for 2FA with them, if they want to login to wikipedia in a public library. The reasoning is that "it's only wikipedia, not a bank account!" and "we have backups for the case of a security break." Authors come to Wikipedia, start editing, do not think about security/tech/bullies, and then are terrified, when they get harrassed, then leave this unfriendly project. It is still a good idea to offer 2FA to all, to nag users with more than 500 edits or "passiver Sichter" rights to use 2FA and to force admins, users with more than 1000 edits and "aktiver Sichter" to use 2FA. But still new users do not think about security. --𝔊 (Gradzeichen Diſk✉Talk) 17:27, 17 November 2017 (UTC)[reply]
      I'd imagine the people who dislike extra security measures and do not care much about their account being breached, and the people who worry about their email address leaking and would set a secondary email, to be disjunct groups. Sometimes you might want to force to some measure of security on people whether they want it or not, but this wish is not about that. --Tgr (WMF) (talk) 19:37, 17 November 2017 (UTC)[reply]
  • As the signup-mockup-picture drew some criticism: How about a signup-wizard, that asks for the username on the first page, the password on the second and so on? --𝔊 (Gradzeichen Diſk✉Talk) 20:51, 19 November 2017 (UTC)[reply]
  • The UI looks unwieldy. Asking for two email addresses on registration (even though both are optional) is a cognitive burden for editors registering a new account. Perhaps call the auxiliary "account recovery email" instead, and only gently prompt after a few days/edits. We can also have other account recovery options later on, because the problem is only one method of self-serve account recovery (e-mailing sysops doesn't count). --Kakurady (talk) 14:19, 29 November 2017 (UTC)[reply]
  •   Comment I support the Anti-Harassment team working on a suitable solution to this problem, but no, Community Tech resources are better spent elsewhere. MER-C (talk) 11:47, 4 December 2017 (UTC)[reply]
  • I have absolutely no advanced computer skills, but it seems to me that, in my online auction days, that my e-mails with the other side of the transaction went to a randomly generated e-mail address connected with the person's account (something on the order of random code@onlinecompany.com). Is that something that can be done on WP? -- Dolotta (talk) 17:33, 7 December 2017 (UTC)[reply]
  • Not sure if this is a good solution to the problem, or a solution at all. The problem is that you want a priority channel and a throw-away channel, now both are the same. I would propose that all interactions with other users goes on a separate thread, where some (all) interactions are private and anonymous by default. When a user writes a private message only a transcript is sent to the recipient, and both must agree on letting the thread be non-anonymous or non-private. (Yes this can be implemented as part of the Flow-system.) — Jeblad 22:45, 10 December 2017 (UTC)[reply]
  • As product manager for the WMF's Anti-Harassment Tools team I have created a project concept page at Community health initiative/Do more to avoid disclosing the email address of users to track this proposal. We have not prioritized developer time to work on this, but want to have our thoughts organized if we decide to do so. — Trevor Bolliger, WMF Product Manager 🗨 23:54, 13 December 2017 (UTC)[reply]

Voting

edit

Smart blocking

  • Problem: Our tools for blocking harassers, vandals and others are not as effective as they could be, there are loopholes that harassers and vandals exploit. So a harasser blocked on one IP address will move to another in the same range.
  • Who would benefit: Victims of harassment, vandalfighters, some goodfaith IP editors caught in blocks meant for others
  • Proposed solution: Implement and enable smart IP blocking of IP addresses and ranges of IP addresses. Smart blocks would use the checkuser info of a blockworthy edit and block other IP editors with the same checkuser info (user agent) in the same IP address or range.

    Smart blocks would be a new intermediate option between "soft" and "hard" blocks.

    More details at en:User:WereSpielChequers/IP and OS blocks

This would greatly reduce the collateral damage of blocking the wrong person when doing range blocks, though it wouldn't entirely prevent it as some user agents are very popular.

  • More comments: Note - this proposal would use checkuser info for a particular edit without the blocking admin knowing what that checkuser info was.
  • Phabricator tickets:

Unlike phab:T152462 smart blocks couldn't be circumvented by simply clearing cookies, so smart blocks could work alongside the cookie blocks proposed in phab:T152462.

Discussion

edit
  • @WereSpielChequers: Could you update the proposal with a TL;DR version of w:en:User:WereSpielChequers/IP and OS blocks? Sorry, I think I understand the problem, but not sure about the proposed solution. The part that stands out is the suggestion to use CheckUser data. Are you suggesting we go by the user agent to detect if an IP within the same range is the same person? The issue there I think is that some user agents are very, very popular (newest version of the browser, newest version of the OS). It would not always be a safe assumption to say two IPs in a given range are related (such as mobile IP ranges). I wonder if human review would be required to prevent collateral damage?

    Also, where you aware of phab:T152462? This would help the scenario you speak of, where you block one IP and the user refreshes their IP to another. It of course isn't foolproof because all they have to do is clear their cookies, but it would likely work for your every day vandal. MusikAnimal (WMF) (talk) 02:12, 21 November 2017 (UTC)[reply]

    Thanks MusikAnimal, I'm assuming harassers are a bit more sophisticated than adolescent vandals and sometimes we'd need a bit more than phab:T152462. But I've expanded the proposal to hopefully encompass your points. Yes I appreciate that some user agents are very popular and therefore this would reduce rather than prevent the collateral damage of blocking innocent third parties. But another way of thinking of this is that for a given amount of collateral damage we could now have a much more effective anti harassment block. WereSpielChequers (talk) 05:53, 21 November 2017 (UTC)[reply]
    @WereSpielChequers: Alright I think I understand -- You are looking to introduce a new autoblock system for IPs that goes only by user agent? So when blocking an IP, there will be a new option "Autoblock other IPs used by this editor that have the same browser and OS". Let's say I'm blocked with that option set. Now when I refresh my IP, I am autoblocked because the user agent matches. Is that correct? Is it meant to do this only for users within a specific range of the individual IP you blocked? How does it know what range to use? Perhaps /64 for IPv6 (which is often end-user), and something modest for IPv4, like /24 ?

    When blocking an actual range, everyone in that range is blocked then and there (collateral already happened). Perhaps we should do this: You go to block a range, you can select the smart block option, which will allow you to enter in a diff of the edit made by the IP you wanted to block. Now the system knows what range to target, and what user agent to go off of. The block would only affect IPs in that range that have the same user agent. That would put the chance of collateral in the hands of the admin (and not MediaWiki gone haywire), and indeed would be safer than a normal range block. How does that sound?

    Sorry if it seems like I'm giving you a hard time! I just want to make sure the proposal is clear so people know what they're voting on. See also phab:T172477 which I think would help here, and supersede phab:T152462. MusikAnimal (WMF) (talk) 22:02, 21 November 2017 (UTC)[reply]

    Yes, but because the collateral damage would be far less within the same range we could be a bit more flexible about blocking ranges where people keep coming back with harassment from different accounts or a range of IPs. WereSpielChequers (talk) 23:21, 26 November 2017 (UTC)[reply]
  • On the note of smart blocks is it possible for a similar thing to this but for browser fingerprints? Were if someone has a unique fingerprint on the site then it restricts or limits account creation somewhat. Cause if a user uses enough unique extensions it could make them identifiable and could help for tracing vandals. Of course a problem would be the chance that someone else tries to make an account who also has a really strange browser configuration within the time the temporary fingerprint block lasts for. -glove- (talk) 08:45, 9 December 2017 (UTC)[reply]
  • In this case I do see a problem, but I don't see a solution. I do see a pretty large loophole for wild goose hunts. And it seems like the proposal does not address various anonymous browsers, and browsers that can fake fingerprints. It is although possible to identify trolls given some identifiable features, where browser agents are extremely unreliable even if some people claim they are not, and then use that to try to fingerprint the user. This is a hard problem, but the only alternative to wild guesswork. Sorry, I have been in a lot of discussions about these kinds of tools and very few of them work. (The only thing that do work is to let the gain associated with an account be higher, and thus the cost of loosing the credentials be higher. There must be something to gain, and unless you have sufficient creds you should not be able to post on a user page, probably not even name another user.) — Jeblad 22:31, 10 December 2017 (UTC)[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 🗨 22:29, 15 December 2017 (UTC)[reply]

Voting

edit
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Anti-harassment&oldid=23947712"