Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

IP Editing: Privacy Enhancement and Abuse Mitigation/header

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.

Feedback on tools

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

Feedback on persistence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Archiving

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

Communication plans

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

Well...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Third Party MediaWiki installs.

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

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

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

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

Range information

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

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

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

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

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

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

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

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

Crypto-PAn

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

Treat all users on a /64 as one

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

Make separate user right for "unmasking" IPs

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

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

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

Who can access the IP of an unregistered editor?

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

An idea could be to create three tiers.

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

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