Re: [tor-talk] New TOR Service Suggestions and Enhancements

[Mark McCarron <mark.mccarron@xxxxxxxxxx>]

> Date: Tue, 19 Nov 2013 11:47:06 +0100
> From: tor@xxxxxxxxxxxxxxxxxx
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] New TOR Service Suggestions and Enhancements
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/19/2013 06:50 AM, Mark McCarron wrote:
> >> Date: Mon, 18 Nov 2013 21:11:40 +0100 From:
> >> tor@xxxxxxxxxxxxxxxxxx To: tor-talk@xxxxxxxxxxxxxxxxxxxx Subject:
> >> Re: [tor-talk] New TOR Service Suggestions and Enhancements
> >> 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 11/18/2013 05:23 PM, Mark McCarron wrote:
> >>> With all the recent crack downs on civil liberties, seizure of
> >>> TOR services and general censorship that is now hitting even 
> >>> mainstream search engines, I would like to propose a set of new
> >>>  services and some enhancements to the network layer to improve
> >>>  anonymity. We need to get as much support as possible behind
> >>> these services and improvements as they will assist in both
> >>> the expansion and self-funding capability of TOR going
> >>> forward.
> >>> 
> >>> The following services have been suggested and will require a
> >>> fee, paid in Bitcoins, which will be donated to the TOR
> >>> project. This is a security measure to prevent saturation of
> >>> the services. These services should be integrated into the TOR
> >>> software and run in a distributed fashion.
> >>> 
> >>> 1.  Distributed Web Hosting
> >>> 
> >>> Currently, anyone hosting a hidden service must provide their
> >>> own hosting solution and use software to provide access to the
> >>> TOR network. This strategy has seen increasing number of
> >>> services taken down in raids by various governments. We require
> >>> a distributed hosting solution that provides a web server and
> >>> database to anyone. The requirements for the service are as
> >>> follows:
> >>> 
> >>> a.  Payment gateway that accepts Bitcoins and either generates
> >>> a new site, or renews a previously generated private key. This
> >>>  gateway should retain no knowledge of any transaction, or the
> >>>  ability to revoke a site once generated. Sites should 
> >>> automatically expire after a given date, unless the private key
> >>> is renewed. Private key renewals should not require the private
> >>> key to leave the client-side.
> >>> 
> >>> b.  Sites can be hosted at any node in an encrypted server with
> >>>  redundancy options (whack-a-mole) and automatic replication
> >>> between nodes. No node should be able to inspect what it hosts
> >>> in any fashion. A premium can be paid to increase replication
> >>> times.
> >>> 
> >>> c.  Should provide a set minimum of traffic capacity, a
> >>> premium can be paid to increase that capacity or link sites to
> >>> build a larger service (i.e. multiple front-ends, database
> >>> clusters). A Bitcoin pool should be created that providers of
> >>> this service can be paid from to compensated for the increased
> >>> processing.
> >>> 
> >> 
> >> While I strongly agree that a distributed HS system would be
> >> very desirable, I find the idea to make it dependent on any kind
> >> of payment very appalling.
> >> 
> >> Especially your point 1c, which is exactly what many ISPs try to
> >> force upon their customers nowadays. Be on the slow lane or pay a
> >> premium. And what if a critical mass of users is already on the
> >> fast lane? Thanks, but no thanks. Best effort should remain the
> >> way to go.
> >> 
> >> What you call the gateway would also be a single point of
> >> failure. Unless that gateway was decentralized, too, some TLA
> >> could simply decide to seize it because one of the countless
> >> Hidden Services was doing something bad. Consequently, all other
> >> HS would fade out when their keys expire.
> >> 
> > 
> > In an ideal world, there would be no payment system.  In the world
> > as it is today, we must deal with both abuse of a system and the
> > realities of the costs of operating a system.  In respect to the
> > latter, we cannot live in some hippy freeloader universe.
> 
> Can you specify what kind of abuse you are expecting to prevent by
> introducing a payment system?
> 

In a distributed system there are finite resources.  Only so many web sites, file hosting sites, VM's, can be hosted at any one point in time.  It would be easy to consume these resources on a free system.  By billing for them, it would cost a lot of money to perform this kind of attack.

> Don't even think about letting the Tor project have the power to disable
> a given HS. It would make them subject to legal liabilities and
> harassment at its finest. IANAL, but in principle, the Tor project
> would then be responsible for any and all HS and anything and
> everything people might do with it. That would, likely literally, be
> fatal for Tor.
> 

I completely agree.  There would be no mechanism for this.  All that payment gateway does is take payment, request that a new hosting site be provides, present the credentials to the user.  The expiry of the hosting service would be a done within the hosting software and is just a countdown to a specific date, or lack of use.

> You seem to view payments as a viable way to prevent abuse. Have a look
> at the "Real World", where nearly everything is subject to fees. No
> abuse anywhere, right? It just does not work. Requiring payments *is* an
> entry barrier, but it does *not* filter out the bad guys, only the poor
> guys.
> 

Certainly, but it means that the consumption of resources on TOR is sustainable.  That is, there will be enough funds available to invest in additional hardware and expand the network.

> Also, the fact that everyone can trivially set up a HS without requiring
> anyone else's permission or going through any kind of potentially
> de-anonymizing process like a payment, is of the absolute key aspects of
> Tor.
> It is a very democratic, maybe even slightly anarchistic approach,
> without any gatekeepers.
> Doing away with that in an anxious attempt to reduce unspecified cases
> of abuse would be a terrible idea in my opinion.

The implementation of this service would preserve this and actually make it a lot easier and more secure.  The feds could not shut down a HS once launched.  There is no gatekeeper and existing tools to host hidden services would still be provided.


> 
> And I can only speak for myself here, but I would surely NOT run one
> single Tor relay if I knew that people using it were somehow required
> to make any kinds of payments for their use. I am only willing to do
> so because Tor is a "hippy freeloader universe" and I gladly support that.
> 

When websites, databases and users start consuming resources this model would be unsustainable.  There are costs associated with providing the necessary hardware and scaling the services.  You are, of course, welcome to pay those costs yourself but I do feel that is not supporting those who help provide the TOR infrastructure.

I am not asking that anyone aim for making a profit from this payment system, just that the funds are used to expand the service and ensure that it scales well.

> > 
> > In regards to 1c, you felt it was a type of net neutrality.  No,
> > that is wrong.  Think of it more like the difference between shared
> > and dedicated hosting.
> > 
> > The payment gateway would also be distributed.
> 
> Different wording, same meaning.
> That approach is based on discriminatory treatment as a function of
> coughing up money.
> As far as I can tell, that goes pretty much against the goals Tor is
> aiming to achieve.
> 

That does not really make sense.  Let's say I run a site that gets 100 visits a day and someone else runs a site that gets 1 million visits a day.  Both of these services require different architectures and supporting hardware resources to operate.  In a distributed platform, is it fair to ask users to host a solution to accept 1 million users without assisting towards the cost of that hosting solution?  Is such a model sustainable?  Ideals and goals are great, but there is also a reality, the hardware costs money.

Given that this reality exists and those who operate nodes have limited financial resources, how could we ever hope to scale the system on good will alone.  I am not seeking to dispose of the current architecture, merely provide an alternative that will allow for rapid sustainable expansion.

> If you are worried about the operating costs of node operators, have a
> look at this discussion: [1].
> 
> Notice that even if it were trivially possible to reimburse node
> operators according to some distribution scheme, you must take into
> account the implications of that.
> 
> When you suddenly introduce a financial incentive in running Tor
> nodes, the relative amount of idealism is likely to drop, because you
> attract people for financial reasons.
> 

I do agree on this point.  That said, what are the long term implications of this given the structure?  Very little from a practical viewpoint, we just see an expansion of the system and better services with a variety of secure options.  What we get is greater choice.

> 
> > 
> >> 
> >> 
> >>> 2.  Distributed File Hosting
> >>> 
> >>> Follows the same structure as web hosting, but provides an FTP
> >>>  service. Should integrate into the web hosting layer
> >>> seamlessly.
> >>> 
> >>> 3.  Distributed Virtual Machine Hosting
> >>> 
> >>> Follows the same structure as web hosting, but provides a
> >>> complete virtual OpenBSD/Linux platform. A Bitcoin pool should
> >>> be created that providers of this service can be paid from to
> >>> compensated for the increased processing.
> >> 
> >> This kind of approach would be needed to go beyond a "simple" 
> >> distributed storage for static files. How else would you host a
> >> HS which runs any kind of interactive content...
> >> 
> > 
> > The file hosting discussed on deals with ftp-like services.  If a
> > need is shows for other types of file hosting, it can be added, but
> > we should focus on core services first.
> 
> Go ahead and write a paper about how to implement a distributed static
> file hosting scheme to be integrated into Tor.
> 
> Proposed requirements:
> 
> - - Node operators define a certain, arbitrary amount of disk space they
> are willing to share for the service
> - - Files must distribute automatically among nodes, given some minimum
> redundancy (Maybe 3? Maybe the actual redundancy should automatically
> scale up if there is "enough" space available on the network?)
> - - Node operators (or anyone else, for that matter) must *never* be
> able to tell what files are currently (being) stored on their nodes.
> Obviously, everything needs to be entirely encrypted, so not even
> filenames or filesizes can be seen on any node.
> - - For scalability, there should at least be an expiry date and/or a
> way for the uploader to delete files afterwards, so the storage
> requirements don't run off beyond all bounds over time.
> 
> 
> And that is only the "easy" task with static files.
> 
> Try to come up with a viable system for distributed virtual machines!
> 

