Opened 20 months ago

Closed 8 months ago

#30029 closed project (implemented)

Objective 2, Activity 5: POC for Human-memorable addresses for .onion services

Reported by: pili Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: network-team-roadmap-november, network-team-roadmap-2020Q1, TorBrowserTeam202004
Cc: gaba Actual Points:
Parent ID: #30281 Points: 50
Reviewer: Sponsor: Sponsor27-must


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.

Child Tickets

#28005closedtbb-teamOfficially support onions in HTTPS-EverywhereApplications/Tor Browser

Change History (16)

comment:1 Changed 20 months ago by gk

Sponsor: Sponsor27Sponsor27-must

MUSTing tickets.

comment:2 Changed 20 months ago by asn

Parent ID: #30281

comment:3 Changed 20 months ago by cypherpunks

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.onion part 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.

Last edited 20 months ago by cypherpunks (previous) (diff)

comment:4 Changed 19 months ago by dkg

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.

comment:5 Changed 19 months ago by cypherpunks

dkg, thank you for your 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.

Last edited 19 months ago by cypherpunks (previous) (diff)

comment:6 Changed 19 months ago by asn

I think the mailing list is the right place for these discussions FWIW.
Also see this 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.

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.

comment:7 Changed 17 months ago by gaba

Keywords: network-team-roadmap-november added

comment:8 Changed 15 months ago by pili

Points: 50

comment:9 Changed 15 months ago by pili

Keywords: TorBrowserTeam201910 added

comment:10 Changed 14 months ago by pili

Keywords: TorBrowserTeam201911 added; TorBrowserTeam201910 removed

comment:11 Changed 12 months ago by pili

Keywords: TorBrowserTeam202001 added; TorBrowserTeam201911 removed

Moving tickets to January

comment:12 Changed 11 months ago by gaba

Keywords: network-team-roadmap-2020Q1 added

comment:13 Changed 10 months ago by pili

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed

Moving tickets to February

comment:14 Changed 9 months ago by pili

Keywords: TorBrowserTeam202003 added; TorBrowserTeam202002 removed

We are no longer in February, moving tickets

comment:15 Changed 8 months ago by pili

Keywords: TorBrowserTeam202004 added; TorBrowserTeam202003 removed

We are no longer in March

comment:16 Changed 8 months ago by pili

Resolution: implemented
Status: newclosed

We are done here for now

Note: See TracTickets for help on using tickets.