reincoder

Diamonds and IPv4 share a common trait.

Lab-grown diamonds found a strong role as industrial components, which expanded overall demand for diamond materials and widened their use cases. IPv6 may follow a similar path, with adoption concentrated in newer and novel applications where IPv4 addresses were scarce.

IPv4 seems likely to remain in place for many existing applications, much like natural diamonds in jewelry, regardless of policy/advocacy views.

I work for IPinfo (but not the author here). We really appreciate the feedback!

So, what we have been doing is we publish a blog and we publish an interactive dashboard as well

  - https://ipinfo.io/reports/most-popular-places
  - https://ipinfo.io/blog/united-states-walmart-wifi-data

We could have done something similar here as well. It is really challenging to balance the stats and explainers. So, the approach we sometimes take with high-impact topics is to provide companion blogs and dashboards for users to explore the data themselves.

I work for IPinfo but my colleague is the author. It is very interesting challenge to "translate" vast amounts of data we have into stories that are insightful.

So, what we have been doing recently is publishing a blog and a companion dashboard. Check it out here:

  - Report: https://ipinfo.io/reports/most-popular-places
  - Blog: https://ipinfo.io/blog/united-states-walmart-wifi-data

Now, that is a good approach for high-impact data to build a dashboard and have a companion piece that only provides surface-level information, so it keeps things interesting and invites you to explore.

But building the dashboards is not an easy task, as you have to deal with data pipelines and work with engineering teams to bring them online.

I am absolutely not being demeaning at all, but just look at the graphics and diagram and skip the text. I think the graphics are a pretty solid explainer of what the article is about. The text dives more into granular information that you may not find useful if you want skimmable content.

We have country level breakdown for ASNs.

  - https://ipinfo.io/AS214822#geolocation

We have some IP range breakdown as well:

  - https://ipinfo.io/AS214822/45.8.228.0/24
  - https://ipinfo.io/ips/45.8.228.0/24

We have the data. How would you like us to present it? (Bonus point if you can tell me why that will be helpful because that will help me to make a better pitch to engineering!)

Not an advert. I wish we ran example.com. However, we run a few other services.

The issue with example.com is this statement:

> This domain is for use in documentation examples without needing permission. This is not a service; avoid relying on it for testing and monitoring purposes.

The problem is that, disclaimer or not, if a website provides a useful utility, people will use it as a service.

If example.com breaks, IANA can reasonably say it was never intended to be stable. But that does not change the fact that people will use it for testing and monitoring.

What we do is adopt legacy services whose maintainers can no longer afford, want, or have the resources to maintain them, and invest in keeping them running reliably.

We (IPinfo) have a practice of adopting low-maintenance, high-utility services. Generally, we adopt websites that would have become defunct and run them as services.

Even though IANA says example.com is intended for documentation purposes and not as a service, I feel that it nonetheless serves as a service to the broader internet. I think there are some cornerstone services on the internet, regardless of the maintainers' intentions or their legal definitions.

For example, we ourselves sometimes have to recognize that we are not a standard API service. Considering that we expect to process 3 trillion requests this year, a major outage could take down a good chunk of IT systems everywhere. So, we invested in infrastructure to avoid outages. We then started adopting other cornerstone services and running them indefinitely because we might as well support the users who depend on them because we have infrastructure to support them and us.

I have been part of this community for over a decade, and in my experience the mods do take flagging and voting irregularities seriously when they are reported. If you believe there is manipulation happening on your posts, that is worth raising directly with them, since they have visibility we do not.

---

On the broader point, we process 3 trillion requests last year, have more than 80 employees, and run a dedicated privacy engineering team led by an ex-cybersecurity company founder. We invest in research on new detection methods and stay closely engaged with the developer community. If there are specific gaps you see in our product, I would be glad to hear them and discuss.

---

Whether any dataset, including residential proxy IP data, is valuable depends heavily on the application. Treating a dataset as invalid because it does not fit one particular model can lead to decisions on shaky ground.

We are regarded as one of the more if not the most accurate IP geolocation providers, and we spend considerable effort on education, solutions architecture, and documentation so customers understand what our data can and cannot support. For example, IP geolocation, even at highest level of accuracy, is not a person identifier. It will never be a 1:1 replacement of GPS geolocation.

Many of the largest companies in AI, anti-bot, fingerprinting, KYC, and CDN spaces use our data. If anti-bot systems and CAPTCHAs were fully reliable on their own, there would be less need for additional signals like residential proxy data. We do not assign a score or label an IP as good or bad. That judgment sits with the customer's own threat or analytics model.

Residential proxy IPs are, by and large, mostly used in web scraping operations of many different forms. If a company sees a moderate to high amount of traffic mimicking human behavior, it can struggle to tell bot traffic apart from real users. Anti-bot mechanisms can help, but they add friction to the user experience, and they are not cheap to run at scale.

Residential proxy detection data is one of the easiest zero-knowledge ways to gather intelligence. There is no need for users to solve a puzzle or for multi-page traversal to collect fingerprint data. All that is needed is the IP address.

Our residential proxy data customers tend to be on the more sophisticated side of cybersecurity. Suggesting that this data is a silver bullet for all their security needs would not reflect well on their expertise or ours. We present the data as is, and from there we work with customers on the right solution for their case.

I work for IPinfo. We offer a residential proxy detection service, which you can check at ipinfo.io/my.

We had a previous discussion about surfacing visitor IP address resproxy status explicitly. Should we have some sort of badge or a more explicit alert to show if a site visitor's IP address is part of a residential proxy network?

Even though it is great for demonstrating the product's value, it is kind of a low-tier value. What can a user actually do when they realize their IP address is part of a residential proxy pool?

The first issue is that residential proxy SDK infiltration is massive. If you start connecting to different IP addresses and constantly check your IP address on our website, you will often see that many of those IP addresses were, at some point, part of a residential proxy pool. We provide frequency information showing how many times an IP address was observed in a residential proxy pool, with a default observation period of 7 days.

Then there is the question of what a user can actually do about it. If it is a controlled IT environment with paranoid IT admins, sure, they can actively monitor traffic and identify why their IPs are showing up in residential proxy pools. They can attempt to do something about it. But it is not easy even then.

Residential proxy SDKs can simply be baked into almost any smartphone or smartphone-derived OS that allows app installation through marketplaces. So, many residential networks are already cooked (because of android TVs). Moderate-scale NAT connections almost always see residential proxy flags, as do public Wi-Fi hotspot IPs, which we also detect.

Identifying the apps that are generating background network traffic is quite hard. You need some level of DNS monitoring or a network sniffer. Alternatively, you need router-level firewall software.

These SDKs are not always sending high-volume, constant traffic that makes them easy to detect. If you see a 100% residential proxy flag for your IP address, then they probably are. But in many cases, the traffic is intermittent and much harder to identify.

Nobody has an answer to what I should do when I see my IP address in a residential proxy pool. It has been accepted in spirit as a "consented malware" for the last few years. It is undetectable and extremely hard to remove because the SDK has been baked into apps themselves.