Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
Tim
On 28 Feb 2016, at 18:30, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi Kate,
As we talked about at your press session, can you help us name a new "Hidden Service" variant?
If we call the overall feature "Onion Services", we need to come up with names for a new variant:
- "Single" Onion Services: a service where the client is anonymous and the server is not (like Facebook)
We already have:
- "Hidden" Onion Services: a service where the client and server are anonymous (like SecureDrop)
We might also want names for two different implementations of "Single" Onion Services:
- "Rendezvous" Single Onion Services: a service where the server only makes connections out, so it can be behind a NAT
- "Extend" Single Onion Services: a service that opens a port that Tor clients can connect to via Tor
But that's not as important, as it's very likely that we'll only end up with one of these alternate implementations in a tor release.
I've forwarded part of a tor-onions mailing list discussion below.
Tim
Begin forwarded message:
From: Alec Muffett <alec.muffett@gmail.com mailto:alec.muffett@gmail.com> Subject: Re: [tor-onions] Renaming Rendezvous Single Onion Services Date: 25 February 2016 at 14:17:00 GMT+1 To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org Reply-To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org
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
tor-onions mailing list tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hi Kate,
It might help to check out the (many) suggestions that have been made over the past year or two: <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminol... https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology>. Names that I have seen suggested for the “single onion service” variant are under #1 of the "Ideas for the future” section.
Best, Aaron
On Mar 8, 2016, at 7:01 AM, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
Tim
On 28 Feb 2016, at 18:30, Tim Wilson-Brown - teor <teor2345@gmail.com mailto:teor2345@gmail.com> wrote:
Hi Kate,
As we talked about at your press session, can you help us name a new "Hidden Service" variant?
If we call the overall feature "Onion Services", we need to come up with names for a new variant:
- "Single" Onion Services: a service where the client is anonymous and the server is not (like Facebook)
We already have:
- "Hidden" Onion Services: a service where the client and server are anonymous (like SecureDrop)
We might also want names for two different implementations of "Single" Onion Services:
- "Rendezvous" Single Onion Services: a service where the server only makes connections out, so it can be behind a NAT
- "Extend" Single Onion Services: a service that opens a port that Tor clients can connect to via Tor
But that's not as important, as it's very likely that we'll only end up with one of these alternate implementations in a tor release.
I've forwarded part of a tor-onions mailing list discussion below.
Tim
Begin forwarded message:
From: Alec Muffett <alec.muffett@gmail.com mailto:alec.muffett@gmail.com> Subject: Re: [tor-onions] Renaming Rendezvous Single Onion Services Date: 25 February 2016 at 14:17:00 GMT+1 To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org Reply-To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org
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
tor-onions mailing list tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Tim Wilson-Brown - teor:
Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
I remain persuaded by Paul Syverson's arguments for using names that reflect design. Design is unambiguous and reliably accurate, unless there have been substantive coding or merging errors. Conversely, functionality, usage and applicability by threat model are all ephemeral. Bugs and unforseen vulnerabilities can make such names inaccurate and misleading, or even ironic.
Consider how "hidden services" fared against the CMU jerks. But there's no irony when you call them "onion services". It's just that they exploited a bug that allowed relays to readily message each other across shared circuits. That is, onion circuits got pwned, and so did "hidden" services and their users, but it was still accurate to call them "onion" services.
Tim
On 28 Feb 2016, at 18:30, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi Kate,
As we talked about at your press session, can you help us name a new "Hidden Service" variant?
If we call the overall feature "Onion Services", we need to come up with names for a new variant:
- "Single" Onion Services: a service where the client is anonymous and the server is not (like Facebook)
We already have:
- "Hidden" Onion Services: a service where the client and server are anonymous (like SecureDrop)
We might also want names for two different implementations of "Single" Onion Services:
- "Rendezvous" Single Onion Services: a service where the server only makes connections out, so it can be behind a NAT
- "Extend" Single Onion Services: a service that opens a port that Tor clients can connect to via Tor
But that's not as important, as it's very likely that we'll only end up with one of these alternate implementations in a tor release.
I've forwarded part of a tor-onions mailing list discussion below.
Tim
Begin forwarded message:
From: Alec Muffett <alec.muffett@gmail.com mailto:alec.muffett@gmail.com> Subject: Re: [tor-onions] Renaming Rendezvous Single Onion Services Date: 25 February 2016 at 14:17:00 GMT+1 To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org Reply-To: tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org
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
tor-onions mailing list tor-onions@lists.torproject.org mailto:tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On 9 Mar 2016, at 05:33, Ann O'Nymous ann.onymous@vfemail.net wrote:
Tim Wilson-Brown - teor:
Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
I remain persuaded by Paul Syverson's arguments for using names that reflect design. Design is unambiguous and reliably accurate, unless there have been substantive coding or merging errors. Conversely, functionality, usage and applicability by threat model are all ephemeral. Bugs and unforseen vulnerabilities can make such names inaccurate and misleading, or even ironic.
So what name(s) would you or Paul suggest based on the design in #17178 (otherwise known as Rendezvous Single Onion Services)? I've tried to find out, but it's lost somewhere in the backlog.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown - teor:
On 9 Mar 2016, at 05:33, Ann O'Nymous ann.onymous@vfemail.net wrote:
Tim Wilson-Brown - teor:
Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
I remain persuaded by Paul Syverson's arguments for using names that reflect design. Design is unambiguous and reliably accurate, unless there have been substantive coding or merging errors. Conversely, functionality, usage and applicability by threat model are all ephemeral. Bugs and unforseen vulnerabilities can make such names inaccurate and misleading, or even ironic.
So what name(s) would you or Paul suggest based on the design in #17178 (otherwise known as Rendezvous Single Onion Services)? I've tried to find out, but it's lost somewhere in the backlog.
Strictly, that would be just "Rendezvous Single-Onion Services". To emphasize the not-hidden aspect, I like "Exposed Onion Services". "Exposed Rendezvous Single-Onion Services" is too long. In any case, "Rendezvous" and "Single-Onion" are probably not very meaningful for naive users.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On 8 March 2016 at 20:17, Ann O'Nymous ann.onymous@vfemail.net wrote:
Strictly, that would be just "Rendezvous Single-Onion Services". To emphasize the not-hidden aspect, I like "Exposed Onion Services". "Exposed Rendezvous Single-Onion Services" is too long. In any case, "Rendezvous" and "Single-Onion" are probably not very meaningful for
naive users.
It's an interesting approach.
I, too, don't like the Overly Long And Wordy Verbose Tautological Point-Making approach to naming schemes.
The community is harmed more from not having the code than by believing a consensus opinion will form in an open-email-list community process.
We can survive with calling them all "Onion Services" with "Hidden" and "Open" variants if, though I despair that "Open" is an essentially meaningless label which requires clarification and explanation.
But then perhaps that's what's needed? Nobody seems willing to make a call on the Tor side, and the rest of us here are just spinning our wheels.
Let's go with the "mediocre-but-at-least-it's-short".
-a
On 08 Mar (22:37:28), Alec Muffett wrote:
On 8 March 2016 at 20:17, Ann O'Nymous ann.onymous@vfemail.net wrote:
Strictly, that would be just "Rendezvous Single-Onion Services". To emphasize the not-hidden aspect, I like "Exposed Onion Services". "Exposed Rendezvous Single-Onion Services" is too long. In any case, "Rendezvous" and "Single-Onion" are probably not very meaningful for
naive users.
It's an interesting approach.
I, too, don't like the Overly Long And Wordy Verbose Tautological Point-Making approach to naming schemes.
The community is harmed more from not having the code than by believing a consensus opinion will form in an open-email-list community process.
We can survive with calling them all "Onion Services" with "Hidden" and "Open" variants if, though I despair that "Open" is an essentially meaningless label which requires clarification and explanation.
But then perhaps that's what's needed? Nobody seems willing to make a call on the Tor side, and the rest of us here are just spinning our wheels.
Let's go with the "mediocre-but-at-least-it's-short".
Data point. The name here is unfortunately important in terms of public perception but also it becomes an "ABI" because of the torrc file naming so we have to be careful of what we choose since we'll be stuck with it for a while.
This will go in tor 0.2.9 thus not released in a stable version until September so we have a bit of time to come up with a reasonable name.
I like "Visible" or "Non-Hidden" or "Plain".
My two cents. I would like to propose that someone gathers the latest suggestions and makes a new "Final RSOS naming suggestion" kind of email and send it to tor-dev@ and tor-onions@ and tor-project@. This has a broader scope and we should include the whole Tor community but as long as we have "final contenders, please vote" so we don't end up in an infinite email thread :).
Cheers! David
-a
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
David Goulet dgoulet@ev0ke.net writes:
Data point. The name here is unfortunately important in terms of public perception but also it becomes an "ABI" because of the torrc file naming so we have to be careful of what we choose since we'll be stuck with it for a while.
Ok, noted: this casual bikeshedding[0] is actually important!
My two cents. I would like to propose that someone gathers the latest suggestions and makes a new "Final RSOS naming suggestion" kind of email and send it to tor-dev@ and tor-onions@ and tor-project@. This has a broader scope and we should include the whole Tor community but as long as we have "final contenders, please vote" so we don't end up in an infinite email thread :).
I'm not against opening this to a wider audience, but I do see the infinite bikeshed discussion getting out of hand. If this is going to happen, I think it should be structured in some way. For example, a mail is sent there with a list of current suggestions, a call for additional suggestions that aren't already listed and a deadline for additional suggestions is set. Once that deadline is met, then another mail with a final call for deciding is sent, the parameters for how a decision will be made should be detailed, specifically at what date/time the decision will be finalized, who and how people get a say in this decision and what finally is the criteria for the decision (eg. a 2/3rd majority, etc.) otherwise it will be incredibly vague and unbounded and never end.
micah
0. http://bikeshed.com/ - be sure to reload it until you get the color you prefer
Hi!
Can you explain what this is, and its purpose, in language suitable for a general reader? That will help me think about the name. I looked up the ticket number but still don't completely understand (and wasn't at sessions about this in Valencia, unfortunately). I *think* I know--but further explanation would be really helpful here :)
Thanks,
Katie
Tim Wilson-Brown - teor:
On 9 Mar 2016, at 05:33, Ann O'Nymous ann.onymous@vfemail.net wrote:
Tim Wilson-Brown - teor:
Hi Kate,
Aaron and others currently favour "open onion services".
What do you think?
I remain persuaded by Paul Syverson's arguments for using names that reflect design. Design is unambiguous and reliably accurate, unless there have been substantive coding or merging errors. Conversely, functionality, usage and applicability by threat model are all ephemeral. Bugs and unforseen vulnerabilities can make such names inaccurate and misleading, or even ironic.
So what name(s) would you or Paul suggest based on the design in #17178 (otherwise known as Rendezvous Single Onion Services)? I've tried to find out, but it's lost somewhere in the backlog.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 11 Mar 2016, at 02:35, Kate Krauss kate@torproject.org wrote:
Hi!
Can you explain what this is, and its purpose, in language suitable for a general reader? That will help me think about the name. I looked up the ticket number but still don't completely understand (and wasn't at sessions about this in Valencia, unfortunately). I *think* I know--but further explanation would be really helpful here :)
Single Onion Services are an alternative to Hidden (Onion) Services. They share many of the same properties: self-authenticating addresses, end-to-end encryption, censorship circumvention, and client anonymity.
The difference is this: Hidden Onion Services keep the location (IP address) of the service hidden, as well as hiding the client's location.
But Single Onion Services make the service easy to locate, in return for faster connection speeds. They are ideal for sites that are publicly known and high-volume, that want to give their users the anonymity, security, and circumvention features of Tor Onion Services.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Wed, Mar 30, 2016 at 11:33:39AM +1100, Tim Wilson-Brown - teor wrote:
On 11 Mar 2016, at 02:35, Kate Krauss kate@torproject.org wrote:
Hi!
Can you explain what this is, and its purpose, in language suitable for a general reader? That will help me think about the name. I looked up the ticket number but still don't completely understand (and wasn't at sessions about this in Valencia, unfortunately). I *think* I know--but further explanation would be really helpful here :)
Single Onion Services are an alternative to Hidden (Onion) Services. They share many of the same properties: self-authenticating addresses, end-to-end encryption, censorship circumvention, and client anonymity.
Well no. The naming (which I thought was settled long ago so not sure how this whole thread got re-opened) goes like this:
Onion services: All of them
Double-onion services: Those that connect client to server over two Tor circuits, one from the client and one from the service.
Single-onion services: Those that just use one Tor circuit (from the client) to connect to the service.
The entire point of calling them 'onion services' was to get away from the pejorative and intentional confusions of 'hidden services'. So going forward, nothing should be called 'hidden services' at all unless you are explicitly calling attention to the address-hiding feature. And even then there are probably preferable other ways to say it.
The terms above were intended to provide short simple names that distinguish two important types. They don't describe what the services are for, because that makes them misleading and confusing names when someone comes up with another use for them. It also creates problems for some existing uses. But the names do provide an easy to understand distinction. If you want to know what they're for, the names don't tell you, and it depends anyway so you don't want people mislead by the names.
For example, consider NAT and firewall punching onion services for system administration. Suppose you set this up as a rendezvous single-onion service, but you intentionally don't give out the address. Is that hidden? Well not in the original sense of hidden services. If, however, you're not worried about a correlating end-to-end attacker, but you don't want people in general to have the address or to know how/where to connect to it, that clearly isn't meant to be "open" or "public" or...
The above names are all that we need to use for broad discussion to general readers. Further subtleties are not easily captured in simple names that anyone can grasp quickly. For example, though I myself am not thrilled, we seem to be settling on
Rendezvous single-onion services: That's a name for people who already understand things a bit, not naive users. If they think upon hearing the name and nothing else, "I don't understand that," that's a good thing. Developers also need short simple names to use around the office. I prefer RSOS services (pronounced arr-sauce services, and continuing the longstanding tradition of the RAS syndrome https://en.wikipedia.org/wiki/RAS_syndrome ) Plain single-onion services (without rendezvous) can be (pronounced p-sauce services).
The difference is this:
Hidden Onion Services keep the location (IP address) of the service hidden, as well as hiding the client's location.
But Single Onion Services make the service easy to locate, in return for faster connection speeds. They are ideal for sites that are publicly known and high-volume, that want to give their users the anonymity, security, and circumvention features of Tor Onion Services.
I don't like this description. It mixes a functional-use name with a design-description name. Better
Single-onion services are an alternative to the double-onion services from Tor's original design. All onion services share some important protections in practice: self-authenticating addresses, end-to-end encryption, censorship circumvention, and client anonymity.
Double-onion services connect a browser to a web server using two Tor circuits, one from the web server in addition to the usual one from the browser. One thing this does is hide the location (IP address) of the server, not just the client.
Some service providers would like to offer their users the protections that onion-services offer. But they prefer the faster connections and better performance they can get from single-onion services. Single-onion services also put less load on the Tor network, so those who do not feel they need the additional protections offered by double-onion services can reduce their impact while still providing the basic onion service protection.
I wrote the description assuming a web-browsing context, but I thought that would be appropriate for a first description to a general reader.
aloha, Paul
tor-onions@lists.torproject.org