Check updates in the background.
Instead of the current logic which is "Check for updates once at launch, if it has been either over 6 hours since the last successful check OR the time of last check is in the future.", the update check/update download should happen every six hours in the background, and the user should be prompted to restart.
Full integration into the Tor Browser UI is likely a lot of work, so this is probably best accomplished by the agent popping up a dialog box when the update is complete (or using GNotification ~~and a system tray icon/menu~~~).
Edit: Due to time constraints this ticket primarily concerns background update checks.
Activity
If I do this, I can probably have Tor Browser (well torbutton)'s onion menu "Check for Tor Browser Update..." actually do something as well, by having it poke the sandbox agent to schedule an update check instead of what it usually does (eg: If an env var is set, send "FETCHUPDATE\r\n" over the control port, which is the
sandboxed-tor-browsersurrogate).Trac:
Description: Instead of the current logic which is "Check for updates once at launch, if it has been either over 6 hours since the last successful check OR the time of last check is in the future.", the update check/update download should happen every six hours in the background, and the user should be prompted to restart.Full integration into the Tor Browser UI is likely a lot of work, so this is probably best accomplished by the agent popping up a dialog box when the update is complete (or using GNotification and a system tray icon/menu).
to
Instead of the current logic which is "Check for updates once at launch, if it has been either over 6 hours since the last successful check OR the time of last check is in the future.", the update check/update download should happen every six hours in the background, and the user should be prompted to restart.
Full integration into the Tor Browser UI is likely a lot of work, so this is probably best accomplished by the agent popping up a dialog box when the update is complete (or using GNotification ~~and a system tray icon/menu~~~).
https://git.schwanenlied.me/yawning/sandboxed-tor-browser/src/bug20778
Is the work in progress branch with a working background update check and #20851 (closed) fixed. It is not merged because it is lacking any sort of UI at all, except for "it dumps information to the log", and also does not handle downloading the MAR in the background yet.
If I can't figure out a good UI for all this, I might just opt for "display a dialog box if the browser is out of date" instead of "download the MAR in the background/integrate into the onion menu".
https://bugzilla.mozilla.org/show_bug.cgi?id=336193
I don't have a good self contained way of making firefox exit gracefully. Maybe if I wait for another 10 fucking years, firefox will do a graceful shutdown on either SIGTERM or SIGINT.
My branch will display a modal dialog box asking the user to restart, because without modifying torbutton that's the best I can do.
Replying to arma:
I think Tor Browser does its checks every 12 hours? It would be nice to match their schedule, since I think the metrics folks have been planning to estimate extant Tor Browser users by counting update checks and dividing by n.
The code leads me to believe that it is every 2h.
const kMinSecsBetweenChecks = 120 * 60; // 2.0 hoursThe metrics thing is broken regardless because the way I check for updates (via the XML files that the update download process uses) is different from the way torbutton checks for updates (via the JSON file in the pref
extensions.torbutton.versioncheck_urlwhich currently points to https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions).I would rather not add extra code to check for updates a different way, when the current method works, and is required for the update process to work.
Ok, so my plan as far as Tor Browser UI integration of the sandboxed update goes is:
- Introduce a new env var
TOR_SANDBOXthat my implementation will set tolinux-v0. - Modify the
sandboxed-tor-browsercontrol port surrogate to add:-
_TBB_CHECKUPDATE, a command which will trigger (or display if already in progress) thesandboxed-tor-browserupdate check. -
_TBB_UPDATE, an event that will fire if there is a browser update pending.
-
- Modify torbutton to (all actions assuming the new env var is set appropriately):
- Send the
_TBB_CHECKUPDATEcommand fromtorbutton_check_for_update()instead of calling into the prompter. - Register for the
_TBB_UPDATEevent, and setextensions.torbutton.updateNeededtotrueif it fires.
- Send the
I believe this mostly preserves the existing UX. I'm not sure what the right thing to do when the browser doesn't support integration would be, though I doubt my current strategy of "pop up a modal dialog box every 5 mins asking if the user wants to udpate" is the correct behavior.
nb: Since the new command and event are entirely synthetic and never hit the actual tor daemon, I'm not going to bother with a
control-spec.txtpatch (and since the surrogate doesn't allowevents/namesas aGETINFOquery, the right way to check if this behavior should happen is "is the env var set to what I said I will set it to".- Introduce a new env var
Under this model update checks will:
- Still be done solely by querying the XML thingies, instead of
versioncheck_url(I could fetch that and discard the results on a timer, but that seems wasteful and stupid). - Occur:
- At launch if the browser is known to be out of date (ie: The user exited instead of restarting to apply the update, after a check indicated that updates are available).
- At launch if it has been > 2 hours past the last check.
- Every 2 hours past the launch in the background.
- If requested by the user via the torbutton menu item.
This is fairly close (barring the check URL being different), to existing behavior, except:
- I use a timer, torbutton triggers off "new tab" and "new window".
- I'll always wait 2 hours before hitting up the update server after launching firefox, torbutton can end up checking earlier (I could do the time math, if it's utterly important).
Assuming no one convinces me otherwise my plan moving forward is roughly:
- Do the
sandboxed-tor-browsernon-UI modifications required to support basic integration. - Write the torbutton changes.
- (Maybe) Add support for downloading the MAR in the background (I might punt on this till a future version due to time/funding constraints).
- Do the
sandboxed-tor-browserUI modifications, basically adding a dialog box to the background update checker. - Change the behavior for old bundles that lack update integration to something other than "annoy the user with a modal dialog box every 5 mins".
- Still be done solely by querying the XML thingies, instead of
The contingency plan here would be something along the lines of:
- Figure out a good way to signify to the user that an update is ready, and prompt them for a restart that super annoying/obnoxious.
- Set the env var when launching
sandboxed-tor-browser. - Write a tiny/trivial torbutton patch that just hides the
Check for Tor Browser Update...menu entry if the env var is set.
And, at a later date, when time/funding is available, revisit my grand integration plans, and bump the env var value to
linux-v1.Regardless suggestions on what to do when Tor Browser -> sandbox integration does not exist would be appreciated.
Instead of displaying an ugly dialog box, I wrote code to opportunistically use
libnotifyto inform the user that an update is available. This integrates better into most desktop environments, and is what other applications do.libnotifywas chosen because I'd rather deal with cgo than refactor the launcher around glib'sGApplication(or the Gtk counterpart). The cost is another build time dependency, and a runtime optional dependency (the binding I wrote usesdlopen()/dlsym()), but the library is on my Debian/Fedora VMs so I suspect it's fairly ubiquitous, and the code will fall back to the ugly dialog box if required.TODO: Notifications can have actions, so add an action to restart.
Replying to yawning:
https://bugzilla.mozilla.org/show_bug.cgi?id=336193
I don't have a good self contained way of making firefox exit gracefully. Maybe if I wait for another 10 fucking years, firefox will do a graceful shutdown on either SIGTERM or SIGINT.
Ugh. I just managed to trigger this, unrelated to updates. I think I need to (in general) ask Tor Browser nicely to shoot itself in the head when tearing down the sandbox, so instead of the
_TBB_UPDATEevent, the code shall:- Register for the
_TBB_SANDBOXevent, and depending on the yet to be specified arguments, either set the pref or gracefully exit.
- Register for the
I assume "Safe Mode" in the context of Tor Browser is basically totally broken (along with "Reset Firefox"), I just disabled the automatic prompt by setting a pref so that hopefully, it doesn't get into a totally messed up state when it gets killed.
This will hopefully make it ok to kill the firefox process with extreme prejudice and will stop the rare safemode prompts I see when testing.
I spent some time trying to move from libnotify to glib's
GApplication/GNotification, but it's a no go. The fundamental problem isg_notification_set_icon()doesn't appear to support usingGBytesIcon, at least in a way that is compatible with the notification daemon I'm primarily testing with (the GNOME Flashbacknotification-daemon).libnotify works fine, and is near ubiquitous, so this is more a minor rant for posterity than an actual problem.
I'm going to go with the contingency plan here, so I can work on other also useful things.. I'll file separate tickets for the background update download and full UI integration.
Trac:
Description: Instead of the current logic which is "Check for updates once at launch, if it has been either over 6 hours since the last successful check OR the time of last check is in the future.", the update check/update download should happen every six hours in the background, and the user should be prompted to restart.Full integration into the Tor Browser UI is likely a lot of work, so this is probably best accomplished by the agent popping up a dialog box when the update is complete (or using GNotification ~~and a system tray icon/menu~~~).
to
Instead of the current logic which is "Check for updates once at launch, if it has been either over 6 hours since the last successful check OR the time of last check is in the future.", the update check/update download should happen every six hours in the background, and the user should be prompted to restart.
Full integration into the Tor Browser UI is likely a lot of work, so this is probably best accomplished by the agent popping up a dialog box when the update is complete (or using GNotification ~~and a system tray icon/menu~~~).
Edit: Due to time constraints this ticket primarily concerns background update checks.
Summary: Check and download updates in the background. to Check updates in the background.Filed #21089 (closed) and #21090 (closed) for the follow up issues.
Merged.
Trac:
Status: accepted to closed
Resolution: N/A to fixedmentioned in issue #20791 (closed)
mentioned in issue #20851 (closed)
mentioned in issue #21089 (closed)
mentioned in issue #21090 (closed)
mentioned in issue #21092 (moved)
mentioned in issue tpo/applications/tor-browser#21092 (closed)
