reincoder

That is a great point! For us, it is 100% of end users not limited to our customers. If you are impacted by our data in any way, it is on us. We are accountable for that.

https://community.ipinfo.io/t/wrong-geolocation-based-on-ip-...

Our free database is licensed under "CC-BA-SA" (freely distributable but requires attribution) because of accountability. If you use our data as an enterprise or a free open-source project, if there is any issue, you can come to us and talk with us.

It is not even end-users. We maintain open communication policies in general. Even if a streaming service does not use our data, if they come to us, we try our best to help them based on our industry knowledge.

I am not sure whether this kind of IP spoofing will impact our accuracy because we will likely identify the noise and behavioral anomaly and discard the location hint derived from traceroute.

We have tons of historical traceroute data patterns, and generic traceroute behaviors are likely modeled out internally. So, if you can spoof the traceroute to your IP address, our traceroute-based location hint scoring weight for that IP address will decrease, and we will rely on the other location hints.

You have to be extremely deliberate to misguide us. But I would love to see this in action, though.

We are actively trying to improve our system and build it as figuratively 'antifragile'. We can not afford to get comfortable and we need to constantly find faults in it. If you know anything, you can contact our founder or me directly.

The problem is that everyone knows we are the most accurate data provider and our growth is exponential. To my knowledge, most cybersecurity teams use our data to some degree. We cannot risk having any secrets out there that could disrupt the accuracy of the system. We are aware of several cases where accuracy may be affected, with the most notable being adversarial geofeed submissions.

If the issue is an adversarial geofeed submission, it is a well-known problem. When active measurement fails, we have to fallback to some location hint. There are layers of location hints we have to fall through to ultimately landing on echoing geofeed location hint.

But aside from that... I'm not sure what could possibly impact us. A substantial systemic malicious change in data accuracy seems highly unlikely and quite impossible.

If it is an anycast IP address, we have hints of all locations. However, because we have to produce a standard IP geolocation product, we can only select one address. So, we choose the address we find from a reliable geofeed and designate the IP address as "anycast" in the API response.

Internally, we have an anycast database. I believe we can also provide all the location hints we see for each anycast IP. It is generally niche data though.

I can tell you how we approach enterprise partnerships: absolute accountability. If something is wrong with the data, it is not our customers' fault for trusting us, it is our fault. End users talk to us directly. And because the data is so good these days, we just have to present evidence, that's it.

We with multi-billion-dollar corporations, and for every product integration we maintain an active, visible presence in their user communities.

For example: https://community.cloudflare.com/search?q=ipinfo%20order%3Al...

Customer support teams are encouraged to build support pipelines that either route data-related questions directly to us or send users directly. We remove friction rather than hiding behind layers of enterprise support.

We make a deliberate "account manager for everyone" effort when introducing ourselves to a partner's user community. We engage with influential community members and MVP users and encourage them to contact us directly when issues arise. We also connect with the engineers who work hands-on with our data and make it clear that they have a direct line to our engineering team.

We actively and aggressively monitor social media for reports of issues related to our data within partner platforms and engage with users directly when something comes up.

To be honest, this is not difficult. Once or twice a month, we may need to present evidence to a user to explain our data decision.

This is not a paid add-on or a special clause in an enterprise contract. Our customers do not pay extra for this level of engagement.

Developers hold us in high regard. Maintaining that trust requires ongoing investment of time and resources. We fundamentally believe developers trust us because of the quality of the product and the lengths we go to provide clear, honest explanations when questions arise.

That is an excellent point!

That is why we have the IP to country level data available for free. As you have recognized the fact that country level data is good for security, we are willing to take a massive hit on potential revenue to allow everyone to use our country level data for free, even for commercial purposes. We literally built separate dedicated infrastructure that provides unlimited queries for our IP to Country data. We want to ensure that everyone has access to reliable data.

For us, based on active measurements, what we do is distribute IP addresses to more densely populated areas. The issue is that we are good at zip code level accuracy, but it is impossible for us to get street addresses correct for residential internet connections. Even if we get geographic coordinates fairly close to you, it is largely coincidental. Our accuracy radius goes as low as 5 KM.

However, consider hotels, conference centers, airports, train stations, etc., where large numbers of people gather and where there are a few public WiFi hotspots that usually remain in the same location. We can identify the exact building from those WiFi hotspot IP addresses.

We have approximately 1,200 servers in operation. Simply by knowing which data centers house our servers, we can reliably identify neighboring hosting IP addresses to the exact data center.

So, there is a dashboard internally for that. When we do ProbeNet PoP assessment, we have a high-level overview of the frequent and favored connections. We have a ton of servers in Africa, and there is a strong routing bias towards France, Germany, and the UK instead of neighboring connections.

Everyone in our engineering and leadership is very close with various CDN companies. We do echo this idea to them. It is not IP geolocation; we actually have a ton of routing data they can use.

We run traceroutes and latency measurements from many different locations, so we are looking at aggregate behavior rather than any single path. When you combine data from hundreds of ProbeNet PoPs over time, asymmetric routing mostly shows up as noise. When that happens, latency based hints lose weight and we lean more on other signals.

We have seen this in practice. For example, when we deployed servers in Gambia, even traffic between local networks often left the country and came back due to limited peering and little use of the national IXP. Stil, the overall routing patterns were still learnable once you look at enough paths.

For VPNs, we are measuring the location of the endpoint IP itself, not user traffic inside a tunnel. If routing only changes after a tunnel is established, that is a service level behavior, not the network location of the IP.

Anycast and tunneling are things we explicitly detect. They tend to create clear patterns like latency clustering or unstable paths, and when we see those and flag them as anycast IPs by defaulting to their geofeed location.

See the classic: https://ipinfo.io/1.1.1.1

We are actually a sponsor of RIPE Atlas and have a bunch of credits.

But I am not sure if we use them extensively. I think, as we own and operate the ProbeNet, much of the data collection efforts can be done through that in a scalable manner.

They have a correction form but I am not sure if it is super robust: https://support.google.com/websearch/workflow/9308722?hl=en

I talked to someone who bought a /24 from South America to be used in the United States for office use. I asked him to tell everyone to get on WiFi and keep Google Maps running. Apparently, that solved the issue.

> how you can spoof IPInfo's location probes...

Interesting. I would love to know how this is possible. Like with Geofeed or something else?

Some of our (IPinfo) services are hosted on GCP, and because our service is widely used (with 2 trillion requests processed in 2024) people sometimes say they cannot access our service. It is usually due to how Google's device-based IP geolocation is used. The user's IP address is often mistakenly identified as being located in a country where Google does not offer service.

I have seen a Europe-based cloud hosting provider's IP ranges located in countries where Google does not provide service. This is because these IP ranges are used as exit nodes by VPN users in that country.

Device-based IP geolocation is strange. We prefer IP geolocation based on the last node's IP geolocation. We hope to collaborate with Google, Azure, and other big tech on this if they reach out to us.

That is really interesting. I wonder if we have any internal data on this. I will check.

We are trying to work with ISPs everywhere, so if port level geolocation of the IP address is common, we surely need to account for that. I will flag this to the data team. To get the ball rolling, I would love to talk to an ISP operator who operates like this. If you know someone please kindly introduce me to them.

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.