February 2019 - tbb-dev - lists.torproject.org

Nightly rebase experiment proposal
by Arthur D. Edelstein 03 Feb '20

03 Feb '20

Hi everyone, Here's a plan for experimenting with moving Tor Browser from ESRs to mozilla-central. Why try this? There are several reasons I can think of: * There is no mobile Firefox ESR. In order to keep mobile Tor Browser secure, we would either need to constantly monitor for security fixes and apply backports. It will be simpler to follow the Mozilla release cycle. * Tor Browser will receive all security patches and security features from Mozilla, not simply those deemed important enough to backport to the last ESR. * Closer collaboration between Mozilla and the Tor Browser team will be possible, because everyone will be focused on the same codebase. For example, non-urgent patches can land directly on mozilla-central, bypassing tor-browser.git altogether, and those patches will be deployed to Tor Browser faster than they would have been on an ESR-only schedule. Mozilla will provide expert review of patches. Also, some non-urgent patches by Tor Browser may be written by Mozilla engineers. * The Tor Browser development process will be smoother and more gradual. Instead of rebasing and patch-fixing sprints ahead of each ESR, we can automatically rebase patches every night, and fix any patch whenever its rebase fails. (The total rebase effort should be approximately the same as before.) * Patches that frequently break because they live on "hot code" can be identified and uplifted. * We'll need to continuously monitor the mozilla codebase for new features that could harm privacy. That's potentially difficult, but by focusing on Mozilla's current work, we can hopefully stop patches that affect privacy before they land. Here's how I envision the new rebase process: * An automated script rebases all tor browser patches every night against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr. An email alert will be sent if the rebase of any patch fails. (I have a prototype script that does the basic rebasing -- it found that ~40/140 patches from our ESR-52 branch could be auto-rebased onto mozilla-central without any intervention.) * Any failed patches will need to be manually fixed up promptly so that the automated rebase can resume. * Diagnostic Tor Browser bundles will be built against the latest rebase branches. We can also run regression tests. So how do we ramp up this experiment? 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on top of Firefox 59-beta. (We have to do this anyway.) 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser patches nightly onto mozilla-(central, beta, stable, esr). 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds based on nightly rebases. At this point, we can evaluate whether we would like to transition to releasing Tor Browser alphas based on the mozilla-beta branch. Switching Tor Browser stable to mozilla-stable can happen sometime after that. How does this sound? Interested to hear what you think. Thanks, Arthur

7 12

proposal for #28044 (Integrate Tor Launcher into tor-browser)
by Mark Smith 19 May '19

19 May '19

A draft proposal for #28044 (Integrate Tor Launcher into tor-browser) is attached. Your feedback is welcome and appreciated! -- Mark Smith Pearl Crescent http://pearlcrescent.com/

4 8

Off-topic: Dev Meeting July 2019 - Who should the Browser Team invite?
by Pili Guerra 27 Feb '19

27 Feb '19

Hi everyone, Apologies for the slightly off-topic post. We’re brainstorming who we want to join us at the Dev meeting to be held in Stockholm from the 11th - 15th July 2019 and we’d like your help. Can you please send me your suggestions by the end of next week (Friday 8th March)? Please reply to me directly instead of replying to the list :) Thanks! Pili — Project Manager: Tor Browser, UX and Community teams pili at torproject dot org gpg 3E7F A89E 2459 B6CC A62F 56B8 C6CB 772E F096 9C45

1 0

Next weekly Tor Browser meeting on 2/25 1830 UTC in #tor-meeting2
by Georg Koppen 15 Feb '19

15 Feb '19

Hi all! We'll skip the weekly Tor Browser meeting next week and will meet again on February 25 at 1830 UTC in #tor-meeting2 on the OFTC IRC network. See you there, Georg

2 1

Media Codecs and the canPlayType/Media Capabilities API
by Tom Ritter 08 Feb '19

08 Feb '19

This is an old concern I'm trying to revive to figure out a path forward on. I'm going to do my best to summarize this issue. The issue at hand is that codec support is not uniform across all users. The 'why' for this is that ffmpeg is not installed on all Linux machines; and that certain versions of Windows (N and KN versions in Europe) don't have the Windows Media Pack. I don't know for certain of any other situations where unusual codecs might be present and usable that allow fingerprinting or situations where common codecs would be missing or disabled (excepting, of course, about:config changes.) But it seems likely? If a user has installed a weird and unusual codec, the browser might still be able to play the video because the codec's on the system? Or perhaps a user is on an old Linux that has an old ffmpeg that doesn't support a newer codec? I don't think we have data about how common/uncommon it is that Linux users don't have ffmpeg or Windows users are missing WMF; although an approximate answer was '90% or more people have it.' Firefox detects when a user tries to play a video with a codec and it doesn't work; MediaWMFNeeded is the most relevant; it redirects people to a page that tells them to install WMF: https://support.mozilla.org/en-US/kb/fix-video-audio-problems-firefox-windo… https://searchfox.org/mozilla-central/source/dom/locales/en-US/chrome/dom/d… https://searchfox.org/mozilla-central/rev/bee8cf15c901b9f4b0c074c9977da4bbe… So the codec is the issue; but how it gets exposed through the platform is three ways: - canPlayType - and 'old' API that asks if a <video> element can play a particular codec - The Media Capabilities API - the new style API - Just trying to play videos with different codecs and seeing if it works In addition to exposing codec information; it also exposes things like whether certain codecs are hardware accelerated or if a machine can handle high resolution video or not. My understanding is that the third one is essentially impossible to prevent; absent requiring the user to manually click play for each video. As far as a path forward; there are a few ideas: - Maybe we can allowlist codecs so only certain codecs are usable? - In the short term; we can modify canPlayType and Media Capabilities to accurately report (effectively) whether or not the user has WMF/ffmpeg or not but lie about hardware acceleration and all other aspects. (We have a patch for this written.) - Alternately; we could lie and say no one has it installed (this would be a bad experience for most users) or everyone has it installed (bad for a small percentage of users) - Tor Browser could detect whether or not you have ffmpeg / WMF and inform you in some capacity that installing this software will make you less identifiable - Tor can probably bundle ffmpeg in some capacity; but it can't bundle WMF due to licensing. All of these have some drawbacks; and we probably want to use data to make an informed decision. I don't think we know what codecs we care about; or are installed by ffmpeg/WMF. I (personally) don't know if Firefox will pass non-standard codec requests out to the system to see "Hey do you happen to have a codec for 'randomweirdthing'" I don't think we know what the install rate for ffmpeg/WMF is. We have some data about codec use; however I don't fully understand it: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date… There is a bug on file here https://bugzilla.mozilla.org/show_bug.cgi?id=1461454 ; however most discussion over the months has taken place in an email thread. -tom

5 7