MUTE is a new peer-to-peer (P2P) network that supports anonymous file sharing, including search-and-download functionality. Using mechanisms inspired by ant behavior, MUTE can route information between two users without revealing the identity of the users to each other or to the rest of the network. In the wake of the recent RIAA lawsuits against individuals, MUTE has received a surge of attention from users who are interested in protecting the privacy of their online sharing activities.
This article provides an introduction to MUTE and how it protects the privacy of its users.
How to Use the MUTE Network
Before we delve into the details of how MUTE works, we will give an overview of how to install and use it.
MUTE is available in binary form for four platforms (GNU/Linux Intel, GNU/Linux PPC, Mac OS X, and Win32), with downloads available from the MUTE website.
A source distribution, which can be compiled on many Unix platforms, is also available.
During its first startup, a MUTE node asks for configuration information, including firewall status and the location of a shared folder.
MUTE also asks for random data to seed its cryptography algorithms---simply typing a long string of random keystrokes should be sufficient for most security purposes.
After generating an RSA key pair, which is used to encrypt connections to neighbor nodes in the network, MUTE displays the main user interface window.
MUTE's user interface should feel familiar to anyone who has used other file sharing networks.
The centerpiece is basic search-and-download functionality, while other screens display node status and provide control over various settings.
Upon startup, a MUTE node connects to Web-based caches that provide it with a list of other MUTE nodes to connect to.
After a minute or two, the Connections panel should indicate that MUTE has discovered a few neighbor nodes in the network.
At this point, MUTE is ready to search.
The searching and downloading interfaces in MUTE are self-explanatory, so we will only touch on a few of the finer points here.
First, we might notice that each search result is accompanied by a "virtual address" instead of the IP address which we are used to seeing in other file sharing applications.
Each MUTE node has a unique virtual address that it randomly generates each time it starts up.
MUTE uses these virtual addresses to route anonymous messages through the network.
When you initiate a download, your request is routed through the network of MUTE nodes, using the virtual address of the file source, instead of being sent directly from your node to the file source using an IP address.
The next point we should mention is MUTE's hashing support.
For each shared file, a MUTE node computes an SHA1 hash value, which essentially acts as a unique fingerprint for a file.
Along with a source virtual address, the search results include a hash for each file.
This hash can be used to locate file duplicates in the network (files that may differ in name may have the same contents, and the hash will reflect this).
MUTE supports searching for a file by its hash.
For example, if a file has a hash value of 7AEA3...98A, it can be located by entering a search for hash_7AEA3...98A.
How MUTE Routing Works
The MUTE network is comprised of a mesh of neighbor connections.
Each MUTE node maintains small number of neighbor connections (for example, the default is five connections), and these connections are made using IP addresses and standard TCP sockets.
Each node creates a random virtual address for itself upon startup, and it uses this address to send and receive messages through the network.
Messages are routed through the mesh of connections, and virtual addresses are used to direct messages from senders to designated receivers.
For a given virtual address, no node in the network knows which node owns the address, not even the neighbors of the addressed node.
Thus, MUTE must solve the problem of "routing blind," so to speak, since we have no information about the exact location of a given recipient.
MUTE's distributed routing algorithm is inspired by the scent-based navigation that ant colonies use.
As ants explore their environment, they leave behind trails of chemical scents known as pheromones.
When an ant finds food, it heads back to the nest, leaving behind even more pheromone.
Other ants are like to follow strongly-scented trails, so they are lead toward the food source, reinforcing the scent as they go.
Since shorter trails receive more traffic than long trails (in a given time interval, more ants can complete a round-trip on a shorter trail than on a longer trail), the scents on short trails become stronger over time.
Eventually, most of the ants in the colony walk along a rather direct trail between their nest and the food source, often in the familiar "straight line" army formation.
Each message that travels through the MUTE network leaves its sender's "scent" on each connection that it passes through.
These scents can be used later when directing messages back to the corresponding senders.
For example, if a node X has five neighbors, and it receives a message "From Alice" from neighbor 3, the node can remember that messages from Alice have been seen coming from neighbor 3.
In the future, if node X receives a message "To Alice", it can send this message on to neighbor 3.
Of course, neighbor 3 may actually be Alice, or neighbor 3 may just be one step closer to Alice.
In any case, node X has no precise information about where Alice is in the network: it only knows which direction she is in.
The same holds true for other nodes along a path to Alice, and only Alice herself knows that she is indeed Alice (she silently consumes messages "To Alice" without passing them onward).
This kind of local routing has several nice properties.
First, routes can dynamically respond to changing traffic patterns, automatically picking the fastest paths with the lowest traffic levels.
Second, broken routes can repair themselves with local "patches" (for example, by circumventing a node that disconnects from the network), much in the same way that ants find their way around an obstacle that is placed in their path.
More information about MUTE routing and ant behavior, including diagrams, can be found on the MUTE website.
MUTE File Sharing
The MUTE routing mechanism gives us the ability to pass messages anonymously from a sender to a receiver.
With this primitive in hand, any number of communication services are possible.
The first MUTE-based application builds file sharing on top of this routing primitive, and we will give a few details about how this works.
General searches in MUTE are broadcasted instead of being routed.
In a broadcast, each node passes a message on to all of its neighbors instead of forwarding it to just one of its neighbors.
MUTE uses a novel mechanism called utility counters (UCs) to limit how far a search can go in the network and to control the share of network resources that a search can consume.
A detailed discussion of UCs is beyond the scope of this article, but more information is available in Scalable Real-time Search in P2P Networks.
A given search will reach many nodes in the network, and those with results route MUTE messages back to the search's sender.
As mentioned earlier, each search result includes the virtual address of the node that is hosting the file.
For file transfers, MUTE splits files up into multiple chunks, each of which are routed through the network as a separate message.
Thus, to download a file, a node routes a series of chunk request messages to the file source node, and the source responds to each of these by routing back the requested file chunk.
Trade-offs
Since file transfers pass through several nodes, instead of directly between uploader and downloader, they can be substantially slower than downloads in other networks.
For example, even if both the uploader and downloader are blessed with T1 connections, the only viable route between them may pass through a node with a modem connection.
The speed of a MUTE transfer is limited by the connection speed of the slowest node on the transfer route.
Of course, we cannot get anonymity for free, and it is impossible to build an anonymous direct-download system.
A system that uses a fixed number of "download proxies" for each transfer would certainly result in faster downloads, but it would be vulnerable to attack, especially if the proxies cannot be trusted.
For example, a system that uses a single intermediary node to anonymize transfers would break when the intermediary node was compromised.
The anonymity of MUTE transfers, given that they pass through a variable number of intermediary nodes, cannot be broken even if every intermediary node is compromised, since there is no way for the attacker to prove that there are not additional intermediary nodes involved (for example, the suspected uploader and downloader could themselves be intermediary nodes).
Thus, MUTE trades download speed for anonymity, and users must weigh the value of fast downloads against the value of privacy before they decide to switch from other file sharing networks to MUTE.
Of course, users have been willing to make trade-offs in the past to avoid legal confrontation, and we will discuss these trade-offs in the following sections.
As the legal landscape evolves, other anonymous file sharing systems will certainly emerge.
Given the slew of recent user-directed lawsuits, it is safe to say that the heyday of non-anonymous file sharing will soon come to an end.
However, with the advent of anonymous alternatives, the battle over the future of file sharing is just beginning.
A Brief History of Online File Sharing
In the early days of wide-spread Internet access, many files were too large to be swapped online, especially for users who were connecting from home.
This was particularly true for multimedia files: an uncompressed audio file for a five-minute song would take roughly two hours to transfer over the fastest available modem.
Users who had faster connections (for example, students at universities) were more likely to exchange large files online, but the wait involved for multimedia files was still substantial.
The wide deployment of the MP3 audio compression format changed the landscape substantially, making the wait times for high-quality audio downloads more tolerable, even over modem connections.
Initially, people shared collections of "favorite songs" as MP3 files on their websites, and Web search engines (at the time, Alta Vista was the most popular choice) were used to locate songs.
A crack-down by various copyright holders, primarily through "cease and desist" letters to Web hosting providers, quickly put an end to Web-based MP3 trading. However, a search for "mp3" in Google will still reveal traces of residue left over from the Web-MP3 boom, which ended over three years ago.
Enter Napster, a seemingly viable alternative to Web-based MP3 sharing. Each user downloaded and ran a Napster client, while Napster, Inc., maintained a bank of index servers that tracked the files being shared by each client. To search, clients would send requests to Napster's index servers, and the servers would send back addresses of other clients that had matching files. To download, clients would connect to each other directly. Since files were no longer being hosted through always-on Web servers, but instead through comparatively transient Napster clients, there were no hosting providers to send "cease and desist" letters to. Napster, Inc., was only indexing content and not distributing the files directly, so it was apparently free-and-clear. The key word is "apparently": the record labels, and ultimately the courts, did not agree, and eventually Napster was shut down, index servers and all.
Just as Napster began to face legal troubles, an alternative came on the scene.
Gnutella was similar to Napster in many ways, but it was completely decentralized: it required no bank of index servers and no corporation to run it.
Each user ran a Gnutella node that acted as both a download client and a mini index server, indexing only its own files.
Search requests were flooded throughout the network, hopefully reaching as many other nodes as possible, and results were routed back.
Downloads happened much in the same way as they happened in Napster, with the nodes connecting directly to each other.
Gnutella, as a network, has been impossible to shut down completely, especially when compared to the quick legal death of Napster.
Shutting down the Gnutella network would involve shutting down every single Gnutella node, and there are millions of them.
Several other networks emerged after Gnutella and usurped it in terms of popularity, most of them improving upon Gnutella's scalability.
The most popular network today is Fasttrack, and the most popular Fasttrack client is KaZaA.
Realizing that they could not attack these decentralized networks with top-down techniques, copyright holders (such as the RIAA) attacked from the bottom up, filing lawsuits against individual users.
To target an individual with a lawsuit, the RIAA simply connected to the KaZaA network and performed a search.
The list of search results contained the Internet (IP) address of each person who was sharing matching files on the Fasttrack network.
By sending a subpoena to the appropriate Internet service provider (ISP), the RIAA was able to translate IP addresses into the names and mailing addresses---with this personal information, the RIAA was able to file lawsuits.
Though the RIAA has not succeeded in dismantling the Fasttrack network entirely, they have certainly scared away many would-be users.
MUTE's Place in the Timeline
The historical progression of file sharing techniques can be distilled into the following trend: file sharing has become less centralized and more anonymous over time.
Each step in the progression, from the Web, to Napster, and then to Gnutella, has been motivated by circumventing the legal tactics of the day.
Unfortunately, this trend has forced file sharing to become less scalable and efficient over time, as more information is exchanged through a network of peers instead of directly from sender to receiver.
Motivated by the RIAA's latest user-directed legal tactics, MUTE represents the culmination of these trends, as downloads themselves are routed through the peer network to ensure complete anonymity.
Users in the MUTE network are immune to the spying techniques that are possible in direct-download networks like Gnutella and Fasttrack.
Since each each download potentially passes through several nodes as it travels from uploader to downloader, MUTE is much less efficient than a direct-download network.
However, decentralized networks are much less efficient than Napster, and Napster was arguably less efficient than the Web---we simply cannot improve privacy for free.
Just as users were willing to move from Napster to Gnutella as the legal landscape changed three years ago, they have been willing to move from Fasttrack to MUTE to protect their privacy today.
Jason Rohrer is the lead developer for several open source projects, including MUTE, konspire2b, minorGems, and tangle. He is also a writer, artist, and musician, as well as an activist for personal freedom. He lives voluntarily poor and job-free, dividing his time between parenting and personal projects.
|