[tor-dev] Potential projects for SponsorR (Hidden Services)
griffin at cryptolab.net
Tue Oct 21 16:19:09 UTC 2014
Roger Dingledine wrote:
>> h) Back to the community again. There have recently appeared a few
>> messaging protocols that are inherently using HSes to provide link
>> layer confidentiality and anonymity . Examples include Pond,
>> Ricochet and TorChat.
There are also a fair few IRC and XMPP servers floating around
onionland (and soon to be many more via Stormy). I'm also really
curious what the impact that Pond would have on the HS landscape if it
become popular. Right now, there are probably only a handful of people
who run their own independent Pond HS, but that could change.
There's also onionshare, which creates hidden services as-needed --
which are typically discarded after sharing a single file one time.
>> It might be worth researching these use cases to see how well Tor
>> supports them and how they can be supported better (or whether they
>> are a bad idea entirely).
> Yes. My guess is that it's lightweight to establish a circuit with each
> of your friends, and then when it goes away you try to reestablish it
> and if you fail then your friend is probably gone. And my guess is that
> it's heavyweight to try rendezvousing with each of your friends every
> 5 minutes to see if they're still there.
> We should put up some guidelines for eco-friendly use of hidden
> in this situation.
Scott Ainslie and I came to the conclusion that two one-way video
conversations over hidden services is a pretty decent replacement for
Skype etc. At a really crude level, this can be achieved using
gstreamer (maybe with FreeNote) and then sharing the hidden service
addresses with each other. Some assembly required, obviously. It's my
undying wish that someone create a proof-of-concept app for this using
gtk or kivy or something.
>> == Opt-in HS indexing service ==
> The question of whether this has to be built-in is a fine one to
> explore. I bet we'd get more people doing it if it were just a torrc
> option that you can uncomment. But it also seems inherently less safe,
> since it might mean more publishings by your Tor than the human would
It would definitely get more opt-ins than if there were additional
steps. There's a measure of informed consent there, because if you are
opting in intentionally, then you are saying that you want your hidden
service publicized. Any given person running a library or art project
might think "Oh nobody cares about my hidden service" and not bother
going through additional steps, but would be perfectly happy to have
more people look at their work.
The question, to me, is how to frame the torrc option so as to make
sure people know it's optional.
>> - #8902 Rumors that hidden services have trouble scaling to 100
>> concurrent connections
I've been curious about this ticket for a while, and happy to
structure&run a follow-up test on a controlled server. Since the
original problem was with an IRC server, it makes sense to set one up
for the purposes of a test, and then set up a secondary machine for
'user' connections and an extra monitoring point.
I suspect that there are other factors that might have influenced that
report. Could it be an issue with one of the intermediary points?
There certainly *seem* to be tons of people using the OFTC hidden
service, but that could be perception (ie, still <100 concurrent users).
>> What useful projects/tickets did I forget here?
> 1) We should identify and describe the great use cases of hidden
> especially the ones that are not of the form "I want to run a website
> that the man wants to shut down."
One thing that is interesting: in practice, onionshare (RetroShare et
al) winds up being easier than trying to share a file with a friend
using third-party services. Particularly for large-ish files or
something where you want some measure of privacy (ohai dropbox), sending
it to a third-party and then making it available to your friend and then
deleting/hiding it again is a little annoying. (And there are of course
privacy and cost tradeoffs with this as well).
People like to set up private IRC & Jabber chats to chat without
attracting trolls and spambots, and get an extra layer of encryption
> What sorts of hidden service examples are we missing from the world
> we'd really like to see, and that would help everybody understand the
> value and flexibility of hidden services?
> Along these lines would be fleshing out the "hidden service challenge"
> idea I've been kicking around, where as a follow-up to the EFF relay
> challenge, we challenge everybody to set up a novel hidden service. We
> would somehow need to make it so people didn't just stick their current
> website behind a hidden service -- or maybe that would be an excellent
This could be fun. =) We could put out a blog post when Stormy
reaches 1.0 about this too.
> there is a lot of, shall we call it, dark matter in hidden service
> space. What are some safe ways we can improve our knowledge of this
> other 95% of the space?
> 6) In general, anything that falls under the umbrella of "better
> understanding hidden services and their role in society" is fair game
> here. So far we've mostly emphasized the technical part of
> them, which makes sense because we're mostly a technical organization.
> But we should think about whether there are steps we can take on the
> social side. And I think our funder will be sympathetic to "oh and we
> took these steps to improve the chance that hidden services will be
> for good" too.
> In other news, I plan at some point to write up a blog post explaining
> who the funder is and what exactly we're doing (and not doing!) for
> A few more things have to fall into place first though.
I'd be happy to work on this more as well =) There are some good ways
to discuss hidden services -- even outside of the easier pitches like
whistleblower protection, hidden services are really awesome and need
more positive attention from the outside non-hardcore-nerd world.
== Such References ==
 Where'd he run off to?
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
More information about the tor-dev