#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs