\documentstyle[11pt,titlepage,doublespace,fullpage,epsf,amssymbols]{article}
\author{Todd Kamin}
\title{The Free Haven User Interface: Methods for Inserting and Retrieving Information Stored in Free Haven}
\begin{document}

\begin{singlespace}
\maketitle
\end{singlespace}

\pagenumbering{arabic}
\setcounter{page}{1}

\begin{singlespace}
Todd Kamin (tkamin@mit.edu)

6.199 AUP Final Report

May 21, 2000
\end{singlespace}

\section{Motivation: The Free Haven User Interface}
The Free Haven Project is a distributed, anonymous, data storage haven:

% following quote was taken from freehaven.tex
\begin{singlespace}
\begin{quotation}

\input ./abstract
\footnote{Dingledine, Roger, ``The Free Haven Project: Design and
Deployment of an Anonymous Secure Data Haven,'' Massachusetts
Institute of Technology Masters Thesis May 2000: 3.}

\end{quotation}
\end{singlespace}

The motivation for the user interface is to facilitate user
interaction with the Free Haven system -- to allow people to store data and
retrieve that data.

\section{Introduction}

The core infrastructure of the Free Haven Project is built upon the
idea that documents are split into shares.  Documents are split so
that a number of servers each hold a share.  When a user wants to
reconstruct the file, a certain number \emph{k} shares are required.
One of the larger challenges facing the implementers of this
infrastructure is designing a robust protocol that governs the trading
of document shares 1 for 1.  The trading of shares occurs through a
``mixnet'' that preserves the anonymity of the two servers trading
shares.

The user interface has three main goals: to allow anonymous insertion
of documents into the network, to allow the anonymous retrieval of
documents from the network, and to provide an easy to use interface
for performing these two operations.  This paper first describes the
composition of a share.  Then an overview of the user interface is
presented.  The user interface is next described in detail, including
the insertion and retrieval of documents.  Then, the current
implementation of the user interface is analyzed regarding ease of use
and success at providing anonymity.  That analysis is then translated
into a discussion on the future work needed in the user interface.
Finally, some related works are presented.

\input ./fh-design-share.tex

\input ./fh-design-ui.tex

%\input ./fh-impl-ui.tex

\section{Analysis of Current Implementation}

One of the weaknesses of the current implementation of the user
interface is its heavy reliance on one servnet node, currently
http://freehaven.net.  That node is currently used to publish all
documents and will be hereafter referred to as the ``publishing
server.''

Secondly, an uploaded document is sent in plain text from the user's
browser to the publishing server.  Sensitive materials such as trade
secrets, etc. may be grabbed by any operating packet sniffers.

\subsection{Ease of use}

The current implementation of the user interface to Free Haven is
fairly easy to use.  Inserting a document into Free Haven is simple.
The user simply finds the correct form, enters the document, picks the
time to expiration, and then clicks submit.  The user interface takes
care of the rest.  Retrieving a document is more difficult than
inserting a document.  The user must first set up an appropriate
remailer reply block.  Then, she must place the request into the
system using the user interface form (this step is as trivial as
inserting a document).  Finally, the user must manually reconstruct
documents from shares arriving in the mail.

\subsection{Anonymity}

One of the main goals of Free Haven itself and this user interface is
to provide ``anonymity.''  Several different agents are involved in
the publication of a document, and anonymity can be defined for each
of these agents.  The Free Haven master documentation defines:
author-anonymity, publisher-anonymity, reader-anonymity,
server-anonymity, document-anonymity, and
query-anonymity.\footnote{Dingledine, Roger, ``The Free Haven Project:
Design and Deployment of an Anonymous Secure Data Haven,''
Massachusetts Institute of Technology Masters Thesis May 2000: 9-14.}

%\footnote{The careful reader will note that ``query-anonymity'' is
%defined in the master documentation.  Query-anonymity means that
%each server should not know which document was served for a given
%request.  Query-anonymity is only defined within each Free Haven node
%and is outside the scope of the user interface.  The user interface
%can neither preserve nor reduce query-anonymity.  Therefore,
%query-anonymity is excluded from the analysis in the main text.}  

The user interface deals directly with authors and publishers of
documents and needs to preserve anonymity as much as possible.  The
current implementation of the user interface is now analyzed with
respect to the distinctions of anonymity provided above.

\subsubsection{Author-anonymity}

The user interface preserves author-anonymity.  Author-anonymity means
that the original author of a given document is unknown.  Adversaries
interested in uncovering the author of any document might try
capturing packets being sent to the publishing server.  From those
packets, adversaries can determine a user's IP address.  Unfortunately
for the adversary, only the IP address is guaranteed.  The author
might have asked someone else to help publish the document, or perhaps
simply used another machine to connect to the user interface.  In this
respect, the user interface preserves author-anonymity.

\subsubsection{Publisher-anonymity}

When used intelligently, the user interface is effective at preserving
publisher-anonymity.  Publisher-anonymity addresses the agent that
originally introduces the document into the system.  Because all
documents being placed in the servnet are currently going through the
same publishing server, the publishing server for all documents placed
into Free Haven through the user interface can reasonably be assumed
to be that server.  Even then, however, the publishing server is not
guaranteed.  For example, suppose Alice is running a Free Haven node
on her home computer, and by reading the documentation she learns how
to manually insert a document into Free Haven.  Alice then loads the
document's shares into her Free Haven node.  If that Free Haven node
intelligently trades those shares away, then the publishing server
(Alice's home computer) is anonymous.  When Free Haven contains more
than a few nodes, perhaps with more than one operating the user
interface, then the publishing server becomes effectively anonymous.

\subsubsection{Reader-anonymity}

The user interface is also somewhat effective at preserving
reader-anonymity.  Reader-anonymity means that servers responding to
requests for documents are unable to identify the identity or location
of the intended reader.  Because the retrieval request is sent to the
user interface before finding its way to the servnet in general, haven
servers have no way to link the document request to an identity or IP
address.  Servers with shares only have the reader's reply block, and
a well-chosen reply block will not provide any distinguishing
information.  In the current implementation, the CGI request provided
to the user interface contains the reader's IP address.  If a node
that implements the user interface has a share that matches the
request, then that node will be able to link the request to the
reader's current IP address.  Colluding nodes (as long as one of the
nodes receives the IP address) will also be able to link requests to
IP addresses.

