#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs