[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 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs