Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives/2020-10

Support and Oppose List

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

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)
5. For 2 reasons: 1) It is really unbelievable that the Wikimedia projects have been subjecting their editors (both unregistered, and registered who accidentally log out) to such horrendous security and privacy flaws, by allowing IPs to edit the projects since their inception in 2001. It is false that people that edit unregistered are aware they are revealing their IP. I've experimented editing unregistered both with the Wikipedia app, and with Visual editor (wiki.pt), and in both cases I edited revealing my IP without any kind of notice or warning about it. Then there is no wonder that people risk losing their job and being arrested for editing Wikipedia unregistered. In some places, and depending on the controversy of the edition, this can cost their lives or the lives of their family. So, anything that can be done to improve privacy, such as IP masking, is very much welcome. 2) I am, nonetheless, convinced that masking the IP will cause a lot of very serious problems concerning vandalism management. In a Machiavellian way, this can be an advantage to the ones already struggling with the IP vandalism tide, as it may be the shortest way to effectively and permanently ban IPs from every Wikimedia project, as should have been done already in 2001.--- Darwin ^Ahoy! 19:00, 6 September 2020 (UTC)

Editors in opposition to this proposal

1. Computer Fizz
2. MER-C
3. Incnis Mrsi
4. Strong oppose – Just to be clear where I stand on this issue. My position has not changed. In short, this proposal is a very flawed, and a very, very bad idea. LightandDark2000 🌀 (talk) 22:24, 23 August 2020 (UTC)
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 ^talk_contrib. 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 (talk 桜 enwiki) 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)
94. Strong oppose If you want to make vandalism and resulting degradation of the encyclopaedia easier, go right ahead. Narky Blert (talk) 15:47, 19 September 2020 (UTC)
95. Strong oppose While I understand the WMF's desire to allow anyone to edit the encyclopedia, this openness invites all sorts of abuse. Anonymous editors make some good contributions, but those are vastly outnumbered by the trolls, bored kids, POV crusaders, etc. whose edits are simply destructive. The onus then falls on the cleanup crew, a cadre of volunteers who give their time to keep the encyclopedia reliable, accurate, and trustworthy. I'm speaking from experience with the English Wikipedia, where I've learned, first-hand, how difficult—and time consuming—it is to stop one persistent IPv4 vandal. It's even worse with IPv6, where mobile device infrastructure can change their addresses every five minutes. Volunteers donate (hundreds of?) thousands of hours to the encyclopedia each year; making these volunteers' work harder will only discourage them. Don't let the pendulum swing so far that volunteers are thrown under the bus in an effort to allow everyone to anonymously edit. I remember, some time back, prominent notes in key places cautioned anonymous users that editing without logging on can expose their IP address(es). Maybe this is a caveat that should remain and be expanded. One commenter (above) mentioned that his IP address was exposed when he used the mobile editor. If so, fix that. UncleBubba (talk) 19:34, 19 September 2020 (UTC)
96. Strong oppose IPs of all registered users should be publicly available in the edit history too. 73.148.104.176 12:58, 21 September 2020 (UTC)
97. Strong oppose This will make fighting vandals much more difficult, a large proportion of IP address contributions are not constructive, and this will only encourage the blanket removal of contributions by IP's further discouraging the editing by new users. Hemiauchenia (talk) 16:24, 22 September 2020 (UTC)
98. Super Extreme Ultimate Strong oppose This will single-handedly neuter the many, many years of work that your unpaid volunteers have done trying to stem the tide of trolling and vandalism on Wikipedia. Privacy is a great thing, but it's very hard to actually tie an IP address to someone in a meaningful way. If someone is at risk of government reprisal for editing Wikipedia, there are other tools at their disposal, and it's not Wikipedia's job to right that wrong. All the other arguments are just inane platitudes. MrAureliusR (talk) 17:29, 24 September 2020 (UTC)

Comments/discussion

( 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. SQL^{Query 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)

I support this idea in theory, but I would like it to be implemented in a way that doesn't hinder administrative functions (rangeblocking, etc.). Perhaps letting only admins see IPs would work as a compromise. PiRSquared17 (talk) 15:54, 19 September 2020 (UTC)

Except @PiRSquared17:, this discussion has already been had previously here (I don't know why the threads aren't archived in an easily searchable form) - lots of the identification that IP visibility needs is done by non-admins. A user-right, under a mutually acceptable set of criteria would be an alternative. I'm not sure what level of rigour would be required for that, but I'd be happy to have the discussion. Nosebagbear (talk) 16:07, 19 September 2020 (UTC)

Archiving

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. Nosebagbear (talk)

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)

Hi @Johan (WMF): - sorry, I'd completely missed this comment here, which given my statements on need for responses on other discussions is particularly poor of me. I'm also aware that your team isn't the ones who designated the archive set-up, so apologies if it felt targeted - it's more a general "better for all if fixed" hope. The only way to find the archives is a small link to "archive index", which then splits just by a list of chronological set-ups. A bigger link would be good, but what would be particularly desired is a search box for the archives - this is fairly common on en-wiki, so I was hoping it wouldn't be too difficult to do here Nosebagbear (talk) 12:44, 8 October 2020 (UTC)

Feedback on tools

Hey folks, IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools has our current thinking around tools to mitigate issues IP masking will bring. We're looking for comments both on those and if there are other things you need us to build. Please do see Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools. /Johan (WMF) (talk) 13:23, 15 October 2020 (UTC)

Feedback on persistence

We're also looking into how to exactly create the IP masking. To avoid as many problems as possible, we need to know how persistence or lack of persistence (that is: how to connect the identities over time) is causing or could cause problems for you. Please see IP Editing: Privacy Enhancement and Abuse Mitigation/Persistence and tell us all the things that could go wrong on the talk page. /Johan (WMF) (talk) 13:23, 15 October 2020 (UTC)

Third Party MediaWiki installs.

Hi, Could this at least be opt-in for third party installs? or at least a config flag to disable it? RhinosF1 (talk) 21:08, 16 October 2020 (UTC)

Looking into this, RhinosF1. /Johan (WMF) (talk) 08:46, 17 October 2020 (UTC)

RhinosF1: I'd really recommend going with some sort of masking for the same reason we're doing it, but it won't be forced on third-party installations. /Johan (WMF) (talk) 20:40, 19 October 2020 (UTC)

Of course we'll consider any meausres you put in place on the legal and community approval sides but I just wanted to make sure it would be optional. RhinosF1 (talk) 08:43, 20 October 2020 (UTC)

Range information

It is absolutely necessary that recent changes patrollers and administrators have access to IP range information. The ideas in IP Editing: Privacy Enhancement and Abuse Mitigation/Persistence are wholly inadequate in that regard. As Hemiauchenia wrote on the talk page there, using a persistent range-preserving mapping such as Crypto-PAn is necessary. Furthermore administrators need to be able to access WHOIS-Information so they can make informed decisions about blocking parameters. It is something quite different to block a range of a company compared to a range of dynamic IP addresses of a local service provider. --Count Count (talk) 08:01, 19 October 2020 (UTC)

Hey Count Count, thanks for the feedback, much appreciated.

As a general comment, just want to point out that a lot of folks seem worried that we have presented implementation specifics that we feel prepared to put into reality, unless they protest. I just want to be clear this is not the case: because we know how complicated this is, we have no ambition to suggest how to move forward until we have heard the concerns. We figured that we needed to involve the communities very early in the planning process, rather than coming up with a plan before talking to you. It might be helpful to understand this more as a technical investigation than a proposal for how to move forward.

We're working on tools to serve key WHOIS info such as owner (company or ISP?) to everyone who needs it, not just admins. See IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools#1. IP info feature and feel free to comment on those plans. /Johan (WMF) (talk) 08:34, 19 October 2020 (UTC)

Is that cleared with legal? Giving everyone access to personal information such as GEO location, organization, etc. might be just as problematic as the IP address at least under the GDPR. --Count Count (talk) 08:54, 19 October 2020 (UTC)

@Count Count: We don't plan on giving everyone access to personal information. In the series of interviews we did with checkusers and patrollers it became very apparent that their jobs are really hard and not having access to IP Information readily available is part of the complication. They rely on external websites that are broken or misleading quite often. Also different editors rely on different websites creating inconsistencies in data. The feature we are building is focused on making it easier for patrollers (including checkusers) easier to detect where an IP is coming from and get some basic information available at their fingertips. We are yet to decide which group of users will have access to this information but rest assured it will not be handed out to everyone. I'd love to hear your thoughts about this. Thanks much. -- NKohli (WMF) (talk) 04:21, 20 October 2020 (UTC)

(Just to clarify: by "everyone who needs it" I didn't mean "everyone", I meant "everyone who needs it from our perspective of vandal fighting". /Johan (WMF) (talk) 17:07, 20 October 2020 (UTC))

On dewiki we have quite few recent changes patrollers who are able to check the edits of an IP, find out if it is dynamic or static, check the WHOIS information and the block log as well as the same for ranges including that IP. They often remember if they saw similar unconstructive edits from IPs in the same /x range recently. They are then able to include valuable insight in their vandalism reports. If at all possible knowledgable recent changes patrollers (non-administrators) and administrators should have access to information about anonymous editors including WHOIS, geolocation, range information, edits of those ranges, etc. --Count Count (talk) 17:40, 20 October 2020 (UTC)

Going forward: IP masking happening, where there's flexibility

Hey folks, I wanted to acknowledge that there’s been plenty of concerns raised about this, in the archived discussions and not least this list. Thank you for your concerns, everyone. We need to understand all issues around this.

There are some questions we’ve been unable to answer with the requested amount of detail. They have been where we can’t answer because of legal aspects; and where we weren’t able to describe our specific plans or implementations. We didn’t have answers to this second type of question, because if we have the hows ready for something like this before we talk to the communities we’d be asking for disaster. You need to be part of this if it’s going to work.

We’ve been talking internally to get a sense of understanding of what we can do and what we can’t, and the Legal department has clarified their guidance for the project and emphasized the importance of getting this done. If the Legal department tells us we have to do something for legal reasons – which they unfortunately can’t explain publicly in more detail without risk to the projects – we have to take this and do the best we can within the bounds we've been given: the status quo can't remain, and we have to do something about the ways we handle IPs for non-registered users.

But how we do this is yet to be determined. We have some flexibility, so we are trying to figure out how to best do it. We have a page specifically on this. Please do let us know: we’ll need as many use cases as possible. We also don’t have to throw the switch this month, or next month: we are committed to figuring out how to offset the issues this will cause by building new tools. We’re looking for your comments on them too. And please continue to let us know what your main concerns are, so that we can try to work around them as well as we can.

There are a lot of very valid concerns. We’re listening to these and adapting as well as we can. However, please understand that this is something we have to do one way or another, and there’s no available strategy here that is without risk. We do understand the potential this has to create problems for the wikis, though we’re optimistic that by learning from your experiences, we can build tools that will help you offset that and come out with no greater burden than you had a year ago. /Johan (WMF) (talk) 13:23, 15 October 2020 (UTC)

@Johan (WMF): Can we get an official statement from Legal on this? --Rschen7754 19:14, 15 October 2020 (UTC)

Rs7754: Yes, coming. /Johan (WMF) (talk) 03:40, 16 October 2020 (UTC)

@Johan (WMF): I don't mean to be a bother, but it's been days now. Do you have a ballpark idea on when we might hear from Legal - whom ordered this? SQL^{Query me!} 07:10, 21 October 2020 (UTC)

SQL: When I asked them towards the end of last week, they were aiming for some point this week. /Johan (WMF) (talk) 08:17, 21 October 2020 (UTC)

(But it could also be next week. /Johan (WMF) (talk) 08:32, 21 October 2020 (UTC))

Is the IP masking retroactive for all IP edits made on all projects so far, or is this only for edits made after the IP masking is implemented? Hemiauchenia (talk) 22:16, 17 October 2020 (UTC)

Hemiauchenia: Per current plans, only the ones after IP masking is implemented. /Johan (WMF) (talk) 05:54, 18 October 2020 (UTC)

@Johan (WMF): Could you please explain what is actually meant by "IP masking"? The term sounds rather vague. In particular, does that mean that won't be able to look up the contribution history for a particular IP editor? And to tell that two edits were made by the same IP editor? In the history log for a given page, would all the IP edits just by marked by something like "anonymous IP editor"? Or would you try to assign to them some sort of internal identifying numbers, e.g. "anonymous IP editor 3233", "anonymous IP editor 3234", etc? Thanks, Nsk92 (talk)

Nsk92: It means that we will somehow need to replace the IP with something else, but definitely individualise them, using some sort of alias: I don't see how we could work with non-registered edits if they were all treated as one user. We are looking for feedback on exactly how this would work. Please see this page. /Johan (WMF) (talk) 05:54, 18 October 2020 (UTC)

The first question I'd have here is whether an RFA or RFA-like process would be sufficient to access IP material. The tooling needed will differ dramatically based on that point. power~enwiki (talk) 04:20, 18 October 2020 (UTC)

power~enwiki: Important question. We will need to figure out what the potential legal aspects of this detail are before I can give you a good answer. /Johan (WMF) (talk) 05:54, 18 October 2020 (UTC)

So we have this alleged "directive" from legal that IP masking MUST!!! happen, but I am to understand that there has been absolutely no thought on how it would actually be implemented? I wish I could say that I was surprised. Anyone with +sysop must be able to see IP addresses and contributions for IP addresses and ranges, they must be able to review block logs and place blocks, in the same way that they can today. Not on some masked "anonymous user 2351/64", but on an IP address or range that can be run through WHOIS and proxy checkers and cross-wiki contributions checks. On the other hand, if you expect admins to continue to clean up vandalism and worse while breaking all of the tools that they rely on, the only possible conclusion is that whoever came up with this idea is dramatically out of touch with the day to day operations of the wikis. ST47 (talk) 16:06, 18 October 2020 (UTC)

ST47: IP masking is not going to happen tomorrow. We have specifically tried to talk to the communities long before we have the solutions because we need vandal fighters to be involved in the process. With that said, there's been plenty of thought on how it could be implemented, both internally and in the archives here. What I'm saying is that the team responsible for this are adapting to a new situation and there are some implications we're still figuring out, but we also don't want to keep important information like this from the communities. The only way we could have the solutions ready would have been if we had tried to solve this without involving the communities, which I think would not have ended up well.

Our goal is to have as much tool development as possible before we mask IPs. If we just wanted to mask IPs, we could do that in a couple of days. This is a long-term project because we're trying to fix as many of the issues as possible. Telling us what you see as the most prioritised issues are is helpful; the ones others see aren't necessarily the ones I concentrate on, for example. /Johan (WMF) (talk) 20:57, 18 October 2020 (UTC)

ST47: Also, by the way, since you're a member of the SWMT – are there any SWMT-specific concerns you think we should be aware of? Do they differ in any way from the problems you're seeing for English Wikipedia? /Johan (WMF) (talk) 21:17, 18 October 2020 (UTC)

• Two points, @Johan (WMF): - one is that you note that Legal requires it, but "which they unfortunately can’t explain publicly in more detail without risk to the projects" - the WMF has always pushed for transparency, so why can't it be explained in more detail? If there's a legal argument for it based off public laws (as opposed to say, a contract) then transparency should be taking precedence - especially in the case of an action that is going to cause in-ordinate disruption to every (non-pt) community. In more implementation-oriented direction, the early discussions with NKolhi and team indicated that they'd been surprised but accepted how much activity in this field was carried out by non-admins. Unless the replacement can guarantee 100% of the same ability, in all circumstances, for non-admins, the information barrier needs a lower threshold than a passed-RfA, probably on a userright basis. Nosebagbear (talk) 19:07, 18 October 2020 (UTC)

Nosebagbear: I don't know what they'll be able to say, but Legal has promised a statement in addition to what I've written here, hopefully next week if nothing gets in the way. /Johan (WMF) (talk) 20:57, 18 October 2020 (UTC)

@Johan (WMF):, I'll keep my eyes out for that, are you in a position to reply to the second half of my comment (obviously it's a weekend atm)? Nosebagbear (talk) 22:37, 18 October 2020 (UTC)

Nosebagbear: Nothing beyond what I could give power~enwiki in Special:Diff/20547191, i.e. that I will have to get back to you on that, I'm afraid. /Johan (WMF) (talk) 06:30, 19 October 2020 (UTC)

• • My reading of the passage "for legal reasons – which they unfortunately can’t explain publicly in more detail without risk to the projects" in Johan's original post is that WMF wants to maintain plausible deniability here. They apparently think that they are already exposed to some substantial legal liability on this issue in some jurisdictions and explaining publicly could be used against WMF in some lawsuits later on. There may be some validity to that argument but on a larger scale it is basically BS. The fact that this thread even exists is already proof positive that WMF is aware of it current legal exposure on the issue, and I doubt that making the reasons public would make that much of a difference. As others noted above, transparency is a key basic principle of WMF and of all of its projects. I believe that in this situation WMF owes us a much fuller explanation of the reasons for its actions than what has been offered so far. That is especially the case in view of the overwhelming opposition that this proposal received here on Meta just a month ago, Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives/10-2020. If somehow it turns out that the potential legal liability to WMF created by the current practices with unmasked IP addresses is really extremely severe (and so far we have not been provided explanations to that effect), then the correct solution would probably be to just institute mandatory account registration across all WMF projects and disallow any IP editing at all. Masked IP editing creates too many problems that are too difficult to mitigate, not just with straightforward vandalism, but with other forms of disruption such as sockpuppetry, meatpuppetry, block evasion, etc. It's just not worth the trouble. Giving every IP an individualized alias is almost a form of registration anyway, except that they haven't chosen a password. We might as well make them do that. Nsk92 (talk) 20:33, 18 October 2020 (UTC)

Nsk92: Not being a lawyer, I really can't comment on the legal aspects of this, but as a data point, my home wiki has specifically decided against turning off IP editing in the light of IP masking, for example. (: The role IP editing plays across the wikis varies a lot. Not trying to get into an argument about the best way forward here, merely trying to explain why we think it's worth investing a couple of years of work in trying to solve the problems instead. /Johan (WMF) (talk) 20:57, 18 October 2020 (UTC)

"Not being a lawyer, I really can't comment on the legal aspects of this." User:Johan (WMF), sorry, but once again, I call out BS on this point. The only thing that not being a lawyer prevents you from doing is arguing a case in court. You most certainly can comment on the legal aspects of the reasons behind this WMF move. We all got brains and the ability to use reason and rational arguments, at least I hope we do. We routinely have to delve into fairly complicated laws when we deal with copyright issues on various wikis. Similarly, we discuss various legal cases and court decisions at talk pages of Wikipedia articles about them, or about judges who wrote relevant opinions, and nobody asks to verify if an editor has a law degree in order to edit such an article. Of course, in real life we do the same too, when we deal with various legal matters, in our own lives or in politics and public life. We don't suddenly switch off our brains and say: "I am not a lawyer so I can't comment on the legal aspects of this issue." It's not rocket science. We all can comment on legal matters and so can you. Nsk92 (talk) 21:42, 18 October 2020 (UTC)

I would feel a lot more comfortable about Legal's "we can't speak publicly about it" statement IF anyone who has been elected "bureaucrat or higher" and is still in good standing, or others who has signed an NDA already for other reasons such as OTRS, had the opportunity to get the full details from the legal team, even if a separate, purpose-written NDA was required. Notice I said "opportunity" - what is heard cannot be un-heard, so it should be "on request" rather than "pushed out" to people who hold high privileges. If more than handful of "highly trusted users" on the English Wikipedia were to say "yeah, we got the full deal, yeah, they really can't talk about it, and yeah, it really is one of those things we have to do" I'd feel a lot more comfortable, especially if at least half of them were currently serving in an elected position or had gone through an RFB-like procedure. Those on other large projects deserve similar respect. Those on small projects may have to rely on the words of stewards and other cross-wiki highly-trusted editors. Davidwr/talk 21:17, 18 October 2020 (UTC)

It does seem likely that the "WMF is already subject to major non-compliance" would be the only reason to want to hide it that might hold up (Legal teams in general are reticent to provide unwarranted information, so I can see them desiring not to spread it even if that weren't the case, it would just have less justifiability to it), but if we're currently in major breach then logically an emergency shut-down of IP-editing for 6 months would be the action. If it's an impending risk (technically all risks are impending, but still), say, from upcoming US law, then there'd be no issues with stating that. Nosebagbear (talk) 22:37, 18 October 2020 (UTC)

Davidwr, I assume it depends a lot on why they can't speak publicly. While this is very far from my field, I assume if they're subject to some sort of gag order or similar, getting someone to sign any NDA is not going to be enough. They need to convince a court to allow them to disclose it under said conditions which may be difficult. Likewise, if they don't want to speak publicly because they don't want to give any ammunition to a legal opponent, then I suspect this also isn't going to work. Getting someone to sign an NDA probably won't affect that you've communicated it with some random person and therefore protections against enforced disclosure (attorney-client privilege etc) may go out the window. (As someone pointed out above, the very fact this has occurred poses a risk. Still I can imagine the risk may be lower if all you have is this and whatever limited carefully vetted statement they eventually put out compare to having the exact opinion of the legal team to show a judge or jury.) Nil Einne (talk) 07:24, 20 October 2020 (UTC)

• I can't reconcile 'We also don’t have to throw the switch this month, or next month' with 'which they unfortunately can’t explain publicly in more detail without risk to the projects'. If the risk is indeed so material, I can't understand the delay - and if it isn't, I can't understand the non-disclosure. I would be keen to understand whether Legal has engaged external counsel on this, whether an impact assessment has been done, and whether the Board has endorsed the approach also. I do think Legal have missed a trick by not having a statement ready to go. Best, Darren-M (talk) 10:02, 20 October 2020 (UTC)
• @Johan (WMF):, I realise "don’t have to throw the switch this month, or next month'" wasn't meant purely literally, but I do hope the timeline on this is not tight - getting CluebotNG (which has an easier mission that identifying similar-looking editors) into a form where the false positives weren't too high took a lengthy period of time. All the previous documentation states that the tools would be up and running before any switch-over (since we are apparently going ahead, despite the fact that I still can't see how we're going to get 100% equivalence even if tools all work as desired). Nosebagbear (talk) 10:50, 20 October 2020 (UTC)

It's not a tight timeline. I'll get back to you on more details when we have them. (I realise I'm saying this a lot, but we really wanted to involve the community as early in the process as possible, and that means not spending a lot of time first keeping silent on this while figuring out everything internally.) /Johan (WMF) (talk) 17:11, 20 October 2020 (UTC)

A lot doesn't make sense here. If this really is some sort of legal compliance issue, IP editing should at least be temporarily disabled while solutions are figured. I think we need that statement from Legal sooner rather than as later, and to at minimum at least know which jurisdiction's laws they think require such a step. Unless the answer is "the US", the answer there might be "Time to pull out of that jurisdiction." I work in tech, and I have never once heard of US-specific law demanding that IP addresses be kept secret. Seraphimblade (talk) 19:36, 21 October 2020 (UTC)

@Seraphimblade: - the USA or EU would both be rather too problematic to consider a withdrawal, at a bare minimum (if that is the issue) Nosebagbear (talk) 19:47, 21 October 2020 (UTC)

Quite honestly, if EU law is messing with us in that way, I think there's no better time than the present. But it would certainly be good to know which law it is—some of us in the relevant jurisdiction might be very interested in talking to our legislators about it and encouraging others to do the same. If it were US law, you better bet I'll be calling up my Senators and Congresscritter. Seraphimblade (talk) 19:57, 21 October 2020 (UTC)

• Isn't this an indication that we should only allow registered users to edit WP? Just think - no more vandalism, a sharp reduction in backlogs at AfC and NPP because editors won't be wasting their time fighting vandals and can focus where their time is more productive, and we'll have a better shot at ensuring accuracy in our articles instead of worrying about drive-by kid games. I don't think the arguments for allowing IP editing are as convincing as they were in the earlier days of WP. It's not a big deal to register, or get an IP exemption. A grammar/spell check algorithm can be created by WMF to fix what some drive-by IPs do. IPs are already restricted in several ways, so why not just eliminate it all together? Atsme^📞📧 14:50, 23 October 2020 (UTC)

A huge amount of vandalism is done by short-term accounts and if we canned IPs, obviously we'd see even more of them. So I wouldn't think we'd lose more than a tithe or so of vandalism. And getting an IP exception is quite hard if you don't have a pre-standing link with the site. The main reason is that even though individuals are more willing to create accounts than was in the case in 2001, we still get lots of new editors joining the site having initially experimented with some IP edits. Nosebagbear (talk) 14:54, 23 October 2020 (UTC)

I've addressed this elsewhere, but in short, at least an explanation of why we think it's worth investing a lot of resources instead of going with just turning IP editing off: IP editing is important for editor recruitment and we're afraid we'll significant harm the wikis if we just turn off unregistered editing. For example Swedish Wikipedia has explicitly discussed turning off IP editing in the light of IP masking and decided not to, since they don't seem to consider IP masking to be much of a problem, or the see the discussion when Arabic Wikipedia discussed it. And IP Editing: Privacy Enhancement and Abuse Mitigation/Research shows there are significant differences in how important IP editing is for wikis, with some wikis depending on IPs to a considerable degree for their content even when you ignore the role it plays in editor recruitment. Personally I worry it would almost completely kill some small wikis, like Faroese Wikipedia.

(For those unfamiliar with the English acronyms: NPP refers to the new page patrol, patrolling new articles. AfC refers to the English Wikipedia w:en:Wikipedia:Articles for creation, a system where unregistered and newly registered users can't create articles directly but has to guide them through a system. A similar system is used on a few other wikis too, but the vast majority of Wikimedia wikis and Wikipedias don't have an equivalent, if you can't find it on your home wiki.) /Johan (WMF) (talk) 13:58, 26 October 2020 (UTC)

Minors

I often get the vibe that some of our most enthusiastic recent changes patrollers are a long way from 18. Will younger editors be eligible for the new user right, even though they aren't eligible for CheckUser access? Suffusion of Yellow (talk) 02:04, 26 October 2020 (UTC)

This is a good point that I don't think we had thought about. Thank you. /Johan (WMF) (talk) 00:33, 27 October 2020 (UTC)

Rangeblocks

How will rangeblocks be handled? Will admins be able to block ranges larger than a /24? Will more privileged users be able to block smaller ranges? In each case, how will the block be displayed in the public log? For example suppose an user will "full IP" access blocks 1.2.3.192/26? Then, an "ordinary" admin considers blocking 1.2.3.0/24. Will they even know that that a block already covers 1/4 of the range? Suffusion of Yellow (talk) 02:10, 26 October 2020 (UTC)

Just wanted to note that rangeblocks is very high on our to-do list of technical investigations. The use cases and questions around this are most appreciated. Thank you, Suffusion of Yellow. /Johan (WMF) (talk) 14:27, 26 October 2020 (UTC)

Now that I think about, it is vitally important for all users to know when a masked IP is blocked. Otherwise, there will be endless redundant reports of whatever malfeasance the IP was up to. Suppose 1.2.3.4, 1.2.3.40, and 1.2.3.44 spam the same racist garbage across the wiki. The usernames seen by "normal" users are "Anonymous #98761111", "Anonymous #98762314" and "Anonymous #98760013". Now we have this problem:

• Alice, with no special privileges, checks if each anon is blocked, finds not, and reports them.
• Bob, who is a CheckIP, find they are all in the same range, and blocks 1.2.3.0/26. This is recorded as a block of "Range #654032/26". Problem solved, right?
• Carol, with no special privileges, checks if each anon is blocked, finds not, and reports them.
• Dave, with no special privileges, checks if each anon is blocked, finds not, and reports them.
• ...

It's also important to know when the block expires, and who blocked them. But if you include that it any information about "Anonymous #98761111" and "Anonymous #98762314", then any user can connect them with each other, from the identical timestamps.. And any user "inside" the range can now recognize users from the same range. Which I don't have any problem with (hence my suggestion of using Crypto-PAn, above), but I gather WMF-legal does. Suffusion of Yellow (talk) 17:26, 26 October 2020 (UTC)

Well...

If you want to mask IPs, I'd rather take the plea of ptwiki and require signup to contribute. (Permalink)

IPs protected (from the public), and the ptwiki community got their wishes fulfilled. Two problems solved once. (BTW, if you are going to use "Legal told us so", why all the "consultations"?) — regards, Revi 20:58, 16 October 2020 (UTC)

revi: There's a section in the FAQ, but in short, here are some of the main reasons why we're doing a long-term project on this, attempting to come up with new tools and spending significant time and resources instead of merely turning off unregistered editing across the projects:

IP editing is important for editor recruitment and we're afraid we'll harm the wikis if we just turn off IP editing. For example Swedish Wikipedia has explicitly discussed turning off IP editing in the light of IP masking and decided not to, since they don't seem to consider IP masking to be much of a problem. And IP Editing: Privacy Enhancement and Abuse Mitigation/Research shows there are significant differences in how important IP editing is for wikis, with some wikis depending on IPs to a considerable degree for their content even when you ignore the role it plays in editor recruitment. Personally I worry it would almost completely kill some small wikis, like Faroese Wikipedia.

With regards to the "Legal told us this has to be done", I want to stress that we didn't know we'd end up with this when we started this project. We haven't been hiding it: we learned it recently which is why we're telling you now. It did come from Legal, but it wasn't clear that we'd end up with "and the status quo can't remain". Second, our main goal was never to present an idea and get a yes or no: we didn't have a clear suggestion for what to do. We needed to talk to the communities to understand their concerns and technical wishes, so we can do our best to find solutions to these – involve the communities early in the process. We're still looking for feedback on tools and collecting use cases so we can avoid creating unnecessary problems. /Johan (WMF) (talk) 06:27, 17 October 2020 (UTC)

I'm still confused on a pretty major point. The FAQ says: We think that deciding for all wikis that they can’t have IP editing is a destructive solution. However, here it seems you are refuting the idea that a wiki (in this case ptwiki) itself cannot decide whether turning off IP editing is appropriate for their own community. I mean, maybe Portuguese Wikipedia doesn't want to prioritise editor recruitment, so shouldn't they be allowed to make that decision? –MJL ‐Talk‐^☖ 07:00, 17 October 2020 (UTC)

MJL: Sorry, I probably took revi's comment to be more generalised than it was meant to. The Portuguese Wikipedia case has been addressed to the board, which is quite beyond what this team can act on. You're quite right it has implications for both what we've said previously – we've talked about helping a wiki pilot limiting IP contributions to get more data if they wanted to go that way – and this conversation, and I'm not trying to ignore that, nor refute anything. It's just grown into a process we're also trying to figure out before we can give a good answer. /Johan (WMF) (talk) 08:39, 17 October 2020 (UTC)

(The TL;DR of the comment above is "will have to get back to you on that, which might take a while". The rest is just trying to be transparent about why. /Johan (WMF) (talk) 10:12, 17 October 2020 (UTC))

@Johan (WMF): No, that's fair. -revi was being pretty sardonic in that comment, so it's not unreasonable to just imagine it as sarcasm. If you need a wiki to work with in the future to implement a ip pilot program, Scots Wikipedia would certainly be interested in discussing that to say the least. –MJL ‐Talk‐^☖ 21:56, 17 October 2020 (UTC)

• This entire proposal remains an awful idea. Vandal-fighters and admins rely on IP addresses in order to identify and block vandals and abusers. The persistence and subnettability of IP addresses is essential to this work. If IP masking goes into effect, it will be impossible to place a range block without being a checkuser, as you need access to the complete WHOIS information in order to calculate the correct range, and access to the complete contributions in order to check collateral. Even regular users need to be able to view the contributions, block log, and talk page history of an IP address in order to determine how to respond to various types of disruptive editing. Forcing IP masking on the communities will result in more wikis taking the route of disabling anonymous editing, in all namespaces, so you might as well just acknowledge that that is the decision that you're making here, and update $wgGroupPermissions['*']['edit'] = false. Once the communities see that their anti-vandalism and anti-abuse workflows have been completely upended, they will make the same decision. ST47 (talk) 15:53, 18 October 2020 (UTC)

ST47: I've replied to the point about turning off IP editing above, but honest question, if you've got time (and totally understandable if you've got something else to do, of course): Why do you think regular users wouldn't have access to the contributions, block log, and talk page history?

Also, are there any particular situations with regards to persistence you think we should be aware of? /Johan (WMF) (talk) 21:07, 18 October 2020 (UTC)

@Johan (WMF): This masking cannot stand. Disabling unregistered editing is better in every way. Everyone else has already explained why. If transparency is the goal here, why is this not being acknowledged? Naleksuh (talk) 22:04, 19 October 2020 (UTC)

Hi, Naleksuh, we’re hearing you (and the others). And we are taking it seriously. Let me reiterate why we think that investing a lot of time in trying to solve the problems involved – we know we haven't, by the way. We're talking to the communities to figure out this together, not to present you with a solution that we've tried to come up with on our own, without community input. I completely understand looking at the situation today, imagining what it would look like if we turned on IP masking, nothing else changes, and think it'll be really bad on some wikis (but not necessary all – IP editing and spam patterns vary a lot across the wikis).

This page, and its archives, is not the total sum of Wikimedia community discussion on this subject, because Meta conversations are vey dominated by English which shuts out a lot Wikimedians. Here, for example is a community discussion on the subject asking the question "in the light of IP masking, do we want to turn IP editing off?" with other perspectives. Or the very varied results when Arabic Wikipedia discussed it.

The researchers who have been trying to look at what the effects would be are really afraid of the long-term effects it would have. But, as I wrote above, we’ve said we’re open to take a closer look together with a suitable community. For example, w:en:User:Benjamin Mako Hill wrote up IP Editing: Privacy Enhancement and Abuse Mitigation/Research. /Johan (WMF) (talk) 17:30, 20 October 2020 (UTC)

Sorry, just realised I linked to the wrong research page. That's just data of Wikimedia wiki usage. I wanted to point to Research:Value of IP Editing. /Johan (WMF) (talk) 17:47, 27 October 2020 (UTC)

The mask will need to be the same on all WMF wikis

Just a reminder. If the mask is different on each of the 700+ wikis, then you've made it impossible to even detect cross-wiki vandalism and spam. Even if stewards can globally block the real IP, no one will ever report anything to the stewards unless they know there is something to report. Suffusion of Yellow (talk) 17:44, 26 October 2020 (UTC)

I don't think it had ever occurred to us to consider making them local, to be honest. They will be global. /Johan (WMF) (talk) 15:51, 27 October 2020 (UTC)

Legal statement timescales?

When can we expect to get the statement from WMF Legal on this? A lack of understanding of what has driven the policy seems to be the main comment being made by editors and one that seems to be stopping us engaging meaningfully with the actual technical solution. Best, Darren-M (talk) 12:46, 27 October 2020 (UTC)

I would expect it this week. /Johan (WMF) (talk) 15:51, 27 October 2020 (UTC)

But I do want to temper expectations: If Legal could be clear and explain in detail, my earlier statement would have been much clearer on that point. /Johan (WMF) (talk) 14:09, 28 October 2020 (UTC)

Communication plans

We're planning to communicate this more widely soon – there's a lot of things happening right now, and we don't want to overwhelm the communities with so many things at the same time they've got no chance to react, but we also didn't want to sit on major updates and not tell you. /Johan (WMF) (talk) 13:27, 15 October 2020 (UTC)

For the next steps, this is going out in Tech News on Monday. w:en:The Signpost also reached out and requested a text, so we've written one for them mainly explaining the things we've tried to explain on this talk page, but in a more coherent fashion. /Johan (WMF) (talk) 21:48, 29 October 2020 (UTC)

Old blocks

What happens to all the blocks from before the masking? If they carry over, then it will be trivial to connect the masked IP with the real IP, from the timestamp, blocking admin's name, etc. If they don't, then how will we deal with the gigantic flood of vandalism when everyone gets unblocked all at once? Suffusion of Yellow (talk) 02:13, 26 October 2020 (UTC)

Good point. It's obvious possible, in theory, to assign a truly anonymous user name to each IP address with a prior edit history, and - perhaps more focused, to each IP address with a prior history of being blocked. Technically that might not be easy. And it would pretty much be impossible to hide the fact that (for example) Anonymous123QWR was blocked on June 13, 2020, for edits done under IP address [whatever], though I suppose that the association of the block information to an IP address could be restricted to being only viewed by admins.

The larger point is the discontinuity between edits done before and after the changeover by the same IP address - not only for problem editors (those with blocks), but also for those who should get credit for good (IP) edits, but won't now, and therefore are more likely to have their edits reverted, be taken for single purpose accounts, have opinions discounted in deletion discussions, etc. [I vaguely remember, from years ago, a very constructive and prolific editor who had a stable IP address - I think he/she ran his/her own server - and took it as a point of pride that he/she had never registered. That person, of course, may well no longer be editing ... ]. John Broughton (talk) 23:58, 28 October 2020 (UTC)

We will not unblock every blocked IP on the Wikimedia wikis. This is a very good point and one of the many things we'll have to hash out together, but I just wanted to make clear that the Foundation also considers removing old blocks to be an unviable option. /Johan (WMF) (talk) 16:40, 29 October 2020 (UTC)

Crypto-PAn

Has anyone looked into Crypto-PAn? This would mask IPs while preserving range information. As originally specified, it only works for IPv4 addresses, but it might be possible to modify it to support IPv6 as well. Suffusion of Yellow (talk) 20:23, 19 October 2020 (UTC)

Yes, please go for Crypto-PAn or something equivalent. Ordinary editors like myself fight a great deal of vandalism and it's better for everyone if you allow us to continue doing so. We don't care about the exact IP address but we do need to be able to:

1. find contributions from adjacent IPs, especially within a v4 /24 or a v6 /64
2. determine whether two contributions are from similar IPs
3. communicate an IP to other editors, especially in a form which an admin can turn into an IP block if appropriate

Removal of access to IP addresses will always be a step backwards for us, but Crypto-PAn can repair most of the breakage. Certes (talk) 20:54, 1 November 2020 (UTC)

Treat all users on a /64 as one

Idea: Before masking, throw away the 64 low-order bits of IPv6 addresses. That is, everyone on a single /64 range is considered to be one user. This is the most common case where an unprivileged user benefits from knowing range information. This might cause trouble where one user on a home network gets lumped in with the "little brother" on another device, but that would have happened anyway if they had been using IPv4. And there might be some issues with weird ISPs (e.g. AT&T) where unrelated users can share /64 ranges. But I don't think there will be major problenms. In fact, I'd support this even if IP masking doesn't happen. (Pinging @TonyBallioni: for a second opinion here). Suffusion of Yellow (talk) 20:34, 19 October 2020 (UTC)

This is not workable. Verizon Wireless and its millions of customers are not allocated their own /64. They bounce around on a /40. This is true of a very large number of ISPs that have similar numbers of customers. NinjaRobotPirate (talk) 06:01, 22 October 2020 (UTC)

To be clear, I wasn't suggesting that merging /64s would be the magic pixie dust that would make masking IPs anything other than a disaster. But it might make it a slightly smaller disaster. On Verizon and similar ISPs, merging /64s would be pointless, but also harmless. It's only on AT&T-like ISPs that it could be harmful, and from my understanding those aren't all that common. Suffusion of Yellow (talk) 01:59, 26 October 2020 (UTC)

Some IPv4 customers also bounce around on a /24 or larger. However, many IPv6 customers bounce around within a /64 in a way that has no parallel in IPv4. They are a particular problem because we cannot effectively communicate with them: talk pages are specific to the exact 128-bit address which may never be reused. However, as mentioned above, Crypto-PAn would solve this problem, because we can ignore the lower 64 bits of the masked address and simply compare the high bits. Certes (talk) 21:02, 1 November 2020 (UTC)

Archiving

Hey everyone, this page has been regularly archived, but there were still some sections here. I've archived those too, in accordance with the existing system. I've been rather undecided on the best way to go about this, because we really don't want to hide away the fact that there's been a lot of concern and resistance (see the list here, for example), but my reasoning is as follows: a) We did a major update to the main page. The old talk page discussion doesn't really discuss the same page as earlier, which could be confusing. b) The old talk page belonged to a project which we hoped to be able to do, but were not entirely certain would happen. Now that the Legal department has clarified that we'll need to do this one way or another, getting people stuck in patterns of an old discussion and risk missing being clear about where there's flexibility would make it more difficult for them to actually influence what happens. /Johan (WMF) (talk) 13:23, 15 October 2020 (UTC)

Draceane: You unarchived an old discussion and put it at the top of the page. This will be very confusing for people who come here for the first time for a number of reasons. First, because it basically belonged to an older page – it's been heavily rewritten. Second, because our replies don't make much sense now, because the reality of what we're doing has changed – Legal has clarified their guidance and this changes everything we do here. But most importantly, because it tells people they are supporting or opposing a proposal, and this is simply not true. If we put that on top we're lying to editors new to this page, because this is not a proposal. Legal decisions are not and have not been a matter of community consensus. This is not new. A hundred or a thousand editors in opposition: as the entity legally responsible for the wikis, if our Legal department tells us something needs to be done for legal reasons, we are not free to take the community's preference into account.

By putting that on top, we'd be telling them this is a proposal and that putting their name under oppose or support matters for whether IPs will be masked or not. This is a lie. Most probably won't scroll down to read that it won't affect the outcome: they'll be thinking they're acting on something where they are asked to affect it. I really don't want to hide the opposition to this, and I'm happy to put the link to that part of the archive somewhere more visible (on the main page, in the FAQ maybe?), but we can't continue doing this while giving people the impression that this is a decision that hasn't been taken. Not only will that hide where they've actually got agency – that they can heavily influence how it's done – but it will also hide the hard truth here. A proposal that can be opposed or supported would make the Foundation look more open than what we're actually saying. /Johan (WMF) (talk) 14:06, 28 October 2020 (UTC)

I mean, Legal hasn't really told us we have to do it for legal reasons...they haven't actually told us anything at all, thus far. Nosebagbear (talk)

I think people are hoping for more than the Legal department, for legal reasons, are going to be able to say. If I could have shared more details from the beginning, I would have done so: we gain nothing by keeping information from the communities if we have the realistic option of not doing so. It just fosters conflict and distrust.

(Is linking to it from the FAQ on the main page a good solution? I don't want to sweep it under the rug, but we shouldn't steer people towards spending their energy making a decision because they were told there was a proposal to support or oppose when there wasn't.) /Johan (WMF) (talk) 16:41, 28 October 2020 (UTC)

• Johan (WMF) no opinion on the above but borrowing this space as it's relevant. Do we want to do montly archives, I think 3 months - 6 months is okay, or even a single one for the current archive system is near impossible to navigate. There isn't so much for 1 month I mean. Just my 2 cents. Regards, Camouflaged Mirage (talk) 17:02, 28 October 2020 (UTC)

I have absolutely no opinion and we weren't part of setting up this system, just to be clear – anyone should feel free to be bold and get an archive system they think works better. If no one does, I'll take another stab at it. I've never dealt with the bot that does the current work, and a brief look didn't immediately tell me how to set parameters for this, if possible. /Johan (WMF) (talk) 19:42, 4 November 2020 (UTC)

Anons and sockpuppetry

1. Alice is a troll. She wants to create an illusion of support for a position she is taking on a talk page. So, she registers multiple accounts, and uses a new one with each message.
2. Bob is also a troll. He also wants to create an illusion of support for a position he is taking on a talk page. He does not register, and lets MediaWiki auto-assign him a new mask with each edit. He is not too stupid to clear cookies.
3. Carol is not a troll. She does not register. She always uses private browsing mode, and her IP changes frequently, without her knowledge. She participates in a long discussion on a talk page, inadvertently using a new mask with each edit.
4. Alice, Bob, and Carol are all reported to the checkusers
5. Alice has no excuse. She didn't create multiple accounts by accident. All accounts are indeffed.
6. But Bob and Carol can both say "I didn't know, how did that happen? I value my privacy and can't control my ISP." How will we know that Bob is lying, and Carol is telling the truth?

Suffusion of Yellow (talk) 22:12, 31 October 2020 (UTC)

Thank you, Suffusion of Yellow. So these are situations we need to keep in mind, but just a few things for the discussion:

• Checkusers would be far from alone in having access to Bob's and Carol's IPs (see #Who can access the IP of an unregistered editor?).
• Carol, changing her IP frequently, would have similar problems today.
• We have not decided on how to create the mask, to use a cookie or not etc. We're looking for use cases like these (or completely different ones) here or over att IP Editing: Privacy Enhancement and Abuse Mitigation/Persistence, and more people who want to be part of this discussion.

/Johan (WMF) (talk) 22:52, 31 October 2020 (UTC)

@Johan (WMF): The point is that, today, Bob wouldn't try this, since it would be obvious to everyone that all the IPs are in the same range. He'd register accounts, giving up plausible deniability when he's caught. So we already know Carol is probably innocent. If most participants in the discussion can't see that all his IPs are in the same range, Bob can get away with this, then (unlikely Alice) play innocent when he's caught. Suffusion of Yellow (talk) 23:01, 31 October 2020 (UTC)

I'm not trying to convince anyone of anything here, and I'm happy you're throwing use cases at us – I just wanted to clarify, for the best possible discussion, e.g. that the use of cookies isn't anything that's been decided, so people don't assume it is when they try to find problems and solutions. /Johan (WMF) (talk) 00:02, 1 November 2020 (UTC)

As you probably are aware, if Crypto-PAn is used for masking everyone could still tell that the IPs are in the same range. --Count Count (talk) 14:11, 1 November 2020 (UTC)

Yep, already suggested that above, but so far no response. Suffusion of Yellow (talk) 18:47, 1 November 2020 (UTC)

@Suffusion of Yellow and Count Count: Hi. Thanks for this example. Like Johan noted above, we haven't yet decided how the actual masking will happen -- but I can assure you that we won't assign a new mask for each edit. We have been discussing what's a better way to mask and it has been brought up a few times that we might want to link that to a cookie - which serves as a better identifier because it's more likely to belong to the same person. IPs are getting more and more dynamic and consequently, less reliable. I want to really emphasize again that we are not pushing forward or making any decisions right now. All we are really looking for is ideas for what might be problematic and how we might address those problems. I appreciate this post. We haven't looked into Crypto-PAn yet but we will soon. Thanks for getting that to our attention. -- NKohli (WMF) (talk) 22:28, 5 November 2020 (UTC)

Make separate user right for "unmasking" IPs

A danger I fear: If only checkusers can unmask IPs, wikis will need to increase the checkuser count by an order of magnitude, just to keep up. That's an order of magnitude more accounts that could be compromised. So the unintended consequence will be to decrease privacy for registered users. Instead there should be a separate right, given out more freely than checkuser. Suffusion of Yellow (talk) 20:40, 19 October 2020 (UTC)

It will need to be a userright - more than admins (let alone CUs!) will need access. A discussion should be had with Johan as to what, presumably fairly strenuous, set of criteria will be needed, whether it will be globally/locally provided, etc. Nosebagbear (talk) 21:03, 19 October 2020 (UTC)

We're talking about what we can do, internally – it's been suggested before – and will get back to you as soon as I can with our thoughts around this. /Johan (WMF) (talk) 17:05, 20 October 2020 (UTC)

Who can access the IP of an unregistered editor?

OK, so this is what we're thinking right now: We could create a new user right, which would give access to the full IP. We could look into making it an opt-in function, dependent on yet undefined criteria. This could simplify bureaucracy but make access less flexible. The important part here is that we need to know who has access at any given point. I want to stress that we haven’t tried to answer all questions here, as we’re trying to solve this together with you.

An idea could be to create three tiers.

1. The vast majority of people who access our wikis would see the IPs fully masked.
2. All admins could see them partially masked (the first three parts of an IP being visible). This could be helpful to see patterns even if they don’t have the new user right. Partially masking them reduces the privacy risk for the unregistered user.
3. The new user right – in addition to checkusers and stewards – would have access to the entire IP.

Thoughts? /Johan (WMF) (talk) 17:02, 21 October 2020 (UTC)

First 3 parts, does it applies to ipv6 too? In addition, since it's privacy related, why not oversighters also have the full access? As we now OS logged out user IPs too. And the new userright seems so like interface admin, there are wikis which IAs are given like per request, while others are very strict. Will communities get to decide or WMF will mandate the process (or rather % of the new userright / admins etc). And will 2FA be needed for this right? Camouflaged Mirage (talk) 17:05, 21 October 2020 (UTC)

Camouflaged Mirage: Masking the equivalent information value of IPv6 addresses, to be clear. (:

I want to stress that this is a conversation starter to figure out what the different communities' needs are, rather than trying to define exactly how this would work – my examples are not exhaustive. There will be some sort of requirement from the Foundation, since this has to do with handling user data, but really, tell us what you think would work best? My personal best guess – not speaking for the team, just for myself – is that an automatic opt-in process would probably make requirements more similar across the wikis than if it was a user right that was manually assigned.

The 2FA question is a very good one. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

How would the automatic opt-in process work and what kind of requirements would it have? A certain number of edits? kyykaarme (talk) 19:37, 8 November 2020 (UTC)

kyykaarme: That's one of the things we'd have to figure out together, if we decide to go down that road instead of a user right the communities control handing out. Consider this more a discussion starter than a proposal. Would we need a certain period of time? How do we handle previous blocks? Do we see them as a sign of users who can't handle the norms of the wiki? What's the process for those who were unfairly blocked and immediately unblocked, or blocked themselves for some reason? And so on. /Johan (WMF) (talk) 04:00, 9 November 2020 (UTC)

It's difficult to give suggestions, when I don't know what the WMF requires from the users who can see IP addresses in the future. I first thought from your three tier plan that the user right would be between admin and CU, but then you said that it would be easier to get the user right than it is to become an admin in enwiki. Does that mean that the WMF is willing to give all one thousand+ admins in enwiki the new user right, if they want it? And then how many more users, a few hundred "trusted" vandal fighters, or a few thousand? From your comments I also understand that the users probably have to be adults and possibly sign the confidentially agreement (with their username). Checkusers often have a long history and are trusted by the community, but in the opt-in version this new user right will be given to pretty much anyone, it seems, as long as they contribute long enough and maybe haven't gotten blocked. And are you going to communicate to the unregistered editors that there are X amount of users who can see their IP addresses? kyykaarme (talk) 17:59, 18 November 2020 (UTC)

kyykaarme: Understandably. This is sort of a friendly rope pulling between the privacy requirements and legal necessities on the one hand, and our ability to defend the wikis on the other hand. We have a lot of people being concerned they wouldn't be able to handle spam and vandalism in the comments here and elsewhere, and we don't want to risk that, so we are talking about giving more people access than we'd have done if it was based on e.g. my needs as a vandal fighter on my home wiki (which isn't terribly concerned) and what would have been preferable from a privacy perspective. We're still in the process trying to find the right balance. I assume we'd want to keep some sort of warning that not logging in will lead to being more exposed as well as not having access to most preferences or a reliably permanent identity, like today but not quite the same. /Johan (WMF) (talk) 05:17, 19 November 2020 (UTC)

And I get that some of you will feel that it should be easier to get this user right than adminship, and look askance at why this would be necessary, but remember that while this talk page is currently dominated by users from English Wikipedia, the English Wikipedia Request for Adminship process is an outlier and we need something that works for all wikis.

If you’ve been around for nine months, have a thousand edits, been active in discussions in the Wikipedia namespace to show that you’re aware what the community is, and been somewhat active in patrolling, there’s a fair chance you’ll be completely unopposed in a request for adminship on my home wiki. On some small wikis, you’ll get a time-limited adminship when you request it and the two other users who turn up say sure, why not. The global minimum for permanent adminship on Wikimedia content wikis is five editors supporting you.

The process and requirements to gain adminship vary a lot. We figure that the ability to handle sensitive information here is below what’s currently required in e.g. the English Wikipedia Request for Adminship process, but above what the global minimum can mean in practice. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

I will suggest a mass message to village pumps in every wiki to solicit what every community thinks if this is what you hoped for. Thanks for the replies, appreciate it.Camouflaged Mirage (talk) 17:32, 21 October 2020 (UTC)

Yes, we're planning on some sort of MassMessage, to make sure vandal fighters on all wikis are aware of what's happening and how they can participate in the process. /Johan (WMF) (talk) 17:35, 21 October 2020 (UTC)

Thanks. One more, if we are speaking about global issues, how will wikis without local communities work, they are now patrolled by SWMT and global rollbackers, sysops, stewards handle the issues. Will these groups be granted access to the new userrights on these wikis? I understand the different rights systems as I edit wikis ranging from large ones (with local crats) and small ones (which I was once a perm sysop on a small content wiki). If we are saying we can accept users lower than enwp RFA bar and higher than perm sysop other wikis bar, then for enwp, sysops should be given the right to view full. One user in the middle range, let say a small wiki perm sysop + enwp rollbacker, he can see the IP address in homewiki, but not on enwp, if we trust them on one, why not all? Anyway the same IP user will be seen by the same person. I know it's hard to define what exactly is, I agree a massmessage will be proper, I think we might even benefit from a global RFC similiar to how global sysops is conceived for the new userrights. This will be benefical IMO. Camouflaged Mirage (talk) 17:41, 21 October 2020 (UTC)

Hmm, @Johan (WMF):, this is at least a good discussion benchmark. I thank you for your bottom half - I was absolutely going to step in and make a point that it should be lower, but of course you are right as regards variable levels for adminship. Hmm. I will have to have a think, please excuse the whirring hamster noises. I realise it continues the userright proliferation, but would it make sense to actually have two userrights (akin to edit filter helper and edit filter manager), the lower (partial vision) of which would be the "given to all admins", but could also be given to others under one criteria set - while the other (full vision) would be under a higher set? I'm not set on that, but would like to hear your and others' feedback. Nosebagbear (talk) 19:19, 21 October 2020 (UTC)

I think it would be logistically easier, if you go that route, to decide what global and local permissions the foundation considers this access equivalent to. If it's equivalent to the 'trust' for rollbacker, for example, then projects like enwiki might as well bundle the permission into the rollback user right. I'm not sure it should be a separate user right, imo that increases the burden/workload for all projects to have to start assigning that to people. ProcrastinatingReader (talk) 22:17, 30 December 2020 (UTC)

I think this proposal still lacks crucial details in that it says nothing about what exactly the regular users will see instead of an IP address. That is, 'how' will an IP address be masked? If you plan to assign the IPs individualized aliases, then how exactly will that work? That's not an aside question. E.g. will it be possible to tell that two individualized IP aliases for IP addresses from the same geographical area do come from a common geographical area? Or will the aliases be assigned randomly? Or perhaps in the same linear order as the IPs come online and make their first WP edits? Or using some other scheme? This question matters a great deal for anti-vandalism and SPI considerations, and the matter can't just be omitted from the above discussion. Nsk92 (talk) 23:12, 22 October 2020 (UTC)

Nsk92: Just to be clear, this isn't a proposal as much as it is a conversation starter. In order to solve these questions, we're trying to bring the communities into the process as early as possible, instead of trying to figure out everything on our own and risk missing crucial things. We're sort of taking the kind of conversation that normally lives in Phabricator and having it on the wikis where it's more accessible for more Wikimedians. Do you have use cases we should be aware of here? A preferred solution? /Johan (WMF) (talk) 23:54, 22 October 2020 (UTC)

From the prospective of anti-vandalism and SPI work, the least harmful solution version of IP masking would be some system of assigning internal IP aliases that effectively serves the same purposes that the current public IP address system does. That is an alias system where, say, two IP editors with "similar" (in whichever ways the term is precisely quantified) public IP addresses are assigned "similar" internal aliases. That might still allow for some modified form of range-blocking; in cases of sock puppetry and block evasion it would also make it easier (as the current system does) to infer that the same editor is engaged in IP hopping. I have no idea if such a way IP aliases is technologically feasible (plus, I suppose, you'd have to make sure that one can't actually de-scramble it), but in terms of preserving the functionalities of the current system, that'd be most useful, IMO. Nsk92 (talk) 10:11, 23 October 2020 (UTC)

As a note, this discussion is clearly critical, (certainly we need something far better than mere cookies) but it's not inherently related to this specific conversation topic (they warrant their own section), which is who will have access to the information (whether that be the default - whatever that turns out to be), partial, or full. The discussion will logically expand into "and what are going to be the levels needed for those access rights" Nosebagbear (talk) 10:25, 23 October 2020 (UTC)

Make separate user right for "unmasking" IPs

A danger I fear: If only checkusers can unmask IPs, wikis will need to increase the checkuser count by an order of magnitude, just to keep up. That's an order of magnitude more accounts that could be compromised. So the unintended consequence will be to decrease privacy for registered users. Instead there should be a separate right, given out more freely than checkuser. Suffusion of Yellow (talk) 20:40, 19 October 2020 (UTC)

It will need to be a userright - more than admins (let alone CUs!) will need access. A discussion should be had with Johan as to what, presumably fairly strenuous, set of criteria will be needed, whether it will be globally/locally provided, etc. Nosebagbear (talk) 21:03, 19 October 2020 (UTC)

We're talking about what we can do, internally – it's been suggested before – and will get back to you as soon as I can with our thoughts around this. /Johan (WMF) (talk) 17:05, 20 October 2020 (UTC)

Who can access the IP of an unregistered editor?

OK, so this is what we're thinking right now: We could create a new user right, which would give access to the full IP. We could look into making it an opt-in function, dependent on yet undefined criteria. This could simplify bureaucracy but make access less flexible. The important part here is that we need to know who has access at any given point. I want to stress that we haven’t tried to answer all questions here, as we’re trying to solve this together with you.

An idea could be to create three tiers.

1. The vast majority of people who access our wikis would see the IPs fully masked.
2. All admins could see them partially masked (the first three parts of an IP being visible). This could be helpful to see patterns even if they don’t have the new user right. Partially masking them reduces the privacy risk for the unregistered user.
3. The new user right – in addition to checkusers and stewards – would have access to the entire IP.

Thoughts? /Johan (WMF) (talk) 17:02, 21 October 2020 (UTC)

First 3 parts, does it applies to ipv6 too? In addition, since it's privacy related, why not oversighters also have the full access? As we now OS logged out user IPs too. And the new userright seems so like interface admin, there are wikis which IAs are given like per request, while others are very strict. Will communities get to decide or WMF will mandate the process (or rather % of the new userright / admins etc). And will 2FA be needed for this right? Camouflaged Mirage (talk) 17:05, 21 October 2020 (UTC)

Camouflaged Mirage: Masking the equivalent information value of IPv6 addresses, to be clear. (:

I want to stress that this is a conversation starter to figure out what the different communities' needs are, rather than trying to define exactly how this would work – my examples are not exhaustive. There will be some sort of requirement from the Foundation, since this has to do with handling user data, but really, tell us what you think would work best? My personal best guess – not speaking for the team, just for myself – is that an automatic opt-in process would probably make requirements more similar across the wikis than if it was a user right that was manually assigned.

The 2FA question is a very good one. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

How would the automatic opt-in process work and what kind of requirements would it have? A certain number of edits? kyykaarme (talk) 19:37, 8 November 2020 (UTC)

kyykaarme: That's one of the things we'd have to figure out together, if we decide to go down that road instead of a user right the communities control handing out. Consider this more a discussion starter than a proposal. Would we need a certain period of time? How do we handle previous blocks? Do we see them as a sign of users who can't handle the norms of the wiki? What's the process for those who were unfairly blocked and immediately unblocked, or blocked themselves for some reason? And so on. /Johan (WMF) (talk) 04:00, 9 November 2020 (UTC)

It's difficult to give suggestions, when I don't know what the WMF requires from the users who can see IP addresses in the future. I first thought from your three tier plan that the user right would be between admin and CU, but then you said that it would be easier to get the user right than it is to become an admin in enwiki. Does that mean that the WMF is willing to give all one thousand+ admins in enwiki the new user right, if they want it? And then how many more users, a few hundred "trusted" vandal fighters, or a few thousand? From your comments I also understand that the users probably have to be adults and possibly sign the confidentially agreement (with their username). Checkusers often have a long history and are trusted by the community, but in the opt-in version this new user right will be given to pretty much anyone, it seems, as long as they contribute long enough and maybe haven't gotten blocked. And are you going to communicate to the unregistered editors that there are X amount of users who can see their IP addresses? kyykaarme (talk) 17:59, 18 November 2020 (UTC)

kyykaarme: Understandably. This is sort of a friendly rope pulling between the privacy requirements and legal necessities on the one hand, and our ability to defend the wikis on the other hand. We have a lot of people being concerned they wouldn't be able to handle spam and vandalism in the comments here and elsewhere, and we don't want to risk that, so we are talking about giving more people access than we'd have done if it was based on e.g. my needs as a vandal fighter on my home wiki (which isn't terribly concerned) and what would have been preferable from a privacy perspective. We're still in the process trying to find the right balance. I assume we'd want to keep some sort of warning that not logging in will lead to being more exposed as well as not having access to most preferences or a reliably permanent identity, like today but not quite the same. /Johan (WMF) (talk) 05:17, 19 November 2020 (UTC)

And I get that some of you will feel that it should be easier to get this user right than adminship, and look askance at why this would be necessary, but remember that while this talk page is currently dominated by users from English Wikipedia, the English Wikipedia Request for Adminship process is an outlier and we need something that works for all wikis.

If you’ve been around for nine months, have a thousand edits, been active in discussions in the Wikipedia namespace to show that you’re aware what the community is, and been somewhat active in patrolling, there’s a fair chance you’ll be completely unopposed in a request for adminship on my home wiki. On some small wikis, you’ll get a time-limited adminship when you request it and the two other users who turn up say sure, why not. The global minimum for permanent adminship on Wikimedia content wikis is five editors supporting you.

The process and requirements to gain adminship vary a lot. We figure that the ability to handle sensitive information here is below what’s currently required in e.g. the English Wikipedia Request for Adminship process, but above what the global minimum can mean in practice. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

I will suggest a mass message to village pumps in every wiki to solicit what every community thinks if this is what you hoped for. Thanks for the replies, appreciate it.Camouflaged Mirage (talk) 17:32, 21 October 2020 (UTC)

Yes, we're planning on some sort of MassMessage, to make sure vandal fighters on all wikis are aware of what's happening and how they can participate in the process. /Johan (WMF) (talk) 17:35, 21 October 2020 (UTC)

Thanks. One more, if we are speaking about global issues, how will wikis without local communities work, they are now patrolled by SWMT and global rollbackers, sysops, stewards handle the issues. Will these groups be granted access to the new userrights on these wikis? I understand the different rights systems as I edit wikis ranging from large ones (with local crats) and small ones (which I was once a perm sysop on a small content wiki). If we are saying we can accept users lower than enwp RFA bar and higher than perm sysop other wikis bar, then for enwp, sysops should be given the right to view full. One user in the middle range, let say a small wiki perm sysop + enwp rollbacker, he can see the IP address in homewiki, but not on enwp, if we trust them on one, why not all? Anyway the same IP user will be seen by the same person. I know it's hard to define what exactly is, I agree a massmessage will be proper, I think we might even benefit from a global RFC similiar to how global sysops is conceived for the new userrights. This will be benefical IMO. Camouflaged Mirage (talk) 17:41, 21 October 2020 (UTC)

Hmm, @Johan (WMF):, this is at least a good discussion benchmark. I thank you for your bottom half - I was absolutely going to step in and make a point that it should be lower, but of course you are right as regards variable levels for adminship. Hmm. I will have to have a think, please excuse the whirring hamster noises. I realise it continues the userright proliferation, but would it make sense to actually have two userrights (akin to edit filter helper and edit filter manager), the lower (partial vision) of which would be the "given to all admins", but could also be given to others under one criteria set - while the other (full vision) would be under a higher set? I'm not set on that, but would like to hear your and others' feedback. Nosebagbear (talk) 19:19, 21 October 2020 (UTC)

I think it would be logistically easier, if you go that route, to decide what global and local permissions the foundation considers this access equivalent to. If it's equivalent to the 'trust' for rollbacker, for example, then projects like enwiki might as well bundle the permission into the rollback user right. I'm not sure it should be a separate user right, imo that increases the burden/workload for all projects to have to start assigning that to people. ProcrastinatingReader (talk) 22:17, 30 December 2020 (UTC)

I think this proposal still lacks crucial details in that it says nothing about what exactly the regular users will see instead of an IP address. That is, 'how' will an IP address be masked? If you plan to assign the IPs individualized aliases, then how exactly will that work? That's not an aside question. E.g. will it be possible to tell that two individualized IP aliases for IP addresses from the same geographical area do come from a common geographical area? Or will the aliases be assigned randomly? Or perhaps in the same linear order as the IPs come online and make their first WP edits? Or using some other scheme? This question matters a great deal for anti-vandalism and SPI considerations, and the matter can't just be omitted from the above discussion. Nsk92 (talk) 23:12, 22 October 2020 (UTC)

Nsk92: Just to be clear, this isn't a proposal as much as it is a conversation starter. In order to solve these questions, we're trying to bring the communities into the process as early as possible, instead of trying to figure out everything on our own and risk missing crucial things. We're sort of taking the kind of conversation that normally lives in Phabricator and having it on the wikis where it's more accessible for more Wikimedians. Do you have use cases we should be aware of here? A preferred solution? /Johan (WMF) (talk) 23:54, 22 October 2020 (UTC)

From the prospective of anti-vandalism and SPI work, the least harmful solution version of IP masking would be some system of assigning internal IP aliases that effectively serves the same purposes that the current public IP address system does. That is an alias system where, say, two IP editors with "similar" (in whichever ways the term is precisely quantified) public IP addresses are assigned "similar" internal aliases. That might still allow for some modified form of range-blocking; in cases of sock puppetry and block evasion it would also make it easier (as the current system does) to infer that the same editor is engaged in IP hopping. I have no idea if such a way IP aliases is technologically feasible (plus, I suppose, you'd have to make sure that one can't actually de-scramble it), but in terms of preserving the functionalities of the current system, that'd be most useful, IMO. Nsk92 (talk) 10:11, 23 October 2020 (UTC)

As a note, this discussion is clearly critical, (certainly we need something far better than mere cookies) but it's not inherently related to this specific conversation topic (they warrant their own section), which is who will have access to the information (whether that be the default - whatever that turns out to be), partial, or full. The discussion will logically expand into "and what are going to be the levels needed for those access rights" Nosebagbear (talk) 10:25, 23 October 2020 (UTC)

Make separate user right for "unmasking" IPs

A danger I fear: If only checkusers can unmask IPs, wikis will need to increase the checkuser count by an order of magnitude, just to keep up. That's an order of magnitude more accounts that could be compromised. So the unintended consequence will be to decrease privacy for registered users. Instead there should be a separate right, given out more freely than checkuser. Suffusion of Yellow (talk) 20:40, 19 October 2020 (UTC)

It will need to be a userright - more than admins (let alone CUs!) will need access. A discussion should be had with Johan as to what, presumably fairly strenuous, set of criteria will be needed, whether it will be globally/locally provided, etc. Nosebagbear (talk) 21:03, 19 October 2020 (UTC)

We're talking about what we can do, internally – it's been suggested before – and will get back to you as soon as I can with our thoughts around this. /Johan (WMF) (talk) 17:05, 20 October 2020 (UTC)

Who can access the IP of an unregistered editor?

OK, so this is what we're thinking right now: We could create a new user right, which would give access to the full IP. We could look into making it an opt-in function, dependent on yet undefined criteria. This could simplify bureaucracy but make access less flexible. The important part here is that we need to know who has access at any given point. I want to stress that we haven’t tried to answer all questions here, as we’re trying to solve this together with you.

An idea could be to create three tiers.

1. The vast majority of people who access our wikis would see the IPs fully masked.
2. All admins could see them partially masked (the first three parts of an IP being visible). This could be helpful to see patterns even if they don’t have the new user right. Partially masking them reduces the privacy risk for the unregistered user.
3. The new user right – in addition to checkusers and stewards – would have access to the entire IP.

Thoughts? /Johan (WMF) (talk) 17:02, 21 October 2020 (UTC)

First 3 parts, does it applies to ipv6 too? In addition, since it's privacy related, why not oversighters also have the full access? As we now OS logged out user IPs too. And the new userright seems so like interface admin, there are wikis which IAs are given like per request, while others are very strict. Will communities get to decide or WMF will mandate the process (or rather % of the new userright / admins etc). And will 2FA be needed for this right? Camouflaged Mirage (talk) 17:05, 21 October 2020 (UTC)

Camouflaged Mirage: Masking the equivalent information value of IPv6 addresses, to be clear. (:

I want to stress that this is a conversation starter to figure out what the different communities' needs are, rather than trying to define exactly how this would work – my examples are not exhaustive. There will be some sort of requirement from the Foundation, since this has to do with handling user data, but really, tell us what you think would work best? My personal best guess – not speaking for the team, just for myself – is that an automatic opt-in process would probably make requirements more similar across the wikis than if it was a user right that was manually assigned.

The 2FA question is a very good one. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

How would the automatic opt-in process work and what kind of requirements would it have? A certain number of edits? kyykaarme (talk) 19:37, 8 November 2020 (UTC)

kyykaarme: That's one of the things we'd have to figure out together, if we decide to go down that road instead of a user right the communities control handing out. Consider this more a discussion starter than a proposal. Would we need a certain period of time? How do we handle previous blocks? Do we see them as a sign of users who can't handle the norms of the wiki? What's the process for those who were unfairly blocked and immediately unblocked, or blocked themselves for some reason? And so on. /Johan (WMF) (talk) 04:00, 9 November 2020 (UTC)

It's difficult to give suggestions, when I don't know what the WMF requires from the users who can see IP addresses in the future. I first thought from your three tier plan that the user right would be between admin and CU, but then you said that it would be easier to get the user right than it is to become an admin in enwiki. Does that mean that the WMF is willing to give all one thousand+ admins in enwiki the new user right, if they want it? And then how many more users, a few hundred "trusted" vandal fighters, or a few thousand? From your comments I also understand that the users probably have to be adults and possibly sign the confidentially agreement (with their username). Checkusers often have a long history and are trusted by the community, but in the opt-in version this new user right will be given to pretty much anyone, it seems, as long as they contribute long enough and maybe haven't gotten blocked. And are you going to communicate to the unregistered editors that there are X amount of users who can see their IP addresses? kyykaarme (talk) 17:59, 18 November 2020 (UTC)

kyykaarme: Understandably. This is sort of a friendly rope pulling between the privacy requirements and legal necessities on the one hand, and our ability to defend the wikis on the other hand. We have a lot of people being concerned they wouldn't be able to handle spam and vandalism in the comments here and elsewhere, and we don't want to risk that, so we are talking about giving more people access than we'd have done if it was based on e.g. my needs as a vandal fighter on my home wiki (which isn't terribly concerned) and what would have been preferable from a privacy perspective. We're still in the process trying to find the right balance. I assume we'd want to keep some sort of warning that not logging in will lead to being more exposed as well as not having access to most preferences or a reliably permanent identity, like today but not quite the same. /Johan (WMF) (talk) 05:17, 19 November 2020 (UTC)

And I get that some of you will feel that it should be easier to get this user right than adminship, and look askance at why this would be necessary, but remember that while this talk page is currently dominated by users from English Wikipedia, the English Wikipedia Request for Adminship process is an outlier and we need something that works for all wikis.

If you’ve been around for nine months, have a thousand edits, been active in discussions in the Wikipedia namespace to show that you’re aware what the community is, and been somewhat active in patrolling, there’s a fair chance you’ll be completely unopposed in a request for adminship on my home wiki. On some small wikis, you’ll get a time-limited adminship when you request it and the two other users who turn up say sure, why not. The global minimum for permanent adminship on Wikimedia content wikis is five editors supporting you.

The process and requirements to gain adminship vary a lot. We figure that the ability to handle sensitive information here is below what’s currently required in e.g. the English Wikipedia Request for Adminship process, but above what the global minimum can mean in practice. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

I will suggest a mass message to village pumps in every wiki to solicit what every community thinks if this is what you hoped for. Thanks for the replies, appreciate it.Camouflaged Mirage (talk) 17:32, 21 October 2020 (UTC)

Yes, we're planning on some sort of MassMessage, to make sure vandal fighters on all wikis are aware of what's happening and how they can participate in the process. /Johan (WMF) (talk) 17:35, 21 October 2020 (UTC)

Thanks. One more, if we are speaking about global issues, how will wikis without local communities work, they are now patrolled by SWMT and global rollbackers, sysops, stewards handle the issues. Will these groups be granted access to the new userrights on these wikis? I understand the different rights systems as I edit wikis ranging from large ones (with local crats) and small ones (which I was once a perm sysop on a small content wiki). If we are saying we can accept users lower than enwp RFA bar and higher than perm sysop other wikis bar, then for enwp, sysops should be given the right to view full. One user in the middle range, let say a small wiki perm sysop + enwp rollbacker, he can see the IP address in homewiki, but not on enwp, if we trust them on one, why not all? Anyway the same IP user will be seen by the same person. I know it's hard to define what exactly is, I agree a massmessage will be proper, I think we might even benefit from a global RFC similiar to how global sysops is conceived for the new userrights. This will be benefical IMO. Camouflaged Mirage (talk) 17:41, 21 October 2020 (UTC)

Hmm, @Johan (WMF):, this is at least a good discussion benchmark. I thank you for your bottom half - I was absolutely going to step in and make a point that it should be lower, but of course you are right as regards variable levels for adminship. Hmm. I will have to have a think, please excuse the whirring hamster noises. I realise it continues the userright proliferation, but would it make sense to actually have two userrights (akin to edit filter helper and edit filter manager), the lower (partial vision) of which would be the "given to all admins", but could also be given to others under one criteria set - while the other (full vision) would be under a higher set? I'm not set on that, but would like to hear your and others' feedback. Nosebagbear (talk) 19:19, 21 October 2020 (UTC)

I think it would be logistically easier, if you go that route, to decide what global and local permissions the foundation considers this access equivalent to. If it's equivalent to the 'trust' for rollbacker, for example, then projects like enwiki might as well bundle the permission into the rollback user right. I'm not sure it should be a separate user right, imo that increases the burden/workload for all projects to have to start assigning that to people. ProcrastinatingReader (talk) 22:17, 30 December 2020 (UTC)

I think this proposal still lacks crucial details in that it says nothing about what exactly the regular users will see instead of an IP address. That is, 'how' will an IP address be masked? If you plan to assign the IPs individualized aliases, then how exactly will that work? That's not an aside question. E.g. will it be possible to tell that two individualized IP aliases for IP addresses from the same geographical area do come from a common geographical area? Or will the aliases be assigned randomly? Or perhaps in the same linear order as the IPs come online and make their first WP edits? Or using some other scheme? This question matters a great deal for anti-vandalism and SPI considerations, and the matter can't just be omitted from the above discussion. Nsk92 (talk) 23:12, 22 October 2020 (UTC)

Nsk92: Just to be clear, this isn't a proposal as much as it is a conversation starter. In order to solve these questions, we're trying to bring the communities into the process as early as possible, instead of trying to figure out everything on our own and risk missing crucial things. We're sort of taking the kind of conversation that normally lives in Phabricator and having it on the wikis where it's more accessible for more Wikimedians. Do you have use cases we should be aware of here? A preferred solution? /Johan (WMF) (talk) 23:54, 22 October 2020 (UTC)

From the prospective of anti-vandalism and SPI work, the least harmful solution version of IP masking would be some system of assigning internal IP aliases that effectively serves the same purposes that the current public IP address system does. That is an alias system where, say, two IP editors with "similar" (in whichever ways the term is precisely quantified) public IP addresses are assigned "similar" internal aliases. That might still allow for some modified form of range-blocking; in cases of sock puppetry and block evasion it would also make it easier (as the current system does) to infer that the same editor is engaged in IP hopping. I have no idea if such a way IP aliases is technologically feasible (plus, I suppose, you'd have to make sure that one can't actually de-scramble it), but in terms of preserving the functionalities of the current system, that'd be most useful, IMO. Nsk92 (talk) 10:11, 23 October 2020 (UTC)

As a note, this discussion is clearly critical, (certainly we need something far better than mere cookies) but it's not inherently related to this specific conversation topic (they warrant their own section), which is who will have access to the information (whether that be the default - whatever that turns out to be), partial, or full. The discussion will logically expand into "and what are going to be the levels needed for those access rights" Nosebagbear (talk) 10:25, 23 October 2020 (UTC)

Make separate user right for "unmasking" IPs

A danger I fear: If only checkusers can unmask IPs, wikis will need to increase the checkuser count by an order of magnitude, just to keep up. That's an order of magnitude more accounts that could be compromised. So the unintended consequence will be to decrease privacy for registered users. Instead there should be a separate right, given out more freely than checkuser. Suffusion of Yellow (talk) 20:40, 19 October 2020 (UTC)

It will need to be a userright - more than admins (let alone CUs!) will need access. A discussion should be had with Johan as to what, presumably fairly strenuous, set of criteria will be needed, whether it will be globally/locally provided, etc. Nosebagbear (talk) 21:03, 19 October 2020 (UTC)

We're talking about what we can do, internally – it's been suggested before – and will get back to you as soon as I can with our thoughts around this. /Johan (WMF) (talk) 17:05, 20 October 2020 (UTC)

Who can access the IP of an unregistered editor?

OK, so this is what we're thinking right now: We could create a new user right, which would give access to the full IP. We could look into making it an opt-in function, dependent on yet undefined criteria. This could simplify bureaucracy but make access less flexible. The important part here is that we need to know who has access at any given point. I want to stress that we haven’t tried to answer all questions here, as we’re trying to solve this together with you.

An idea could be to create three tiers.

1. The vast majority of people who access our wikis would see the IPs fully masked.
2. All admins could see them partially masked (the first three parts of an IP being visible). This could be helpful to see patterns even if they don’t have the new user right. Partially masking them reduces the privacy risk for the unregistered user.
3. The new user right – in addition to checkusers and stewards – would have access to the entire IP.

Thoughts? /Johan (WMF) (talk) 17:02, 21 October 2020 (UTC)

First 3 parts, does it applies to ipv6 too? In addition, since it's privacy related, why not oversighters also have the full access? As we now OS logged out user IPs too. And the new userright seems so like interface admin, there are wikis which IAs are given like per request, while others are very strict. Will communities get to decide or WMF will mandate the process (or rather % of the new userright / admins etc). And will 2FA be needed for this right? Camouflaged Mirage (talk) 17:05, 21 October 2020 (UTC)

Camouflaged Mirage: Masking the equivalent information value of IPv6 addresses, to be clear. (:

I want to stress that this is a conversation starter to figure out what the different communities' needs are, rather than trying to define exactly how this would work – my examples are not exhaustive. There will be some sort of requirement from the Foundation, since this has to do with handling user data, but really, tell us what you think would work best? My personal best guess – not speaking for the team, just for myself – is that an automatic opt-in process would probably make requirements more similar across the wikis than if it was a user right that was manually assigned.

The 2FA question is a very good one. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

How would the automatic opt-in process work and what kind of requirements would it have? A certain number of edits? kyykaarme (talk) 19:37, 8 November 2020 (UTC)

kyykaarme: That's one of the things we'd have to figure out together, if we decide to go down that road instead of a user right the communities control handing out. Consider this more a discussion starter than a proposal. Would we need a certain period of time? How do we handle previous blocks? Do we see them as a sign of users who can't handle the norms of the wiki? What's the process for those who were unfairly blocked and immediately unblocked, or blocked themselves for some reason? And so on. /Johan (WMF) (talk) 04:00, 9 November 2020 (UTC)

It's difficult to give suggestions, when I don't know what the WMF requires from the users who can see IP addresses in the future. I first thought from your three tier plan that the user right would be between admin and CU, but then you said that it would be easier to get the user right than it is to become an admin in enwiki. Does that mean that the WMF is willing to give all one thousand+ admins in enwiki the new user right, if they want it? And then how many more users, a few hundred "trusted" vandal fighters, or a few thousand? From your comments I also understand that the users probably have to be adults and possibly sign the confidentially agreement (with their username). Checkusers often have a long history and are trusted by the community, but in the opt-in version this new user right will be given to pretty much anyone, it seems, as long as they contribute long enough and maybe haven't gotten blocked. And are you going to communicate to the unregistered editors that there are X amount of users who can see their IP addresses? kyykaarme (talk) 17:59, 18 November 2020 (UTC)

kyykaarme: Understandably. This is sort of a friendly rope pulling between the privacy requirements and legal necessities on the one hand, and our ability to defend the wikis on the other hand. We have a lot of people being concerned they wouldn't be able to handle spam and vandalism in the comments here and elsewhere, and we don't want to risk that, so we are talking about giving more people access than we'd have done if it was based on e.g. my needs as a vandal fighter on my home wiki (which isn't terribly concerned) and what would have been preferable from a privacy perspective. We're still in the process trying to find the right balance. I assume we'd want to keep some sort of warning that not logging in will lead to being more exposed as well as not having access to most preferences or a reliably permanent identity, like today but not quite the same. /Johan (WMF) (talk) 05:17, 19 November 2020 (UTC)

And I get that some of you will feel that it should be easier to get this user right than adminship, and look askance at why this would be necessary, but remember that while this talk page is currently dominated by users from English Wikipedia, the English Wikipedia Request for Adminship process is an outlier and we need something that works for all wikis.

If you’ve been around for nine months, have a thousand edits, been active in discussions in the Wikipedia namespace to show that you’re aware what the community is, and been somewhat active in patrolling, there’s a fair chance you’ll be completely unopposed in a request for adminship on my home wiki. On some small wikis, you’ll get a time-limited adminship when you request it and the two other users who turn up say sure, why not. The global minimum for permanent adminship on Wikimedia content wikis is five editors supporting you.

The process and requirements to gain adminship vary a lot. We figure that the ability to handle sensitive information here is below what’s currently required in e.g. the English Wikipedia Request for Adminship process, but above what the global minimum can mean in practice. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

I will suggest a mass message to village pumps in every wiki to solicit what every community thinks if this is what you hoped for. Thanks for the replies, appreciate it.Camouflaged Mirage (talk) 17:32, 21 October 2020 (UTC)

Yes, we're planning on some sort of MassMessage, to make sure vandal fighters on all wikis are aware of what's happening and how they can participate in the process. /Johan (WMF) (talk) 17:35, 21 October 2020 (UTC)

Thanks. One more, if we are speaking about global issues, how will wikis without local communities work, they are now patrolled by SWMT and global rollbackers, sysops, stewards handle the issues. Will these groups be granted access to the new userrights on these wikis? I understand the different rights systems as I edit wikis ranging from large ones (with local crats) and small ones (which I was once a perm sysop on a small content wiki). If we are saying we can accept users lower than enwp RFA bar and higher than perm sysop other wikis bar, then for enwp, sysops should be given the right to view full. One user in the middle range, let say a small wiki perm sysop + enwp rollbacker, he can see the IP address in homewiki, but not on enwp, if we trust them on one, why not all? Anyway the same IP user will be seen by the same person. I know it's hard to define what exactly is, I agree a massmessage will be proper, I think we might even benefit from a global RFC similiar to how global sysops is conceived for the new userrights. This will be benefical IMO. Camouflaged Mirage (talk) 17:41, 21 October 2020 (UTC)

Hmm, @Johan (WMF):, this is at least a good discussion benchmark. I thank you for your bottom half - I was absolutely going to step in and make a point that it should be lower, but of course you are right as regards variable levels for adminship. Hmm. I will have to have a think, please excuse the whirring hamster noises. I realise it continues the userright proliferation, but would it make sense to actually have two userrights (akin to edit filter helper and edit filter manager), the lower (partial vision) of which would be the "given to all admins", but could also be given to others under one criteria set - while the other (full vision) would be under a higher set? I'm not set on that, but would like to hear your and others' feedback. Nosebagbear (talk) 19:19, 21 October 2020 (UTC)

I think it would be logistically easier, if you go that route, to decide what global and local permissions the foundation considers this access equivalent to. If it's equivalent to the 'trust' for rollbacker, for example, then projects like enwiki might as well bundle the permission into the rollback user right. I'm not sure it should be a separate user right, imo that increases the burden/workload for all projects to have to start assigning that to people. ProcrastinatingReader (talk) 22:17, 30 December 2020 (UTC)

I think this proposal still lacks crucial details in that it says nothing about what exactly the regular users will see instead of an IP address. That is, 'how' will an IP address be masked? If you plan to assign the IPs individualized aliases, then how exactly will that work? That's not an aside question. E.g. will it be possible to tell that two individualized IP aliases for IP addresses from the same geographical area do come from a common geographical area? Or will the aliases be assigned randomly? Or perhaps in the same linear order as the IPs come online and make their first WP edits? Or using some other scheme? This question matters a great deal for anti-vandalism and SPI considerations, and the matter can't just be omitted from the above discussion. Nsk92 (talk) 23:12, 22 October 2020 (UTC)

Nsk92: Just to be clear, this isn't a proposal as much as it is a conversation starter. In order to solve these questions, we're trying to bring the communities into the process as early as possible, instead of trying to figure out everything on our own and risk missing crucial things. We're sort of taking the kind of conversation that normally lives in Phabricator and having it on the wikis where it's more accessible for more Wikimedians. Do you have use cases we should be aware of here? A preferred solution? /Johan (WMF) (talk) 23:54, 22 October 2020 (UTC)

From the prospective of anti-vandalism and SPI work, the least harmful solution version of IP masking would be some system of assigning internal IP aliases that effectively serves the same purposes that the current public IP address system does. That is an alias system where, say, two IP editors with "similar" (in whichever ways the term is precisely quantified) public IP addresses are assigned "similar" internal aliases. That might still allow for some modified form of range-blocking; in cases of sock puppetry and block evasion it would also make it easier (as the current system does) to infer that the same editor is engaged in IP hopping. I have no idea if such a way IP aliases is technologically feasible (plus, I suppose, you'd have to make sure that one can't actually de-scramble it), but in terms of preserving the functionalities of the current system, that'd be most useful, IMO. Nsk92 (talk) 10:11, 23 October 2020 (UTC)

As a note, this discussion is clearly critical, (certainly we need something far better than mere cookies) but it's not inherently related to this specific conversation topic (they warrant their own section), which is who will have access to the information (whether that be the default - whatever that turns out to be), partial, or full. The discussion will logically expand into "and what are going to be the levels needed for those access rights" Nosebagbear (talk) 10:25, 23 October 2020 (UTC)

Make separate user right for "unmasking" IPs

A danger I fear: If only checkusers can unmask IPs, wikis will need to increase the checkuser count by an order of magnitude, just to keep up. That's an order of magnitude more accounts that could be compromised. So the unintended consequence will be to decrease privacy for registered users. Instead there should be a separate right, given out more freely than checkuser. Suffusion of Yellow (talk) 20:40, 19 October 2020 (UTC)

It will need to be a userright - more than admins (let alone CUs!) will need access. A discussion should be had with Johan as to what, presumably fairly strenuous, set of criteria will be needed, whether it will be globally/locally provided, etc. Nosebagbear (talk) 21:03, 19 October 2020 (UTC)

We're talking about what we can do, internally – it's been suggested before – and will get back to you as soon as I can with our thoughts around this. /Johan (WMF) (talk) 17:05, 20 October 2020 (UTC)

Who can access the IP of an unregistered editor?

OK, so this is what we're thinking right now: We could create a new user right, which would give access to the full IP. We could look into making it an opt-in function, dependent on yet undefined criteria. This could simplify bureaucracy but make access less flexible. The important part here is that we need to know who has access at any given point. I want to stress that we haven’t tried to answer all questions here, as we’re trying to solve this together with you.

An idea could be to create three tiers.

1. The vast majority of people who access our wikis would see the IPs fully masked.
2. All admins could see them partially masked (the first three parts of an IP being visible). This could be helpful to see patterns even if they don’t have the new user right. Partially masking them reduces the privacy risk for the unregistered user.
3. The new user right – in addition to checkusers and stewards – would have access to the entire IP.

Thoughts? /Johan (WMF) (talk) 17:02, 21 October 2020 (UTC)

First 3 parts, does it applies to ipv6 too? In addition, since it's privacy related, why not oversighters also have the full access? As we now OS logged out user IPs too. And the new userright seems so like interface admin, there are wikis which IAs are given like per request, while others are very strict. Will communities get to decide or WMF will mandate the process (or rather % of the new userright / admins etc). And will 2FA be needed for this right? Camouflaged Mirage (talk) 17:05, 21 October 2020 (UTC)

Camouflaged Mirage: Masking the equivalent information value of IPv6 addresses, to be clear. (:

I want to stress that this is a conversation starter to figure out what the different communities' needs are, rather than trying to define exactly how this would work – my examples are not exhaustive. There will be some sort of requirement from the Foundation, since this has to do with handling user data, but really, tell us what you think would work best? My personal best guess – not speaking for the team, just for myself – is that an automatic opt-in process would probably make requirements more similar across the wikis than if it was a user right that was manually assigned.

The 2FA question is a very good one. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

How would the automatic opt-in process work and what kind of requirements would it have? A certain number of edits? kyykaarme (talk) 19:37, 8 November 2020 (UTC)

kyykaarme: That's one of the things we'd have to figure out together, if we decide to go down that road instead of a user right the communities control handing out. Consider this more a discussion starter than a proposal. Would we need a certain period of time? How do we handle previous blocks? Do we see them as a sign of users who can't handle the norms of the wiki? What's the process for those who were unfairly blocked and immediately unblocked, or blocked themselves for some reason? And so on. /Johan (WMF) (talk) 04:00, 9 November 2020 (UTC)

It's difficult to give suggestions, when I don't know what the WMF requires from the users who can see IP addresses in the future. I first thought from your three tier plan that the user right would be between admin and CU, but then you said that it would be easier to get the user right than it is to become an admin in enwiki. Does that mean that the WMF is willing to give all one thousand+ admins in enwiki the new user right, if they want it? And then how many more users, a few hundred "trusted" vandal fighters, or a few thousand? From your comments I also understand that the users probably have to be adults and possibly sign the confidentially agreement (with their username). Checkusers often have a long history and are trusted by the community, but in the opt-in version this new user right will be given to pretty much anyone, it seems, as long as they contribute long enough and maybe haven't gotten blocked. And are you going to communicate to the unregistered editors that there are X amount of users who can see their IP addresses? kyykaarme (talk) 17:59, 18 November 2020 (UTC)

kyykaarme: Understandably. This is sort of a friendly rope pulling between the privacy requirements and legal necessities on the one hand, and our ability to defend the wikis on the other hand. We have a lot of people being concerned they wouldn't be able to handle spam and vandalism in the comments here and elsewhere, and we don't want to risk that, so we are talking about giving more people access than we'd have done if it was based on e.g. my needs as a vandal fighter on my home wiki (which isn't terribly concerned) and what would have been preferable from a privacy perspective. We're still in the process trying to find the right balance. I assume we'd want to keep some sort of warning that not logging in will lead to being more exposed as well as not having access to most preferences or a reliably permanent identity, like today but not quite the same. /Johan (WMF) (talk) 05:17, 19 November 2020 (UTC)

And I get that some of you will feel that it should be easier to get this user right than adminship, and look askance at why this would be necessary, but remember that while this talk page is currently dominated by users from English Wikipedia, the English Wikipedia Request for Adminship process is an outlier and we need something that works for all wikis.

If you’ve been around for nine months, have a thousand edits, been active in discussions in the Wikipedia namespace to show that you’re aware what the community is, and been somewhat active in patrolling, there’s a fair chance you’ll be completely unopposed in a request for adminship on my home wiki. On some small wikis, you’ll get a time-limited adminship when you request it and the two other users who turn up say sure, why not. The global minimum for permanent adminship on Wikimedia content wikis is five editors supporting you.

The process and requirements to gain adminship vary a lot. We figure that the ability to handle sensitive information here is below what’s currently required in e.g. the English Wikipedia Request for Adminship process, but above what the global minimum can mean in practice. /Johan (WMF) (talk) 17:27, 21 October 2020 (UTC)

I will suggest a mass message to village pumps in every wiki to solicit what every community thinks if this is what you hoped for. Thanks for the replies, appreciate it.Camouflaged Mirage (talk) 17:32, 21 October 2020 (UTC)

Yes, we're planning on some sort of MassMessage, to make sure vandal fighters on all wikis are aware of what's happening and how they can participate in the process. /Johan (WMF) (talk) 17:35, 21 October 2020 (UTC)

Thanks. One more, if we are speaking about global issues, how will wikis without local communities work, they are now patrolled by SWMT and global rollbackers, sysops, stewards handle the issues. Will these groups be granted access to the new userrights on these wikis? I understand the different rights systems as I edit wikis ranging from large ones (with local crats) and small ones (which I was once a perm sysop on a small content wiki). If we are saying we can accept users lower than enwp RFA bar and higher than perm sysop other wikis bar, then for enwp, sysops should be given the right to view full. One user in the middle range, let say a small wiki perm sysop + enwp rollbacker, he can see the IP address in homewiki, but not on enwp, if we trust them on one, why not all? Anyway the same IP user will be seen by the same person. I know it's hard to define what exactly is, I agree a massmessage will be proper, I think we might even benefit from a global RFC similiar to how global sysops is conceived for the new userrights. This will be benefical IMO. Camouflaged Mirage (talk) 17:41, 21 October 2020 (UTC)

Hmm, @Johan (WMF):, this is at least a good discussion benchmark. I thank you for your bottom half - I was absolutely going to step in and make a point that it should be lower, but of course you are right as regards variable levels for adminship. Hmm. I will have to have a think, please excuse the whirring hamster noises. I realise it continues the userright proliferation, but would it make sense to actually have two userrights (akin to edit filter helper and edit filter manager), the lower (partial vision) of which would be the "given to all admins", but could also be given to others under one criteria set - while the other (full vision) would be under a higher set? I'm not set on that, but would like to hear your and others' feedback. Nosebagbear (talk) 19:19, 21 October 2020 (UTC)

I think it would be logistically easier, if you go that route, to decide what global and local permissions the foundation considers this access equivalent to. If it's equivalent to the 'trust' for rollbacker, for example, then projects like enwiki might as well bundle the permission into the rollback user right. I'm not sure it should be a separate user right, imo that increases the burden/workload for all projects to have to start assigning that to people. ProcrastinatingReader (talk) 22:17, 30 December 2020 (UTC)

I think this proposal still lacks crucial details in that it says nothing about what exactly the regular users will see instead of an IP address. That is, 'how' will an IP address be masked? If you plan to assign the IPs individualized aliases, then how exactly will that work? That's not an aside question. E.g. will it be possible to tell that two individualized IP aliases for IP addresses from the same geographical area do come from a common geographical area? Or will the aliases be assigned randomly? Or perhaps in the same linear order as the IPs come online and make their first WP edits? Or using some other scheme? This question matters a great deal for anti-vandalism and SPI considerations, and the matter can't just be omitted from the above discussion. Nsk92 (talk) 23:12, 22 October 2020 (UTC)

Nsk92: Just to be clear, this isn't a proposal as much as it is a conversation starter. In order to solve these questions, we're trying to bring the communities into the process as early as possible, instead of trying to figure out everything on our own and risk missing crucial things. We're sort of taking the kind of conversation that normally lives in Phabricator and having it on the wikis where it's more accessible for more Wikimedians. Do you have use cases we should be aware of here? A preferred solution? /Johan (WMF) (talk) 23:54, 22 October 2020 (UTC)

From the prospective of anti-vandalism and SPI work, the least harmful solution version of IP masking would be some system of assigning internal IP aliases that effectively serves the same purposes that the current public IP address system does. That is an alias system where, say, two IP editors with "similar" (in whichever ways the term is precisely quantified) public IP addresses are assigned "similar" internal aliases. That might still allow for some modified form of range-blocking; in cases of sock puppetry and block evasion it would also make it easier (as the current system does) to infer that the same editor is engaged in IP hopping. I have no idea if such a way IP aliases is technologically feasible (plus, I suppose, you'd have to make sure that one can't actually de-scramble it), but in terms of preserving the functionalities of the current system, that'd be most useful, IMO. Nsk92 (talk) 10:11, 23 October 2020 (UTC)

As a note, this discussion is clearly critical, (certainly we need something far better than mere cookies) but it's not inherently related to this specific conversation topic (they warrant their own section), which is who will have access to the information (whether that be the default - whatever that turns out to be), partial, or full. The discussion will logically expand into "and what are going to be the levels needed for those access rights" Nosebagbear (talk) 10:25, 23 October 2020 (UTC)

Statement from the Wikimedia Foundation Legal department

This is a statement from the Wikimedia Foundation Legal department. They are reading the conversation, but there will unfortunately be limits to what answers they can give, or we'd have told you all the details from the beginning, of course. /Johan (WMF) (talk) 16:19, 28 October 2020 (UTC)

Statement

Hello All. This is a note from the Legal Affairs team. First, we’d like to thank everyone for their thoughtful comments. Please understand that sometimes, as lawyers, we can’t publicly share all of the details of our thinking; but we read your comments and perspectives, and they’re very helpful for us in advising the Foundation.

On some occasions, we need to keep specifics of our work or our advice to the organization confidential, due to the rules of legal ethics and legal privilege that control how lawyers must handle information about the work they do. We realize that our inability to spell out precisely what we’re thinking and why we might or might not do something can be frustrating in some instances, including this one. Although we can’t always disclose the details, we can confirm that our overall goals are to do the best we can to protect the projects and the communities at the same time as we ensure that the Foundation follows applicable law.

Within the Legal Affairs team, the privacy group focuses on ensuring that the Foundation-hosted sites and our data collection and handling practices are in line with relevant law, with our own privacy-related policies, and with our privacy values. We believe that individual privacy for contributors and readers is necessary to enable the creation, sharing, and consumption of free knowledge worldwide. As part of that work, we look first at applicable law, further informed by a mosaic of user questions, concerns, and requests, public policy concerns, organizational policies, and industry best practices to help steer privacy-related work at the Foundation. We take these inputs, and we design a legal strategy for the Foundation that guides our approach to privacy and related issues. In this particular case, careful consideration of these factors has led us to this effort to mask IPs of non-logged-in editors from exposure to all visitors to the WIkimedia projects. We can’t spell out the precise details of our deliberations, or the internal discussions and analyses that lay behind this decision, for the reasons discussed above regarding legal ethics and privilege.

We want to emphasize that the specifics of how we do this are flexible; we are looking for the best way to achieve this goal in line with supporting community needs. There are several potential options on the table, and we want to make sure that we find the implementation in partnership with you. We realize that you may have more questions, and we want to be clear upfront that in this dialogue we may not be able to answer the ones that have legal aspects. Thank you to everyone who has taken the time to consider this work and provide your opinions, concerns, and ideas.

Comments

• I'm going to have to say that I'm not sure how much I believe that any of " user questions, concerns, and requests, public policy concerns, organizational policies, and industry best practices" could have applied here, otherwise it would be grossly poor form for Legal to not just run a proper notification to the Community to provide notice that such a consideration was underway and gather information on the first three. It definitely reads, in very vague terms, that it's got to be law-generated. I also find "several potential options on the table" rather irksome, since that would suggest that the options provided thus far meet all the Community needs (that is, no loss of any functionality in countering vandalism & sock-puppetry, no increase in false positives, no increase in time taken to carry out those two tasks). While Johan has certainly engaged, I would neither say we have progressed to "options" stage yet, or to provisions of solutions that are fully "supporting community needs". Nosebagbear (talk) 16:29, 28 October 2020 (UTC)
• The issue is that why we need this haven't been revealed by legal team. Yes, if we say which law this might contravene, people might sue striaght, but at least we can have a hint on which countries law this might contravene. Regards,Camouflaged Mirage (talk) 16:42, 28 October 2020 (UTC)
• Sadly, I can't tell if Legal invoking privacy/legal concerns is just "smoke and mirrors" or if there are really legal concerns here. After all, they refused to tell us anything in WP:FRAM and it did just turn out to be interpretation and WMF-created constructs rather than a black-and-white violation of the law or TOS. The answer to the question Is this project the result of a particular law being passed? makes me think that this is the WMF's own deliberation and subjective opinion rather than a black-and-white violation of a particular law. Community trust is low at this point, and condescending political drivel like this that ignores the consensus and objections from the community doesn't help. --Rschen7754 00:44, 30 October 2020 (UTC)

  Also: can we know who wrote the statement? --Rschen7754 00:45, 30 October 2020 (UTC)

  This is probably not that useful - I imagine that several people will have helped write it, and it was probably reviewed by at least the vice-GC. Nosebagbear (talk) 13:36, 30 October 2020 (UTC)

Yes, they collectively reviewed it. /Johan (WMF) (talk) 05:58, 16 November 2020 (UTC)

• It's not clear if this proposed change has any legal compulsion behind it. It's written to read that way but a careful perusal shows that content doesn't actually say so. The Statement seems to say that the privacy subgroup of the legal team recommends IP masking but it also says that the privacy group operates makes decisions that "are in line with relevant law, with our own privacy-related policies, and with our privacy values." Adding IP masking is clearly within relevant law. What's clearly more interesting is if not having IP masking is within relevant law, especially considering that our Privacy Policy explicitly states that your IP address will be visible if you edit Wikipedia without an account. It's completely consistent with the statement that the privacy group just decided that since IP masking increases privacy, it's a good thing and more in-line with their "privacy values" and therefore they made a recommendation it be implemented. In other words, under just the wording of the Statement, it's possible this is not a necessary legal change but one intended to protect the editing community. I think it's really important that the legal team distinguish between the two here. If there's actual legal compulsion, we have two easy options, 1) add IP masking at least where needed, or 2) deny anonymous editing where needed. On the other hand, if there's no legal compulsion, it focuses the discussion on whether the benefits of this increase in privacy the change outweigh the cost to the project in terms of implementing IP masking. Those are totally different discussions. Jason Quinn (talk) 06:13, 30 October 2020 (UTC)
• This is a frustrating statement and I think the use of legal privilege as a cloak is unhelpful and misrepresents what that tool is meant to achieve. As others have said, it's not clear where there is a legal basis to the change at all, or whether it has been driven by Legal or by other groups. I cannot see how the community can support the change or can input meaningfully if we don't understand the reasoning. I asked previously, but haven't had a response, on whether the Board has supported this approach? Best, Darren-M (talk) 11:27, 30 October 2020 (UTC)
• TLDR: Hi this is us, trust us, we can't or won't say anything. Not that I don't think we shouldn't be hiding IP addresses, but these kinds of statements are kinda useless of course, and when you put so many words of window dressing on top, the only expectation should be that people will be annoyed. —TheDJ (talk • contribs) 12:09, 30 October 2020 (UTC)
• I feel like I have just read a press release from Trump's White House. The Statement even invoked "privilege" to refuse to discuss the specific reasons for the Legal's decision. I suppose next thing we'll hear that some NDA prevents them from speaking more openly. Or perhaps somebody is being audited by the IRS and they have to wait for the results first. Nsk92 (talk) 11:02, 31 October 2020 (UTC)
• Legal said: We can’t spell out the precise details of our deliberations, or the internal discussions and analyses that lay behind this decision, for the reasons discussed above regarding legal ethics and privilege. In other words this tells us nothing except Legal thought it was a "good idea", and doesn't explain the legal threat or lack of, or whether this is merely a best practice rubber-stamp. So much for community involvement in a potentially devastating decision. --Mrjulesd (talk) 13:58, 31 October 2020 (UTC)

It is much worse than that and the Legal's Statement is unethical and dishonest on several levels. First. nobody is asking them to disclose the "the precise details of our deliberations, or the internal discussions and analyses that lay behind this decision", it's complete BS. They can still explain what their summary conclusions were, at least in broad terms, or even in more specific terms, if there are particular countries/jurisdictions and local privacy laws where our current practices with using unmasked IP addresses may be problematic. Nobody is asking for a detailed legal brief here or an explanation how exactly this brief was produced. Second, the Legal's Statement above is so obfuscating and obtuse in its language that after reading it I understand less than I did before the Statement was issued here. Originally I assumed that our current practices with unmasked IP addresses place WMF in legal jeopardy in some jurisdictions because of some local privacy laws somewhere. But the Statement above uses much more obscure language on this point, as Jason Quinn notes above. So now I don't know what to think, exactly. Third, whatever professional ethical legal "privilege" conundrum the fine folks from Legal think they find themselves in, the WFM officials above them are not limited by such considerations. They can, and in my opinion certainly should, explain to us in their own layman's terms, what the substance of the issue compelling this change is. In fact, I'd rather hear this explanation from somebody at WMF than to read another torturous exemplar of verbal obfuscation and evasiveness prepared by Legal. Nsk92 (talk) 14:57, 31 October 2020 (UTC)

What I know about legal privilege in the US wouldn’t fill a thimble, which I was reminded of when I first tried to answer this requset and it was gently pointed out to me that I was mistaken about how it works.

I could do not just the WMF, but the movement, damage by blindly speculating about things far beyond my area of expertise while publicly representing the Foundation. It's certainly frustrating to be bound by legal aspects in communication from this side, too. If I had things to share that I could share, I would: Not just for the communities, for transparency and so on, but also for purely selfish reasons – it would make my life so much easier. But not only am I not equipped to analyse the legal situation: If privileged information is shared with me in my professional role, I'm legally bound not to spread it. (Otherwise it'd be a very thin paper shield – if lawyers wanted to share something they weren't allowed to, they could just share it with a non-lawyer colleague, who could then tell everyone.)

I know it’s not just one single jurisdiction that worries them, and that they consider our publication of IP addresses out of sync with where modern privacy law in general has moved and is moving, but I know precious little more than that. I’m very much here from the product side of things. /Johan (WMF) (talk) 06:02, 16 November 2020 (UTC)

• As an attorney who specialises in IT and data protection law, I have very much supported this project since the beginning. I am confident that this change can be implemented in a way that protects the privacy of unregistered users and gives the community the necessary tools to keep vandals at bay. However, it bugs me whenever I read a statement from the legal team that says they can't disclose something for professional reasons. Their client, the Wikimedia Foundation, could simply choose to allow them to disclose whatever they know or think. So the real reason that they're not saying something is that WMF management has consciously decided to keep it a secret, and probably for good reasons – we don't want to make it easy for people to attack us. When that is the case, we should say it that way. Leave out the legal jargon, it just makes the community angry and doesn't help anybody. --Gnom (talk) 22:13, 22 November 2020 (UTC)
• More questions than answers.

Reading the statement from Legal has left me feeling even more unsure about what is going on. Here is my attempt to interpret the language of the Statement. I don't mean to pick it to shreds for the sake of disparagement; I imagine the words were carefully chosen, so I'm trying to see what we can understand from them and what is still obscure.

we can’t publicly share all of the details of our thinking

We don't want all the details, but some clarity of where the goalposts (and out-of-bounds areas) lie might help.

We believe that individual privacy for contributors and readers is necessary

Of course, but it's debatable whether IP addresses are PII in the same way that residential addresses or phone numbers are. [1]

applicable law, further informed by a mosaic ... guides our approach

So, is it a legal imperative, or just a guide?

this effort to mask IPs of non-logged-in editors

Is it sufficient to have made an effort? If the outcome is "we made some improvements but other changes were found to be impractical", if our eventual position is that we "have made reasonable efforts to protect users' privacy", would that work in a legal sense?

from exposure to all visitors to the Wikimedia projects.

From whom should addresses be masked? Does "visitors" include registered users? Does "all" mean everyone, non-negotiable?

the specifics of how we do this are flexible; we are looking for the best way to achieve this goal ... make sure that we find the implementation

This sounds like you've already decided on the what, per above you can't/won't tell us the why, you just want to consult on the how, right?

we may not be able to answer the ones that have legal aspects.

Everything has some legal aspect. Does that mean Legal can answer nothing publicly? If you can't discuss "applicable law", can you discuss the non-legal "own privacy-related policies, ... our privacy values", "public policy concerns, organizational policies, and industry best practices"?

[Apologies if DT-DL isn't desirable formatting above, feel free to adjust that.]

[1] To match my IP address to my real-life identity, you would have to compel my ISP, or operate a service where you have already made that connection in your own logs. If you call my utility supply company and give them my name, address, and phone number, you'd be a fair step towards impersonating me, but my IP address won't work for you there. On the other hand, addressing information can be used more directly in non-personal-identification ways: if you know my phone number then you can call me and harass me; if you know my IP then you can DoS my connection or crack into my network; if you know where I live then you can throw a Molotov cocktail through the window. So though "privacy" laws may generally be about reputational harm and freedom from unnecessary surveillance, there are other potential harms. There are also things that are legal and required in jurisdictions where Wikimedia operates, but still harmful to the users and to the mission, e.g. assisting local authorities to track down and seize users into custody for being involved in "subversive" Wikimedia activities or for disrespecting the Grand Leader, etc. It's one thing to say you want to protect users' privacy, but if we are not clear on what we're protecting against, then how can we assess how effective are those protections?

I hope everyone is getting a holiday break if it's a festive season in your part of the world. For some of us, being away from the day job means more time to engage in Wikimedia. For those whose job is Wikimedia, then we'll hear from you in good time. Best wishes, Pelagic (talk) 05:15, 29 December 2020 (UTC).

Regarding the [1]: social engineering is very much a thing. More importantly, the DPAs consider "IP addresses" to be PII [1][2] ProcrastinatingReader (talk) 22:08, 30 December 2020 (UTC)

Sure, but one can choose to make their PII public. If people see the big yellow box that says "Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits." and decide to not log in or create an account, I don't see a compelling privacy issue. If they want to not have their IP public, there's a very simple solution. —‍Mdaniels5757 (talk • contribs) 22:58, 30 December 2020 (UTC)

I think the idea is that most people don't know what an IP means. Most people don't know basic password security either, hence some sites need to enforce password strength and 2FA requirements. ProcrastinatingReader (talk) 19:50, 31 December 2020 (UTC)

Pelagic: Thank you for patience, and yes, we're coming back from the holidays now. I can't answer everything, as I'm not from Legal, but to briefly comment on the "all visitors" part, no, it doesn't mean from everyone, including stewards, checkusers and so on – or others: we're talking about how to give more people access to this to combat vandalism elsewhere, e.g. discussions on a potential new user right. /Johan (WMF) (talk) 22:48, 6 January 2021 (UTC)