June 2018 - 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

Why Tor Browser and not Tor + $browser
by Georg Koppen 27 Jun '18

27 Jun '18

Hi! One thing I wanted to bring up yesterday in the meeting was asking around whether anybody from the team would like to help Stephanie with drafting a blog post about why we don't recommend Tor with any other browser, explaining the benefits Tor Browser has compared to setups like using Tor + Chrome. Is someone interested in helping out? If so, that would be awesome. Georg

5 4

Re: [tbb-dev] Favicons are nasty!
by The Dude 27 Jun '18

27 Jun '18

IMO this "feature" should be disabled! via: about:config browser.chrome. browser.chrome.favicons;false browser.chrome.site_icons;false browser.chrome.image_icons.max_size;0 I never liked this feature anyway. In addition to finding questionable privacy/security issues in the past, if it's enabled and you bookmark websites it inserts a bunch of garbage into the bookmarks for that bookmarked site and just increases the size of the bookmarks file if you keep it. I'd just configure it per above in future versions of TBB.

1 0

Moving next Tor Browser meeting to June 26, 1800 UTC
by Georg Koppen 26 Jun '18

26 Jun '18

Hi! We'll move the next Tor Browser meeting to June 26 (which is the Tuesday next week), 1800 UTC as I'll be traveling and likely unavailable during our regular meeting time. The meeting location is, as usual, #tor-meeting on the OFTC IRC network. Georg

3 4

Fwd: Favicons are now loaded in the content process
by Tom Ritter 26 Jun '18

26 Jun '18

Not in ESR60; but wanted to let you know since there have been favicon issues in the past. ---------- Forwarded message ---------- From: Dave Townsend <dtownsend(a)mozilla.com> Date: Mon, Jun 25, 2018 at 6:02 PM Subject: Favicons are now loaded in the content process To: Firefox Dev <firefox-dev(a)mozilla.org> I just landed a fairly major change to how favicons are loaded on mozilla-inbound and it looks like it might stick. Previously we relied on the places service and XUL image elements to load favicons from the main process but now we load the favicon data in the content process and then just re-use that data everywhere we need it, currently as a data URI. This should mean we now honour CSP rules for favicons, expose favicon requests properly to webextensions and a few other things. But the change is significant enough that there might be some edge cases that changed. If you notice any oddities around favicons in tabs, the new tab page or the all tabs menu please CC me on the bugs you file. _______________________________________________ firefox-dev mailing list firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/firefox-dev

1 0

Re: [tbb-dev] Tor Browser 7.5.5 seg fault
by qubenix 25 Jun '18

25 Jun '18

> qubenix: >> Hello, I've got a strange issue where I'm getting a seg fault when >> trying to launch tbb 7.5.5 with the included start-tor-browser script. >> >> Here is a "bash -x start-tor-browser" log: >> https://paste.debian.net/plainh/9170feda. >> >> I'm using Qubes/Whonix (Debian stretch) as my os, you can see the thread >> I started on the Whonix forum: >> https://forums.whonix.org/t/whonix14-qubes3-2-latest-upgrade-prevent-tor-br…. >> >> To add some complexity and strangeness to this all, launching tbb with >> the Whonix "torbrowser" script works even though it ultimately uses the >> same script which fails for me. >> >> You can see a successful "bash -x torbrowser" log here: >> https://paste.debian.net/plainh/cea3d210. >> >> I'm happy to provide any further information upon request. > > Could that be https://trac.torproject.org/projects/tor/ticket/25305 ? > > Georg > > > > _______________________________________________ > tbb-dev mailing list > tbb-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev > Thanks Georg, that seeems to be the problem. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

1 0

Tor Browser 7.5.5 seg fault
by qubenix 25 Jun '18

25 Jun '18

Hello, I've got a strange issue where I'm getting a seg fault when trying to launch tbb 7.5.5 with the included start-tor-browser script. Here is a "bash -x start-tor-browser" log: https://paste.debian.net/plainh/9170feda. I'm using Qubes/Whonix (Debian stretch) as my os, you can see the thread I started on the Whonix forum: https://forums.whonix.org/t/whonix14-qubes3-2-latest-upgrade-prevent-tor-br…. To add some complexity and strangeness to this all, launching tbb with the Whonix "torbrowser" script works even though it ultimately uses the same script which fails for me. You can see a successful "bash -x torbrowser" log here: https://paste.debian.net/plainh/cea3d210. I'm happy to provide any further information upon request. Thank you for reading. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

2 1

Future Plan for Tor Browser for Android
by Matthew Finkel 20 Jun '18

20 Jun '18

At the Mozilla All-Hands in SF we had some discussions about Mozilla's future plans on Android. Currently, Mozilla are actively supporting four Android app web browsers - Fennec[0], Focus[1], Rocket[2], and Firefox on Fire TV[3]. Focus, Rocket, and Firefox on Fire TV are all minimal browsers, and they do not have the same features as Fennec. Fennec is the codebase Orfox uses, and it is the browser we are currently planning on using for Tor Browser. However, Fennec is not being actively developed, but Mozilla are keeping Fennec alive and they do not have an EOL date. The two important parts from this are: 1) The Fennec code will not change much over the next 12+ months 2) We can safely continuing using Fennec for the 12+ months This effectively means Fennec 67 will be very close to Fennec 60ESR. Therefore, I propose we backout our current plan of following Fennec releases and we make this simple and follow ESR (exactly the same as desktop). We can track on-going changes in mozilla-central that affect Fennec, but these changes should not happen often - backporting any high priority patches shouldn't be difficult. The two additional components I should mention are GeckoView[4] and Fenix[5]. GeckoView is an Android library acting as a glue-layer between the Gecko native code and the UI/Browser app layer. Firefox Focus is currenty using Android WebView (Android's built-in renderer), but they are moving Focus onto using GeckoView in the very near future. Fennec currently uses parts of GeckoView, so if we decide we should use the ESR then we should also watch the work done on GeckoView in case there are any improvements we want. Fenix is the last piece in this puzzle. It is a new browser Mozilla will be working on, and it has a lot of promise - but currently it does not exist in a form we can use. We may want to consider using Fenix in 2-3 years. Mozilla's Android Components project is also interesting. When it is ready, we could create our own browser by picking-and-choosing the parts we want. Unfortunately, this isn't as easy as hardening an existing private browsing mode. This is the reason I think we should continue working on Fennec right now. In conclusion, I propose we develop Tor Browser for Android based on Firefox Fennec ESR. This is not an official ESR, but the changes between Fennec releases will be very small (if any changes at all). This will allow us maintain the same branches for desktop and mobile. [0] https://play.google.com/store/apps/details?id=org.mozilla.firefox [1] https://play.google.com/store/apps/details?id=org.mozilla.focus [2] https://play.google.com/store/apps/details?id=org.mozilla.rocket [3] https://www.amazon.com/Mozilla-Firefox-for-Fire-TV/dp/B078B5YMPD [4] https://wiki.mozilla.org/Mobile/GeckoView [5] https://github.com/mozilla-mobile/fenix [6] https://github.com/mozilla-mobile/android-components

4 5

Tor Browser nightly builds based on Firefox 60 ESR are available for Linux
by Georg Koppen 15 Jun '18

15 Jun '18

Hi all! We are happy to announce that we finally have Tor Browser nightly builds for Linux available that are based in Firefox 60 ESR. From today, May 30, on you find them at the usual location: http://f4amtbsowhix7rrf.onion/tor-browser-builds/ We already tagged a bunch of issues we found in the pre-nightly bundles we built locally. For those we used the "ff60-esr" keyword. If you feel brave and test those nightlies, please report unfiled bugs you encounter. This helps us prioritizing things and gets those very likely fixed faster. We'll provide macOS bundles and Windows bundles as fast as we can. We are currently still working on the toolchain update. Known major issues with the nightlies so far: 1) A couple of months ago we needed to get out an emergency Tor Browser release to fix a possibly proxy bypass bug[1], affecting above all macOS users and potentially some Linux setups as well. We currently don't have a patch for that one as the underlying code changed too much between ESR52 and ESR60. However, Mozilla is working on that for us and we'll port the final fix back as soon as possible. 2) Loacalized bundles are not working correctly due to missing locale strings for the new circuit display. This should be fixed starting with the next nightlies as I pushed the respective changes a couple of hours ago to our Torbutton repository. 3) The nightlies have JavaScript blocked by default (some of you might even call this a feature). 4) Loading default bridges/moat is not working. Georg [1] https://blog.torproject.org/tor-browser-709-released

1 2

Fwd: Intent to unship: bootstrapped extensions
by Tom Ritter 05 Jun '18

05 Jun '18

---------- Forwarded message ---------- From: Andrew Swan <aswan(a)mozilla.com> Date: Tue, Jun 5, 2018 at 3:34 AM Subject: Intent to unship: bootstrapped extensions To: firefox-dev <firefox-dev(a)mozilla.org>, dev-addons <dev-addons(a)mozilla.org> Since various types of legacy extensions became unsupported in Firefox Quantum, we've been busy removing obsolete code and streamlining the Addons Manager which, as you might imagine, had become quite large and complex in order to support a wide variety of legacy addon formats. At this point, the largest remaining category of legacy extensions is bootstrapped extensions. We no longer support bootstrapped extensions for general use, but we do use them for things like system addons, Test Pilot experiments, Shield studies, extensions used in automation, and a few other things. Bootstrapped extensions are useful for these applications since they provide a relatively simple way to run some chrome-privileged javascript code without having to land that code and wait for it to ride the trains. But continuing to support these extensions comes at some cost (for instance, they are one of the last users of RDF in mozilla-central). An important feature of WebExtensions is that they run in a sandboxed environment much like web content without direct access to chrome-privileged browser internals. However, a feature called WebExtensions Experiments allows certain extensions to run some privileged code. Converting bootstrapped extensions to WebExtensions plus experiments has a bunch of advantages: - It means less privileged code overall which is good for stability and security - Though porting takes some work, the result should be easier to maintain and build on in the future - It frees us up to remove more old code and further streamline the addons manager So, we plan to remove support for bootstrapped extensions altogether in Firefox 65. This will entail porting existing bootstrapped extensions to WebExtensions (or converting them to something other than an extension where that is appropriate). This effort is tracked in bug 1449052. If you are responsible for a bootstrapped extension that we rely on and it is not already tracked as a dependency of that bug, please: 1. Add a comment or dependency. to bug 1449052, and 2. Aim to get the extension converted by the end of the 64 Nightly cycle (Oct 15) And needless to say, we shouldn't be creating any new bootstrapped extensions at this point. A lot of things are going to need to come together to hit his schedule but we are eager to get this wrapped up and move on. If you are responsible for an extension and have questions about how to handle it, feel free to either contact me directly or drop into #webextensions on IRC. If you want to learn more about WebExtensions Experiments, there is a brief overview at [1] and a lot of gory implementation details at [2]. [1] https://webextensions-experiments.readthedocs.io/en/latest/ [2] https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webex… _______________________________________________ Dev-addons mailing list Dev-addons(a)mozilla.org https://mail.mozilla.org/listinfo/dev-addons

1 0