Re: [tor-onions] Renaming Rendezvous Single Onion Services
Hello onioneers, We’ve had several naming discussions for single onion services at this point. They started out as “encrypted services”, then they shifted to “direct onion services”, and most recently “single onion services” seems to be winning. I have been collecting all the suggested names at <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminol... <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology>>. I have added all terms in this discussion to that wiki page. That page also includes other suggested terminology name changes for onion services. The broader “hidden”->”onion” shift seems to have been successful since this was first created, so that’s encouraging! It does seem that everybody still isn’t satisfied with “single onion services”, though. A couple of points I would make: 1. I think it’s really useful to keep “onion services” as a broad term that includes all onion flavors, including hidden, single, etc. 2. I think the “rendezvous” adjective is not going to be used outside of discussions by developers. Therefore we need not worry about how ugly or confusing the qualifier “rendezvous" is, and we should feel free to attach it when necessary to make the distinction in our technical documents and discussions. At most, in my opinion, enabling rendezvous for single onion services will be a minor configuration option to be considered when setting up your single onion service. Probably, in my opinion, the non-rendezvous variety of single onion services will never get implemented, because the performance cost of including the rendezvous is incredibly minor, while (i) the cost of splitting the anonymity set of services even further is *not* minor, and *(ii) the advantage of enabling NAT-punching is widely useful.
open: very good, traditional, positive word, but with overloaded meaning
For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better. Best, Aaron
Aaron Johnson <aaron.m.johnson@nrl.navy.mil> writes:
open: very good, traditional, positive word, but with overloaded meaning
For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better.
Personally, I feel like 'open' has to broad of a set of overloaded meanings and could be confused for one of the other meanings that is not intended. If these are 'open onion services', does that make the others 'closed onion services'? My vote is for the most obvious, because its name positions it in relation to existing onion services: 'non-hidden onion services'. The traditional onion services would then be known as 'hidden onion services'. micah
For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better.
Personally, I feel like 'open' has to broad of a set of overloaded meanings and could be confused for one of the other meanings that is not intended. If these are 'open onion services', does that make the others 'closed onion services'?
How about “exposed" onion services? It’s less ambiguous than “open”, is an antonym to “hidden”, is short and nice to say, and suitably indicates a lack of protection for the onion service.
My vote is for the most obvious, because its name positions it in relation to existing onion services: 'non-hidden onion services'. The traditional onion services would then be known as 'hidden onion services’.
First, I hope that long-term we could move away from the term “hidden” because it has a negative connotation (I like “protected” as a positive replacement). Second, “non-hidden” is annoying to say and hear. Third, I’d prefer a positive term to a negative, that is, one that describes what these services are rather than what they are not. Exposed onion services should be considered to be equally valuable to hidden onion services and not their lesser, deficient cousin. Aaron
Aaron Johnson <aaron.m.johnson@nrl.navy.mil> writes:
For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better.
Personally, I feel like 'open' has to broad of a set of overloaded meanings and could be confused for one of the other meanings that is not intended. If these are 'open onion services', does that make the others 'closed onion services'?
How about “exposed" onion services? It’s less ambiguous than “open”, is an antonym to “hidden”, is short and nice to say, and suitably indicates a lack of protection for the onion service.
I liked "exposed", it indicates something that is discoverable, and not concealed. it has a couple unfortunate secondary meanings: 2. To lay bare; to lay open to attack, danger, or anything objectionable; to render accessible to anything which may affect, especially detrimentally; to make liable; as, to expose one's self to the heat of the sun, or to cold, insult, danger, or ridicule; to expose an army to destruction or defeat. and: 4. To disclose the faults or reprehensible practices of; to lay open to general condemnation or contempt by making public the character or arts of; as, to expose a cheat, liar, or hypocrite. In language you get to chose which of many meanings you intend when you use a word, we would just need to push people away from these meanings and instead towards the 'discoverable' and non-concealed one.
My vote is for the most obvious, because its name positions it in relation to existing onion services: 'non-hidden onion services'. The traditional onion services would then be known as 'hidden onion services’.
First, I hope that long-term we could move away from the term “hidden” because it has a negative connotation (I like “protected” as a positive replacement).
I'm not 100% convinced that "hidden" is negative, but there are secondary meanings that *are* negative, in the same way that 'exposed' has negative secondary meanings. "Protected" is nice, but its opposite is "unprotected" which connotes unsafe.
Second, “non-hidden” is annoying to say and hear.
I agree, its awkward.
Third, I’d prefer a positive term to a negative, that is, one that describes what these services are rather than what they are not. Exposed onion services should be considered to be equally valuable to hidden onion services and not their lesser, deficient cousin.
Another few to throw out there, without any specific preferences attached: 'bare', 'detectable', 'bald', evident', 'light' (in contrast to 'dark' ha ha), 'naked', 'noticeable', 'observable', 'open-air', 'overt', 'perceivable', 'perceptible', 'recognizable', 'revealed', 'uncovered', 'unhidden', 'unveiled', 'visible', 'viewable' of those, i like 'bare', 'revealed', 'uncovered', 'unveiled', and 'visible' [onion] services. With the exception of 'bare', I don't think of any secondary negative/unfortunate meanings for these. micah
On 9 March 2016 at 06:38, Aaron Johnson <aaron.m.johnson@nrl.navy.mil> wrote:
How about “exposed" onion services? It’s less ambiguous than “open”, is an antonym to “hidden”, is short and nice to say, and suitably indicates a lack of protection for the onion service.
This is why you should never geeks - including me - decide branding issues. :-) "Exposed" is a case in point; it's a negative concept. People die of exposure. You might be naked and exposed. The word "expose" generally is associated with connotations where "exposure" is a bad thing. Sorry Aaron, but the very example you cite is about "indicating a lack of protection". That's not how I feel about the Onion sites I run, at all; in fact the onion "technology" (call it that for the moment) adds value to what is otherwise a normal, safe, secure "public" site. I've written elsewhere that if people use a site over Tor then they probably have a good reason to do so. The reason for running a public onion site is so that those people have a better experience and enjoy the benefits of end-to-end authentication. They are experiencing a positive benefit from onion services, rather than a negative one; thus they should be using a kind of site with a positive name, rather than a negative one. All qualitative labels will have this problem: Free, Libre, Open, Closed, Hidden, Public, Private ... all of these describe an abstract intent, rather than a technology. Such qualitative label-names are inevitably presumptuous of {some} implementer's intent. One can at least support "NonHidden" because it is the inverse of Hidden, but if "Hidden" is to be deprecated (?) then that seems silly. "Overt" is a variation of the same, the word literally means "not hidden". David says that this is "going to be part of the ABI" - in which case I am amazed that we're having this discussion because config file contents are free to be disjoint from branding, and can be as insane as you like. But regards branding: get someone who's qualified in Marketing and who understands Tor to read everything in this thread and in Trac, let them pick, and abide by what they say. It's faster and simpler than expecting consensus by adding geeks. It nothing else, Brooks' Law applies. -a -- http://dropsafe.crypticide.com/aboutalecm
How about “exposed" onion services? It’s less ambiguous than “open”, is an antonym to “hidden”, is short and nice to say, and suitably indicates a lack of protection for the onion service.
This is why you should never geeks - including me - decide branding issues. :-)
I don’t accept the label “geek”. Moreover, I am participating in this discussion to choose the name that I will be calling it for the next many months, and thus I have a stake in it.
"Exposed" is a case in point; it's a negative concept. People die of exposure. You might be naked and exposed. The word "expose" generally is associated with connotations where "exposure" is a bad thing.
Sorry Aaron, but the very example you cite is about "indicating a lack of protection”.
It is exactly this cautionary message to the operator that we are trying to obtain, and it apparently is successful. I would prefer a slightly more positive message, but I don’t see how to have both.
All qualitative labels will have this problem: Free, Libre, Open, Closed, Hidden, Public, Private ... all of these describe an abstract intent, rather than a technology. Such qualitative label-names are inevitably presumptuous of {some} implementer's intent.
I am definitely arguing to convey intent rather than to convey technical implementation. We had reached an equilibrium with “single onion services” that nickm upset because it didn’t properly convey intent.
David says that this is "going to be part of the ABI" - in which case I am amazed that we're having this discussion because config file contents are free to be disjoint from branding, and can be as insane as you like.
I see this is a discussion to figure out how we describe it as we develop it. If Tor wants to rebrand later, fine. Aaron
On Wed, Mar 09, 2016 at 12:22:31PM -0500, Aaron Johnson wrote:
All qualitative labels will have this problem: Free, Libre, Open, Closed, Hidden, Public, Private ... all of these describe an abstract intent, rather than a technology. Such qualitative label-names are inevitably presumptuous of {some} implementer's intent.
I am definitely arguing to convey intent rather than to convey technical implementation. We had reached an equilibrium with “single onion services” that nickm upset because it didn’t properly convey intent.
Well I remain completely opposed to anything conveying intent and regard that as just a mistake for our purposes. The people who understand the technology don't need it, they just need a simple word to use around the office (so to speak). The people who don't understand the technology are going to be misled by anything conveying intent into thinking they are getting something that they're not or just be confused (not "I don't know what that means" but "I think I know what that means, but it's wrong somehow"). First because it won't have the "hidden" "free" "public" "closed" whatever semantics that they will bring with them, and I think are _more_ likely to hurt themselves because of this than if it were given an architecturally descriptive name. You will also need to give them detailed explanations of the system ever after anyway, be it the misunderstanding of "hidden", "anonymity", what have you. Second, because function creep/new applications is/are bound to happen and it will become a weird misnomer for important or even perhaps the most widespread use, e.g., facebookcorewwwi.onion Even for internal use just in specs, code, or Tor proposals we should be aware that if they don't have a simple name for the public already, then somebody for some journalistic or other reason will grab a name and use it. (E.g., I'm calling these 'excellent beer services', for my own purposes because it's such an awesome name. 'EBS' for short.) I favor: "onion services" for all kinds of err onion services "single onion services" for all kinds of err single onion services rendezvous can come up as needed, but as Aaron noted is specialized. If you are in a position to ask, you should already have something of a description. (Even if it's coming up in a configuration gui, "Is your single onion service behind a firewall or a NAT? etc. For easy writing RSOS, for easy saying "arr sauce" This becomes even more moot if RSOS are the only kind of single onion services that get widely deployed. (I would currently argue against abandoning the other kind of single onion service design, but that's for another time.) A possible compromise I'm mixed about, but hey compromise plain onion services or simple onion services (Keep rendezvous as needed). This is a compromise because it can have an architectural as well as intent of use meaning. This means that if the intent of use doesn't apply after some time to some applications, the name still fits. This may still have the users/operators importing their own semantics and thus hurting themselves. But again, compromise. It also loses the nice duality with double onion services. Maybe 'plain' and 'double' can still work together. 'Simple' and 'double' do not as well IMO. Hmm, time to go for a double big mac... but plain, hold the onions. aloha, Paul
On Wed, Mar 09, 2016 at 03:02:08PM -0500, Paul Syverson wrote:
Well I remain completely opposed to anything conveying intent and regard that as just a mistake for our purposes.
Agreed. What happened here? There's a huge thread, which is just rehashing discussions that other people had already over the last year? And it looks like teor started the thread on behalf of one line that Nick said on irc? And Nick probably doesn't even know that a tor-onions list exists? This seems like a good opportunity for somebody to put all of the good thoughts on this topic into one place, so everybody here can get up to speed and be able to contribute new things if they have them, and so future people can get up to speed too (so we don't do this again in 6 months). Anybody want to take that on? Otherwise this thread is just going to get worse. :) --Roger
On 10 Mar 2016, at 07:22, Roger Dingledine <arma@mit.edu> wrote:
On Wed, Mar 09, 2016 at 03:02:08PM -0500, Paul Syverson wrote:
Well I remain completely opposed to anything conveying intent and regard that as just a mistake for our purposes.
Agreed.
What happened here? There's a huge thread, which is just rehashing discussions that other people had already over the last year? And it looks like teor started the thread on behalf of one line that Nick said on irc? And Nick probably doesn't even know that a tor-onions list exists?
Nick's concern was that users could configure Single Onion Services without realising that it provides no server location anonymity. I initially thought we could change the torrc option name to make this clear. But the discussion turned into changing the public name of the feature as well (which wasn't my original intention). I'm sorry that I kept the discussion going, without stepping back to look at the initial purpose of the discussion. I now believe that trying to overload the name of a feature with warnings about its downsides was a mistake. I also believe that we have a perfectly good name for the feature that's been in use for almost a year now: "Single Onion Services". Unless there's some compelling reason we can't use that name, I propose that we keep it. (I can't remember a compelling reason to change a year-old name in the discussion so far.) This would mean that Single Onion Service operators would include in their torrc: SingleOnionMode 1 HiddenServiceDir … (If we ever have multiple SingleOnionMode implementations, such as rendezvous and extend, we can modify the option to take mode names: "rend", "extend". We could migrate to the new names by making "1" an alias for "rend".) As a separate issue, I think there are two alternative designs that can prevent users from configuring the feature and then exposing their location unintentionally: Tor2WebMode requires users to add a compilation option: --enable-tor2web-mode We could do this with Single Onion Services as well: --enable-single-onion-mode If SingleOnionMode is configured without the compilation option, tor warns the user and refuses to start. When it is configured, tor warns the user they're non-anonymous, then starts. However, using a compilation option makes the feature harder to test. And Tor2Web operators already don't like having to compile separate binaries. It's likely Single Onion operators would feel similarly. Alternately, we could add a torrc option: NonAnonymousMode If SingleOnionMode is configured without NonAnonymousMode, tor warns the user and refuses to start. When it is configured, tor warns the user they're non-anonymous, then starts. I spoke with Nick on IRC and he's happy with either of these options. I'd like to proceed with the NonAnonymousMode torrc option, unless there are compelling reasons against that design. I hope that this will allow us to get SingleOnionMode merged early in tor 0.2.9.
This seems like a good opportunity for somebody to put all of the good thoughts on this topic into one place, so everybody here can get up to speed and be able to contribute new things if they have them, and so future people can get up to speed too (so we don't do this again in 6 months).
Anybody want to take that on?
Otherwise this thread is just going to get worse. :)
I can't take on updating (or creating) a wiki entry right now. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Paul Syverson:
On Wed, Mar 09, 2016 at 12:22:31PM -0500, Aaron Johnson wrote:
All qualitative labels will have this problem: Free, Libre, Open, Closed, Hidden, Public, Private ... all of these describe an abstract intent, rather than a technology. Such qualitative label-names are inevitably presumptuous of {some} implementer's intent.
I am definitely arguing to convey intent rather than to convey technical implementation. We had reached an equilibrium with “single onion services” that nickm upset because it didn’t properly convey intent.
Well I remain completely opposed to anything conveying intent and regard that as just a mistake for our purposes.
<cut>
I favor:
"onion services" for all kinds of err onion services "single onion services" for all kinds of err single onion services
<cut>
A possible compromise I'm mixed about, but hey compromise
plain onion services or simple onion services
(Keep rendezvous as needed).
<cut> How about "fast onion services"? That is the real intent, right?
participants (7)
-
Aaron Johnson -
Alec Muffett -
Ann O'Nymous -
micah -
Paul Syverson -
Roger Dingledine -
Tim Wilson-Brown - teor