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
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/
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
