tbb-dev January 2019

tbb-dev@lists.torproject.org

7 participants
7 discussions

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

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

Fingerprinting Test Page
by Tom Ritter 30 Jan '19

30 Jan '19

There's a Mozilla contributor (https://github.com/ghacksuserjs/TorZillaPrint/commits?author=Thorin-Oakenpa…) who's been working on a unified fingerprinting test page. It is in-progress here: https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html (code: https://github.com/ghacksuserjs/TorZillaPrint) I am not sure how this compares to fpcentral, either in current incarnation or in architecture and future ease-of-evolution or ease-of-automated-integration BUT it seems to be pretty handy. I know he is interested in building it out to make it feature-complete. So if you're working on a fingerprinting bug and you need to code up a test; you might consider putting it in this framework to work towards keeping it all in one place? -tom

2 1

Tor Browser for Android Reviews on Google Play
by Matthew Finkel 28 Jan '19

28 Jan '19

Hi all, I read the reviews/comments of Tor Browser for Android on Google Play from November and December. Some of the requests were addressed/implemented in the December Tor Browser 8.5a5 release, but I'll mention them here for completeness. In November, the most frequent comment/request was about the lack of copy/paste functionality. This was tracked and fixed in #27256. The second most frequent comment referred to receiving a browser proxy error message (some mentioned "incorrect proxy setting" message). It seems possible this was due to Orbot not being installed or running. Before tor was bundled in the app, Tor Browser did warn the user if an Orbot installation wasn't detected and it tried starting Orbot if it was detected but wasn't running, but maybe this wasn't sufficient in all cases. Tor Browser now includes its own tor proxy, so those failures should be mitigated. The remaining comments were: - Requesting tor integration directly into the app (ticket #28051) - Requesting ability to take screenshots (ticket #27987) - Can't download images/pdfs/files (ticket #28705) - Tor is slow - Request for Russian localizations (ticket #26843) - Request for additional localizations (ticket #26843) - Lack of ad-blocker - Prevented from installing add-ons (primarily for installing an ad-blocker) - Request for a single button that disables all scripts - Request for supporting x86 devices (ticket #27210) - Observation Tor Browser is not a torrent client In December, including comments before and after the release where the app included its own tor client, the most frequent comment/request referred to the browser not connecting. I know there is currently a bug where Android stops the tor process but Tor Browser doesn't detect this, and the user only receives a proxy error. I'm not certain this why the users are saying the browser doesn't connect, but it's an annoying bug in any case. The second most frequent comment in December related to the app crashing after attempting a file download. There were multiple comments and questions about the Orbot integration. Some users asked if they needed Orbot installed anymore, others requested that development continue on Orbot and Tor Browser shouldn't replace Orbot. There were additional questions and concerns about Tor Browser's Orbot screen and configuring VPN mode - specifically using Tor Browser's (Orbot's) VPN mode for torifying other apps. This last issue should be resolved with the new bootstrapping UI and the enxt release should mitigate the Orbot/Tor Browser UI/UX confusion. We should be more clear about Tor Browser's dependency on the Orbot app. I'm not sure how we should communicate this, yet. There were more requests for Russian localization and Turkish localization. Users should see this automatically now if their device is configured with another language as the default. If the device is not configured with Russian/Turkish as their default language, then they can select another locale in Fennec/Tor Browser's settings menu, but maybe this isn't obvious. We can think about how we can/should make this easier. The remaining comments were: - The new update didn't work in Iran - Request for bridge support (ticket #28802) - It's not obvious when Tor isn't running - Request for x86 support (ticket #27210) - Updates aren't working, users are reinstalling the app after each update - Request for detecting and using the Orbot app if it's installed - A user noticed the app "randomly" start - A user noticed the app stop after a long period of use - Tor Browser is using the Orfox logo (ticket #27399) - Add-on installation is blocked - Request for a Javascript button (toggle on/off) - Tor is slow - Request for a circuit display - Tor Browser's Orbot doesn't start tor, progress hangs at startup without any errors - Tabs aren't restored after Android kills the app in the background - Request to make Tor Browser SDCard-compatible - Request for allowing taking of screenshots (ticket #27987) There were two comments about failure after installing the update and reinstalling the app as a result. We should investigate this. One instance was reported on a Blackberry Priv. - Matt

3 2

We move our meeting time to Monday 1830 UTC (in #tor-meeting2)
by Georg Koppen 23 Jan '19

23 Jan '19

Hi all! Due to conflicts some folks on the browser team have we are moving our meeting time. It's now half an hour earlier on Mondays: 1830 UTC. That results in a new meeting location as well as #tor-meeting will be occupied by the network team folks during that time. We'll therefore use #tor-meeting2. Thus, the next weekly meeting will be on Monday, 1/28/2019, at 1830 UTC in #tor-meeting2 at irc.oftc.net. See you there, Georg

1 0

Next Tor Browser meeting is on Tuesday, 1/22 1900 UTC
by Georg Koppen 15 Jan '19

15 Jan '19

Hi, As next Monday, 1/21, is a national holiday in the US (Martin Luther King Jr. day) we'll move the weekly Tor Browser meeting by one day. The next meeting will then be at Tue, 1/22, 1900 UTC in #tor-meeting on irc.oftc.net. See you there, Georg

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev January 2019