reincoder

We operate servers for the purpose of measuring the internet using a wide variety of methods. We have more than 1,200 of these servers distributed across 530 cities, running not only ping but traceroute and many other types of active measurements.

In addition to active measurement and research, there are many other sources of data we use. Also, we are actively investing in R&D to develop new sources. Adding just 300ms of latency at the end of an IP address would simply appear as noise to us. We have dozens of locations, hints cut through the noise.

We welcome people to try to break the system. Perhaps it is possible to dupe this system.

We (I work for IPinfo) talk about latency because it is a thread that you can start from when exploring our full depth of data.

We are the internet data company and our ProbeNet only represents a fraction of our investment. Through our ProbeNet, we run ping, traceoute, and other active measurements. Even with traceroute we understand global network topology. There are dozens and dozens of hints of data.

We are tapping into every aspect on the internet data possible. We are modeling every piece of data that is out there, and through research, we are coming up with new sources of data. IP geolocation is only product for us. Our business is mapping internet network topology.

We are hoping to work with national telecoms, ISPs, IXPs, and RIRs to partner with them, guiding and advising them about data-driven internet infrastructure mapping.

I work for IPinfo.

We also run traceroutes. Actually, we run a ton of active measurements from our ProbeNet. The amount of location data we process is staggering.

https://ipinfo.io/probenet

Latency is only one dimension of the data we process.

We are pinging IP addresses from 1,200+ servers from 530 cities, so if you add synthetic latency, chances are we can detect that. Then the latency-related location hints score will go down, and we will prioritize our dozens of other location hints we have.

But we do welcome to see if anyone can fool us in that way. We would love to investigate that!

We (IPinfo) attended the IETF 3-day workshop on IP geolocation. Our presentation was about geofeed that can be viewed here: https://youtu.be/l8PR7VCmA3Q?si=dG-00UqljTopBquF&t=372.

It was a great session and we received a lot of questions. We attend different NOG conferences regularly. ISPs are incentivized to help us by providing good data. Although we are agnostic about adversarial geofeeds, ISPs themselves need to work with us to ensure good quality of service to their users.

We already do quite a lot of outreach, in fact, most network engineers in the ISP industry across the world are familiar with us. But if any ISP operator has any feedback for us, we are only an email (or even a social media comment) away.

That was actually a great article. For us, that is like a crowdsourced bug hunting program. We actually got duped ourselves, and we appreciate the author.

We added additional features for location hint modeling and selection for IPv6 networks. There are a handful of open engineering tickets to understand more about the entire internet infrastructure of the country. Of course, hosting a probe server out there would be helpful.

https://ipinfo.io/countries/kp

We always appreciate feedback like that.

I can not access https://www.cromite.org/

It redirects to a dead link hosted on aruba.it. I can investigate it.

Our headcount is approximately 70 right now. Most of engineering consists of data engineers, researchers, and data scientists because data is our product. Then we have infrastructure engineering, software engineering, integration engineering, support engineering, solutions architects, mobile application engineering, UX/UI designers, website engineering, API engineering (separate from the website because of the volume of traffic we receive), a full commercial team with partnerships and sales, finance/accounting, legal and a marketing team. I think I am still forgetting some people. We also work closely with consultants who are foundational to the internet as a whole. We have an open hiring policy for the right talent.

During our offsite, we had to rent out a small ship (ferry?) to host everyone: https://x.com/coderholic/status/1975333382604398702/photo/4

More than a decade ago, when IPinfo launched, a lot of community interaction was done by our founder. Now, you have me in a full-time role talking to people. My role is literally called Developer Relations.

We are not just a IP geolocation company; we are an internet data company. IP geolocation and VPN detection are only products to us; the team and goal are actually quite huge.

We are always happy to work with large technology enterprises and streaming platforms, not necessarily to sell, but to share insights, data, and practical advice. We observe the entire internet through active measurements, and we are open to co-publishing research when it benefits the broader ecosystem.

Google/GCP is top of mind for me due to a recent engineering ticket. Some of our own infrastructure is hosted on GCP, and Google’s device-based IP geolocation model causes issues for internet users, particularly for IPv6 services.

From what we understand, when a large number of users from a censored country use a specific VPN provider, Google's device-based signals can bias the geolocation of entire IP ranges toward that country. This has direct consequences for accessibility to GCP-hosted services. We have seen cases where providers with German-based data centers were suddenly geolocated to a random country with strict internet censorship policies, purely due to device-based inference rather than network reality. Our focus is firmly on the geolocation of exit-node IPs, backed by network evidence.

https://community.ipinfo.io/t/getting-403-forbidden-when-acc...

We are actively looking to connect with someone at Google/GCP, Azure/Microsoft and others who would be willing to speak with us, or directly with our founder.

Our community consistently asks us to partner more deeply with enterprises because we are in constant contact with end users and network operators. To be honest, we do not even get many questions or issues. We are partners with a large CDN company, and I get one message about a month, which usually involves sharing evidence data and not fixing something.

From a large-scale organization's perspective, IP geolocation should not be treated as an internal project. It is a service. Delivering it properly requires the full range of engineering, sales, support, and personnel available around the clock to engage with users, evaluate evidence, and continuously incorporate feedback.

I work for IPinfo. We provide IP geolocation and VPN detection services. We identify which IP addresses are associated with a VPN and the actual location of the IP address.

We have not collaborated with any VPN companies for the report and have not even requested permission or pre-draft approvals. We had the data of what we were seeing and published a report based on that. We have published a ton of resources around the nature of VPN location in the past. Our focus is on data accuracy and transparency.

After the article was published, we received feedback from only a single VPN provider - Windscribe (https://x.com/ipinfo/status/1998440767170212025). I do not think anyone from Mullvad, iVPN, or any other VPN company has reached out to our team or our founder yet.

We are happy to take feedback and comments and are even open to a follow-up!

I work for IPinfo.

No, the article does not make this conclusion at all! It was carefully written to highlight the nature of virtual locations of VPN exit nodes and does not make such conclusions.

The article is written by our founder, who is accessible to the VPN industry at large and is open to feedback and comments.

I work for IPinfo, and I appreciate your comment.

Our product philosophy is centered on accuracy and reliability. We intentionally diverge from the broader IP geolocation industry's trust-based model. Instead of relying primarily on "aggregation and echo", we focus on evidence-backed geolocation.

Like others in the industry, we do ingest self-reported IP geolocation data, and we do that well. Given our scale and reputation, we receive a significant volume of feedback and guidance from network operators worldwide. We actively conduct outreach, and exchange ideas with ISPs, IXPs, and ASNs. We attend NOG events, participate in research conferences, and collaborate with academia. We have a community and launch hackathon events, which allow us to talk to all the stakeholders involved.

Where we differ is in who our core users are. Our primary user base operates at a critical scale, where compromises on data accuracy are simply not acceptable. For these users, IP geolocation cannot be a trust-based model. It must be backed by verifiable data and evidence.

We believe the broader internet ecosystem benefits from this approach. That belief is reflected in our decision to provide free data downloads, a free API with unlimited requests, and active collaboration with multiple platforms to make our data widely accessible. Our free datasets are licensed under CC-BY-SA 4.0, without an EULA, which makes integration, even for commercial use straightforward.

I appreciate you recognizing that our product philosophy is different. We are intentionally trying to differentiate ourselves from the industry at large, and it is encouraging to see competing services acknowledge that they are focused on a different model.

I work for IPinfo. I am not sure what routing tricks Proton uses. I have looked into the smart routing and stealth protocol related documentation. I am not sure if Proton does anything unique when it comes to IP location. I am not saying this officially, but I am just curious here.

Smart routing documentation: https://protonvpn.com/support/how-smart-routing-works

'Virtual' VPN server geolocation involves informing IP geolocation providers that their Singaporean servers are located in India. We looked into data and latency-based locations, but the industry at large uses self-reported location information for their data. So, if you use a service that uses IP geolocation provider (that is not us) they will just tell them that the Singaporean IP address is located in India, because that is the information they have and they do not have any other ways to verify it. But at the end of the day, the location information is coming from the VPN itself.

I could be wrong, and there could be technology and technique I am missing, so I am happy to learn. The blog is written by our founder who is accessible to the Proton team if they want to share their feedback with us.

I work for IPinfo. I have raised a ticket internally, but I think we focused on consumer VPNs for this test.

For our ProbeNet, we are attempting to reach 150 countries (by ISO 3166's definition). We are at around 530 cities. Server management is not an easy task. We do not ship hardware, but operate using dedicated servers, so this reduces one layer of complexity.

To maintain the authenticity of our server locations, we utilize cross-pings and network traffic behavior detection. If any abnormality is detected, the server will be immediately disabled to prevent polluting our data. There will be a ticket to investigate what went wrong.

We pay for each (excluding 3 to 4 servers where the owner and the team really likes us and insists on sponsoring) server. Expansion is an active effort for us, as there are 70k ASNs and about 100 more countries where we do not have a server.

We hope to partner with more ASNs, particularly residential ISPs and IXPs. So, a lot of effort is put into active outreach through WhatsApp, emails, social media and phone calls. We use a number of different data-based techniques to identify "leads".

That is surprising. I am not sure what is going on. This type of accuracy can only work if you are operating like a literal data center. Even in that case, I think meter level accuracy will involve hosting one of our ProbeNet PoPs.

For example, we know where our ProbeNet PoPs are located. If hops to your ranges are through private IPs or sub 1 MS RTT, we can pretty much confidently tell the name of the data center. However, considering that there are data centers that span thousands of square meters, we can point to the data center building, rather than the rack or the room.

To me, it is likely a coincidence.

I work for IPinfo. If you're on a residential connection, the geolocation of that IP address is likely to be accurate up to the ZIP code area. We have generalized hints of location information from over 70 different sources. Then we aggregate them and we map this information based on population density in the geographic region. Sure, our data is becoming more granular, but it's not granular enough to detect individual houses from residential connections.

However, our data is improving for POI (Points of Interest). For example, with data centers, we're working on identifying the exact data center from IP addresses. Similar accuracy applies to airports, hotels, and conference halls, as they tend to have a large concentration of IP addresses in a very small area.

We do publish a lot of information on our research page: https://ipinfo.io/data-research

I work for IPinfo. I'm not sure how ChatGPT incorporates IP geolocation data in their services, but I have seen open-source LLM-based conversational AI use our service before. The API provides context around location and time mostly.

However, my opinion is that geolocation, at least on a country level, can be largely inferred based on conversational context.

I work for IPinfo. Creating adverserial geofeeds is not illegal — it's just frowned upon at best. We treat geofeeds as self-reported location data, and we do not assume they are trustworthy.

This is exactly why, unlike much of the industry, we maintain a large team across engineering, data engineering, data science, and research, along with a substantial data-processing infrastructure and 1,200+ servers. Our entire purpose is to verify location data rather than simply aggregate, parse, and repeat whatever is self-reported. Otherwise, it’s just GIGO.

Even though we came up short in this particular case, we are actively pushing updates right now that eliminate these issues going forward.

Thank you for mentioning us. I work for IPinfo. We perform a combination of a ping and a traceroute to understand how packets travel through the internet so that we can determine the location of the IP address. Our objective is to map the entire internet.

However, ideally, we should have a PoP in Seychelles. Some of our recent expansions have been in offshore territories.

https://ipinfo.io/probe-network

I am the DevRel for IPinfo. While we recognize that we should have been more accurate in this instance, it’s worth breaking down how our methodology works. We are also rolling out some geolocation tweaks that should neutralize the inaccuracies caused by adversarial correction submissions.

First, we use active measurement for IP geolocation as our primary source. Our main data source is our ProbeNet infrastructure, which consists of 1,200 PoPs across 500 cities. Through ProbeNet, we run active measurements to every IP address and routable IPv6. Because we run both ping and traceroute, we typically have a very strong sense of where an IP address is located.

However, ProbeNet is not our only data pipeline. We process several dozen additional data sources. For example, unrouted or unassigned IP addresses do not generate active measurements, so we must rely on other forms of data.

In reality, we must “fallback” to alternative location evidence when active measurement is unavailable. Even though we manage, expand, and maintain a very large server network and a highly complex data pipeline, some IPs require us to rely on what the ASN operator reports.

It’s fair to say that no ASN other than AS131279 (https://ipinfo.io/AS131279 ) is located in North Korea. However, if someone asks for evidence showing that a particular IP address is not located in North Korea, that is extremely difficult to prove in isolation. We prefer not to rely on a null-island methodology and instead choose a location based on a hierarchy of hints.

For unrouted or unassigned IP addresses, geolocation can point to random locations, and in such cases we often must rely on the ASN operator’s data. I’ve seen this happen, even among well-established ASN operators. Some assign random placeholder locations to unrouted and unassigned ranges particularly for IPv6 IP addresses.

More context:

https://community.ipinfo.io/t/the-north-korean-gamers-on-ste...

https://community.ipinfo.io/t/why-is-this-orange-com-ip-rang...

I work for IPinfo, and this is a tangent note on a tangent note. We offer a free IP geolocation database, and we recently started providing an unlimited API query service for free against that database.

Maintaining an IP geolocation database requires some upkeep. You have to download the database regularly (in our case, daily) to keep the data fresh, and you need a system in place to make it useful.

That’s why we created a dedicated API tier that offers unlimited requests. The data is being used by many open-source projects, so we’re simply doing our part to support them by providing both the data and the API infrastructure service. Last year, we processed over 2 trillion API requests across all our API services. There are many projects, Open Source and Enterprise, that are making billions of requests daily, and they are on a free tier plan.

Thank you very much for looking into it. I really appreciate it! I agree with you. I understand the point clearly.

I work for IPinfo and provided the data for it. The original intention for the project was to identify data center locations. The original idea of the project came from https://stefansundin.github.io/traceroute-mapper/. I reworked it and then OP added a lot of bells and whistles. For my day-to-day work, I still use my version.

I manage approximately 1,200 PoPs that are part of IPinfo's ProbeNet platform, which is used to generate our internet measurement data. We, in turn, use this data to produce the IP geolocation data you utilize. The issue is that the servers we manage can be moved to different locations or not be in the advertised locations. We operate these PoPs across 500 cities.

Whenever the PoP fails to meet certain physical location checks, I run basic diagnostic tests to determine where the server is located and where it is not. Aside from running ping and traceroute operations to the target servers, I can run traceroutes to certain IP addresses whose paths I am familiar with. A traceroute visualizer provides a visual interface, information on the ASN, the geolocation, and the time measurements. This provides an intuitive view of where the server "could not be" located rather than could be located. We use several techniques to run basic diagnostic tests. This traceroute visualizer isn't an official test of IPinfo; it is something I vibe-coded together. There are far better internal tools, such as running ping and traceroutes across all of our ~1,200 servers simultaneously.

It is a network diagnostic tool. I think based on your comment, it is not just a tool, it is more of an abstraction of a tool! But it is somewhat useful I thinkl.

I am happy to hear your thoughts. I manage these servers and we are trying our best to improve our data consistently. So, any ideas or even random thoughts you might have can help us improve.

I work for IPinfo and we provided the data for the project. I would really appreciate your insight on this.

We run ping and traceroute operations from 1,200 servers across the world to every (within reason) IP address out there. So, we have ping RTT and traceroute data history of these measurements.

Considering the physical network topology does not match the physical network topology, we would love to hear your thoughts.

Unrouted IP addresses do not appear on the internet traffic, and we have limited network data for them.

If you can share your traceroute output and obfuscate as much data as possible, we will be happy to investigate and share feedback.

Thank you very much! I work for IPinfo. I am not super familiar with the platform, so it went under my radar. I appreciate the correction.

I work for IPinfo. I did not know that our site was blocked by Firefox Enhanced Tracking Protection. Not sure what I can do here. The project takes the IP addresses you have provided from your traceroute and gets the information related to them from our website using a frontend HTTP call.

I work for IPinfo, focusing on data adoption and supporting the wider use of our free services.

The dataset the user is accessing (IPinfo Lite) is licensed under CC-BY-SA 4.0 and does not come with an End User License Agreement (EULA).

Most free IP geolocation databases in the market do include restrictive EULAs. These usually require each individual user to register, obtain their own copy of the database, and limit usage to themselves only. In many cases, sharing the data or keys outside of the original intended scope is considered a violation of license agreement. Because of these restrictions, some providers also offer paid redistribution licenses, which can be expensive and typically targeted at enterprises.

Our approach is different. By licensing IPinfo Lite under CC-BY-SA 4.0 WITHOUT an EULA, we allow anyone to share or redistribute the data freely, as long as proper attribution is given. The goal is twofold:

  - Make it easier for projects to use the data without legal barriers.
  - Ensure that any questions or issues about the data are directed to us rather than to project maintainers.

Some large open-source projects, major global enterprises, and governement institutes are already using IPinfo Lite right now.

I think the main thing was that we were doing a migration. We operate a very large-scale infrastructure, and our engineering team is super talented. However, you can imagine this is not a very common case.

I appreciate you taking a look. Let me know if you have any feedback for us. I am the DevRel, so I hang out in the community. If you see any issues where you think you need immediate support, post that in the community, and I will respond.

https://community.ipinfo.io/

Here is the postmortem report: https://ipinfo.io/blog/post-mortem-september-17th-api-outage

Here it is: https://ipinfo.io/blog/post-mortem-september-17th-api-outage

I know. We running a postmortem right now.