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

[Random Tor Node Operator <tor@xxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2013 07:04 PM, Mark McCarron wrote:
>> 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.

It is rather obvious that resources are always finite in the end.

The naive idea of payments being a savior to all scalability problems
is what bugs me.

a) It would introduce a single point of failure (the payment gateway).
b) Consequently, the user would not be in full control of their
service anymore.
c) Also, it might have legal implications if Tor started to collect
money to set up some HS which later is found to be subject to prosecution.
d) It would be an undemocratic entry barrier to Tor.

If you fear somebody would fill up all storage alone, check out [4] in
my last message. Technical measures against this kind of attack do
exist. Without money being involved.


> 
>> 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.

See above. That obscure payment gateway would be a single point of
failure for any and all HS.


> 
>> 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.


So you want to lock out the poor guys because you think Tor might
scale better that way?
And where exactly does the introduction of an additional single point
of failure make it "easier"? And where "more secure"? Nowhere!
As long as the user cannot create a HS anymore like now, where they
generate a private_key and keep in their (and only their) hands, your
proposed system is surely *less secure* and *more complicated*,
because that obscure payment gateway would have a say in the creation
of such private_key (or similar) files.

Also, the feds could simply seize the obscure payment gateway or force
Tor to shut it down or interfere with it the way they like (because it
would obviously be under control of the Tor project) and thus render
their targeted HS useless, at least after a while. It could, depending
on the implementation, render *all* HS useless, but that's like what
they did before, with FH. As far as I can tell, legal services were
hosted there, too, yet they were all being destroyed as collateral damage.

The Tor project must never, ever, have any say or technical influence
in what people do with it, or they will be subject to terrible
liabilities. Your payment thing would do just that.

>> 
>> 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.

So you think running Tor relays is *not* helping the Tor
infrastructure? Interesting.

As far as I can tell, the current system works. For every so many
"ordinary users", Tor attracts one person who is willing to run a
relay, bridge, or submit patches or whatever.
Scalability in general *is* a problem, but none that can be solved by
introducing a paywall for users.


> 
> 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.

It does indeed make sense. It is called "solidary group" or "shared
risk pool" and is frequently used in insurance schemes.

You have a pool of resources (in case of distributed static file
hosting: bandwidth usage, disk space, CPU cycles) and it is evenly
distributed along requests. Best effort. And as long as the pool is
sufficiently large, it works. And yes, it would indeed be too much to
specifically ask HS operators to pay for their specific use case. For
privacy reasons alone.


> 
> 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.

As long as the fraction of people willing to contribute to the network
and the "ordinary users" stays at least constant, this aspect of
scalability won't ever be a problem.

If you want to offer a commercial hosting service within Tor, give it
a shot. You could charge your users proportional to the resource
consumption they require. And it would all scale so damn well! You
could buy new hardware and all from your revenues!

Or, if you simply want to set up a regular Tor relay, you can email me
off-list, I will gladly assist you.


> 
>> 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.

In your proposed paywall scheme, I don't see "better services", I
don't see "secure options", and the extortionate "choice" of "slow for
little, faster for premium" is not a choice I want to be exposed to.


> 
>> 
>>> 
>>>> 
>>>> 
>>>>> 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.


Alright, I'd say make it workable for Tor and submit some proposals
and/or patches with this functionality.
If it gets accepted it would surely satisfy the criteria I defined
above, and I will then gladly share something around 100 gigabytes on
my relays for that.



> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> 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. :)

Congratulations, that's what's called Chilling Effect. It is pretty
much what Tor is aiming to eliminate. People should speak freely.

Please do away with your paywall idea.


> 
>>> 
>>>> 
>>>>> 
>>>>> 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. 
> 

Go ahead and do it, make a start page for Tor as a HS.


Best regards,
- --RTNO
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSi8naAAoJEJe61A/xrcOQUqcP/102exBi5Je/rFduRnZ2osPn
LL+GJBex9d8Ml/w8fjwDjZ8y7l9jmldAmIEzq3HmwQjd8yZgnRAtDTn5eo7iW4e1
4kDx8wQtxudXFb+hYgOEZUc4lRJo+nGcJ2oFSGGOHY4l393DWW8jwUag1cAIvq3j
Ny7d8xD4PF7pyx0hs5nKP9TEK/uNlHUwOMDJQQkrsFoYGKq5Pqe/LXyc4xdW4LU0
Dls+dP7OR4ijOvs7lUb0sNLJtaQfo4lpHW5dGvbuwmf1bMunndDPJ3hR5jnTSJhl
d6DGcov5TPfPCrC8p1KEVs3iIq+KjGwWoywu0nhTwbtN3+4y5qRCfDHLJWXQXNkc
2TrspURdHi+FzXAQQ1gajHHRxHZlroyLt22tauE56rnC121dz3ubw7cxrQOLEzgd
blRubVZCS6iHICuNlacUwfWZSKmdSVZ470gMg6dUTt0fCS1W4+jVo65qdQT19qNx
guKjWfaLKExaoGuyUxHRBgkBRO5n6pH7J2FOChdwgI2M2nX8eqwOycOmuAaJHXaI
6xNHNPx6AiEzlOPRu19dGXzAwDhVGzhKJtbzY9x4HimZPQrxOKmGcVqa4/swu/ef
pIHwB2cIuF2gH4616JQyF5Z/HeSsx2sLirtsstMqwh6beOV1M4/exstZX1FWphed
3TiXEIGNHY2p1rIPkvzN
=R0Ml
-----END PGP SIGNATURE-----
-- 
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