I’m a user of Tor, the privacy protection software that slows the seemingly endless forces of internet data collection. This past week, Motherboard revealed that Carnegie Mellon University worked with federal agents to attack the privacy protections of the Tor network. While the attackers might argue these attacks were necessary and limited, we have seen similar situations where the tools created to do good things are co-opted to do not-so-good things.
A Brief Overview of Tor
The internet works like a giant game of telephone. When two people want to exchange a message, one computer must send a message to a peer, which then sends the message to its peer, and so on until it reaches the recipient.
Tragically for privacy, every step in that communication can suck up important “metadata” like the identities of the receiver and sender. This is a problem for all of us who are concerned with the vast swaths of personal data that might end up in the hands of advertisers, data brokers, insurance companies, employers and other malicious agents. The US Navy realized it was an especially dangerous problem for diplomats, armed services members, and pro-western activists overseas.
In response to the threat of data collection, the US Navy funded the design of an onion-routing protocol called Tor. Rather than passing messages between two users, it bounces messages between a number of proxies. Each of these proxies can see which proxy sent them a message and the next proxy, but they can’t see anything beyond that. With the addition of multiple layers of proxies, the metadata needed to track users online gets stripped away.
Notably, the privacy of the Tor network is dependent on maintaining a high layer of traffic. If an attacker can see that Alice sent a message at 3:24 and Bob received a message at 3:24, and if those are the only messages sent on the network that day, it is obvious they are communicating. In order to be effective, Tor would have to be a public network with a high level of organic traffic.
However, to convince people to use the network, the Navy would have to allow anyone to run a proxy. Few people would be comfortable relying on Tor if they knew every proxy was controlled by the US government. The reason for this is simple: if a single actor controls multiple proxies in a single message pass, that actor can unilaterally track the messages’ metadata.
In 2004, the Naval Research Laboratory released the Tor code under a free license. In 2006, the Tor Project began maintenance of the Tor network as an independent non-profit.
Tor’s Fundamental Weakness
While the privacy protections of Tor require a large number of proxies, there exists no incentives for users to provide them. Proxies are run mostly by volunteers or funded by non-profits. Without an incentive structure to support it, the infrastructure is under-resourced, load times are slow, participation is diminished, and privacy protections are eroded.
Most troublingly, access to the internet via Tor is frustratingly limited. Site owners mistake large amounts of traffic originating from a small number of proxies as a denial of service attack. After all, why else would a single IP address be generating the traffic of hundreds or thousands of average users? Well intentioned site owners often block or limit access to Tor users, forcing them to complete time-consuming captchas with every page load.
Smart Contracts and Why We Need Them
The blockchain allows us to trustlessly and cheaply transfer value between two parties that have never met. Coupled with smart contracts, it is a revolutionary tool for incentivizing the proxies needed for a more private internet.
Rather than simply passing messages between proxies, we could pass messages bundled with a micropayment transaction which, when submitted to the blockchain, compensates proxies. In other words, instead of telling Proxy A “Please relay this message to Proxy B”, we tell Proxy A “Please relay this message to Proxy B and here’s .0001c for your service.”
If the blockchain was simply a value transfer system without smart contracts, such a micropayment system would be unfeasible. Each single message pass would require a half dozen individual micropayments to be submitted to the blockchain. Multiply that by millions of users accessing hundreds of web pages a day and any blockchain would be overwhelmed. Luckily, smart contracts provide us with a way to trustlessly batch a large number of micropayments into a single transaction.
How to Bundle MicroPayments with Smart Contracts
Imagine Alice is a privacy conscious individual and wants to use a proxy owned by Bob. Alice creates a smart contract on the blockchain and locks up a small amount of value (~1USD). The rules of the smart contract are as follows:
- Only Bob may withdraw funds from this contract
- In order for Bob to withdraw funds from the contract, he must provide a signed transaction from Alice
- Once Bob withdraws a portion of the funds, the rest is returned to Alice
The third stipulation is perhaps the most important. It means that Bob can only withdraw funds from the contract once. After the first withdrawal, the remaining funds in the contract are automatically returned to Alice.
After Alice deploys her smart contract on the blockchain for Bob’s proxy, she repeats the process for dozens of other proxies scattered across the globe. Each of these smart contracts locks up a small amount of value (~$1USD) and has the exact same rules.
Let’s say that Alice, who happens to live in Amsterdam, wants to send a message to Ellen in El Salvador. Now that Alice has prepaid for the services of a number of proxies, she is able to send messages privately. She plans a route for her message that goes like this:
- Alice in Amsterdam
- Bob in Boston
- Charles in Chile
- Dan in Duluth
- Ellen in El Salvador
Alice then sends Bob her message, bundled with a signed transaction that says:
“Bob may with withdraw .0001c from our contract. Sincerely, Alice.”
Bob then passes the message to Charles, bundled with a signed transaction that says:
“Charles may with withdraw .0001c from our contract. Sincerely, Alice.”
The process continues until it reaches Ellen in El Salvador.
All the individual proxies, from Bob to Dan, may individually decide to submit their signed transaction to the blockchain. However, doing so would only release a fraction of a cent from the contract — a small reward compared to the transaction fee required to submit it. Rather than submit their transactions immediately, the proxy owners decide to wait, knowing that Alice will likely want to use their proxy again. After all, she has already prepaid ~$1USD, which she cannot unilaterally withdraw.
The next time Alice wants to use any of the proxies, she includes a signed transaction that says:
“The proxy owner may with withdraw .0002c from our contract. Sincerely, Alice.”
Note that the new signed transactions release larger amounts from the contracts (.0002c versus .0001c). The proxy owners can now submit a single signed transaction and be compensated for both messages. This micropayment batching compensates proxies for passing messages while minimizing the strain on the blockchain.
Beyond Privacy
While this post has focused on Tor and private routing, Tor is not the only routing system suffering from poor infrastructure incentives. The underlying internet is itself powered by a system of routers. This routing infrastructure is both enormously expensive and naturally monopolistic, characterized by extremely high fixed costs and low marginal costs.
In the developed world, this infrastructure works, but just barely. Consumers pay exorbitant fees to ISPs for low bandwidth, poor service, privacy violation, and too much junk mail. In the developing world, as well as in cases of natural disaster, political turmoil, and health pandemics, this infrastructure fails the people who need it most. Large, centrally planned organizations do not have the local knowledge that communities have and are prone to resource misallocation.
The same smart contract systems which power a network of proxies could also be used to power a network of routers. Individuals could join together in a mesh to provide the backbone of a more resilient internet. Micropayments at each route would incentivize users to contribute bandwidth. Such a system would be the framework for a new, more resilient and more equitable internet.
by Aakil Fernandes, Lead Developer of SafeMarket
