# Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

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

## Support and Oppose List

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

### Editors in opposition to this proposal

1. Computer Fizz
2. MER-C
3. Incnis Mrsi
4. LightandDark2000
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.
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
45. Victar
46. OJJ
47. Rschen7754
48. Smallbones
49. FocalPoint
50. Indy beetle
51. आर्यावर्त (talk) 07:06, 29 August 2019 (UTC)
52. Arthur Rubin T C (en: U, T). I thought I was clear. I'm opposed, but would be willing to reconsider if better anti-vandalism tools are provided to all (including IPs), and provide better coverage than existing IP-based tools. 05:36, 28 August 2019 (UTC)
53. Johnuniq (talk) 07:06, 28 August 2019 (UTC) I might have been too subtle below.
54. Vehemently. Praxidicae (talk) 19:59, 28 August 2019 (UTC)
55. Strongly, WMF start solving real problems first - you have open bugs and feature requests from 10 years ago. --Dirk Beetstra T C (en: U, T) 07:56, 29 August 2019 (UTC)
56. Sunny00217
57. Double sharp (talk) 02:38, 1 September 2019 (UTC)
58. JFG
59. Vermont
60. — Draceane talkcontrib. 07:29, 3 September 2019 (UTC)
61. Celia Homeford (talk) 12:58, 3 September 2019 (UTC)
62. Very trivial issue that seems like a pointless chore to implement, let alone put into effect. Do I even need to stress why this will cause more problems than it solves? (Especially when others put it better than I can.) ToThAc (talk) 23:35, 4 September 2019 (UTC)
63. Vojtasafr (talk)
64. What a terrible idea Nomad (talk) 16:59, 5 September 2019 (UTC)
65. Strongly oppose. --Homo ergaster (talk) 17:11, 5 September 2019 (UTC)
66. All or nothing; implement mandatory registration or leave it as it is. PCHS-NJROTC (talk) 23:46, 8 September 2019 (UTC)
67. No. Make it possible for the patrollers to also see ip's of logged-in accounts to track puppetry. --Madglad (talk) 03:33, 9 September 2019 (UTC)
68. * Pppery * it has begun 03:44, 9 September 2019 (UTC)
69. MrClog (talk) 18:49, 10 September 2019 (UTC)
70. Trialpears - IP editors are aware that their IP will be shown and if that's a major problem they can register an account without even an email.
71. Oppose.As noted below is voluntary and it is disclosed that the IP address will be visible to anyone anon making an edit. Now as some other editors have pointed that we can make this more clear to the IP editors by having a checkbox as pointed out below and through it is already clearly mentioned Your IP address will be publicly visible if you make any edits. and Saving the change you are previewing will record your IP address in this page's public edit history. but we can have a checkbox in addition to this to be even more clearer.Pharaoh of the Wizards (talk) 20:12, 15 September 2019 (UTC)
72. Notrium
73. nsaa (talk). I really don't see any advantages of doing this masking. One of the cornerstones of the Wikipedia projects has been the ability to edit directly from your IP address. It's easy to handle vandalism from Schools (and help teachers). You can do range blocks, you can create 3rd party services like this Twitter account that send out all editing done from the Norwegian Parliament Stortinget at https://twitter.com/wikistorting etc. 06:34, 12 October 2019 (UTC)
74. Accountability and reputation are good for the projects. Accountability and reputation require a persistent identity, and the only way to have persistent identity is via usernames. This proposal wouldn't make identity less persistent, but it would make it more difficult to make it more so. It would do that by lending fresh legitimacy to shifting identity, as well as increasing our investment in it, whereas we are currently just tolerating what was created in the beginning and has outlived its usefulness; i.e. unregistered editing. Mandruss (talk) 00:23, 15 October 2019 (UTC)
75. Jéské Couriano (v^_^v)
76. Oppose. Creating an account expresses a wish to be part of the community. If an editor does not want to be part of the community, then we owe them nothing. -- Llywrch (talk) 16:56, 3 November 2019 (UTC)
77. See EN:WP:SNOW. In other words, "given the overwhelming results here, this doesn't have a snowball's chance in hell". Alsee (talk) 23:58, 7 November 2019 (UTC)
78. Per IP Editing: Privacy Enhancement and Abuse Mitigation#Q: Will users with advanced permissions such as CheckUsers, Admins, Stewards still have access to IP addresses after this project is complete? I am opposed to preventing trusted admins on a site from being able to see IP addresses. This is critical to preventing abuse and harrasement of participants. --mikeu talk 06:53, 27 November 2019 (UTC)

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

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

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

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

### Sounds good

I proposed this in 2013 Wikipedia:en:User:Sphilbrick/User_naming_convention_proposal At the time I wrote that, I did not focus on the issue of privacy, but I did identify several problems that this approach would address, so while this particular approach may be motivated by privacy issues, if implemented correctly, it will simultaneously solve some other problems.--Sphilbrick (talk) 12:41, 1 August 2019 (UTC)

Sorry but I don't like your idea. It has a lot of problems but I'll just mention one: nobody is going to remember their own username if it's a seemingly random string of characters. -kyykaarme (talk) 20:02, 2 August 2019 (UTC)
I think you are misunderstanding the issue. This no particular need to remember your username — the entire point of this is to assign generated username for people who choose not to login. If you make your first edit without logging in you will be assigned a name. If at some later point in time to make another edit the system will keep track of you and will assign the same name you won't need to remember it. Secondly, it's not all that hard. It's a string that includes the date you first edited followed by a relatively short sequence, probably a number between one and a couple hundred. My specifics key can be made a little easier now because I originally wrote it before unified login track of the language. In summary, you don't need to remember your assigned username but if you want to it's easy.--Sphilbrick (talk) 21:17, 3 August 2019 (UTC)

It's more human readable, instead of numbers and dots now it's just numbers. Computer Fizz (talk) 17:51, 16 September 2019 (UTC)

### IP Encryption?

On the thought of what text string should be presented instead of an IP address, the idea of presenting an encrypted IP address of some sort springs to mind. It's similar to how password checking works - a password is entered and encrypted, and then compared to a stored encrypted version, without the unencrypted version being stored. In the case of IP addresses, as long as a unique encryption algorithm is used, I'm thinking an encrypted IP address could be shown wherever a plain IP address currently is. That should still work for, say, checkuser checks where the checkuser can see that a registered account and an unregistered editor do or do not share the same encrypted IP without being able to see the plain IP, but with privacy protection in that you can't determine location information from it. And, given that there's no longer any private location information, maybe checkusers could then even be allowed to link registered accounts to encrypted IPs, where they're currently forbidden from doing so. You wouldn't be able to do range checks and range blocks from an encrypted IP with current tools, but presumably tools could be developed to, say, "Show contributions made by the /xx range in which the IP associated with this encrypted IP lies", or "Range block the /xx range associated with this encrypted IP". Anyway, it's early where I am and I haven't been up long and I might be talking nonsense - or I might be teaching Grandma to suck eggs. But I thought I'd offer my thoughts. Boing! said Zebedee (talk) 10:08, 2 August 2019 (UTC)

We'd rather hear something we're aware of ten times than miss important input because someone figured we'd already thought about it. (: /Johan (WMF) (talk) 10:13, 2 August 2019 (UTC)
Definitely an idea worth exploring. The problem with encryption is, what if the WMF is hacked and the key is stolen? Then an attacker can decrypt the IPs. On the other hand, if you perform a one-way hash on the IP, like is best practice with passwords, how do the checkusers get the IPs back? Also, hashes of IPs could be precomputed, so you'd need a salt, but then that needs to be kept secret... Basically, good crypto is hard, and if checkusers/WMF have a backdoor, then so does everyone. BethNaught (talk) 11:50, 2 August 2019 (UTC)
One option would be to store the IP but only display the one-way hash. But this could eventually be broken. GoldenRing (talk) 12:13, 2 August 2019 (UTC)
I see two problems with this, one particular to this scheme and one that's been mentioned several times before:
• Firstly, it's a privacy-protecting as your encryption is strong. Once the encryption is broken, it will reveal all IP addresses ever recorded using it. The encryption could be broken by (a) newly discovered vulnerabilities in the encryption scheme used (or old vulnerabilities if the choice is made poorly); (b) someone leaking the encryption key; (c) someone stealing the encryption key; or (d) someone breaking the encryption (brute force attacks etc). Only the first of these can avoided indefinitely, if you happen to choose a perfect encryption scheme with no implementation bugs. All of the rest will happen eventually; all you can do is make them as unlikely and as far-in-the-future as possible. Perhaps you could find ways of changing the key over time, though any scheme I can think of has enormous drawbacks; principally, that anyone who refers to an IP by the encrypted text on-wiki would expect that text to remain constant, so that others will understand in the future what they were talking about.
• Secondly, WHOIS information is useful. When I'm dealing with an IP, my response will be quite different depending on whether WHOIS says it's a school, a university college, a business, a public library or a consumer ISP. One potential way around this would be to record edits against a CIDR range instead of an individual IP; this would allow us to WHOIS an IP edit and see where it came from but it would make it impossible to conclusively tie an individual edit to an individual editor. It might also make dealing with IP-hopping editors on dynamic addresses easier. But I'm sure others will think of problems with this scheme.
Overall, I have some sympathy for the suggestion above that we just turn off IP editing. I'm not really convinced by the argument that this would make dealing with vandals much harder; for anyone who really wants to avoid this sort of scrutiny, creating an account is already an option and if that makes it so much harder to handle them, it's hard to believe that the determined vandals are not doing this already. On the other hand, the bar of creating an account (as low as it may be) would deter some of the drive-by vandalism we get; it's hard to think that much of what I refer to as the "Welsh school lunchtime" contingent could be bothered creating an account to change the name of their head teacher to something endlessly amusing. GoldenRing (talk) 12:13, 2 August 2019 (UTC)
One problem with turning off IP editing is that lots of goodfaith editors start off making a few IP edits. So losing IP editing would raise a barrier against those editors and lose us a proportion of them. While if it is true that vandals and spammers do the minimum needed to do their vandalism or spam, we won't lose any vandalsim or spam, we'll just make it a little harder to spot. WereSpielChequers (talk) 09:22, 29 August 2019 (UTC)
Also, more of a feather in your cap if you can "hack" Wikipedia. We'll lose some of the bored 12-year-olds but not necessarily those who can do some real damage (and Wales especially?; I've been impressed by how much vandalism comes from capital cities and other posh places where you might expect better: Dubai, UAE, the Australian outback). Dhtwiki (talk) 22:28, 20 October 2019 (UTC)

This type of encryption scheme would be unworkable with regard to rangeblocks, for several reasons. Firstly, ISPs are inconsistent with how they both report and assign the subnets from a given allocation. A user could be confined to a private subnet that is not even listed on the WHOIS data, or he could be roaming over a shared pool that is somewhere between the largest and smallest networks listed on WHOIS. A Comcast-USA customer can be blocked with zero collateral, while it is impossible to block a T-Mobile-USA customer without also blocking 15-20 million other customers, and in either case you need to either see who is on the range or simply know about the ISP to configure the block correctly. If they are just going to hand us the ISP information, including location, then there was no point to the fancy encryption scheme to begin with. And if they are going to keep that a secret but let us see everyone on the same /XX range where XX can be anything, privacy is also out the window, because some of those people are not going to be shy about where they are. And if you think you can get around this by having some internal software automatically find the smallest range that catches all of someone's secret IPs, that is even worse. You could have the software report how many people share the range it's chosen, but you're taking a sledgehammer to a problem that could be excised with a scalpel. That is, if someone vandalizes Wikipedia from their home computer, and then they switch to their neighbor's wifi to vandalize it again, and you include both IPs to have some secret serverside thing make a rangeblock, congratulations, you've just blocked all of Chicago. But if you'd known the actual IPs, you could have just blocked the vandal. And regardless, even under that scheme where even the admin never knows what the IPs were, privacy is still out the window because when you do take out an entire city or country, a bunch of people are going to file unblock requests, and unless WMF is going to have us handle those blind, we're probably going to know which block caught them, and boom goes the privacy. In brief, there are a lot of very clever ways to mask IP addresses, but we already have an excellent one deployed - registration. Future technology developments should focus on abuse mitigation, not abuse facilitation. Someguy1221 (talk) 23:41, 2 August 2019 (UTC)

