[tor-bugs] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  legind
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS           |        Version:
  Everywhere                                     |
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,    |  Actual Points:
  network-team-roadmap-november,                 |
  TorBrowserTeam202001, network-team-roadmap-    |
  2020Q1                                         |
Parent ID:  #30029                               |         Points:  20
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by antonela):

 Replying to [comment:11 acat]:
 > Some thoughts after thinking a bit how to implement this.

 thanks for sharing this walking through, acat :)

 > A few questions/issues regarding showing short `.tor.onion` in urlbar:
 >
 >   1. Whenever there is a `.tor.onion` -> `.onion` redirect, should we
 display the full original URL in the urlbar,   or just replace the
 hostname for the human-memorable one in the final URL? For example, let's
 say we observe a redirect from http://nytimes.securedrop.tor.onion to
 https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from
 `.tor.onion` + adding www). In this case I think it would not make much
 sense to show the original URL, but just display
 https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution
 I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on
 it).
 >

 Right. The urlbar should display the onion icon + the .onion name:
 `[⊚] https://www.[nytimes.securedrop.tor.onion]`

 >   2. What should we do when user keeps navigating in subpages of some
 `.onion`, given the fact that the `.tor.onion` -> `.onion` is only
 observed in the first navigation? Should we show the human-memorable
 `.tor.onion` in the urlbar for that tab until the user navigates away from
 the underlying `.onion`? Do we also need to show `.tor.onion` for links
 opened in a new tab from there?
 >

 Maybe, ideally, yes. I wonder what sysrqb or pospeselr think about this.
 It is hard for me to map all the problems it could carry.

 >   3. Do we need to show `.tor.onion` when user navigates directly to a
 `.onion` page for which we have some `.tor.onion` "rule"? (mentioned by
 sysrqb in a IRC conversation)
 >

 This is a good question and I think we should define it before anything
 because it can be very weird. If we have a strong communication about
 onion names (via trusted parties, like SecureDrop), then showing an
 unmemorable onion address to end-users is not smart. If a user
 writes/copypaste the `.onion` we can think about how to communicate the
 `.tor.onion` redirect for first time users with any UI fashion (a
 doorhanger can do this work very nicely)

 > So I would suggest discussing/deciding about the `Add support for
 viewing rulesets (?)` feature, as I'm not sure how it could look like if
 we are going to do this with https-everywhere.
 >

 Maybe this is out of scope. We will not allow users to add nor remove
 .onion related rulesets. IMO showing them at the UI is not needed on this
 sprint.

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