| I apologize for a somewhat snippy comment, but the idea that VPNS don't really protect against bad ISPs comes up all the time, and it drives me bonkers. > Between TLS and DNS over HTTPS, the number of things an ISP can reliably discern from your traffic is becoming vanishingly small. A) While encryption is commonplace, not everything on the web is encrypted. The most recent stats I can find[0] say that about 3-10% of common web traffic is still not encrypted. If you're browsing more interesting parts of the web (ie, old forums and independent sites, and not just Facebook/CNN) your stats are probably worse. B) Even if all of the websites you visit are fine, a nontrivial portion of native apps also don't use encrypted endpoints, because unlike on the web there were never native warnings or lock icons in a URL bar to force them to make the change. C) Even if the server is using TLS, there are numerous attacks based around measuring packet delivery times and request sizes to figure out exactly which static pages of a domain you're visiting. This is why Linux package managers have widely dismissed HTTPS -- it provides no privacy for their specific use-case, because anyone can figure out what you're downloading just by counting how many bytes get sent to you. D) So you just turn on DNS over HTTPS, right? Sounds good, except pretty much none of your native apps or dedicated devices like game consoles, e-readers, and smart-home appliances support it unless you're handling it on the network level. Even if you are doing DOH on your router, it's not uncommon for dedicated devices to bypass your DNS settings entirely. Even Google is guilty of this, for a long time you could not set a Chromecast to use a custom DNS server. E) Even if you have DNS over HTTPS, you still need to worry about SNI, and encrypted SNI still has relatively low adoption on the web outside of industry-leaders like Cloudflare. ---- But let's assume that none of the above applies to you. You're connecting to a site that's using TLS 1.3 and supports encrypted SNI. You're using DNS over HTTPS. In that scenario, knowing the IP/port of the server you're connecting to can still be good enough to unmask the domain. You do bring up this point, but then you kind of just skip over it. > One can argue that IPs and ports matter, but if all the IPs you visit are in AWS (and their ilk) But they're not. Yes, if every single site I visited had the same IP, I'd be fine leaking that information. But they don't all have the same IP. I visit plenty of sites that are being hosted on independent hardware, on Linode servers, and so on. Servers with unique, static IPs are not uncommon. Not only is this bad advice in the sense that it just isn't true, it's also bad advice because it's tying security/privacy to centralization. We want people to host their own stuff online, we don't want everyone to be on AWS and Google Cloud. We want diversity of hosting. ---- Finally, although I understand you're only talking about ISPs above, it's also worth noting that the point of a VPN is not just to obscure your traffic from your ISP, it's also to obscure your IP address from the sites you visit. That's also an idea that gets regularly dismissed by a vocal subgroup on HN, who are apparently of the opinion that the entire TOR project is just a waste of time because IP addresses don't actually matter. VPNs are not a perfect solution. They're arguably not a even a good solution. But the problem that they're trying to solve does exist. There are reasonable, strong arguments to make against VPNs: that they aren't magic, that they're deceptively marketed, that shifting trust can be problematic. "IP addresses aren't worth protecting", or "DNS is fine already", are not reasonable arguments. [0]: https://transparencyreport.google.com/https/overview |