diff options
| -rw-r--r-- | wiki/gossamer/index.md | 315 |
1 files changed, 202 insertions, 113 deletions
diff --git a/wiki/gossamer/index.md b/wiki/gossamer/index.md index fef08ba..0907cbc 100644 --- a/wiki/gossamer/index.md +++ b/wiki/gossamer/index.md @@ -30,17 +30,16 @@ software. (This is a major failing with Diaspora, which limits access to personal ownership of data by being hard to run.) +* Users must be able to communicate without the consent or support of an + intermediate authority. Short of being completely offline, Gossamer should + be resilient to infrastructural damage. + * Any functional communication system _will_ be used for illicit purposes. This is an unavoidable consequence of being usable for legitimate purposes without a central authority. Rather than revealing illicit conversations, Gossamer should do what it can to preserve the anonymity and privacy of legitimate ones. -* Centralization encourages control and enables pervasive monitoring. - Contrary to received wisdom, people who haven't done anything wrong - _should_ be entitled to hide things, and to have conversations without the - intervention of a central conversation authority. - * All nodes are as equal as possible. The node _I_ use is not more authoritative for messages from me than any other node. You can hear my words from anyone who has heard my words, and I can hear yours from anyone @@ -52,123 +51,77 @@ software. authoring must be as indistinguishable as possible, to limit the utility of traffic analysis. -## Gossamer Network Primitives - -The Gossamer network is built around a gossip protocol, wherein _nodes_ -connect to one another periodically to exchange _messages_ with one another. -Connections occur over the existing IP internet infrastructure, traversing -NAT networks where possible to ensure that users on residential and corporate -networks can still participate. - -Gossamer bootstraps its network using a number of paths: - -* Gossamer nodes in the same broadcast domain discover one another using UDP - broadcasts as well as Bonjour/mDNS. - -* Gossamer can generate _locator_ strings, which can be shared "out of band" - via email, SMS messages, Twitter, graffiti, etc. - -* Gossamer nodes share knowledge of nodes whenever they exchange messages, to - allow the Gossamer network to recover from lost nodes and to permit nodes - to remain on the network as "known" nodes are lost to outages and entropy. - -### Locators - -A Gossamer _locator_ is a URL in the `g` scheme, carrying an encoding of one -or more network addresses as well as an encoding of one or more identities -(see below). Gossamer's software attempts to determine an appropriate -identifier for any identities it holds based on the host computer's network -configuration, taking into account issues like NAT traversal wherever -possible. - -**TODO**: Gossamer and uPNP, what do locators _look_ like? - -When presented with an identifier, Gossamer offers to _follow_ the identities -it contains, and uses the _nodes_ whose addresses it contains to connect to -the Gossamer network. This allows new clients to bootstrap into Gossamer, and -provides an easy way for users to exchange Gossamer identities to connect to -one another later. - -(Clever readers will note that the address list is actually independent of -the identity list.) - -### Gossip - -Each Gossamer node maintains a pair of "freshness" databases, associating -some information with a freshness score (expressed as an integer). One -freshness database holds the addresses of known Gossamer nodes, and another -holds Gossamer messages. - -Whenever two Gossamer nodes interact, each sends the other a Gossamer node -from its current node database, and a message from its message database. When -selecting an item to send for either category, Gossamer uses a random -selection that weights towards items with a higher "freshness" score. -(**TODO**: how?) - -When sending a fact, if the receiving node already knows the fact, both nodes -decrement that fact's freshness by one. If the receiving node _does not_ -already know the fact, the sending node leaves its freshness unaltered, and -the receiving node sets its freshness to the freshest possible value. This -system encourages nodes to exchange "fresh" facts, then cease exchanging them -as the network becomes aware of them. +## Public and Private Information -During each exchange, Gossamer nodes send each other one Gossamer node -address, and one Gossamer message. Both nodes adjust their freshness -databases, as above. +Every piece of data Gossamer uses, either internally or to communicate with +other ndoes, is classified as either _public_ or "private". Public +information can be communicated to other nodes, and is assumed to be safe if +recovered out of band. Private information includes anything which may be +used to associate a Gossamer identity with the person who controls it, except +as noted below. -If fact exchange fails while communicating with a Gossamer node, both nodes -decrement their peer's freshness. Unreliable nodes can continue to initiate -connections to other nodes, but will rarely be contacted by other Gossamer -nodes. +Gossamer must ensure users understand what information that they provide will +be made public, and what will be kept private, so that they can better decide +what, if anything, to share and so that they can better make decisions about +their own safety and comfort against abusive parties. -**TODO**: How do we avoid DDOSing brand-new gossamer nodes with the full -might of Gossamer's network? +Internally, Gossamer _always_ stores private information encrypted, and +_never_ transmits it to another node. Gossamer _must_ provide a tool to +safely obliterate private data. -**TODO**: Can we reuse Bittorrent's DHT system (BEP-5) to avoid having every -node know the full network topology? +### Public Information -**TODO**: Are node-to-node exchanges encrypted? If so, why and how? +Details on the role of each piece of information are covered below. -### Authenticity +* Public status updates, obviously. Gossamer exists to permit users to easily + share short messages with one another. -Gossamer node addresses are not authenticated. Gossamer relies on freshness -to avoid delivering excess traffic to systems not participating in the -Gossamer network. (**TODO**: this is a shit system for avoiding DDOS, though.) +* The opaque form of a user's incoming and outgoing private messages. -Gossamer messages _are_ partially authenticated: each carries with it a -public key, and a signature. If the signature cannot be verified with the -included public key, it _must_ be discarded immediately and it _must not_ be -propagated to other nodes. The node delivering the message _may_ also be -penalized by having its freshness reduced in the receiving node's database. +* The users' identities' public keys. (But not their relationship to one + another.) -### Gossip Triggers +* Any information the user places in their profile. (This implies that + profiles _must not_ be auto-populated from, for example, the user's address + book.) -Gossamer triggers a new Gossip exchange under the following circumstances: +* The set of identities verified by the user's identity. -* 15 seconds elapse since the last exchange attempt. +Any other information Gossamer retains _must_ be private. -* Gossamer completes an exchange wherein it learned a new fact from another - node. +## Republishing -* A user injects a fact into Gossamer directly. +Gossamer is built on the assumption that every participant is willing to act +as a relay for every other participant. This is a complicated assumption at +the human layer. -Gossamer exchanges that fail, or that deliver only already-known facts, do -not trigger further exchanges immediately. +Inevitably, someone will use the Gossamer network to communicate something +morally repugnant or deeply illegal: the Silk Road guy, for example, got done +for trying to contract someone to commit murder. Every Gossamer node is +complicit in delivering those messages to the rest of the network, whether +they're in the clear (status updates) or not (private messages). It's unclear +how this interacts with the various legal frameworks, moral codes, and other +social constructs throughout the world, and it's ethically troubling to put +users in that position by default. -**TODO**: how do we prevent Gossamer from attempting to start an unbounded -number of exchanges at the same time? +The strong alternative, that each node only relay content with the +controlling user's explicit and ongoing consent, is also troubling: it limits +the Gossamer network's ability to deliver messages _at all_, and exposes +information about which identities each node's owner considers interesting +and publishable. -### Size +I don't have an obvious resolution to this. Gossamer's underlying protocol +relies on randomly-selected nodes being more likely to propagate a message +than to ignore it, because this helps make Gossamer resilient to hostile +users, nosy intelligence agencies, and others who believe communication must +be restrictable. On the other hand, I'd like not to put a user in Thaiwan at +risk of legal or social reprisals because a total stranger in Canada decided +to post something vile. -Gossamer must not exhaust the user's disk. Gossamer discards _extremely_ -un-fresh messages, attempting to keep the on-disk size of the message -database to under 10% of the total local storage, or under a -user-configurable threshold. - -Gossamer rejects over-large messages. Public messages carry with them the -author's profile and a potentially large collection of verifications. -Messages over some size (**TODO** what size?) are discarded on receipt -without being stored, and the message exchange is considered to have failed. +(This is one of the reasons I haven't _built_ the damn thing yet. Besides +being A Lot Of Code, there's no way to shut off Gossamer once more than one +node exists, and I want to be sure I've thought through what I'm doing before +creating a prototype.) ## Identity in the Gossamer Network @@ -202,22 +155,40 @@ update their profile at will; potentially, every message can be sent with a distinct profile. Gossamer software treats the profile it's seen with the highest timestamp as authoritative, retroactively applying it to old messages. -### Multiple Devices and Key Security. +### Multiple Devices and Key Security A Gossamer identity is entirely contained in its private key. An identity's key must be stored safely, either using the host operating system's key -management facilities or using a carefully-designed key store. +management facilities or using a carefully-designed key store. Keys must not +hit long-term storage unprotected; this may involve careful integration with +the underlying OS's memory management facilities to avoid, eg., placing +identities in swap. This is _necessary_ to protect users from having their +identities recovered against their will via, for example, hard drive +forensics. Gossamer allows keys to be exported into password-encrypted archive files, which can be loaded into other Gossamer applications to allow them to share the same identity. -**GOSSAMER MUST TREAT THESE FILES WITH EXTREME CARE**. Identity keys protect -the user's Gossamer identity, but they _also_ protect the user's private -message (see below). The export format must be designed to be as resilient as +**GOSSAMER MUST TREAT THESE FILES WITH EXTREME CARE, BECAUSE USERS PROBABLY +WON'T**. Identity keys protect the user's Gossamer identity, but they _also_ +protect the user's private messages (see below) and other potentially +identifying data. The export format must be designed to be as resilient as possible, and Gossamer's software must take care to ensure that "used" -identity files are destroyed safely wherever possible and to discourage users -from following unsafe practices. +identity files are _automatically_ destroyed safely wherever possible and to +discourage users from following practices that weaken their own safety +unknowingly. + +Exported identity files are intrinsically vulnerable to offline brute-force +attacks; once obtained, an attacker can try any of the worryingly common +passwords at will, and can easily validate a password by using the recovered +keys to regenerate some known fact about the original, such as a verification +or a message signature. This implies that exported identities _must_ use a +key derivation system which has a high computational cost and which is +believed to be resilient to, for example, GPU-accelerated cracking. + +Secure deletion is a Hard Problem; where possible, Gossamer must use +operating system-provided facilities for securely destroying files. ## Status Messages @@ -225,7 +196,7 @@ Status messages are messages visible to any interested Gossamer users. These are the primary purpose of Gossamer. Each contains up to 140 Unicode characters, a markup section allowing Gossamer to attach URLs and metadata (including Gossamer locators) to the text, and an attachments section -carrying arbitrary MIME blobs. +carrying arbitrary MIME blobs of limited total size. All three sections are canonicalized (**TODO**: how?) and signed by the publishing identity's private key. The public key, the identity's most recent @@ -337,3 +308,121 @@ This is fundamentally incompatible with strong blocking. It will _always_ be possible for a newly-created identity to deliver at least one message before being blocked. _This is a major design problem_; advice encouraged. +## Gossamer Network Primitives + +The Gossamer network is built around a gossip protocol, wherein _nodes_ +connect to one another periodically to exchange _messages_ with one another. +Connections occur over the existing IP internet infrastructure, traversing +NAT networks where possible to ensure that users on residential and corporate +networks can still participate. + +Gossamer bootstraps its network using a number of paths: + +* Gossamer nodes in the same broadcast domain discover one another using UDP + broadcasts as well as Bonjour/mDNS. + +* Gossamer can generate _locator_ strings, which can be shared "out of band" + via email, SMS messages, Twitter, graffiti, etc. + +* Gossamer nodes share knowledge of nodes whenever they exchange messages, to + allow the Gossamer network to recover from lost nodes and to permit nodes + to remain on the network as "known" nodes are lost to outages and entropy. + +### Locators + +A Gossamer _locator_ is a URL in the `g` scheme, carrying an encoding of one +or more network addresses as well as an encoding of one or more identities +(see below). Gossamer's software attempts to determine an appropriate +identifier for any identities it holds based on the host computer's network +configuration, taking into account issues like NAT traversal wherever +possible. + +**TODO**: Gossamer and uPNP, what do locators _look_ like? + +When presented with an identifier, Gossamer offers to _follow_ the identities +it contains, and uses the _nodes_ whose addresses it contains to connect to +the Gossamer network. This allows new clients to bootstrap into Gossamer, and +provides an easy way for users to exchange Gossamer identities to connect to +one another later. + +(Clever readers will note that the address list is actually independent of +the identity list.) + +### Gossip + +Each Gossamer node maintains a pair of "freshness" databases, associating +some information with a freshness score (expressed as an integer). One +freshness database holds the addresses of known Gossamer nodes, and another +holds Gossamer messages. + +Whenever two Gossamer nodes interact, each sends the other a Gossamer node +from its current node database, and a message from its message database. When +selecting an item to send for either category, Gossamer uses a random +selection that weights towards items with a higher "freshness" score. +(**TODO**: how?) + +When sending a fact, if the receiving node already knows the fact, both nodes +decrement that fact's freshness by one. If the receiving node _does not_ +already know the fact, the sending node leaves its freshness unaltered, and +the receiving node sets its freshness to the freshest possible value. This +system encourages nodes to exchange "fresh" facts, then cease exchanging them +as the network becomes aware of them. + +During each exchange, Gossamer nodes send each other one Gossamer node +address, and one Gossamer message. Both nodes adjust their freshness +databases, as above. + +If fact exchange fails while communicating with a Gossamer node, both nodes +decrement their peer's freshness. Unreliable nodes can continue to initiate +connections to other nodes, but will rarely be contacted by other Gossamer +nodes. + +**TODO**: How do we avoid DDOSing brand-new gossamer nodes with the full +might of Gossamer's network? + +**TODO**: Can we reuse Bittorrent's DHT system (BEP-5) to avoid having every +node know the full network topology? + +**TODO**: Are node-to-node exchanges encrypted? If so, why and how? + +### Authenticity + +Gossamer node addresses are not authenticated. Gossamer relies on freshness +to avoid delivering excess traffic to systems not participating in the +Gossamer network. (**TODO**: this is a shit system for avoiding DDOS, though.) + +Gossamer messages _are_ partially authenticated: each carries with it a +public key, and a signature. If the signature cannot be verified with the +included public key, it _must_ be discarded immediately and it _must not_ be +propagated to other nodes. The node delivering the message _may_ also be +penalized by having its freshness reduced in the receiving node's database. + +### Gossip Triggers + +Gossamer triggers a new Gossip exchange under the following circumstances: + +* 15 seconds, plus a random jitter between zero and 15 more seconds, elapse + since the last exchange attempt. + +* Gossamer completes an exchange wherein it learned a new fact from another + node. + +* A user injects a fact into Gossamer directly. + +Gossamer exchanges that fail, or that deliver only already-known facts, do +not trigger further exchanges immediately. + +**TODO**: how do we prevent Gossamer from attempting to start an unbounded +number of exchanges at the same time? + +### Size + +Gossamer must not exhaust the user's disk. Gossamer discards _extremely_ +un-fresh messages, attempting to keep the on-disk size of the message +database to under 10% of the total local storage, or under a +user-configurable threshold. + +Gossamer rejects over-large messages. Public messages carry with them the +author's profile and a potentially large collection of verifications. +Messages over some size (**TODO** what size?) are discarded on receipt +without being stored, and the message exchange is considered to have failed. |