### Synthetic user names

This can be done simply by using the existing IP address and do a modulus division. The remainder can then be used for lookup in a hashed name table. Doing this with several base numbers will give several names, and joining them will then give a synthetic name. Instead of a cryptic 123.231.012.210 you will get something like “Colorful Moccasin” or perhaps “Hungry Crocodile”. To make the name recognizable as anonymous they should be prefixed with something like “Anonymous”, so full names would be “Anonymous Colorful Moccasin” and “Anonymous Hungry Crocodile”.

The synthetic name can be stored as a cookie on the machine, and as long as this exist the synthetic name is reused for editing from that machine. As long as the cookie exist the machine will be identified with the same synthetic name.

To avoid that two different users on the same IP address is given the same synthetic name the IP address should be merged with a slowly changing random number. It should still update faster than the lease time on the IP address. That will make the system generate new synthetic names for each anonymous machine over time.

A variation is to replace or augment the random number with a digest from the agents header fields. That will make a more machine specific synthetic name, but note that nothing stops someone from using the exact same machine, OS, and browser as someone else from within the same school, university, or company.

A very interesting, yet somewhat difficult solution, is to make a user specific fingerprint. It will be difficult to make it similar enough that the same user is assigned the same synthetic name for each session. It is although possible to measure a fingerprint to see if it is likely that two sessions belong to the same user. A fingerprint will typically be w:keystroke dynamics, which will be collected in the browser and transferred to the server as content of a cookie. A user will then slowly over time establish a stable fingerprint. — Jeblad 14:39, 5 August 2019 (UTC)

This doesn’t address long-term abusers who use the “private” mode in browsers, or may delete cookies manually. These concerns are expressed on this talk: so many times (and by different authors) that I won’t bother to find a specific link for Jeblad. Moreover, some IP ranges are infested with physically distinct abusers, schools and cheap/leaky hostings serving as most known examples. Incnis Mrsi (talk) 16:35, 5 August 2019 (UTC)

### Regarding the automatically generated handles

> > Q: If we don’t see IP addresses, what would we see instead when edits are made by unregistered users?

> A: Instead of IP addresses, users will be able to see a unique, automatically-generated, human-readable username. This can look something like “Anonymous 12345”, for example.

I don't like this handle, would suggest

• If random, make it non numeric, ie 'Mooing lemur' or 'Flying eggs' or another nickname that is more readable.
• Anything customizable and marked as non-registered could also work if they store it in a cookie.

Thanks and regards, --Gryllida 00:00, 6 August 2019 (UTC)

I have raised this issue a number of times, so I'm pleased something is now being done. It's quite unusual for a website to intentionally publicly reveal people's IP address, and to do so without giving users a full and appropriate explanation of the consequences of having their IP address revealed to everyone permanently.

Each unregistered log in can be assigned a guest name and number that is associated with that IP address. The guest name being selected randomly. So an IP address, such as 172.16.254.1, could become, for example, Guest NW567, and each use of 172.16.254.1 would be shown as Guest NW567. SilkTork (talk) 09:23, 6 August 2019 (UTC)

We could create a new user field - GuestUser, to run alongside User. This would immediately identify the user as someone who has intentionally not created an account, and such users would have the same limited access as IP users. Where an IP address is known to belong to a school or library, this could be identified as GuestUserLibrary and GuestUserSchool. SilkTork (talk) 09:33, 6 August 2019 (UTC)
Great idea. Perhaps we can add country code as well GuestUserUk, GuestUserUs etc. followed by Com, Edu, Lib, Xxx whatever so we have an idea where Nomen Nescio hails from.
Greetings & salutations, Klaas Z4␟ V:  10:11, 6 August 2019 (UTC)
@SilkTork: sure, but it is also quite unusual for a website to intentionally allow anyone to edit.
Also, people do get warned that their edits are associated with their IP address ("Saving the change you are previewing will record your IP address in this page's public edit history"). I can agree that that warning could (or even should) be more elaborate, but it is there. --Dirk Beetstra T C (en: U, T) 10:22, 6 August 2019 (UTC)

### L10n/i18n

Now I know I'm getting way ahead, but remember that MediaWiki is proud of its internationalisation and localisation, supporting hundreds of languages. The specific suggestions above are only starting points, I know, but any final solution will at least need to be:

1. language-neutral and script-neutral or localised before it's deployed;
2. gender-neutral (if we need to ask for gender preferences we defeat the purpose of non-registration);
3. and yet sufficiently stable to not break signatures, SUL and so on.

There is no way we're going to have a sufficiently advanced dictionary to support a string of the kind "Anonymous <adjective> <noun>" in 400 languages, so we can discard that option outright. We could use the "User" namespace translation plus a number (and then format the number according to each language's convention), but this would already break (3): changing translation would be impossible because we'd need to rename the user across all wikis.

So in practice there aren't many options: we'll probably need the username to be just a number, or some neutral Unicode character plus a number, although the display might be different (cf. #IP address attribution is just rubbish). This is what StackExchange does, unsurprisingly, although they prefix the number with "user" because they're basically English-only. Nemo 16:24, 6 August 2019 (UTC)

We don't localize user names, or demand that user names must be localizable, so a claim we must localize anonymous (or pseudonymous) user names is invalid, at least for now and the foreseeable future. I'm not even sure it would be possible as user names are often constructed from real names, and we can not and should not try to localize or demand that real names should be localizable. We can although create a subsystem for transliteration that can handle real names and pseudonyms.
If we want to create synthetic names, and make them translatable (which would be contrary to present handling of pseudonyms) then we can use existing translated sets of terms. Note that we don't have to translate "Anonymous <adjective> <noun>" in 400 languages as the previous participant argue, it would create a ${\displaystyle O\left(K\times M\times N\right)}$ problem, but translate "<adjective>" and "<noun>" in 400 languages, which would create a much simpler ${\displaystyle K\times \left(O\left(N\right)\times O\left(M\right)\right)}$ problem. This neglects problems with languages that has changes in grammatical case given adjective or noun, but I'm not sure we must (or need to) support this.
In short; I believe this is a constructed problem, and it is an attempt to escalate non-existing problems to keep the current system. — Jeblad 12:16, 16 August 2019 (UTC)
We do localise the part of "usernames" that is software-made, i.e. the namespace. We don't need to translate the usernames because it's the users' choice to use whatever language is appropriate to their activity. Nemo 07:54, 26 August 2019 (UTC)
While we might not have "Anonymous <adjective> <noun>" in 400 languages, it's okay to have graceful degradation and fallback to either a neutral number or an English user name when there's no translation into the language. ChristianKl❫ 17:01, 27 August 2019 (UTC)
Not a fallback to English, because that would produce a mass of untranslatable software-generated "interface"; yes a fallback to a language-neutral method. However, I see little point in developing a method which doesn't scale language-wise: better focus on a method which can scale. Nemo 19:06, 10 September 2019 (UTC)

## Simpler solution - turn off IP editing

All of the privacy concerns identified here could be addressed by disallowing anonymous editing. In 2019, registering an account (with no requirement for email or any other kind of validation) is a ridiculously low bar. There would be substantial cost savings, since all of the design, specification, and creation of software necessitated by this "enhancement" would be eliminated. More to the point, Wikipedia volunteer administrators would not experience a substantial shift in their decades long practice. All of this seems obvious, but someone had to say it. Bitter Oil (talk) 18:34, 1 August 2019 (UTC)

As someone who has spent a lot of time blocking autoconfirmed vandalsocks, I have to also say that blocking new accounts is like playing Whac-A-Mole. There are good reasons for keeping unregistered users on IP addresses - namely being able to effectively block them. zzuuzz (talk) 18:47, 1 August 2019 (UTC)
If anyonymous editing were just turned off, or changes were sufficiently disruptive, I could forsee that on EnWiki the practice of warning vandals before blocking would be abandoned under a deluge of vandalism. Sentimentally, I would support a zero-tolerance approach to vandalism, but in reality this would breed even more trigger-happy admins, further reducing the wiki's welcomingness and diversity. BethNaught (talk) 19:14, 1 August 2019 (UTC)
I think the WMF is telling us that they are going to hide IP addresses. Leaving things as is does not seem to be an option. Turning off IP editing is much less work to accomplish the same goals. Perhaps they could use the budget for this project to work on better tools for admins instead. Bitter Oil (talk) 20:27, 1 August 2019 (UTC)
Your edit summary is unappreciated. I know very well that the WMF can play games, but I also know that the community is a match for them. Whether the WMF is being deceptive or not with this initiative, we have an opportunity to steer the direction or even stop it. As to whether they are being deceptive, I am not going to engage in any drama-mongering at this stage.
Ironically, if it hadn't been for the edit summary, I would have been sympathetic towards your comment. BethNaught (talk) 20:41, 1 August 2019 (UTC)
Community consultations don't have sections called "implementation plans" and don't say things like "We'd like to figure out sensible early steps that a development team could work on soon" and don't have the "Director of Engineering" fielding questions. It isn't drama-mongering to point out this is a done deal. Accepting that will greatly reduce the drama potential. Bitter Oil (talk) 21:21, 1 August 2019 (UTC)
I can really see where this looks like a done deal. It looks like that to me too. The phab ticket looks like a developed plan to implement it, the research paper looks like a prepared justification, it appears input is mostly being solicited on how to implement it - and not if it should be implemented, and it looks like this has been discussed privately for at least a year if not longer. Even as someone that thinks that this could be implementable with lots of hard work, a few to several years down the line - that's how this appears. SQLQuery me! 02:09, 5 August 2019 (UTC)
Of course, the drawback of "accepting something to avoid drama" is that the accepted thing may be a bad one. And turning off IP editing is likely going to be bad, since it will reduce participation, and we don't know what the impact will be. Jo-Jo Eumerus (talk, contributions) 21:34, 1 August 2019 (UTC)
• Turning off IP editing is an awful idea that goes against Wikimedia's ethos of "anyone can contribute". We already have so many editor retention problems across the spectrum that adding another bar to initial participation would severely exacerbate our biggest problem. — Bilorv (talk) 18:44, 2 August 2019 (UTC)
• I support this proposal. Speaking as an EnWiki admin, vandals seem much more likely to operate from unregistered accounts than registered ones. Requiring people to take the simple step of registering an account will considerably thin out the amount of vandalism volunteer admins need to respond to, for almost zero loss to content improvements. As noted above, it would also be simple and very low cost to implement. Nick-D (talk) 02:06, 3 August 2019 (UTC)
• While the concern of barring new editors further is valid (there are people who prefer not to have an account tied to their edits), considering most people already make accounts for social media and other websites, it won't be a barrier to most. Thus, the removal of anon editing may be the right choice.
Additionally, just hiding IP addresses will hurt our current system (at least, on the English Wikipedia) - for instance, marking shared IPs or finding proxies will be exponentially more difficult as we will only be able to find them based on behavioral evidence, which is subjective and not as good as a "whois" search that can provide a definitive answer.
Both of these do provide a good reason to remove anon editing, but there is the spirit of Wikipedia at stake here as well. Ultimately it will be up to those who created said spirit to decide if it will change. Kirbanzo (talk) 14:13, 9 August 2019 (UTC)
• As a member of the English Wikipedia, I endorse this idea for ironically the same reason User:Bilorv opposes it. In the past few years, I've been seeing some absolutely ridiculous blocks on shared IPs and even /16 ranges by ignorant administrators who are more interested in attempting to prevent school children (and immature adults for that matter) from ever being able to write silly comments on articles (which will never work on an open wiki) than promoting the fundamental Wikipedian philosophy of an open encyclopedia project where any person in the world can contribute to human knowledge. It's 2019, an increasing number of people only have internet through their cell phone, yet admins are thinking nothing of blocking /16 ranges belonging to the top four American cell companies because the likes of some punk 13 year olds circumventing their six year school block grinds their nerves so much that stopping them outweighs recruiting and retaining new users in their minds. It only takes a minute to register an account, and doing this will restrict IP blocks to CheckUsers, who should be experienced in recognizing patterns of abuse rather than blocking four year high schools for "repeat vandalism" because some girl wrote how awesome she thinks she is on an article *one time* after the expiration of a five year block. There has to be a better way to address vandalism than these massive blocks, and with privacy issues in mind, requiring registration seems to be a no-brainer at this point. PCHS-NJROTC (talk) 11:48, 8 September 2019 (UTC)
It takes one minute to create an account and then you forget the details the next time you come back and have to sign up again, and that's too much hassle and then we lose an editor. The solution to admins making uneducated blocks is to educate those admins. Even 60 seconds to create an account is a genuinely very high barrier to the average first productive edit, which is something like "this sentence is missing a full stop" that the reader expects to take 10 seconds to fix, not a full 3 minutes (sign up, now it's redirected you to another page so find your way back, try to find the mistake again and click edit and then the code on the editing screen makes no sense to you so you either give up or have to spend another minute working out which bit the actual text is). I think it's quite rare for someone to go "I absolutely and unequivocally want to start editing Wikipedia as a hobby". More common is someone seeing things they can improve and gradually being drawn in. Forcing account creation cuts off that low entry bar. — Bilorv (talk) 15:03, 8 September 2019 (UTC)

