Opened 5 months ago

Last modified 4 weeks ago

#30237 new 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: TorBrowserTeam201907, network-team-roadmap-september
Cc: gaba, pospeselr 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 (11)

30237-1.png (207.7 KB) - added by antonela 5 months ago.
30237-2.png (214.2 KB) - added by antonela 5 months ago.
30237-3.png (188.1 KB) - added by antonela 5 months ago.
30237-1.1.png (198.3 KB) - added by antonela 5 months ago.
30237-2.1.png (269.6 KB) - added by antonela 5 months ago.
http-auth.png (557.1 KB) - added by antonela 4 months ago.
client-auth-notification-mockup-1.png (102.2 KB) - added by mcs 4 months ago.
30237-prompt.1.png (183.6 KB) - added by antonela 4 months ago.
30237-xhtml.1.png (192.8 KB) - added by antonela 4 months ago.
30237-prompt.2.png (169.9 KB) - added by antonela 4 months ago.
client auth prompt rev1.png (56.1 KB) - added by mcs 3 months ago.

Change History (37)

Changed 5 months ago by antonela

Attachment: 30237-1.png added

Changed 5 months ago by antonela

Attachment: 30237-2.png added

Changed 5 months ago by antonela

Attachment: 30237-3.png added

comment:1 Changed 5 months 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 5 months ago by antonela (previous) (diff)

Changed 5 months ago by antonela

Attachment: 30237-1.1.png added

Changed 5 months ago by antonela

Attachment: 30237-2.1.png added

comment:2 Changed 5 months 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 5 months 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 4 months ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:5 in reply to:  3 Changed 4 months 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 4 months 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 4 months 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 4 months ago by antonela

Attachment: http-auth.png added

comment:8 Changed 4 months 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 4 months ago by mcs

comment:9 Changed 4 months 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.

comment:10 Changed 4 months ago by gk

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.

Last edited 4 months ago by gk (previous) (diff)

comment:11 Changed 4 months ago by cypherpunks

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

comment:12 in reply to:  9 Changed 4 months ago by asn

Replying to 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.

Yes I think this is totally an acceptable approach. And I was not aware of the line-of-death issue but it does make sense.

Changed 4 months ago by antonela

Attachment: 30237-prompt.1.png added

Changed 4 months ago by antonela

Attachment: 30237-xhtml.1.png added

comment:13 Changed 4 months ago 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 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?.

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

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 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.

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


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?

comment:14 Changed 4 months ago by pospeselr

Cc: pospeselr added

comment:15 in reply to:  13 ; Changed 4 months ago by brade

Replying to 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 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 window).

Option 3 will result in a prompt that is easy for a phishing site to spoof.

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.

Changed 4 months ago by antonela

Attachment: 30237-prompt.2.png added

comment:16 in reply to:  15 ; Changed 4 months ago by antonela

Replying to brade:

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.

All good. We should make sure that we are not mixing the password/auth flow. Maybe, we can achieve that by removing the key icon at the URL bar.

We will not have an inline validation for user input errors; all the errors will render in an error page. Am I right?

I'll work on the error page in the meantime. Do we have different errors? Which errors we are going to handle?

Personally, I'd prefer to get closer to the HTTP auth standard instead of introducing a new user flow. If the doorhanger implementation is easier for doing it than the regular popup, it is good.

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

comment:17 in reply to:  16 Changed 4 months ago by brade

Replying to antonela:

...
We will not have an inline validation for user input errors; all the errors will render in an error page. Am I right?

I'll work on the error page in the meantime. Do we have different errors? Which errors we are going to handle? ...

Errors specifically related to user input of a key will be displayed in a doorhanger-like prompt, and Mark and I think we should be able to do inline validation there. For this bug we are focused on error codes 0xF4 and 0xF5 as described in this page:

https://lists.torproject.org/pipermail/tor-dev/2019-May/013835.html

Let's move the discussion about other errors to ticket #30025. Those errors can be displayed in the content area. We haven't done detailed research yet, but we are hoping to build on Firefox's ESR68 error pages.

That said, Mark and I are trying to stay focused on client auth so we can get something working before we must switch to ESR68 work. In fact, it probably makes sense for you to give us another week to determine if the doorhanger-like approach we are currently pursuing will work out before you invest more time in UX design for this ticket.

comment:18 Changed 3 months ago by gk

Keywords: TorBrowserTeam201906 added; TorBrowserTeam201905 removed

Moving tickets to June

Changed 3 months ago by mcs

Attachment: client auth prompt rev1.png added

comment:19 Changed 3 months ago by mcs

Status: needs_informationnew

Kathy and I pushed our "work in progress" patches for tor-browser, Torbutton, and Tor Launcher so that anyone who is interested can look at what we have so far:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-01&id=d92a5bd3fd961b7b9f05383501b1bc3ed6391ecb
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug30237-01&id=a7e7992a9fa749e99bfad1a724672b6091cba1ad
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug30237-01&id=44931dac3bb51fc45aacc53c6a27e2983e84c7ac

Here is a screenshot (yes, it will look better without the onion name redacted):

https://trac.torproject.org/projects/tor/raw-attachment/ticket/30237/client%20auth%20prompt%20rev1.png

Significant loose ends include:

  • Our tor-browser changes do not support localization (see the many places that are marked with L10n). Kathy and I would like to understand our localization strategy in a post-Torbutton world before we work on L10n support.
  • We need to insert the correct "Learn More" URL.
  • The text/copy will need some work. Some concepts are difficult to communicate clearly. For example, if the user enters a key of the wrong length or format, we currently show the somewhat cryptic validation error that is visible in the screenshot I posted.
  • We need artwork for the onion icon that is used within the prompt (and if it would be better to do so, we could remove it). As a placeholder, we are using a plain onion image that we downloaded from https://media.torproject.org/image/Onion Icon/
  • We would like Antonela to give us feedback about the UX flow and overall experience. For example, while the prompt is displayed we show a blank page behind it. Is that okay?

Using the above patches, we created some builds for testing. We used a tor daemon based on David's ticket30381_042_01 branch from https://git.torproject.org/user/dgoulet/tor.git (which includes the work-in-progress patches for both #30381 and #30382). Please look at the README.txt file that is in the same directory as the builds for a helpful tip about reducing your SocksTimeout setting. The builds are here:

https://people.torproject.org/~brade/testbuilds/clientauth-2019-06-27/

Version 0, edited 3 months ago by mcs (next)

comment:20 Changed 3 months ago by mcs

I forgot to mention that our implementation does not yet provide an option to store private keys persistently.

comment:21 Changed 3 months ago by asn

This looks really good!

comment:22 in reply to:  19 ; Changed 2 months ago by antonela

Thanks mcs and brade, it looks great! Will go inline:

  • Our tor-browser changes do not support localization (see the many places that are marked with L10n). Kathy and I would like to understand our localization strategy in a post-Torbutton world before we work on L10n support.
  • We need to insert the correct "Learn More" URL.

Yes. I can coordinate it with the community team. The link should give users more info about why they need a key and how they can find it. Filed #31069 to make it happen.

  • The text/copy will need some work. Some concepts are difficult to communicate clearly. For example, if the user enters a key of the wrong length or format, we currently show the somewhat cryptic validation error that is visible in the screenshot I posted.

I was able to reproduce two kinds of errors: "Please enter a valid key" and "Unable to configure Tor with your key". Are more errors coming?

Could we use a class to make those errors look more like an error? We can rely on the firefox suggestions -> https://design.firefox.com/photon/patterns/errors.html

I think we can use Firefox's login/key icon. Do we want a custom icon here?
https://design.firefox.com/icons/icons/desktop/login-16.svg

  • We would like Antonela to give us feedback about the UX flow and overall experience. For example, while the prompt is displayed we show a blank page behind it. Is that okay?

I think the white page is good for now, I'll think more about it. We should have a better error page when users click "Cancel". I'll make sure we have it in consideration for #30025.

Using the above patches, we created some builds for testing. We used a tor daemon based on David's ticket30381_042_01 branch from https://git.torproject.org/user/dgoulet/tor.git (which includes the work-in-progress patches for both #30381 and #30382). Please look at the README.txt file that is in the same directory as the builds for a helpful tip about reducing your SocksTimeout setting.

Thanks a lot for doing this!

comment:23 Changed 2 months ago by gk

Keywords: TorBrowserTeam201907 added; TorBrowserTeam201906 removed

Moving tickets to July

comment:24 in reply to:  22 Changed 2 months ago by gk

Replying to antonela:

I think we can use Firefox's login/key icon. Do we want a custom icon here?
https://design.firefox.com/icons/icons/desktop/login-16.svg

I'd be fine with that icon. On the other hand maybe we can make some combo of a key and a onion to make sure users understand that this the key for the .onion service.

comment:25 Changed 2 months ago by gaba

Keywords: network-team-roadmap-september added

comment:26 in reply to:  22 Changed 4 weeks ago by mcs

Replying to antonela:

I was able to reproduce two kinds of errors: "Please enter a valid key" and "Unable to configure Tor with your key". Are more errors coming?

Just those two for now. Later we can add a specific error message to cover the case where the key provided by the user does not work (NS_ERROR_TOR_ONION_SVC_BAD_CLIENT_AUTH). In English, that message might be something like "The private key you provided for thing.onion is not valid. Please enter a new key".

Could we use a class to make those errors look more like an error? We can rely on the firefox suggestions -> https://design.firefox.com/photon/patterns/errors.html

Yes, Kathy and I will take a look after the ESR68 crunch is past us.

Note: See TracTickets for help on using tickets.