[tbb-bugs] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed May 29 16:45:09 UTC 2019
#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 brade):
Replying to [comment:13 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? ...
I agree that the key icon is not necessarily ideal but I assume it would
be straightforward to use our own icon for onion services. Is changing
the icon in the URL bar and the icon in the door hanger sufficient to set
apart our set of prompts from login manager prompts?
Yes, if a user cancels the prompt, they will see an error page. They will
need to reload the page to see the prompt again (I believe there is a "Try
again" button on the error page).
> 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.
I'm not sure if we should mix the saving of keys with the saving of
passwords. Mark and I were thinking that we could provide a "Remember
this key" checkbox in the prompt and if checked the key would be stored in
the user's `torrc` file. Building an interface to managed stored client
auth keys probably deserves its own ticket; I don't see us getting to that
during this first round (before the end of June).
> 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?
Mark and I think that options 1 and 4 will require a lot of work to
achieve a good looking prompt and that the approach is too modal (we
really want a prompt that is modal to the tab but not to the entire
Option 3 will result in a prompt that is easy for a phishing site to
We think we can achieve a good experience with option 2. We can prevent
the notification prompt from disappearing until the user clicks "Cancel"
or "Done" and we can customize the appearance as needed.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30237#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs