[tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

> On Aug 8, 2015, at 1:44 PM, Paul Syverson <paul.syverson at nrl.navy.mil> wrote:

Hi Paul!

I think it would be valid to propose a third direction, which is to partially give-up arguing about the importance of Zooko’s Triangle and instead make attempts to meet human beings and computers somewhere in the middle.

I don’t believe that this direction should preclude development of the other two - they might indeed be complementary - but making Onion addresses accessible in the ways that an IPv4 “dotted quad” is, or that an IPv6 “::” field-pad does, cannot be a bad thing.

There is, as you point out:

> One is to produce human meaningful names in association with onion
> addresses.

…which is akin to the layer that DNS provides atop IP addressing; everyone with a domestic DSL router probably has “http://192.168.1.1 <http://192.168.1.1/>” bookmarked somewhere, which is more direct and unambiguous than the “http://router <http://router/>.local” that it may also masquerade as, by providing DNS bootstrap through DHCP.

> The other that I am aware of is to bind onion addresses in a human
> meaningful way to existing names, typically registered domain names,

I recall the discussion we had inside Facebook, along the lines of “why don’t we register “onion.facebook.com” and issue a redirect, rather than forcing people to type this gibberish?” - an argument which was won by the observation “we are putting this out for people to have trust, and why should we make them trust DNS+redirection when we can instead give them something direct and unambiguous"

You’ll gather that I like “direct and unambiguous”. :-)

Hence: let there be innovation.

Please  let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs.

But, what they boil down to, please let *that* be human-readable, too.  The more I like about it, the more I like:

a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion

…where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring.

That way people looking to quickly compare addresses can check the first octet, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls") and be reasonably satisfied and reasonably secure.

And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150808/917dd481/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150808/917dd481/attachment-0001.sig>