Community Wishlist Survey 2017/Anti-harassment
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:
- Proposer: WereSpielChequers (talk) 19:53, 10 November 2017 (UTC)
- Translations: none yet
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)
- 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)
- 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)
- 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)
- 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
- 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)
- Definitely makes sense.--Ymblanter (talk) 20:15, 18 November 2017 (UTC)
This has already been proposed in the Admin section (which is probably a better place for protection/blocking proposals):
- Community Wishlist Survey 2017/Admins and stewards/Allow further user block options ("can edit XY" etc.)
- Community Wishlist Survey 2017/Admins and stewards/Specialised blocks
Those frame it as blocking, not protection, but it's essentially the same thing. --Tgr (WMF) (talk) 04:08, 19 November 2017 (UTC)
- The three proposals are all slightly different.
- This is proposing blocking a user from a specific page.
- Community Wishlist Survey 2017/Admins and stewards/Allow further user block options ("can edit XY" etc.) is proposing blocking a user for everything except specific pages, blocking a user for non-talk pages only, and blocking a user from email, upload, and/or account creation only without blocking editing.
- Community Wishlist Survey 2017/Admins and stewards/Specialised blocks is proposing many more fine-grained blocking options without the whitelist feature: blocking from certain namespaces, from email, from upload, from account creation, etc.
- Anomie (talk) 23:22, 19 November 2017 (UTC)
- 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)
- 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)
Voting
edit- Support —viciarg414 08:12, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:49, 28 November 2017 (UTC)
- Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 13:15, 28 November 2017 (UTC)
- Support Sadads (talk) 13:33, 28 November 2017 (UTC)
- Support Jc86035 (talk) 14:38, 28 November 2017 (UTC)
- Support--Ymblanter (talk) 16:22, 28 November 2017 (UTC)
- Support - Darwin Ahoy! 16:59, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:37, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:51, 29 November 2017 (UTC)
- Support –Ammarpad (talk) 06:50, 29 November 2017 (UTC)
- Oppose – this is excessive and unnecessary. Temporarily blocking editors that refuse to follow the rules of an article works fine. Natureium (talk) 19:07, 29 November 2017 (UTC)
- Support Nabla (talk) 19:20, 29 November 2017 (UTC)
- Support LakesideMiners (talk) 19:28, 29 November 2017 (UTC)
- Support Joshualouie711 (talk) 19:32, 29 November 2017 (UTC)
- Support Andrew (talk) 20:31, 29 November 2017 (UTC)
- Support MGChecker (talk) 22:01, 29 November 2017 (UTC)
- Support --g (talk) 00:27, 30 November 2017 (UTC)
- Support Daylen (talk) 01:16, 30 November 2017 (UTC)
- Oppose - My feeling is that there are better things for comm tech team to spend their time on, when there is a suitable alternatively (notably, full protection of problematic article, or if the problem is across multiple pages, blocking of the problematic user). --Izno (talk) 03:00, 30 November 2017 (UTC)
- Support Strong support. Why didn't we have this already? This could also help to enforce topic bans. I really don't understand the opposition.Mr. Guye (talk) 03:43, 30 November 2017 (UTC)
- Support Nihlus 04:59, 30 November 2017 (UTC)
- Support This would be a good and more efficient alternative to the usage of filters for selective page blocking. --L736Etell me 08:05, 30 November 2017 (UTC)
- Support I'd also like to dispute the two oppose rationales: Temporary blocking often causes the issues to reoccur as soon as blocks expire, or the user was being helpful on pages A and B but not pages C and D and then other users working on pages A and B complain. Full protection has too much collateral damage in many instances. Jo-Jo Eumerus (talk, contributions) 08:29, 30 November 2017 (UTC)
- Oppose per Izno. Unnecessary. --Vachovec1 (talk) 17:32, 30 November 2017 (UTC)
- Support I agree. Sometimes people just get a little overreactive. Tessaract2 (talk) 18:16, 30 November 2017 (UTC)
- Support Reception123 (talk) 19:30, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:47, 1 December 2017 (UTC)
- Support Ottawahitech (talk) 13:34, 1 December 2017 (UTC) Please ping me
- Support --Superchilum(talk to me!) 16:16, 1 December 2017 (UTC)
- Support Danii.3 (talk) 17:41, 1 December 2017 (UTC)
- Support Supuhstar (talk) 19:29, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:03, 1 December 2017 (UTC)
- Support per nom. This could be a very useful tool. Operator873 (talk) 05:17, 2 December 2017 (UTC)
- Oppose per above. --Terra ❤ (talk) 06:49, 2 December 2017 (UTC)
- Support MichaelSchoenitzer (talk) 14:24, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:53, 2 December 2017 (UTC)
- Support Patar knightchat/contributions 20:59, 2 December 2017 (UTC)
- Support Yes, PLEASE. In coming across a report at RFPP, a MAJOR consideration before protecting a page is the degree of "collateral damage" in the form of constructive users who would be prevented from editing. This is particularly the case when two experienced users begin an edit-war. A user-specific protection/page-specific block would be immensely helpful. Vanamonde93 (talk) 06:33, 3 December 2017 (UTC)
- Support could be very useful in some cases. -- seth (talk) 10:44, 3 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:26, 3 December 2017 (UTC)
- Support Ciao • Bestoernesto • ✉ 22:53, 3 December 2017 (UTC)
- Support TheNavigatrr (talk) 01:07, 4 December 2017 (UTC)
- Support Majo statt Senf (talk) 01:21, 4 December 2017 (UTC)
- Support Tiputini (talk) 07:11, 4 December 2017 (UTC)
- Support GoEThe (talk) 11:48, 4 December 2017 (UTC)
- Support –Davey2010Talk 15:32, 4 December 2017 (UTC)
- Support Yeza (talk) 23:22, 4 December 2017 (UTC)
- Oppose People need to learn how to temper their enthusiasm and self revert when warned. Doc James (talk · contribs · email) 02:08, 5 December 2017 (UTC)
- Support Lofhi (talk) 17:49, 5 December 2017 (UTC)
- Support even though I believe that both edit warriors and vandals can and should go rot somewhere else. Do I feel strongly about edits? yes! Have I and will I ever edit war? No. enL3X1 ¡‹delayed reaction›¡ 03:48, 6 December 2017 (UTC)
- Support Yohannvt (talk) 11:59, 6 December 2017 (UTC)
- Support Me-123567-Me (talk) 22:14, 6 December 2017 (UTC)
- Support WWGB (talk) 00:21, 7 December 2017 (UTC)
- Support Ealdgyth (talk) 13:35, 7 December 2017 (UTC)
- Support X:: black ::X (talk) 13:51, 7 December 2017 (UTC)
- Support Miaow 01:59, 8 December 2017 (UTC)
- Support Alangi Derick (talk) 15:10, 8 December 2017 (UTC)
- Support --Hkoala (talk) 05:14, 10 December 2017 (UTC)
- Support Perrak (talk) 20:50, 10 December 2017 (UTC)
- Support Preferably, some documentation on a process to accompanying this user to more constructive contributions should be done. This is no longer a technical task, but technical mechs are just a light part of the story here. Psychoslave (talk) 07:36, 11 December 2017 (UTC)
- Support GoboFR (talk) 10:53, 11 December 2017 (UTC)
- Support, with reasoning detailed in Community Wishlist Survey 2017/Admins and stewards/Allow further user block options ("can edit XY" etc.). Please do it not as a protection level but as sort of personal sanction against given users so that it appears in block (sanctions?) log of respective users rather that in the protection log of the page — NickK (talk) 12:55, 11 December 2017 (UTC)
- Support — Luchesar • T/C 13:15, 11 December 2017 (UTC)
- Support--KRLS (talk) 14:12, 11 December 2017 (UTC)
- Support Martin Kraft (talk) 17:53, 11 December 2017 (UTC)
Allow a second email address
- 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.
- Add the following global preferences (email and password are already global):
-
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.
- Phabricator tickets: phab:T129747
- Proposer: 𝔊 (Gradzeichen Diſk✉Talk) 09:32, 7 November 2017 (UTC)
- Translations: none yet
Discussion
editFor the records, https://phabricator.wikimedia.org/T129747#2777853 offers some concerns about the proposed approach. --AKlapper (WMF) (talk) 12:34, 7 November 2017 (UTC)
- 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)
- I agree with your concerns, TheDJ. The proposed solution seems over-complicated, but the root problem of disclosing email addresses is definitely a problem worth looking into. @°: Would it be OK for me to re-phrase your proposal as a problem to solve, rather than this exact solution? — Trevor Bolliger, WMF Product Manager 🗨 18:32, 13 November 2017 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- The root problem is definitely an issue, would be good to fix it. Raystorm (talk) 17:18, 14 November 2017 (UTC)
@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)
- 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)
- 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)
- "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)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Voting
edit- Support —viciarg414 08:12, 28 November 2017 (UTC)
- Support ·addshore· talk to me! 10:37, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:49, 28 November 2017 (UTC)
- Support Long overdue. Muhraz (talk) 13:07, 28 November 2017 (UTC)
- Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 13:17, 28 November 2017 (UTC)
- Support Sadads (talk) 13:34, 28 November 2017 (UTC)
- Support Jc86035 (talk) 14:37, 28 November 2017 (UTC)
- Support should have implemented long ago. - Mailer Diablo (talk) 15:12, 28 November 2017 (UTC)
- Support - Darwin Ahoy! 16:59, 28 November 2017 (UTC)
- Support --NaBUru38 (talk) 17:04, 28 November 2017 (UTC)
- Support — Draceane talkcontrib. 17:52, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:29, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:37, 28 November 2017 (UTC)
- Support Much higher priority than any changes in the MediaViewer right now. This should be No.1 on the list and then the rest. --Hedwig in Washington (talk) 02:40, 29 November 2017 (UTC)
- Support Shizhao (talk) 02:50, 29 November 2017 (UTC)
- Support 𝔊 (Gradzeichen Diſk✉Talk) 06:50, 29 November 2017 (UTC)
- Support Sebastian Wallroth (talk) 06:56, 29 November 2017 (UTC)
- Support goal, but Oppose a 2 email address solution. —TheDJ (talk • contribs) 17:00, 29 November 2017 (UTC)
- @TheDJ: on 7 nov 15:14 you named some conditions under which you would be "in". I think, that I actually addressed all of them in my post on 14 nov 17:53. You then raised no more concern, but you are still not in? Please elaborate. --𝔊 (Gradzeichen Diſk✉Talk) 21:53, 29 November 2017 (UTC)
- @°:, sorry, i had not noticed that part of the discussion. It would be much better if you could at least refer to that from the proposal section, because I totally didn't notice. —TheDJ (talk • contribs) 12:56, 30 November 2017 (UTC)
- Thanks. A second mailbox would have been helpful for me, as I recently received 2000 mails from commons. Even so they were send to my wiki-folder, they still might have exceeded the mailbox quota. --𝔊 (Gradzeichen Diſk✉Talk) 05:05, 1 December 2017 (UTC)
- @°:, sorry, i had not noticed that part of the discussion. It would be much better if you could at least refer to that from the proposal section, because I totally didn't notice. —TheDJ (talk • contribs) 12:56, 30 November 2017 (UTC)
- @TheDJ: on 7 nov 15:14 you named some conditions under which you would be "in". I think, that I actually addressed all of them in my post on 14 nov 17:53. You then raised no more concern, but you are still not in? Please elaborate. --𝔊 (Gradzeichen Diſk✉Talk) 21:53, 29 November 2017 (UTC)
- Support Joshualouie711 (talk) 19:32, 29 November 2017 (UTC)
- Support Seb26 (talk) 21:47, 29 November 2017 (UTC)
- Support --g (talk) 00:26, 30 November 2017 (UTC)
- Support - long needed. George Ho (talk) 01:14, 30 November 2017 (UTC)
- Support I like the private messaging in structured discussions idea proposed in the discussion. Daylen (talk) 01:15, 30 November 2017 (UTC)
- Support Zhangj1079 talk 01:58, 30 November 2017 (UTC)
- Support the problem statement. Oppose the "two email" solution. --Izno (talk) 02:57, 30 November 2017 (UTC)
- Support--L736Etell me 08:03, 30 November 2017 (UTC)
- Support Like tears in rain (talk) 11:35, 30 November 2017 (UTC)
- Support Gato Preto (talk) 14:53, 30 November 2017 (UTC)
- Support The underlying problem (exposing your e-mail adress when answering to a wikimail) needs adressing. This seems like a decent solution. Vachovec1 (talk) 17:41, 30 November 2017 (UTC)
- Support --OrsolyaVirág (talk) 19:35, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:36, 30 November 2017 (UTC)
- Support Sahaquiel9102 (talk) 21:33, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:47, 1 December 2017 (UTC)
- Support --Tigerzeng (talk) 15:54, 1 December 2017 (UTC)
- Support — Hmxhmx 16:11, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:07, 1 December 2017 (UTC)
- Support Xavi Dengra (MESSAGES) 22:48, 1 December 2017 (UTC)
- Support SEMMENDINGER (talk) 23:43, 1 December 2017 (UTC)
- Support the problem, Oppose the second email thing. Terra ❤ (talk) 06:40, 2 December 2017 (UTC)
- Support Szoltys (talk) 12:05, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 12:14, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:52, 2 December 2017 (UTC)
- Support Patar knightchat/contributions 21:00, 2 December 2017 (UTC)
- Support No comments on the specific implementation details, but the general principle is a good one. A private messaging system that does not use email addresses would help greatly with the problem too. Boing! said Zebedee (talk) 21:46, 2 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:27, 3 December 2017 (UTC)
- Support TheNavigatrr (talk) 01:08, 4 December 2017 (UTC)
- Support Tiputini (talk) 07:10, 4 December 2017 (UTC)
- Support --Unterstrichmoepunterstrich (talk) 08:14, 4 December 2017 (UTC)
- Support Davidpar (talk) 15:17, 4 December 2017 (UTC)
- Support giving editors the option of adding a second email address but Oppose making it a required thing - Let editors have the choice if they want to it or not and maybe put something along the lines of "Enter a second email if you want but it's not necessary). –Davey2010Talk 15:35, 4 December 2017 (UTC)
- Support Fixer88 (talk) 17:11, 4 December 2017 (UTC)
- Support Ronhjones (talk) 18:26, 4 December 2017 (UTC)
- Support Yeza (talk) 23:19, 4 December 2017 (UTC)
- Support if it's not mandatory. Lofhi (talk) 17:50, 5 December 2017 (UTC)
- Support Support should have implemented long ago. LaMèreVeille (talk) 21:07, 5 December 2017 (UTC)
- Support A great idea. Orielno (talk) 22:01, 5 December 2017 (UTC)
- Support I suppose this is easier than setting up a WikipediaPrivate Messaging System? And no, PMing on the IRC doesn't fulfill the needs, esp as WP:911 isn't on the freenode. enL3X1 ¡‹delayed reaction›¡ 03:44, 6 December 2017 (UTC)
- Support Yohannvt (talk) 12:00, 6 December 2017 (UTC)
- Support As per TheDJ -glove- (talk) 16:16, 6 December 2017 (UTC)
- Support JAn Dudík (talk) 08:50, 7 December 2017 (UTC)
- Support Dolotta (talk) 17:26, 7 December 2017 (UTC)
- Support Alangi Derick (talk) 15:10, 8 December 2017 (UTC)
- Support MichaelMaggs (talk) 13:36, 9 December 2017 (UTC)
- Support Pharos (talk) 16:55, 9 December 2017 (UTC)
- Support Nigo0909 (talk) 02:44, 11 December 2017 (UTC)
- Support GoboFR (talk) 10:53, 11 December 2017 (UTC)
- Neutral. I Support that we should solve the problem of single email for everything (a more secure one is needed for password recovery than for answering spammers) but I Oppose the proposed solution as overly complex to use and to manage — NickK (talk) 13:20, 11 December 2017 (UTC)
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.
- Proposer: WereSpielChequers (talk) 06:38, 20 November 2017 (UTC)
- Translations: none yet
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)
- 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)
- @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)
- 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)
- @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 ?
- 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)
- 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)
- 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)
- 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)
Voting
edit- Support —viciarg414 08:13, 28 November 2017 (UTC)
- Support-- Liuxinyu970226 (talk) 12:49, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:30, 28 November 2017 (UTC)
- Support — Luchesar • T/C 21:32, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:37, 28 November 2017 (UTC)
- Support I am assuming this would, like the cookie block setting, be placed as an option for admins for each block. Like the cookies, this has a potential for collateral damage, and is easily circumvented by knowledgeable folk. I still support it because it increases the barrier to be persistently disruptive. This will require a lot of testing before going live though. Chico Venancio (talk) 21:44, 28 November 2017 (UTC)
- Support -- Rohini (talk) 11:25, 29 November 2017 (UTC)
- Support EVinente (talk) 19:46, 29 November 2017 (UTC)
- Support —Syrenka V (talk) 21:21, 29 November 2017 (UTC)
- Support--L736Etell me 08:04, 30 November 2017 (UTC)
- Support. It can be circumvented by a smart user, but most spammers and vandals are not so smart. JzG (talk) 15:08, 30 November 2017 (UTC)
- Support Sounds hard to implement, but if done well it would be amazing. Tessaract2 (talk) 18:17, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:37, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:49, 1 December 2017 (UTC)
- Support Supuhstar (talk) 19:32, 1 December 2017 (UTC)
- Support Making the barrier to entry more difficult for folks not here to contribute civilly should be pursued. This seem to add just a little more friction to the process and will undoubtedly deter many of the low-effort attempts to harass or vandalize. Ckoerner (talk) 21:28, 1 December 2017 (UTC)
- Support Agreed. Very topical for me as I've had the same individual use three different IPs to harass my talk page everytime the page protection expires and all the IP stem from the same initial numbers. Good idea. SEMMENDINGER (talk) 23:44, 1 December 2017 (UTC)
- Support I support this. Hope that it applies to all Wikipedias, specially the spanish one, each time comes many kids to vandalize popular animation/games related articles.--VictorPines (talk) 01:28, 2 December 2017 (UTC)
- Support Terra ❤ (talk) 06:42, 2 December 2017 (UTC)
- Support Mark the train (talk) 10:45, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 12:14, 2 December 2017 (UTC)
- Support Петър Петров (talk) 14:57, 2 December 2017 (UTC)
- Support --Мико (talk) 15:17, 2 December 2017 (UTC)
- Support --Nk (talk) 19:55, 2 December 2017 (UTC)
- Support Patar knightchat/contributions 21:01, 2 December 2017 (UTC)
- Support Matěj Suchánek (talk) 21:12, 2 December 2017 (UTC)
- Support Boing! said Zebedee (talk) 21:48, 2 December 2017 (UTC)
- Support Michal Lester לסטר (talk) 07:29, 3 December 2017 (UTC)
- Support NinjaRobotPirate (talk) 07:52, 3 December 2017 (UTC)
- Support Kostas20142 (talk) 17:59, 3 December 2017 (UTC)
- Support Giraffedata (talk) 21:34, 3 December 2017 (UTC)
- Support Tiputini (talk) 07:10, 4 December 2017 (UTC)
- Support Jc86035 (talk) 12:30, 4 December 2017 (UTC)
- Support –Davey2010Talk 15:30, 4 December 2017 (UTC)
- Support Ronhjones (talk) 18:24, 4 December 2017 (UTC)
- Support Yeza (talk) 23:20, 4 December 2017 (UTC)
- Support We need to be able to limit vandals ability to edit. Doc James (talk · contribs · email) 02:07, 5 December 2017 (UTC)
- Support Vincent Simar (talk) 11:45, 5 December 2017 (UTC)
- Support Defender (talk) 17:40, 5 December 2017 (UTC)
- Support NessieVL (talk) 18:01, 5 December 2017 (UTC)
- Support Sounds like a good idea. Orielno (talk) 22:03, 5 December 2017 (UTC)
- Support User agent info provides a lot more than just browser and OS versions. If we're to continue to allow IP editing, we need this. Kudpung (talk) 20:22, 6 December 2017 (UTC)
- Support yes our tools do need to get smarter. Steelpillow (talk) 22:45, 6 December 2017 (UTC)
- Support WWGB (talk) 00:23, 7 December 2017 (UTC)
- Support This looks like a valuable step in the right direction, so thank you! Can we investigate the possibility of making the same available at a global level? I'm thinking of a specific globally-locked LTA nuisance editor who dances from project to project; while larger Wikipedias are probably more or less able to contain the damage, some smaller ones may be very vulnerable. Justlettersandnumbers (talk) 23:27, 7 December 2017 (UTC)
- Support Miaow 02:06, 8 December 2017 (UTC)
- Support per Justlettersandnumbers. This would be really valuable with respect to the LTA with whom I am very familiar as well. This person returns almost daily, with constantly shifting IPs almost invariably from the same ISP and location. They also do considerable cross-wiki damage as well. Voceditenore (talk) 08:58, 8 December 2017 (UTC)
- Support Julia\talk 10:37, 8 December 2017 (UTC)
- Support Doug Weller (talk) 17:25, 8 December 2017 (UTC)
- Support Pipetricker (talk) 17:43, 8 December 2017 (UTC)
- Support --jdx Re: 18:54, 8 December 2017 (UTC)
- Support -glove- (talk) 08:46, 9 December 2017 (UTC)
- Support --Omotecho (talk) 12:12, 10 December 2017 (UTC)
- Support Haxpett (talk) 23:18, 10 December 2017 (UTC)
- Support GoboFR (talk) 10:51, 11 December 2017 (UTC)
- Support. I am not sure this would be easy to implement, but it is a good idea. We do have a number of vandals in large ranges (e.g. a huge mobile operator) and our two main options are either blocking everyone in this range or blocking a single IP knowing that it can change within seconds. We really need something in between — NickK (talk) 12:54, 11 December 2017 (UTC)
- Support--KRLS (talk) 14:12, 11 December 2017 (UTC)