### Make registration compulsory

Feel it is better to make registration compulsory further no email or verification is required for anyone wishing to edit this project and anyone can do it within a minute rather than this. Further vandalism from an account is easy to detect and total privacy is there. Pharaoh of the Wizards (talk) 11:51, 2 August 2019 (UTC)

Never ever. Fundamentally anti-wiki. Winged Blades of Godric (talk) 12:16, 2 August 2019 (UTC)
It could be an automatic registration, with automatic username, linked to IP address, which is used every time this IP address uses WP without registration. This way, the IP is protected the same way a registered user is, and these accounts are managed with the same tools than registered users. No big changes, but the IP are protected. --Jean-Christophe BENOIST (talk) 12:35, 2 August 2019 (UTC)
How do we determine sock-hops or do range block and all that ..... Winged Blades of Godric (talk) 13:14, 2 August 2019 (UTC)
Maybe a smart algorithm can generate username from which we cannot infer IP, but that are close together when they are in the same IP range.. Feasible for IPV4 IMO but hard for IPV6.. --Jean-Christophe BENOIST (talk) 08:25, 3 August 2019 (UTC)
For example, if we use "WhoIs" on an IPV4 or V6, it gives us the CIDR/Range of the IP network. The algorithm could generate a random ID for this network. Then, the weak bits (the place in the network) can also be obfuscated in a deterministic way (hash for example). For example, WhoIs 92.154.22.48 => 92.154.22.0/24 => AEXFUU4XAB. 48 => EFFC8. Username => AEXFUU4XAB-EFFC8. MediaWiki retains of course a private table which can do the reverse. --Jean-Christophe BENOIST (talk) 08:42, 3 August 2019 (UTC)
I agree that compulsory registration goes against the wiki way, and I think that the value of allowing anonymous and easy contribution has been discussed often over Wikip/media's existence. The idea that Jean-Christophe puts forward is one possible solution, though it would still make identifying contributions from a range very difficult. A compromise might be to strongly encourage account creation, through a pop-up message when saving an edit while logged out that says "hey, this will make your IP address visible, are you sure you want that?" That combined with making the account creation process easier (for example, a check to confirm username availability before pressing the register button would be nice) might be the right balance between privacy and maintaining our anti-abuse systems. – Ajraddatz (talk) 12:55, 2 August 2019 (UTC)

Wake up folks, it's 2019. People have no problem registering for Instagram, Telegram, Facebook, etc. Registering an account is a very low bar to participation. Make up a username, solve a captcha, you're done. All the concerns expressed here about privacy and access to information are solved. This project is an unnecessary waste of resources. Bitter Oil (talk) 14:43, 2 August 2019 (UTC)

Sure but from an enwiki perspective (forgive me) it will result in a lot of backlogs, particularly at SPI. If I had to guess, a lot of IP edits are one off interested editors correcting a minor spelling error, adding a source, generally improving an article. So let's say someone finds a spelling error at Apple, they'd be forced to make an account to correct it. They come back 3 weeks later, can't remember the password, didn't register with an email, so they create another, then another, then another and it looks like sock puppetry. I don't see an issue for the most part with the current IP editing system and think that creating barriers to good faith editors (particularly those that work in anti-spam and anti-vandalism) is better for any project. The exception to this is the handful of sensitive IPs, like people editing accidentally (or intentionally) from their work address but that doesn't seem like a good reason to throw out the entire system. I would be really interested in a report on IP statistics before any serious changes are even proposed that outline the percentage of IP edits vs. account edits (if this already exists, my apologies.) Praxidicae (talk) 14:54, 2 August 2019 (UTC)
• I think there are (at least) two objections to making registration compulsory. One is political, in that "the encyclopedia anyone can edit" is a key part of the Wikipedia proposition. OK, I know it's not literally anyone and never has been, but eliminating unregistered editing would be a big political move and I think many Wikipedia critics would see it as evidence of failure. The other objection is as Praxidicae suggests, that it prevents people who are predominantly readers from fixing typos, spelling and grammar errors casually in the course of their reading - and having to register an account to fix a typo you've just spotted would surely make it so that a lot of people wouldn't bother. Do we have any stats anywhere for the number of edits made that way? I suspect it's a lot. Instagram, Telegram, Facebook etc are all well and good, but people want the full social service from those and unregistered use of them doesn't make any real sense. Boing! said Zebedee (talk) 15:47, 2 August 2019 (UTC)
One would think that the quantity and quality of IP edits would be something well understood by the WMF, especially before proposing a project like this. But it is not. If you read the research report associated with this project, it states

A ​2007 study​, conducted by a Wikipedia user, indicated that about 80% of vandalism comes from unregistered users, but that vandalism represented only about 20% of total edits made byunregistered users.

But that 2007 study involved a total of 250 edits (of which 89 were from anonymous users). A tiny study over a decade ago is a very questionable basis for any assumptions. It seems to me that the idea of IP editing being beneficial is an ideological one, not an observed conclusion. Bitter Oil (talk) 16:05, 2 August 2019 (UTC)
The point discussed here is anonymous is not anonymous for an IP and only for a registered logged-in user.Pharaoh of the Wizards (talk) 20:12, 2 August 2019 (UTC)
I'd like to dispute People have no problem registering for Instagram, Telegram, Facebook, etc. on the grounds that a) they are social networks and not encyclopedias so not an apples to apples comparison and b) we have no evidence that Instagram, Telegram, Facebook et al would not receive more input if they allowed unregistered users. It's a quantitative judgment that is needed here. Jo-Jo Eumerus (talk, contributions) 20:20, 2 August 2019 (UTC)
I was not suggesting that the sites are the same, just pointing out registering for sites is something that people understand in 2019. This was not the case when Wikipedia began, but much has changed since then. I have no doubt that Instagram, Telegram, Facebook et al would receive more "input" if they allowed unregistered users but it would not be the kind of content that they want. Bitter Oil (talk) 21:38, 2 August 2019 (UTC)
• You realize that compulsory registration will create exactly the same problems as masked IP editing, don't you? There's no difference in the impact of anti-vandal work, of identifying socks, of not being able to track edits by a specific IP or IP range whether the IP is masked or the potential editor has to create an account. The only difference is in the likelihood that someone will succeed in making the first edit without jumping through the "create an account" hoop. Risker (talk) 01:40, 4 August 2019 (UTC)
I agree on that: registering an account only masks the IP (which can be done in other ways as well). This limits just the occasional vandalisms, for which CUs and other elaborate verification is pointless. That's true that there is a limit on the number of accounts that an IP can make, but I don't think that's sufficient to limit the attacks from LTAs. --Ruthven (msg) 14:03, 6 August 2019 (UTC)
• Requiring registration would be a negation of the entire point of the project. It would be completely unacceptable. --Yair rand (talk) 02:23, 5 August 2019 (UTC)
• Each site may separately decide whether to allow edits (or other activity) without registration. It is up to the whole Wikimedia people to decide on specifications of unregistered edits—where they are permitted—because fighting abuse requires coordination. Imagine editors’ IPs were hashed/encrypted on the site X, left open on the site Y, and hidden from the world on the site Z. Confusion and chaos among Wikimedia volunteers would arise from it. Incnis Mrsi (talk) 08:36, 5 August 2019 (UTC)
• There seems to be at least two theories as to what would happen if we switch off IP editing and require everyone to create an account. The optimists think that none of the goodfaith edits will be lost and that many vandals will be deterred by this step. The pessimists fear that some readers will remain readers and not make those first edits as an IP that precede creating an account, and that the vandals and spammers will still be with us, but just a little harder to spot as they will now all create throwaway accounts. I'm very much with the pessimists, but willing to see a proper research project to test this out. But if it is true that IP editing is part of the "secret sauce" of this site and is one of the things that allowed us to see off rivals such as Citizendium, then it would be a mistake to lose it. WereSpielChequers (talk) 04:55, 7 August 2019 (UTC)
• I remember a study being posted in en:WP:SIGNPOST maybe a year ago that found that a few registered editors were responsible for more than half the total edits, but that their edits were mostly WikiGnoming and the burden of content creation actually fell on IPs and accounts with a couple edits. The IPs' adding a sentence here and there well outweighed all the concerted content creation efforts such as FA/GA. DaßWölf 08:25, 10 August 2019 (UTC)
• Re: the idea of IP editors willing to jump through more hoops to edit, the general UX wisdom in the e-commerce world is that hoops such as registration before the call to action can easily drive off the vast majority of the potential users. While WP's IP editors might be more "ideologically motivated" so to say, that sentiment can realistically take them only so far. DaßWölf 08:25, 10 August 2019 (UTC)

In my personal experience as a long-time volunteer and bureaucrat on he.ws, lots of our hard-to-detect minor typos and scanning errors are fixed by a random passer-by who came to read a text and encountered the typo in the middle of reading. This user will most definitely not bother to register (or log into their account even if the do have one already) just to fix that typo. The benefits of allowing anonymous editing far outweighs the cost of monitoring them.--Naḥum (talk) 16:31, 21 August 2019 (UTC)

To be honest, I don't like this idea, however, if it ties the hands of two specific administrators on the English Wikipedia (who I am not going to name as a courtesy to them) who think making a significant portion of the world population request an account in order to edit Wikipedia is good for our project, I'm for it. Some admins seem to see blocking as punishment rather than prevention, and they can't accept the fact that some vandalism is going to slip through the cracks and letting some things go is how the project remains open as intended; limiting IP access to CheckUsers (and keeping current CheckUser policies) will ensure that editors are judged by their contributions, not where they are editing from, and that a maximum number of the world population has the ability t contribute. PCHS-NJROTC (talk) 00:18, 9 September 2019 (UTC)

#### Research on the Value of IP editing

