Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote:
> > The problem with "fast", "direct", and maybe "bare" is that they
> > describe some property we're trying to provide with these. Like
> > hidden, I think the chance that they will evolve or be applied in some
> > way for which these terms won't apply is too great.
> 
> I disagree in general. Hidden service is still a perfectly accurate
> term. âFastâ may have this issue if such services change and take
> advantage of the fact that the server location is known for other
> purposes (e.g. location-based security improvements).

I disagree. Firewall punching service administration may also involve
hiding, which may or may not be viewed as a benefit. But calling this
hidden is not a good description of the most salient or important
aspects of the service.  Similarly for the authenticated services
Griffin and I described in "Genuine Onion". Admittedly the latter
currently is largely academic with only a few working examples at the
moment.

> 
> > The problem with "exposed", "peeled", and maybe "bare" is that these
> > all imply that these are onion services that are diminished in some
> > way.
> 
> I can see this with âexposedâ (although it actually has the
> advantage of making it clear to the operators that the service is
> *not hidden*). Neither âpeeledâ nor âbareâ seems negative to me.

You haven't seen the headlines in Time Magazine or The Register yet.

> 
> > because if it ends up not having the .onion
> > domain name or requiring lookup in the HSdir system etc.
> 
> This doesnât seem relevant. We are discussing an existing proposal,
> in which the .onion domain and Tor's name resolution service are
> used.

See my last paragraph below.

> 
> > This is another reason why [modifier] onion service is
> > problematic; it will almost certainly get shortened in use, just
> > as location-hidden service did.
> 
> The obvious and suggested shortening (i.e. omitting the word
> âonionâ) works well, in my opinion.

What then was wrong with clientside service, or evn client service?
(Although I am again increasingly sour on the idea of trying to treat
these and heretofore "hidden" services as somehow broadly the same
animal.)

> 
> > Here's one suggestion: must-tor service (or mustor service if we want
> > to be even more compressed.
> 
> This reminds me of the âTor-required serviceâ suggestion you
> initially made. I dislike like it for the same reasons, the primary
> one of which is that it uses two entirely separate names for
> services that actually will probably indistinguishable to the
> user. Thatâs why I like the âonion servicesâ umbrella over both
> hidden and fast/direct/exposed/public/peeled/etc.


Thank you for making my point. My fundamental concern is that these
are two separate services with important differences. We will use the
same (or too similar) names for them, and the user will be confused
about which s/he is using. (Note that user here includes the Tor user
setting up the service, not just the one who is the client of that
service. Also those doing subsequent design and analysis are very much
steered by terminological choices "anonymity", "hidden", etc.)  A
similar point was raised to me after my post earlier today by someone
in a private response. I encouraged reposting the point in public
discussion in this forum, but I haven't heard back or seen that, so
will wait to say more.


A primary motivation here on terminology is to make sure we don't
rush ahead and assume terminology and/or design that runs them
together and therefore decide that the design and/or terminology that
follows this running-together naturally follows. That's viciously
circular justification. 
> 
> Best,
> Aaron
> 

> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev