Thanks for your question - it is a very interesting one! I would personally refer to what Tor uses as ‘padding’ traffic not ‘cover’ traffic.
The two types of padding traffic Tor uses are:
Connection-Level Padding: it is a 1-hop padding between the client and its guard node. It is used to hinder traffic analysis by ISPs and surveillance infrastructure and helps obscure NetFlow-style traffic monitoring. And my understanding is, that this padding is only sent when no real traffic is being sent. It does not add extra padding on top of real traffic. So while it prevents ISPs from knowing exactly when the user is actively sending or receiving data, it does not prevent advanced traffic analysis or hide communication patterns. It can prevent some basic forms of flow-based tracking, but won’t protect against advanced traffic analysis (eg one which utilises machine learning). Also, as a side note: The Guard node can distinguish padding packets from real traffic, meaning the Guard sees the exact communication patterns of the user.
Circuit-Level Padding - this padding traffic is used to obfuscate client connections (handshakes) with hidden services. It mainly targets the first 10 cells (packets) of a circuit setup, making onion service circuits look more like general circuits. So it is only applied selectively in specific cases and does not provide comprehensive traffic analysis resistance for general Tor traffic. Once the initial handshake is complete, no further padding is added I believe, meaning that traffic patterns within the Tor network remain exposed.
We define cover traffic as a type of traffic whose primary purpose is to obfuscate a user’s communication patterns, making even advanced traffic analysis difficult. Additionally, in mix networks, cover traffic helps increase the anonymity set by blending user traffic with decoy traffic, making tracking much harder.
thanks for pointing it out, it might be a good idea to clarify this table in a blogpost indeed
let me know if you have any more questions about that!
What price ranges are you considering for Systweak VPN in March, and will there be an option to include phone VPN access in existing multi-device plans?
very good, Honestly I would just also add MullvadVPN comparison indepedentm of general privacy vpns with the ticks as follows, because they do have different things than traditional privacy vpns, in this case:
Unlinkable payments (mullvad supports monero and other crypto and cash)
Open source (Mullvad VPN · GitHub)
Noise (tick whatever’s accordingly here). (DAITA: Defense Against AI-guided Traffic Analysis)
Independent Operators, hard to say but they did partner with Obscura so probably counts as such? (Mullvad has partnered with Obscura VPN | Mullvad VPN)
it’s a 2 party multi-hop when enabled.
but overall it’s an improvement!
(but yes the rest is X)
Edit: after some html inspect shenanigan, I was thinking something like this:
I think Mullvad is doing some great work towards advancing the privacy for their users! As for DAITA - we looked at it when they announced it. Looking at the code, they implemented the addition of cover traffic with the Maybenot framework. Doing a bit of a deeper dive back then showed that they used four different state machines, but in all cases, the cover traffic patterns were quite predictable and could be easily filtered out with simple traffic analysis. I haven’t checked recently, so I can’t say whether they’ve improved it, but back then, it was doing very little to hinder traffic analysis. And also it wasn’t by default - you have to enable it in settings.
Regarding the independent operators model with Obscura: I think it is a very nice step towards decentralisation that Mullvad partnered with Obscura, as otherwise Mullvad’s 2-hop mode wasn’t really decentralised because they control all the nodes. Pairing with Obscura adds a bit of decentralisation indeed, as in theory you’re routing traffic through 1 node controlled by Obscura and 1 controlled by Mullvad.
Hence, the claim here is that ObscuraVPN cannot decrypt your traffic, and Mullvad’s servers cannot see your original IP address - and cannot correlate your IP with your activities. This is true under the assumption that the two services do not collude—which, of course at this point, is based on a pinky promise as those two companies already collaborate
Also, worth noting is that since the Obscura app encrypts traffic using WireGuard for the Mullvad exit server before sending it over QUIC to the Obscura entry node, there is no separate WireGuard tunnel between the Obscura app and the Obscura entry server (at least that’s my understanding of their design). This setup requires the client to be aware of both ObscuraVPN and Mullvad’s servers. Specifically, my device must know the public WireGuard key and endpoint of the Mullvad exit server before it can establish a connection. Because my WireGuard session is end-to-end encrypted between my device and Mullvad’s exit node, Mullvad does see my WireGuard public key. If I reuse the same key across multiple sessions, Mullvad could track my activity by associating different connections with the same key. I’m not sure they rotate the long-term public-private WireGuard key pairs between sessions.
Please add Qubes OS support, namely being able to run the nym app in a qubes proxy vm. Essententially the proxy VM acts as a gateway for the Internet. Essentially the same design as a whonix workstation and gateway. If this isn’t possible to do with your app, please allow for users to use wireguard configuration files. Please note that both mullvad and ivpn support this usecase with their native apps.
That’s not how it works. You don’t just install the Linux client and suddenly it can route traffic to other VMS. There are certain qubes specific scripts that need to be configured that work differently for each VPN provider because their clients are all different.
Thanks for the review. The table will always be an oversimplification. Each cell actually deserves a footnote.
Thanks to the “zk-nyms” (zero-knowledge proof-based access), NymVPN users’ online activity cannot be linked to their payment data (i.e. personal data). This is valid across all payment methods. Even for people paying in card (one might find out they are NymVPN customers, not what they do online).
For the rest, see @ania’s comments above regarding DAITA and operators.
Point taken, let us check with the team and get back to you.
To register with the 2 WireGuard gateways, the app has to send 2 “zk-nyms” over the mixnet. Basically cryptographic “entry tickets” that are shown to each gateway to prove right of use. We can improve the process of getting WireGuard config files back, but it’s not a 1-1 with what other VPNs allow.
For now, any use case that can accommodate high latency and average speeds: Messaging, email, crypto transactions. Basic browsing is also fine. We do have a long list of improvements to make the mixnet faster, but it will never (cannot) offer a VPN-like experience (given the 5-hop setup, packet delays, etc.).
Thanks for reporting. I’ve pinged the Brave team. It’s also been reported with strict NextDNS settings. We’ll see if the Hagezi TIF allowlisting fixes it.
(mullvad supports monero and other crypto and cash)
