it should probably link to this: <a href="https://mullvad.net/en/blog/exit-ip-fingerprinting-between-vpn-servers" rel="nofollow">https://mullvad.net/en/blog/exit-ip-fingerprinting-between-v...</a><p>which is the blog post, rather than a list of exit servers<p>related to this post: <a href="https://news.ycombinator.com/item?id=48143880">https://news.ycombinator.com/item?id=48143880</a>
That blog post is a perfect example of when RFC5737 should be used.<p><a href="https://datatracker.ietf.org/doc/rfc5737/" rel="nofollow">https://datatracker.ietf.org/doc/rfc5737/</a>
Nice. But unfortunately these addresses are hard to remember and "nobody" recognizes them when reading examples. One of those "standards" that have been a great idea, but lack practical relevance.
Anyone who writes technical documentation about networking knows the key ranges, and at least TEST-NET-1 (192.0.2/24) is pretty easy to remember. You only gotta look it up a few times, instead of being sloppy and justifying so with “no one cares anyway”.<p>It partly because attitudes like that is why software is a mess. Too few people care about correct semantics, everyone is satisfied with whatever sticks. From lists for sets, to tag soup instead of markup, and so on - all the way to modern code slop.<p></rant>
> But unfortunately these addresses are hard to remember and "nobody" recognizes them when reading examples.<p>Mmm.<p>It's pretty easy to put three IPv4 /24s on a sticky note on your monitor. I think it's not unfair to say that if one can remember <i>every</i> fact related to one's job, then one has a job with a very, <i>very</i> small scope.<p>Also, this is another great reason to use IPv6. The v6 documentation prefix is '2001:db8::/32'... plenty of space for example subnets and easy to remember.
On a side note, buttons icons on this page won't load without javascript. I cannot comprehend what would justify such decision.
Without justifying it, the reason is simple. They are using a front end framework (bootstrap) that many developers use/understand that also supports 99.9% of browsers.<p>Running a browser without javascript that you still want graphics to display (so not a screenreader or text-based-browser), is part of the .1% they are willing to disappoint.<p>Do I think it is overkill? Sure. Do I still use jQuery at work even though the vast majority of its once handy features are now baked into JS in the browser by default? Of course.
It’ll be a run-on effect of whatever framework they are using, and they very justifiably don’t want to bother catering to you. Having JS disabled in 2026 and complaining about sites not behaving is simply a performative act.
>and they very justifiably don’t want to bother catering to you<p>Considering they are one of the very few sites and VPNs that allow sign up without JS your claim is verifiably false. They also collaborate with and develop there own tor browser fork which has the highest rate of non JS user.
It’s basic self defense. Who runs around the web in 2026 allowing random JS? Might as well be licking seats on the subway.
[flagged]
What "buttons icons"? When I set the "javascript.enabled" preference in Firefox 151 to "false" and reload the page for RFC 5737, I get a "Javascript disabled? Blah blah blah blah." complaint near the top of the page. I <i>do not</i> get<p>* the useless-to-me "document history" bar graph at the top<p>* the automatic switch to Dark Mode(TM) that I don't care about<p>* functional pull down menus at the very tippy top of the page that are entirely unrelated to RFCs that I give zero shits about<p>The "without javascript" version of the page seems to me to be otherwise identical. Amusingly, the "Email authors", "IPR", & etc buttons switch to the pages they reference notably faster with Javascript disabled.<p>What broken things were you seeing that I haven't mentioned? Were you using Chrom(e|ium)? Safari?
Are you in 2006 or 2026?
The post you preferred was submitted before. And had not much new information. The rollout was the news. The link was correct.
The page already contains link to both of these resources
I'd really like some version of E.G. Librewolf configured to spoof the exact SAME information no matter who's using it. Like standard resolution for a 1080p monitor, the same GPU profile, Allow device timing stuff to work but with a fixed profile etc.<p>Effectively, stop spoofing random data, start spoofing still useful but not for finger printing data.
The Mullbad Browser?
<a href="https://mullvad.net/en/browser" rel="nofollow">https://mullvad.net/en/browser</a>
This is already what LibreWolf does for most of its fingerprinting protection, including resolution, which you call out. It already works, LibreWolf is the only browser besides Tor I’ve found that actually defeated fingerprinters in some of my testing. Is there something that’s currently randomized that you think should be binned or homogenous?
Maybe it's just me, but I'm incredibly surprised by their prompt reaction to this. As a user, I was already preparing to deal with this myself.<p>Wow, is this how things were before bureaucratic behemoths took over the tech industry?
When news broke I was really confused how IPs with thousands of users would suddenly be more identifying than <i>your home IP</i> with one user.<p>I'm happy that Mullvad actually explains the issue very clearly in <a href="https://mullvad.net/en/blog/exit-ip-fingerprinting-between-vpn-servers" rel="nofollow">https://mullvad.net/en/blog/exit-ip-fingerprinting-between-v...</a>
If you us Mullvad browser, which has built in Mullvad proxies, this isn't an issue because it doesn't use wireguard.<p>The browser also has a cool feature in the browser extension called Random mode. This gives you a different IP for each site, improving your privacy.
You can probably also use it on regular Firefox.
It's not going to be an issue for most things which have been properly thought out as they will have proper isolation between servers which should have separate identities. Reusing the same VPN for all servers and relying on an eventual expiry before the IP changes is fundamentally not a great approach to rely on for isolation.
Which you absolutely shouldn't use, because just like Tor Browser before, a vulnerability in the browser can be immediately escalated into decloaking your real IP. Ideally the proxying doesn't even happen on the same machine.
"Absolutely shouldn't" is silly.<p>- Browser vulnerabilities are non-trivial.<p>- Mullvad browser's proxy feature only works if you're connected at the OS level, which helps mitigate browser level exploits.<p>Compared to any other off the shelf solution, Mullvad browser provides a good balance of usability & privacy.<p>Compared to something like you're describing, I agree it's worse.
One possible mitigation might be to run your system (or just the browser/certain apps) sandboxed to only communicate with the IP/ports mullvad uses for VPNs.
What threat model should you use Mullvad browser in? What threat model should you avoid Firefox-based browsers?<p>Please talk in terms of specific threats instead of fearmongering. For people wanting to avoid surveillance capitalism, which is a very common threat, I think Mullvad Browser is a fantastic choice.<p>For journalists targetted by nation states, perhaps it would be better to use Brave or Chrome inside of Qubes.
> For journalists targetted by nation states, perhaps it would be better to use Brave or Chrome inside of Qubes.<p>Curious why Chrome/Brave is recommended? I don't think any modern browser is better for anti-fingerprinting like the Firefox-based ones, including TOR and Mullvad Browser? Don't install random extensions outside the defaults and you're doing a lot better than a Brave/Chrome install if you want a usable internet.
I mentioned those because they are more focused on security than privacy/anonymity.<p>Chrome takes security a lot more seriously than Firefox, but Firefox does more for privacy. It would depend on the specific person, whether they are more worried about zero days or more worried about being identified.<p>Zero days for chrome will cost more than zero days for Firefox because Chrome takes security more seriously, there are more exploit preventions.<p>Brave is based on chromium and has a good update schedule, but it has some regressions like allowing manifest v2. Chrome is going to have the best update schedule.<p>Vanadium is the only browser that improves on Chrome's security.<p>(Don't get your opsec advice from HN)<p>(I learned this from GrapheneOS)
> Zero days for chrome will cost more than zero days for Firefox because Chrome takes security more seriously<p>They may cost more for Chrome, but it needn’t be because Chrome takes security more seriously; Chrome’s greater market share alone would be enough to account for this.<p>Not that I’m denying the overall conclusion. Just this bit of reasoning.
Do VPNs pay retail ISPs for exit points?
No, not usually. Few ISPs are willing to risk blacklisting.<p>Just like scrapers (and a lot of VPNs are quietly using their custom VPN clients to sell your own IP [and data] to scrapers) it's mostly a "don't ask don't tell" situation for IP sourcing. You use a multitude of IP providers and if a scandal happens you just say "We didn't know!" and move on to the next. Almost always grey-market, very rarely through legitimate providers.
I see DataPacket.com have VPN clients.<p>Does anyone know if this is any issue for non-vpn users of datapacket.com?<p><a href="https://www.datapacket.com/case-study/nordvpn" rel="nofollow">https://www.datapacket.com/case-study/nordvpn</a>
>Does anyone know if this is any issue for non-vpn users of datapacket.com?<p>Probably not that much worse than other VPS providers with trashed IP reputations, eg. digital ocean, vultr, ovh. If you're blocking bots, the first thing to block is any datacenter ip ranges, not just known VPN servers.
why is this downvoted? I'm not aware of a single ISP that would willingly let VPN providers use their ip blocks for their exit nodes
Mullvad in particular has a page that lists the ISPs they use (in a few cases their own servers at a datacenter), although they don't list the datacenters (sometimes you can get this info from the ISPs).<p><a href="https://mullvad.net/en/servers" rel="nofollow">https://mullvad.net/en/servers</a><p>They also have a document that lists some of their practices around the servers, such as not using shared servers:<p><a href="https://mullvad.net/en/help/server-list" rel="nofollow">https://mullvad.net/en/help/server-list</a><p>I noticed that the website of one of the two providers they use near me was over a decade out of date :/. DAITA is Mullvad's anti-traffic analysis framework, without it a single hop can likely be easily deanonymized by logging by a single party (it isn't clear if multihop uses fixed packet sizes between their servers).
Some VPN providers don't even have exit nodes in the country they're claiming. Instead they'll have their IPs registered to the respective countries in GeoIP databases.<p>This isn't a practice all VPN providers partake in. And from my own anecdotal experiences, Mullvad seem to be using services that are geo-located (I say this because I've tested latency between different endpoints in Mullvad). But it is something to be wary of with some of the less reputable providers.
Not retail ISPs, but many extensions and free VPNs route VPN traffic through the connections of those who use them.
[flagged]
[dead]
[flagged]
[flagged]
[dead]
Is this at all related to Wyden's recent congressional warning? Are any other VPN providers speaking up on this?<p><a href="https://www.wyden.senate.gov/imo/media/doc/wyden_letter_to_gabbard_on_commercial_vpn.pdf" rel="nofollow">https://www.wyden.senate.gov/imo/media/doc/wyden_letter_to_g...</a>