Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

Active discussions


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 ListEdit

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 proposalEdit

  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 proposalEdit

  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. — Draceane talkcontrib. 07:29, 3 September 2019 (UTC)
  60. Celia Homeford (talk) 12:58, 3 September 2019 (UTC)
  61. 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)
  62. Vojtasafr (talk)
  63. What a terrible idea Nomad (talk) 16:59, 5 September 2019 (UTC)
  64. Strongly oppose. --Homo ergaster (talk) 17:11, 5 September 2019 (UTC)
  65. All or nothing; implement mandatory registration or leave it as it is. PCHS-NJROTC (talk) 23:46, 8 September 2019 (UTC)
  66. 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)
  67. * Pppery * it has begun 03:44, 9 September 2019 (UTC)
  68. MrClog (talk) 18:49, 10 September 2019 (UTC)
  69. 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.
  70. 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)
  71. Notrium
  72. 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)
  73. 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)
  74. Jéské Couriano (v^_^v)
  75. 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)
  76. 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)
  77. 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)
  78. 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)
  79. 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)
  80. 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)
  81. Per Mike. --Achim (talk) 23:02, 20 January 2020 (UTC)
  82. 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)
  83. Xxanthippe. Xxanthippe (talk) 05:02, 4 March 2020 (UTC).
  84.   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)
  85. TheSandDoctor -   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)
  86.   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)
  87. At this juncture, this proposal is completely unfeasible, especially on large projects. --QEDK (talkenwiki) 17:54, 20 May 2020 (UTC)
  88.   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)
  89. 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)
  90. Hasley
  91. Strong Oppose -- JavaHurricane. It is better to prevent IPs from editing rather than masking them.
  92.   Strong oppose unless most of the tooling problems are fixed (or, at a minimum, explained how they would be fixed) first. --Mdaniels5757 (talk) 16:34, 10 June 2020 (UTC)
  93.   Strong oppose unless something to create a persistent identifier that's at least as stable as a dynamic IP address. If someone can get a new identifier merely by clearing their cookies (which many people have their browsers set to do every time they close them), then they can have a different ID for each edit. They can do the same, of course, in many cases by forcing a new dynamic IP or by moving around through undetected proxies, but that requires knowledge and intent while just closing your browser for whatever reason does not. Allowing IDs or, for that matter, IPs to change makes discussions and dispute resolution far more difficult than necessary. The better solution here is to disallow anonymous editing altogether, but that's not going to happen. — TransporterMan (talk) 17:14, 22 June 2020 (UTC)

Comments/discussionEdit

( 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)
  • @NKohli (WMF), CLo (WMF), DannyH (WMF), and Johan (WMF): In light of the extremely strong consensus in opposition to this proposal, why hasn't it been officially shelved? If the legal team has concerns about exposed IP addresses, then the simple solution is to just require registration to edit everywhere. If you truly do intend to make our lives easier than harder, then I would not advise moving forward with a proposal with less than a 5% approval rate.--Jasper Deng (talk) 23:51, 1 June 2020 (UTC)
Jasper Deng: As you indicate, we're not doing this because we think it's a terrific idea to spend our resources on doing something that significant parts of our community think is going to cause problems for ability to fight vandalism, but because of changing norms around what we can do with IPs. We've been having a number of conversations in other languages than English and will report them here as soon as possible, at least one Wikipedia community that has discussed this actively want IPs to be masked, some are torn, some think it's not an issue. We'll get back to this, and do a proper update as soon as we have managed to get things together, but I just briefly wanted to comment on the underlying assumption that it would be easy and uncontroversial to simply disallow IP editing. My home wiki, for example, has explicitly discussed and rejected requiring registration in the light of IP masking, and would be angry and upset if the WMF decided to take that route for the Wikimedia communities in general. /Johan (WMF) (talk) 01:02, 2 June 2020 (UTC)
@Johan (WMF): Yes, Swedish Wikipedia may support this proposal, but this is just one Wikimedia site out of the almost 1000 that we now have, and certainly not the norm in many areas. I can tell you that English Wikipedia is resoundingly against this proposal, and quite frankly if WMF alienates that wiki (as they nearly did with superprotect and w:en:WP:FRAM, and maybe even the Universal Code of Conduct), I think Wikimedia will be over. Why does the WMF continue to push pet projects that the editing community (that quite frankly, generates the content that brings in the viewers and the donations) does not want?
If you really doubt the numbers above - why doesn't the WMF make an official RFC on Meta? Any of these "studies" you have done - they could be cherrypicked and that's not how we do things on Wikimedia. We do them by open discussion and consensus, not by closed discussions and forum-shopping. --Rschen7754 01:18, 2 June 2020 (UTC)
Rschen7754: I'm not sure many at all would really prefer the Foundation to put so much resources on this, including us. We're doing this because what can be published on the internet is changing, not because we think it's a great idea in itself. Or do you mean on disallowing IP editing?
To clarify, we went looking for workflows and feedback on the anti-vandalism tools we're trying to build, not to have a general discussion about the merits of masking IPs in general to disregard feedback here on Meta. This, of course, doesn't keep communities to have discussions around the future in general. The Swedish Wikipedia discussion on disallowing IP editing was an internal decision, not mainly meant as feedback to the Foundation, and I wouldn't say Swedish Wikipedia supports IP masking. It just doesn't care much either way, but that is besides the point – I merely wanted to point out that disallowing IP editing is not a simple and uncontroversial solution. /Johan (WMF) (talk) 02:29, 2 June 2020 (UTC)
@Johan (WMF): I mean this proposal in general. I think you're missing the point: since when does the outside world tell Wikimedia what to do? If you don't think it's a good idea and we don't think it's a good idea, then it seems to be settled - why are we doing it? If they want, they can convince us why we should do it, and then we can have a consensus discussion. --Rschen7754 02:52, 2 June 2020 (UTC)
@Johan (WMF): Again, there is a very simple and straightforward solution if you do not think IP addresses can be shared publicly anymore: require registration (globally). Don't re-invent the wheel; just because one, small, wiki wants it does not mean it should be forced upon the rest of us. If you want a proper assessment of opinion, open a formal RfC with a well-defined proposal. However, I have seen literally zero support for this from the people who are actually involved in global anti-abuse activities. Even if one wiki supports it, you can see that it is still wildly unpopular in the global community as a whole and therefore that should be a sign that you should not pursue this half-baked solution in search of a problem. Even if one wiki does not like requiring registration, whatever alternative that might be proposed here is not at all worth the complexity.--Jasper Deng (talk) 02:56, 2 June 2020 (UTC)
Jasper Deng: Sorry for the long reply. I’m not trying to win an argument here, merely attempting to – as you request – explain why we’re not pushing for blocking IPs as a simple solution to this, instead of spending years on technical solutions trying to offset the problems.
The first thing we set out to do when tasked with this was to try to systematically figure out to which degree IP edits are useful, and how important they are.
I don’t know if you saw it, but Benjamin Mako Hill posted a link to the research on IP editing User:Benjamin Mako Hill/Research on the value of IP Editing earlier in the discussion (now archived). We’re doing this long project with a lot of software development instead of simply turning off IP editing because all we know about disallowing IP editing when it has been systematically studied shows it to be damaging in the long run. Not just in the immediate results, but also – suggests the research – because it’s a danger to long-term recruitment, as it can discourage newcomers from making their first edit and adds to the barrier of entry. This is the thing that perhaps concerns us the most.
Take Japanese Wikipedia, which has a culture of IP editing. They have a far higher percentage of IP editing than English Wikipedia, but the revert rate of those edits are only a third of the revert rate on English Wikipedia – 9.5% compared to 27.4% – indicating that they are also far more useful. Yet no one from Japanese Wikipedia has participated here – partly because this is in English, partly because they rarely interact outside of their own wiki. An RFC – as all our RFCs – would very likely be dominated by discussion and arguments in English. You can see similar things with Korean Wikipedia, another significant Wikipedia with similar patterns and no participation here. German Wikipedia, on the other hand, already has more restrictive measures in place as they’ve turned on flagged revisions for unregistered and new edits, meaning that edits from these accounts need to be accepted before they’re visible to logged-out users. Or Arabic Wikipedia, where we went looking for feedback on our tools, we didn’t get much specifics but people were happy about the idea of masking IPs. I’m not saying this to try to reduce the importance of the feedback here, just to point out how much things can differ across different parts of the movement. This page (including archived comments) has been edited by 122 users, excluding Foundation staff. 83 of these have monolingually English wikis as their home wiki, 78 English Wikipedia. That is 68% – or 64% for English Wikipedia only – of the participants, which doesn’t accurately reflect what the Wikimedia movement looks like. Based on this, historical examples and knowing what it is like to come from a non-English wiki, I’m also concerned that heavily affected wikis would have a difficult time fully participating in an RFC. Based on the data we have on IP participation in combination with the research Benjamin Mako Hill put together above, I personally worry blocking IP editing would simply kill most of the productive editing on some smaller Wikipedias, such as Faroese Wikipedia. I could be mistaken in that, of course. I would like to be.
Those are, I think, our main reasons.
This page isn’t well-defined because it’s not a proposal, by the way, it’s a technical investigation by a software team trying to build tools to help anti-vandalism work. We didn’t start this as a solution to something, but to understand the issues. We have to talk to the Wikimedia communities – here, locally where we can talk to people who don’t speak or aren’t comfortable speaking English, to especially affected groups such as the stewards and so on – to understand workflows for technical development. Being in the process of finishing up talking to a small number of wikis to see if their workflows and worries differ, we’d also be very interested in listening to the experiences of the SWMT if you – in the plural sense – be willing to, to guide further work on anti-vandalism tools.
May I ask a couple of questions? They are not rhetorical questions, I’m genuinely trying to understand your line of thought here.


You seem convinced that almost all wikis would reject IP editing in the light of this, yet the only example we have of wiki explicitly taking a decision on ”should we ban IP masking when IPs are masked” decided not to. Do you base this on this conversation, your work in the SWMT, or something else?
Why does this need to be decided now? Doesn’t it make more sense to see if the work to find technical support to handle masked IPs is successful, and base a decision on that knowledge, rather than now?
Lastly, I’m trying to understand why you think the Foundation – or the general Wikimedia community – should decide this for all wikis, rather than letting them decide locally. Is it because it would be a waste of time and resources to develop the tools we are working on? Is it because you’re worried small wikis won’t actually take any decisions, yet this will be an issue, causing more work for you in your cross-wiki anti-vandalism efforts? Or some other reason? While we do worry it would hurt that wiki, we have also offered to help in case a wiki wants to pilot trying to turn off.
I hope it at least explains where we are coming from. /Johan (WMF) (talk) 18:24, 4 June 2020 (UTC)
@Johan (WMF):, this is purely from an en-wiki editor, but some of your above points are still relevant so I thought I'd take the opportunity to comment on them and hope for a reply. I obviously can't provide SWMT relevant thoughts.
One of the issues with cross-wiki discussion being done that's not on meta, where the WMF is functionally a co-ordinating and an involved party, is determining what truly has been said and whether everything considered there, and here, was considered in both venues. Personally if discussion is going to be separated I'd prefer (cross) transcluding within a section, which would at least allow machine translating to give it a go - particularly important points could be properly translated. The WMF technical teams not being moustache-twirling villains, there's no deliberate issue, but I imagine you can see concerns about holding two roles in the discussion - confirmation bias is something none of us are completely immune to.
In terms of "why decide now, wait until tools and judge" would, ideally, be the logical route. The only issue is that with any organisation, but particularly those of significant size (whether that by the WMF or a large company etc etc), the more time, effort and money that have been put in, the harder it becomes to change cause and choose not to use them. Sunk cost fallacies become a real issue, and demonstrating then that that route should not be taken becomes really hard. This is particularly the case as it locks in the dichotomy between "block all IPs, or accept and implement the masking" - both of which come with major issues. A "default to masking, allow local wikis to disable (or a close variant)" is more logical.
Both the initial documentation and interim statements by NKohli indicated that some loss of vandal-fighting function was anticipated, especially in the short-term. The archives (which you may need to load and read manually unless someone can sort them out to be searchable properly) also have unanswered questions and specific pointed out issues - particularly with regard to relatively easy evasion of the masking info. Until those have been reloaded and answered as to how any loss of sock and vandal-fighting ability can be managed with masking, I and seemingly many others here are not likely to buy in. Nosebagbear (talk) 13:08, 5 June 2020 (UTC)


I'll probably cause some trouble for the WMF by writing this but they deserve some trouble. guys, when someone tells you vaguely about legal reasons on the internet there're two options. they're being d*cks or they've got legal reasons for being vague. my guess? they're not trolling. they're trying to tell you "like everyone else we have to follow GDPR" but can't say they're breaking the law and waiting a year to fix it so they hope you get the hint. or they'd have to start masking IPs tomorrow. maybe it's because I live in Europe but it has got to be this unless they're professional masochists and like being spit in the face. they're not going to have an RFC on following the law or not. 84.247.50.57 12:21, 2 June 2020 (UTC)

@84.247.50.57: A GDPR discussion has already been considered within this page's very unnavigable archives. The GDPR hasn't been amended since I worked in that field, and a fairly clear Legitimate Interest case can be made for why this personal data (that is, the IPs) should be public, because a masked version cannot be guaranteed to be as efficient (indeed, the opposite) as the current case. The WMF's legal team is excellent, and I'm sure the WMF can find a couple of souls in compliance good on data protection to write a good DPIA and an LIA to demonstrate that, assuming it's EU law they want to also meet. Nosebagbear (talk)

@Johan (WMF):, it's definitely important to continue supporting editing without logging in. Mako's and other research supports what many communities would say. A simple solution would be to mask IPs in edit histories but make them visible to all functionaries. Don't try to solve all problems at once, just change how edit histories look. This offers some basic privacy enhancement, and lets us get out a first-pass of a tool that autogenerates names for IPs, with no loss of countervandalism. Then roll out better tools for sock protection. Only then consider whether to go further. –SJ talk  08:33, 26 June 2020 (UTC)

@Sj: - that would cause a significant drop in countervandalism, and I don't think they'd planned on hiding the detail from CU/OSs anyway. The discussions from the early on point demonstrated the need for it to be seen by at least most editors in the field (even a limit to Admins would be a significant hindrance). Nosebagbear (talk) 13:00, 26 June 2020 (UTC)
@Nosebagbear: I think it should be fine for it to be visible to anyone who logs in and looks for it, just not the default in the history page. Similarly, though this is another issue, it should be fine for us to share non-oversighted deleted pages -- which would make deletion much more flexible and overeager AfDs less of a problem. –SJ talk  16:33, 26 June 2020 (UTC)
@Sj: - but you said "visible to all functionaries" - if the requirement was just to be logged in we wouldn't have any disagreements! Indeed, AC or even EC would be happily waved on. As to deleted pages sharing policy I can only speak to en-wiki's policy. One of the biggest causes of revdelled (but not OSed) pages is copyright breach - we couldn't share those without committing copyright breach ourselves. Others are attack pages etc, that still get requested back and obviously shouldn't be returned. Pages deleted on the basis of notability and similar at AfD will usually be shared on request to the admin, though it's not the auto-default like PRODs are, but that's really something to raise on a local project. Nosebagbear (talk) 17:21, 26 June 2020 (UTC)

