[tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,    |  Actual Points:
  network-team-roadmap-november, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002           |
Parent ID:  #30029                               |         Points:  20
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------
Changes (by acat):

 * status:  new => needs_review


Comment:

 Patches for review in https://github.com/acatarineu/tor-
 browser/commit/28005 and
 https://github.com/acatarineu/torbutton/commit/28005. Test builds in
 https://people.torproject.org/~acat/builds/28005_testbuild/. I will also
 attach a short video.

 Some comments:

 This was implemented without any change to the https-everywhere code, just
 the official latest version. For now I went for just observing the https-
 everywhere local redirects as a way to learn the `.tor.onion -> .onion`
 mappings. A test securedrop update channel
 (https://people.torproject.org/~acat/misc/rulesets/) is installed
 programatically on startup [https://github.com/acatarineu/tor-
 browser/commit/28005#diff-f2877e5f680c088366ab9ef15860e3e1R34 here] by
 sending messages to https-everywhere, which are handled in the extension
 [https://github.com/EFForg/https-everywhere/blob/master/chromium
 /background-scripts/background.js#L856 background script]. Probably it's
 not an ideal solution for release, but maybe it's ok for nightly? Ideally,
 replacing the test update channel by an official securedrop one if it's
 available. For testing: note that it might take a while on first startup
 to fetch the update channel and add the rules, so the .tor.onion addresses
 might not work immediately. Currently, only one .tor.onion address is
 available: http://nytimes.securedrop.tor.onion.

 This implementation does not display `.tor.onion` in the urlbar if the
 user has navigated to the corresponding `.onion` directly, only when it
 has done so with `.tor.onion`. We also keep the human-memorable hostname
 in the urlbar for navigations triggered from that page, as long as they
 are in the same origin. This made the implementation a bit more
 complicated than I would have liked, since we have to keep track for each
 "tab" whether we should rewrite the urlbar to `.tor.onion` (we navigated
 to a `.tor.onion`) or not (we navigated to .onion directly). The
 implementation would be significantly simpler if we would treat the two
 cases in the same way (always show `.tor.onion`, even if user navigated
 directly to the corresponding .onion). But I'm not sure if that's
 acceptable UX-wise. If so, we could do that in a next revision, although
 that would require changes to https-everywhere (we should be able to ask,
 for a given `.onion`, whether https-everywhere knows of some human-
 memorable `.tor.onion`).

 Regarding the `Click to Copy` + ellipsis implementation in the circuit
 display, something I'm not sure of is whether we should be copying just
 the `.onion` domain, or the full URL. I would say I expect it to copy just
 the domain (since that's the text we are showing), so I'm not sure if
 that's fine as a solution for the "I want to copy the real `.onion` URL
 when it's rewritten to `.tor.onion`" use case. Besides, should we also
 show the trimmed .onion with ellipsis in the "Site information for ..."?
 The mockups do not show that, in that case the name from the EV
 certificate is used (Pro Public, Inc.).

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