Activity 3.1: Improve the user experience of updating Tor Browser

added component::applications/tor browser owner::antonela priority::medium resolution::fixed severity::normal sponsor::17 status::closed tbb-update type::defect ux-team labels

Trac:
Description: First thing here is to review

All these tickets were selected back in the day when we were creating sponsor17 proposal.

So we should read what is going on at these tickets to define the problems we will try to fix.

Once we have the problems defined is when we will start drafting solutions.

to

First thing here is to review usability tickets for the updater:

All these tickets were selected back in the day when we were creating sponsor17 proposal.

So we should read what is going on at these tickets to define the problems we will try to fix.

Once we have the problems defined is when we will start drafting solutions.

Ccing the tbb-team.

Trac:
Cc: N/A to tbb-team

Trac:
Cc: tbb-team to tbb-team, dmr

Additional tickets related to this task: #23721 (moved) (website banner) #25580 (moved) (Torbutton should trigger update)

Kathy and I have been testing the revised updater UX that we get "for free" with our upcoming update to an ESR60-based Tor Browser. The main change compared to the older UX is that doorhangers are used to inform users about update-related things instead of a Big Ugly Window. Hopefully an expansion of what was done for Firefox will meet our needs. There are hidden preferences we can adjust so that Tor Browser users are nagged as soon as an update is available (Firefox delays some hours or days before nagging).

Another thing to keep in mind is an architectural issue that we should resolve — Tor Browser currently uses two separate methods to determine if the browser needs to be updated:

The traditional Firefox-based update service mechanism, which pulls down XML data from https://aus1.torproject.org/torbrowser/update_3/.... These checks occur twice per day and trigger an automatic download and staging of the update.
Retrieving https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions. This is used by Torbutton to display the update needed warning and associated arrow on the about:tor page. This kind of check occurs when a new window or tab is opened (including once during browser startup). Kathy and would like to eliminate the second method and simply reply on the update service checks, unless we need redundancy to make it less likely that a bad actor can mount a successful "denial of update" attack. If we keep both mechanisms, we should integrate them in a smart way.

Trac:

Hi all,

Here is a first approach for Update Tor Browser UX, based on tickets #13309 (moved), #17594 (moved), #18179 (moved), #18193 (moved), #18948 (moved), #25151 (moved), #25580 (moved), #25702 (moved), #19270 (moved), #20083 (moved), and #23721 (moved).

Please, take a look at the user flow I mapped and let me know if I'm missing anything.

https://trac.torproject.org/projects/tor/attachment/ticket/25694/25694.png

We have two main user tasks: Update Tor Browser and Check for Updates.

I'm describing each of them here:

Existing Update

If there is an updated package to download, could we check it once the Tor Browser starts?

If the package exists, could we download it automatically and inform users? See the image 1.1

If the package exists, but the user has opted out for non-automatic updates, could we ask if they want to Download and Restart to apply changes? See 1.2. Do you think we need a Settings secondary button? I'd like to find some way to encourage these users to enable automatic updates.

Once the updated browser restart we can show feedback to users by changing the about:tor message. See 1.3

Checking for Updates

Right now users need to go to Tor Button → Check for Tor Browser Updates to check if a new version is available.

We could make this pattern consistent by don't open this updater windows. Instead, we may open the About Tor Browser popup which includes a Updates checking. See 1.4

I would like to have a review on:

User Flow: am I missing something?
Top Banner: I think it is taking enough attention to explain what is happening, what do you think?
About:Tor Warning: The red background, is it too much?

Notes from tickets https://share.riseup.net/#HIWU1lsguq7-avQ-4jDB7g

Copy All the copy status is up to review.

1.0 - Main Title: Your browser is outdated Description: Get the most recent version to keep browsing securely. Call To Action: Update Now

1.1 - Banner Title: We found a new Tor Browser stable version. Downloading now… Call To Action: Restart Now Secondary: Settings -> about:preferences/updates

1.2 - Banner Title: We found a new Tor Browser stable version. Please, download it now. Call To Action: Download and Restart

1.3 - Main Title: Your Browser was updated Description: Now you are connected to Tor. Browse the internet anonymously and securely.

Replying to mcs:

Thanks a lot for all the tech background added here and in #25580 (moved) too. It is pretty useful for our work.

Trac:

mockup based on the Firefox 60 UI

Overall, the flow looks good. We will need to add some error cases, e.g., if the update fails to apply, Firefox prompts the user to download a new installer (which seems like a good idea).

However, Kathy and I are interested in reusing as much of the new Firefox updater UI as we can. Did you consider that approach? Advantages:

We can avoid some "line of death" problems (see https://textslashplain.com/2017/01/14/the-line-of-death/).
We reduce our dependency on about:tor (which some users do not use as their home page).
We will reduce our implementation effort and patch maintenance effort.
We will have the opportunity to help Mozilla improve their update UX.

I attached a mockup (FF60 Updater.png) that shows what that might look like (using Firefox screenshots).

Thanks, Katty and Mark! Firefox approach seems just good for what we need to solve.

One thing we could discuss is the little noticeable icon we have as an "update remainder." We might make it more noticeable. As you mentioned in #26049 (moved) reducing a delay to prompt a message is a good idea. I would like to explore a new icon or some red flag to make it more visible.

Another thing I would like to explore is if we can show in some way a successful update. About:tor seems to be the first place to do it at first glance. But you mentioned that a lot of people doesn't have about:tor as a homepage. Should we do more research about it? How % of users have a custom home page? And how might the prompt works once the user restart?

That said, I'm in favor to keep this looking same as FF60 as much as we can. For sure, there is a lot of benefits to approaching this kind of tasks in this way for us.

Replying to antonela:

Another thing I would like to explore is if we can show in some way a successful update. About:tor seems to be the first place to do it at first glance. But you mentioned that a lot of people doesn't have about:tor as a homepage. Should we do more research about it? How % of users have a custom home page? And how might the prompt works once the user restart? The basic assumption is that most users don't touch the default settings, I'd bet at worse that only a tiny percentage have a custom homepage.

Trac: