Remember — (from their own article announcing these servers):
> Running the system in RAM does not prevent the possibility of logging. It does however minimise the risk of accidentally storing something that can later be retrieved.
This doesn’t mean you can’t be logged. Running in RAM just means that any system level logging is transient and largely accidental. But if there were a need to specific logging, data could always be sent to a different node with disks. From Mullvad’s point of view, there is a reliability benefit to having diskless nodes. But from a privacy point of view, your access could still be logged, if required. But it would probably require more “active” monitoring than “passive”/accidental logging.
If government comes to you and says you must send data here and there or log this and that and you must not tell anybody about it, then you have to comply and you can't do much about it even with your best intentions. I don't think it should be like this but as far as I understand it is the current state of affairs.
Even if they shouldn't be able to force you to do some things the best you can do is take them to court, still completely outside public eye, and they can provide some plausible reasons regarding say national security which are likely pretty much impossible to verify.
> government comes to you and says you must send data here and there or log this and that and you must not tell anybody about it, then you have to comply and you can't do much about it
Eh, this is unsettled law [1]. If you have logs and the U.S. asks for them, you must turn them over. But it's unclear the U.S. can compel you to write new software.
> Swedish authorities have no legal right to force developers to write any software.
“A party which conducts activities which are subject to a reporting obligation pursuant to Chapter 2, section 1 of the Electronic Communications Act (2003:389) ("LEK") is obligated, upon request of the enforcement agency, to cooperate in connection with the enforcement of covert surveillance of data.”
> 2. What significance does the law have for the Mullvad service?
> Mullvad cannot be made subject to a duty to cooperate in connection with the enforcement of a decision authorising covert surveillance of data since VPN services are not an activity subject to a reporting obligation pursuant to Chapter 2, section 1 of the LEK.
> If government comes to you and says you must send data here and there or log this and that and you must not tell anybody about it, then you have to comply and you can't do much about it even with your best intentions.
Even if you go the nuclear option, you might risk being arrested:
> Levison said that he could be arrested for closing the site instead of releasing the information, and it was reported that the federal prosecutor's office had sent Levison's lawyer an email to that effect.
> Even if you go the nuclear option, you might risk being arrested:
Surely, in a free society, you are free to close down your business for whatever reason you want? Someone might feel like the business is no longer fun to run for X reason, it just happen to have coincided with law enforcement wanting to add wiretaps.
He is free to close down his business//not take on new customers, but that doesn't change his non compliance with a warrant for previous customer information.
Much like you are free to destroy your belongings in general, but not once their is or there will be a legal order for their surrender (I.e. Destruction of evidence).
Regarding printing it in 0.5 font, I don't think this kind of passive-aggressive rebellious act accomplishes anything, and actually highlights how powerless he is. It caused extra work and frustration for the poor guy who got handed the job of transferring the private key from paper, but nobody else was bothered. His shutting down the service was much more of a stance.
There is also the distinct possibility that a government would just hack your system secretly if they thought it was a worthwhile target. I would assume that is the case for these well known VPN companies that operate outside US jurisdiction. The actual attacks that might be used are a different discussion but I don't think this is a remote possibility. I think it's quite likely the US government would target companies like these.
Do you know any countries where this actually works? Usually if a powerful country wants something from a small supposedly independent country, this doesn't really apply anymore. One well documented example is how the US lobbied Sweden into raiding The Pirate Bay (https://torrentfreak.com/pirate-bay-investigator-to-cash-in-...)
The Pirate Bay was openly defying copyright as defined in just about every country except Sweden with barely any legitimate use. It’s a household name for lawlessness.
That’s really not comparable to a vpn service if a significant proportion of users are using it to legitimately protect against privacy invasion when using an open WiFi network.
You don’t need to actually know, it’s enough to extrapolate from their own advertising material and the general public sentiment.
Besides, if it’s “terrorism” and “child pornography” the vpn endpoints would attract attention quickly enough. It’s not like a VPN is a magical anonymous entry into the internet, it just changes the location and mixes your traffic with other customers’.
> You don’t need to actually know, it’s enough to extrapolate from their own advertising material and the general public sentiment.
I'm pretty sure if someone is determined enough to shut down a service or force them to add logging they don't really care about the marketing material of said service. Just like EncroChat didn't brand themselves as phone brand for organized crime.
I there's an entity that wants WireGuard to add logging they'll make up a "terrorism" reason and all the existing "anti-terrorism" laws will open many doors to do just that.
Sure but with no evidence either way the task of proving it to a judge, politicians or the general public could be done pretty effectively using the companies marketing material or general public sentiment.
Encrochat was never really taken down, it took itself down because it was cracked and so lost its sole asset, the secrecy of the communications.
I don’t think that Apple “caved” per se, but the authorities seem to have found a path to what they want, and somehow Apple hasn’t been able, willing, or motivated to close those holes.
Apple also tweaked things like iMessage to make that data available in the cloud (ie available via subpoena or warrant) in most common scenarios.
Tor isn't the almighty all-in-one-solution one might think it to be. Other OPSec measures need to be take in addition to Tor. FBI agents tracked Harvard bomb threats despite Tor [1].
Admittedly from the article: "used two separate anonymity tools to cover his tracks — the routing service Tor, which covered his web traffic, and the temporary mail service Guerrilla Mail, which offered a one-time email"
Then they noticed that "that the originating IP address would have been revealed in the email header, which would have indicated Tor usage"
And from there "agents checked to see if anyone had accessed Tor through the local wireless networks. That led them to <culprit>, who promptly confessed."
Doesn't sound like they even had to engage with Tor infrastructure or Guerrilla Mail backends, just 'hmmm did a student use Tor, oh some did, let's check them out in full FBI livery' which freaked the kid out and he confessed.
It's easy to check if an IP is a Tor exit node, but unless you happen to also have egress logs it's still a thornier problem to de-anonymize without heavy resources.
> but unless you happen to also have egress logs it's still a thornier problem to de-anonymize without heavy resources.
It's an easy problem if you control the majority of the nodes. All it takes is throttling traffic on an exit node and watching which inbound traffic is affected. It is cheap for the US to fund the operation of all Tor nodes in return for the massive intelligence boost it offers.
At the end of the day, it's a DARPA project originally, I'm sure the US Gov't has been _heavily_ invested in monitoring it for a while. Still I'd argue when doing anything on the web the behemoth that is the US could probably flex some of that spending muscle to levy massive resources.
However FBI tracing bomb-threat is probably still not using NSA-level resources... given the whole not our citizens wink wink thing.
> given the whole not our citizens wink wink thing.
Intercepting encrypted domestic communication is fair game as far as the TLAs are concerned. They also always have the option of routing domestic traffic outside the country to make it "foreign origin".
Not saying that's not laudable. But any company beholden to any government that has any law with the wording along the lines of being able to get the logs of citizens using it and with a court system that can enforce such judgement then the only outcome I can see is:
1. Something happens (terrorism/cpam/insert-bad-thing-here) and a court case ensues and the defense says we don't have logs as we pipe them to /dev/null and the judge says haha nice try here's a fine that puts you out of business or worse jail time.
No matter what they think and what they advertise. They use the same silicon, same motherboards, same designs as everyone else. So, they have all the risk that everyone else has, no matter the implementation. You don't know jackshit about the silicon and the firmwares that control them.
Mullvad is not bad, but until average people don't have the means to create their own silicon in a cheapo way, you are just farting in the wind.
VPNs were never a technology to secure your data from everyone. If you want to change your apparent location, bypass LAN restrictions, or hide what you're specifically looking at from your LAN admin, those are all perfectly adequate use cases for a VPN.
If you're doing any sort of activism, well, Darwinism applies here very well.
This view is probably a little too cynical. Are some providers honeypots? Sure. But I'd wager that most no-log VPN providers are earnest in their claims and intent.
The problem, of course, is that, as Proton demonstrated, any "no log" provider can be compelled to begin logging for a specific customer by any random corrupt privacy-hating judge.
I am a huge fan of technical solutions to tyranny, but what we need is a VPN provider that provides a jurisdictional solution. Set up the operating corporation in a Non-FVEY jurisdiction with no MLAT, and run all your edge nodes in colos where you install your own hardware with tamper detection switches.
That way, when the Feeb decides to make you an Enemy Of The State, there's no local judge or LEO required to follow an MLAT request, and when they try to go after the edge node providers that are in their jurisdiction, any attempt to tamper with the box will just brick the device.
At that point, the only real option left is for the CIA to smear the country's leader as a "dictator" and covertly fund a coup.
This is a common argument, but if you assume that a VPN works with the agencies to begin with, a staged public confrontation with the agencies is great for publicity.
This is such an underrated test - the response to a court order is; here is every piece of information we have and can hand over. (Ironically any response at all to a court order triggers hysteria amongst the 'privacy' cosplayers out there)
Even without network logging, the hypervisor can still access the memory of the VM, parsing the kernel process and paging structures to read process memory, which can store transient logging information.
Things like AMD SEV/SEV-ES are designed to mitigate that aspect, the implementation of which can be proven to end-users of the VM by remote attestation.
That's not necessarily the case, vendors have VMs that can spin up with encrypted memory so that only the person spinning them up can see what is in the memory. All AMD and Intel processors have capabilities for this. Just in case you didn't know.
I get the immediate appeal of “open source servers that run from RAM”… but it’s the same thing as always, you just have to believe your VPN provider.
There is just no saying that they don’t swap gear out for the auditors or for the disk less servers or whatever it is.
I like that they say the right things. But I think the current models of Facebook and Google show just how much money there is in data, so it’s just faith that the VPN provider won’t fall to temptation.
Mullvad is more trustworthy that most, and possibly more trustworthy than all other public VPN providers. They have a good history, and are regularly audited: https://mullvad.net/en/blog/tag/audits/
Don't get me wrong, you still have to believe them. But they're easier to believe than others.
In short: auditors audit providers against their own privacy policies. If there is a loophole, the result, with some auditors, might still be a legitimate "pass" - e.g. because exfiltration is not logging, and the privacy policy says only "we don't log".
P.S. Mullvad's privacy policy falls into the same bucket: "we never store any activity logs of any kind". Sending data to a third party who stores it would be 100% compliant. Mullvad, please fix the wording.
We are talking about different documents. I mention the privacy policy, which contains a "leaky" wording, likely unintentionally. You mention the audit report that plugs the leak and confirms that Mullvad protects customer data even better than written in their privacy policy.
Mullvad is pretty much the only VPN provider saying the right things and doing the right things. They actually publish open source code and articles backing up their statements.
Ontop of that many of us here in Sweden know people at Mullvad and can attest to them being conscious of privacy issues.
> many of us here in Sweden know people at Mullvad and can attest to them being conscious of privacy issues
Me for example, I can vouch for them if that matters to anyone, but it's the same problem isn't it, if people can't trust Mullvad on their word, why should they trust two random HN users they've never met or conversed with before?
Yup. But you can use crypto or mail cash to Mullvad without your name attached, and then just multihop to them as an endpoint, and it's about as secure as a VPN can be.
It is not pointless, it is a huge practical win. That means that you don't have to trust your VPN to have a reasonable guarantee that adding VPN won't reduce your privacy (depending on your goals).
As many VPNs are sketchy (and even the best one might get bought out or otherwise get compromised) relying on one might seriously reduce your privacy. Especially considering that in many jurisdictions your ISP has much higher legal requirements on integrity and privacy.
But if the VPN don't know who you are the absolute worst case is that you fall back to your ISP. Whether that is good enough for you is something you have to check against your threat model. But in a world where adding a VPN in many cases threatens to reduce your privacy it is massive win.
"fall to temptation" implies they were legitimate actors in the first place.
Most VPNs are run by small and relatively non-transparent private companies. It would be trivial and in fact the obvious thing to do for law enforcement and similar agencies to setup VPN companies and advertise them to their targets.
ISPs are actually more transparent and their business model does not fundamentally relies on exploiting customer data.
> ISPs are actually more transparent and their business model does not fundamentally relies on exploiting customer data.
And yet they do, largely because many people _can't_ vote with their dollars. I can move which VPN provider I use. Also, VPN's are a big benefit on filtered wifi if that's something you have to deal with.
> ISPs are actually more transparent and their business model does not fundamentally relies on exploiting customer data.
To be fair this applies to VPNs too. Their customers give them money, and that should make their business sustainable without needing to spy on people.
To be honest I trust Mullvad way more than I trust my ISP not to sell my DNS queries.
I was going to say that theoretically this was something that trusted computing can solve, but then I realized even if you could guarantee that the server was behaving as advertised (ie. diskless, no log), there's nothing preventing the provider from putting a middlebox in front of the server to log all packet flows. From there it's fairly trivial to deanonymize every connection through traffic analysis.
The provider doesn’t have to do anything. Their upstream transit provider probably has a span port plugged directly into the NSA. Which is what was happening with Room 641A over a decade ago.
On one hand, they won’t be able intercept encrypted VPN traffic, but on the other, they are definitely collecting IP addresses, timestamps and traffic heuristics. With enough resources to pick out patterns and bulk collection on both sides, encryption and logging might not even matter.
I bet some kind of blockchain based trust can solve some issues ,for eg , hardware ownership delegated with blockchain trust .It will add p2p ownership/rent of hardware
Wouldn't there be a clear performance difference between a RAM based and disk based (even if it's NVMe SSD) machine? If so, isn't that something you can routinely/programmatically authenticate?
I doubt there would be any detectable difference. Logging to disk can easily be done out of the hot loop, and I doubt any service with disks has any relevant memory in swap/page file.
The point of the RAM-only server is not that it ensures that everything is operating from RAM. Everything is operating from RAM already even on servers that have attached disks. The point is that RAM-only means there is no intentional or even unintentional logging to non-volatile memory or storage. Think of it as a physics enforced capability system (no disk is physically connected).
Fair enough on there not being a performance difference. I suppose you could run an IPMI or redfish query (assuming they expose it to you) to get hardware specs on the server to see if any storage is physically connected?
I guess there's a larger question - is it possible to construct a completely transparent architecture for customers who are trustless in you as a service provider?
The CPU essentially signs running code and API responses using a key that only the CPU manufacturer knows. That way, you can verify that your cloud services are running the binaries you told them to run.
Note the long list of vulnerabilities on that page and the removal of this feature from desktop CPUs. (Let’s be real, its only use case on desktop is DRM)
I mean, you need some kind of trust, somewhere. Maybe you don't have to trust the service provider, if it provides some type of TPM attestation traced to the key of someone you do trust.
On the other hand, they have physical access. Even with efforts at remote attestation, etc, the game is lost.
> RAM-only means there is no intentional or even unintentional logging to non-volatile memory or storage
Let’s say worst case, there is an unintentional leak to a another machine, pretty likely that machine has a disk. These are very obviously highly connected machines. Sorry, but it can never be anything but faith - which is fine if you have or, or chose to.
I don't have a lot of faith in such things, at base, you always have to trust the provider as people or an organization. I'm just describing what this technical measure is and what it is not. It's also not a silver bullet that on its own means you can trust their service enough for your needs -- no purely technical measure can do that.
Forwarding packets doesn't need much if any disk i/o, so the server will be running mostly from RAM either way, even if the hard drive isn't physically unplugged.
I think that low latency can act as a proof of being close and fast, but once the apparent network latency goes up how do you know that server times are low if the server can claim the time was spent on the network?
I think the only thing that would give more trust is a remote attestation setup similar to GrapheneOS[1] since it's the only way to prove that servers are running the software they publicly say they are.
The configuration would have to be run at the hypervisor level, so that logging couldn't simply occur by nesting the server in a VM then logging that.
I read this differently than intended. For the life of me, I couldn’t figure out why RAIDs were so troublesome. I mean, yes, they can be a little slow, so running in RAM would be much faster.
Then I got it. Raid. Not RAID. Made so much more sense.
Running from memory is no big deal. You gain all and everything like a normal system and can still log persistent to some lokal disk or a remote central log service as it is quite common.
For example, all Ceph storage nodes bootet with croit.io run in RAM and have no OS installed. But you still have all logs and everything available right out of the box.
A trick I've used in the past for secrets on cloud providers: store them in "/dev/shm". Requires init after boot from a trusted source of course.
It's absolutely not foolproof but reduces the odds of them ending up on a SAN somewhere where they might be found by someone scanning free space or gaining direct access to an iSCSI bus or similar.
Adding to this for completeness sake, if using tmpfs such as the default /dev/shm mount, one must ensure that swap is either encrypted or disabled as tmpfs is swap backed and data not being actively accessed/written can end up in swap on disk.
Lets say, hypothetically, that there did exist some trustworthy VPN provider, one that behaved in a way that you would approve (where, if you had unlimited time and access to the internal operation of the provider to evaluate it, then you would eventually be convinced that it's "good", as good as reasonably, humanly possible). So assuming it exists, what would it look like? What would you see that would be positive or negative signs?
Sweden is going to join NATO soon. So do not expect VPNs operating from their teritory and under their law to be any different then the rest of Europe, as it was before.
Meh, I generally agree with the laws of my country and of the EU, so I don’t really care if they can obtain a warrant to wiretap me. I prefer to live in a society where law enforcement can be effective (with checks!) than one where bad things can happen with zero negative consequences.
They do two hops, first to an Apple-controlled server, then to the “second relay” which is operated by Cloudflare in a lot of cases. Encryption is terminated at the second relay.
So Cloudflare sees the content (or whatever is visible in a TLS stream), and Apple sees your real IP, but neither can know both without collaboration.
Not exactly. WARP hides your content and IP from anyone but the destination website. The website can still track the user. Apple mixed it with own relay such that neither Apple nor Cloudflare can track the IP and content simultaneously.
It’s mostly an anti-tracking feature. But also now government needs cooperation from two companies.
On another note, WARP is a VPN. But Mullvad is preferred to WARP, because Cloudflare most likely logs connections for some time.
I would trust real TOR much more than Apple's pseudo-TOR. They control all the entry and exit nodes so correlation attacks are quite viable.
Might as well chain two VPNs if you want a TOR-like experience without slowdowns. Bonus feature is that you can rotate providers.
Not really equivalent. There are possible attacks based on: key generation process, stored data correlation, access patterns, etc. You're much safer if you don't store anything in the first place.
> Running the system in RAM does not prevent the possibility of logging. It does however minimise the risk of accidentally storing something that can later be retrieved.
This doesn’t mean you can’t be logged. Running in RAM just means that any system level logging is transient and largely accidental. But if there were a need to specific logging, data could always be sent to a different node with disks. From Mullvad’s point of view, there is a reliability benefit to having diskless nodes. But from a privacy point of view, your access could still be logged, if required. But it would probably require more “active” monitoring than “passive”/accidental logging.
https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...