I have some experience in writing distributed filesystems on highly scalable networks.  I actually have some functional software for windows at present.  I would just need to add encryption and an access interface.  It should not be too difficult to implement.

For distributed VM's, it should not be too different to website hosting.  I could leverage existing tools such OpenStack or KVM.  The tricky part will be creating a management interface.  It is highly workable.

> 
> > 
> >> 
> >>> 
> >>> 4.  Distributed Web Indexer
> >>> 
> >>> Uncensored search of the entire internet.  Speed is
> >>> unimportant, as is the frequency of updates. The primary goal
> >>> is to make it uncensored.
> >> 
> >> Have you had a look at YaCy [1]?
> >> 
> > 
> > Not until you mention it.  This solution looks viable and should be
> > re-written and absorbed into the default install of TOR.
> 
> Why exactly should it be rewritten?
> 
> Feel free to come up with ways to integrate it into Tor... without the
> need for a rewrite.
> 

It is based on java and I'm not sure about the way the indexer works.  I would prefer a java-less solution if possible for security reasons.  If the solution can scale to millions of nodes and not require everyone to download a complete copy of the index, then it will be a simple port.


> 
> > 
> >> 
> >>> 
> >>> 5.  Distributed Email and Instant Messaging
> >>> 
> >>> Accounts can be purchased for Bitcoins, completely
> >>> decentralized. Speed of delivery is unimportant and should be a
> >>> best effort system. The inclusion of a "global broadcast" for a
> >>> premium is recommended. This latter services allows for
> >>> important announcements to be flashed across the world. The
> >>> premium should be set very high to prevent abuse.
> >> 
> >> Why do you want to sell anything and everything? The nice thing
> >> about Tor is that you can set up your own HS *without* the need
> >> for a central authority and *without* the need to pay anything.
> >> 
> >> For decentralized instant messaging (without the need to pay, I
> >> might add), have a look at TorChat [2]
> >> 
> > 
> > Its not about selling, its is about preventing the abuse of
> > resources and ensuring anything that requires servers can scale
> > with the user base rather than being contested.
> 
> See above.
> 
> 
> > 
> > TORChat solves the instant messaging issue and should be bundled.
> > Now we need a distributed email system.
> 
> Good luck with that.
> 
> In principle, you need the same requirements as for a distributed
> storage of static files, plus some more, because only the recipient
> must be able to read and delete their emails.
> 
> Also, perfect forward secrecy [2] might be desirable for emails.
> Something that is not available for example with GPG.
> 
> Maybe you should also have a look at Bitmessage [3].
> 

There is another thread on this list talking about a distributed email system in development, so it looks like there may be a solution in the works.  I'll keep an eye on it.


> 
> > 
> >> 
> >>> 
> >>> 6.  Distributed News Service
> >>> 
> >>> Pay a premium and post your story.  This will ensure only 
> >>> important news hits this newswire.
> >> 
> >> Yes, because those with most money and willingness to pay are
> >> those with the most important news for everybody.
> >> 
> > 
> > It would be a token amount, its just to prevent spam mainly.
> 
> There are better concepts than money against spam [4].
> 
> 

I find when people need to part with cash, they tend to be very shy. :)

> > 
> >> 
> >>> 
> >>> 7.  Distributed Start Page and TOR Index
> >>> 
> >>> TOR needs an entry point, somewhere that provides access to all
> >>>  services and can guide users through the system. Many sites
> >>> have tried to serve this function, none have survived.
> >>> 
> >> 
> >> Do you realize that one of the points of a *Hidden* Service might
> >> be that it does *not* show up in a publicly available list of
> >> services?
> >> 
> >> Feel free to create a HS for users new to Tor, which exemplarily 
> >> introduces the users to some Hidden Services cherry-picked by
> >> you.
> >> 
> > 
> > I understand that, I'm thinking of an automated directory similar
> > to TORDir where you manually add services and ones that fail a
> > given number of checks get pruned from the system.
> > 
> > Creating a hidden service to act as a start page, or gateway, for
> > users has been tried time-and-time again.  Look at core.onion, gone
> > in a flash.  We require something more robust. 
> 
> Can you explain why exactly we require that? There is no global index
> of the "normal internet" either, at least none that is intended to be
> used by humans.
> 

The distributed services require an interface of some form and bundling it all together into some start page, or gateway, with a few other services sounds like a good idea.  It also helps new users find their feet on the network and branch out.
 		 	   		  
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk