Opened 5 weeks ago

Last modified 46 minutes ago

#30237 needs_information defect

Tor Browser: Improve TBB UI of hidden service client authorization

Reported by: asn Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201905
Cc: gaba Actual Points:
Parent ID: #30000 Points:
Reviewer: Sponsor: Sponsor27-must

Description

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

This used to be #14389, but it contained too many network-team-specific information so I repurposed #14389 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

Child Tickets

Attachments (7)

30237-1.png (207.7 KB) - added by antonela 3 weeks ago.
30237-2.png (214.2 KB) - added by antonela 3 weeks ago.
30237-3.png (188.1 KB) - added by antonela 3 weeks ago.
30237-1.1.png (198.3 KB) - added by antonela 3 weeks ago.
30237-2.1.png (269.6 KB) - added by antonela 3 weeks ago.
http-auth.png (557.1 KB) - added by antonela 2 days ago.
client-auth-notification-mockup-1.png (102.2 KB) - added by mcs 49 minutes ago.

Download all attachments as: .zip

Change History (16)

Changed 3 weeks ago by antonela

Attachment: 30237-1.png added

Changed 3 weeks ago by antonela

Attachment: 30237-2.png added

Changed 3 weeks ago by antonela

Attachment: 30237-3.png added

comment:1 Changed 3 weeks ago by antonela

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

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/30237-1.png

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?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/30237-2.png


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.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/30237-3.png

Last edited 3 weeks ago by antonela (previous) (diff)

Changed 3 weeks ago by antonela

Attachment: 30237-1.1.png added

Changed 3 weeks ago by antonela

Attachment: 30237-2.1.png added

comment:2 Changed 3 weeks ago by 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.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/30237-1.1.png

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

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/30237-2.1.png

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.

comment:3 in reply to:  2 ; Changed 3 weeks ago by asn

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?

comment:4 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:5 in reply to:  3 Changed 6 days ago by antonela

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.

comment:6 Changed 3 days ago by mcs

Status: newneeds_information

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?

comment:7 in reply to:  6 Changed 2 days ago by acat

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.

Changed 2 days ago by antonela

Attachment: http-auth.png added

comment:8 Changed 33 hours ago by gk

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.

Changed 49 minutes ago by mcs

comment:9 Changed 46 minutes ago by mcs

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:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/client-auth-notification-mockup-1.png

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.

Note: See TracTickets for help on using tickets.