[tor-project] New Tor Metrics graph: Tor Browser downloads and updates

[Yawning Angel]

On Sun, 29 Jan 2017 17:30:23 +0100
Karsten Loesing <karsten at torproject.org> wrote:
> Okay, we rely on folks telling us which resource strings to look after
> and how to interpret them.  If we should be looking for different
> resource strings in the logs or change the documentation in any way,
> please tell us!

Downloading (sandboxed-tor-browser application):

  https://dist.torproject.org/torbrowser/7.0a1/sandbox-0.0.3-linux64.zip
  https://dist.torproject.org/torbrowser/7.0a1/sandbox-0.0.3-linux64.zip.asc

sandboxed-tor-browser works similarly to tor-browser-launcher in
certain regards, and handles downloading/installing an actual bundle.
For the purposes of illustration, the `release` channel will be shown,
and I will assume that substituting in the right thing is trivial.

  Installing tor browser (done only once):

    http://x3nelbld33llasqv.onion/torbrowser/update_2/release/downloads.json
    OR    
    https://aus1.torproject.org/torbrowser/update_2/release/downloads.json

    https://dist.torproject.org/torbrowser/6.5/tor-browser-linux64-6.5_en-US.tar.xz
    https://dist.torproject.org/torbrowser/6.5/tor-browser-linux64-6.5_en-US.tar.xz.asc

    The HS is only used here if a system tor instance is
    explicitly pre-configured.

    (This probably shouldn't be hitting up dist.tp.o, but the JSON file
     is generated by the automated build process, and is beyond my
     control.)

sandboxed-tor-browser also handles checking for updates, and keeping
the installed browser up to date, because the sandboxed firefox instance
doesn't have sufficient file system privileges to be able to rewrite
itself (This is a good thing).

  Update check (every 2h):

    http://x3nelbld33llasqv.onion/torbrowser/update_2/release/Linux_x86_64-gcc3/6.5/en-US

    If the fetch from the HS fails, it will immediately attempt to
    fetch:

      https://aus1.torproject.org/torbrowser/update_2/release/Linux_x86_64-gcc3/6.5/en-US

    Any further failures are retried after another 2 hours has elapsed.

    All other internal update checks present in Tor Browser are
    disabled, so it will never fetch:

      https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions

    If there is an update, it will grab the MAR as specified in the XML
    response just fetched.

    This will probably be the main source of inconsistency.  Personally
    I don't see why `RecommendedTBBVersions` still exists at all.

    nb: If the user closes sandboxed-tor-browser completely, on next
    launch an update check cycle is forced before firefox is allowed to
    execute if it has been over 2 hours since the last update check,
    after the bootstrap process completes. Complete failure then
    results in a failure to launch with a modal dialog box (Yes, I know
    some people will consider this a misfeature.  No, I don't care).

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20170130/ed625084/attachment.sig>