Tor Browser: Improve TBB UI of hidden service client authorization

This is the parent ticket for Sponsor27 Objective1 Activity1 about improving the UI of client authorization.

This used to be #14389 (moved), but it contained too many network-team-specific information so I repurposed #14389 (moved) to be about the network-team side of things, and please use this ticket for the Tor Browser side of things.

Resources about setting up client auth: https://2019.www.torproject.org/docs/tor-onion-service.html.en#CookieAuthentication https://lists.torproject.org/pipermail/tor-project/2019-January/002180.html and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L3021 and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L1122

Trac:
Parent Ticket: #30000 (moved)

added 9.5a5 TorBrowserTeam202001R actualpoints::16.2 component::applications/tor browser network-team-roadmap-2020Q1 network-team-roadmap-september owner::mcs parent::30000 points::17 priority::medium resolution::implemented reviewer::richard reviewer::sysrqb severity::normal sponsor::27-must status::closed type::enhancement labels

Trac:

Trac:

Trac:

Hi, I'm working back on this ticket. I listed some user stories to make sure that we are handling these various user flows with the implementation:

As a user, I want to access to an authenticated .onion. I type the .onion address at the URL bar, and I get a user/password prompt. I fill the user/password field to access the onion website. I succeed.

This UI will looks like


As a user, I want to access to an authenticated .onion. I type the .onion address at the URL bar, and I get a user/password prompt. I fill the user/password field to access the onion website. I fail.

For users who cancel the prompt or fail with the credentials, the default ux is very sad. Could we think together about how we can allow users to recover from those situations? Is a password error message like "Enter a valid password" doable? What happens if users enter a non-existent user name in the user field? Are these situation able to validate? Is that part of this scope?


** As a recurrent user, I want to save the authenticated .onion credentials. I type the .onion address at the URL bar, and a get a password prompt. I succeed. I want to save these credentials in the browser password manager.**

As suggested in #14389, we could explore how to use default Firefox save password flow to allow users to save these credentials. After the user succeed on accessing the .onion, the password saving will prompt.


Trac:

Trac:

Following the specs, we don't have user/password, end-users just have a private key. So, I updated the first user story's UI.


For the second user story, we may want to consider a different kind of validation scenarios. Following Firefox Photon UI, user input errors should be exposed at the UI as an in-line validation. And, system errors should be presented with a message bar. Both use cases are rendered here


We should work on this validation. I made a first approach for this content, please feel free to suggest/add/remove any of this lines:

= Type =	= Error =	= UI Message =
User Input	incomplete form	Please, enter your private key
User Input	over/under character or word count	Must have 52 characters
System Error	misspelled errors	The private key is wrong. Try again.
System Error	connectivity issues	There was an error. Check your internet connection and try again.
System Error	failure to load	There was an error handling your request. Try again.

Which else error scenario should we consider?

For the 3rd user story, we don't have a proper password, so saving the privkey in the password manager seems weird. Perhaps, we can think about it for the next iteration.

Replying to antonela:

Following the specs, we don't have user/password, end-users just have a private key. So, I updated the first user story's UI.

Looks good. Not sure how we can do better than "Private Key" but perhaps we should. Perhaps we can write "Personal key" or "key" and then have more info in a "?" box? No idea...

We should work on this validation. I made a first approach for this content, please feel free to suggest/add/remove any of this lines:

||= Type =||= Error =||= UI Message =|| || User Input ||incomplete form|| Please, enter your private key || || User Input ||over/under character or word count|| Must have 52 characters || || System Error ||misspelled errors|| The private key is wrong. Try again. || || System Error ||connectivity issues|| There was an error. Check your internet connection and try again. || || System Error ||failure to load|| There was an error handling your request. Try again. ||

Which else error scenario should we consider?

The first two errors can indeed be detected and IMO should be detected.

The misspelled errors can be detected (by checking whether we could decrypt the descriptor with the key), but depending on how communication channel between TB<->Tor works, we might not learn the result on time to keep the auth dialog open. So we would have to respawn the auth dialog to throw the error. Does this make sense, and is it ok?

Same for connectivity issues and failure to load but perhaps this should be handled the same way as #30025 (moved)?

Moving tickets to May

Trac:
Keywords: TorBrowserTeam201904 deleted, TorBrowserTeam201905 added

Replying to asn:

Looks good. Not sure how we can do better than "Private Key" but perhaps we should. Perhaps we can write "Personal key" or "key" and then have more info in a "?" box?

Private Key seems the most appropriate term for what users should input there. I like the idea of having a [?]. We should figure out which content we would like to have at the [?]. I think we should link to something like support.torproject.org/onionservices/auth where end-users will have information about what the key is, how they can get it.

The misspelled errors can be detected (by checking whether we could decrypt the descriptor with the key), but depending on how communication channel between TB<->Tor works, we might not learn the result on time to keep the auth dialog open. So we would have to respawn the auth dialog to throw the error. Does this make sense, and is it ok?

Yes, exactly. Those two different kind of errors are defined by how the UI react to it. For System Errors we must to reload the auth dialog. Users will click Done and then the dialog box will reload with the error.

The mockups from comment:2 show a prompt that is contained entirely within the content area. How concerned should we be about the "line of death" issue (https://textslashplain.com/2017/01/14/the-line-of-death/)? It seems like a bad idea to implement a prompt that any site could easily spoof, but there are tradeoffs to consider.

This question came up as Kathy and I looked at various options within the Firefox codebase for implementing the client auth prompt. We might be able to use a doorhanger that includes an arrow that overlaps the chrome area (thus avoiding the "line of death" problem). But doorhangers within Firefox are designed for optional interactions and entering a key for client auth is not optional.

We could use the prompt service (which is what HTTP basic auth uses), but the prompts that are available to us are not very flexible. It might be a lot of work to achieve the look we want; for example, I am not sure how to implement the inline validation requirement. A final option is to just implement an xhtml page (similar to what Firefox uses for network error pages) where the entire prompt is contained within the content area. That would give us the most flexibility, but of course "line of death" is an issue.

Antonela and others: what do you think?

Trac:
Status: new to needs_information

Replying to mcs:

The mockups from comment:2 show a prompt that is contained entirely within the content area. How concerned should we be about the "line of death" issue (https://textslashplain.com/2017/01/14/the-line-of-death/)? It seems like a bad idea to implement a prompt that any site could easily spoof, but there are tradeoffs to consider.

This question came up as Kathy and I looked at various options within the Firefox codebase for implementing the client auth prompt. We might be able to use a doorhanger that includes an arrow that overlaps the chrome area (thus avoiding the "line of death" problem). But doorhangers within Firefox are designed for optional interactions and entering a key for client auth is not optional.

We could use the prompt service (which is what HTTP basic auth uses), but the prompts that are available to us are not very flexible. It might be a lot of work to achieve the look we want; for example, I am not sure how to implement the inline validation requirement. A final option is to just implement an xhtml page (similar to what Firefox uses for network error pages) where the entire prompt is contained within the content area. That would give us the most flexibility, but of course "line of death" is an issue.

Antonela and others: what do you think?

Interesting read :)

How difficult would it be to have a new kind of prompt/modal that mimics HTTP auth behaviour, but with the style/layout of the Onion Auth mockups? For behaviour I mean darkening the background (also above line of death) and blocking the browser UI.

Trac:

It seemed we are on the same page here that we don't want to have line-of-death-issues. Thus, this already cuts down possible options. Not sure how much we still have available though.

I am not sure how to deal with user story 3 either as by default saving things to disk is not allowed in Tor Browser. I think the risks are in particular evident for private keys. So, we'd have to think about how we would offer users this option if at all.

Trac:

Kathy and I have been exploring whether we can use Mozilla's notifications module (toolkit/modules/PopupNotifications.jsm) to implement the onion services authentication prompt. This would produce a doorhanger and would look a lot like the password manager's prompts. Here is a mockup:


Antonela, Georg, and others: do you think this is an acceptable approach?

A side note: if it is important, we can move the "Learn more…" link up near "Onion Authentication"; we get it "for free" in the location shown because that is how Mozilla positions it within their other prompts.

Hah, almost the same idea as I had tonight. :) Yes, I think we should try to use that one and style it so nobody thinks it is a browser username/password prompt. And I think we should make it modal. That should give another hint about the dialog being not a usual username/password prompt. "modal" not in the sense of the HTTP authentication dialog which pops up if you load a page but need to wait and get bored switching to a different tab and suddenly an authentication prompt pops up out of nowhere. We should not do that. But "modal" in the sense that you can't click it away if you are on the page unless you either press Cancel or Done.

What is this feature? Looks like something new. Could you document it?