Jason Rohrer is the developer of the MUTE file sharing application, which claims to make its users anonymous and is currently in beta testing. Jason Rohrer is also the author of fictional and non-fictional literature, all of which can be found at his website. Zeropaid decided to catch up with him to find out what MUTE is about and to ask those circling technical questions.
This interview was conducted for www.zeropaid.com by Malicious Intent.
Zeropaid: What made you decide to make a p2p application?
Jason: I have been working on p2p for nearly four years now, and it has become the focus of my research and programming. Like many other people in p2p, I was inspired by Napster, and I started working on a decentralized alternative (konspire 1.0) in 2000. Of course, that was right at the time when Gnutella was taking over for Napster, so konspire never caught on. More recently, I developed konspire2b, a p2p network that focused on efficiently broadcasting content instead of search-and-download. Since konspire2b uses p2p ideas in a different way than most people are used to, it has been slow to catch on, though I still plan to work on it more in the future.
MUTE was partially inspired by Nullsoft’s WASTE. WASTE had some great ideas, but it was intended for small, private networks, and it couldn’t scale to support thousands, let alone millions, of simultaneous users. The scalability issues primarily came from the fact that WASTE was using message flooding for everything: each chat message and file chunk request was delivered to every node in the network.
I read Thomas Pynchon’s novel, “The Crying of Lot 49″, which was the inspiration for WASTE. That book describes an elaborate underground postal system (called W.A.S.T.E.) for delivering paper messages. But the way Pynchon’s WASTE system worked was much more elegant than the way Nullsoft’s WASTE software works. Messages in Pynchon’s WASTE were tagged with destination numbers, much like post office box numbers, and it seemed to me that these messages were being routed from person to person until they reached their destination. It also seemed that senders and receivers in Pynchon’s WASTE could be anonymous, which was something that Nullsoft’s WASTE didn’t explicitly support.
With Pynchon’s WASTE as an inspiration, MUTE focused on routing instead of flooding for message delivery, and it also focused on keeping both senders and receivers anonymous. Of course, if no one knows who or where a particular receiver is, how can a message be routed to that receiver?
When I lived in Santa Cruz, CA, a colony of ants invaded my house and built their nest in a indoor planting (a ficus tree rooted right into the floor of my living room). I battled them, albeit in a humane manner, for months, trying to disrupt the pheromone trails that they were using to find their way in and out of my house. They always found their way around any obstacle that I constructed, so I eventually gave up the fight and learned to live with them. Of course, each ant was really “routing” itself in and out of my house, even though it probably didn’t know exactly where its destination was. This is similar to a message that needs to get to a receiver without knowing exactly where that receiver is: the message can follow the “scent” left by previous messages from that receiver.
After MUTE routing was working, I collaborated with the guys from Downhill Battle on a defense fund for people who had been sued by the RIAA. We talked a lot about the RIAA’s legal tactics and about the future of the music industry. I realized that MUTE routing could be used for anonymous file sharing, and anonymous file sharing could be used to defeat the RIAA’s current legal tactics, so I got to work building file sharing on top of MUTE.
Zeropaid: MUTE has made an impressive impact on the p2p scene and has got many file sharers and developers talking about anonymity and the future direction of p2p applications. Interested readers can discover exactly how MUTE works from the website, but please briefly explain what makes MUTE different from other networks, such as Fasttrack.
Jason: The core difference is really the way MUTE handles downloads: they are routed through the network instead of going through a direct uploader-downloader connection.
Fasttrack (KaZaA), as an example, routes search requests and results through the network, but attaches an IP address to each result. When you want to download a file, you connect to the IP address and download directly from the person who is sharing that file. Thus, you know their IP address, and they know your IP address. Sounds fine, but what if the RIAA is the one doing the searching? Then they can see which IP address is sharing particular files. An IP address, combined with appropriate legal action against your ISP, can be translated into your name and address.
In MUTE, all messages are routed through the network based on virtual addresses (random strings), not IP addresses. Each MUTE search result comes with a virtual address that your node can use to request that file, but your request and the file data itself are routed through the MUTE network. The file data may pass through several other MUTE nodes on its way from the sharing node to you. Your node never finds out the IP address of anyone that you download from, and the nodes that you download from never find out your IP address. This also means that the RIAA cannot find the IP address of someone who is sharing particular files.
Zeropaid: The MUTE system for finding the shortest route from the seeding node to the destination node makes no consideration to user’s connection speed. Does this mean that users may have to wait for a dialup user to download and upload their requested file before their download starts?
Jason: Connection speeds are taken into account automatically by the routing algorithm. When we say that MUTE finds the “shortest” route, that really means “the fastest route”. When you think about the ant analogy, the shorter routes usually are faster, and that’s why you often see ants walking in a straight line. More ants pass over the shorter routes in a given period of time than over the longer routes, so the scent on the shorter routes becomes stronger. The same is true for MUTE routing, except that other factors can affect the speed of a route, including network traffic and connection speeds.
If you are downloading a file through MUTE, and traffic suddenly increases along the route that you were using, the MUTE network can react to this and discover another route. Also, if there are several possible routes between you and another node, but one of those routes happens to be going through a dialup connection, MUTE routing will choose one of the other, faster routes.
Even if the only available route passes through a dialup node, you still won’t have to wait for the dialup node to download the entire file before your download starts. MUTE splits all file transfers up into chunks that are 22 KiB in size, so you will only have to wait for the dialup node to transmit one of these chunks before you see your download start.
Zeropaid: If a node acting as a proxy completes the download and then logs off, does the network realize that data has been lost? How does the seeding node know to reseed the file? How long does the requesting node wait until it requests the information again?
Jason: Since MUTE File Sharing uses chunk-based transfers, there aren’t “proxies” that must complete a download before you get it, only nodes along the route through which your chunks are sent. If a mid-route node logs off and causes one of the chunks of your download to be dropped, your MUTE node will send another request for that chunk. The new request will travel over a repaired route between you and the file source.
It’s probably best to think of MUTE routing as a black box: you put a receiver address on a message and drop it into the network, and the message is routed to the receiver. MUTE File Sharing was built on top of this black box. You drop a chunk request into the network, and you wait for your chunk to come back. As nodes join and leave the MUTE network, the routing algorithm automatically discovers new routes as necessary. Even when a mid-route node drops out, MUTE routing can still deliver a message by finding a new route on-the-fly. This is demonstrated on the MUTE experiments page, which shows mid-route nodes dropping out of the network while a transfer is in progress.
Zeropaid: In your technical documentation, you refer to “cancerous nodes”. These are nodes on the network that are set up to corrupt data, damage the network or to collect information on users.
Would it be fair to say that a blackhat acting as a proxy could forward corrupted data?
Jason: Yes, cancerous MUTE nodes could corrupt messages and cause certain downloads to fail.
However, cancerous nodes are a problem in any P2P network. Imagine cancerous nodes in Gnutella or Fasttrack that corrupt search results, replacing valid IP addresses with bogus addresses. You would get back search results, but then every download you attempt would fail.
When you rely on other nodes to route data back to you, there is simply no way to prevent them from interfering. You can add checks to detect data that has been corrupted in-transit, but the only fool-proof mechanism is digital signatures, which require you to know the identity of the people that you are communicating with (you need their public keys before you can check that their digital signatures are valid). How can you get their public keys in a secure way? What if the cancerous node modifies their public key in-transit? Thus, in mass-scale networks like MUTE and Gnutella, digital signatures are not practical.
Of course, MUTE does check the SHA1 hash of every file that it downloads, so it can discard corrupted downloads. But what if a cancerous node corrupts both the hash and the download data? The only solution here would be to obtain the hash from an outside source (like a web-based hash index) ahead of time, since there is no way to completely trust a hash that you discover through a MUTE search.
So, this question leads us in circles. I think that it is impossible to have both true anonymity and true message security/integrity. We could add all kinds of semi-effective security “fixes” to MUTE, but all of these could be defeated by sufficiently sophisticated cancerous nodes.
If people are determined to annoy MUTE users with cancerous nodes, they will be able to. But how determined are people to do this? And why don’t we see massive search result corruption in networks like Gnutella and Fasttrack? Maybe people have better things to do with their time.
Zeropaid: All nodes in the mute network know the IP addresses of all their neighbour nodes. A cancerous node would therefore know the IP address of a node sending it copyright material. Is this a security loophole?
Jason: This is a legal question, not a security question: is it illegal to route copyrighted material unknowingly?
ISPs are provided protection by law: if their users violate copyright, the ISP is not liable, as long as they cooperate with the copyright holder to track down the violator.
I doubt that a MUTE node counts as an ISP in front of the law. However, there is a big difference between intentionally sharing a file and unintentionally routing chunks of it on behalf of someone else. If the RIAA decides to take this route against MUTE users (suing for routing instead of suing for sharing), the courts will have to decide.
The other point to keep in mind is that the RIAA can only sue for the provable damages caused by copyright infringement. That’s why they have been going after people who are sharing 1000+ files, since they can show that these people are distributing many files and therefore potentially causing huge financial losses for record labels. Transmitting a single file, on the other hand, results in very little financial loss for the RIAA, and probably not enough loss to be worth suing over. When they “catch” someone routing a single copyrighted file, I doubt that they will be motivated to sue that person. However, if they catch someone routing 1000s of files over time, they might be able to justify a suit. This kind of long-term monitoring is much more difficult than their current “search and write down IPs” tactic, so MUTE at least buys us some time if they plan to go this route. If you cannot safely transmit files through direct connections (Gnutella), and you cannot safely ! be a router (MUTE), then mass-scale file sharing (as we know it) is dead.
It would be nice to have a precedent here for the routing question, but we simply don’t have one (yet?).
Zeropaid: Could the problem of a cancerous node be made worse by it sending signals to suggest that it knows the shortest route to the destination node, hence attracting more traffic?
Jason: MUTE nodes engage only in local routing algorithms, and they do not communicate with each other about routing decisions. There is no way for a particular node to “attract” messages toward it by sending signals to other nodes.
However, a cancerous node could influence other nodes’ local “scent” trails by sending out lots of falsely-addressed messages (in other words, by pretending to be a particular virtual address). The scent from these messages would compete with the scent of the true messages from that address. This kind of address competition would cause problems for the particular virtual address being attacked, though it could be easily overcome by generating a fresh virtual address (which is currently done each time MUTE restarts).
Zeropaid: Have the beta tests for MUTE proven successful?
Jason: At this point, MUTE is quite stable and functional. People are able to download large files through it, and I have heard very few complaints about the latest version (0.2.2).
Downloads, of course, are slower than what you would see in a direct-connection network like Fasttrack or Gnutella, but they are fast enough to be usable. You cannot get anonymity for free.
Zeropaid: What properties of MUTE do you hope to achieve for the final release?
Jason: Search scalability is a huge problem in any p2p network. I’m current working on making MUTE searches more scalable.
Other features that might be added include:
–Magnet URIs
–Resumable transfers
–Multi-source transfers (swarming)
–Download queues
Zeropaid: Where do you see file sharing next year? What about 5 or 10 years time?
Jason: File sharing will survive. Historically, we have programmed our way around whatever legal tactics they throw at us, and we will continue to do so. If the RIAA makes mass-scale file sharing too risky, then people will continue to move to private, invitation-only networks. This change would be sad, since a massive, instantly-available, free collection of music is an amazing resource for research and social purposes. Ten years ago, we couldn’t imagine every song being at our fingertips, and now we have that.
I think that what happens over next few years will determine where file sharing will end up in five or ten years. If the RIAA wins outright, then all we will have left will be the private networks. If the RIAA loses outright (i.e., goes bankrupt), then we might not need file sharing at all: we can go back to web sites featuring “My Favorite Songs”. If the RIAA’s attacks get no more sophisticated than they are right now (suing for sharing based on IP addresses), everyone will be using anonymous file sharing networks (either MUTE File Sharing or its successors) in five or ten years.
Zeropaid: Thank you for your time and your contribution to the file sharing community. I trust that we will be seeing more of you in the Zeropaid Forums.
