Skip to content

Officially support onions in HTTPS-Everywhere

The plan:

A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much harder to verify it.

There is a field of literature called "secure name systems" but none of the candidates are good enough for us right now. Hence, we present a hotfix that might offer a situational relief for users for the medium-term future, until we come up with something better, or while we experiment with more solutions. I suggest we keep this ticket focused to this idea, instead of debating why this and not that since we've already been doing this for far too long.

The plan is to use the HTTPS-Everywhere extension that we already have in Tor Browser, and encourage people to write their own rulesets for onions. We are talking about community-maintained rulesets and nothing that is officially maintained by The Tor Project or by HTTPS-Everywhere. This ticket is about making it easier for people to create, import and use this rulesets. We are talking about UI/UX improvements, writing blog posts and doing Q&A.

Here are some example of community rulesets we can imagine:

  • The SecureDrop ruleset: where securedrop makes a ruleset with their whole directory. People can download that to quickly visit securedrop destinations, by going to securedrop-nyt.tor.onion .

  • The Torproject ruleset: where torproject makes a ruleset with all their onions. We developers can use that to quickly visit Tor sites over onion, by going to tor-trac.tor.onion instead of remembering the onion.

  • The Bitcoin ruleset: where a "trusted" bitcoin entity publishes a ruleset with various cryptocurrency-related rules that allow people to quickly visit them.

This approach has both positives and negatives (I assure you this is the case with every "secure naming" project out there):

  • Positives: Good security if the ruleset is taken from a trusted source. No state keeping. Reachable engineering effort. No global names, hence no fear of name squatting. Easy to understand tradeoffs.

  • Negatives: Terrible security if the ruleset is evil. No global names: If you want people to use your shorten onion name, you need to persuade them to use your ruleset.

Here are some HTTPS-Everywhere issues we need to solve based on my Mexico notes:

  • Be able to stop update channels per-channel.
  • Need good UI to easily look and understand rules.
  • Need to implement file extension to install ruleset with one-click from web button.

Here are some issues we need to think about:

  • We need good user text to make sure that people don't shoot themselves in the foot too often by installing bad rulesets and whatnot (they already do it daily when they open onions from "search enginers" or reddit).

  • Which tld to use? If we use .tor we open ourselves to DNS leaks in normal browsers. If we use .tor.onion that might be confusing to people.

  • Are there any issues with SSL?

More resources:

https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/OnionV3ux https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/HTTPSEverywhereNotes https://blog.torproject.org/cooking-onions-names-your-onions

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information