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 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

-- http://dropsafe.crypticide.com/aboutalecm

_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions

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

-- Kate Krauss Director of Communications and Public Policy kate@torproject.org @TorProject 1-718-864-6647 (works for Signal also) PGP: CC0D 9B42 DE89 D4D0 619B A606 DDEB 3937 7D18 973B

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