[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freehaven-dev] proposal 1.0 is out

Relevant diffs:

< \lhead{Thesis Proposal 1.0}
> \lhead{Thesis Proposal 0.9}
< the `servnet') where each server hosts data from the other servers in
< exchange for the opportunity to store data of its own in the servnet. The
< system is designed to store data without concern for its popularity
< or controversial nature. Possible uses include storing source code
< or binaries for software which is currently under legal debate, such
< as the recent DeCSS controversy or other software with patent issues;
< storing political speech in an anonymous fashion for people afraid that
< tying their speech to their public persona will damage their reputation;
< or even storing more normal-looking data like a set of public records
< from Kosovo. The system is designed more for storage than for frequent
< querying --- it is expected that in many cases, interesting material will
< be retrieved from the system and published in a more available fashion
< (such as normal web pages) in a jurisdiction where such publishing is
< more reasonable. Then the document in the servnet would only need to be
< accessed if the other sources were shut down.
< The potential adversaries are many and diverse: governments,
< corporations, and individuals all have reason to oppose the system.
< There will be social
< attacks from citizens and countries trying to undermine the trust in the
< security of the system, as well as attacking the motivation for servnet
< node operators to continue running nodes. There will be political attacks,
< using the influence of a country's leaders to discourage use of the
< servnet. There will be government and legal attacks, where authorities
< attempt to shut down servnet nodes or arrest operators. Indeed, in many
< cases ordinary citizens can recruit the power of the government through
< lawsuits or subpoenas. Multinational corporations will hold sway over
< several countries, influencing them to pass similar laws against anonymous
< networks. There will be technical attacks, both from individuals and from
< corporations and national intelligence agencies, targetted either at the
< system as a whole or at particular documents or node operators, to reduce
< the quality of service or gain control of part of the network. Clearly
< the system needs to be designed with stability, security, and longevity in
< mind.
< More formally, requirements beyond anonymity for a stable and useful system
< include:
> the `servnet') where each server hosts data from the other servers in exchange for
> the opportunity to store data of its own in the servnet. Besides the above
> anonymity requirement, there are a number of other requirements for a stable
> and useful system:
< otherwise `evil' node can perform should be limited. This might be
< accomplished by a trust network, where each node active maintains an
< opinion of other nodes, and nodes inform each other when they change
< an opinion.
> otherwise `evil' node can perform should be limited.
< medium.  By becoming part of the communications medium, it would be
< possible to observe the traffic more closely and get a better idea
< of where it's coming from or where it's going.
> medium.  This shortens the eventual path-length considerably.
< \item Denial of service attack on the communications medium: flooding
< it with messages may well increase latency beyond tolerable limits, or
< actually crash some of the nodes.
< \item Denial of service attack on the servnet: continued flooding of
< queries for data or requests to join the servnet may use up all available
< bandwidth and processing power for a node.
< Old nodes need to be removed from use after a while, since continued
< mail bombardment from the mixnet to a closed account will eventually slow
< down the service (as well as angering a lot of systems administrators).
< On the other hand, any operation which can remove nodes from the servnet
< must be handled very carefully, because it's easy to introduce security
< vulnerabilities that let an adversary disable a node.
< One solution is to allow the trust network to gradually lose trust in a
< given node to the point that it doesn't ever send trade requests to it.
< On the other hand, broadcast requests will still go to it. This means that
< we might consider a sort of `ping' query for a node, to make sure that
< it's still responding to its mail. On the other hand, this introduces new
< denial of service attacks where a node might answer pings but not other
< queries. I think the benefits of being able to notice dead nodes outweigh
< the denial of service concerns and the extra protocol.
> foo bar baz
< information is relatively rare.  The content-neutral policies mean that there is
< no reason to expect that the server operator has looked at the data he holds, which
< might make it more difficult to prosecute. \emph{2a, 2g}
> information is very rare [is this true?].  The content-blindness of the system also
> makes it difficult to prosecute. \emph{2a, 2g}
< One approach that we're considering is for each servnet node to simply remember how much
< useful service it has received from each other node, and only trusting nodes with
< at most the amount of useful work they've already provided. This means that we can
< limit the amount of damage a given node can do, and make sure that we'll always get
< at least 50\% useful return out of each node.