- tbb-dev - lists.torproject.org

Recovering from Broken Tor Browser Nightly
by Matthew Finkel 13 May '21

13 May '21

Hello everyone, Today you may discover that Tor Browser Nightly does not bootstrap tor and only shows the red error page. This is due to on-going work improving the initial bootstrapping experience [0]. Unfortunately, only part of the changes were merged yesterday, and that resulted in the current broken state [1]. As described in [1], the workaround is setting the `TOR_USE_LEGACY_LAUNCHER` environment variable as `1`: `export TOR_USE_LEGACY_LAUNCHER=1` or `TOR_USE_LEGACY_LAUNCHER=1 ./tor-browser_$l/Browser/start-tor-browser` Sorry for the inconvenience. This issue should be resolved tomorrow. [0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27476 [1] https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/40009

1 0

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

Tor Browser Weekly Meeting (new time, today's meeting cancelled)
by Matthew Finkel 29 Mar '21

29 Mar '21

Hello! At the meeting last week we discussed how (or if) our meeting time should change as a result of the (northern hemisphere's) summer-time transition. We decided that beginning next week, Monday, 5 April, we'll begin meeting at 15:00 UTC. The meeting today, 29 March, is cancelled due to the conflict with the Hackweek kickoff meeting [0]. [0] https://lists.torproject.org/pipermail/tor-project/2021-March/003070.html

1 0

Changes in Tor Browser's build system
by Georg Koppen 25 Feb '21

25 Feb '21

Hello! I am happy to inform you that I just landed changes[1] that make our Tor Browser builds not require sudo privileges anymore. Thanks for the hard work done by boklm to make that happen. For everyone building Tor Browser with our reproducible builds system that means they'll not only need to create new containers (that should happen automatically) but will likely need to enable user namespaces support as well on their build machine. This should already be properly documented in our updated README file[2]. If there are things missing or broken don't hesitate to ask and/or file a bug. Thanks, Georg [1] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/2… [2] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/mas…

3 2

Weekly Meeting (18 January)
by Matthew Finkel 18 Jan '21

18 Jan '21

Hi everyone, We're moving today's weekly meeting to tomorrow - same time and place as usual: 1900 UTC in #tor-meeting. See some of you there tomorrow.

1 0

About Tor Source Code
by adhith adhi007 12 Jan '21

12 Jan '21

Hi, we are a team but newbies, and we have an idea using tor features so we are wondering about source code. actually for android.like any tutorials or videos or wiki pages anything. what we want is our customers need to be using tor and maximum tor anonymity and proceed to our app (like in tor browser android not to all apps). Is there any way we can achieve this in an android app. We know android app development using android studio and Xamarin or do we need to learn any other language? help us.

2 2

Chrome's Proposed Privacy Budget?
by Sanketh Menda 05 Jan '21

05 Jan '21

Hello, #ChromeDevSummit this month hosted a talk on the privacy budget (https://youtu.be/0STgfjSA6T8) and in the talk they mentioned that they are currently running a large-scale study to identify which potentially identifying APIs sites are using and how much they are using them. This data might be really useful for us to improve the fingerprinting protections in the Tor Browser so we might want to keep an eye on the developments here. Also, I think I am finally beginning to see the brilliance in the privacy budget proposal (https://github.com/bslassey/privacy-budget) To the best of my knowledge, current mainstream browsers use some combination of hardcoded lists of companies (like the disconnect list used by Firefox's Enhanced Tracking Protection), hardcoded lists of scripts (like uBlock Origin), and heuristics (from the relatively simple Privacy Badger to the more complicated Intelligent Tracking Prevention in Safari). These approaches are oddly reminiscent of old-school signature-based AV and they don't really attack the core problem but try to identify bad scripts. For starters, as AV experience has taught us, these approaches might work for mass attacks but don't work well against targeted attacks. So these approaches, while they allow for mainstream browser-level usability, don't seem compatible with the threat model of the Tor Browser. This is where IMO the privacy budget shines. It goes straight to the problem: APIs that reveal potentially identifying information and keeps a ledger of the calls. This is more conservative than the above approaches and seems closer to the Tor Browser's current approach (which is to block or spoof the outputs of potentially identifying APIs). Of course, this comes with the same false positive issue that currently affects the Tor Browser, but hey we can't have everything. Moreover, this seems to lend itself nicely to a good affordance where the browser can easily expose to the user how much data they are leaking to the webpage and if the webpage exceeds the set budget and requests more API calls, how much more data they would expose by allowing these calls. Right now, the Tor Browser's fingerprinting protection is all-or-nothing and it might soon become per-origin all-or-nothing (see Mozilla Bug 1450398), privacy budget might be a nice next step where a user can allow access to some fingerprinting surface without potentially being completely identifiable. What do you folks think? Best, Sanketh

2 2

Search Usability Regression in v10
by Peter Story 09 Dec '20

09 Dec '20

I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention. > I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication: > > Open a new window > Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. > Click on a link in the search results > Click the back button > Actual behavior: you are returned to a blank search page > Expected behavior: you are returned to your search results > > I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser. > > I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected. Sincerely, -Peter Story PhD Student

2 5