\subsubsection{Server-anonymity}

Server-anonymity means that the location of the document at any time
should not be known or knowable.  Retrieved documents do not provably
pass through any given server.  The user interface preserves
server-anonymity because a document is never guaranteed to have passed
through a given node.  See discussion in ``Publisher-anonymity.''

\subsubsection{Document-anonymity}

The user interface does not preserve document-anonymity at the
publishing server.  If any given server can recreate bits inserted
into the system, then the document does not achieve anonymity.
Because the publishing server has, for some period of time, all the
data inserted, it can certainly recreate inserted bits.  Once shares
of the document leave the publishing server, then the infrastructure
of Free Haven is liable for any breaches in document-anonymity.  Our
definition of ``document-anonymity'' makes it almost impossible to
achieve.  In this context, violating document-anonymity is not such a
bad thing.

\subsubsection{Query-anonymity}

Query-anonymity means that although a server may have many different
documents stored, which document was served for a given request is not
knowable by the server.  Query-anonymity is outside the scope of the
user interface.  The user interface, therefore, is not responsible for
preserving query-anonymity.

\section{Future Work}

\subsection{Work Remaining on Current Implementation}

The insertion operation is almost completely implemented.  The user
interface currently implements a framework that allows files to be
inserted.  This section of the user interface is not completely
finished yet because some key cryptographic functionality has not yet
been implemented.  Namely, the user interface is not able to generate
real public keys for documents nor is the user interface able to sign
shares.  The next step is to completely implement the insertion
operation.  After the insertion operation is completely finished, the
user interface will then be improved to provide support for the
insertion of binary documents such as Word documents, etc.

The retrieval operation has not yet been implemented.  The main reason
for this is simply because the Free Haven team has not yet defined a
broadcast message protocol in any sort of written document.  Once I
understand the protocol, then the user interface portion of the
retrieval process will be relatively easy to implement.  After that is
implemented, then that script that provides users with any easy method
to reconstruct their documents needs to be written.

\subsection{Possible Design Improvements}

In working through the logic, design, and implementation of the user
interface I noticed several places where the user interface might be
improved.  These include:

\begin{singlespace}
\begin{itemize}
\item Hiding documents being uploaded from prying eyes
\item Making the retrieval operation easier to use
\end{itemize}
\end{singlespace}

Ideally, the user interface design schema would provide users with a
secure method of uploading their documents.  Without that secure
method, some number of potential Free Haven users will not use the
system.  Privacy of uploaded documents can be achieved in several
ways.  First, the interaction between the user and the user interface
can be made using HTTPS.  This solutions is probably the easiest to
implement and simply requires setting up an HTTPS server on one or
more of the nodes.  Secondly, a client-server application, perhaps
written in java, can be designed that encodes and decodes all
communications between the user's computer and the Free Haven node
running the server part of the application.  The advantage of writting
the whole application is that it can be made object oriented.  Modules
can then be improved with minimal pain.  The disadvantages of this
approach are that it requires extensive developement work and
implements the same functionality as provided by HTTPS.

The retrieval operation is currently rather difficult to use because a
reply block is required and the users must reconstruct the file
themselves.  We could perhaps have the broadcasting node reconstruct
the pieces of the document and then send the full document to the
reply block.  This method, however, violates some of our anonymity
requirements.  A second solution would go along with the object
oriented application mentioned in the above paragraph.  The java
client running on the user's machine could listen to a port for the
shares, and once enough shares arrive reconstruct the document.

\input ./fh-related-ui.tex

\section{Conclusion}

The Free Haven user interface has three main goals: to allow anonymous
insertion of documents into the network, to allow the anonymous
retrieval of documents from the network, and to provide an easy to use
interface for performing these two operations.  While the retrieval
operation is currenlt difficult to use, the user interface does
provide functionality for inserting documents into the Free Haven data
storage system and retrieving documents from that system.  In
addition, the user interface preserves author-anonymity,
reader-anonymity, server-anonymity, and query-anonymity while almost
achieving publisher-anonymity and document-anonymity.  Because one of
the main expressed goals of the Free Haven project is to provide
anonymity, the work described in this paper provides a good first
implementation of the Free Haven user interface.


\newpage
\section{Acknowledgements}

I would like to thank Roger Dingledine for the Free Haven project and
the opportunity to work on the user interface, David Molnar for
cryptographic functionality, Michael Freedman for the comm, which I
will have to use when I implement retrieval functionality, and
everyone in the Free Haven team for their patience.  And finally, I
would like to thank Professor Ronald Rivest for his part as my project
advisor.

\begin{thebibliography}{99}

\bibitem{freehavenmaster} Dingledine, Roger, ``The Free Haven Project:
Design and Deployment of an Anonymous Secure Data Haven,''
Massachusetts Institute of Technology Masters Thesis May 2000.

\bibitem{anonymizer} ``Anonymizer.com,'' 14 May 2000
http://www.anonymizer.com/3.0/index.shtml.

\bibitem{stats}  Anonymous Remailer Information.
http://anon.efga.org/Remailers/

\end{thebibliography}
\end{document}