Johan makes some very good points above. Jasper, there's no need to "reinvent the wheel" indeed: ways to have unregistered editing without showing IP addresses have already been explored by other wiki-like software, see also mw:Requests for comment/Exposure of user IP addresses. Consensus will need to be found for such a big change, but it will be easier to have a real discussion after something has been developed and tested. Wikimedia Foundation should also be free to develop such a feature for third-party wikis without using it on any Wikimedia wiki: in fact it would be an excellent way to get some real-world testing of the feature "for free" (i.e. without risks for our communities). Nemo 19:44, 26 June 2020 (UTC)

@Nemo bis: The issue here, and it's by no means a WMF-only issue (though there are plenty of examples to pick from), is it's a sunk cost case - having put significant developer time to make the offering, it makes it far harder to decide not to use it, even if the arguments still apply with the same strength. If the WMF were making commitments going "we'll make this, and it's entirely up to Communities the degree of implementation utilised) then obviously there'd be no concern. Nosebagbear (talk) 21:26, 26 June 2020 (UTC)
There is no sunk cost if the feature is used elsewhere. One just needs to be clear at the beginning that we're developing the feature because it's useful for MediaWiki, not specifically for Wikimedia projects. (I know WMF is bad at it, but sometimes in the future they might succeed!) Nemo 06:47, 27 June 2020 (UTC)
Except that the WMF clearly does want this for the WMF projects, so unless and until they change that (and critically, accept that), it definitely would be a sunk cost as they wouldn't be getting the main use they intended unless they went through with it. Nosebagbear (talk) 10:09, 27 June 2020 (UTC)

ArchivingEdit

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)

How would you want to set it up? Note that we – the team mentioned – weren't involved in archiving the discussions here. /Johan (WMF) (talk) 10:10, 1 July 2020 (UTC)

Local discussions about the toolsEdit

Hi everyone, we had a number of local discussions to gather information about workflows we could be missing due to differences between wikis and things we didn't know because of the language gap. To keep you informed about what we're doing and the tool feedback we're getting, we've written a simple report at IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools/Local discussions 202006. You can see the post that was used on most wikis in English here if you want to know what we were asking: IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools/Discussion starter. /Johan (WMF) (talk) 10:12, 1 July 2020 (UTC)

  • @Johan (WMF): For a set to tools to even be a viable claim of compensating for the damage done by a limitation in those who can't see and utilise all the information they could, we should logically have some criteria for that - with an assessment for some period of time before and a trial run of some length after. If extra tools will come on in the interim before masking may then grabbing some figures before then would be important. These criteria would need to be somewhat mixed, but would involve things like the level of time to handle bad edits, block negative editors, and dealing with IP socks (one of the more relevant bits on IPs), there's also an accuracy aspect that's a little trickier to determine, perhaps on viable unblocks etc. There's also a perception effort of users - if users drop parts of their efforts we'd be worse off even if the reduced remaining pool of editors were individually quicker. All this is open to probably a significant amount of discussion, but if you bring in a change and a local community is worse off it's not going to aid. This is particularly the case with a low-hanging fruit issue - I've still not heard (or, I hope not, missed) how the tools will make IPs as easy to identify they are now (i.e. changing cookie/session should not be enough). Nosebagbear (talk)
  • On a different tack, and hoping some negotiation might aid us, (despite the fairly convincing poll above), the archived discussion included some consideration from editors and NKohli on who would be able to see unmasked IPs. Obviously CUs can see everyone's IPs (in line with policy) and everyone can currently see IPs. I think there'd be functionally no resistance were that visibility set at AC or EC, but that appeared to be insufficient. A huge amount of work in this area is done by non-admins, so just limiting it to them would be an insufficient action. Perhaps a distinct userright at an agreed set of criteria might be the way to go (and as an additional benefit, particularly from the local community answers, local communities being able to limit to either "just CUs", "Just CUs & admins" and "CU, admins, userright holders" might further answer certain focuses. Nosebagbear (talk) 19:46, 1 July 2020 (UTC)
Return to "IP Editing: Privacy Enhancement and Abuse Mitigation" page.