February 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

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

Pad for planing for Rome o/
by isabela 04 Mar '18

04 Mar '18

Hello TB team! I created a pad for us to create agenda and share information folks should review before Rome: https://storm.torproject.org/shared/2RXUuAa_G4_GNy5yHFt8gjFqOv2wAJeq8-_0mQm… This pad ^^ is for all the meetings on March 11th. I merged UX sync with Roadmap because: 1. I think most of the conversation is coordination of work (when Antonela needs to be done, when dev starts etc) 2. This gives 2 hrs of hanging out and talking roadmap; so there is no rush and if it ends earlier - the better :) Mobile! I added a big chunk of the language used in the proposal to describe the activities to help guide you on the discussion related to what is the final product for this project. The timeline is just a guide for you, if you want to change it, you can do it. Is better to change and have things reflect reality. Also, use the time you think you need to get the work done. We will ask for an extension to sponsor8 contract, so this will help me know how long do you need it to be. Desktop! :) I think coordination with Antonela and Mobile is good for all the UI changes coming up (work Antonela is doing under OTF grant). We sent a SOI to DRL asking money for TB team, there is a link in the pad to it. But is nothing crazy, just keeping up with Mozilla releases and implement Anto's work. I left agenda for meetings with Mozilla open - we should share with folks so it can be populated before Rome. I also left the questions to answer when doing the retrospective, you can reflect on it ;) I leave it up to the team if folks want to fill it up before Rome or after Rome. One less thing, Antonela will be with yall during the roadmap meeting. I will have to split and be with network team roadmap meeting hehe :) Let me know if you have any questions! isabela

2 1

#25112 - Tor Browser 7.5 is not working on Windows Vista 64bit
by Richard Pospesel 22 Feb '18

22 Feb '18

So I've tracked down the root of the problem here: we're not currently building nor packaging wow_helper.exe with Tor Browser. This exe is a necessary part of the sandbox init process for Vista (but not newer Windows OSes) I'm able to build locally with mingw via: x86_64-w64-mingw32-g++ -m64 -municode -static -static-libgcc -static-libstdc++ -I../../.. *.cc -o wow_helper.exe Dropping that exe into the Browser folder lets sandbox'd tabs work once more! That said, getting this building with FF's build system and also updating RBM to work with the new dependencies requires some specialized knowledge I don't currently have, so any pointers on this front would be great. Just spit-balling, but the main hurdles as I see them are as follows: - firefox : wow_helper is built with special Makefile.in configuration file which temporarily overwrites the CXX, LIB and friends to point to the 64-bit MSVC compiler toolchain. We can probably do a similar thing here with x86_64-w64-mingw32-g++ - rbm : need to update the docker image to install the x86_64 version of the mingw toolchain. - tor-browser : will need to update the nsis installer and possibly other things to properly include and deploy the wow_helper.exe However, Chromium removed this entire code path back in 2016 when they dropped support for XP and Vista, and somewhere between version 52.6 and latest this code path was also removed in Firefox. So, depending on the timeline for updating Tor Browser to latest, we may just want to ignore this issue just do a simpler code patch that disables sandboxing all together for those under Windows 7. best, -Richard

2 1

Android OS Candidate
by Ozojie Gerald 12 Feb '18

12 Feb '18

Hello, I chose this task: 1) Integrate "tor-android" binary library with the Tor Onion Proxy Library: https://github.com/thaliproject/Tor_Onion_Proxy_Library/issues/35 Here is the repository with updated version: https://github.com/lordzouga/torandroidlib I have updated the ticket in accordance with the instructions in the mail and sending this mail to complete the process. Thanks Ozojie

1 0

Proposal for redesigning the security controls
by Georg Koppen 09 Feb '18

09 Feb '18

Hi! I managed to come up with a proposal for redesigning the security controls (see below). As always feedback and discussion is very welcome. Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 1-February-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 Bowser 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 and 3.3. 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. 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 be made visible once there is a respective object embedded in a website or, even better, once the user actually chose to unblock any of them. 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

7 18

building wow64 with sandbox enabled?
by Richard Pospesel 09 Feb '18

09 Feb '18

How do we do this? I've commented out the --disable-sandbox flag in the relevant mozconfig in rbm, but doing so results in build errors in firefox. Haven't looked at all of them, but at least some of them seem to be mingw gcc issues and some of patches for similar issue in mozilla's bugzilla. Building with the --disable-flag enabled works fine. We must be able to do this, since 7.5 64-bit has sandboxing enabled... thanks, -Richard

2 1

UX + TB teams meeting about circuit display ticket
by isabela 06 Feb '18

06 Feb '18

Hello there! Me and Antonela would like to sync with TB team, Arthur and Geko are not optional :P, everyone else is optional and more than welcomed to join!! Let's sync next Wed, Jan 31 at 1600UTC at #tor-meeting? Arthur this is quite early for you :| Here is the ticket: https://trac.torproject.org/projects/tor/ticket/24309 I think version 8 is the most popular so far. And we also got a request to: 1. make sure people can find the new location (who is already using) 2. help solve the overall problem of new users finding these features This ticket https://trac.torproject.org/projects/tor/ticket/24918 was mentioned in some comments. It actually describes more the problem number 2 above. This problem me and Antonela are planning to fix by creating a user onboarding as part of the about:tor page redesign. For this meeting we will probably only talk about problem 1 as we plan present some ideas on how to solve it :) o/ We can chat more at the meeting! cheers, isabela

3 4

Pull Request for Tor Onion Proxy Library
by Shane Isbell 06 Feb '18

06 Feb '18

I submitted a pull request for TorOnionProxy. It contains a number of fixes and updates to the build. This includes using the tor-android-library and the freehaven-jtorctl library as dependencies. A more complete list of changes is in the pull request submission. https://github.com/thaliproject/Tor_Onion_Proxy_Library/pull/45 Best Regards, Shane Isbell

3 2

TASK03 was finished
by WU RUXU 06 Feb '18

06 Feb '18

Hi all 3) Update tor-android project Makefile and documentation to support Tor 0.3.2.9 stable release, which requires Rust: https://github.com/n8fr8/tor-android I haven't find any issue ticket on TASK03, so I attached the patch file for tor-android. tonight I have verified the tor armeabi binary on my mobile device, tomorrow I will test the tor x86 binary on my friend's devices. -- Thanks PGP Fingerprint: F7BA D6CE 6592 77C7 0D2E 3BD5 5479 A15E B305 B8FE

2 1