tbb-dev March 2018

tbb-dev@lists.torproject.org

13 participants
12 discussions

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

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

Moving next Tor Browser meeting to April 3, 1800 UTC
by Georg Koppen 29 Mar '18

29 Mar '18

Hi! We'll move the next Tor Browser meeting to April 3 (which is the Tuesday next week), 1800 UTC as there are some jurisdictions where April 2 (Easter Monday) is a public holiday. The meeting location is, as usual, #tor-meeting on the OFTC IRC network. Georg

3 4

Intent (Request?) To Remove: privacy.firstparty.isolate.restrict_opener_access
by Tom Ritter 28 Mar '18

28 Mar '18

Back in https://bugzilla.mozilla.org/show_bug.cgi?id=1319773#c20 we decided to create this pref to allow Tor Browser to relx it's FPI back to it's old version, which allowed opener access. As far as I can tell, there was never a need to do this. This pref _can_ be used to debug one specific instance of FPi login failures. But it's also a confusing edge case that it doesn't seem we need to support anymore. If I remove it, it will still be present in 60 ESR. -tom

2 1

Compiling Firefox with mingw-w64/clang
by Georg Koppen 26 Mar '18

26 Mar '18

Hi all! We need to switch away from our mingw-w64/gcc-based toolchain for our Windows builds in the near future as Mozilla's Rust-based Stylo can't get compiled with it anymore.[1] We have time to do this switch during the ESR 60 cycle and I guess this is needed, too, as I anticipate at least a bunch of reproducibility issues and probably other bugs we have not found yet/not thought about. I am not done yet with the Stylo bug but I thought I write up some instructions for those who want to try out this new toolchain (and I even know of someone already showing interest :) ). I've been using https://github.com/mstorsjo/llvm-mingw. `master` should basically work although I am right now still on commit 48af4af2c3f7aad1b0d58c82fe38c8d44996d912. 1) Building llvm/clang ---------------------- First we need to get all the needed llvm/clang/lld sources: git clone https://github.com/llvm-mirror/llvm.git cd llvm git checkout ea4dd0b9197d95bd52b54f18666bdd8ff60238af cd tools git clone https://github.com/llvm-mirror/clang.git git clone https://github.com/llvm-mirror/lld.git cd clang git checkout 09a80cc504e13cd931d86446f194d4a0ddf89e8f cd ../lld git checkout 1493087f49cd388f501f0b802ac7c1e1796d2f29 cd ../../../ Now, make sure you skip the arm and aarch64 targets in build-llvm.sh by patching the script to use -DLLVM_TARGETS_TO_BUILD="X86" only. Then doing a /path/to/llvm-mingw/build-llvm.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 2) Dealing with the res format ------------------------------ Install the proper $ARCH-w64mingw32-windres binary with your Linux package management tool and rename it to $ARCH-w64-mingw32-windresreal. We need that as the tool LLVM provides (llvm-rc) is not mature enough to deal with the res format. (This step is explained in the README.md) 3) Install the wrappers ----------------------- Go into the llvm-mingw directory and patch install-wrappers.sh to install the needed wrappers just for your architecture. E.g. if you are building on x86_64, do ${ARCHS:=${TOOLCHAIN_ARCHS-x86_64}} then run ./install-wrappers.sh /path/to/your/install/prefix 4) Build mingw-w64 ------------------ First we need to get the mingw-w64 sources: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 cd mingw-w64 git checkout 6c676fa4cf13e86127cb350349ced94ce4288497 cd .. We use the build-mingw-w64.sh script in the llvm-mingw repo to build the mingw-w64 part. There are two patches needed to this script a) Again, as in 3) ARCHS need to get adapted. b) Firefox does not compile using ucrtbase yet. So, we need to remove '--with-def ault-msvcrt=ucrtbase' and 'FLAGS="$FLAGS --with-default-msvcrt=ucrtbase"' Now, again doing a /path/to/llvm-mingw/build-mingw-w64.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 5) Build compiler-rt -------------------- The sources first again: git clone https://github.com/llvm-mirror/compiler-rt.git git checkout 97adb78eaae40595d052cfa76514db8256063bea cd .. Now, we use the build-compiler-rt.sh script in the llvm-mingw repo to build the compiler-rt part. There are two patches needed to this script: a) Again, as in 3) ARCHS need to get adapted. b) If ARCHS does not include i686 then we can omit a respective symlink by commenting it out ( #ln -sf i686-w64-mingw32 $PREFIX/i386-w64-mingw32 ) Then, doing a /path/to/llvm-mingw/build-compiler-rt.sh /path/to/your/install/prefix should build all the things and install the results in the prefix directory. 6) Building libcxx ------------------ Getting the sources git clone https://github.com/llvm-mirror/libunwind.git git clone https://github.com/llvm-mirror/libcxxabi.git git clone https://github.com/llvm-mirror/libcxx.git cd libunwind git checkout 86ab23972978242b6f9e27cebc239f3e8428b1af cd ../libcxxabi git checkout 05ba3281482304ae8de31123a594972a495da06d cd ../libcxx git checkout a351d793abce1ecaead0fd947fe17f75b0c41ae5 cd .. Now, we use the build-libcxx.sh script in the llvm-mingw repo to build the all three pieces. Again, just the ARCHS part in it needs to get adapted. Afterwards we can do /path/to/llvm-mingw/build-libcxx.sh /path/to/your/install/prefix and it should build all the things and install the results in the prefix directory. That's it! Now, pick a mozilla-central revision that still allows disabling Stylo and use the .mozconfig and patches attached to the Mozilla bug[1] to get the whole piece built. Note, the above is from memory and looking at the scripts again. Attached is the patch I have in my llvm-mingw repo. The commits outlined in this mail are the ones I have used, though, as I needed to work around some bugs. The setup should not be too complicated but I am glad to help if anyone got stuck. Georg [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1390583

1 0

MOZ_DISABLE_NONLOCAL_CONNECTIONS
by Tom Ritter 26 Mar '18

26 Mar '18

45 seconds ago I just learned about the environment variable MOZ_DISABLE_NONLOCAL_CONNECTIONS that we use in our testing environment. It feeds through to one real location in the browser: nsSocketTransport2 https://searchfox.org/mozilla-central/rev/8976abf9cab8eb4661665cc86bd355cd0… This isn't a sandbox. If an attacker has code execution (parent or content process) they can make network connections manually from system libraries and will never touch this code. But it might be a way to add (some) assurance about browser features accidentally bypassing the proxy. So I'm wondering if this is something Tor Browser can set for defense in depth. In fact, it's already in esr52: https://dxr.mozilla.org/mozilla-esr52/search?q=AreNonLocalConnectionsDisabl… I tried to get Tor Browser to unset the proxy but couldn't seem to get it to work; is there a patch that prevents this? It would be interesting to remove the patches tagged 'tbb-proxy-bypass' (on https://torpat.ch/uplift) and see if this prevented (some) of those. -tom

3 3

Daily users of Tor Browser
by sajolida 23 Mar '18

23 Mar '18

I originally wrote wrote to metrics-team@ but they redirected me to you. I wanted to have a (rough) number of daily users of Tor Browser to compare it to the daily users of Tails (instead of comparing it to the daily users of Tor as a whole). I went up to "Update pings" in "Tor Browser downloads and updates": https://metrics.torproject.org/webstats-tb.html But I have a hard time interpreting this number from the description of the metric: « Update pings and update requests are requests made by Tor Browser to check whether a newer version is available or to download a newer version. » How often Tor Browser is pinging for updates? Once a day? Every time it starts? I also understand from #22346 that I should rather use the numbers after the big drop around January 20.

2 1

Next Tor Browser meeting on March 26 at 1800 UTC in #tor-meeting
by Georg Koppen 17 Mar '18

17 Mar '18

Hi all! Some of you might wonder whether we'll have our regular Tor Browser sync on the coming Monday. As we said before we started travelling to Rome, we'll skip that one and would have our next meeting on Monday, March 26. Note that we adapt the meeting time slightly as well as we'll have daylight saving time by then in the US and Europe. Thus, the next meeting will be on Monday, March 26 at *1800* UTC in #tor-meeting on the OFTC network. Georg

1 0

Work left before releasing the first alpha for Tor Bowser on Android
by Georg Koppen 14 Mar '18

14 Mar '18

Hi all! While doing roadmapping on Sunday we decided to work towards getting our first alpha for Tor Browser on Android out in July this year. Sitting together today we discussed what needs to be done by then. The blockers for that release are: 1) The first alpha should not be based on Firefox ESR but on the regular release channel which we tend to follow for the mobile Tor Browser 2) We need to make sure there are no proxy bypasses possible 3) We need good hints for our users that this is an alpha, possibly showing the missing features (UX team help) Moreover, the following things should have been investigated by then: a) What do we want to do with the updater/updating users in case we want to not only use Google's Play Store but have the browser availale in F-Droid and on our website as well? b) Are the first-party-isolation and fingerprinting defenses on Android working if the respective preferences are flipped? That means we don't plan to include Torbutton nor Tor Launcher right now, which should happen later. Neither are we planning to have the reproducible build of that browser ready by then. This is planned for the second alpha scheduled for September. Let me know if I forgot something or whether the above does not make any sense. Georg

3 3

Tor Browser for Android Roadmap/Proposal
by Matthew Finkel 09 Mar '18

09 Mar '18

Hi, Below is the current (rough) roadmap and outline of Tor Browser for Android. There remains some uncertainly of some aspects (and timing), but we should be able to make some decisions in Rome. (Igor, sorry if you wanted to make additional changes - we can continue modifying it this next week) Thanks, Matt --------------------------------------------------------------------- The Tor Browser for Android Design Proposal and Roadmap 0. Introduction Tor Browser for Android, from here on referred to as TBA, is a new implementation of Tor Browser targeted at recent Android platforms. In addition to the existing implementation, where Tor Browser is supported on Microsoft Windows, Apple OS X, and Unix-like systems, Tor Browser for Android will provide similar functionality on Android. Currently Tor Browser is based on the most recent Mozilla Firefox ESR. Unfortunately, Mozilla does not support an ESR for Firefox for Android, therefore TBA must follow the most recent Mozilla Firefox releases. This reduces the risk introduced by using vulnerable and unsupported code, and allows leveraging Mozilla's teams for support. Tor Browser for Android will provide an implementation of the Private Browsing Mode, as documented in the Tor Browser Design[0]. Currently, the Guardian Project maintain and support Orfox as the initial implementation of TBA. The goal is using Orfox as a base and improving upon it such that TBA obtains privacy, security, and usability parity with Tor Browser (for Desktop). 1. Roadmap Over the following one year, we will work toward this goal. If we divide this time frame into quarters, we can set expectations for what will be accomplished. In Q1 2018: - Orfox patches will be reviewed and merged into tor-browser.git - Porting Torbutton for TBA will begin. - Porting TorLauncher for TBA will begin - Rebasing TBA patches onto Firefox for Android 60 will begin - A new version of Orfox will be released in parallel with Tor Browser, based on ESR 52.6 - XXX Discuss in Rome with TGP, coordinating releases In Q2: - Add TBA into tor-browser-builder and eliminate reproducibility issues - Continue porting Torbutton and TorLauncher including implementing mobile-UI - UI design discussions will take place in Rome - Investigate mobile-specific fingerprinting vectors - Release Orfox updates in parallel with Tor Browser In Q3: - TBA is fully reproducible - Release first version of TBA (alpha?) (probably based on Firefox for Android (Fennec) 60) - XXX We can considering coordinating this with an announcement at HOPE XII in July - Begin auditing GeckoView and Mozilla Focus implementation as upstream of TBA - Focus has different "look and feel", evaluate UX impact In Q4: - Release first version of TBA with TorLauncher integration 2. Design Tor Browser for Android will adhere to the Tor Browser design requirements[0] and it will maintain the same adversary model with increasing adversary capabilities. The user interface restrictions present on Android platforms introduce additional obstacles and require re-design and re-implementation of some existing Tor Browser features. However, the end result is maintaining the same "look and feel" on desktop and Android. 3. Adversary Capabilities - Attack a. Read and change Tor configuration variables through the Tor Control protocol. - An adversary (malicious application) could access the Android IPC mechanism and change the configuration values. 4. Additional Information - Supported Android versions - Android 6 and above. 5. References: [0] https://www.torproject.org/projects/torbrowser/design/

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev March 2018