[tbb-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]

#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:6 antonela]:
 > Replying to [comment:5 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.
 > >
 > 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. 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." 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30024#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online