E-COMMERCE NETWORK FOR BLACK MARKET GOODS AND SERVICES

The eCommerce Network for Black Market Goods and Services is an anonymous network that enables people to engage in the exchange of illicit or embarrassing goods and services. All transactions require the use of a total of 3 nodes. The network consists of a single mediator node and n number of client nodes. Client nodes can act as either a customer node or a vendor node in any exchange.

Users request to be added to the network by contacting the mediator node via email with a list of things they have for offer/sale and/or a list of items they would like to obtain/purchase. Each client node only knows how to contact the mediator node. The mediator node doesn't know the physical identity of client nodes. The mediator node simply knows what each node has requested or offered and an email address for that node. The mediator node is responsible for directing messages back and forth between nodes that wish to engage in exchange. The network does not govern or mediate the actual physical exchange of goods that are offered or requested. Such details are left to the nodes engaging in the transaction.


Network Characteristics
  • What are the nodes in this network made of? They are made up of people. There are two types: customer/vendor nodes and a single, central mediator node. The exchange of goods takes place outside the network.
  • What are the protocols this network uses in arranging its connections? The transmission layer uses regular email protocol. Customer/vendor nodes (almost) only ever contact one node directly--the mediator node. Communication and negotiation between all nodes takes place anonymously. Only when a final agreement is made do the nodes determine the method of the exchange of goods.
  • How are the contents of the data actually passed from one node to the next? Messages are transported from one node to the next using email protocol over the internet.
  • What are the contents of this network? The contents of the network are messages passed back and forth between buyers and sellers.
  • What are addresses in your network? How is each node addressed? Addresses are email addresses.
  • What is the topology of this network? It is a centralized network, where nodes cannot communicate directly, but must* contact the central node to have a message routed properly. The central node then forwards that message to the appropriate client node.

  • *There is a single exception to this: client nodes may both request that the central node furnish their respective contact emails to the other. In such a case, the administrator does so and further communication and transactions between those client nodes are removed from the network altogether.

Stack
  • How do sending and receiving nodes handle the content? Nodes initially publish a list of items offered and/or a list of items wanted. Communication to other individual nodes is initiated in response to wanting to buy or sell specific items.
  • How is the content sent through the system? The content is sent through the system using email.
  • What layers is your transmission layer built on top of? The physical layer is built on top of the existing internet infrastructure.

Visual Explanation



Communications take place pseudonymously with the central node. The identities and the number of other nodes in the network are unknown to the client nodes.


Initial Predictions
  1. Messages will travel back and forth as fast as the central node is able to read and manually forward them to the appropriate nodes. It is assumed that the central node will be manually checking email a few times a day. So the speed of the network will vary, but messages should likely be forwarded to their appropriate destinations within 24 hours of having been sent.
  2. The network will be able to handle about 25 messages per day in total and about 3 per minute (when the central node is actually checking for and routing messages).
  3. The longest and shortest possible route is 2 hops.
  4. It is possible for some content never to reach its destination. The central node will not forward requests or offers for child pornography or volatile or highly-toxic materials.
  5. The percentage of content that will never reach its destination is difficult to predict, since that number relies on usage.

Predictions and Discussion

What It Was Designed To Do
The network was designed to enable its users to anonymously engage in the trade of goods and services that are embarrassing or illegal. Many people are afraid to attempt to buy, sell, or exchange a variety of things since they fear prosecution or are worried that people they know will find out or both. So my network was intended to allow people to try to fulfill their desires without fear.

Predictions About Operation
Before starting the network, I predicted that the network would be at least minimally successful in that I'd be able to route a few requests to a few offers and that, of those, at least one successful transaction would take place. I also believed that I would be able to do this without worrying about risk of prosecution. Regarding scale and the obvious network vulnerability presented by having a single node responsible for manually reading and routing every message, I predicted that in the course of a single week of operation, I would be able to handle all the traffic in a timely fashion. This prediction was correct. Of course, scale would be a very big problem if a certain number of users ever signed on and/or I (another central node administrator) became too busy to deal with the responsibilities of routing even a few transactions.

Predictions vs. Reality
Regarding the network's performance in a week's time, it was a failure. In the course of the week, I received a few request/offers (requests for a kidney, ecstasy, and marijuana and offers of marijuana, porn, movies, music and software). A couple of these requested/offered illegal goods also struck me as suspect in some way. I found that I was afraid to properly route or otherwise respond to these and the remaining illegal ones, since my identity as central administrator was easily discovered by anyone with even a little bit of determination. The remaining legal offers/requests I received didn't have corresponding buyers or vendors. So no transactions ever took place.

What I Learned in this Experiment
I learned that, for such a network to be successful, there needs to be a more robust level of anonymity and security built into the network for both users and administrator (assuming such a role would even exist in a re-designed version). It's difficult to openly promote such a network since such promotion would almost certainly attract the attention of those who would like to monitor and perhaps prosecute its users. For the purposes of getting some kind of results within a week's time, I posted instructions about the list and how to use it to a mailist list under a pseudonym. Promotion would likely need to take place via word-of-mouth (in much the same way that other clandestine networks function). User trust and willingness to engage in the network would likely come from a friend or other trusted source that has vetted the network and reported success in buying and selling particular kinds of items. The network's success would also depend on the routing process being automated, since manual routing would be too time-consuming for any but the smallest number of users, perhaps 25 total waiting for a matching response to an outstanding request or offer.


What I Would Do Differently

In a second implementation, I would focus on improving three general areas:

User and Administrator Security:
  • Robust Anonymity/Psuedonymity: Users must be able to feel reasonably certain that their identities will not be discovered by anyone.
  • Secure Exchange of Goods/Services: Users need to be able to engage in a secure physical exchange without compromising identity or at least without fear of compromising identity (perhaps once they make the connection, they're convinced that revealing their identity no longer matters).
Network Architecture - change from centralized star network to a peer-to-peer architecture:
  • The routing of user requests/offers for goods & services would need to not be the responsibility of a central node. Such an architecture creates two major problems. The first problem is the vulnerability of a network that can be completely disabled by the failure of a single node. The second problem is the amount of criminal liability that must be accepted by the single node responsible for reading and routing requests since such a network can be reasonably expected to be used for criminal activity.
  • Somehow (and I'm not sure how) the network would need to keep its users anonymous and secure while also protecting the liability of those responsible for the networks' existence. The responsibility of routing requests and offers would need to be somehow taken out of the hands of the administrators but also the users since vulnerability to prosecution is made possible not only by the actual exchange of illegal goods/services, but also by the routing of requests to offers. It's easy to simply place the physical exchange outside the network altogether, but much harder to offload the routing.
Promotion
  • Promotion would need to take place differently than in the experiment. Potential users would need to made aware of the network's existence via a more secure channel than broadcast email promotion, like in my initial experiment. In a future iteration, I'd likely rely on word-of-mouth promotion since people tend to only tell trusted friends about the existence of such things. However, if the two above goals were reached (security and architecture), the inherent legal risk in either creating or using the network would be eliminated.
© 2008 David Yates