Several people asked me to respond to the sub-proposal about making account creation mandatory (#4 in NKohli (WMF)'s summary & response) in my capacity as an academic researcher who has studied non-registered contributions to wikis. I have worked with a number of collaborators to put together a response at User:Benjamin Mako Hill/Research on the value of IP Editing which I will eventually move to a page in the Research namespace. The very short version is that we think that research suggests mandatory registration will deter a large number of valuable contributions. We think it is a bad idea.

The page is not an argument against the current proposal to obscure IP address information. In fact, at least one papers we refer to would provide evidence in support of the idea that the proposed change could encourage valuable contributions from anonymity-seeking users. Our argument is focused on the value of unregistered contributors rather than the importance of identifying these editors by their IP addresses.

The page we've put together includes citations to studies that we we believe provide evidence for the claims that (1) many IP-based edits are valuable; (2) blocking IP edits may discourage newcomers from making their first edit; (3) contributing without an account opens a pathway to deeper contributions; (4) past trials of this idea have been damaging; and (5) several other considerations.

I think the strongest evidence is simply that similar experiments have resulted in substantial decreases in valuable contributions. This includes both (a) experiments were users were asked (but not forced) to register before editing Wikipedia and (b) evidence from 130+ Wikia wikis that switched to requiring accounts. Both experiments deterred vandalism and caused enormous collateral damage. Some users will create accounts in order to make valuable contributions. Many others will not.

The page we've put together was written by and has been signed by a number of academic researchers who study Wikipedia contribution dynamics. —mako 00:54, 11 September 2019 (UTC)

I haven't yet read the paper, but this paper would be an argument against IP masking, as Wikipedias would be required to revert sensible statistic edits to avoid having random statistic edits remain in the Wikipedia. There would be even less of a way to determine whether (say) a change of birth date from April 10 to April 12 is a vandal or an intelligent edit than there is now. — Arthur Rubin T C (en: U, T) 00:57, 12 September 2019 (UTC)
Possibly? It seems like it would depend quite a lot on details of how it is done that haven't figured out yet. In any case, the summary doesn't attempt to speak to the IP masking proposal in any systematic way. Just to the counter-proposal to make accounts mandatory. We think the evidence pretty compelling suggests that doing that would incur serious costs. —mako 02:55, 12 September 2019 (UTC)
I haven't had the time to look through everything on that page, but in the first section alone there is cause to wonder about the relevance of this research. Under the heading (and presumed conclusion) "IP-based edits are valuable", the first of the four points is drawn from a 2009 study. The second is drawn from a 2010 study. What was true a decade ago may no longer be true. The third point suggests that IP editors' first edits are no worse than the first edits of new accounts. That is not only a very low bar, it is not an argument that IP edits are valuable. The fourth point suggests that IP edits spur on registered users to (presumably) correct errors. To quote the abstract "Findings show that novice contributors have a direct negative effect on good quality". I question whether this is an unbiased overview of research. World's Lamest Critic (talk) 17:58, 4 October 2019 (UTC)
• Irrelevant waste of time. The section "Make registration compulsory" was supported by about two or three people. The majority of responses in the section rejected the idea, and general community has clear and long established consensus against it. The report author clearly erred in characterizing this as a "major theme" of discussion on this page, and staff erred in thinking it would be a constructive response to the masking discussion to request this research.

### identification from external web sites

Best regards, --Gryllida 00:01, 6 August 2019 (UTC)

Now, this is something that may make sense. --Dirk Beetstra T C (en: U, T) 06:12, 6 August 2019 (UTC)
1. Partnership with big corporate tech giants.
3. Privacy concerns about the data the tech giants want back in such arrangements
4. Our commitment to open source software
WereSpielChequers (talk) 05:03, 7 August 2019 (UTC)
The WMF already has partnerships with "big corporatetech giants". Google and Facebook and Amazon are big donors as well as big consumers of Wikipedia information. OAuth and OpenID are both open standards, by the way. I would be very interested in learning more about "data the tech giants want back in such arrangements". Bitter Oil (talk) 22:24, 8 August 2019 (UTC)

I support this. Autoblocks and IP blocks would still be a thing so "whack-a-mole" is not the case, and would make it a lot easier to identify who made what edits. Or...maybe all IP edits could be pending changes? Computer Fizz (talk) 18:25, 13 August 2019 (UTC)
It could be an option, but it should not be required. Facebook, Twitter, etc are not accessible everywhere Wikipedia is. PCHS-NJROTC (talk) 18:34, 8 September 2019 (UTC)

### IP editing is the opposite of anonymous

This has been well-known for a long time. When you edit under an account, you're as anonymous as you want to be, at least to the public face of Wikipedia (users with Checkuser have more visibility, but not a lot). When you edit logged out, your IP address is revealed every time you make an edit. If it's the goal of the WMF to better secure anonymous editors' IP addresses (which they should, we're years behind the times here) disabling IP editing is the simplest approach.

