241–250 of 333 posts
I can't connect to this site because my adblocker doesn't like it. It seems to be on the bad-domain-list https://www.cromite.org/filters/badblock_lite.txt . Now is the question: is ipinfo.io on this list for a good reason?
I can not access https://www.cromite.org/ It redirects to a dead link hosted on aruba.it. I can investigate it.
I tried to use ProtonVPN when I switched over to ProtonMail a year ago. But so much of the web does not work when you're on a VPN. For example even HackerNews has VPN restrictions. More and more sites know where VPN endpoints originate. How will VPNs prevent this in the future without them just become easy to block?
Even worse is the Reddit approach, where leaving your VPN on will get your account shadow banned permanently. But you are not notified of that, so if you are wondering why nobody is replying to your comments, check in a private session if you can visit your profile page.
I'm a co-founder at WonderProxy, we didn't make their list (we target people doing application testing, not consumer VPNs). We're in 100+ countries, and I'll stand by that claim. It's a huge pain in the neck. In our early years we had a lot of problems with suppliers claiming to be in Mexico or South America who were actually just in Texas. I almost flew to Peru with a rackmount server in my luggage after weeks of pr…
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,…
That way everyone benefits.
I know multiple people who worked / working at Mullvad and they take their business, security and privacy _very_ seriously. Not surprised to see them shine here.
At risk of sounding sale pitch'y. Mullvad is the only VPN the longer I use the more I like it. I've tried MANY competitors first and all the other ones so far seem to only get worse over time. I love that I can pay directly with a crypto wallet and have true anonymity.
Earlier quoted context omitted.
Google, Apple, and Meta (maybe others?) have the data to build a complete GeoIP dataset. None of them will share because there are only downsides to doing so. When FB was rolling out ipv6 in 2012, well meaning engineers proposed releasing a v6 only GeoIP db (at the time, the public dbs were shit). Not surprisingly, it was shot down.
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 GC…
Yep, this is a known effect.
How it seems to work is: Google uses Android phones as data harvesting probes. And when it sees that a lot of devices in a given IP range pick up on GPS data, Wi-Fi APs or cell tower IDs that are known to be located in Iran, and possibly other cues like ping to client devices or client device languages, timezones, search request contents, then the system infers "there's a network wormhole there with Iran on the other end", and the entire IP range grows legs and drifts towards Iran.
The owner of those IP addresses can mitigate the issue, mostly by shaping traffic or doing things to Google's system, but I know of no way for anyone else to do it.
Interesting to learn you can identify the real country/area of origin using probe latency. Though could this be simulated? Like what if the VPN IP just added 100ms-300ms of latency to all of its outgoing traffic? Ideally vary the latency based on the requesting IP's location. And also just ignore typical probe requests like ICMP (ping). And ideally all the IPs near the end of the traceroute would do all this too. To…
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…
In the case of a ping you might think it shouldn't matter but I can imagine a world where a VPN provider configures a server in London to route traffic via Somalia only when a user establishes a connection to the "Somalia" address of the server. You could only test this if you did a traceroute/ping through the VPN.
And I'm not saying this is what's happening but if you just ping the IP from your infra, couldn't stuff like anycast potentially mess you up?
In the case of traceroutes, you only see the route your traffic takes to the VPN, you don't see the route it takes to get back to you, which I think is really important.
I tried to use ProtonVPN when I switched over to ProtonMail a year ago. But so much of the web does not work when you're on a VPN. For example even HackerNews has VPN restrictions. More and more sites know where VPN endpoints originate. How will VPNs prevent this in the future without them just become easy to block?
ProtonVPN stinks. Websites refuse to load and I get autobanned on Reddit etc. Mullvad just worked everywhere. I'm going back when my year plan on Proton ends.
It's the only VPN I've tried thoroughly, so i don't know how they and Proton compare today (or, really, ever). The landscape has been degenerating across the board, I reckon.
Earlier quoted context omitted.
They don't have to assume that traffic is efficiently routed, on the contrary if they can have a It just can't be outside England, just one 0.4ms RTT as seen here is enough to be certain that the server is less then 120 km away from London (or wherever their probe was, they don't actually say, just the UK). RTT from a known vantage point gives an absolute maximum distance, and if that maximum distance is too short th…
I see I was mistaken, but I'm tempted to continue poking holes. Trying a different angle, though it may be a stretch, but could a caching layer within the VPN provider cause these sort of "too fast" RTTs? Let's say you're a global VPN provider and you want to reduce as much traffic as possible. A user accesses the entry point of your service to access a website that's blocked in their country. For the benefit of this…
It is very unlikely that VPN providers use convoluted caching systems just to make their ping replies appear to come from a different region than the one they claim to be in. It would be much more likely for them to add a little latency to their responses to make them more plausible, instead.
Earlier quoted context omitted.
> Wireguard and remove Apple and Tailscale from the equation entirely I agree you could send them a preconfigured pi, but can we stop pretending talescale is just wireguard - there is a lot of convenience in the NAT traversal that you otherwise need router config and/or a publically routable server to achieve.
> but can we stop pretending talescale is just wireguard That's precisely the issue. It introduces additional centralized dependencies and closed source components.