[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization
#30237: Tor Browser: Improve TBB UI of hidden service client authorization
--------------------------------------+-----------------------------------
Reporter: asn | Owner: tbb-team
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: TorBrowserTeam201905 | Actual Points:
Parent ID: #30000 | Points:
Reviewer: | Sponsor: Sponsor27-must
--------------------------------------+-----------------------------------
Comment (by antonela):
We talked a bit about the notification prompt, and I think it is a
possible solution. It works per site, and the key icon is straightforward
to identify for end-users as a password need. The downside of it is how
confusing it is when the public key is not a password. And, as mentioned
in [[comment:6]] prompts are usually optional. If a user cancels the
prompt, will we render an error page? How can we allow users to recover
from that flow to successfully add a key and access the website?.
[[Image(https://trac.torproject.org/projects/tor/raw-
attachment/ticket/30237/30237-prompt.1.png, 700px)]]
The primary use of the password manager notification is for saving
passwords. Therefore, are we going to allow users to save their used key?.
Logins in Firefox has two general settings in Preferences. The first will
enable users to remember logins for sites, and the second allows users to
use or not a master password. What happens if users have "Remember logins
for sites" disabled? What happens if users are using a master password?
Mixing private keys and passwords seems a complicated idea.
We can still use the notification doorhanger UI, tho. We need to be
careful about to mimic the password behavior for a different flow. We
should consider a scenario when the input fails, or the users have
disabled the prompts at the General Preferences. If we allow users to re-
use their saved key, we will need a specific section at Preferences to
manage the saved private keys.
----
When I realized about the sad error recovering flow that the native HTTP
Auth box is offering [[comment:1]], I also thought about to take over the
DOM via an XHTML page. Back then, I made a mockup of it. The main question
remains in how spoofable it is from a random website.
[[Image(https://trac.torproject.org/projects/tor/raw-
attachment/ticket/30237/30237-xhtml.1.png, 700px)]]
----
So, we have four routes for this UI implementation:
1. an HTTP Auth UI + custom errors
2. a notification doorhanger
3. a XHTML page
4. a custom modal
Which of them is more comfortable for users to understand what is the task
there? Which of them can empower users to recover from an error? Which of
them allow users to re-use their key? From the development perspective,
which of these options is good enough for managing errors, scalable, and
doable in the timeframe we have set for this scope?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30237#comment:13>
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