Objective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service version

This is the parent ticket to hold any tickets under this activity, including:

• Investigate the ideal browser user experience for when such a redirection takes place, to minimize user confusion.
• Build the code necessary to optimally support this experience on Tor Browser such as prioritizing .onion addresses when Alt-Svc is used.
• Correctly display the .onion Alt-Svc circuit path on the circuit display.
• Educate the user on how the redirection takes place, so that users get more familiar with the concept of onion services. We will employ appropriate “stop-and-learn” techniques to inform our users of the benefits of onion services and how they should be used.
• Continue work on our Onion-Location proposal which gives the user the option to choose whether or not onion redirect should take place.

Trac:
Parent Ticket: #30281 (moved)
Child Ticket(s): #21952 (moved), #25025 (moved), #27502 (moved), #30599 (moved)

added component::applications/tor browser owner::tbb-team parent::30281 points::21 priority::medium resolution::implemented severity::normal sponsor::27-must status::closed type::project labels

MUSTing tickets.

Trac:
Sponsor: Sponsor27 to Sponsor27-must

Right now this task has no blockers on the network-team since the TB team has inherited the Onion-Location proposal. It's all TB/UX work here, and network-team can be used for reviewing.

Trac:
Parent: N/A to #30281 (moved)

Trac:

Trac:

Trac:

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. onion-location
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 (moved)]

2. onion-location

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.

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
   1. If the rule doesn't exist, we could encourage users to add it. That will be discussed at [#30029 (moved)].
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.

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 (moved). I propose to try a truncated version of the URL that is also easy to verify and copy.

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?

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.

• How valuable is for us showing Onion addresses at the URL in the alt-svc scenario?

• What should we do with vanity domains? Do they become useless if any petname solution is available?

• 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?

• Can Tor Browser prompt users for opt-in to Onions just the first time they visit the site?

• In a good world, we need a section at the Global Preferences about:preferences#security where users can 1. allow/deny Onions prioritization 2. See a list of mapped/saved onions.

Replying to 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 (moved)]

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 (moved).

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 (moved). 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?

Replying to gk:

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.

Yes, the circuit display should render exactly what is happening and the url bar address will not change. Do we want to have an onion icon at the url bar to show that foo.com has been accessed through an onion?

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 (moved).

The identity and the onion icons are triggering the same behavior: open the doorhanger. There is not any actionable behavior at the onion icon but opening the doorhnager. At the moment, they don't open different doorhangers.

The onion icon made explicit that the traffic is going through an onion service, even in the cases where the domain name is not a .onion but this is happening under the hood. That is the main idea behind the onion icon. Ideally, we can rely on this icon as the next iteration of the different security feedback we achieved following up #23247 (moved). This is relevant for Tor Browser because we want to be an educational resource for people to understand when an onion service is being used. For 3rd parties implementing Tor, the onion icon becomes relevant to brand the Tor traffic.

How would you verify a truncated version of the onion address? And what would you use the copy for?

How are users verifying onion addresses integrity nowadays? That is interesting research to run.

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?

As far as I understand, the only scenario that allows us to recommend onions at this moment is alt-onion. Other scenarios may allow us to have an onion icon at the URL bar (when the client knows that an onion service has been used) but cannot trigger that recommendation upfront before user opt-in. That is the main use case for alt-onion.

Replying to antonela:

Replying to gk:

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.

Yes, the circuit display should render exactly what is happening and the url bar address will not change. Do we want to have an onion icon at the url bar to show that foo.com has been accessed through an onion?

We could think about that and test whether that works or not. It might be confusing, though, to just pop an onion icon up without any other visible change. But maybe it is not.

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 (moved).

The identity and the onion icons are triggering the same behavior: open the doorhanger. There is not any actionable behavior at the onion icon but opening the doorhnager. At the moment, they don't open different doorhangers.

The onion icon made explicit that the traffic is going through an onion service, even in the cases where the domain name is not a .onion but this is happening under the hood. That is the main idea behind the onion icon. Ideally, we can rely on this icon as the next iteration of the different security feedback we achieved following up #23247 (moved). This is relevant for Tor Browser because we want to be an educational resource for people to understand when an onion service is being used. For 3rd parties implementing Tor, the onion icon becomes relevant to brand the Tor traffic.

Sounds good to me, re: functionality of onion icon. What does "Ideally, we can rely on this icon as the next iteration of the different security feedback we achieved following up #23247 (moved)." mean?

[snip]

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?

As far as I understand, the only scenario that allows us to recommend onions at this moment is alt-onion. Other scenarios may allow us to have an onion icon at the URL bar (when the client knows that an onion service has been used) but cannot trigger that recommendation upfront before user opt-in. That is the main use case for alt-onion.

That part sounds good to me.

Replying to gk:

Sounds good to me, re: functionality of onion icon. What does "Ideally, we can rely on this icon as the next iteration of the different security feedback we achieved following up #23247 (moved)." mean?

As part of #30025 (moved), we could consider iterating the security indicators made back in #23247 (moved). That will allow us to achieve consistency across the significant pieces of this puzzle and also align the decisions with Firefox's approach on warnings.

A first draft here.

Trac:
Points: N/A to 21

Trac:
Resolution: N/A to implemented
Status: new to closed

closed

changed time estimate to 168h

mentioned in issue #30599 (moved)

mentioned in issue #32256 (moved)

mentioned in issue #33516 (moved)

mentioned in issue #30281 (moved)

mentioned in issue tpo/web/trac#33516 (closed)

moved to tpo/applications/tor-browser#30024 (closed)