Even with multiple assertions the test failure reason should be quite clear as most testing frameworks allow to specify a message which is then output in the testing summary.
E.g. `assertEqual(actual_return_code, 200, "bad status code")` should lead to output like `FAILED: test_when_delete_user_then_ok (bad status code, expected 200 got 404)`
It's a great topic :) and with so many interesting ideas and constructions.
In my comment I was trying to make the more general statement that is (likely) impossible to achieve strong metadata privacy (or unobservable communication) without cover traffic.
However, metadata privacy is a bit of a spectrum (see my other comment above).
Adding latency at the relays/mixes already helps to make it harder for an adversary to correlate the traffic as their measurements get more noisy. This then very quickly gets to a level where we have "practically unobservable communication" as the signal to noise ratio is very low.
Similarly, this holds for cover traffic. In an ideal scenario the rate of the outgoing traffic is fully independent of whether one communicates or not. In a less ideal scenario we just add some other requests on top (e.g. a random browser bot on Tor) to create noise. In some cases this might be good enough. However, it won't satisfy any theoretical definition of unobservable communication which indicates that an observer can mitigate the noise by extending their observation over a long-long time.
Hi paper author here :) thanks for the great comment. I'll add some thoughts for other potential future readers:
Generally, almost every protocol that does not do some form of traffic shaping is vulnerable to traffic analysis.
If an adversary just wants to confirm their suspicion that A talks to B, they can correlate the outgoing traffic patterns of A with the incoming traffic patterns of B. Doing this over a multiple rounds they can increase their confidence. This is something they can do on Signal or even between two Tor participants.
Note that starting with such a suspicion is easier than finding out _who_ A is talking to. In that case they'd need to either (a) follow network messages through the network or (b) collect traffic patterns from all potential communication partners. That's why Tor is nevertheless effective in hiding which websites you visit.
Thanks also for listening other anonymous network designs! There are many really interesting ones. And for some (e.g. DC nets) you can get broadcast that is only depending on the total network size and not the group size.
We chose Loopix because we were looking into mobile devices. Here, Loopix has the interesting concept of provider nodes which (i) can store messages if clients are offline and (ii) regulate access to the network e.g. against a fee to make it commercially viable. Also, Mix networks are very easy to scale up by simply adding more nodes.
When we tried to put decentralised collaboration (e.g. CRDTs) on top of Loopix we hit the problem that distributing the edit updates was rather inefficient. That's basically the problem from which the Rollercoaster idea developed.
Hi, paper author here :) thanks for providing a great answer to that question. I missed that the post/paper made its way to HN.
One thing I'd add for the benefit of the discussion is that the term "metadata privacy" is rather fuzzy and different people mean different things with it. That's where some confusion can come from.
I like to use "unobservable communication" to refer to absolute metadata privacy where no single bit of information is leaked - i.e. an adversary cannot even tell if any communication is happening at all at any point in time.
For most real-world use-cases and threat models, this absolute privacy goal is often a bit unpractical because it comes with high latency or bandwidth needs. For instance, Tor is popular and practical because they prioritise latency and throughput with a careful threat model that excludes a global network adversary. However, the right threat model really depends on the individual use-case and circumstances.
I think that Loopix (as linked above and what we use in our paper) does a great job in quantifying the achieved anonymity. See also https://bib.mixnetworks.org/pdf/serjantov2002towards.pdf for some more Information Theory in the context of Mix networks.
E.g. `assertEqual(actual_return_code, 200, "bad status code")` should lead to output like `FAILED: test_when_delete_user_then_ok (bad status code, expected 200 got 404)`