On 08 Aug (11:36:35), Alec Muffett wrote:
Hi All,
Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.
Beers, very nice! :)
[snip]
taking a cue from World War Two cryptography, breaking this into banks of five characters which provide the eyeball a point upon which to rest, might help:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion
That I like quite a bit!
Right now, with the 16 char address, I doubt very much that people actually type them in the browser, I bet it's still and will continue to be Copy-Paste. As for the verification part that is making sure you have the right .onion, I'm pretty sure this is just ignore by most users and that it is actually worst with vanity address because as long as I see "facebook" in there, that's good enough. Ok, you guys have a pretty epic one that is quite noticeable but let's take Wikileaks upload page for instance "wlupld3ptjvsgwqw.onion", only seeing "wlup" is MOST probably way enough for most of the users and 12 characters are then ignored.
(Altough, most users probably rely on the CA-mafia to get their .onion in a "trusted" ways so anycase the "verification of .onion" situation is pretty bad. ;)
With "banks of char", it makes it much more easier for someone to remember one of them and verify that at least the one I remember is there. It's not perfect but it's a damn good start imo. I remember reading a while back a study about research done at Bell Labs when they were trying to come up with a standard length for the phone numbers in North America (now 7 digits + 3 area code). One of the reasons in the end was the human brain capability of quickly, and for a reasonable amount of time, remembering <= 7 digits.
So, this approach takes advantage of that "human brain quirk" and we should definitely use it to improve onion address verification by users. With 52 characters, there could be 7 blocks of 7 chars (49) and a last block of 3 chars + the 4 unused bits (see below for those). If you remember at least one of those blocks somewhere in the string, I say amazing improvement!
(I would NOT go with different length though, I bet *everyone* will end up remember the smallest one so have them at least all the same length or some of them bigger.)
using underscores would be a pain (tendency to have to use SHIFT to type)
using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs
being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:
agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only
…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.
appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
See section 1.2 of proposal 224 (NOT 244 ;), there are 4 unused bits when using base32 encoding. I remember we had a discussion about those at the HS meeting [1], ideas where the length, very small checksum ("a la credit card"), or human readable word.
So definitely, this needs to be clarified in the proposal.
- it might be good to discuss this now, rather than later?
Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-)
Totally and if by some email magic we reach a concensus, this should be added to the prop#224 before we do implement it. (Or even it's own proposal if too big.)
Cheers! David
[1] https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords
- alec— Alec Muffett Security Infrastructure Facebook Engineering London
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev