[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser
#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--------------------------------------+---------------------------
Reporter: isabela | Owner: antonela
Type: defect | Status: assigned
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: ux-team | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor: Sponsor17
--------------------------------------+---------------------------
Comment (by mcs):
Additional tickets related to this task:
#23721 (website banner)
#25580 (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:
1. 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.
2. 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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25694#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs