Objective 2, Activity 5: POC for Human-memorable addresses for .onion services
This is the parent ticket to hold any tickets under this activity, including:
- Evaluating using HTTPS-Everywhere.
- Evaluating using HTTPS-Everywhere’s Update Channels feature to add custom onion rulesets that can be updated automatically.
- Evaluating adding a designated file extension handler in Tor Browser to handle HTTPS-Everywhere rulesets.
- Evaluating enhancing the UI of HTTPS-Everywhere so that it educates users on how onion update channels work.
Activity
Trac:
Parent Ticket: #30281 (moved)
Child Ticket(s): #28005 (moved)
Trac:
Parent: N/A to #30281 (moved)Responding to the title of this ticket, which includes 'Human-memorable addresses for .onion services': we must be careful to consider Zooko's Triangle, which argues that names cannot be human-meaningful, decentralised, and secure. In particular, we must not seek to re-implement something like DNS, whose requirement of universality implies the creation of hierarchy, authorities, and control points, all of which undermine a salient benefit of onion services: the ability for all individuals to create and use them freely. Consider the implicit role for authorities in any effort to secure DNS. (Currently, it would seem that we rely either upon authorities to tell us whether a name is trustworthy because it is 'real', implicitly assuming that power is on our side, or upon marketplaces to tell us whether a name is trustworthy because it is 'expensive', implicitly assuming that wealth is on our side.)
As an alternative, we might consider adopting an approach more like Petnames, which encourages individuals to create and use their own meaningful names for opaque identifiers, without requiring everyone to agree. To help users with this, I might suggest modifying Tor Browser such that when browsing to onion sites, it hides the
http://OPAQUENAME.onionpart of the URL from the URL bar entirely and instead displays the Petname defined by the user for that site, which the user might be prompted to input (or accept, or modify) the first time it is accessed.We might also want to create tools to help users track the provenance of addresses learned via introductions (or referrals, or links), so that they would be empowered to make decisions based upon their own judgment of the trustworthiness of those who provided introductions. We could likewise encourage individual users to establish multiple identities for their own services this way and use different addresses based upon context.
i agree with cypherpunks that Zooko's triangle is relevant here, and i generally really like petnames as the solution to that trilemma.
But effective petnames depend on persistent local configuration -- the user's history with a given site, and their selected petname. Torbrowser, on the other hand, seems to strive to avoid persistent local configuration, since persistent local configuration has two drawbacks:
- it leaves records on the local machine of the user's history (a stored petname for a particular onion service implies that the user has visited that onion service in the past)
- if network behavior changes at all on the basis of the persistent local configuration, it represents a potential tracking/fingerprinting vector (not clear that this is an issue for the petname proposal, but it could be depending on how the petnames affect torbrowser's user experience).
For the people advocating petnames, i'd love to see more detail about how they plan to balance these tensions.
dkg, thank you for your [comment:4 reply].
Briefly, you are certainly right that Tor avoids local storage of data that pertain to a user's behaviour, such as cookies and history. However, this is not the case for "Bookmarks", with good reason: "Bookmarks" represent conscious choices on the part of the user. For this argument to hold in the case of Petnames, we might want to ensure that the decision to associate a long-lived Petname with a particular onion site is always conscious, and not the 'default' behaviour resulting from simply visiting a site. User empowerment is key to striking the right balance: for example, we might consider creating Petnames by default but having them be ephemeral by default, like the browsing history associated with a particular tab, so that users would be able to make the conscious decision to save the association in their browsers like Bookmarks if they plan to revisit them. The implementation would presumably be slightly different to Bookmarks since it would (1) only bind onion hostnames rather than complete URLs and, optionally, (2) require each Petname to be (locally) unique. But this could be done in addition to Bookmarks, as a similar data store.
You're also right that the existence of a Petname should not affect network behaviour. I am fairly certain that the existence of particular Bookmarks does not (non-negligibly, anyway) affect network behaviour. Presumably the Tor Browser developers could make sure that the 'hiding' of the opaque onion address and replacement with the Petname is only a cosmetic (UX) change to the URL bar based upon the existence or non-existence of Bookmark-like Petname data for the given hostname. The Tor Browser developers have already decided that Bookmarks do not pose a fingerprinting risk; it follows that we can implement Petnames to not be a risk also.
-
I think the mailing list is the right place for these discussions FWIW. Also see this https://blog.torproject.org/cooking-onions-names-your-onions blog post.
IMO anyone who advocates for a petname solution (which is just a generic term at this point) should provide a precise specification/design plan with clear explanation of why it's superior to browser bookmarks or other systems. Everything can be considered a petname-like solution, including the https-e plan of #28005 (moved).
I'd suggest you take further discussion to the [tor-dev] mailing list, and I welcome any concrete proposals on things we can do here.
mentioned in issue #30558 (moved)
mentioned in issue #33652 (moved)
mentioned in issue #30281 (moved)
