[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, network-   |  Actual Points:  15
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202002, ux-team          |
Parent ID:  #30029                               |         Points:  20
 Reviewer:  mcs, sysrqb, antonela                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by mcs):

 Kathy and I did a quick review of the patches (comment:21). Overall, very
 impressive work! We know you are working on a revision already, but here
 are some comments:
 * UX: For the circuit display, does it make sense to show the full onion
 address on hover? (in addition to the "Click to Copy" functionality). That
 could be done with a tooltip and would allow users to see the complete
 name without pasting somewhere else.
 * Please add some more detail to the tor-browser commit message.
 * Please add copyright notices to the new files
 (browser/components/onionalias/*).
 * We wish that the tor-browser patch did not have to touch the Firefox
 code in so many places. That might be unavoidable though. Please add some
 comments near the added codeblocks; for example, to explain the places you
 perform origin checks.
 * In docshell/base/nsDocShell.cpp, there is no need to check that `oldURI`
 and `newURI` are defined since they are checked by code immediately above
 the code you added.
 * In toolkit/content/widgets/browser-custom-element.js,
 `this._allowOnionUrlbarRewrites` is initialized to `null` but it would be
 clearer and more consistent to initialize it to `false`.
 * In toolkit/content/widgets/browser-custom-element.js, there is a typo:
 `this.docShell.allowOnionUrlbarRewritesu` (trailing `u`).
 * In browser/components/onionalias/OnionAliasStore.jsm, it seems that
 nothing is ever removed from `_onionMap` while the browser is running.
 Will this cause any problems? For example, what happens if an HTTPS-E rule
 update removes some mappings?
 * The `.tor.onion` illusion is not complete. For example, I noticed that
 when I created a bookmark the unfriendly `.onion` name was stored in the
 bookmark. It might be difficult to find and fix all cases like this
 though. In the long run, I wonder if we can learn something from how
 things like AltSvc are implemented (I assume AltSvc is handled at a much
 lower level than the URL bar but I have not looked closely).

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