diff options
Diffstat (limited to '.html/gossamer/index.html')
| -rw-r--r-- | .html/gossamer/index.html | 463 |
1 files changed, 463 insertions, 0 deletions
diff --git a/.html/gossamer/index.html b/.html/gossamer/index.html new file mode 100644 index 0000000..66fe858 --- /dev/null +++ b/.html/gossamer/index.html @@ -0,0 +1,463 @@ +<!DOCTYPE html> +<html> +<head> + <title> + The Codex » + Gossamer: A Decentralized Status-Sharing Network + </title> + + <link + rel='stylesheet' + type='text/css' + href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'> + <link + rel="stylesheet" + type="text/css" + href="../media/css/reset.css"> + <link + rel="stylesheet" + type="text/css" + href="../media/css/grimoire.css"> +</head> +<body> + +<div id="shell"> + + <ol id="breadcrumbs"> + + <li class="crumb-0 not-last"> + + <a href="../">index</a> + + </li> + + <li class="crumb-1 last"> + + gossamer + + </li> + + </ol> + + + + <div id="article"> + <h1 id="gossamer-a-decentralized-status-sharing-network">Gossamer: A Decentralized Status-Sharing Network</h1> +<p>Twitter's pretty great. The short format encourages brief, pithy remarks, and +the default assumption of visibility makes it super easy to pitch in on a +conversation, or to find new people to listen to. Unfortunately, Twitter is a +centralized system: one Bay-area company in the United States controls and +mediates <em>all</em> Twitter interactions.</p> +<p>From all appearances, Twitter, Inc. is relatively benign, as social media +corporations go. There are few reports of censorship, and while their +response to abuse of the Twitter network has not been consistently awesome, +they can be made to listen. However, there exists the capacity for Twitter, +Inc. to subvert the entire Twitter system, either voluntarily or at the +behest of governments around the world.</p> +<p>(Just ask Turkish people. Or the participants in the Arab Spring.)</p> +<p>Gossamer is a Twitter-alike system, designed from the ground up to have no +central authority. It resists censorship, enables individual participants to +control their own data, and allows anyone at all to integrate new software +into the Gossamer network.</p> +<p>Gossamer does not exist, but if it did, the following notes describe what it +might look like, and the factors to consider when implementing Gossamer as +software. I have made <a href="mistakes">fatal mistakes</a> while writing it; I have not +rushed to build it specifically because Twitter, Gossamer's model, is so +deeply woven into so many peoples' lives. A successor must make fewer +mistakes, not merely different mistakes, and certainly not more mistakes.</p> +<p>The following is loosely inspired by <a href="http://www.mememotes.com/meme_motes/2005/02/rumor_monger.html">Rumor +Monger</a>, at +“whole world” scale.</p> +<h2 id="design-goals">Design Goals</h2> +<ul> +<li> +<p>Users must be in control of their own privacy and identity at all times. + (This is a major failing with Diaspora, which limits access to personal + ownership of data by being hard to run.)</p> +</li> +<li> +<p>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.</p> +</li> +<li> +<p>Any functional communication system <em>will</em> 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.</p> +</li> +<li> +<p>All nodes are as equal as possible. The node <em>I</em> 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 + who has heard your words, so long as some variety of authenticity and + privacy are maintained.</p> +</li> +<li> +<p>If an identity's secrets are removed, a node should contain no data that + correlates the owner with his or her Gossamer identities. Relaying and + authoring must be as indistinguishable as possible, to limit the utility of + traffic analysis.</p> +</li> +</ul> +<h2 id="public-and-private-information">Public and Private Information</h2> +<p>Every piece of data Gossamer uses, either internally or to communicate with +other ndoes, is classified as either <em>public</em> or <em>private</em>. 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.</p> +<p>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.</p> +<p>Internally, Gossamer <em>always</em> stores private information encrypted, and +<em>never</em> transmits it to another node. Gossamer <em>must</em> provide a tool to +safely obliterate private data.</p> +<h3 id="public-information">Public Information</h3> +<p>Details on the role of each piece of information are covered below.</p> +<ul> +<li> +<p>Public status updates, obviously. Gossamer exists to permit users to easily + share short messages with one another.</p> +</li> +<li> +<p>The opaque form of a user's incoming and outgoing private messages.</p> +</li> +<li> +<p>The users' identities' public keys. (But not their relationship to one + another.)</p> +</li> +<li> +<p>Any information the user places in their profile. (This implies that + profiles <em>must not</em> be auto-populated from, for example, the user's address + book.)</p> +</li> +<li> +<p>The set of identities verified by the user's identity.</p> +</li> +</ul> +<p>Any other information Gossamer retains <em>must</em> be private.</p> +<h2 id="republishing">Republishing</h2> +<p>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.</p> +<p>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.</p> +<p>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 <em>at all</em>, and exposes +information about which identities each node's owner considers interesting +and publishable.</p> +<p>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 Taiwan at +risk of legal or social reprisals because a total stranger in Canada decided +to post something vile.</p> +<p>(This is one of the reasons I haven't <em>built</em> 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.)</p> +<h2 id="identity-in-the-gossamer-network">Identity in the Gossamer Network</h2> +<p>Every Gossamer <em>message</em> carries with it an <em>identity</em>. Gossamer identities +are backed by public-key cryptography. However, unlike traditional public key +systems such as GPG, Gossamer identities provide <em>continuity</em>, rather than +<em>authenticity</em>: two Gossamer messages signed by the same key are from the +same identity, but there is no inherent guarantee that that identity is +legitimate.</p> +<p>Gossamer maintains relationships between identities to allow users to +<em>verify</em> the identities of one another, and to publish attestations of that +to other Gossamer nodes. From this, Gossamer can recover much of GPG's “web +of trust.”</p> +<p><strong>TODO</strong>: revocation of identities, revocation of verifications. Both are +important; novice users are likely to verify people poorly, and there should +be a recovery path less drastic than GPG's “you swore it, you're stuck with +it” model.</p> +<p>Gossamer encourages users to create additional identities as needed to, for +example, support the separation of work and home conversations, or to provide +anonymity when discussing reputationally-hazardous topics. Identities are not +correlated by the Gossamer codebase.</p> +<p>Each identity can optionally include a <em>profile</em>: a block of data describing +the person behind the identity. The contents of a profile are chosen by the +person holding the private key for an identity, and the profile is attached +to every new message created with the corresponding identity. A user can +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.</p> +<h3 id="multiple-devices-and-key-security">Multiple Devices and Key Security</h3> +<p>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. 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 <em>necessary</em> to protect users from having their +identities recovered against their will via, for example, hard drive +forensics.</p> +<p>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.</p> +<p><strong>GOSSAMER MUST TREAT THESE FILES WITH EXTREME CARE, BECAUSE USERS PROBABLY +WON'T</strong>. Identity keys protect the user's Gossamer identity, but they <em>also</em> +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 <em>automatically</em> destroyed safely wherever possible and to +discourage users from following practices that weaken their own safety +unknowingly.</p> +<p>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 <em>must</em> use a +key derivation system which has a high computational cost and which is +believed to be resilient to, for example, GPU-accelerated cracking.</p> +<p>Secure deletion is a Hard Problem; where possible, Gossamer must use +operating system-provided facilities for securely destroying files.</p> +<h2 id="status-messages">Status Messages</h2> +<p>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 of limited total size.</p> +<p>All three sections are canonicalized (<strong>TODO</strong>: how?) and signed by the +publishing identity's private key. The public key, the identity's most recent +profile, and the signed status message are combined into a single Gossamer +message and injected into the user's Gossamer node exactly as if it had +arrived from another node.</p> +<p>Each Gossamer node maintains a <em>follow list</em> of identities whose messages the +user is interested in seeing. When Gossamer receives a novel status message +during a gossip exchange, it displays it to the user if and only if its +identity is on the node's follow list. Otherwise, the message is not +displayed, but will be shared onwards with other nodes. In this way, every +Gossamer node acts as a relay for every other Gossamer node.</p> +<p>If Gossamer receives a message signed by an identity it has seen attestations +for, it attaches those attestations to the message before delivering them +onwards. In this way, users' verifications of one another's identity spread +through the network organically.</p> +<h2 id="private-messages">Private Messages</h2> +<p>Gossamer can optionally encrypt messages, allowing users to send one another +private messages. These messages are carried over the Gossamer network as +normal, but only nodes holding the appropriate identity key can decrypt them +and display them to the user. (At any given time, most Gossamer nodes hold +many private messages they cannot decrypt.)</p> +<p>Private messages <em>do not</em> carry the author's identity or full profile in the +clear. The author's bare identity is included in the encrypted part of the +message, to allow the intended recipient to identify the sender.</p> +<p><strong>TODO</strong>: sign-then-encrypt, or encrypt-then-sign? If sign-then-encrypt, are +private messages exempted from the “drop broken messages” rule above?</p> +<h2 id="following-users">Following Users</h2> +<p>Each Gossamer node maintains a database of <em>followed</em> identities. (This may +or may not include the owner's own identity.) Any message stored in the node +published by an identity in this database will be shown to the user in a +timeline-esque view.</p> +<p>Gossamer's follow list is <em>purely local</em>, and is not shared between nodes +even if they have identities in common. The follow list is additionally +stored encrypted using the node's identities (any one identity is sufficient +to recover the list), to ensure that the follow list is not easily available +to others without the node owner's permission.</p> +<p>Exercises such as <a href="http://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/">Finding Paul Revere</a> +have shown that the collection of graph edges showing who communicates with +whom can often be sufficient to map identities into people. Gossamer attempts +to restrict access to this data, believing it is not the network's place to +know who follows who.</p> +<h2 id="verified-identities">Verified Identities</h2> +<p>Gossamer allows identities to sign one anothers' public keys. These +signatures form <em>verifications</em>. Gossamer considers an identity <em>verified</em> if +any of the following hold:</p> +<ul> +<li> +<p>Gossamer has access to the identity key for the identity itself.</p> +</li> +<li> +<p>Gossamer has access to the identity key for at least one of the identity's + verifications.</p> +</li> +<li> +<p>The identity is signed by at least three (todo: or however many, I didn't + do the arithmetic yet) verified identities.</p> +</li> +</ul> +<p>Verified identities are marked in the user interface to make it obvious to +the user whether a message is from a known friend or from an unknown identity.</p> +<p>Gossamer allows users to sign new verifications for any identity they have +seen. These verifications are initially stored locally, but will be published +as messages transit the node as described below. Verification is a <em>public</em> +fact: everyone can see which identities have verified which other identities. +This is a potentially very powerful tool for reassociating identities with +real-world people; Gossamer <em>must</em> make this clear to users.</p> +<p>(I'm pretty sure you could find me, personally, just by watching whose +identities I verify.)</p> +<p>Each Gossamer node maintains a database of every verification it has ever +seen or generated. If the node receives a message from an identity that +appears in the verification database, and if the message is under some total +size, Gossamer appends verifications from its database to the message before +reinjecting it into the network. This allows verifications to propagate +through</p> +<h2 id="blocking-users">Blocking Users</h2> +<p>Any social network will attract hostile users who wish to disrupt the network +or abuse its participants. Users <em>must</em> be able to filter out these users, +and must not provide too much feedback to blocked users that could otherwise +be used to circumvent blocks.</p> +<p>Each Gossamer node maintains a database of blocked identities. Any message +from an identity in this database, or from an identity that is verified by +three or more identities in this database, will automatically be filtered out +from display. (Additionally, transitively-blocked users will automatically be +added to the block database. Blocking is contagious.) (<strong>TODO</strong>: should +Gossamer <em>drop</em> blocked messages? How does that interact with the inevitable +“shared blocklist” systems that arise in any social network?)</p> +<p>As with the follow list, the block database is encrypted using the node's +identities.</p> +<p>Gossamer encourages users to create new identities as often as they see fit +and attempts to separate identities from one another as much as possible. +This is fundamentally incompatible with strong blocking. It will <em>always</em> be +possible for a newly-created identity to deliver at least one message before +being blocked. <em>This is a major design problem</em>; advice encouraged.</p> +<h2 id="gossamer-network-primitives">Gossamer Network Primitives</h2> +<p>The Gossamer network is built around a gossip protocol, wherein <em>nodes</em> +connect to one another periodically to exchange <em>messages</em> 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.</p> +<p>Gossamer bootstraps its network using a number of paths:</p> +<ul> +<li> +<p>Gossamer nodes in the same broadcast domain discover one another using UDP + broadcasts as well as Bonjour/mDNS.</p> +</li> +<li> +<p>Gossamer can generate <em>locator</em> strings, which can be shared “out of band” + via email, SMS messages, Twitter, graffiti, etc.</p> +</li> +<li> +<p>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.</p> +</li> +</ul> +<h3 id="locators">Locators</h3> +<p>A Gossamer <em>locator</em> is a URL in the <code>g</code> 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.</p> +<p><strong>TODO</strong>: Gossamer and uPNP, what do locators <em>look</em> like?</p> +<p>When presented with an identifier, Gossamer offers to <em>follow</em> the identities +it contains, and uses the <em>nodes</em> 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.</p> +<p>(Clever readers will note that the address list is actually independent of +the identity list.)</p> +<h3 id="gossip">Gossip</h3> +<p>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.</p> +<p>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. +(<strong>TODO</strong>: how?)</p> +<p>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 <em>does not</em> +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.</p> +<p>During each exchange, Gossamer nodes send each other one Gossamer node +address, and one Gossamer message. Both nodes adjust their freshness +databases, as above.</p> +<p>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.</p> +<p><strong>TODO</strong>: How do we avoid DDOSing brand-new gossamer nodes with the full +might of Gossamer's network?</p> +<p><strong>TODO</strong>: Can we reuse Bittorrent's DHT system (BEP-5) to avoid having every +node know the full network topology?</p> +<p><strong>TODO</strong>: Are node-to-node exchanges encrypted? If so, why and how?</p> +<h3 id="authenticity">Authenticity</h3> +<p>Gossamer node addresses are not authenticated. Gossamer relies on freshness +to avoid delivering excess traffic to systems not participating in the +Gossamer network. (<strong>TODO</strong>: this is a shit system for avoiding DDOS, though.)</p> +<p>Gossamer messages <em>are</em> partially authenticated: each carries with it a +public key, and a signature. If the signature cannot be verified with the +included public key, it <em>must</em> be discarded immediately and it <em>must not</em> be +propagated to other nodes. The node delivering the message <em>may</em> also be +penalized by having its freshness reduced in the receiving node's database.</p> +<h3 id="gossip-triggers">Gossip Triggers</h3> +<p>Gossamer triggers a new Gossip exchange under the following circumstances:</p> +<ul> +<li> +<p>15 seconds, plus a random jitter between zero and 15 more seconds, elapse + since the last exchange attempt.</p> +</li> +<li> +<p>Gossamer completes an exchange wherein it learned a new fact from another + node.</p> +</li> +<li> +<p>A user injects a fact into Gossamer directly.</p> +</li> +</ul> +<p>Gossamer exchanges that fail, or that deliver only already-known facts, do +not trigger further exchanges immediately.</p> +<p><strong>TODO</strong>: how do we prevent Gossamer from attempting to start an unbounded +number of exchanges at the same time?</p> +<h3 id="size">Size</h3> +<p>Gossamer must not exhaust the user's disk. Gossamer discards <em>extremely</em> +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.</p> +<p>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 (<strong>TODO</strong> what size?) are discarded on receipt +without being stored, and the message exchange is considered to have failed.</p> + </div> + + + +<div id="comments"> +<div id="disqus_thread"></div> +<script type="text/javascript"> + /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ + var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname + + /* * * DON'T EDIT BELOW THIS LINE * * */ + (function() { + var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; + dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js'; + (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); + })(); +</script> +<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> +<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a> +</div> + + + + <div id="footer"> + <p> + + The Codex — + + Powered by <a href="http://markdoc.org/">Markdoc</a>. + +<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/gossamer/index.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/gossamer/index.md">history</a>). + + </p> + </div> + +</div> +</body> +</html>
\ No newline at end of file |