[tahoe-dev] Friend-net use case development.

[Nathan]

Hi folks,

I'm interested in developing a friend-net topology on top of Tahoe.
Part of this work would be an experiment to see if Tahoe is flexible
enough to fit some design goals I had brainstormed before Tahoe's
creation.  Here's an overview of the design philosophy and related
goals for my pet project, which I've code-named Grapevine.

Mission:
Grapevine provides user friendly, secure, private, online interaction
between friends.


Security Goals:
A. A user's intuitions about interactions should reflect as closely as
possible the actual security implications.  A corollary is that
whenever there is a security implication which humans are already good
at handling, the software delegates to the user.

B. Vulnerabilities should be localized, s.t. while attacking a single
target may be possible, a general spidering attack across the whole
network is very expensive.

C. If Grapevine is not user-friendly, then users will prefer less
secure alternatives, and the status quo of privacy and security for
this use-case will not improve.  Therefore, as a security requirement,
Grapevine must be very user friendly.


Design Implications:
1. The user interface represents all nodes which the given node
interacts with, along with the nature (class) of the interaction.
(From all three goals.)  This means no forwarding, DHT routing, or
other algorithmically automated routing!

This prevents spidering attacks [FIXME: Reference needed], where a
powerful adversary disables a network by running the node discovery
mechanisms, then individually DOSing each node.  It also protects
privacy by making it expensive to create the social graph.

2. The UI provides a means for out-of-band introductions, but promotes
a more secure and user friendly in-band introduction mechanism.  (From
A and C.)

In-band introductions promote goal A, because if a user believes
introducing two of her friends connects their nodes, she is most
likely correct.  Out-of-band introductions do not meet goal A as well,
because user's may not understand how the leakage of authentication
secrets can lead to subtle privacy invasions or attacks.

3. The UI is easy to extend to create new user friendly, competitive
applications (IM, blogs, photo-sharing, etc...).  (From C.)


Tahoe-based Implementation Roadmap (brainstorm):
Several of these paths involve very tricky issues, including
extensions to the proposed Tahoe use cases (such as multi-grid
support, and secure third-party extensions).

I. Introduction:
a. Create a user interface for associating user-centric profiles with
a node's cryptographic identity.
b. UI for out-of-band introduction.
c. UI for in-band introduction.

II. Topology Issues:
a. Initially relax Goal C by allowing non-direct friends to share a
storage grid.  (If A <-> B <-> C is a friendship path, but A does not
know C, they still share a grid for convenience.)
b. Implement privacy-preserving mutual friend discovery.  (In the
previous example, if A meets C, then each pair can discover they've
met the third without accidentally leaking non-mutual friendships.)
c. Implement multiple grid-per-node support.
d. Map groups of mutual friends (complete friendship subgraphs) to
grids for effeciency in the face of privacy.

III.  Extensions:
a. Create an API for third party extensions which can both extend the
UI as well as interactions with other nodes.
b. Create extensions for primary killer apps (IM, blogs...  Compete
with popular social sites.).

IV.  Publicity:
a. Advertise to hackers during development.
b. Once it's good enough for my mom to use, invite her to meet my node.



Nathan