But we want people to be able to edit anonymously, without jumping through the hurdle of creating an account, right? It's one of our fundamental principles that anyone can edit. Well, that's easy too. The social network Whisper is designed to be fully anonymous, and they do something like this: when you install the app and make a first post, an account is automatically generated with a human-readable name (I'm pretty sure they just pick two random dictionary words and mash them together) and that account is linked to your device. No login, no choosing a name or generating a password, nothing to remember at all. Wikipedia should be easily able to do the same: when someone wants to edit but doesn't have an account, we just randomly make one up and assign it to them for that session. If they edit a bit and decide they want to keep that account (to use later, for posterity, whatever) we give them the option of actually creating a proper account under that name, or rename it to a different permanent name if they want (and the name is available). If not, when their session expires the account becomes inaccessible because there's no way to log in to it, pretty much the same as when a dynamic IP is reassigned. We of course log the IP address and make it available to checkusers for abuse management, the same way we log all account contributions now, but that log is effectively hidden to the vast majority of users and access is pretty tightly controlled.

Yes, it makes some forms of abuse detection marginally more difficult, but that is going to be a thing with IP addresses hidden no matter what way we do it. The "temporary" account's IP is still available to the software so we can still do things like autoblocking an account's underlying IP (so new "temporary" accounts can't be created for the duration of the block) and checkusers could still disable account creation on problematic IPs and ranges. Yeah it's some technical work but that seems to be why we're here. Ivanvector (talk) 16:13, 22 August 2019 (UTC)

This doesn't solve the problem that of 934 projects, only 36 have checkusers. GMGtalk 17:31, 22 August 2019 (UTC)
And that even on en-wiki, only a couple of dozen are Checkusers, and half are Arbs who rarely exercise it day to day. And they're busy with just the current style of sock investigations atm. Nosebagbear (talk) 18:09, 22 August 2019 (UTC)
Yes, it makes some forms of abuse detection marginally more difficult, but that is going to be a thing with IP addresses hidden no matter what way we do it. Or, speaking as a former enwiki checkuser, you're making that out to be a much bigger problem than it actually is. Ivanvector (talk) 13:39, 23 August 2019 (UTC)
Removing wholesale the ability for 96% of our projects to issue range blocks is hardly a trivial matter. GMGtalk 13:53, 23 August 2019 (UTC)

## Strong oppose

This is a terrible idea for many reasons, and is the kind of nonsense one would expect from WMF staff that are totally out of touch with regards to how these projects are run. In addition to the reasons pointed out above:

1. IP addresses being public has provided public scrutiny and deterrence of COI editing and other abuse, see e.g. w:United States Congressional staff edits to Wikipedia.
2. The ability to WHOIS IPs and be able to tell whether they are a school, a webhost, a dynamic residential IP and so forth is essential information in the fight against abuse.
3. Being able to get a new identifier by clearing cookies is so utterly trivial to any experienced vandal. In fact it is a clear regression over the current system where one has to both clear cookies and get a new IP address (range).
4. Range blocks become impossible.

This project should be immediately confined to the trash can and never brought up again. We need to make anti-abuse editing easier, not harder. MER-C (talk) 18:48, 1 August 2019 (UTC)

Hi MER-C. Please avoid calling this nonsense or saying that the WMF are out of touch. We have behavioural expectations on Meta, and I would appreciate it if would make an effort to frame your comments in a more positive and less attacking way. Your feedback on the specifics are appreciated, but can be made without the theatrics. Thanks, – Ajraddatz (talk) 18:57, 1 August 2019 (UTC)
Please avoid calling this nonsense or saying that the WMF are out of touch -- seriously? I am inclined to point at the en-wiki article about snowflakes but it might breach urbanity (which seems like the perpetuation of a colonial stereotype against rural folks), in light of it's political co-relations. Also, in my part of world accusing someone of indulging in theatrics is a clear-cut breach of social etiquette.Winged Blades of Godric (talk) 19:09, 1 August 2019 (UTC)
I understand that it is the wiki way to use strong and aggressive language to get your point across. I'm saying that it is unnecessary and unwelcome here. Please keep comments civil and respectful; your feedback will be considered without an abusive tone (what I meant by theatrics, apologies if you are actually concerned with my word choice). – Ajraddatz (talk) 19:24, 1 August 2019 (UTC)
These are unhelpful and poorly-phrased comments, which explicitly intend to have a chilling effect, and have partly succeeded]. Johnbod (talk) 02:59, 2 August 2019 (UTC)
The only intent is for people to contribute in a productive and civil manner, and that same standard applies to you. – Ajraddatz (talk) 03:19, 2 August 2019 (UTC)
There is a fine line between encouraging civility and suppressing dissent. Caution is in order from both sides. Cullen328 (talk) 23:45, 2 August 2019 (UTC)
It boggles my mind how do you not see the chilling effect of your comment (particularly when coming from a "power-user" such as yourself) - it is pure suppression of dissent! Calling this proposal "nonsense" or the WMF "out of touch" is valid criticism, especially in context. Notrium (talk) 12:34, 19 September 2019 (UTC)
There is an expectation of respectful participation on Meta. As I've said elsewhere, criticism is very welcome, but this discussion should not devolve into name calling and rants. – Ajraddatz (talk) 12:38, 19 September 2019 (UTC)
• Agree with MER-C. They ought to spend more efforts to developing more anti-abuse features (as MER-C and DirkBeetsra has been pleading for years) rather than these. Winged Blades of Godric (talk) 19:09, 1 August 2019 (UTC)
• I totally agree with MER-C. This is nonsense. I come from a small wiki whereby admin credibility is questionable. Restricting access to IP info to this small bunch of admins is much worse than the status quo. On one hand, no guarantee this small group of admin would fulfil anti-vandalism tasks. If only they have access, it's a unnecessary hurdle for non admins to help counter vandalism. On the other hand, when the small group goes rogue and abuses the private info, it's too hard to hold them accountable. Out of 300 wikipedias I'd say ~250 are small. Most non-wikipedia wikis are small too.--Roy17 (talk) 19:10, 1 August 2019 (UTC)
1. This project won't necessarily hide that information. IF we end up hiding IP addresses from administrators (which is a big "if"), we could probably still provide the ISP of the user based on their IP address.
2. See answer to #1 above.
3. As the FAQ says, the generated identifier may be associated "with a cookie, the user’s IP address, or both". If associating it with only a cookie is too easy to circumvent, we won't do it that way. In fact this could be an opportunity to make anonymous editors easier to track by making their identity more sticky than an IP address (which isn't very sticky these days due to mobile editing, VPNs, etc.). We just have to be careful about collateral damage on shared computers.
4. As the FAQ says, "We hope to restrict IP address exposure to only those users who need to see it." If administrators need IP addresses in order to do range blocks, and there is no better way to do it (like automatically creating masked range blocks based on a set of users from the same ISP), then we won't be hiding IP addresses from administrators. We have no intentions of destroying the community's ability to fight vandalism.
• Ryan Kaldari (WMF) (talk) 19:46, 1 August 2019 (UTC)
This does not address my first and foremost concern. The proposal harms the scrutiny of inappropriate edits by the public, and that scrutiny deters abuse. The Foundation knows, or should have known, about the Congressional IP editing scandals. Public interest journalism is not harassment.
> we could probably still provide the ISP of the user based on their IP address
Not sufficient. Geolocation is also necessary. Think Comcast or any large ISP. At this stage, you might as well publish the whole IP address. As for making identities more sticky - I'll believe it when I see it. The Foundation haven't even bothered to make available the entirety of the HTTP request headers to Checkusers, which they are sent automatically on every single page load. (In)actions speak louder than thought bubbles. MER-C (talk) 20:37, 1 August 2019 (UTC)
MER-C Those are good points we will need to take into consideration. Editing from Congressional IP addresses is mentioned in our research report, but it only discusses how administrators interact with that information, not the public. Are there any ways that we could retain some sort of public scrutiny (via something like ISP + state-level Geolocation) without revealing IP addresses to everyone (or exactly where a person is editing from)? In other words, do you think it is possible to improve anonymous editor privacy without losing public scrutiny or are they mutually exclusive in your opinion? Ryan Kaldari (WMF) (talk) 21:03, 1 August 2019 (UTC)
Mutually exclusive. State level is also not good enough - think California and its three large cities, or Guangdong. Also, good luck in getting the community to accept zombie cookies. MER-C (talk) 21:08, 1 August 2019 (UTC)
Also, if you disclose the ISP and geolocation, the whole change becomes unfit for your intended purpose - protecting from the danger of people being at risk of government persecution. The ISPs in third world dictatorships are always controlled by said dictatorships and keep extensive logs - and therefore the proposal is pointless. You cannot say we are going to publish all US IPs but hide all Russian ones because the public has a genuine interest in knowing whether our projects are being (clumsily) manipulated by state-sponsored disinformation troll farms. MER-C (talk) 11:10, 2 August 2019 (UTC)
Indeed: the information available for enforcement would have to at least be the same as what is already known about an IP address (including block/network relationship for range blocks and identifying problematic networks). Moreover, if addresses, or any of that information was restricted to administrators, this would reduce the efficiency of patrollers (most are not administrators, many do not intend to be, but they resort to them when necessary, in which case technical knowledge helps to produce better reports for faster processing, mark schools as such for future patrollers, etc)... PaleoNeonate (talk) 03:57, 27 August 2019 (UTC)
1. There are IPs and IP ranges associated with long term abuse, sometimes sporadic, and therefore IP information must be retained indefinitely. w:Special:Contributions/195.171.136.42, w:Special:Contributions/122.166.47.217 come to memory. There are likely hundreds more. MER-C (talk) 20:51, 1 August 2019 (UTC)
The WMF Security team also needs long-term information about certain abusive editors/hackers, so I imagine we will need to solve that one way or another, perhaps by flagging accounts for long-term tracking or something similar. Let me know if you have any ideas on that. Ryan Kaldari (WMF) (talk) 21:12, 1 August 2019 (UTC)
VxFC was specifically relegated to WMF. What did you do? Winged Blades of Godric (talk) 05:48, 2 August 2019 (UTC)
How am I supposed to tell whether there is an abuse pattern lasting years based on only 90 days of data? Look at the 195.171.136.42 link above: four spam links, then nine months of inactivity, then three spam links, then another six months of inactivity. If the person on the other end of this IP wanted any resemblance of cybersecurity, they would have updated their browser in the meantime = different user agent = different hashed identity. As for the solution, it is obvious - keep the current system. MER-C (talk) 09:13, 2 August 2019 (UTC)
• Doesn't sound like a good idea. If people are concerned about their privacy, they should become registered. I don't know if we warn ip editors their address will be visible, but if not we might consider that. Johnbod (talk) 02:59, 2 August 2019 (UTC)
• Attempting to edit while logged out is always met with "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." Though it seems like a lot of people just ignore this warning, based on how many emails oversight gets along the lines of, "I had no idea my IP address would be visible if I edited." If there is a concern about people doing this unknowingly, then just make the warning huge and intrusive. Someguy1221 (talk) 04:58, 2 August 2019 (UTC)
I endorse the idea of a click-through warning. It is both the easiest and the best solution to this "problem", if it really is a problem. Unregistered users can either affirmatively consent to public logging of their IP addresses, or register an account. Let's not pursue complex, expensive and divisive solutions when a very simple solution is readily available. Cullen328 (talk) 23:40, 2 August 2019 (UTC)
Attempting to edit while logged out is always met with a warning, BUT only when trying to edit enwiki. It is easy to Inadvertently edit other wikis without realizing you are not logged in. Ottawahitech (talk) 02:16, 16 August 2019 (UTC)
That does not seem to be accurate. The message "anoneditwarning" displayed above the edit field is a standard part of MediaWiki, not an enwiki customization. It's possible that some wikis have disabled the message entirely, but that's the non-standard customization. Anomie (talk) 13:42, 16 August 2019 (UTC)
@Anomie:. Yes, you are correct. I don't know why I did not see it before. Sorry for the wild-goose chase.Ottawahitech (talk) 14:36, 17 August 2019 (UTC)
Just to add, though. Sometimes when I am logged in, something happens and I get logged-out without noticing. I don't know if it is a glitch that no longer happens, but I remember distinctly using HOTCAT (this happened years ago), and being logged out in the middle of an update. When I checked the history it clearly showed a HOTCAT update made by an IP, something that should never happen, I think? Ottawahitech (talk) 14:44, 17 August 2019 (UTC)
It is possible that HotCat is or was coded in such a way that it would still make an edit if you became logged out. If it's still the case, that should be fixed in HotCat, for example by checking the user when (re-)fetching an edit token. Anomie (talk) 15:03, 17 August 2019 (UTC)
• I concur with User:MER-C and everyone above. As a non-admin (and as someone who doesn’t want to be an admin) that assists in investigating sockpuppets and long-term abuse when needed, losing access to IP data (and consequently, WHOIS and geolocation information would absolutely cripple that work in investigating abuse, not to mention the invaluable work that the Open Proxies wikiproject does. Even in cases of simple vandalism, there have been times where I’ve reached out to the abuse contact listed on an IP’s WHOIS (mostly schools) to let network administrators know about the vandalism issue, which is invaluable for anti-vandalism efforts and stopping long-term abuse. I’m also concerned at the fact that non-administrators weren’t seemingly taken into account with the report, and I would vehemently urge the team involved to keep us plebs in mind going forward with any decisions made. OhKayeSierra (talk) 07:55, 2 August 2019 (UTC)
1. > we should expect a transitional period marked by reduced administrator efficacy
Translation: we are deliberately compromising the integrity of our projects and deliberately increasing administrator burnout. Let's say the WMF actually gets the implementation order correct and deploys the anti-abuse enhancements first. That leaves a change that in isolation should not be deployed ... in isolation and therefore should not be deployed.
1. > We intend to implement some method to make the generated usernames at least partially persistent, for example, by associating them with a cookie, the user’s IP address, or both.
Say hi to zombie cookies and invasive web analytics, because that is the only way this will work in any acceptable manner. MER-C (talk) 09:28, 2 August 2019 (UTC)
I look forward to WMF enabling zombie cookies! Winged Blades of Godric (talk) 12:11, 2 August 2019 (UTC)
• @MER-C: where can I voice my opposition to this wrecking privacy-above-all initiative? Many Wikimedia sites—such as en.Wikipedia and Commons—are already cluttered with dumb sock puppeteers; CheckUsers’ backlog is clogged due to scores of puppets produced by various morons handy enough to register multiple accounts. If, in addition, every random person had his/her IP range concealed, then the ruin would come to anti-vandal, anti-copyvio, and anti-pushing job. Does any mean exist yet to counteract this vandal-friendly infiltration into the Wikimedia government? Incnis Mrsi (talk) 11:55, 2 August 2019 (UTC)
• You just did so. But I suspect that the outcome of this "consultation" is predetermined, and to stop it will require escalation to Board/Jimbo level (again). MER-C (talk) 12:15, 2 August 2019 (UTC)
I am committed to oppose and expect to see instructions by MER-C. Thanks a lot for early comments, by the way. Incnis Mrsi (talk) 12:37, 2 August 2019 (UTC)
To prove this isn’t a rant by yet another incompetent wiki user: I caught seven socks of the LTA Pakistanpedia, with my naked hands and IP-range tips. Two (previously unnoticed) copyvio files were deleted from Commons consequently. And it’s certainly not my unique achievement. Incnis Mrsi (talk) 14:21, 2 August 2019 (UTC)
• Hey WMF, we're not close at all to get rid of abuse, so you don't need to help abusers *so much*, leaving us fighting bots by hand is already enough! --Vituzzu (talk) 14:23, 2 August 2019 (UTC)
• I have to agree that this would be a huge detriment to attempts to deal with abuse. The only exception would be if the IP address information was still available to experienced editors, which would mean the whole thing would become a bit pointless. I have generally supported the right of unregistered editors to edit but I think if making IP addresses accessible really is unacceptable then a better solution would be to require registration. Hut 8.5 19:04, 2 August 2019 (UTC)
• If you want to hide IP's from edit histories because of privacy concerns then make it a requirement to register an account. I don't even want to think about how easy it would be for vandals to vandalize if this is going to be happen. WMF should try alone to fight against vandals for few weeks and then make that kind of proposals again. Stryn (talk) 04:48, 3 August 2019 (UTC)
• Very Strongly Oppose – For many, many reasons, including those listed at the top of this section and others brought up by other users above. As an experienced anti-vandalism user, I can personally attest that these changes will make fighting vandalism/abuse, much more difficult, especially when dealing with experienced LTAs/trolls. Anyone determined enough could easily find loopholes - in fact, vandals and LTAs will have much more options to vandalize and harass others while the anti-vandalism work of most other non-admin users would be effectively crippled. Any small benefits from these changes would be vastly outweighed by the downsides to this ill-conceived plan. If you want to be "anonymous" (not reveal your public info), you should sign up for an account, simple as that. The WMF has already screwed up badly on the execution of Fram's "partial Foundation Ban" (regardless of the merits); we do not need to see another WMF screw-up after the last public relations disaster. On the same topic, I also oppose making registration mandatory. We already have plenty of measures in place for dealing with IP/new account vandalism, and if someone wants to abuse one of the projects using their IPs, then they can suffer the consequences. Per , I would also like to hear the opinions of other experienced anti-vandalism users and admins. Also, I think that it would be very beneficial if we keep all of our discussions in one thread. LightandDark2000 🌀 (talk) 18:15, 3 August 2019 (UTC)
• What is not clear from this research is why it is necessary to do this in the first place. It couldn't be easier to create an account. Those that have a privacy or security issue are surely doing this already. So what is the great evil that is coming about from exposing IP addresses? What is badly needed much more than hiding IPs is some defence against problem editors who avoid scrutiny with dynamic IPs on mobile devices. We need a statement of the problem that is being fixed before discussing the fixes. SpinningSpark 21:54, 4 August 2019 (UTC)
My understanding, from the first sentence of the page in question, is that the world is becoming more conscious. </s> Killiondude (talk) 05:06, 5 August 2019 (UTC)
• Agree with MER-C. Benjamin (talk) 05:03, 5 August 2019 (UTC)
• Yes, my first instinct was to think of how en:Church of Scientology editing on Wikipedia and en:United States Congressional staff edits to Wikipedia would have resolved (or not resolved) very differently had the general proposed changes here been in effect at those moments in time. I don't know how we can resolve what the WMF wants and how the WMF wikis are actually fighting vandalism and COI edits and so on. Killiondude (talk) 05:06, 5 August 2019 (UTC)
• I also oppose in agreement with MER-C. Keeping track of IPs helps us spot COI and subtle vandalism, and gives us more tools for dealing with it. Obscuring it would be a boon to vandals and abusers. For the sake of irony, I submit "my" contributions on EN-WP as evidence. 168.244.4.53 02:59, 7 August 2019 (UTC)
• Agree with MER-C. If someone is worried about their privacy, they should create an account. It is really that simple! There is no problem to solve here. jni (talk) 05:20, 7 August 2019 (UTC)
• actually the "w:CongressEdits." twitterbot was no deterrent, but rather was weaponized to broadcast personal information about senators , resulting in some jail time for a staffer. and was shut down at twitter. apparently your deterrence theory will need another example. Slowking4 (talk) 01:45, 9 August 2019 (UTC)
• Strong oppose. This is absolutely non-sense you should not waste any resources on this. Don't fix it if there is nothing to fix. --2001:999:82:9855:DC90:883A:206A:2 14:47, 21 August 2019 (UTC)
• Just for the record, yes, I would overall prefer the status quo and that the Foundation simply do nothing in this regard. If users are concerned about their privacy, then there is an easy currently-existing solution: register an account. For that matter, if they wish, they could register a new account consisting of entirely gibberish for each editing session, and then throw it away when they're done. There's nothing AFAIK in any local or global policies preventing them from doing so, so long as they're making productive contributions. The process takes a few seconds and doesn't even require an email address. I don't see that as an onerous burden for those concerned about privacy.
All in all, this seems like a lot of discussion about how to solve all these various problems when the easiest solutions seems to be not creating all these problem that need solving in the first place. GMGtalk 15:19, 21 August 2019 (UTC)
• Please, do not hide IPs from registered users, because the hiding will make much harder war against vandalism. Раммон (talk) 08:40, 22 August 2019 (UTC)
• Agree with MER-C. The current system is already good, why should we change it? Veracious (talk) 16:10, 23 August 2019 (UTC)
• Oppose per all good points made by MER-C and Cullen328. Public IP is a handy and speedy tool for non-CU regulars in terms of sock investigations, COI, trolling, threats, harassment, etc. and we already encourage to create an account for those who don't want a publicly open IP. This is a solution in search of a problem where modern privacy trend is stretched beyond necessity. Brandmeister (talk) 20:40, 25 August 2019 (UTC)
• Strong oppose per MER-C. Millennium bug (talk) 03:03, 27 August 2019 (UTC)
• Strongly discourage per my above comment in this same thread. PaleoNeonate (talk) 04:04, 27 August 2019 (UTC)
• Strong oppose per MER-C, Vituzzu, Stryn and also in view of the comments from Rschen7754, billinghurst and Dirk Beetstra in #Petition to WMF. --Udo T. (talk) 11:17, 27 August 2019 (UTC)
• No bueno, bad idea -Indy beetle (talk) 03:45, 28 August 2019 (UTC)
• Seems a pharisian idea from a deeply buried thinker who has no idea of real-life process of the simple contributor or administrator. In the age of VPN (living inside the Great Firewall, I use it every day), the clever vandal has everything to continue. Concealing the IP will remove information needed to deal with the naïve vandal (or erratic beginner). --Wuyouyuan (talk) 07:47, 29 August 2019 (UTC)

## Petition to WMF

The below editors intend to resign all sysop and higher rights if this proposal is implemented as written.

1. Rschen7754 (talk · contribs) (English Wikipedia/Wikidata administrator, former steward) - I deeply believe in privacy, having been the victim of harassment on other sites. And I think that there is some room for masking the IPs of editors where government censorship is an issue (though a lot of spam comes from Chinese IP addresses, so that might be tricky). But this proposal will very quickly decrease our ability to deal with basic vandalism and spam by taking away the ability to handle rangeblocks, open proxy checks, VPS checks, blacklist checks, etc. Seeing how the WMF rolls out things like Visual Editor, and Flow (where you could not even block editors from making Flow posts in code deployed to production), and how poorly infrastructure like WMF Labs is run, I have little faith that these so-called tools will help us. And if we really care about privacy, we should think about the cross-wiki abusive editors who will post the residential addresses of users from many mobile IPs, and who will not be able to be blocked if this proposal is enacted. If administrators and some specific global groups were given the ability to see these IPs, I could be convinced to support, but without these assurances, I cannot - and I would find the tools not of much use and would resign. Rschen7754 00:31, 26 August 2019 (UTC)
I will add: this proposal shows the severe disconnect between WMF and the base of the volunteers who do the heavy lifting of keeping the site running. It and the Fram debacle are very discouraging as it is. --Rschen7754 00:34, 26 August 2019 (UTC)
Some damn fine points here.

Plus with WMF wikis having spambots flooding the system, as IP addresses and creating accounts to spam, and they don't show the inclination to fix those issues, and then to take away some of the few defences that exist, it is quite dispiriting to see this sort of proposal. If IP edits are a problem, then maybe it is time to remove IP edits and force accounts. (Noting that I am not threatening to resign my rights, but if you make it harder to stop spam, definitely won't be helping further in that space.)  — billinghurst sDrewth 02:07, 26 August 2019 (UTC)

