April 2021 - tbb-dev - lists.torproject.org

Release schedule update
by intrigeri 19 May '21

19 May '21

Hi, Mozilla has updated their release schedule [1] recently, and the Tor Browser release schedule [2] does not match anymore. Can I safely assume that the Tor Browser release schedule will be updated to match Mozilla's? [1] https://wiki.mozilla.org/Release_Management/Calendar [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Release_… Cheers!

2 4

Tor Browser arm builds
by Roger Dingledine 10 Apr '21

10 Apr '21

Hi folks! A user on irc pointed us to https://github.com/Botspot/pi-apps which has an unofficial Tor Browser arm build -- unofficial because, among other reasons, there *are* no official Tor Browser arm builds at this point. It apparently pulls from https://sourceforge.net/projects/tor-browser-ports/ which...just has binaries, meaning it's hard to tell what exactly got built? They seem to be made by this person: https://sourceforge.net/u/holind/profile/ https://launchpad.net/~holindho So, I know nothing more, but I wanted to pass the info on to the Tor Browser team, in case they can find a way to make good use of it, e.g. by bringing the person into the Tor ecosystem. After all, it is not easy to build a Tor Browser for arm, and if they have done it well that would be great. :) --Roger

1 0

Tor Browser Friendliness Scanner: Seeking Feedback
by Kevun 09 Apr '21

09 Apr '21

Hello all! After a year away from my Tor related research, I'm finally back at it. As I've introduced in the past [1] I wanted to build a Tor Browser Friendliness scanner that would scan the web and rate the Tor Browser friendliness of web pages. Unfortunately time got away from me for personal reasons, but I finally got the chance to work on the scanner and I feel it's close to being ready to run. To re-introduce the concept: the scanner checks a web page for evidence of some activity that would likely cause the site to not render or run properly on the Tor Browser. This includes the tests listed below, which are motivated by the Tor Browser Design Document [2] and our own experiences analyzing what broke on the Tor Browser during analysis of some randomly selected websites. _*Tests*_ 1. Checks to see if the site supports HTTPS. If not, there's a problem. 2. Checks to see if the site serves JavaScript over HTTP. If not, there could be a problem on the Safer setting of the Tor Browser Security Slider, 3. Checks to see if there is auto-played media or hidden media. This could cause issues on the Safer setting of the Tor Browser Security Slider. 4. Checks to see if there is any evidence of usage of the following JavaScript libraries/functionalities. These were taken from the draft of the Tor Browser Design Document. 01. asm 02. battery status 03. game pad 04. graphite 05. media devices 06. navigator online 07. sensor 08. network connection 09. touch 10. web audio 11. webgl 12. webrtc 13. web speech 14. HTML canvas 5. Checks to see if the page contains JAR files or Flash files. 6. Checks to see if the page contains chrome:// or resource:// links. Given this information, I have a few questions. 1. What other tests should I add, if any? 2. Is there any other feedback on this idea that you'd like to provide? Please keep in mind that I intend on releasing the source code soon. At the moment it's in an "academic code" state, and I want to clean it up before release. Thanks, Kevin References: [1] https://lists.torproject.org/pipermail/tor-dev/2019-March/013731.html [2] https://2019.www.torproject.org/projects/torbrowser/design/

4 3

Thoughts about future Tor Browser plans
by Matthew Finkel 08 Apr '21

08 Apr '21

Hi everyone, (tldr; read the last paragraph) In October [0] we were very excited about the prospect of all Tor Browser platforms following the Firefox Rapid Release schedule. However, in April (now), Android is still the only platform following the rapid release train and Windows, macOS and Linux remain on the extended support release (ESR). As we move closer to the next ESR transition, this year it is beginning at Firefox 91 in May [1], I am wondering whether we should reverse course and slow down. At this point, we cannot safely transition all platforms onto the rapid release train before October (when 78esr reaches its EOL), so the only option is moving all desktop platforms onto FF91esr and then evaluate migrating onto the rapid release train after that. Unfortunately, we are still a very small team, and the current situation is already pushing our team to its limits. Yesterday I spoke with Georg about another subject, and he briefly mentioned the idea of keeping the desktop platforms on ESR instead of moving onto the rapid releases. This alone wouldn't make much difference, and I previously discarded this idea, because we're already fighting all of the code churn for Android (although some of the code, like the automatic updater, is not used on Android). The important piece of this plan is reducing Fenix's burden, too. My current thought is that we move desktop platforms from 78esr to 91esr, and we begin rebasing our Fenix branches (and dependencies) only every 2-3 months. The only exception is geckoview where we continue rebasing our geckoview branches on the existing schedule. In addition, we drop desktop patches from the geckoview branches, and Android patches from the ESR branches. We could've (and should've) done the latter simplification earlier, but the former change makes future ESR transitions a little more complicated. I think we can live with that. - Matt [0] https://lists.torproject.org/pipermail/tbb-dev/2020-October/001154.html [1] https://wiki.mozilla.org/Release_Management/Calendar

3 4