Re: [tor-bugs] #30029 [Applications/Tor Browser]: Objective 2, Activity 5: POC for Human-memorable addresses for .onion services

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30029: Objective 2, Activity 5: POC for Human-memorable addresses for .onion
services
--------------------------------------+--------------------------------
 Reporter:  pili                      |          Owner:  tbb-team
     Type:  project                   |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:  #30281                    |         Points:
 Reviewer:                            |        Sponsor:  Sponsor27-must
--------------------------------------+--------------------------------

Comment (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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30029#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs