Talk:Trust and Safety Product/IP Info/Archive1

What is not available at this stage? And Communication Issues

Can I check whether this is an intermediate step which is "let's make it easier, and provide some consistency, by providing information about IP addresses", but which won't (of itself) hide any information?

That is, a non-admin can still use the IP to look up the address (to the degree currently possible), but won't have the information readily given to them? Or is it a non-intermediate step and the IP address will become hidden?

@PSaxena (WMF): I realise you're not the comms lead for the team, but this desparately needed to be further spread - it only just now got put onto the discussion page on IP masking project, and that's the most linked page. I've not seen any mention on broader meta pages, let alone the larger community tech pages Nosebagbear (talk) 00:31, 19 May 2021 (UTC)

@Nosebagbear: Your first interpretation is correct - this is an intermediate step. No IPs will be hidden. Sorry for not spreading this more widely. We are actually talking about this project currently on some other wikis (like wikidata and wikivoyage). I admit fault for not notifying about this on the main IP masking page. I will rectify this in the coming week. This project is very much under development and your opinion is welcome. -- NKohli (WMF) (talk) 20:24, 23 May 2021 (UTC)

Stack of questions from a frequent proxy blocker

Lots of questions and thoughts here.

• What source or sources are being looked at for the "might be a proxy" determination? Speaking as one of the active folks at enwiki's WikiProject on Open Proxies, the reliability of different proxy-checking tools/websites varies quite widely. We haven't had any official support (that I know of) in the proxy-hunting department, so I'm very interested to hear what your plan is and how it compares to what we're doing day-to-day. You've said Since this project will be Foundation-maintained, it will probably be much more reliable than some websites our users are dependent on currently. - that does not comfort me. To be blunt, history suggests that a Foundation-maintained project will be delivered half-complete and then left unmaintained while the developers move on to the next shiny project.
• "Source IP is a colo" would be another useful indicator - colos and other hosting arrangements aren't proxies, strictly speaking, but they're still useful to hide one's origins. A bit of scope creep to add a field for each aspect of interest, so might be worth just having a list of "interesting properties" like colo, open proxy, tor, etc.
• Right now, we take a fairly proactive approach to VPNs and other anonymizing tools, including a couple of bots to hunt them (w:en:User:ST47Bot reports some, and w:en:User:Procseebot blocks some) fairly wide blocks of known webhost/colo ranges (both softblocks and hardblocks, depending on factors like "are there a lot of VPNs/proxies in their range" and "how sketchy does the colo provider seem"), that sort of thing. How will that work under this new model?
• Being able to see the activity on a range is a very important tool, both for admins and non-admins - lets us see how much collateral damage a block would do, how often people seem to change IPs, that kind of thing. The proposed feature (and the IP privacy enhancement in general) is focused on individual IPs, which doesn't help much on dynamic ranges.
• An idea of static-ness of an IP would be useful in determining how long to block for. See comments in the bullet above. I just noticed static/dynamic in the list of exposed data...not perfect (dynamic IPs can vary quite a bit in how "dynamic" they really are) but it's being considered at least.
• We are going to be consolidating IPv6 /64s into single anons...right? Please.
• Shameless plug: I actually wrote a tool with a few of these features a while ago. w:en:User:GeneralNotability/ip-ext-info. I use it routinely, so adding this kind of information, even without anonymizing IPs, would be quite useful.

GeneralNotability (talk) 00:49, 19 May 2021 (UTC)

More generally: adding this as a normal feature to Mediawiki would be quite useful. It will not, however, solve all of the problems introduced by the IP-hiding proposal. GeneralNotability (talk) 00:54, 19 May 2021 (UTC)

I mostly concur with the General here; some additional notes from my side:

• It's pretty hard to parse this proposal because it's interwoven with IP masking. If masking wasn't a thing, it would be easier to comment on it (and I wouldn't have many demands)–but since it seems like the output of this tool will be the only thing that 99% of Wikipedia users ever see about an IP, it will have to get a lot of things right.
• I want to point to my comment about proxy blocks and collateral in task T265845, which may be relevant to implementing this (no details here per w:en:WP:BEANS). A red/yellow/green light system (which I'm largely opposed to -- proxy checking requires lots of interpretation; the more condensed the data becomes, the more useless it is for me) would have to be based on APIs that differentiate between different types of proxies and implement Wikipedia-specific heuristics to prevent people from blocking everything that isn't in "the west" based solely on an API result.
• Range information is crucial when making IP blocks in an anti-abuse context. For the majority of ISPs in the world, a single-IP block won't stop any determined abuser for long. Information about (ASN-)CIDR ranges would be very handy to have on-hand to track and block abusers on dynamic IPs (when IP masking comes, this would likely have to be restricted to those with access to unmasked IPs). Both the ASN CIDR and the underlying wider ranges (if applicable) should be displayed in this case–in many cases, the ASN CIDR does not accurately reflect the ranges people are actually floating around on.
• This seems to be mostly looking at things from an antivandalism perspective, but in my experience as someone who used to do lots of antivandalism patrolling and now handles 90+ percent of ACC's proxycheck queue and a good chunk of incoming w:en:WP:WPOP reports, I can tell you that I never really looked at a WHOIS output when doing antivandalism patrolling, nor do I know many patrollers who do. Many people who hit the rollback button dozens of times each day don't know what a /64 is. The people who would probably be relying on this tool the most are checkusers, SPI clerks, admins who make lots of rangeblocks and proxy checkers. Consider actively seeking these groups out and consulting with them–these are the people who will feel the impact of IP masking (and it will be very substantial) the most, and who will benefit the most from these added features. Best, Blablubbs|talk 18:54, 21 May 2021 (UTC)

@Blablubbs I will encourage you to look at this proposal independent of IP Masking. It is not intended as the one solution to all the problems. We will be building more tools to address more of the challenges that come with IP Masking.

• Our thinking behind condensing the data in the tool was to make it more easily understandable for people who are not really tech-savvy or don't completely understand the nitty-gritties of IPs (Spur seems to do something similar for the public IP check). I see your point about needing more detailed information and it is probably a common use case for most power users. We can possibly make an "Advanced" mode for the tool for users who need more information and expose everything we can about the IP.
• About ASN CIDR - noted. Will see if we can incorporate that.
• That's a good point. We have put it through a few rounds of user testing with admins and checkusers from different language communities which has helped us shape this. As we make more progress, we will invite more people to look over this and provide feedback.

Thank you for your replies, both here and on T265845. -- NKohli (WMF) (talk) 14:22, 26 May 2021 (UTC)

@GeneralNotability I am sorry about your experience with Foundation-maintained products. I admit fault for being involved in some of those in the past. Sometimes when teams move on from projects, it is not really up for them to decide what they will be working on. I am hopeful that IP Info won't meet a similar fate. This project is getting the attention it deserves from the WMF. I'll respond to your specific points below:

• We discovered the same thing about variance in data from different IP information sites. Our long-term plan is to use multiple paid services to show a range of information. For the first iteration of the tool we are going to use the paid version of MaxMind. We picked MaxMind as it seemed to be a reliable service that is also used by other teams in the WMF. I will be happy to hear if you have suggestions about which other sites do you find most reliable when you look into this data? So far I've heard about Spur being liked by some community members. Also trying to look for services that reliably cover diverse geographical areas. Translation is probably too good to hope for.
• About "colo" - I have not seen this pop-up in any IP services I have used. Is it covered under a different label?
• Regarding proactively blocking VPNs and other anonymizing tools -- there is a lot of potential for internalizing that functionality within MediaWiki with the advent of IP Info. When we get to a stage where we can rely on IP Info data - we can use that data to flag or auto-block potential bad actors. This could show up in RecentChanges/Log/History pages. This could even potentially tap into the Notification system to alert admins.
• Yeah, I am not quite sure yet how we could enhance this feature to work well for IP ranges. We are not planning to take away IPs completely from admins and patrollers who rely heavily on IPs on a day-to-day basis. So most people who require this information will not lose out on the ability to track IP ranges. I will make a new update on the IP Masking project page to post our plan in the near future.
• For static verus dynamic: We get a variance % from MaxMind. We are planning to expose that better. A new mockup will be coming forth soon.
• "We are going to be consolidating IPv6 /64s into single anons...right?" <--- This sounds to me like something we would need a community RfC on. Do you think most people would share this request? We could probably do this technically but I will have to consult with people who know more about code than I do.
• This is great! We have been searching high and low for scripts people have built. How do I see it in action? I installed it in my global.js but don't see the icon I am supposed to be seeing...

Thanks for all your feedback. It is really valuable. -- NKohli (WMF) (talk) 13:47, 26 May 2021 (UTC)

NKohli (WMF) Thanks for the response, and sorry for the delay in replying - I've been on vacation the past couple weeks.

• Colos might also be called colocation hosts, datacenters, en:VPS services, or (for some) webhosts. We generally use "colo" as a catchall term. It's a fairly wide range of services, but it boils down to somewhere that you either park your own server(s) or buy a share of someone else's servers, and as part of that the users are using the colocation host's IP block. We usually softblock them (and I believe we have bots that block them automatically), since there are some legitimate uses of those services. However, some are sketchier than others, and some of them are absolutely crawling with VPN endpoints - those get the hardblock treatment.
• I'm all for working on automatic blocking of proxies, but emphasize Blablubbs's comment above about how the dynamic-ness (and proxy-infested-ness) varies based on ISP and part of the world. If we autoblock everything showing as a possible proxy, Indonesia's going to end up permanently blocked. This is something that will need some thinking.
• For IPv6: yes, treating a /64 as a single IP is fairly standard practice. See, for example, enwiki's advice at en:WP:/64. There are two main reasons for this. First, /64 is the minimum IPv6 range assignment (I have seen a few cases where it looks like an ISP is assigning smaller ranges within a /64, but that's exceedingly rare, and WHOIS always says the assigned block is a /64). My understanding is that the average (western, at least) ISP delegates a /64 per residential customer, avoiding any need for NAT. Second, blocking individual IPv6 ISPs almost never sticks, since computers routinely shuffle the latter half of their IP address (part of IPv6 privacy extensions, see en:IPv6#Stateless_address_autoconfiguration_(SLAAC) and en:IPv6_address#Temporary_addresses for the gory technical details). Basically: IPs are assigned randomly within the /64, they can change every $amount_of_time and/or every time the computer connects to a new network, and you don't even have to reset your router to grab a new IP. If a /64 is not considered as a unit, it is both near-impossible to assess the editor's contributions over time and trivially easy to grab a new IP to get around the block (and there's effectively zero chance that they'll be back on the first blocked IP, given that we're talking about 2^64 possible IPs).
• First rule of demos: tell someone "go try my new tool" and it breaks. It wasn't checking links to Special:Contributions, which is what shows up in history views, that should now work - if you look at IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/IP_Info_feature's history, you now should see a little globe icon next to the IP address who made the random comment last month.

GeneralNotability (talk) 20:35, 6 June 2021 (UTC)

Re /64s: My experience is the same as GN's. I've been told that some ("western") providers apparently do shared /64s in some regions, but they still function as /64s (similar to a shared IPv4). Some providers, often Asian mobile networks, don't seem to do /64s at all (or people hop across them so quickly that it doesn't matter), but even in those cases, bundling will generate zero collateral because the address space is so vast and the /64 is so tiny in comparison to the underlying ranges (think /32 and larger). I would consider this a purely technical matter, not something that needs community consultation. Blablubbs|talk 20:51, 6 June 2021 (UTC)

It depends largely on the project whether proxies are blocked or not. Yes, I am aware that LTA's use proxies extensively. I also know that the polish wikipedia does autoblock proxies by a bot. This should be an config option.--Snævar (talk) 12:37, 7 June 2021 (UTC)

Good proxies

The IP Info tool should distinguish between different types of proxies, and allow suitably trusted users to classify them.

Wikimedia projects rely on IP blocks to constrain or at least slow down disruption from unregistered and logged-out users. So it's understandable that there are policies and countermeasures against services which make it easier for people to hop to alternate IP addresses.

But not all "proxies" allow IP hopping or have user anonymization as their primary goal. Some will responsibly set the X-Forwarded-For header to show where the user is really coming from. And, if I'm at work and accessing the web through a corporate-sanctioned, 3rd party security service, I can't easily turn that off or route myself through a different one of their datacentres.

