Renaming Rendezvous Single Onion Services
Hi all, It looks like Rendezvous Single Onion Services may not make it into tor before the 0.2.8 code freeze in a few days' time. One of the blocking issues is that it needs to be renamed. Nick said on IRC: "RSOS is not really intelligible in the same way that Hidden Service was." "I want to make really sure that nobody configures this without realizing it's not anonymous" Does anyone have any suggestions? I'm out of names (and soon to start travel). Tim
fOnion service On Mon, Feb 22, 2016, 9:17 PM Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
Hi all,
It looks like Rendezvous Single Onion Services may not make it into tor before the 0.2.8 code freeze in a few days' time.
One of the blocking issues is that it needs to be renamed.
Nick said on IRC: "RSOS is not really intelligible in the same way that Hidden Service was." "I want to make really sure that nobody configures this without realizing it's not anonymous"
Does anyone have any suggestions? I'm out of names (and soon to start travel).
Tim _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On Tue, Feb 23, 2016 at 01:17:42PM +1100, Tim Wilson-Brown - teor wrote:
Hi all,
It looks like Rendezvous Single Onion Services may not make it into tor before the 0.2.8 code freeze in a few days' time.
One of the blocking issues is that it needs to be renamed.
Nick said on IRC: "RSOS is not really intelligible in the same way that Hidden Service was." "I want to make really sure that nobody configures this without realizing it's not anonymous"
So every name's a problem. I think "Hidden Service" was a bad name in hindsight in that it focused only on the location hiding and not on the provided authentication, and worse, it facilitated stupid pundits coining the misleading "Dark Web". That's why I like names like "Single-Onion Service" and "Double-Onion Service" that describe the technology not what it provides (which can also become a misnomer if other features of the service become prominent in use). If you want to underscore in the name specifically the not-hidden property, then I suggest the best would be 'Rendezvous Located-Onion Service'. And Single Onion Service, would be 'Located-Onion Service'. I think focusing in the name on such aspects is a really bad idea, but I offer this suggestion in case it is going to happen no matter what I think.
Does anyone have any suggestions? I'm out of names (and soon to start travel).
Bon Voyage, Paul
Single* Hop Onion Services (*singleness not guaranteed) In general: stay away from qualitative or policy-based like hidden/public/secret/private, they only cause a problem later. Stick to descriptive terms. - alec On 23 Feb 2016 3:14 a.m., "Paul Syverson" <paul.syverson@nrl.navy.mil> wrote:
On Tue, Feb 23, 2016 at 01:17:42PM +1100, Tim Wilson-Brown - teor wrote:
Hi all,
It looks like Rendezvous Single Onion Services may not make it into tor before the 0.2.8 code freeze in a few days' time.
One of the blocking issues is that it needs to be renamed.
Nick said on IRC: "RSOS is not really intelligible in the same way that Hidden Service was." "I want to make really sure that nobody configures this without realizing it's not anonymous"
So every name's a problem. I think "Hidden Service" was a bad name in hindsight in that it focused only on the location hiding and not on the provided authentication, and worse, it facilitated stupid pundits coining the misleading "Dark Web". That's why I like names like "Single-Onion Service" and "Double-Onion Service" that describe the technology not what it provides (which can also become a misnomer if other features of the service become prominent in use).
If you want to underscore in the name specifically the not-hidden property, then I suggest the best would be 'Rendezvous Located-Onion Service'. And Single Onion Service, would be 'Located-Onion Service'.
I think focusing in the name on such aspects is a really bad idea, but I offer this suggestion in case it is going to happen no matter what I think.
Does anyone have any suggestions? I'm out of names (and soon to start travel).
Bon Voyage, Paul _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
If RSOS becomes "Single Hop Onion Services" then to answer the obvious followup questions: * Hidden Services should become ''Full Onion Services" or "Multi-Hop Onion Services" * The existing draft for SOS / "Single-Onion Services" would perhaps be "Direct Onion Services" Of course all deference to Paul, Roger & Nick, who are perhaps thinking of the number of layers of crypto in each onion, but all the discussion I ever have regards this matter seems to pivot entirely on "the number of hops" as a graspable concept, and the "Onion Services" reflects the server-nature of the configuration. -a On 23 Feb 2016 9:03 a.m., "Alec Muffett" <alec.muffett@gmail.com> wrote:
Single* Hop Onion Services (*singleness not guaranteed)
In general: stay away from qualitative or policy-based like
hidden/public/secret/private, they only cause a problem later.
Stick to descriptive terms.
- alec
Ah, the hardest problem in computer science, naming! Alec Muffett <alec.muffett@gmail.com> writes:
Single* Hop Onion Services (*singleness not guaranteed)
On 23 Feb 2016 3:14 a.m., "Paul Syverson" <paul.syverson@nrl.navy.mil> wrote:
If you want to underscore in the name specifically the not-hidden property, then I suggest the best would be 'Rendezvous Located-Onion Service'. And Single Onion Service, would be 'Located-Onion Service'.
The problem with both 'Single Hop' and 'Rendezvous Located' is that it requires that you know enough about tor to understand what those mean, before you can understand that you don't get a certain property that you might be expecting. These describe the technology, instead of telling you what you get. The "Hidden" services name was good because it told you what you got. Now we have come to recognize that there is a valid use case for these that doesn't involve being 'hidden' so there is a move to change the name to "Onion" services instead. At the same time, there is this effort to create RSOS and Single Onion Services. Does it make sense to continue to push for a broadening of the term Hidden->Onion Services, while also trying to individually name these different types of services? If we keep "hidden services" and then call these "non-hidden services" that might be the clearest. However, the functional differences between RSOS and Single Onion Services are not obvious enough to me to come up with a distinguishing name for each that an admin with only a surface level understanding of tor would be able to make a choice based on the name alone. Single Onion seems easy to describe as a "non-hidden onion service", but the difference between RSOS and Single Onion Services perhaps too subtle to give a functional name. Could we just call RSOS "non-hidden onion service behind NAT" or "non-hidden onion service with unreachable OR port"? micah
On 23 February 2016 at 15:07, micah <micah@riseup.net> wrote:
Ah, the hardest problem in computer science, naming!
Totally! :-) Alec Muffett <alec.muffett@gmail.com> writes:
Single* Hop Onion Services (*singleness not guaranteed)
On 23 Feb 2016 3:14 a.m., "Paul Syverson" <paul.syverson@nrl.navy.mil> wrote:
If you want to underscore in the name specifically the not-hidden property, then I suggest the best would be 'Rendezvous Located-Onion Service'. And Single Onion Service, would be 'Located-Onion Service'.
The problem with both 'Single Hop' and 'Rendezvous Located' is that it requires that you know enough about tor to understand what those mean, before you can understand that you don't get a certain property that you might be expecting. These describe the technology, instead of telling you what you get.
Oh yes, this is true; I suppose that underscoring my proposal is an assumption that "Hidden Services" are no longer a positive (or complete) description of the features that Tor provides, and that HS would be deprecated as a term in favour of a broader "Onion Services" feature under the greater Tor "brand". Then when people are on stage talking about the features provided by "Tor Onion Services" they can talk about capabilities: - the first (and oldest) kind of onion services gives you anonymity & privacy and end-to-end trust! (Full / 3-hop) - a second, backward-compatible kind of onion service lets you trade server-anonymity for better speed, lower latency & improved UI responsiveness (1-hop) - the third kind is for performance nerds, enabling optimum speed and fastest connection setup for people who need to reach your site over Tor primarily for end-to-end trust (Direct) ...rather than explaining a series of abstract names. By having this kind of discussion in the public arena, narrative can be moved away from spooky dark-web historical rubbish, towards instead the beneficial - maybe "next step beyond SSL?" - features which Onions provide to people who have need for better communications security. At the same time, there is this effort to create RSOS and Single Onion
Services. Does it make sense to continue to push for a broadening of the term Hidden->Onion Services, while also trying to individually name these different types of services?
I think not. I feel we may perhaps be on the same page. :-) -a -- http://dropsafe.crypticide.com/aboutalecm
On 2/23/16 4:14 AM, Paul Syverson wrote:
So every name's a problem. I think "Hidden Service" was a bad name in hindsight in that it focused only on the location hiding and not on the provided authentication, and worse, it facilitated stupid pundits coining the misleading "Dark Web". That's why I like names like "Single-Onion Service" and "Double-Onion Service" that describe the technology not what it provides (which can also become a misnomer if other features of the service become prominent in use).
+1
If you want to underscore in the name specifically the not-hidden property, then I suggest the best would be 'Rendezvous Located-Onion Service'. And Single Onion Service, would be 'Located-Onion Service'.
-1 I think that anybody who configure a Tor for feature that Tor Project may consider risky from the Anonymity perspect, the right approach is to look forward what i wrote in this ticket https://trac.torproject.org/projects/tor/ticket/17019 . "For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and Client), we can build them in the standard version of Tor by adding a command line like: --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-client (tor2web mode) --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-server (encrypted services)" That way: - The feature could be described as Paul is suggesting, by it's technical functionality - The end-user configuring will be prevented from making mistakes that may jeopardize it's anonymity Fabio
On 23 Feb 2016, at 14:44, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch <mailto:lists@infosecurity.ch>> wrote:
On 2/23/16 4:14 AM, Paul Syverson wrote:
So every name's a problem. I think "Hidden Service" was a bad name in hindsight in that it focused only on the location hiding and not on the provided authentication, and worse, it facilitated stupid pundits coining the misleading "Dark Web". That's why I like names like "Single-Onion Service" and "Double-Onion Service" that describe the technology not what it provides (which can also become a misnomer if other features of the service become prominent in use). ... I think that anybody who configure a Tor for feature that Tor Project may consider risky from the Anonymity perspect, the right approach is to look forward what i wrote in this ticket https://trac.torproject.org/projects/tor/ticket/17019 <https://trac.torproject.org/projects/tor/ticket/17019> .
"For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and Client), we can build them in the standard version of Tor by adding a command line like:
--yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-client (tor2web mode) --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-server (encrypted services)"
That way: - The feature could be described as Paul is suggesting, by it's technical functionality - The end-user configuring will be prevented from making mistakes that may jeopardize it's anonymity
We discussed requiring a separate build for Single Onion Services, and initially rejected it in favour of a long option name containing "NonAnonymous". But it does provide an extra layer of protection for hidden service operators, and it's quite easy to implement - the way the code is abstracted at the moment, we could add a few lines of code, and it would be done. I'll ask Nick and others wha they think in Valencia. But the name still remains an issue - it needs to be memorable, and describe a critical feature/technology, like "Hidden Service" and "Tor2web". I agree with Paul, features should describe technology wherever possible, and not single out one feature among many. But in this case, we want the name to remind people that location-anonymity isn't property of these services. Perhaps we do need a special build? If we do end up choosing a feature-based name, I think we could start with a base name like: (With credit to a thesaurus antonyms section...) * Visible Service * Obvious Service * Overt Service * Open Service * Revealed Service * Known Service Then we could add "Onion" to distinguish Tor services when necessary in context. We can also add: * "Rendezvous", or * "Extend" / "(OR)Port" to distinguish between the different onion services. To be really explicit, we could add "IP Address": "Visible IP Address Service", "Known IP Address Service" - but I hope we can find a name where this is unnecessary. I'm not entirely comfortable with any of these options, but I think they could get us close to a usable name that's easily memorable for onion service operators. (And perhaps those with media experience could steer us towards a name with fewer connotations.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
If we do end up choosing a feature-based name, I think we could start with a base name like: (With credit to a thesaurus antonyms section...) * Visible Service * Obvious Service * Overt Service * Open Service * Revealed Service * Known Service
Then we could add "Onion" to distinguish Tor services when necessary in context.
We can also add: * "Rendezvous", or * "Extend" / "(OR)Port" to distinguish between the different onion services.
I'd suggest that the general goal is to convey the value proposition and avoid abstract or ambiguous terms that require further explanation. Running through the list of suggestions: visible: begs the question "to whom?" and whether a traditional HS is not "visible" obvious: not bad, but begs grammarians to criticise it overt: i like this; I like "flagrant" too. both of them speak to the concept that this is the complement of a "hidden" service open: very good, traditional, positive word, but with overloaded meaning (the open service is closed for maintenance) revealed: not bad, but grammar again. "overt" is better. known: same criticism as "visible"; if you're shooting for this you might want to consider "attested" instead? -a
Tim Wilson-Brown - teor:
On 23 Feb 2016, at 14:44, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch <mailto:lists@infosecurity.ch>> wrote:
On 2/23/16 4:14 AM, Paul Syverson wrote:
So every name's a problem. I think "Hidden Service" was a bad name in hindsight in that it focused only on the location hiding and not on the provided authentication, and worse, it facilitated stupid pundits coining the misleading "Dark Web". That's why I like names like "Single-Onion Service" and "Double-Onion Service" that describe the technology not what it provides (which can also become a misnomer if other features of the service become prominent in use). ... I think that anybody who configure a Tor for feature that Tor Project may consider risky from the Anonymity perspect, the right approach is to look forward what i wrote in this ticket https://trac.torproject.org/projects/tor/ticket/17019 <https://trac.torproject.org/projects/tor/ticket/17019> .
"For both NON-ANONYMOUS Tor Hidden Service use-cases (Server and Client), we can build them in the standard version of Tor by adding a command line like:
--yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-client (tor2web mode) --yes-i-know-that-i-m-going-to-use-non-anonymous-tor-hidden-services-server (encrypted services)"
That way: - The feature could be described as Paul is suggesting, by it's technical functionality - The end-user configuring will be prevented from making mistakes that may jeopardize it's anonymity
We discussed requiring a separate build for Single Onion Services, and initially rejected it in favour of a long option name containing "NonAnonymous".
Why did you reject separate builds? The use case for Single-Onion Services is very different from traditional Double-Onion Services. And potential consequences for accidentally using Single-Onion Services are huge. Accidents happen. Stupidity happens. Perhaps someone is learning and testing, and then goes to production with the wrong torrc. Or they hire someone to code, and there is miscommunication. I agree with Fabio. Requiring a custom build with a --very-hard-to-ignore-warning flag is far stronger protection. <trim>
On 25 Feb 2016, at 16:10, Ann O'Nymous <ann.onymous@vfemail.net> wrote:
We discussed requiring a separate build for Single Onion Services, and initially rejected it in favour of a long option name containing "NonAnonymous".
Why did you reject separate builds? The use case for Single-Onion Services is very different from traditional Double-Onion Services. And potential consequences for accidentally using Single-Onion Services are huge. Accidents happen. Stupidity happens. Perhaps someone is learning and testing, and then goes to production with the wrong torrc. Or they hire someone to code, and there is miscommunication. I agree with Fabio. Requiring a custom build with a --very-hard-to-ignore-warning flag is far stronger protection.
We initially decided it wasn't necessary. But now it seems like a good way to address Nick's concerns. I'll talk to him about it when I see him over the next few days. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (7)
-
Alec Muffett -
Ann O'Nymous -
AntiTree -
Fabio Pietrosanti (naif) - lists -
micah -
Paul Syverson -
Tim Wilson-Brown - teor