[tor-talk] Possible solution to next-gen onion services UX disaster
desnacked at riseup.net
Tue Mar 14 15:28:39 UTC 2017
Lolint <lolint at protonmail.com> writes:
> I just thought about a possible (partial) solution to solve the "UX disaster" of next-gen onion services, namely the very long addresses. Tor Browser already ships with HTTPS
> Everywhere, and one can easily write rules that redirect from http or https to onion services, as an example,
> If there was a possibility to add all the famous and most used onion services (facebook
> for example) into those rules then that effectively solves the UX problem for most of these
> onion services, since the user will no longer have to bother about finding the right onion
as Jonathan said this has been proposed and done before, and
unfortunately it did not get very far.
Personally, I think this might be an improvement over the current
situation, but far from the solution to the UX problem.
The whole idea has various social/technical problems as well:
- Who maintains the list of <clearnet> -> <onionspace> mappings?
- How do we ensure the correctness and authenticity of the list?
Validating http -> https changes is not super hard, but validating
<clearnet URL> to <random onion address> mappings is harder.
- Having addons rewrite your URLs is not polite. Going from http to
https is one thing, but rewritting the whole URL is a different
thing. Users will get confused and paranoid.
- What happens if we learn that a mapping was wrong/evil? How do we push
and validate updates? I'm not sure if HTTPS everywhere can/should do
this over the network right now.
The list of issues above is not complete, and it doesn't mean that the
idea is useless at all. I just think that more thinking needs to happen.
Personally, I think launching such a project as a third-party effort is
a fine thing to do. If people like it and use it then that's fine, and
perhaps a community can be built and flourish around the tool. After
all, I2P has been using hosts files to do human-memorable names for ages
and even tho the idea is flawed in nature, it seems to work fine for
people without problems.
And there is also the alternative approach which is that HTTPS
everywhere could define its own pseudo-tld (e.g. .scallion), and then it
could do arbitrary mappings of <onion url> -> <human memorable scallion address>.
That's a more complete solution but it brings even more security/social issues.
FWIW, all these things have been discussed with the HTTPS everywhere
people over the years, but it's unclear whether the team has the
firepower and energy to handle such a task, or whether it's worth it at
As an alternative here is a more general and abstract approach to
solving the UX problem: https://lists.torproject.org/pipermail/tor-dev/2016-October/011514.html
Have a good day!
More information about the tor-talk