- tbb-dev - lists.torproject.org

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

Next meeting: Tue, May 29 1800 UTC in #tor-meeting
by Georg Koppen 22 May '18

22 May '18

Hi all! Next Monday is public holiday in the US (Memorial Day) and we decided to move the weekly Tor Browser meeting by one day to Tuesday, May 29. The time (1800 UTC) and the place (#tor-meeting on irc.oftc.net) stay the same. See you there, Georg

1 0

During April -> Wednesday's syncs with UX team 1800utc
by isabela 25 Apr '18

25 Apr '18

Hello tb team! as mentioned on today's sync the ux team would like to have weekly syncs with you on Wednesdays during the month of April. The syncs will be at 1800UTC at #tor-meeting channel. For this first one we would like to discuss tickets: Activity 4.1: Improve how circuits are displayed to the user https://trac.torproject.org/projects/tor/ticket/24309 Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security feature https://trac.torproject.org/projects/tor/ticket/25658 As we discussed in Rome, we will also be building the design for mobile as we work on these desktop items. These syncs will be to have quick review/feedback cycles every week so we can move on with the work and be ready for when its time to implement it. See you tomorrow! cheers, isabela

2 4

Migrating Orbot to Kotlin?
by Shane Isbell 22 Apr '18

22 Apr '18

Hi, I was wondering if there was any community interest in migrating the Orbot project (or portions of it) to the Kotlin language? This is more of a personal itch since I’m migrating some of my own open-source projects to Scala/Kotlin to reduce code complexity. I will be using Tor for the endpoint connections so will be migrating/writing some of the Tor management libraries. As a prototype, I migrated orbotservice module to Kotlin. I managed to reduce a fair amount of code and to break apart some of the pure data operations from state changes. Below is the code, if anyone is interested in seeing how it looks https://github.com/sisbell/orbot/tree/kotlin/orbotservice If there’s interest, I’ll write up unit tests and verify functionality before doing a merge request to the Orbot project. I would like to eventually explore making the code functional and introducing actors as event handlers. If there is not much community interest, I’ll just maintain a fork and see how it evolves. Best Regards, Shane

2 3

significant ESR60 updater changes
by Mark Smith 12 Apr '18

12 Apr '18

Recently, Kathy and I spent some time looking at the changes that have been made to the Firefox updater since ESR52. The purpose of this message is to highlight a few of the most important changes. It would be helpful for other people on the team to review and comment on our assumptions. 1. "Simplify the application update UI" https://bugzilla.mozilla.org/show_bug.cgi?id=893505 The user experience has been streamlined. The big ugly update dialog has been removed and doorhangers are instead used to prompt people to update. We will want to adjust some prefs that control how soon users are nagged to update (to reduce the time, as we did with the older update UI) but Kathy and I think the new experience should be okay for Tor Browser users. There is a work item for later this year to work with our UX team to improve the update experience, but first we will need to get the ESR60-based one working. 2. "LZMA support for updater" https://bugzilla.mozilla.org/show_bug.cgi?id=641212 Within the MAR files, each file or patch is compressed. Prior to Firefox 60, BZip2 compression was used. By switching to LZMA, file size is reduced by 10-20% in most cases. Some size comparisons that were done for Firefox are available here: https://bugzilla.mozilla.org/show_bug.cgi?id=641212#c250 Kathy and I think we want this change for Tor Browser, but it will mean that we must execute a "watershed" (two-step) update process wherein older browsers must first update to a Tor Browser based on ESR60 before they can update to a newer version. In other words, we will need to provide old-format MAR files to old browsers so they can be updated to a browser that understands the new LZMA-based format. We have never done a watershed update for Tor Browser, so it will be exciting to try. 3. "Support stronger hash algorithms than SHA1 for signing certificates" https://bugzilla.mozilla.org/show_bug.cgi?id=1105689 Mozilla switched from SHA1 hashes for MAR files to SHA384. We have been using SHA512 for Tor Browser from the beginning (via patches to the Mozilla code). The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks. I am not a crypto person, but it seems to Kathy and me that switching to SHA384 is a win because we can eliminate some of our patches. If we are doing a watershed (two-step) update process to get the LZMA support, we can handle the SHA512 -> SHA384 transition at the same time. Mozilla did this same thing, adopting both incompatible changes to the MAR format together in Firefox 56.0 timeframe. 4. "Remove hashFunction and hashValue attributes" https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values. As I mentioned above, your input is welcome. Thanks! -Mark

3 3

Proposal for redesigning the security controls -- updated version
by Georg Koppen 05 Apr '18

05 Apr '18

Hi all! Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent). We had quite some discussion about doing First Party Isolation (FPI) on top of the security slider. I think that idea is sufficiently complex that it merits an own proposal, especially as I still don't see how we can get it right. See bug 21034 for the context where at least one example is shown that the security provided by the slider gets actually worse with FPI. So, we seem to be in a situation that FPI both enhances and decreases the security benefits promised by the slider depending on the context and on users expectations which seems tricky to resolve. Regarding the all-features-enabled-button idea Arthur had it seems to me we should think about that one more as well, taking the different blocked content into account and, above all, its different treatment by NoScript: it is possible to enable/disable scripts right now by web site while e.g. WebGL premissions are session-wide. Providing one button and allowing to blow away big parts of the slider protections for the whole session that way seems not like a thing we should do lightly. We might want to make a distinction between JavaScript which is what users need to have enabled most of the time to interact with a site and "active content" and expose just two buttons for that for the time being. That's what I propose in the proposal update while we think more about it. I agree that we should not bother users with concepts like WebGL, Fonts, SVG etc. I've attached a diff to the original proposal for those following along and not wanting to read the full one again in order to spot the updates. Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 6-March-2018 Status: Open 1 Introduction Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Browser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere. 1.1 Motivation By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address: a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise. 1.2 The State of the Security Controls That is how the toolbar in Tor Browser looks like currently: ---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ---------------------------------------------------------------------- N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs. 2 Proposal Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and follow-up proposals. 2.1 Restructuring the Toolbar 2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now: Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done. HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either. NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that. 2.1.2 Adding a Security Settings Button to the Toolbar I'd like to propose a new button on the toolbar giving easy access to what is essentially the tool that we want to promote: the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution. The button would open the security slider menu with a right-click. With a left-click, keyboard shortcuts, and mouse-wheel scrolling one can adjust the security level directly. However, easily adjusting the slider settings just for a single tab is risky as it affects all the other tabs and windows in the session as well. We should therefore at least warn the users about the possible danger and provide the option to acquire a New Identity right after changing the security slider level. The new toolbar would look like: ---------------------------------------------------------------------- | --- --- ------------------------------- --------------- --- | | |T| |S| | URL bar | | Search bar | |M| | | --- --- ------------------------------- --------------- --- | ---------------------------------------------------------------------- T = Torbutton button S = Security Settings button M = (Hamburger) Menu button Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not. 2.2 Dealing with Per-Site Security Settings There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button. With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar. One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons. By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could show up once there is a respective object embedded on a website. We should refrain from exposing icons for every single "active content" in the URL bar, though. Rather, besides the button for temporarily allowing JavaScript we would only add one additionally, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.). 3 Additional Considerations 3.1 Where Are My Extensions Gone? Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least. 3.2 How Do We Inform Users about the New Interface? I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one. 3.3 Should We Change the Default Security Level? As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs. [1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/… [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805 Georg

3 7