#28005: Officially support onions in HTTPS-Everywhere -------------------------------------------------+------------------------- Reporter: asn | Owner: legind Type: defect | Status: new Priority: Medium | Milestone: Component: HTTPS Everywhere/EFF-HTTPS | Version: Everywhere | Severity: Normal | Resolution: Keywords: tor-hs, https-everywhere, tor-ux, | Actual Points: network-team-roadmap-november, | TorBrowserTeam202001, network-team-roadmap- | 2020Q1 | Parent ID: #30029 | Points: 20 Reviewer: | Sponsor: | Sponsor27-must -------------------------------------------------+-------------------------
Comment (by antonela): Replying to [comment:11 acat]: > Some thoughts after thinking a bit how to implement this. thanks for sharing this walking through, acat :) > A few questions/issues regarding showing short `.tor.onion` in urlbar: > > 1. Whenever there is a `.tor.onion` -> `.onion` redirect, should we display the full original URL in the urlbar, or just replace the hostname for the human-memorable one in the final URL? For example, let's say we observe a redirect from http://nytimes.securedrop.tor.onion to https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from `.tor.onion` + adding www). In this case I think it would not make much sense to show the original URL, but just display https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on it). > Right. The urlbar should display the onion icon + the .onion name: `[⊚] https://www.[nytimes.securedrop.tor.onion]` > 2. What should we do when user keeps navigating in subpages of some `.onion`, given the fact that the `.tor.onion` -> `.onion` is only observed in the first navigation? Should we show the human-memorable `.tor.onion` in the urlbar for that tab until the user navigates away from the underlying `.onion`? Do we also need to show `.tor.onion` for links opened in a new tab from there? > Maybe, ideally, yes. I wonder what sysrqb or pospeselr think about this. It is hard for me to map all the problems it could carry. > 3. Do we need to show `.tor.onion` when user navigates directly to a `.onion` page for which we have some `.tor.onion` "rule"? (mentioned by sysrqb in a IRC conversation) > This is a good question and I think we should define it before anything because it can be very weird. If we have a strong communication about onion names (via trusted parties, like SecureDrop), then showing an unmemorable onion address to end-users is not smart. If a user writes/copypaste the `.onion` we can think about how to communicate the `.tor.onion` redirect for first time users with any UI fashion (a doorhanger can do this work very nicely) > So I would suggest discussing/deciding about the `Add support for viewing rulesets (?)` feature, as I'm not sure how it could look like if we are going to do this with https-everywhere. > Maybe this is out of scope. We will not allow users to add nor remove .onion related rulesets. IMO showing them at the UI is not needed on this sprint. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:15> 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