Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Main project page (discuss)
Ideas for privacy enhancement (discuss)  · Improving anti-vandalism tools (discuss)


IP Editing: Privacy Enhancement and Abuse Mitigation Archive index
This page is to collect feedback for the privacy enhancement for unregistered users project.
Hoping to hear from you. You can leave a comment in your language if you can't write in English.
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days and sections whose most recent comment is older than 90 days.

Support and Oppose List[edit]

This list documents who supports and opposes it. It is useful for a numerical summary of the tangled page below, and also to be clear about who thinks what. Feel free to add your own name to it.

Editors in support of this proposal[edit]

  1. Yger
  2. Gnom
  3. Jeblad
  4. There's a lot that can be done to improve the tooling and implementation of IP editing that can improve the workflow (for registered editors) of canonizing or reverting those edits. Not showing IP addresses directly would also improve the current flaw of SPI, that favors logged-out abuse by refusing to connect IP edits to accounts. These avenues are worth exploring and deciding whether to use them when exact solutions are proposed for the issues raised. —Aron Man.🍂 hist🌾 13:01, 7 November 2019 (UTC)

Editors in opposition to this proposal[edit]

  1. Computer Fizz
  2. MER-C
  3. Incnis Mrsi
  4. LightandDark2000
  5. Winged Blades of Godric
  6. Roy17
  7. Johnbod
  8. OhKayeSierra
  9. Vituzzu
  10. Benjamin
  11. 168.244.4.53
  12. Jni
  13. 2001:999:82:9855:DC90:883A:206A:2
  14. GreenMeansGo
  15. Раммон
  16. Veracious
  17. Brandmeister
  18. Millennium bug
  19. PaleoNeonate
  20. Udo T.
  21. Someguy1221
  22. ネイ
  23. Nosebagbear - I'd only support limiting vision to autoconfirmed users.
  24. Ajraddatz
  25. Bbb23
  26. Cullen328
  27. Nick-D
  28. BrownHairedGirl
  29. Ched
  30. Kudpung
  31. Pharaoh of the Wizards
  32. AlasdairW
  33. Llywrch
  34. 2A01:E35:39AE:B540:BD22:78D9:FBE5:D3B9
  35. Camouflaged Mirage
  36. 87.212.10.251
  37. Nyttend
  38. Deepfriedokra
  39. Matthiasb
  40. Blue Rasberry (talk) 20:51, 27 August 2019 (UTC)
  41. Gryllida
  42. Berean Hunter
  43. Edoderoo
  44. Ahmad252
  45. Victar
  46. OJJ
  47. Rschen7754
  48. Smallbones
  49. FocalPoint
  50. Indy beetle
  51. आर्यावर्त (talk) 07:06, 29 August 2019 (UTC)
  52. Arthur Rubin T C (en: U, T). I thought I was clear. I'm opposed, but would be willing to reconsider if better anti-vandalism tools are provided to all (including IPs), and provide better coverage than existing IP-based tools. 05:36, 28 August 2019 (UTC)
  53. Johnuniq (talk) 07:06, 28 August 2019 (UTC) I might have been too subtle below.
  54. Vehemently. Praxidicae (talk) 19:59, 28 August 2019 (UTC)
  55. Strongly, WMF start solving real problems first - you have open bugs and feature requests from 10 years ago. --Dirk Beetstra T C (en: U, T) 07:56, 29 August 2019 (UTC)
  56. Sunny00217
  57. Double sharp (talk) 02:38, 1 September 2019 (UTC)
  58. JFG
  59. Vermont
  60. — Draceane talkcontrib. 07:29, 3 September 2019 (UTC)
  61. Celia Homeford (talk) 12:58, 3 September 2019 (UTC)
  62. Very trivial issue that seems like a pointless chore to implement, let alone put into effect. Do I even need to stress why this will cause more problems than it solves? (Especially when others put it better than I can.) ToThAc (talk) 23:35, 4 September 2019 (UTC)
  63. Vojtasafr (talk)
  64. What a terrible idea Nomad (talk) 16:59, 5 September 2019 (UTC)
  65. Strongly oppose. --Homo ergaster (talk) 17:11, 5 September 2019 (UTC)
  66. All or nothing; implement mandatory registration or leave it as it is. PCHS-NJROTC (talk) 23:46, 8 September 2019 (UTC)
  67. No. Make it possible for the patrollers to also see ip's of logged-in accounts to track puppetry. --Madglad (talk) 03:33, 9 September 2019 (UTC)
  68. * Pppery * it has begun 03:44, 9 September 2019 (UTC)
  69. MrClog (talk) 18:49, 10 September 2019 (UTC)
  70. Trialpears - IP editors are aware that their IP will be shown and if that's a major problem they can register an account without even an email.
  71. Oppose.As noted below is voluntary and it is disclosed that the IP address will be visible to anyone anon making an edit. Now as some other editors have pointed that we can make this more clear to the IP editors by having a checkbox as pointed out below and through it is already clearly mentioned Your IP address will be publicly visible if you make any edits. and Saving the change you are previewing will record your IP address in this page's public edit history. but we can have a checkbox in addition to this to be even more clearer.Pharaoh of the Wizards (talk) 20:12, 15 September 2019 (UTC)
  72. Notrium
  73. nsaa (talk). I really don't see any advantages of doing this masking. One of the cornerstones of the Wikipedia projects has been the ability to edit directly from your IP address. It's easy to handle vandalism from Schools (and help teachers). You can do range blocks, you can create 3rd party services like this Twitter account that send out all editing done from the Norwegian Parliament Stortinget at https://twitter.com/wikistorting etc. 06:34, 12 October 2019 (UTC)
  74. Accountability and reputation are good for the projects. Accountability and reputation require a persistent identity, and the only way to have persistent identity is via usernames. This proposal wouldn't make identity less persistent, but it would make it more difficult to make it more so. It would do that by lending fresh legitimacy to shifting identity, as well as increasing our investment in it, whereas we are currently just tolerating what was created in the beginning and has outlived its usefulness; i.e. unregistered editing. Mandruss (talk) 00:23, 15 October 2019 (UTC)
  75. Jéské Couriano (v^_^v)
  76. Oppose. Creating an account expresses a wish to be part of the community. If an editor does not want to be part of the community, then we owe them nothing. -- Llywrch (talk) 16:56, 3 November 2019 (UTC)
  77. See EN:WP:SNOW. In other words, "given the overwhelming results here, this doesn't have a snowball's chance in hell". Alsee (talk) 23:58, 7 November 2019 (UTC)
  78. Per IP Editing: Privacy Enhancement and Abuse Mitigation#Q: Will users with advanced permissions such as CheckUsers, Admins, Stewards still have access to IP addresses after this project is complete? I am opposed to preventing trusted admins on a site from being able to see IP addresses. This is critical to preventing abuse and harrasement of participants. --mikeu talk 06:53, 27 November 2019 (UTC)
  79. This would be a mistake. It's easy enough to create an account and we shouldn't give IP editors another reason to refrain from doing so. Also, consensus is pretty clear that this is a no-go, so I suggest that the WMF move on to something else. Lepricavark (talk) 23:14, 28 December 2019 (UTC)
  80. Some vandals may think twice to vandalise if they know the fact that they can be tracked by ip.Ionutzmovie (talk) 20:20, 13 January 2020 (UTC)
  81. This is a solution to a problem that doesn't exist (as any IP editor in good standing can request an account); furthermore it could create a huge raft of problems for vandal fighters and anyone wanting accountability from IP editors. Please don't do it! Mrjulesd (talk) 15:25, 19 January 2020 (UTC)
  82. Per Mike. --Achim (talk) 23:02, 20 January 2020 (UTC)
  83. Dreamy Jazz. How would range blocks even work? How would you be even able to work out what range block is needed? Also how would you be able to connect IPs based on similar addresses? How can regular users prove socking using IPs to justify a CU check for other accounts or to connect accounts when the accounts may not have enough evidence to support a check at SPI on enwiki? How can regular users detect and find abuse by similar IPs? How can range blocks be even seen or vetted by the community (if only administrators (or other trusted roles) have access to the IP addresses affected by the range block)? How can IP addresses affected by a range block see what IP range block is affecting them and how would an administrator be able to determine if the editor is caught up in the range block is close enough to the problem IP addresses or far away enough that it is likley not the problem user(s)? How can abuse by IP editors, by just removing the cookie, stop IPs from just changing their on wiki "name" to avoid blocks or detection? How many anonymous users will be created, especially on busier IP addresses, which may be a computer with potential thousands of different users who could log in using their profile (so have their own cookie) (like a school or work computer)? How can this system prevent spamming of the creation of new "names" for IP addresses (like a person could just set up a script which makes an edit, then removes the cookie and then makes another edit)?
    I have many more issues with this and so I in the strongest possible terms oppose this unless all the issues I mention above are no longer a problem. I also think that there is no way to mitigate some the problems and the current proposal is very unlikely to work as well as what is currently in place. This will only make it easier for abuse by IPs and make it harder to detect. I understand the privacy concerns, but perhaps a tick box for an IP to press to confirm that they understand their edit is associated to their IP. Perhaps a cookie could be used to store if the IP agreed to this. If this proposal is implemented without proper fixes to many, many issues, content on the wikis will get worse as IPs are harder to block and undisclosed paid activities will be so so so much easier to carry out. If this is implemented, I see my ability to prevent block evasion and ban evasion before it happens completely gone as a block of a IPs "name" would be so easy to get around. Dreamy Jazz 🎷 talk to me | my contributions 01:26, 21 January 2020 (UTC)
  84. Xxanthippe. Xxanthippe (talk) 05:02, 4 March 2020 (UTC).
  85. Symbol oppose vote oversat.svg Strong oppose I am usually a big proponent of privacy. At this time, though, I can see no way anti-vandalism work could be anywhere as effective if IP addresses were masked; we strongly encourage account creation for this exact reason. At a time when e.g. Wikidata's vandalism problem needs to be made easier to combat, this makes no sense whatsoever. The gain in perceived privacy is smaller than this document makes it out to be and is not worth it. How exactly it affects anti-vandalism efforts is detailed by everyone who opposed above. It should be noted that unlike other websites like the big social media networks, our anti-abuse activities are carried out by volunteers who are donating their own time to the cause. The only reason those other websites can still conduct anti-abuse activities while hiding IP addresses from the public is their having dedicated staff for that purpose. That solution clearly would not scale here, since "abuse" is, after all, defined partly by the community.--Jasper Deng (talk) 06:27, 2 May 2020 (UTC)
  86. TheSandDoctor - Symbol oppose vote oversat.svg Strong oppose To be clear: I am usually a big proponent of privacy as well, but let me get this straight...
    "It’s also possible that anti-vandalism tools will continue to use IP addresses, but will have restricted access." - you want to restrict tools key to anti-vandalism work, thus giving vandals an easier time? That does not seem wise in the slightest and needs a heavy re-think
    "Wikimedia Foundation does not currently have any definite plans for how to achieve this dual goal of better protecting user privacy, while also giving contributors effective tools to protect our wikis from vandalism and abuse." - you have no idea how to do this, yet are plowing ahead with it anyways?
    "we should expect our administrators' ability to manage vandalism to be greatly hindered." - that is something that I find extremely concerning. Hindering vandalism fighters (in general) from effectively performing their role should never be on the table in the first place. period
    "This can be mitigated by providing tools with equivalent or greater functionality, ..." - I will hold judgement on this point as it has no examples/ideas (itself a concern), but I am having trouble seeing what this could be.
    "but we should expect a transitional period marked by reduced administrator efficacy." - I have an idea: avoid making more work for volunteers
    I do have respect for the WMF and the hard work that they do do, but this is a prime example of an idea that is insane and ill conceived; this is the most idiotic proposal I've seen in a while, probably akin to super-protect and flow. I have a feeling that this will be pushed ahead regardless of what we say, but I sincerely hope not. This idea should be en:WP:SNOW closed as not having a "snowball's chance in hell" & put on the scrap heap where it belongs OR require mandatory registration to edit...none of this in-between stuff. --TheSandDoctor Talk 16:47, 2 May 2020 (UTC)
  87. Symbol oppose vote oversat.svg Strong oppose - This proposal is incredibly vague. What about subnets (i.e. IPv6 /64's) wholly owned by one user? Will they show up as one person or as 1.8e19 users? This could have a massively negative effect on the ability of editors to stop vandalism and trolling. I have a more simple suggestion if the WMF wants all IPs hidden: Block anonymous editing. Reaper Eternal (talk) 14:02, 7 May 2020 (UTC)
  88. At this juncture, this proposal is completely unfeasible, especially on large projects. --QEDK (talkenwiki) 17:54, 20 May 2020 (UTC)
  89. Symbol oppose vote oversat.svg Strong oppose Despite being a strong proponent of privacy, I strongly oppose the current proposal for all the reasons mentioned above by other editors. If privacy and some protection from malicious actors are an objective, I might support obfuscation of only the first octet, as this would still allow meaningful anti-vandalism work (assuming the admin tools will still be able to connect two similar addresses). But getting rid of IP display - no, not possible in the current shape. Kashmiri (talk) 00:28, 26 May 2020 (UTC)
  90. If you want to protect IPs, just ban anonymous editing. Not saying that's the best idea, but it would be the simplest way to achieve this goal. -- King of ♥ 16:58, 26 May 2020 (UTC)

Comments/discussion[edit]

( incomplete list, will add more later feel free to add your own name ) Computer Fizz (talk) 19:45, 27 August 2019 (UTC)

I have moved this to the top for visibility and collection reasons. Also, to show the WMF because their pronouns and implications imply this is, in some universe, going to pass. Computer Fizz (talk) 02:17, 28 August 2019 (UTC)
Their stated goal here is to develop the anti-abuse infrastructure to the point of no longer needing to reveal IPs. Our anti-abuse infrastructure is not ideal as-is, so this is something that I (and I would hope others) would be open to. But yes, I would oppose implementing IP masking alone. – Ajraddatz (talk) 02:46, 28 August 2019 (UTC)
So are you saying i shouldn't have put your name under oppose? Computer Fizz (talk) 03:18, 28 August 2019 (UTC)
I'm saying that you seem to be reacting to the "privacy enhancement" part of this proposal, not the "abuse mitigation" part. – Ajraddatz (talk) 11:46, 28 August 2019 (UTC)

I don't feel like such lists are useful. This is not a vote and at least I don't want that someone add my name on list based on how he/she see my opinion. That's why I took off my name from there. Stryn (talk) 20:42, 28 August 2019 (UTC)

Yeah, that's not usually how RFC's work. Normally people add themselves. I think others have objected to being spoken for as well. SQLQuery me! 16:04, 29 August 2019 (UTC)
I never said this list would be the final decider in whether or not it passes. it's just a proof of concept, a visual representation of who thinks what, and to show to those who act like people enjoy this idea. And i'm sorry if you felt like i was trying to speak for you, when prepopulating the list from discussion i left out a lot of editors who i wasn't entirely sure what they thought. if you want to remove your name i won't be offended but i also don't see the harm in keeping it. Computer Fizz (talk) 23:26, 29 August 2019 (UTC)
I haven't checked every name in the list, but a quick scan of this page for the exchange between 87.212.10.251 and 24.151.50.175 suggests this list is going to be highly dubious. Let's put it another way Computer Fizz. Do you oppose improvements to anti-vandalism tools if it resulted in increased privacy? It's fine to suggest that you've explored all the options and have ruled out any alternatives to publicly displaying IP addresses. But I don't think that's really the case for the majority here. Not wanting change is an understandable reaction, but at this point we don't even know what the proposed change is going to be, so opposing it without fully understanding all the implications doesn't really make much sense. -- zzuuzz (talk) 23:57, 29 August 2019 (UTC)
My proposed change is to require people to create an account. The only real downside is that those ips that just make like one or two edits like fixing a typo then disappear forever probably won't wanna do that and it'll just go unfixed. That said, i still think it's miles better than the current proposal. Computer Fizz (talk) 08:02, 22 September 2019 (UTC)

Tools for improving current workflows[edit]

Hi all! Over the past few months we’ve been collecting existing use cases for IP addresses and brainstorming ideas for tools that can improve upon our existing workflows that involve IP addresses. A lot of work is involved a number of the current processes. Hence we came up with several ideas for tools that can automate some of necessary work and empower users to focus on the things that computers cannot take care of. This includes things like automatically fetching information about an IP address without needing a search engine and also automating some of the steps to find IP editors editing in proximity to a given IP editor or exhibiting similar behaviors. Our goal is to help save time for the communities, rather than add more work. We have put out these ideas on the Improving tools page. We would love to hear your thoughts about these on the talk page. Thanks in advance. -- NKohli (WMF) (talk) 05:13, 14 January 2020 (UTC)

@NickK, MER-C, Someguy1221, SQL, Ruthven, Doc James, ChristianKl, Arthur Rubin, Ah3kal, Pelagic, and Nick-D: - Pinging some folks who have chimed in about tools earlier on this page. Your thoughts on the ideas put forth on improving tools would be very valuable. Thanks for your time. -- NKohli (WMF) (talk) 22:31, 17 January 2020 (UTC)
@NKohli (WMF): Thanks for the ping. There is one argument in your statement that does not get any answer: It takes significant time and effort for new users to get accustomed to using IP addresses for blocking and filtering purposes.. None of these tools really improves it. Replacing a set of digits 198.73.209.241 with a set of digits 12345 simplifies nothing, it is still a set of numbers that don’t make sense (just not seemingly random but really random). However, for those who know how to use IPs it is more complex — NickK (talk) 13:46, 18 January 2020 (UTC)
@NKohli (WMF): Off the cuff? Being able to search UA's in the checkuser tool. It's already something we use (a common first step is to control-f part of the UA). Being baked in would be a huge help. Access to more browser headers. Being able to search those browser headers. SQLQuery me! 08:40, 21 January 2020 (UTC)
"Our goal is to help save time for the communities, rather than add more work" I would be more confident into that being your goals if it would be listed as in the goals of the project. Currently, those goals don't list anything about making it easier for admins to do their job then it's at the status quo. ChristianKl❫ 16:58, 20 January 2020 (UTC)
The main goal for this project is to get better at protecting unregistered user privacy, obviously. Because important workflows depend on that information, we need to do further development, at least going for status quo in how much time they consume, but definitely aiming to make it easier than it is today as opposed to harder. Does that make sense? I mean, "hide IPs" is not going to have "make it easier to fight vandalism, harassment and spam" as the main goal, but "better tools to fight vandalism, harassment and spam" is a necessary part of it and this would describe our goal for that. /Johan (WMF) (talk) 18:15, 20 January 2020 (UTC)
I don't speak for anyone but myself, but, unless the tools, without access to the IP addresses, make vandal-fighting easier than no tools, but with access to the IP addresses, IP masking should not be implemented. That seems a minimal metric to determining whether the tools goal has been met. — Arthur Rubin T C (en: U, T) 22:10, 21 January 2020 (UTC)
I agree with Arthur Rubin's opinion. Any tools that's being made must be making it easier to fight vandalism, or else its function is just for hiding IPs (hence making it difficult for vandal-fighting). XoXo (talk) 03:13, 27 February 2020 (UTC)

Regarding a kind of single-IP block[edit]

Some schools and institutions use fixed IPs. There are always sort of vandalism from these IP. Consider the following situation:

IP 111.111.111.111 belongs to a primary school whose students are under 12. There're always some naughty kids making fun by corrupting some Wikipedia articles. Though their edit pattern are totally different, sysops still block this IP for 2 years, since this IP has been abused for at least 3 years.

In this case, different trouble makers in the same school could be identified as different "Anon User"s, as mentioned in the proposal, because they use different cookies, have a significant gap in time of editing and other possible reasons. Thus, sysops will not apply a long-term block on one "Anon User" because each "Anon User" acts differently and the next time they will be a new "Anon User". We lose the connection (that they share the same IP) between them. Therefore, we are not able to know that an IP should be blocked, even though the new tools provides IP-block function in a way not revealing the IP. The consequence is more energy spent for anti-vandalism works.

This may be an issue related to how "Anon User" are identified. If all the trouble makers in this school are identified as the same user, then their privacy seems to be weakened because the public will know that they were once in the same school in a specific area (rough information about the IP will be provided instead of the IP itself as proposed).--Tiger- (talk) 15:41, 12 March 2020 (UTC)

Thank you. Just to be clear, it's very possible that we'd suggest an implementation where this case would actually show up as one user, similar to today in that sense. /Johan (WMF) (talk) 07:54, 20 March 2020 (UTC)

Archiving[edit]

Could we make for a more accessible and summarisable archive setup here.

Currently you need to go into the history to find the archives, which are all separated, and there are big discussions in there that were never resolved (they are pending answers either NKohli and the team didn't have to hand, or wouldn't make).

A huge amount of critical reasoning is also there, including a fairly comphrehensive laying out of issues with IP Masking and attempting to group the IP addresses in the ways mooted. That reasoning is a fairly substantive part here of the record, and certain key parts should probably be here permanently. At a minimum, individuals need to be able to freely search the content of the archives in a single search. 81.140.68.252 17:22, 20 May 2020 (UTC)