It's increasingly common to use cloud-based security providers for protection against malware and phishing (plus they may offer additional security and performance services like CASB and global peering). This is often part of a defense-in-depth approach of browser plugin + endpoint agent + DNS filtering + content filtering on firewall + external security proxy. But for some devices, like iPads, you can't install a plugin or agent, and your only choice is an edge or external filter. Services that provide full TLS inspection include Broadcom (Symantec / BlueCoat) and Netskope. (If you're reading this and know of others, please comment below.)

If I'm behind my employer's NAT with 400 other people, is that different from my employer being behind a provider with 100's of other companies? Either way, I can't easily IP-hop. The difference is scale and the amount of collateral damage from a rangeblock. For more info, please have a look at User talk:Thsdb#Block of Netskope worldwide IP range (request for local unblock on Meta, granted) and Steward requests/Global#Global unblock for 163.116.128.0/17 (request for global unblock, on hold). I would like to see Movement policy and attitudes evolve to recognize how different providers have different characteristics, and not all are block-worthy, but that won't happen if the tools lump everything into a single VPN/proxy/Tor=yes judgement.

You'll never stop playing whack-a-mole with anonymizing services like Nord and Express – their purpose is to move around and avoid blocklists. (Even Mozilla foundation is promoting Mozilla VPN from Mullvad.) But the security services often have well-documented address ranges, e.g. [1].

Mediawiki users, both Wikimedia projects and other stakeholders, need to be able to classify and list known-good ranges in addition to known-bad ones. It's often easier to learn the former than to chase the latter.

// thsdb [formerly ThscDrb] (talk) 02:54, 29 May 2021 (UTC)

User:NKohli (WMF), it's encouraging to see at Phab:T269760 that MaxMind might return an "isLegitimateProxy" value. I wonder about MediaWiki installations that can't or won't use Maxmind. // thsdb [formerly ThscDrb] (talk) 06:15, 2 June 2021 (UTC)

@Thsdb We're writing the code in such a way that MaxMind can be interchanged for a different service, if desired. But that would change the data that is returned, as expected. NKohli (WMF) (talk) 12:05, 7 June 2021 (UTC)

Admin/Checkuser just to see organization/location information is excessive

This information is crucial for public transparency efforts detecting when organizations are editing. Projects such as CongressEdits can only work because they know the rough location/organization that an originating IP edited from. Restricting it to admins/checkusers would mean that public interest journalism on this topic would be dead - a very serious detrimental tradeoff! 69.172.145.94 21:22, 18 June 2021 (UTC)

Hi there. I agree about your point for increasing public transparency but I am sure you agree with me that such transparency should not come at the cost of loss of privacy. You probably know this better than me, but CongressEdits has been marred with controversies and the bot has been suspended by Twitter due to violation of policies.

We can build tools to do what CongressEdits did but do so in a way that does not expose IP addresses to lots of people. We can look into opening up access to the data to more people as we see interest and need for that information. Thanks for your comment. -- NKohli (WMF) (talk) 00:42, 25 June 2021 (UTC)

Niharika, I'm very interested by the latter, and would like to see that, with regard to "such transparency should not come at the cost of loss of privacy", I'm not sure I can agree as it rests. Neither of us, I believe, would say "sacrifice all transparency for all privacy; or sacrifice all privacy for absolute transparency". Democracy dies in darkness on the former, and the latter brings the issues that the later releases of Wikileaks caused.

However, this is neither of those - IP Masking as a whole, and thus the specifics within it, fall into the messy gray ground in the middle. IP information is one of the most broadly shared pieces of information in the modern world - we give it to every site we visit. Wikipedia is unusual in the breadth of its spread, but also in the breadth of transparency we provide...and need. In a way, it is the moral obligation we gladly accept as the price for becoming the one-stop shop for information for so much of the world. The need for transparency rises in line with the cost of its absence - the reason it's so critical for politicians applies to us as we grow.

Though Legal didn't deign to participate in this critical debate on the broader topic is itself a blow to the nature of Wikimedia, but that doesn't mean it should be viewed as an either/or settled matter in the execution nuances Nosebagbear (talk) 16:35, 25 June 2021 (UTC)

A Ping

Hello Nosebagbear, GeneralNotability, Blablubbs, Snævar,and Thsdb there's an update you might want to check out. –– STei (WMF) (talk) 14:33, 1 April 2022 (UTC)

Join the IP Info Feature testing, request testwiki admin access here

We have an update about IP Info Feature. And if you are considering testing it, please leave your username below to be given Admin access. Please keep this page on your watchlist. Once you are granted access, a checkmark will be added beside your username below. Please use the tools responsibly even though this is a test. Thank you! –– STei (WMF) (talk) 13:23, 1 April 2022 (UTC)

• --Blablubbs (talk) 15:04, 1 April 2022 (UTC)  Done
• -- JavaHurricane 15:09, 1 April 2022 (UTC)  Done
• --Johannnes89 (talk) 16:28, 1 April 2022 (UTC)  Done
• --Gardini (talk) 16:45, 1 April 2022 (UTC)  Done
• --Der-Wir-Ing ("DWI") talk 16:45, 1 April 2022 (UTC)  Done
• XenonX3 (talk) 16:54, 1 April 2022 (UTC)  Done
• --Holder (talk) 04:45, 2 April 2022 (UTC)  Done
• --Ameisenigel (talk) 18:37, 3 April 2022 (UTC)  Done
• --MarioGom (talk) 09:13, 4 April 2022 (UTC)  Done
• --Wnme (talk) 20:28, 10 April 2022 (UTC)  Done
• --Stang 23:47, 10 April 2022 (UTC)  Done
• --FanyustBuddyruh (talk) 08:00, 11 April 2022 (UTC)

  @FanyustBuddyruhI can't find your username on test.wikipedia.org –– STei (WMF) (talk) 09:28, 11 April 2022 (UTC)

  @STei (WMF) I wouldn't grant this account access as I'm certain this is a sockpuppet. See centralauth [2] and also this account [3], both having no global edits except from requesting test wiki admin access. Johannnes89 (talk) 10:51, 11 April 2022 (UTC)

  Yeah, please grant access to established community members only Sakretsu (炸裂) 12:58, 11 April 2022 (UTC)

  Thank you @Johannnes89 and @Sakretsu. I usually run the participant list by Trust & Safety first, but thanks for this addition as well. –– STei (WMF) (talk) 18:09, 12 April 2022 (UTC)

• --Tiger (talk) 16:07, 12 April 2022 (UTC)  Done
• --Udo T. (talk) 19:08, 12 April 2022 (UTC)  Done
• ~~~~
  User:1234qwer1234qwer4 (talk) 22:48, 19 April 2022 (UTC)  Done
• --SCP-2000 09:48, 13 May 2022 (UTC)
• EpicPupper (talk) 04:19, 1 June 2022 (UTC)
• Zippybonzo (talk) 16:48, 1 June 2022 (UTC)
• --Itcouldbepossible (talk) 05:09, 3 June 2022 (UTC)

Do you have any comments or questions about our April 1, 2022 updates?

Please share them below. –– STei (WMF) (talk) 13:37, 1 April 2022 (UTC)

Vandalism only

Hi @STei (WMF):

I'm not on test-wiki actually utilising the tool, so I won't use the testing feedback bit above. Mine is a specific concern on the documentation and, more critically, the obligation imposed on users:

It states users must agree that "this information is being accessed for anti-vandalism purposes only". Now, I'm highly confident it's not intended, but while preventing vandalism is a use of this information, it's hardly the only use. En-wiki's interpretation is fairly common and functionally included in the UCOC (assuming it's ratified) has it that vandalism is wilful damage to the project, usually its content. This data is also used in anti-harassment efforts, but also in non-vandalism counter-sock efforts. Most counter-sock efforts are on individuals who are either vandalising or harassing (frequently both), but there are socks who aren't wilfully harming the project, although may well be doing so.

These are legitimate uses, and thus the scope of permitted uses needs to be broadened. Nosebagbear (talk) 13:43, 1 April 2022 (UTC)

Thanks for the feedback! –– STei (WMF) (talk) 17:59, 7 April 2022 (UTC)

@Nosebagbear thanks for the comment. I'll note that the language as it stands currently is coming from Legal as they are overseeing the contracts with Maxmind and deciding what we need to do based on our agreed terms with them. I will raise this for their consideration.

Also, looking forward to hearing your review of the tool when you get a chance to use it. We are targeting a mid-May deployment to all projects if we don't run into any catastrophic bugs. NKohli (WMF) (talk) 08:05, 20 April 2022 (UTC)

Cheers for following up! - yes, I'll definitely give it a go once it's in broader availability (test-wiki doesn't have many IP editors) and feedback. Nosebagbear (talk) 09:51, 20 April 2022 (UTC)

Questions

1. How, and under what criteria, does the WMF consider imposing or recommending user access levels to the tool? Or will this be left up to the individual projects?
2. Nowadays with most IP addresses being dynamic (especially mobile connections), and the huge use of VPNs, the IP information is nowadays largely inaccurate. What can be said about about the usefulness of this tool in practical terms?
3. How will this impact on the growing interest on some projects to simply ban IP editing altogether? (Portuguese Wiki has already done so).

Kudpung (talk) 02:07, 16 May 2022 (UTC)

Hi @Kudpung. Thank you for your questions.

We currently have an access restriction in place which was informed by our conversations with Legal and Trust & Safety. In general, our goal was to ensure that we do not risk the privacy of an editor by exposing (potentially) sensitive information to users who a) may not need to see it anyway and b) may not be trusted with that information. I realize that the norms vary widely by wikis. If a community wants to lower or increase this restriction, we can discuss the reasons for that and change it accordingly. I hope this clarifies our intention.

I agree that we will not be able to guarantee high data quality at all times. Our goal is to integrate in multiple data feeds to be able to show a more complete picture. This is similar to what patrollers do at the moment. We are talking to Spur and will hopefully be able to obtain their data feed soon. But to address your broader question -- IPs are becoming more dynamic. We are seeing more VPN services come up and more companies are talking about launching native features to protect IPs and user agents (Apple iCloud Relay, Google One VPN etc). It is expected that we will see reduced usefulness from any IP-related tools (including checkuser) as time goes by. Your question is also pertinent to the ongoing conversation about proxy blocks.

Projects that choose to turn off unregistered editing will probably not benefit from this tool in its current state. If we expose this information in the checkuser tool that would be more beneficial for those projects. We will like to improve the data quality before we do that. NKohli (WMF) (talk) 02:18, 26 May 2022 (UTC)

NKohli (WMF), Thank you so much for your detailed reply. On En-Wiki, access and use of the CU is highly restricted and regulated. Many of the reasons to view IP addresses will no longer be available to other special rights users (admins, and patrollers of vandalism, AfC, NPP, SPI, COI, UPE, etc.) who are not CU functionaries. Will this mean that a new, special user group will need to be created locally to view IP addresses? If so, what user experience would be required, and what measures would be available to preven users requesting such a right for the sole purpose of gaming the system? Kudpung (talk) 03:21, 26 May 2022 (UTC)

@Kudpung I think you are talking about IP Masking and not IP Info anymore, correct? If so, we addressed part of your question in the 10 June 2021 update on the IP Masking page. We are suggesting that admins should have the right to view IP addresses (alongside checkusers) by default as we know it is essential many times for admins to view IP addresses and block them, as appropriate. For patrollers, we suggest a new group/right that can be given to trusted patrollers, as defined by the community norms. We are suggesting a lightweight community-driven process for giving these rights to users who meet some minimum criteria of account tenure and number of edits. Advanced users in the community could also have the right to take away this privilege from anyone they think may be misusing their access to IPs. In addition, WMF T&S staff would also be responsible for handling cases of violation. I would love to hear your thoughts on this proposed idea. Thanks for bringing up important questions, as always. Appreciate it. -- NKohli (WMF) (talk) 00:44, 27 May 2022 (UTC)

@NKohli (WMF), I am. That is correct, but the two are inseparably entwined. I am asking, because as the creator in 2016 of the New Page Patroller user right, and the spearhead of the successful ACTRIAL policicy, we have since discovered that a number of users have had to have their rights revoked because they were using them for promotional purposes or editing for pay, or creating spam or paid articles as an IP user then accepting them at AfC or NPP etc. With 750+ holders of the New Page Patroller right, it may not be easy to single out who can be trusted. Its something I will have to look into when we have seen what the effect of IP masking will be. I just need to be prepared for what we are going to propose to the local en-Wiki community. So thanks again for your excellent and most helpful reply. Kudpung (talk) 01:13, 27 May 2022 (UTC)

@NKohli (WMF) I'll just add that it can take up to at three months (or more) of formal discussion on en-Wiki to obtain a consensus for anything new, especially policy, and the more important it is such as the creation of a new user right, it can take a lot longer. Kudpung (talk) 01:27, 27 May 2022 (UTC)

Can't open

Hi. I'm an admin, for a long time, in testwiki. I've opened user contributions for 91.67.252.214, and can't see any infobox or any link to activate the new feature. What should I do? Thanks. IKhitron (talk) 12:01, 25 May 2022 (UTC)

We say that we opened for all wikis but opening on enwiki there is no IP info feature. Thingofme (talk) 12:06, 25 May 2022 (UTC)

I do not understand your answer. I'm talking about testwiki only. IKhitron (talk) 12:21, 25 May 2022 (UTC)

@IKhitron @Thingofme have you both activated the beta feature under Preferences > Beta features tab? Once you do that, you should be able to access the new feature. Please tell me if that solves the issue. Thank you. -- NKohli (WMF) (talk) 01:50, 26 May 2022 (UTC)

This is the part that wasn't clear. Thanks, @NKohli (WMF). It works on testwiki, but in no other place. IKhitron (talk) 02:01, 26 May 2022 (UTC)

@IKhitron I see! To turn on the feature, you need to accept the terms of use for the feature. To do this, go to the Special:Contributions page for any IP address and then expand the "IP Information" infobox on the top of the page. Once you accept the terms of use, you will then activate the feature and will be able to access the popup that you were using on testwiki. Please let me know if this works! -- NKohli (WMF) (talk) 22:40, 26 May 2022 (UTC)

Well, @NKohli (WMF), I did it yesterday on testwiki. There is no infobox to expand on any other wiki. IKhitron (talk) 22:55, 26 May 2022 (UTC)

@IKhitron that sounds like a bug! is your account autoconfirmed on the other projects where you are trying to open the infobox? Did you also try this on meta? -- NKohli (WMF) (talk) 23:03, 26 May 2022 (UTC)

@NKohli (WMF), it's Interface Admin on one and Developer on another. I did now, same problem. IKhitron (talk) 23:15, 26 May 2022 (UTC)

I enabled the feature globally and despite being a sysop on testwiki I can't see anything either. NguoiDungKhongDinhDanh 23:18, 26 May 2022 (UTC)

Thanks @IKhitron and @NguoiDungKhongDinhDanh I will file a bug. I'm not sure what's happening. Thanks for your patience. NKohli (WMF) (talk) 00:02, 27 May 2022 (UTC)

@IKhitron and @NguoiDungKhongDinhDanh to confirm -- you have accepted the terms of use on the wiki you want to access IP Info and even after doing that, you are not able to see the infobox, correct? NKohli (WMF) (talk) 00:04, 27 May 2022 (UTC)

@NKohli (WMF): What do you mean by accept the terms of use? Is there a form or something? NguoiDungKhongDinhDanh 00:07, 27 May 2022 (UTC)

Not at all, @NKohli (WMF). I marked on Beta page, and have no infobox to accept the terms of use. IKhitron (talk) 00:08, 27 May 2022 (UTC)

@IKhitron and NguoiDungKhongDinhDanh: Yes. After you turn on the beta feature, you need to accept the terms of use the first time you want to use the feature on any wiki. This can be done by going to Special:Contributions for any IP address on that wiki. Attaching a screenshot to show this. You can also accept this from Preferences > User Profile > IP Information (right at the bottom). Can you try this and tell me if it works? --

NKohli (WMF) (talk) 00:13, 27 May 2022 (UTC)

@NKohli (WMF): I found those two checkboxes in my preferences, but nowhere else. Honestly, I think they are not really intuitive; viewing IP information has nothing to do with user profiles. Can they be appended somewhere else instead? NguoiDungKhongDinhDanh 00:23, 27 May 2022 (UTC)

Yes -- I think we can perhaps make them part of the popups when they are accessed for the first time. This is good feedback. Thank you for letting us know. -- NKohli (WMF) (talk) 00:25, 27 May 2022 (UTC)

@IKhitron @NguoiDungKhongDinhDanh @Thingofme I have filed a bug here: https://phabricator.wikimedia.org/T309365 please take a look. If you can add a screenshot or comment to confirm whether I have captured the problem correctly, that would be helpful. Thanks. -- NKohli (WMF) (talk) 00:30, 27 May 2022 (UTC)

Well, it works now, thanks. And me either can find the form in Preferences only, not on user contribution pages. IKhitron (talk) 02:01, 27 May 2022 (UTC)

Now it works too no problem, but I have to confirm it in every single wiki (you have autoconfirmed). (some large wiki I don't have autoconfirmed due to requires edits) Thingofme (talk) 08:49, 27 May 2022 (UTC)

Interface messages

• MediaWiki:Ipinfo-widget-error-ip-no-edits

  Currently: "IP information for this address cannot be retrieved since it hasn't made any edits on this wiki.

  Proposed: IP information for this address cannot be retrieved since no edits have been made from it.

  Rationale: According to MediaWiki:Action-ipinfo et. al. IP addresses are considered attach[ments] to revisions and log entries, not identifiers by themselves. Also, per en:WP:IPHUMAN.

• MediaWiki:Ipinfo-property-no-data:

  Currently: "Not Available

  Proposed: Not available

• MediaWiki:Ipinfo-property-label-connectiontype:

  Currently: "Connection Method

  Proposed: Connection method

• MediaWiki:Ipinfo-property-label-usertype:

  Currently: "Connection Owner

  Proposed: Connection owner

• MediaWiki:Ipinfo-property-label-active-blocks:

  Currently: "Active Blocks

  Proposed: Active blocks

  Rationale (for both 4): Bad casing.

• MediaWiki:Ipinfo-infobox-disable-instructions:

  Currently: "If you'd like to disable this feature you can do so from [[Special:Preferences|Special:Preferences]].

  Proposed: If you'd like to disable this feature you can do so from [[{{#special:Preferences}}]].

• MediaWiki:Ipinfo-beta-feature-description:

  Currently: "[...] next to IP addresses on Log, Contributions and RecentChanges pages.

  Proposed: [...] next to IP addresses on {{PAGENAME:{{#special:Log}}}}, {{PAGENAME:{{#special:Contributions}}}} and {{PAGENAME:{{#special:RecentChanges}}}} pages.

  Rationale (for both): Interface messages are displayed in user language while that of special pages is site language.

NguoiDungKhongDinhDanh 03:37, 27 May 2022 (UTC)

Thanks @NguoiDungKhongDinhDanh. I have moved these suggestions along to the engineering team. -- NKohli (WMF) (talk) 18:17, 27 May 2022 (UTC)

Update: This is now tracked in https://phabricator.wikimedia.org/T310759 -- NKohli (WMF) (talk) 23:17, 15 June 2022 (UTC)

Translation

When will the IPinfo extension go into the Translatewiki.net for users to translate? Thingofme (talk) 08:48, 27 May 2022 (UTC)

@Thingofme: Xem translatewiki:Special:MessageGroupStats/ext-ipinfo. Bản dịch tiếng Việt đã có đầy đủ. NguoiDungKhongDinhDanh 09:12, 27 May 2022 (UTC)

But we will have to wait a week before the translation gone live. Thingofme (talk) 09:39, 27 May 2022 (UTC)

That matters not at this talk page. NguoiDungKhongDinhDanh 09:44, 27 May 2022 (UTC)

Remove popup second part for non-admins

Hi. I think the second part of popup, the info that is available for admins only, should be removed for the rest, to save space. IKhitron (talk) 13:13, 27 May 2022 (UTC)

Special:Log/ipinfo

Hi @STei (WMF) and NKohli (WMF): according to your status update (April 1st) Special:Log/ipinfo „is purely for Legal purposes. Only WMF Trust & Safety staff will have access to this log for the time being“.

Since implementing the IP info feature as a beta feature, Special:Log/ipinfo is accessible for all administrators & checkusers – is there a reason why? I'm not sure how I feel about being able to check which IP infos other users in my home wiki (deWP) looked at. -- Johannnes89 (talk) 14:34, 31 May 2022 (UTC)

Thank you for bringing this to our attention, we will get back to you. Have a great day. –– STei (WMF) (talk) 08:02, 1 June 2022 (UTC)

Thanks, other users raised similar concerns too [4] -- Johannnes89 (talk) 09:01, 2 June 2022 (UTC)

This log is definitely not acceptable. The logbook can be used for WMF T&S in my opinion, but other administrators can monitor users using this logbook. It is nobody's interest which IPs I control and when I am active.

The privacy of unregistered users must not be at the expense of the privacy of registered users. @STei (WMF) @NKohli (WMF): 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 12:18, 3 June 2022 (UTC)

I agree with WikiBayer. IMO WMF Legal team (and also T&S, Ombuds etc) and developers can view the log due to legal and maintenance reason. However, there is no reason of Admins and Checkusers viewing the log. At least, the log should only viewed by users who have signed NDA and have valid reason. At present, the permission of viewing log by Admins and Checkusers should be immediately revoked due to privacy concern. Thanks. SCP-2000 12:47, 3 June 2022 (UTC)

@SCP-2000 Why Checkusers? We've all signed the appropriate bits and are considered trusted by the WMF in a way normal Admins aren't. Doug Weller (talk) 15:23, 3 June 2022 (UTC)

@Doug Weller: You are right. Only the permission of Admins should be revoked at present. However, even Checkusers have signed NDA, there is no need to view IPinfo log. If there is an abuse of using IPinfo, it could be investigated by either Legal or Ombuds. If they want to test this tool, there are other places for testing. Thanks. SCP-2000 17:13, 3 June 2022 (UTC)

@SCP-2000|@Doug Weller: FYI, there's a task T309928 open in phab to remove this from sysops.

Frankly, as a checkuser, I can't see how that log would be useful to me anyways. I'd be fine with not having access to it. SQL^{Query me!} 20:10, 5 June 2022 (UTC)

@SQL yes, I don’t care either. Doug Weller (talk) 20:22, 5 June 2022 (UTC)

@Doug Weller It doesn't matter what you signed. No one should see this, because this is personal data.

As long as there is no evidence of abuse, no one should have that right.

This should be handled similarly to Wikimails.

Checkuser can have access, in my opinion when querying, the particular user, but not without reason. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 11:51, 4 June 2022 (UTC)

What's personal data in the log? kyykaarme (talk) 20:48, 6 June 2022 (UTC)

The IP Information tool guidelines (which the user has to "agree to") says,A log is kept of queries made using the IP Information tool and how the information was accessed. Access to this log is limited to Foundation staff and certain advanced user groups.That's pretty vague, but at least it mentions that the log is visible to some users. -kyykaarme (talk) 19:40, 3 June 2022 (UTC)

Some users (as mentioned) may be ok. Every admin and CU without reason - that should be avoided. Kein Einstein (talk) 12:49, 4 June 2022 (UTC)

@Kein Einstein @Kyykaarme @Doug Weller @SQL I am sorry for the mix-up. It seems like the log was mistakenly open to all sysops. The intention to limit it to checkusers for similar as for the checkuser-log -- so that these users can keep each other in check. I noticed Martin has revoked sysop access from the logs. Thank you and sorry everyone. I was away for a week and did not get a chance to follow up. -- NKohli (WMF) (talk) 06:37, 7 June 2022 (UTC)

What is the differences?

Is there any differences between this beta/upcoming feature and the existing GeoLocate feature which is located at the bottom of the Contribs page (which opens up to whatismyipaddress.com) other than IP Info being a built-in/stock feature. As the GeoLocate feature seems to provide more information which IP Info doesn't as it would displayed "Not Available" for ISP and ASN most of the time. Paper9oll (talk) 08:25, 2 June 2022 (UTC)

I think with the upcoming IP masking the GeoLocate feature might no longer be working the way it does now. -- Johannnes89 (talk) 08:59, 2 June 2022 (UTC)

So it seems like GeoLocate would eventually be replaced by IP Info in the near future because of IP masking making it useless I guess. In the IP masking page, it seems to be pointing to two proposals of retaining IP-based identity and also a new session-based identity (if I interpret the logic correctly, they are saying that it's non-registered accounts with randomly generated username) which if they're retaining IP-based identity then this IP Info feature would remain available isn't it, then about the session-based identity, would this IP Info be useless against that? Paper9oll (talk) 15:23, 2 June 2022 (UTC)

If I'm not mistaken they already decided for the session based approach. In the future Special:Contributions would show this randomly generated username, that's why GeoLocate cannot show information.

But the IP of these randomly generated usernames will still be available (at least to admins) and of course the IP info tool will have access to the IP as well. @STei (WMF): please correct me if I'm wrong :) -- Johannnes89 (talk) 07:51, 3 June 2022 (UTC)

Correct if I'm wrong, so in the future, the IP Info feature would only be useful to admins and possibly ECP with checkuser role, while those without neither of those roles like me, the feature would be useless is it? Wonder if the session-based identity would make fighting vandalism/disruptive editing users (and also the annoying sock evasion users) harder, which my thoughts currently say yes it would certainly be, as with IP since they are unregistered, if they jump around their IP, range block is easier to curb them, while for session-based identity, I really have no idea how that would really work, maybe similar to registered user approach by judging on their edit interactions, behaviors, etc, but for non-admins and user without checkuser role, I guess reporting them would be harder since the session-based identity uses randomly generated username which makes them harder to link together if they are same person behind or at least an estimated guess if they are even which is possible with IP. Kind of sad, not sure when the session-based identity would rollout to English Wikipedia (which I edit mainly on), hopefully take their own sweet time lol. Paper9oll (talk) 08:53, 3 June 2022 (UTC)

The IP Info feature will show you the same information as it does now, which provides at least some insight even for users who cannot see the IP.

As far as I know, there will be a new user right to access the IP which can be given to non-admins active in fighting vandals, so I wouldn't worry too much.

Rangeblocks will still be available (as the IP is still available for admins) and of course still affect all non-registered users with IPs belonging to the range. Johannnes89 (talk) 09:07, 3 June 2022 (UTC)

Wait what, if I cannot see the IP address which means I would also not be able to see it in the article's revision history, watchlist, recent changes, signature, and other places where the IP address is currently displayed, hence how would IP Info feature be useful or linked to the IP in the perspective of non-admins since currently I can only see the location, connection method, connection owner, of which the useful information viewable for non-admins is location while the other useful information which is ISP is locked behind admin/checkuser roles as part of the ongoing privacy enhancements. Any clues if the new user right for non-admins to access the locked IP information such as the ISP, would be hard to obtain like what checkuser requirements currently are which are only issued to super small group of only 52 admins on English Wikipedia. And also, if the IP Info feature would function for the planned session-based identity?

As for rangeblocks, my understanding is that admins would still be able to continue their rangeblocking but non-admins (assuming they don't have the new user right) wouldn't be able to request which range to block since they don't know their IP when they are filing their reports such as on administrator's noticeboards, which basing on my personal long-time observation, admins would also be reluctant to rangeblock since normally they ask for what range I would like to request them to block which is kind of requirements when one is filing such reports and they will see if it's feasible on doing so or not. Paper9oll (talk) 12:40, 3 June 2022 (UTC)

If you don't have the user right to see the IP address, the IP info feature at least provides some insight into the nature of the IP behind the randomly generated username (e.g. if it's open proxy or the geolocation, which is more than we know about registered users).

Why should the IP info feature not be working in the future? The IP address is still there, it's just hidden from general view („IP masking“) so of course the tool has access to the database and can provide information about the IP behind the randomly generated username.

As I said, non-admins can request the new „IPViewer role“ which is going to be introduced, see Trust and Safety Product/Temporary Accounts#IP Masking and changes to workflows (9 December 2021), so it's still possible for non-admins to see the IP and calculate the IP-Range. Johannnes89 (talk) 13:25, 3 June 2022 (UTC)

Ok, now I understand what you're referring to. Apologies for the confusion as I was actually talking from the point of IP-based identity whereas you replied in the context of Session-based identity hence the confusion in my reply earlier. Anyway, in my personal opinion, the feature would only be useful regardless of IP-based identity or Session-based identity if user has IPViewer rights otherwise the capability of the feature would be non-useful as compared to the og GeoLocate (yes I know, GeoLocate would be replaced/removed eventually from Wikipedia) and imo if user doesn't has IPViewer rights, it would be a step back from the current tools, but at the same time, this depends on each user current workflow against how they're countering IP vandalism and whether they required IP (location, ISP) information for their analysis of guessing if they're the same person behind before they reports further which for me personally is yes. In short, I'm not very excited on this entire IP privacy enhancement, as I believe my current workflow against countering IP vandalism would be affected somehow. Paper9oll (talk) 13:46, 3 June 2022 (UTC)

@Paper9oll, @Johannnes89, apologies for the late response, I was out of office. But I see the issue raised has been well discussed. With IP Masking, because IPs are masked, the IP Info tool will be the approved reveal tool for masked IP addresses and access to IP Address information. –– STei (WMF) (talk) 11:36, 14 June 2022 (UTC)

Shows a blocked editor as having no blocks

When I look I see the standard red text saying blocked, plus the information I expect to see from the tool but it says "no active blocks". Doug Weller (talk) 08:37, 3 June 2022 (UTC)

@Doug Weller: Where did you see that? NguoiDungKhongDinhDanh 08:39, 3 June 2022 (UTC)

When I clicked on IP Informaton. Doug Weller (talk) 08:45, 3 June 2022 (UTC)

Which IP? -- Johannnes89 (talk) 09:08, 3 June 2022 (UTC)

@Johannnes89 sorry, I don't understand how that's relevant. But I do have a screenshot. Doug Weller (talk) 09:12, 3 June 2022 (UTC)

If you tell us we could check if we see it too. Sounds like a bug if there clearly is a block. Perhaps there is no specific block for this IP, but the red text shows the IP-range is blocked? Johannnes89 (talk) 09:16, 3 June 2022 (UTC)

@Johannnes89 ‎103.242.232.2 Doug Weller (talk) 09:37, 3 June 2022 (UTC)

perhaps it needed some time to update the IP info? When I access it at [5], it now says „1 active block.“ -- Johannnes89 (talk) 09:56, 3 June 2022 (UTC)

@Johannnes89 that must be it, it say9s that now when I look at it. Thanks. 10:12, 3 June 2022 (UTC) Doug Weller (talk) 10:12, 3 June 2022 (UTC)

"A log is kept of queries made using the IP Information tool and how the information was accessed."

Does this log include the editor viewing the information? Doug Weller (talk) 09:11, 3 June 2022 (UTC)

yes it does, see #Special:Log/ipinfo Johannnes89 (talk) 09:16, 3 June 2022 (UTC)

you should be able to access the log at en:Special:Log/ipinfo -- Johannnes89 (talk) 09:18, 3 June 2022 (UTC)

@Johannnes89 thanks. That makes sense and matches what we do with CU. Doug Weller (talk) 09:38, 3 June 2022 (UTC)

I'm fine with CU seeing this but I don't see a reason why I'm allowed to see these details about other user's IP info usage in my home wiki Johannnes89 (talk) 10:03, 3 June 2022 (UTC)

@Johannnes89 What else to you see about the IP that you couldn't find out anyway? Doug Weller (talk) 10:13, 3 June 2022 (UTC)

I'm not talking about the Info feature (which I like), I'm talking about the log. In deWP I can see which user activated the tool (at which time) and which user checked which IP addresses (at which time).

I don't see a reason why I (as a regular admin) should be able to see how other users are using this feature. -- Johannnes89 (talk) 10:33, 3 June 2022 (UTC)

@Johannnes89 Ah, I understand. This should be restricted to those of us who have CU. I can see recent CU checked because I have CU, but regular Admins can't. This seems to be basically the same situation. Doug Weller (talk) 11:43, 3 June 2022 (UTC)

Why would this be interesting for CUs? It doesnt even show when you check a user. Der-Wir-Ing ("DWI") talk 13:25, 4 June 2022 (UTC)

Based on the comments by the Beta testers, it looks as if this entire IP masking is going to significantly add to the workload of admins and/or CU authorised users and will seriously disrupt SPI and combating vandalism which rely on normal editors for filing cases and doing the research. Bear in mind also, that having followed most of these various discussions about IP masking since it was announced over two years ago, I still have not come across any explanation as to which country's legislation is calling for IP masking and when and if such a bill passed to Act of Congress or a National Assembly. All I have seen are comments from the WMF staff that it comes from the Foundation's 'Legal'. Maybe I missed something while I was on a break earlier this year. Kudpung (talk) 12:41, 3 June 2022 (UTC)

en:General Data Protection Regulation, there is no reason for personal data such as the IP to be visible to the general public.

If normal users active in fighting vandalism can get access to the IP as well, I don't see how IP masking might increase admin workload. Johannnes89 (talk) 13:11, 3 June 2022 (UTC)

see also Trust and Safety Product/Temporary Accounts#What is IP Masking and why is the Wikimedia Foundation masking IPs?. Johannnes89 (talk) 13:26, 3 June 2022 (UTC)

I mean, the session-backed methodology is the aspect that would do it to me - changing your cookie being even easier than changing your IP address. Nosebagbear (talk) 21:01, 6 June 2022 (UTC)

Email

In response to your email at [checkuser-l], I've sent you the feedback you requested to steiwm.o. (Just in case you got flooded with emails) — regards, Revi 17:38, 1 July 2022 (UTC)

(Leaving this placeholder {{YGM }} because they did not bother to respond for a while.) — regards, Revi 17:39, 1 July 2022 (UTC)

@-revi your feedback was collected. We are still gathering comments and an update on any improvements made in response to community concerns will be provided. If you have a question however, I am happy to get answers for you. –– STei (WMF) (talk) 10:18, 8 July 2022 (UTC)

Got it.

However, please note that... when you "ask for feedback" on checkuser-l (or for that matter, stewards-l as well), we expect a response from the staff member who requested feedback, even if that's just "OK, we took note of it". That's not how our private mailing lists are run, and doing such is below the conduct we expect from WMF. — regards, Revi 17:14, 19 July 2022 (UTC)

Adjacent IPs

One of the key tools that is currently being used for stopping vandals with dynamic IP addresses is viewing contributions across a range of IP addresses. It would be helpful if this tool could show info on adjacent IP addresses, such as being able to get the blocks and contributions within a /24 or /16 subnet (and this will be especially important once IP Masking rolls out). -- Ahecht (TALK
PAGE) 01:31, 12 July 2022 (UTC)

@Ahechtthank you for the feedback. ––– STei (WMF) (talk) 17:04, 12 July 2022 (UTC)

I approve this request.

It would be especially usefull to have a link towards the contributions of the subnet.

Thanks! Durifon (talk) 08:16, 26 September 2022 (UTC)

Questions 2

IP Info Infobox as of April 1, 2022

1. It is a little silly "Advanced Information" access is logged and made accessible only to certain users, when such information has already been readily available (for now) to patrollers via WHOIS (such as via WMF toollabs:whois/w/84.250.14.116/lookup, or whois 84.250.14.116 on GNU/Linux). No technical person has a better reason to request this "advanced information" (OSINT) or require permission to be proxied via WMF from the new IP Info, with all the negatives associated to go with it. The only practical new thing this new tool achieves is WMF's apparent desire to maintain a new database of access data and tell affected data subjects via access requests who has accessed their IP-address data – but why? The "Benefits and risks" analysis seems at best incomplete or non-convincing, with little consideration given how the tool aims to improve data protection by default, or what it has anything to do with it. (#What is the differences?) The better question is: When does WMF want to use this log information for their purposes, and when do the data subject's data protection interests override WMF's interests to process this data? In my opinion it shouldn't be collected if WMF has no use for it (even if data subjects have uses for it), and there are no effective uses for it unless the IP-masking project is implemented in its entirety (and CheckUsers are forced by agreement with WMF to use the tool in their SPI decisions). My interpretation is that this only holds CheckUsers more accountable (unless they avoid using the proxied new tool), while keeping the same information available in imbalance for non-CheckUsers. If WMF's goal was to improve data protection while being useful to CheckUsers / patrollers, then this new IP Info tool should only ever represent a reduced amount of information from WHOIS (with no access logging). Or am I just tone-deaf here? This talk page wouldn't have had a discussion about admins having access to the information, if it was done proper and with data protection in mind (reduced WHOIS info) from the get-go, the end-result seemed a hacky obvious rule fix defeating the purpose of what the tool was meant for.
2. Another thing the page doesn't answer: Whether queries are shared with MaxMind via their API, or if WMF maintains their own copy of the now-proprietary MaxMind GeoLite2 databases. Then, how does the WMF intend to comply with California Consumer Privacy Act Do Not Sell requests (which was one of the primary reasons MaxMind changed their database license to become proprietary) or similar legal opt-out requests, and will those requests be shared with MaxMind? WMF's current privacy statement seems to be for me at least ambiguous about this.
3. A former concern of mine would've been how the tool distinguishes between Tor relays and Tor exits (since another WMF tool formerly inaccurately flagged my IP-address as open proxy on Wikimedia Commons and a Commons admin banned the IP-address for it, before unblocking after I explained how the tool info was incorrect). I've assumed the tool doesn't currently use the GeoIP2 Anonymous IP database; said database hints it would only flag Tor exit nodes, if this is to be ever implemented?
4. Has the WMF communicated to the public how much it anticipates MaxMind's licensing fees to cost the Foundation? This has not been discussed in benefits and risks.

84.250.14.116 01:12, 13 July 2022 (UTC)

It also seems to me that the country data is not clearly indicated to be potentially non-accurate in the UI (generally less accurate outside of the US), but at the same time the tool is aimed for new and non-technical users who may not be generally aware of that from technical expertise. Oh dear.

Another concern is if the developers (if this is going core in MediaWiki) have considered license compatibility of MaxMind databases with MediaWiki's GPL-2.0+. phab:T248525 hints its using MaxMind API queries for this reason.

~$600 USD/year for only 50,000 queries per month, and that's just for IPQS. 84.250.14.116 01:37, 13 July 2022 (UTC)

Feedback from a network engineer

Hi folks, in my day I'm a network engineer with 10+ year of ISP experience. Let's just assume I know what I'm talking about:

• Location: Location data is often unreliable. Some ISP's assign blocks per region, but others just hand out single ip's or work with dynamic ipaddreses. Let's not even start about mobile. I would make this clearer in the interface that this is a guess. Geoip for my own ip currently ends up on the other side of the country.
• Organization: Seems to be straight from the RIPE database (whois). Names of organizations might be very outdated or cryptic.

Allocation of ip space is done in a hierarchical way:

• IANA is the root and assigns the big blocks to the RIR's, see https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
• The Regional Internet Registry allocates blocks to ISP's. This is called PA space: Provider Allocated space. You'll also see PI (provider independent) space, but that's less common (system that you can switch ISP's while keeping your block of IP space). example
• To actually use IP space you have to assign it in blocks with a meaningful name. example and a route object should exist example

IP assignments (with fallback to IP allocations) are large enough to not cause any privacy issues so these should be included either with metadata or a link to Whois. As an admin I often check the larger block if a single IP is causing problems to see if they're hopping around. The tool should have the same functionality without exposing the individual ipaddresses. If that's not possible I think this will be the last straw on several wiki's and the communities will vote to only allow edits by registered users. Multichill (talk) 10:25, 16 July 2022 (UTC)

Thank you for the feedback. ––– STei (WMF) (talk) 12:46, 9 August 2022 (UTC)

Feedback from an ordinary user

I just used the tool for the first and last time. For ordinary users it is just useless. --jdx ^Re: 04:02, 7 September 2022 (UTC)

@Jdx it is meant for users who work in anti-vandalism. Was there something missing that would make the tool more useful for you? -- NKohli (WMF) (talk) 06:37, 21 September 2022 (UTC)

@NKohli (WMF) and Jdx: This has been going on for a long time. I'm still getting plenty of feedback from my colleagues at en.Wikipedia that the way to go is probably to stop IP editing altogether. Anti-vandalism patrollers do a grand job but they don't catch it all and not all inappropriate IP edits are vandalism. They have other, more sinister agendas. Kudpung (talk) 06:48, 21 September 2022 (UTC)

Yeah, simple, elegant solution which would "magically" solve many problems. Unfortunately, for some reason the Foundation has chosen to burn some money on this nonsense. --jdx ^Re: 09:44, 21 September 2022 (UTC)

Well, I used to fight vandalism a lot on Commons (I am not active there for about a year but I think that I am still the one who patrolled the most edits). Anyway, when I spot a vandal I try to do some investigation before I report them on an administrator/steward noticeboard – sooner or later it will be virtually impossible. In my opinion the most needed information for an occasional anti-vandal fighter is exact location (preferably city, at least 1st level region (state/(Bundes)land/województwo, etc.)) and ISP name. BTW, why it is even possible for an ordinary user to turn the tool on? --jdx ^Re: 09:38, 21 September 2022 (UTC)

Commons is an image repository. Comparing it with an encyclopedia that gets tens of thousands of edits every day is like comparinbg apples with oranges. That said, as one of the en.Wiki editors most concerned with maintaining clean articles, I fail to see how IP masking and its associated tool can be of much help. It's time for the Foundation to come down from its antiquated philosophy of allowing IP edits and stop it once and for all. It's an anachronism in today's Internet, and on the en.Wiki the danger/benefit ratio is only explained by the research that the WMF itself wants to hear. We found that out with ACTRIAL. The en.Wiki can't even cope nowadays with checking the daily submissions of new articles and the Foundation won't help there any more either. Wikipedia is on track for losing its reputation for accuracy and neutrality. I realise the devs do their best but they can only do what they are told to do by their bosses. Kudpung (talk) 10:41, 21 September 2022 (UTC)

Well, one can always retire and that's what I'm going to do once this nonsense takes effect. --jdx ^Re: 11:17, 21 September 2022 (UTC)