What does it even mean to be "implemented as written"? There's no description of something to implement in the current text, either in the form of architecture/design or technical specifications. Nemo 07:53, 26 August 2019 (UTC)
At the end of the day I don't know how you do rangeblocks if you don't have the raw IPs. Not to mention that the history of IP editing before and after this changeover will be fragmented (and that detail is clearly specified in what is written). --Rschen7754 18:26, 26 August 2019 (UTC)
The new model. Software design by resignation ;) —TheDJ (talkcontribs) 13:16, 26 August 2019 (UTC)
It is indeed sad that it has come to this. I am a software engineer, and in my software engineering course important principles were listening to the customer and getting feedback, and implementing it. WMF has done a poor job of this on Flow, on VisualEditor, on MediaViewer (and there's certain things on Wikidata that they didn't listen to feedback on, either). Sometimes, I wonder why I still care about this project. --Rschen7754 18:26, 26 August 2019 (UTC)
I must agree that I would have supported a petition to push WMF to finally resolve old issues with the software (including working on material that is seriously outdated) instead of working on the implementation of new things with questionable use. I am sure that this is going to be written and implemented, and then the big wikis will !vote against it being enabled leaving the use to some small wikis (and through that seriously hampering any crosswiki antivandalism work). Point is that the petition would likely gather some votes, but there is no way to 'enforce' the outcome anyway (see this indication of how much success that would have).. --Dirk Beetstra T C (en: U, T) 14:01, 26 August 2019 (UTC)
Obviously this didn't get the response that I was hoping for, whether it be because it was one of almost a hundred threads and nobody saw it, or because nobody felt that strongly about the matter. Truth be told, if WMF does a crummy job with this I will still resign all my rights and leave the site - out of disgust. But I'm striking this because I don't want to box myself into a course of action for something that won't happen until 2020 or 2021, and because in the meantime I do want to at least feel some motivation to make this site a better place, with the little time that I have (read: if nobody's going to join me, it is probably better to retain the tools until WMF actually does something). --Rschen7754 05:42, 6 September 2019 (UTC)

I am not sure how good of an idea this is. Many editors with elevated permissions have already fallen on their swords over the Fram affair, but has the Wikimedia Foundation's actions relating to Fram and other cases not shown that that is exactly what the WMF wants: their volunteers (editors) to be just a free workforce without any influence? Thus this petition could actually be counterproductive. Notrium (talk) 12:27, 19 September 2019 (UTC)

## testing the change with JS/CSS ?

Hi,

so I did relay the news to the french wikipedia, but while we discussed that, I wondered if it wouldn't be worthwhile to start by giving a way to people to test the change without doing too much work. For example, someone could develop a quick js extension that do mask the IP address on history, and block some URL (like whois, etc), and then volunteers could use the extension for 1 week and report how this did impact their work, and so be forced for a 1 week to use existing tools, record what is missing the most, how much time did they had to ask to someone to look a IP for them, etc. This seems to be a good way to get data on what people use without starting to do lots of development, and lots of tiring discussion. Then once the tools are working well enough, then someone can start working on the change. That seems like a win-win situation. --Misc (talk) 17:20, 27 August 2019 (UTC)

Sounds like an interesting idea, but it would be pretty easy to bypass. Computer Fizz (talk) 15:08, 28 August 2019 (UTC)
Being easy to bypass is not the problem, the whole idea is to test on volunteers so they can tell what was impacted. If people intend to bypass it, they can as well not volunteer to test it. --Misc (talk) 14:06, 28 September 2019 (UTC)

## Threat actors

I'm not a cybersecurity expert myself, but from what I've read they seem to be fond of asking "who is the adversary that you're trying to defend against"?

So, who would be misusing IP addresses, that we should hide them?

1. An oppressive state where Wikipedia is one of many sites banned for the potential to spread wrong-think amongst the populace. All internet traffic is channelled through state-owned conduits where it is inspected and/or blocked. People there who do manage to get to WP would already be using VPN or some other circumvention that would put their IP address somewhere else. The state is probably able to track them down regardless of whether that IP address is shown or hidden on WP.
2. A theoretical oppressive state that doesn't have a Great Firewall or TLS interception, but does access ISPs' records (logs and customer lists) and/or compels citizens to use a mandatory propaganda app on their phones every day (which also tracks the device's location and matches citizen ID to IP address). They could maybe correlate an edit to a real person or a group of suspects based on timestamp (depending on the size of the population and volume of traffic), but having the IP address would make their effort a hell of a lot easier.
3. Another state that compels ISPs to hand over their customer records and IP addresses, but not traffic logs. They can now match the Wikipedia edits to real people via the publicised IP addresses en masse.
4. A government bureaucratic or "law-enforcement" body gets a court order for the ISP to reveal the customer records for specific IPs involved with a particular set of edits. Having the IP addresses up front allows them to filter out people who are outside their jurisdiction and focus on those who they can prosecute. This could be used for preventing terrorist or insurgent actions, or for persecuting those who embarrass the powerful.
5. A company that does TLS inspection of its employees' web traffic by deploying a trusted root certificate on their computers would be able to report on what pages those users are visiting. They don't need the IP address that's listed on WP, and that would be a common NAT address or the addresses of the security provider anyway.
6. A company that doesn't do TLS interception would only see the time and the destination IP that could identified as a WMF server, but not the specific page. The source IP on WP would be a NAT address: it could confirm that the edit came from the company but wouldn't identify the user. It could be a handy means for the company to identify all edits that were made from their infrastructure: just look at the contribs for that IP-user. Matching to a real person would require correlating timestamps.
7. Journalists or activists who report on edits coming from political party offices and government offices as a matter of public interest. How dare they?!
8. Anybody with a website can collect IP address from their own logs, match them with their user records (if they have a user sign-in function), and also match them with Wikipedia edits.

The last point above is alarming. Can you imagine a Cambridge Analytica style actor who got more-than-reasonable access on a major social platform and crossmatched that data to the open wikipedia history?

I take special note of Johan's comments above at 19:33, 5 August 2019 (UTC). Especially There's a rather large difference in capabilities ... It matters if we make something easy, or slightly more difficult. I find it reassuring that we have someone involved who has experience in the area he mentioned. But also we must be mindful of the possibility that Dave Braunschweig raised: people infiltrating the wiki community and gaining direct access to the information this project is trying to hide.

Pelagic (talk) 05:34, 31 August 2019 (UTC)

If the threshold is autoconfirmed to access this information, there is really no point having a barrier at all. MER-C (talk) 20:03, 31 August 2019 (UTC)
I tend to agree — there really is no point to having a barrier. Unless the new tools work better than I believe possible, "extended confirm" seems the maximum restriction that would allow the Wikis to operate. I suspect, although it is difficult to prove, that more IPs perform anti-vandal edits (using existing anti-vandal tools) than are vandals. — Arthur Rubin T C (en: U, T) 01:30, 1 September 2019 (UTC)

I think my answer here would probably be: I would have had not much resistance against this proposal, if WMF would have seriously increased (and/or kept up with) the capabilities to combat undesired behaviour on-wiki. Our tools are crude, our tools are outdated. Sockpuppets have free reign until someone notices something and checkusers them (I have a sockpuppet that I can recognize, but seen that they have enormous ranges of IPs to their disposal, it is 'dweilen met de kraan open' (mopping with an open tap); the edit filter, the spam blacklist, the blocking tool are heavily outdated. There is a community wishlist but I have no confidence that significant time is being put in that (and that has been publicly stated). I understand the problem of saving your edit as an IP, but as it currently stands I cannot support this proposal as our other tools cannot keep up with this. As usual, the approach is top-down, not bottom up. --Dirk Beetstra T C (en: U, T) 07:10, 1 September 2019 (UTC)

Dirk Beetstra: Reasonable. Just making sure: you are aware we are not proposing to do this without actually addressing the tools first? /Johan (WMF) (talk) 09:56, 9 September 2019 (UTC)
That sounds great!!! But overhauling some of these tools is going to take a significant amount of time (one of them has basically waiting to be overhauled for >10 years ..) .. and it would have made the choices here much easier. I am worried to shoot down this project at this time because it is 5 years too soon.... Maybe it is a good idea to start off with those projects then ASAP? --Dirk Beetstra T C (en: U, T) 10:26, 9 September 2019 (UTC)
<crickets>? --Dirk Beetstra T C (en: U, T) 12:51, 25 September 2019 (UTC)
Dirk Beetstra: Sorry, yes, agreed with everything you were saying to the point that I forgot I should reply, too. /Johan (WMF) (talk) 13:51, 25 September 2019 (UTC)
so can you share with us a timeline on the overhaul of a.o. the spam blacklist extension, the abusefilter, capabilities within checkuser capabilities (though this may give opportunities ..), .... ?? --Dirk Beetstra T C (en: U, T) 11:42, 26 September 2019 (UTC)
To start with, to make sure we don't wait for too long before we start doing anything, mw:Anti-Harassment Tools plans to do some checkuser tools work soon. NKohli (WMF) is better suited to comment on the details. (: We don't have a general timeline for all work, since we're still talking to people and collecting information. /Johan (WMF) (talk) 12:02, 26 September 2019 (UTC)
can you please update us here? --Dirk Beetstra T C (en: U, T) 12:59, 9 October 2019 (UTC)
@Beetstra: I posted an update below about kicking off work on making improvements to CheckUser. It would be hard to predict timeline of any sort, given that it is a fairly old extension and we have not yet looked into the codebase or even have a complete idea of the things we want to do (ongoing feedback). Rest assured that we will not be rolling out IP masking without the appropriate tools being in place first. -- NKohli (WMF) (talk) 15:20, 9 October 2019 (UTC)
Basically, that means that we likely have to shut down this proposal for years, CU is not the only thing that needs an overhaul (and months of testing) ... or is this going to mean that the 10 year old bugs get shifted away for another amount of time, frustrating your editors. —Dirk Beetstra T C (en: U, T) 16:38, 9 October 2019 (UTC)
@Beetstra: We were aware that this is a multi-year project when we launched the project page. The idea is to start a conversation and get information from our communities about the various ways IP addresses are being used on our projects. CheckUser is the first of several tools we will be working on improving or building as part of this project. -- NKohli (WMF) (talk) 05:16, 10 October 2019 (UTC)
Thank you for your answers. As I said elsewhere, I would have much less resistance against this if such developments were clearly on its way. I am afraid that you now build up resistance against this proposal and will have to re-discuss this somewhere in the future again - to me this discussion is just (sorry) completely useless at this moment as we do not know how the other tools will progress and even if they ever will be ready for this. --Dirk Beetstra T C (en: U, T) 06:21, 10 October 2019 (UTC)
Dirk Beetstra: Having a lot of people list what they see as they main problems, among all the known and unknown ones, has been very helpful for us, though. We're using the feedback we're getting in planning future development, and this is different from simply diving into old Phab tasks. /Johan (WMF) (talk) 10:33, 10 October 2019 (UTC)
{{rto|Johan (WMF)]] Point is though, those old phab tickets are there. Simply diving into them and rank them shows you already what people have problems with (and you can add the community wishlist to that). I am going to bet that a significant fraction of the people who have problem with their IP being on display are those who come here 'in bad faith'. Of course a spammer wants their IP to be invisible because then they can be related to their origin. Of course a sock is not going to simply run around on a /24 of IPs, we will just block the range. If, e.g. your spam-blacklist, Captcha and other spam-fighting capabilities would be up to par (and not >10 year outdated) quite a number of editors who have a problem with their IP being on display would not even be here. If your CheckUser extension would be up to par with current technology (and not years outdated) quite a number of editors who don't want to show their IP would not be complaining. --Dirk Beetstra T C (en: U, T) 10:51, 10 October 2019 (UTC)

## How is this going to affect people editing from Shared IP addresses?

Take for example the corporate proxy for Advance Auto Parts, seen here. There's a mixed bag of good edits and stupidity, probably from employees at stores all over the United States connecting through one IP address at corporate. Would all of these edits go through the same unique identifier? Currently we have templates like Shared IP corp and Shared IP edu to remind people not to bite the head off of newbies from these IPs over things that other people have done from the same IP (not that anyone on English Wikipedia pays any attention to that; the edu one has become more of a "block this IP longer" tag to admins), what happens when we have no way of knowing what the IP belongs to? Thinking about it, it might be a good thing for admins to no longer know when editors are coming from K-12 schools, both for the contributor's privacy and for Wikimedia's sake to eliminate bias, but will the editing community know to apply common sense that these unique identifiers might represent thousands of people rather than just one person? As a side note to those unfamiliar with me (which is probably most because I'm nothing special), I'm not in high school anymore; the user name comes from my alma mater where I was over ten years ago when I became part of the Wikimedia community. PCHS-NJROTC (talk) 13:35, 9 September 2019 (UTC)

We are thinking about having a way to surface information about the underlying IP (such as location, organization/school etc) without exposing the IP address. That will provide better privacy to unregistered editors than we have right now. We are still thinking about how this would be implemented and what information will be surfaced and how. Thanks for your question! -- NKohli (WMF) (talk) 23:49, 11 September 2019 (UTC)
With all due respect, what is even the point of this if you're just going to tell people what school someone is editing from? That would actually reduce privacy by making it easier for people with less technical knowledge to know where our editors work, go to school, etc, because people who have absolutely no knowledge of IP addresses or how to run a WHOIS query would then be able to see "Anonymous User from Charlotte County Public Schools" (for example) wrote something on Wikipedia, making it even easier for our contributors to be doxxed or harassed for their actions. I mean, imagine the scenario where a middle school student contributes negative but factual and well referenced information on the article of a large corporation and some company exec who knows little about computers suddenly sees that and pays someone to identify that kid and "make him pay" for it. That's already theoretically a possibility with IPs being exposed, and we already make it easier for that to happen by tagging schools with Shared IP edu, but we don't need to make it even easier by having our editors' schools, workplaces, or geographic locations appear in the edit history like that. I don't like this idea at all. PCHS-NJROTC (talk) 13:40, 12 September 2019 (UTC)
We will probably not be exposing the name of the school but rather make it clear that it is a school and provide some sense of location. Please do keep in mind that these are just ideas at the moment and depending on what is feasible from a technical point of view might change things. We are also probably not going to be recording the school/workplace/location identifiers in the edit history but rather have a way for users to be able to see that if they need to. It doesn't take a lot of technical skill to do a whois, with the huge number of tools available on the internet now. You could put in an IP address in a search engine and it will give you a lot of information. There are a lot of things still to be figured out. But trust me, we are not going to make it easier for users to be harassed. Thank you. -- NKohli (WMF) (talk) 22:25, 16 September 2019 (UTC)
If you are going to do this, I think you should seize the opportunity to eliminate an on-going bias at least on the English Wikipedia by NOT identifying the anonymous users as being schools. I hate to be blunt, but I have backed off of participating in recent changes patrol because of the outright stupidity I would observe from other vandal patrolmen/women when dealing with shared IPs, including schools and places that are not schools like big corporations and federal government agencies. The philosophy of an open project where anyone can contribute to human knowledge would benefit if admins were not able to identify educational institutions (or places they incorrectly think are educational institutions) and block them with the bias that educational institutions including universities are nothing but a source of vandalism. Thoughts? PCHS-NJROTC (talk) 01:17, 24 September 2019 (UTC)

## Working Group wants IP masking for everyone but Checkusers, few suggestions how, little consideration of issues and no communication

The Community Health working group has raised the same suggestions - Proposals can be found here. The IP-Masking proposal is number 3 under Q1 (the others don't apply to this).

This is their 2nd set of proposals - they completely failed to communicate with us the first time, putting them well behind NKohli, and it's a far worse set of ideas with little on how they'd do it.

I'd really rather we go there to state the concerns, and I'd appreciate NKohli contacting them more directly to point out the huge number of legitimate issues raised, and why even limiting it to Admins, let alone CUs (as they wish) wouldn't work. Nosebagbear (talk) 13:46, 22 September 2019 (UTC)

Pinging as I forgot to actually do so above. Also pinging as this would be another group to reach out to. Nosebagbear (talk) 18:07, 22 September 2019 (UTC)
Thanks for pointing this out to me! I had not seen the working group recommendations. I will reach out to them and sync up on the idea. I'm not sure they are aware of this project proposal either. -- NKohli (WMF) (talk) 21:04, 25 September 2019 (UTC)
They said "Admin", but I don't recall signing a non-disclosure agreement as an en.Wikipedia admin, so they meant "Checkuser". — Arthur Rubin T C (en: U, T) 20:51, 22 September 2019 (UTC)
-- Any comments? Shall we expect any kind of communication from your fellow WG members; I am yet to see anyone other than you and a couple of others across all WGs who have even minimally engaged. Winged Blades of Godric (talk) 11:26, 25 September 2019 (UTC)
User:Winged Blades of Godric you will need to use my username for the ping to work :-) Just seeing this now. With respect to masking IPs, IMO all admins and maybe another new group (so that this can be given to non admins) should be able to see it. We will simple need a simple way for people to agree to the NDAs. Doc James (talk · contribs · email) 06:36, 18 October 2019 (UTC)

## Redact the IP addresses if it's an issue

I feel like this is a solution in search of a problem; I don't think unregistered users are particularly worried about their IP addresses being public information, or else they would have said something in the past 17 years or so we haven't redacted IP addresses. If it isn't, however, might I suggest we go back to the old UseModWiki/Phase II days where IP addresses were redacted, like Users 216.7.146.xxx or 24.120.22.xxx; the full IP addresses could be left to CheckUsers.

Or just use the phrase "Anonymous Coward." (Or bring back domain names from the UseMod era. :P) John M Wolfson (talk) 20:33, 25 September 2019 (UTC)

So this isn't an issue for say someone editing English Wikipedia from the US, but if someone edits a specific subject in Nynorsk Norwegian from a redacted IP address that indicates they're probably living in Estonia, the addition of the geographical information coming from even part of the IP address could be enough to identify them personally, yet as a patroller I don't get the specific identification that a masked ID that's as unique as the IP would give. What would the benefits be of doing this instead – am I missing something? /Johan (WMF) (talk) 08:45, 26 September 2019 (UTC)
I don't quite know how IPv4 addresses work, but I'm sure that having the last chunk of it redacted will prevent it from narrowing down a specific individual. (Also, I'm not sure if Geolocation services work with only a partial IP.) As said above, however, I don't think this is that big a deal. John M Wolfson (talk) 03:41, 27 September 2019 (UTC)

## Very Good potential

If the alternatives are implemented I think the system will work much more efficiently. I hope things as I understand them have the following potential functionality

1. CU's could be made publicly between registered and unregistered users, since no personal information will be revealed. A lot of disruption can be handled better this way IMO.
2. If the generated usernames are more persistent than dynamic IPs, a lot of silly & "unprofessional" vandalism won't happen. "Professionals" will always find the way around.
3. If a computer based username is generated, school or institutional vandalism won't prevent constructive edits from the same IP. It would be nice for this usernames to have a pattern e.g. XXXXXXX PC-YYYY
4. Bias against IP edits will decline
5. IPv6 is more confusing to the human eye than a readable autocreated username, and much harder to unassisted patern recognition, provided that the autocreating username system will assing some kind of ISP patterns.
6. A faster global contributions tool (as fast as CentralAuth)

I think it's worth a try. —Ah3kal (talk) 02:30, 26 September 2019 (UTC)

@Ah3kal: Your comment makes sense, however, I fail to see how the masked IP info will help us in finding socks, if sock_1 is editing from masked_IP_1 and sock_2 is editing from masked_IP_2 then only the real underlying IPs will show that they are in close IP proximity (say within a /24), which is still invisible. The only positive match may be if sock_2 happens to use masked_IP_1 which we then recognize as maybe being the same editor (just purely based on that info).
But spam coming from masked_IP_1, masked_IP_2, and masked_IP_3 now would make me block the three masks, whereas if I now that the three underlying IPs would be totally unrelated (as now would be possible) I would just plainly blacklist the spam (no need to block 3 complete ranges to stop the spammer). However, if I know that it is just IPs in a /24 spamming, I might consider to just block the range. --Dirk Beetstra T C (en: U, T) 11:52, 26 September 2019 (UTC)
Beetstra It is very much possible to build a tool that tells you if the accounts are editing from a close-range. In fact we could even make it easy to find accounts that are editing from close proximity (IP wise) to a given account. These are things that could be handled by the computer without users having to worry about the IPs and knowing what IPs mean and how they work to understand which ranges to block. -- NKohli (WMF) (talk) 22:25, 4 October 2019 (UTC)
such tools should have been available for years already. I would even go as far as saying that if WMF would have taken up those problems and have properly connected with what the editing community actually needs we would not have ended up with this totally absurd proposal. WMF is approaching things from the wrong side. (I thought I was commenting on Talk:Office actions/Community consultation on partial and temporary office actions/09 2019‎). You would have gathered much, much more support for this idea if that type of problems were finally solved before suggesting this. —Dirk Beetstra T C (en: U, T) 06:12, 5 October 2019 (UTC)
There are several quite promising ways to identify socks, but it is pretty hard to get anything done because it is an uphill battle against users that fear any form of changes. We can do network timing analysis, we can do route analysis, we can fingerprint the source, we can fingerprint the targets, we can do timing analysis on the edits, and probably a whole bunch of methods I don't know about. And not to forget, the most obvious one, starting to use verified accounts. — Jeblad 11:30, 9 October 2019 (UTC)
To me, something as simple as a AbuseFilter from which only the CheckUsers can see the results that besides the on-wiki fingerprint filters also has capability to check IP ranges that the user is using, and similar data that CheckUSers can see would be great. I even don't know if the CheckUser extension has received a major upgrade over the last 10 years, or that it has been neglected like some other extensions. --Dirk Beetstra T C (en: U, T) 11:58, 9 October 2019 (UTC)
It hasn't seen a lot of development (but we're working on that right now). /Johan (WMF) (talk) 12:00, 9 October 2019 (UTC)
mw:Anti-Harassment Tools?? What about the 10 year old bugs? --Dirk Beetstra T C (en: U, T) 12:42, 9 October 2019 (UTC)
We're looking at generally working on these tools, not just some CU improvements. But as mentioned above, we don't have a plan for exactly what yet, so we've just picked one place to start in order to not let development lie untouched while we figure out the needs and workflows across various wikis. This is not a short project that'll be done by the end of the year. /Johan (WMF) (talk) 13:22, 9 October 2019 (UTC)
Also, we don't want to be secretly working towards a goal without telling people what we're aiming at. /Johan (WMF) (talk) 10:47, 10 October 2019 (UTC)

Basically we want to have a persistent ID associated with a single individual / entity. IP addresses do this poorly as they change / are so easy to change. If this proposal results in a more persistent link between IDs and individuals than we may be better off than we are currently from a vandalism point of view. Doc James (talk · contribs · email) 04:24, 22 October 2019 (UTC)

## Update: October 4, 2019

Hello! Thank you everyone for your continued engagement and feedback on this page. I’m here to present an update on this project.

### CheckUser improvements

As mentioned previously, our foremost goal is to improve our existing anti-vandalism tools and to that effect, the Anti-Harassment Tools team will be kicking off work on making (long-overdue) improvements to CheckUser extension. We have been conducting a series of user interviews with Checkusers and stewards to understand their workflows with the tool at present. Based on that research, we have come up with an initial list of proposed improvements we can make to remove some of the biggest pain points. I welcome you to visit the project page and provide your feedback on the talk page.

### Research about usefulness of IP edits

As promised in my last update, we have gathered some data about how many IP edits our projects received over the last year and how many of those were reverted, revdeleted or the IP address was subsequently blocked. The compiled data can be found on the Research page.

We have not seen any major trends in the data except for the fact that majority of IP edits are kept on the wikis and are not reverted or revdeleted. That does not, however, tell us anything about the quality of the content contributed by IP editors. Qualitatively measuring the content contribution is a much bigger task and we are not sure if there is a good way to do it, besides manually looking at incoming IP edits.

Since we don’t yet have an accurate picture of what will happen if IP edits are disabled on a wiki, we are willing to run an experiment to see what the effects of doing a small, targeted intervention to could be. This doesn’t necessarily have to exclude all IP edits. We could selectively prohibit IP edits to certain namespace(s) and see what the effects are. We would like to hear your thoughts about this and if you are interested, we are looking for a small wiki to collaborate with for this experiment.

I will also take this opportunity to thank Benjamin Mako Hill and his team of researchers for putting together a page to showcase the prior research done on this topic. It has been very informative.

Lastly, I’m sorry if we have missed responding to a question raised on this talk page - there is a lot of discussion and sometimes things slip through the cracks. Thank you. -- NKohli (WMF) (talk) 22:36, 4 October 2019 (UTC)

Experimenting around what sort of effect limiting IP editing would have would be useful. With browsers like Chrome remembering all your passwords, registration is less of a barrier than it used to be.
Having a pop up appear after one hits "publish", when they are not logged in to inform them about this would be a good initial measure. This will likely decrease editing by IPs aswell... Doc James (talk · contribs · email) 06:21, 18 October 2019 (UTC)
- I get distinctly concerned at making life awkward for a large subset of our editors in order to encourage them to sign up. It would however cover aspect 1 of your comment well. Perhaps have it once per session, with a session ID to remember it until they closed the tab? Nosebagbear (talk) 18:14, 22 October 2019 (UTC)
Yes could be decreased to once per session... Doc James (talk · contribs · email) 09:06, 25 October 2019 (UTC)

I am always wondering whether it really would be so different. Yes, an editor under IP is now a very good editor, they would also be a very good editor if they were editing logged in. Would really all of those long-term IP editors walk away if they have to make an account? I doubt it, but yes, a few would. But that is also true for editors who already take the situation serious and make an account. Many IPs make a throwaway account and make good edits and are never seen again. You will only lose the few editors who REALLY insist that they do not want to make an account and want to edit as an IP. I really wonder if Facebook would ever worry about the fact that there are editors who do not want to make an account but want to post as an IP. I don't buy the 'but we have also IPs who do not vandalise' argument .. --Dirk Beetstra T C (en: U, T) 10:01, 25 October 2019 (UTC)

This is completely anecdotal, of course, but to give an example of what one could be afraid of: as my normal, volunteer self, I edited almost exclusively as an IP user for four years before I started logging in. The reason I became a Wikimedian is that the barrier to entry was so low that I could help out without any investment – until I became invested, and started using the account I had registered a few years earlier. I would not have become invested if IP editing had not been an option, because I wouldn't have bothered. It wasn't important for me to fix the things I fixed, it was easy. If we look at the long-term IP editors, we might be focusing too late in the chain of events, because the harm we could cause is to the people who aren't yet invested but could become because editing is easy. /Johan (WMF) (talk) 02:57, 1 November 2019 (UTC)
yes, as we know one reason wikipedia prevailed over other online encyclopedia projects was that it had the lowest barriers to entry. Almost Wikipedia: What Eight Collaborative Encyclopedia Projects Reveal About Mechanisms of Collective Action to the extent you continue to raise barriers to entry, you will contribute to editor plateau, and impact the growth of quality content. "would those admins really leave if we banned one, or took away ip surveillance? i doubt it, but a few would." Slowking4 (talk) 15:34, 4 November 2019 (UTC)

Research on the value of IP Editing currently says "A major theme of community responses to that proposal are suggestions to disallow contributions from users without accounts". That is either a serious misunderstanding or mispresentation of the community response here. There is a longstanding community consensus supporting editing by users without accounts. While there is of course some dissent from that consensus, it is (or it was) an effectively dead issue.

The theme of community responses is opposed to masked editing, and that the community can and almost certainly will block masked editing. NKohli (WMF), or anyone else on this project, do you disagree with my assessment of the community response? Can I get a more meaningful update? Does the Foundation still a plan to build a system to mask IPs, given that masked-edits will almost certainly not be allowed? Does the Foundation still intend to work towards terminating IP-editing (converting it into masked-edits), given that Foundation would be terminating the existing ability of those users to edit without making an account? Alsee (talk) 18:23, 8 November 2019 (UTC)

@Alsee: Regarding the issue of disallowing edits from unregistered users - that is something that has come up on this talk page quite a few times and the purpose of that research page was to gather some data to get everyone on the same page about how unregistered users contribute to the projects. We have no intention of terminating the ability of our users to edit without an account if the community does not want that.
As for this project, we are grateful for all replies we are receiving on this and related project pages. We are not making any assessments or decisions yet. We have barely had time to gather ideas since Wikimania. Our team plans to work on improving anti-vandalism tooling over the next few months and we are kicking off this work by making improvements to Checkuser and meanwhile plan our next projects. There are lots of things we don't know yet and hence I can't comment on those. Thanks for your understanding. -- NKohli (WMF) (talk) 05:15, 12 November 2019 (UTC)
@Alsee: I read the entire discussion and do not feel that the sentence was a misrepresentation. Blocking IP editing is a description of one theme that was raised. The section "Simpler solution - turn off IP editing" is one example but the idea is discussed positively in many other sections as well. It's not the only response, and probably not even the most important one, but it is one major theme of community responses to the proposal. More importantly, NKohli (WMF) is considering this option very seriously. I agree with you completely that this suggestion goes against a long-standing community consensus and the outcomes of many discussions over many years. I also think a large body of evidence suggests that consensus is empirically justified. —mako 20:37, 14 November 2019 (UTC)
Benjamin Mako Hill I stand by my comment, you misunderstood the community response. For example in the section you cited, Simpler solution - turn off IP editing, the author of the section says in their second comment that they believe the Foundation will not permit retaining-IP-editing as an option. The author opened that section explicitly to present an argument between two options (1) building masking vs (2) not building masking. More specifically, they argue that not-building-masking would be would be simpler and cheaper and less disruptive than building masking.
The discussion on this page is in response to the masking proposal. To the extent this page contains any debate of pros and cons of contributions-without-an-account independent of masking, it's an irrelevant distraction. That topic is old and thoroughly resolved. That topic has a tombstone is English Wikipedia's Perennial proposals graveyard for zombie topics. The Perennial proposal page exists specifically for topics that we consider a waste of time to discuss anymore. Community consensus is approximately 2-to-1 in favor of contributions-without-an-account. That consensus has been clear and stable for years. That consensus is expected to remain clear and stable... unless the Foundation does something like trying to push masked editing. The Perennial proposal page well summarizes the result of (excessive) past discussion of the topic:
A large portion of our good edits come from IP addresses;[1][2] positive experiences with initial IP edits lead users to create accounts who otherwise would not do so; software features disabling IPs from creating new articles or editing semiprotected ones are sufficient. According to Jimbo Wales, "what is commonly called 'anonymous' editing is not particularly anonymous ... and there are good reasons to want vandals on IP numbers instead of accounts". While about 97% of vandalism comes from anonymous users, about 76% or 82% of anonymous edits are intended to improve the encyclopedia. (Prohibiting IP edits would not eliminate 97% of all vandalism, because those inclined to vandalize could easily take the 10 seconds to register.) The ability of anyone to edit articles without registering is a Foundation issue.

Alsee (talk) 22:22, 15 November 2019 (UTC)
Benjamin Mako Hill to clarify, I'm saying it is not a major theme. I am saying it's not even a significant theme. I'm saying it's a tangential and irrelevant topic. NKohli (WMF), I am saying that you are making a mistake taking this topic seriously. I'm saying that producing Research on the value of IP Editing was not relevant or helpful to the discussion on this page. The fact that the report was produced and presented here is a warning sign that the team is misunderstanding/mishandling community engagement on this project.
There have been very good improvement in communication and engagement between the Foundation and the community recently. However that improvement is absent from this page. The team here has been either been non-responsive or evasive to too many community questions. There are too many warning signs that this project is repeating the mistakes of past failed projects. Alsee (talk) 00:10, 16 November 2019 (UTC)

## December 6, 2019

Hey everyone – this is mainly to tell you we're not ignoring things here. Thanks a lot for all the feedback. While we're working on the checkuser tools, we're also considering all the discussions we've had here (and elsewhere). In a couple of weeks we're moving into the holiday season for most people at the Foundation; we'll be back properly in January with more thoughts. /Johan (WMF) (talk) 07:06, 6 December 2019 (UTC)