We've found that this decoupling (multi-party) approach is a good way to improve privacy in a bunch of networking contexts -- here's a paper we wrote a few years ago with colleagues at Fastly and Cloudflare on the topic:

https://conferences.sigcomm.org/hotnets/2022/papers/hotnets2...

(Carl from Obscura here)

Oh very cool! I met Chris Wood at the IETF a while back, he's working on a bunch of cool things including Privacy Pass!

I never met Chris Wood before but I remember this name due to him being a co-author of the Private Access Token idea[0]. I haven't heard of Privacy Pass before but it sounds very similar to PAT.

My understanding is that both of these would be very helpful to a VPN (I'm using the word loosely) user. Do you know if the adoption of Privacy Pass/PAT has reduced or mitigated annoyances such as frequent CAPTCHA checks for Obscura users?

[0]: https://www.ietf.org/archive/id/draft-private-access-tokens-...

Carl from Obscura here!

Happy to answer any and all questions you may have

I have never seen any of these two-hop designs (which have been increasingly popular recently) explain why--or frankly even mention that!--Tor was/is somehow wrong for believing its three hops is the minimum required number of hops to achieve the goal of anonymity. Without such an explanation, we frankly must assume that these designs are broken out of the gate due to, at bare minimum--without even having to analyze the situation much--the principle of Chesterton's Fence.

(Irritatingly, this article does link to an option from Tor's documentation, claiming its design is equivalent to a particular mode of Tor's hidden services... but, in addition to being a feature for the opposite side of the service, said documentation explicitly says that feature is "non-anonymous"; and, even still, includes a dire warning about then reusing the directory? Somehow, this feels worse than merely not contrasting their design to Tor at all, as most of these designs seem to do.)

.. Tor .. believing its three hops is the minimum required number of hops to achieve the goal of anonymity.

It's more nuanced than that. Tor's design states the following:

"A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary."

https://svn-archive.torproject.org/svn/projects/design-paper...

There are tons of ways to de-anonymize users, Tor and VPN users alike. Same goes for mixnets. Whether or not an attacker can acquire a user's real-world identity depends on a lot of parameters. The number of network proxy hops is just one parameter.

Having said that, everything else equal, more hops is better than fewer. Then again, if all the user does is log into Facebook with their real-world identity, the number of hops doesn't matter at all. Or it does, because their adversary isn't Facebook, but their local ISP! It depends on what the user wants to protect against. There is a reason the Tor Project went on to build the Tor Browser. They realized that the sort of anonymity that users were looking for wasn't to be had with only the Tor network. They needed to complement the tor client with privacy protections on the application layer.

Regarding network proxy hops there's also this perspective: strong anonymity, low bandwidth overhead, low latency - choose two. This anonymity trilemma teaches us yet again that security and performance / UX is often at odds. If you want security you have to be prepared for inconvenience.

When I setup the DNS over Oblivious HTTP service for Waterfox, one of the most important parts of our setup was that each step was controlled by a different entity, which was also recommended by Fastly. In our instance it went Client (Waterfox/us) -> Relay (Fastly) -> Gateway (Cloudflare).

As far as I’m aware, Apple do the same with Cloudflare and Akamai, each controlling one relay.

Unless I’m mistaken, you’re both controlling the client software (closed source) and the first relay? As far as I can tell, trust is still essentially put into your organisation since you still control two critical parts of the setup. So maybe better than a traditional VPN provider, but still flawed?

Ah interesting, I didn't know Waterfox used DNS over Oblivious HTTP! (I used to run an Oblivious HTTP proxy)

Unless I’m mistaken, you’re both controlling the client software (closed source) and the first relay?

The client software is here: https://github.com/Sovereign-Engineering/obscuravpn-client, we also plan to make reproducible builds of our apps. In fact, I previously led the effort to revamp Bitcoin Core’s reproducible builds system to be [bootstrappable](https://bootstrappable.org/), work that is [referenced by the Tor project](https://gitlab.torproject.org/tpo/applications/tor-browser-b...).

VPN:

As a result, users must rely on their provider’s pinky-promise that none of their data is logged. Yet even a provider that keeps true to its promise can suffer a security breach and be compromised.

2-Party Relay:

This splits “who you are” from “what you do”, meaning neither party can tie your identity to your browsing.

Ok, but... don't users have to reply on their provider’s pinky-promise that the two parties won't cooperate with each other and share their separate data, thereby connecting the dots? After all, the two parties are already cooperating to an extent, so why can't they cooperate even more, either voluntarily or at the command of some hostile government?

In the extreme case that Obscura and Mullvad are forced to cooperate, you're right that this is the case. However, this is strictly (and much) less likely than a _single_ party being pressured or even a single party's infrastructure being hacked.

Another important thing to note: in our App, you can check your connected server’s public key against those listed on Mullvad’s server page, since we use the same servers as Mullvad's normal ones. It would be unheard of for a VPN provider (let alone a trustworthy one like Mullvad) to give their WireGuard private keys to a new partner.

less likely than a _single_ party being pressured or even a single party's infrastructure being hacked.

Since Obscura uses a custom QUIC-based (?) protocol, you'd need to use their custom made (open core) app to pay & register with both Obscura & Mullvad. That means, all your apples are in their app-basket, which is built entirely by a single-party?

Private Relay, otoh, seems like a 3 party setup (Apple, Cloudflare, Akamai)?

See also: https://news.ycombinator.com/item?id=43017140

Ok, but... don't users have to reply [rely] on their provider’s pinky-promise that the two parties won't cooperate with each other and share their separate data, thereby connecting the dots? >

Yes. On the other hand, it does complicate things for the attacker, whether it is internal (the orgs) or external - a 3rd party attacker would have to compromise both orgs instead of one.

After all, the two parties are already cooperating to an extent, so why can't they cooperate even more, either voluntarily or at the command of some hostile government?

Voluntarily: If you look at the business incentives that wouldn't make a lot of sense.

Forced by government: Here I'd say look at the jurisdictions of the orgs.

(disclosure: I'm one of the founders of Mullvad)

Here I'd say look at the jurisdictions of the orgs.

Per Covert Surveillance Act passed in 2020, looks like Sweden (where Mullvad is based) can ask communication providers / website services to secretly add or assist with backdoors?

  ... Where the identity of the suspect is not known, but his contacts are known, or a third party (such as a website which the suspects visits) is known, one can permit secret data reading of these contacts, or the third party, but only in order to identify the suspect. Only (stored) historical metadata, not real-time data or communications and not by means of activation of audio or video surveillance functions can be used for this (section 4b).

https://www.venice.coe.int/files/Spyware/SWE-E.htm / https://archive.vn/LgE7a

I'm pretty sure you're talking about this law, in which case it doesn't apply to us.

https://mullvad.net/en/help/swedish-covert-surveillance-data...

In short, "Mullvad is thus not covered by either the data storage provisions in the LEK for operations subject to a reporting obligation, or the duty to cooperate pursuant to the Covert Surveillance of Data Act."

it doesn't apply to us

This is also what your website says,

  But it could be interpreted contrarily - that VPN services through, for example, encryption via signals that the VPN service itself has power over through agreements with subcontractors, etc. could possibly be seen as an electronic communications service ...

And I'm not just talking about Mullvad VPN (the "electronic communication service" provider), but Mullvad AB, which also hosts websites and builds apps (like the browser and VPN clients), too.

So, is the "law doesn't apply" a fact? If so, may want to reword this bit on your website to make that much clear:

  [Mullvad's] opinion is that the reasonable interpretation is that a VPN service is not to be considered as an electronic communications service based on previous legislative history.

If not, due to the "covert" nature of the Act, if Mullvad was coerced to co-operate with the govt, it seems Mullvad couldn't even publicly talk or hint about it (like warrant canaries, for example)?

I'm writing this on my phone and for whatever reason can't find the passages that you're quoting. Are they in the same article that I linked?

In any case, to my knowledge the law in question doesn't apply to us. If the Swedish government tried to argue otherwise we'd get our lawyers involved.

Having said all of this, I am concerned about National Security Letters and similar concepts. Technologies like reproducible builds, transparency logs, and remote attestation can help there.

Thanks.

Are they in the same article that I linked

https://mullvad.net/en/help/new-law-for-electronic-communica... / https://archive.vn/86hGz

to my knowledge the law in question doesn't apply to us

Fair. This isn't the official Mullvad position, then (which is that the law may apply)?

The "Communication provider" part aside, another source (quoted above) makes it explicit that backdooring "websites" (Mullvad has a website) are fair game, btw.

If the Swedish government tried to argue otherwise we'd get our lawyers involved

I don't doubt you would. Given the "covert" nature of the Act, Mullvad's arguments & Sweden's counter-arguments and the outcome from it (backdoors, compromises, coercion etc) will be kept a state secret. That is, there doesn't seem to be a way for the public to independently ascertain the claim that the Mullvad did fight and indeed "the law didn't apply"? [0]

reproducible builds, transparency logs, and remote attestation

Much needed (:

Per Mullvad's posts, the Act seems to grant wide-ranging powers to Swedish authorities, including installing hardware & other sorts of physical compromises (which no amount of software mitigations would thwart, I don't think).

[0] Focusing on the premise: "Forced by government: Here I'd say look at the jurisdictions of the orgs."

Fair. This isn't the official Mullvad position, then (which is that the law may apply)?

I'm pretty sure our official position is that it doesn't apply, rather than it may apply. Note that the article on our website that I quoted is more recent than the one you quoted. I can't find a more recent legal opinion than that.

Regarding backdooring websites, that's interesting. I'll have to ask someone about that. Thanks.

the outcome from it (backdoors, compromises, coercion etc) will be kept a state secret

I am not a legal expert, but I'm pretty sure you're wrong. The first-order outcome would be a court case that says the law applies to VPNs, or not. The second-order outcome would be secret coercion in a specific criminal case, or nothing. The first-order outcome would be public. Interesting question though. I'll have to ask about this too.

Much needed (:

Yes. :)

It might interest you to know that I've spent the past six years working on things like that. My role at Mullvad since several years is only strategic, as I spend almost all of my time on applied research. See glasklarteknik.se and tillitis.se.

(which no amount of software mitigations would thwart, I don't think)

Physical security is hard. However, I see no reason to limit ourselves to only software-based mitigations.

Well they do cooperate with each other. They are partners, working together to provide the service, and sharing the cost. But you have to trust that if they are trying to attack you, they do it separately...?

Ridiculous, as you point out this doesn't increase my trust at all.

Hey! Let me know if this answers some of your questions :-)

https://news.ycombinator.com/item?id=43017755