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

["A. Johnson" <aaron.m.johnson@xxxxxxxxxxxx>]

> Following on Aaron's suggestion, and further pushing my own wee agenda,
> what about PS? it works because even if someone confused the acronym for
> something else, it still works. And it matches well with HS/OS.
> - Public (Onion) Service
> - Peeled (Onion) Service
> - Pseudo (Onion) Service <-- I like this as well, for various reasons

I donât prefer these suggestions because
  1. Public Onion Service: âPublicâ doesnât describe the desired property well. A hidden service can be public in the sense that it is publicly known an accessible. Similarly, it suggests that other onion services are private, or members-only.
  2. Peeled Onion Service: âPeeledâ isnât a very informative descriptor. What is peeled? What does "peeledâ mean in this context?
  3. Pseudo Onion Service: This makes it sound like the service itâs a fake onion service. But the security properties are very real.

> - exposed onion service, in my mind, would lead to people thinking the
> connection is in no way secure, because it is "exposed."â
> this may lead to the wrong understanding
> by a small but loud group of people.

I can see that, although I would say that we shouldnât let the fringe choose how we communicate.

> - bare onion service, if following Aaron's suggestion of dropping the
> onion, would lead to BS, which is not really an acronym anyone would
> want to have. :)

BOS could work. Conversely, POS means âpiece of shitâ to me, but PS could work for the above suggestions.

> I do like FS, but only if the performance improvements are quantifiably
> larger. Obviously the whole point of this endeavour is to make the speed
> and performance better, but until it is measured, I'm concerned "Fast
> (Onion) Service" may somewhat misrepresent the actual outcome. For
> example, hitting terribly slow "Fast Services", presumably because the
> service is so well loved that thousands of people use it, would upset
> some people not really understanding why it's slow.

I agree with this. Also, there are things that a direct onion service could do to improve security that a hidden service canât do, such as providing multiple locations as options to the client and providing information about the Internet paths it takes to Tor relays.

> With the above comment, that's why I like DS, because regardless of
> quantifiably increased performance, it is clear that it is a direct
> connection to the [Service], and there is no implied improvements beyond
> the statement that it's direct.

And, as Alec Muffett said, it has the advantage of being "attractively mundaneâ.

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