Ribut.us Overview

Basic pitch.

Outline

• Privacy
  • Advertising
  • Coercion
  • Confidence
• P2P
  • No servers
  • P2P/UDP
  • Shared resources
• Mixnet / Leapfrog
  • Everyone routes
  • IDNode vs OverlayNode
  • Send Route
  • Receive Route
  • Stateless routing
• DHT
  • Short records, short TTL
  • Connection Example
• Broadcast
  • Most likely to change
  • Through DHT, pulsed, limited
  • General Request example
• Email Example
• Core Apps
  • Social (Speakeasy)
  • Group
  • Authority Publish

Privacy

The goal of Dist.ribut.us is to provide privacy to users. While the long term goal is for this to include state sponsored spying, the immediate concern is invasions of privacy for advertising via coercion. The most prominent example is that of social networks that gather and sell information about their users. The only way for a user to protect their privacy is to avoid using the service, but the simple pervasiveness of the service becomes a coercive force.

It is equally important that users understand that their privacy is protected. Too many services may claim to protect user privacy but couch that in exemptions and caveats. Users do not trust that their privacy is protected. Or they believe that small missteps will leak their information. We must build confidence in that platform that is can be used securely even by users with low computer literacy.

P2P

One of the first conclusions that can be drawn from the goal of providing privacy is a need to move away from a client-server model. It is economically prohibitive, more difficult to secure and risks a concentration of power and authority. A better route is to build a peer-to-peer network where users share their bandwidth, storage and computation resources to collectively emulate services. So long as the burden of these shared resources is kept low (and particularly if that burden can be kept lower than the perceived burden of invasive advertising), I believe users will accept this cost.

Leapfrog, a mixnet

The first step to protecting privacy is having all communication done through a mixnet or onion routing protocol. For Ribut, this is the Leapfrog protocol. All messages are sent with using this protocol. This does not have to incur delays for users who are not concerned about privacy, because they can still communicate directly, but wrap the communication in the Leapfrog protocol (make the message look like it's being routed around, even though it's being sent directly). Having all message on the network use this means that no messages look suspicious.

All nodes on the network act as routers. This means that the network can scale (practically indefinitely) and it provides each node with anonymity because it is unclear if a specific message originated with the node currently sending it. This achieves the same effect as networks that introduce chaff by sending packets randomly, there is enough network noise to mask any individual signal.

Users will have two types of nodes, ID nodes and Overlay nodes. A device will only have one overlay node at a time. The overlay node exposes the public IP address of the device. ID nodes provide pseudonyms that may be linked to the users identity. There must be strict "Heisenberg Privacy" no one (except the user) should know both the overlay node and an ID node, one or the other.

Overlay nodes and ID nodes are linked through mixnet routing. A send route allows a user to send a message containing identifying information by bouncing it between up to 3 nodes before it reaches it's destination. A receive route allows a user to define a path back to their overlay node. A received route can be sent to another user, providing a path for them to send information back. The combination, a send-receive route protects the anonymity of both the sender and receiver.

It's also worth mentioning that the routing is stateless, it does not maintain open tunnels. And once a message has been received, a layer removed and it is relayed, it can be safely removed from memory.

Distributed Hash Table

The central means of coordination is a distributed hash table. Just as with routing, everyone is expected to participate in the hash table. Records in the table have a very limited length (no longer than a return route) and a limited lifespan (probably 5 minutes, but that can be tested and changed). The main purpose of the hash table is for someone to register the hash of some identifier and provide a return route for requesting that resource.

For example, Alice logs on using an ID node for Speakeasy, our hypothetical social network. She uses a send route to anonymously push the hash of her public key to the distributed hash table along with a return route so that users can contact her. Every 5 minutes she generates a new return route and republishes it to the DHT. When Alice's friend Bob logs on, he can look up Alice in the DHT (he knows her public key) and get the receive route. He then generates his own send route and prepends it to Alice's receive route. Bob can now send Alice a message, and possibly include a few receive routes to aid in further communication.

Broadcast

This section is likely to change. It does not scale well and would be easily abused. For now, it is the least-bad option.

If Alice were to publish every resource she has, she may end up doing nothing but updating the DHT and it may leak enough information for a user to identify her. Instead, when a user wants a resource that isn't in the DHT, they broadcast a request for it.

Broadcasting uses the overlay network of the DHT. Broadcast messages are queued up and only forwarded at most, once per second. When a node receives a broadcast message, that node forwards on all the requests it has not seen in the last 5 minutes.

Let's say Alice wants a file that Bob has. Alice checks the DHT for the hash of the file, but it's not there. So she sends (anonymously) a broadcast message to a random node. The next time (within 1 second) that node sends out a request batch, it is added to the batch. This way it is forwarded on, branching by a factor of upto 8 each second. Within a few seconds, it reaches Bob, who can fulfill the request. Bob waits until the request expires (requests generally live ~10 seconds) then posts a return route in the DHT for that resource. When Alice checks again, she sees that the resource is now available.

Email

This lays the groundwork for how something like Email could work. Alice can write a message to Bob. If Bob is online, Alice can send the message directly to him. If he is not online, she puts a secret, prearranged label on the message and sends a copy to all her friends. Alice's friends know the message is from Alice (that's why they're willing to hold on to it) but they don't know who it's for or what it says (it's encrypted). When Bob comes online, he checks for Alice, if she's online, he gets the message directly from her. If she's not online, Bob can send a request for the secret, pre-arranged label. When one of Alice's friends sees the request, they can post the resource to the DHT, where Bob can see the route to retrieve it. But because the message is retrieved through a send-receive route, Bob and Alice's friend remain anonymous to each other.

Vision

Ribut will provide a few low level tools for building these types of applications. Protocols for finding and exchanging resources while protecting privacy. It will also include a package manager, like an "App Store". However, there should only be a few applications available, divided by communication domain.

Social networking (communication between a few people who know each other) is one domain, discussions (communication and sharing between larger groups that remain pseudonymous) would be another, authoritative publishing (like webpages, where the reliability of the content is tied to the source providing it) would be yet another.

However, on top of these few domains should be dozens or hundreds of possible plugins. For instance, the social networking application may not have Voip out-of-the-box, but a plugin could provide it.

I won't go into the details here, but these applications and plug-ins would be subject to peer review and would only be made available to end users when they had been signed by a sufficient number of trusted entities. This provides users with protection against malicious or coercive software.

Together this would create an effective ecosystem of tools that guarantee user privacy.