[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [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



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


 > 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.


 > 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-onions. 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-onions.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30024#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs