[tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Feb 17 17:22:32 UTC 2020
#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
More information about the tor-bugs
mailing list