I wonder about those VPNs that say "we don't log or store anything". That may be the case, but they probably just send a continuous stream of data to the law enforcement / intelligence services or whoever instead of storing it themselves. They can then correctly say "WE don't log".
Even with an honest company, the pressures on them are twofold – security and legal. Their systems can be compromised through security vulnerabilities and social engineering (including coercion – money, ideology, compromise, ego – classic psyops playbook). Or they can get legal government orders - which pretty much every government in the world have laws on books and operational practices to force any actor to hand-over data in the name of fighting money laundering and terrorism (AML/CFT). It is very expensive to put up strong defenses against these. I don't see a viable business model charging $5/month that covers regular operational expenses and covers these types of events.
Edit: Forgot to mention backdoors built into basic technologies they may already be using – like the Cavium HSM thing that came to light earlier this week.
You know at that point why not just hack Level3, Cogent, Telia, Zayo or some other T1 provider?
Frankly VPNs don't protect you from anything other than the most monitoring systems and the occasional public wifi connection. They're really just glorified Netflix region proxies and nothing more to most people
I don't think that the Houston Police Department (or whichever city you're in) is sophisticated enough to set up an NSA-fiber-optic-backbone-data-siphoning operation. Yes, the NYPD is known to buy illegal million dollar cell phone interceptor machines, but that's about it the maximum level that sort of thing ever goes, for the largest municipal law enforcement agency in the United States.
Like, how would that even work? Without a court gag order, gossip would make its way out of the building in weeks. The cell phone shit only was only quasi-secret because only police department employees were involved, something that's impossible for these VPN outfits. They don't get any of the (unjustified) privilege that the CIA or NSA (or even the FBI, sometimes) receive.
Anything I might do that could pique the curiosity of law enforcement is definitely below the level of federal intelligence agency interest. Maybe your life is more exciting though.
This is how lawful intercept systems have worked since the nineties. You’d have to go look at their jurisdiction to see whether there are laws mandating LI that impact vpn providers. Or Mulvad could clear it up, I guess.
Sweden absolutely has LI requirements for all telecom gear but vpns I have no idea.
Lying about it opens you up to potential litigation and being exposed through discovery. It makes less sense to outwardly lie to paying customers rather than simply lie by omission.
The EFF wants a world where this kind of BS, and consequent litigation, is a thing of the past. If there's water running down their face, it's tears, not drool. We deserve a better world.
You get there by either getting congress to pass laws or by setting legal precedent in the court. That’s the goal of the legal arm. Not to fight every bullshit civil liberties case, but to fight the last one that doesn’t get thrown out in court.
If you don’t think they look forward to those cases, I think you’re the one who has read them wrong, not me.
There should probably be case law before anyone actually believes in warrant canaries.
'If it's illegal to advertise that you've received a court order of some kind, it's illegal to intentionally and knowingly take any action that has the effect of advertising the receipt of that order. A judge can't force you to do anything, but every lawyer I've spoken to has indicated that having a "canary" you remove or choose not to update would likely have the same legal consequences as simply posting something that explicitly says you've received something. If any lawyers have a different legal interpretation, I'd love to hear it.' --Moxie Marlinspike
Why would someone have to lie? They can just say "We can't comment on that" without providing an answer. And then customers can go "sounds pretty suspicious, time to switch VPN services".
The point of the canary, is to turn any non-answer into a practical, or at least a tentative, "yes". If you no longer see an explicit "no", it means "yes".
The difference between a canary and a "no comment" is that "no comment" is an extremely common thing to say whether an allegation is true or not so it's not very suspicious, while stopping a canary is very suspicious.
So it's like the scenario you outlined earlier, but more effective.
No, it isn't. It's pretending that "no comment" means something it doesn't. Just because you want it to mean "yes" doesn't mean it means that. It means "we are not going to comment on this, because we have a sane legal department and we're not going to give you any information one way or another".
If you think "no comment" means either yes or no, you're pretending to know something you don't, and you should absolutely stop and go "wait, why am I lying to myself? And why am I believing my own lie?"
Yes, I was the one saying that _people_ consider it suspicious, but I'm also the one saying that as a company your only course of action is to not comment on legal matters unless legally compelled to. Those two things are not mutually exclusive. People (in aggregate) don't act rationally, so even if it's going to lose you some customers, no comment.
That doesn't explain your previous comment. Was the accusation about [[pretending that "no comment" means something it doesn't]] a misunderstanding of what I was saying? Or a confusion between me and powersnail? Or something else entirely?
If it's about what powersnail is saying, I think they're just wording things imprecisely. The canary doesn't actually affect the meaning of "no comment". The canary means that if it disappears, things are very suspicious, and if ask directly about the canary and get a "no comment" then you not only stay very suspicious, you also know they didn't forget. The no comment itself is not a "yes", but from a security point of view you should treat this active lack of canary as if it is a "yes".
Which they referred to as a "practical/tentative yes". Which I think is a reasonable way to describe the situation. It's not "flat out wrong" or "counter-productive".
> so even if it's going to lose you some customers, no comment
You're going too far here.
If you used to comment on something, and you could easily comment on it, and it loses you customers not to comment... you should comment. If you don't, it is suspicious.
I'd hire a lawyer that knows how to deal with them and knows how to say no comment.
I've always felt that the warrant canary is a nerd's gotcha designed to get out of a sketchy legal process (NSLs) and that judges would be very unsympathetic. But IANAL.
At least from my perspective, it is not just a "gotcha" problem or whatever feelings it conjures up in a judge's mind.
When a company, who already has a canary in place, receives this kind of warrants, what _can_ the company practically do to comply with non-disclosure? It seems that lying is now the only option left, if the company must explicitly post a "no, we didn't receive such a warrant".
> This is what "warrant canaries" are for. dont use anyone who doesnt have one
What if they have one like this quarterly canary at privacy-forward "write.as" last updated 9 months ago?
It should be noted with significance if this message
fails to be updated on a quarterly basis.
2023-01-05 21:06:06 UTC
No warrants have ever been served to Write.as, or
Write.as principals or employees.
I formerly worked for a somewhat-older mainstream consumer VPN provider for a few years, to the extent that you can take my word for it, this is not industry-standard practice at least as far as the provider is able to control it.
Commercial VPNs typically run on rental servers -- usually a mix of the major cloud providers and smaller hosting providers -- and in my former company's case, using dedicated hosting (bare metal where available). Steps were taken to restrict access for physical actors, but ultimately, the mantra's always that physical access basically guarantees data access on a long enough timeline if you assume there's a bad actor in the mix.
That said, to the best of my memory, there were no indications of this kind of data siphoning happening without our knowledge, and we absolutely didn't take part in it ourselves knowingly. Occasional requests would come in from various international law enforcement orgs, and every time they'd be replied to with a message about how we don't store user records (which was a truthful reply AFAIK).
The biggest challenge for us was competing with some of the newer actors in the space, taking advantage of deceptive marketing and engaging in (IMO) unethical business practices for the sector:
- Claims of "no logging," even backed up by audits, are only ever point-in-time measurements, and may not reflect reality if the VPN provider approaches the auditors in bad faith (say, with a sanitized code base); a good auditor in my experience will refuse to make this claim in the report
- Claims about having the corporate HQ in one country making it immune from the laws of countries they operate servers in (this is deceptive marketing; failure to comply with laws will get you shut down, and at my old employer we'd make calls about whether to just drop our server presence in a country entirely in response to local laws and political happenings)
- Commercial resale of user data is (allegedly) rampant among many of the newer providers you see constantly plugged on Youtube. This isn't helped by the massive consolidation of the VPN market under just 2 or 3 holding companies.
I won't name names for the companies I mentioned above, but my recommendation is to adjust your threat model from "nation-state level surveillance" to "commercial data resale just like every other web service."
As far as data collection went for my old company: we collected system metrics like resource usage over time, and kept minimal sanitized logs to help diagnose any production issues that'd come up -- basically the absolute minimum amount of data we needed to keep the service operating smoothly. I have every reason to believe this is an industry norm, since otherwise development and troubleshooting would be nearly impossible.
Anyway, there's also the looming "threat" (lol) of HTTPS and encrypted DNS proliferation and improvement making the core use case for commercial VPNs obsolete. I think anyone who's spent a bit of time in that industry realizes that the business model isn't long for this earth as a result, so I suspect many are trying to milk the industry for all it's worth. Personally, I'm all for HTTPS and encrypted DNS proliferation, and I'm also hoping more and more commercial public networks start using virtual private subnets and other device isolation features to make it even harder to abuse coffee shop Wi-Fi.
> Anyway, there's also the looming "threat" (lol) of HTTPS and encrypted DNS proliferation and improvement making the core use case for commercial VPNs obsolete
For a lot of people the core use case is accessing Netflix in a different country!
I'm constantly amazed VPNs get away with advertising that, more specifically the ones that advertise lower prices for subscriptions/products. I guess Netflix themselves won't really care if you switch regions for different shows and might write off discounted subscriptions as alternative to piracy, but the companies that license content by region don't care?
I'm not sure how this relates to the parent comment, but there are free encrypted DNS services out there, though the same can't be said for encrypted and anonymous ones (which is, frankly, a hard problem to solve, realistically speaking).
With encrypted DNS you're just shifting the burden of data privacy away from the local network to the DNS operator. How you determine which operators to trust will probably vary from person to person.
Anyway, the major difference here would be that a VPN will encrypt all traffic in a tunnel, from your DNS requests to your actual followup web requests. On the flipside, you may use encrypted DNS to look up records for a domain that serves content over an unencrypted connection.
You can use dns over https over tor(dohot)[1]. Safer than a vpn if you dont mind your isp knowing you go to tor.
1.https://github.com/alecmuffett/dohot
The other argument is to frustrate network correlation analysis. Many VPN providers have an internal high-bandwidth network (virtual or otherwise); you can send a packet to $VPN_SERVER_X, it sends it to $VPN_SERVER_Y possibly via other intermediate servers, and $VPN_SERVER_Y then forwards it on to your destination.
If you live in a country with detailed data retention laws, this massively changes the shape of the graph: rather than your computer connecting via HTTPS to lots of other IP addresses, it only connects to one, which a large number of other customers do too. The argument then goes that there's enough inherent jitter and generic "chaff" on the internal network to make it very hard to deterministically work out if one of your packets going in to a popular service is the same as that coming out at any moment in time; the greater the traffic of the network and the provider the better the statistical protection becomes as the packets become indistinguishable.
This, and the fact that it represents a giant "no thanks" to dragnet surveillance, is arguably a good reason to just put a VPN on your router (as many people do).
Audits are IMO worthwhile, but end users should be aware of the scope of an audit. In the context of commercial VPN providers, it's usually just a code security audit -- are there any memory leaks? Is sensitive data being passed around a little bit too loosely? Is there some way for unprivileged users to gain privilege escalation by crafting a malicious request against one of your services?
In this sense, they're valuable. As someone working in software, I can figure out if the bugs were subtle or blatant, which is often a good proxy metric for the competence of the team behind the product. Are the same bugs cropping up year after year, even if they've already been previously fixed in other parts of the code? Again, a good red flag to use there.
Audits do not and often cannot cover things like "is the company reselling connection/user metadata to other companies," though, and in most cases consumers will care that there is an audit rather than caring what's in the audit.
I tried to contact the auditor, Altius IT, in order to confirm whether exfiltrating connection data to a third party would result in the audit failure. They replied, but in a very vague way (refused to answer any questions regarding Altius IT's audit of PureVPN's environment). Well, at least they confirmed indirectly that the audit did exist.
I tried to contact KPMG to verify the authenticity of that report, and also asked the same question - "whether deliberate real-time exfiltration of origin IP addresses, assigned VPN IP addresses, connection timestamps, or connected user activities to a third party by PureVPN, without PureVPN (as opposed to that hypothetical third party) storing anything locally in any form of logs, would have constituted a failure of the privacy assessment." Result: no reply from KPMG at all, so I cannot be sure even that the report indeed comes from KPMG and is not a fake.
There are bad auditors, of course. Having had the displeasure of working with KPMG (not in a code-security-audit setting, mercifully), I genuinely don't understand how their staff can be allowed within a ten mile radius of source code.
The ideal way to authenticate audits IMO would be for the audited entity to link back to a PDF or other report hosted on the auditor's site.
Everyone said this about global surveillance before Snowden and yet. I don't see the value in questioning if this is true or not, rather I think we should assume it's true and act as such, isn't that what modern security is about? (see: HTTPS/DNSSEC/DoH etc)
I frankly wouldn't be surprised if it's actually happening.
> but they probably just send a continuous stream of data to the law enforcement / intelligence services or whoever instead of storing it themselves. They can then correctly say "WE don't log"
This has never made any sense to me. I'm surprised this isn't a massive red flag from anyone on HN.
Running a production-grade service with zero metrics and logs? If there's an outage, or even something as mundane as a VM failing to provision, you're telling me that Mullvad developers just shrug and say "well, we can't do anything, because there's no logs!"
I don't use a third party VPN, but if I wanted to, "we deliberately eschew all observability" is not a positive selling point.
Who said they don't have metrics? The VPN servers don't have any storage, but they can still send metrics to an off-machine API, or a different server that does have storage can send requests to the VPN servers and do metrics that way.
Ditto for logging. They claim to not log activity over the VPN itself, but I don't see any claims about not logging more mundane infra stuff like "a VM failed to provision". I think you're arguing here against claims they aren't making.
> but they can still send metrics to an off-machine API
And that would be the next most interesting post, imo. A post about how they metric and log in a RAM-only environment while obscuring or obfuscating the details that could lead to “compromise”. Even if the answer is something so simple like “we regex and discard this out”, I would feel more trusting of their services.
Yes, because it’s a simple service (VPN) that hasn’t added a billion nonesense features over time. You can log VM provisioning and health logs but as long as you don’t log any wireguard logs or user provisioning logs you’re good.
Sending them over the network to where? "We don't store logs" means they certainly aren't being ingested into any persistent storage. I'm highly interested in how one can run time-series queries over /dev/null.
Metrics are mostly by nature anonymous. Things measured are CPU/Mem usage, network rate. Metrics at IP/user level aren't of much value. Companies add country/device type attr. but they can be done without.
