Lunar lunar@torproject.org writes:
[ text/plain ] George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses.
That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model).
Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ...
So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official.
We really need to start serious work in this area ASAP! Maybe let's start by making a wiki page that lists the various potential solutions (GNS, Namecoin, Blockstack, OnioNS, etc.)?
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
Agreed that base32 is not very good as far as encoding goes.
Regardless of the naming system that we need to deploy, we should also acknowledge that we need a good address encoding scheme anyway, as not all HSes will use the naming system. This is also the case with IP addresses: many people mess with IP addresses everyday (for config files, etc.)
I recently read this paper from USENIX which is a UX study on fingerprint encodings: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presen... We might be able to learn somethign from it. For example, they found out that alphanumeric encodings (like base32) make for the worst experience when compared to other encodings (pure numeric, unrelated words, sentences, etc.).
Finally, if we acknowledge that at least some people will have to mess with the raw addresses themselves, another benefit of the addresses being small is that they are easier to verify by hand (verifying a 24 characters fingerprint, is easier than verifying a 54 characters fingerprint).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Indeed. We need a good naming scheme if we ever hope for onion services to become widespread.
Maybe it would be worthwhile to ask the UX team for input on the topic?
I think that would be a good idea indeed.