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

[Paul Syverson]

On Mon, Apr 20, 2015 at 03:18:06PM -0400, A. Johnson wrote:
> > I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment.  It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names.  (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)
> 
> It is actually for usability that I dislike making unnecessary
> distinctions. “Onion service” makes it simple to clients: xyz.onion
> = service accessible only through Tor.

This may be the central source of our disagreement and underscores the
importance of terminology. I think of "onion service" as meaning a
service that is reachable only inside of Tor not merely accessible
only through Tor. 

Suppose someone has a sensitive file that they don't want the wrong
people to obtain or obtain before, e.g., an intended public
release. It would be good for them to easily tell whether the server
they're trusting with that file is location protected or
self-authenticated or.... If both Tor-required and heretofore hidden
services terms are called onion services, then it won't be apparent
simply from the address. (Substitute whatever terms you like for
"Tor-required" and "heretofore hidden", which I'm hoping are
adequately denoted by my usage here.)  And, do we require
self-authentication a la current hidden services for those that we
want to be faster and more convenient if it e.g. would significantly
affect performance?  My point is that if we assume these are all
called 'onion services' we are likely to assume in all kinds of design
requirements or trade-offs without first deciding what we want these
things to do and whether it thus makes sense to bind them together in
this way (or not).  This will then be baked into what 'onion' will mean
and entitle one to assume, even or especially for the users that cannot
articulate this technically. (As an imperfect analogy, think of the
semantics of the lock icon or the green highlighting etc. in URL bars.)
Put differently, whoever's terminological preferences win, we
should get much clearer on these things before we treat this draft as
more than a toy to help us work these out.

aloha,
Paul