[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_revision
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R         |
Parent ID:  #30029                               |         Points:  20
 Reviewer:  mcs, sysrqb, antonela                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by acat):

 Thanks for the review, addressed the comments in
 https://github.com/acatarineu/tor-browser/commit/28005+6.


 Replying to [comment:46 sysrqb]:

 > Is aLocationURI equal to gBrowser.selectedBrowser.currentURI at this
 point?
 I'm not completely sure, but even if it is, that might change in the
 future so I think using aLocationURI is more reasonable. I fixed that.

 >  Should we have a pref that prevents mAllowOnionUrlbarRewrites being
 true?
 I think it's reasonable. I added the check in the getter, in docShell.cpp.

 > Is the "newHost ends with .onion" helpful here?
 Currently we check for "is it a redirect from .tor.onion to .onion (and
 not .tor.onion)"

 Do you mean we could just check for "redirect from .tor.onion to
 anything", or "redirect from .tor.onion to .onion (including .tor.onion)"?

 > I believe this applies for both ts === 0 and null, correct? Can you
 mention null in the comment, as well?
 I changed the code to check explicitly for 0. I think the only case where
 it could return null is if the SecureDropTorOnion update channel has been
 removed, and in that case we don't want to reschedule another check soon.

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