[tor-bugs] #30024 [Applications/Tor Browser]: Objective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service version
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 22 13:30:07 UTC 2019
#30024: Objective 2, Activity 3: Notify users if a current website they are
visiting on Tor Browser has an onion service version
--------------------------------------+--------------------------------
Reporter: pili | Owner: tbb-team
Type: project | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: #30281 | Points:
Reviewer: | Sponsor: Sponsor27-must
--------------------------------------+--------------------------------
Comment (by gk):
Replying to [comment:4 antonela]:
> Hi. Making .onions discoverable is a must for Tor Browser.
>
> We have three different ways (for now) for routing Onion addresses. Each
of them affects differently on two major UI components: The URL bar and
the circuit display at the Identity doorhanger. I've started mapping each
UX and describing how those UI components get affected:
>
> 1. alt-svc
> 2. alt-onion
> 3. https-e
>
> **1. alt-svc**
>
> 1. User type the known URL with a regular domain.
> 2. On server-side, the user gets redirected.
> 3. The Onion icon gets added at the URL bar. The URL could remain. The
circuit display shows the Onion address [#27590]
What is the functionality of the onion icon here? The circuit display is
bound to the load of the website. Thus, either it got already loaded over
alt-svc or not. In either case the circuit display should match what
actually happened. I don't think we should bind it to whether the user
clicked on the onion icon or not. And, yes, it is crucial that the URL
remains as it is in this scenario as it is, as there is not really a
redirect happening.
> **2. alt-onion**
>
> When users are visiting a site which also has an Onion service
available, the ideal user flow allows users to opt-in to visiting an
onion. It is what alt-onion can offer to us, as follow:
>
> 1. User type the known URL with a regular domain.
> 2. If the Onion exists, the URL bar suggest an .onion.
> 3. User click the suggestion
> 1. Tor Browser should save this opt-in and only prompt first-time
users
> 4. The Onion Icon gets added at the URL bar. The URL could remain. The
circuit display shows the Onion address.
Again, what is the functionality of the .onion icon? Does the .onion
version get loaded once I click on it? If so, then the URL bar domain
should change and the circuit display. If not then both should stay as the
display is bound to the actual requests happen(ed).
We need to think about the opt-in saving here as well and how we expose
that, as in #30237.
> **3. https-e**
>
> With this option, we are introducing the opportunity to have a readable
and memorable onion domain name. That option will make sense when we
expose the .onion domain at the URL bar.
>
> 1. User type the known URL with a regular domain.
> 2. If the rule exists, the URL bar suggest a .onion
When does that and 2.1, 3. and 3.1 happen? After the user hits Enter?
> 1. If the rule doesn't exist, we could encourage users to add it.
That will be discussed at [#30029].
> 3. User click the suggestion
> 1. Tor Browser should save this opt-in to only prompt first-time
users
> 4. The Onion Icon gets added at the URL bar. The URL changes to show the
.onion domain. The circuit display shows the Onion address.
I assume this happens together with actually loading the .onion URL which
would be fine from my PoV.
> **The case of the long Onion addresses**
>
> We will continue to have long Onion addresses for a while. What if we
improve the way we are showing them at the circuit display? We reported
some UI bugs, like #26322. I propose to try a truncated version of the URL
that is also easy to verify and copy.
How would you verify a truncated version of the onion address? And what
would you use the copy for?
> `p53lf57qovyuvwsc6xnrppyply3vtqm7l6pcobkmyqsiofyeznfu5uqd.onion →
p53lf5....fu5uqd.onion`
>
> Could we apply any heuristic that help us to define how many characters
are smart to have at the start and and the end? Can we allow users to copy
the full address from the circuit display?
Sure copying the full address sounds fine. However, I am wary of any
truncated version. This sounds like a security risk and we should not
encourage dealing with truncated .onions either I think.
>
> **Some general thoughts and questions:**
>
> - We should prioritize the exposure of Onion domains at the URL bar if
they are readable and memorable for various reasons. On the product side,
we should reinforce the communication about the benefits of using Onion
services.
>
> - Onion addresses should get exposed at the circuit display *always*.
If the requests went over the onion, yes. Otherwise I don't think so as
the circuit display is meant to inform the user which route their traffic
went.
> - How valuable is for us showing Onion addresses at the URL in the alt-
svc scenario?
Dunno, but we should not do that as this mechanism is explicitly meant to
be "under the hood" to not change the security context.
> - What should we do with vanity domains? Do they become useless if any
petname solution is available?
What's the issue with those domains?
> - If as a user I'm logged in foo.com and I opt-in/getredirected to the
.onion, will I lose my login? Should we notice users about this?
That depends on how that is implemented at the sever-side, but yes,
chances are that this is happening if the URL bar domain changes as cookie
scopes etc. changes that way. Not sure yet whether we should notify users.
> - Can Tor Browser prompt users for opt-in to Onions just the first time
they visit the site?
I am not sure what that means? Which of the 3 scenarios above do you have
in mind here? And how does that work with Tor Browser not saving state to
disk?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30024#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list