Future Work

Our experience designing Free Haven revealed several problems which proved to be too hard to solve at this time. We state some of these problems here and refer to the first author's thesis for in-depth consideration [12].

Deployed Free Low-Latency Pseudonymous Channel:

Free Haven requires pseudonyms in order to create server reputations. The only current widely deployed channels which supports pseudonyms seem to be the Cypherpunk remailer network [30] and ZKS Freedom mail. These networks run over SMTP and consequently have high latency. This high latency complicates protocol design. In addition, Freedom mail requires payment and is not yet open source. Payment may be complicated for international users or may allow participation to be traced, and open source facilitates peer review of the implementation.

Accountability and Trust:

We found it extremely difficult to reason about the accountability in Free Haven, especially when considering the ``buddy system.'' At the same time, accountability is critical to ensuring that documents remain available in the system. Future work in this area might develop an ``anonymous system trust algebra'' for formally reasoning about a servnet node's reliability based on various circumstances which would allow us to verify trust protocols.

Modelling and Metrics:

When desiging Free Haven, we made some choices, such as the choice to include trading, based only on our intuition of what would make a robust, anonymous system. A mathematical model of anonymous storage would allow us to test this intuition and run simulations. We also need metrics: specific quantities which can be measured and compared to determine which designs are ``better.'' For example, we might ask ``how many servers must be compromised by an adversary for how long before any document's availability is compromised? before a specific targeted document's availability is compromised?'' or ``how many servers must be compromised by an adversary for how long before the adversary can link a document and a publisher?'' This modelling might follow from the work of Gulcu and Tsudik [20], Kesdogan, Egner, and Buschkes [24], and Berthold, Federrath, and Kohntopp [5] which apply statistical modelling to mix-nets.

Formal Definition of Anonymity:

Closely related to the last point is the need to formalise the ``kinds of anonymity'' presented in section 3. By formally defining anonymity, we can move closer to providing meaningful proofs that a particular system provides the anonymity we desire. We might leverage our experience with cryptographic definitions of semantic security and non-malleability to produce similar definitions and proofs[19]. A first step in this direction might be to carefully explore the connection remarked by Rackoff and Simon between secure multiparty computation and anonymous protocols[37].

Usability Requirements and Interface:

We stated in the introduction that we began the Free Haven Project out of concern for the rights of political dissidents. Unfortunately, at this stage of the project, we have contacted few political dissidents, and as a consequence do not have a clear idea of the usability and interface requirements for an anonymous storage system. Our concern is heightened by a recent paper which points out serious deficiencies in PGP's user interface [45].

We consider the above to be ``challenge problems" for anonymous publication and storage systems.