[tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Feb 27 15:34:10 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: 15
network-team-roadmap-november, network-team- |
roadmap-2020Q1, TorBrowserTeam202002 |
Parent ID: #30029 | Points: 20
Reviewer: mcs, sysrqb | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by antonela):
Thanks for your build acat! It works really smoothly on my end :)
Replying to [comment:21 acat]:
> Some comments:
>
> 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`).
>
>
I really expect to render the memorable name at the URL bar in both cases:
using the .onion and using the .tor.onion. If it requires a patch on
https-e then we can work with https-e folks on it for the next release.
> 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.).
>
>
The main reason for the `click to copy` feature is allowing users to
(manually) check integrity. So, yes. The circuit display should render the
onion address, always. I remember a discussion about using
(https://trac.torproject.org/projects/tor/ticket/30024#comment:4).,
trimmed addresses).
Also, we should use the memorable name at "Site information for.." header.
From now, memorable names are onion services alias. Something that might
be interesting for the next iteration is working on the second level
navigation of the identity doorhanger (Site Security) to improve the
information showed there. We may want to show the origin entire onionsite
address and also if it exists, data about certificates. There is room for
improvement on that section for advanced users.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list