tbb-dev January 2018

tbb-dev@lists.torproject.org

17 participants
13 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

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

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

Tor Browser uplift tracker
by Arthur D. Edelstein 05 Feb '18

05 Feb '18

Hi Tor Browser devs, I've been working on uplift this week and I have updated the uplift tracker table at https://torpat.ch . There are bugzilla bugs for most of our eligible patches, but there are still about 15 "untriaged" patches in gray, because I couldn't be sure if they were appropriate to uplift. If you have time to have a look at the untriaged ones you are familiar with and let me know if you think any are available for uplift, I would be grateful. My goal is to mark all patches either red, yellow, or green so that no untriaged patches remain. Thanks, Arthur

4 8

Tor Browser TorLauncher Proposal
by Matthew Finkel 02 Feb '18

02 Feb '18

Hi All, Apologies for the delay in sending this. Attached (or below) is the proposal for migrating the TorLauncher legacy extension to WebExtension. The main problem with directly moving TorLauncher to using WebExtensions is the two Extensions APIs are not 1-to-1. There was significant functionality previously available that is not available with WebExtensions. In particular these involve launching a child process and controlling it. This is a primary objective of TorLauncher, so we needed an alternative. As a result, this proposal takes a mixed approach. Part of the functionality of TorLauncher will remain as an extension and the remaining functionality will be directly implemented into Tor Browser. >From the mobile/Android perspective, TorLauncher is a strange requirement at this moment. On Android, Orbot controls and configures tor, and external Apps cannot configure tor which is the purpose of TorLauncher. In the future, we may prefer another design and integration, providing a better user experience. Although the proposal is long, it is mostly documenting the extension's existing functionality. Thanks, Matt

4 5

Tor Button Proposal
by Igor Oliveira 17 Jan '18

17 Jan '18

Howdy, As many of you know. We are bringing Orfox on par with Tor Browser(https://blog.torproject.org/blog/upping-support-mobile-browsing) and one of the steps is porting tor button extension to mobile. That said, I wrote an *initial* proposal(https://storm.torproject.org/shared/fchH0_Liol-cWFQwH1dgQsETUC7whK… and it is also bellow) about what are the challenges, the approach and how we can try to keep as much code from the current extension. Tor Button Next Proposal 1. Introduction Tor button, currently, is implemented as a Firefox extension using the XPCOM API and XUL markup language that are not supported anymore since Firefox 58[1]. This document aims to describe the approach used to revitalize the current extension and the changes needed to make it work on mobile. 1.1 Design Requirements and Philosophy The Tor Button requirements and adversary model can be found in two separated documents[2][3]. 2. Implementation Instead of an extension, we propose the Tor Button to be integrated within the Tor Browser, thus we still can reuse few parts of the current extension code such as the components and chrome code. For the XUL markup language, we also suggest to migrate to XHTML when possible. 2.1 Components This section describes the current components and what changes will be made. 2.1.1 Tor About (contract id: @mozilla.org/network/protocol/about;1?what=tor) Overrides the Firefox/Fennec about page. We can reuse it as it is in the Desktop and mobile version. For the mobile version, we need to be careful about not be overridden by the android/components/AboutRedirector.js. 2.1.2 Content Policy (contract id: @torproject.org/content-policy;1) Avoids the Browser to leak resource:// URI information. We can use as it is, however a fix was shipped in the Firefox 57 and we need to make sure that it works as expected. 2.1.3 Cookie Jar Selector (contract id: @torproject.org/cookie-jar-selector;1) Enable selection of separate cookie jars for (more) anonymous browsing. We can keep it as it is, just improving the comments in the code. 2.1.4 Domain Isolator (contract id: @torproject.org/domain-isolator;1) Put requests from different first party domains on separate tor circuits. We can keep it as it is. 2.1.5 Filter drag events (contract id: @torproject.org/torbutton-dragDropFilter;1) Filter drag events to prevent OS access to URLs (a potential proxy bypass vector). For desktop, we can keep as it is. For mobile, Android 7(API Level 24) added support for displaying more than one window at the same time[4], allowing the users to drag and drop data between activities sharing the screen. Looking looking through code and making manual tests we were not able simulate drag events between other apps and Orfox/Firefox. (Can someone else confirm it?) 2.1.6 External apps confirmation dialogs (contract id: @torproject.org/torbutton-extAppBlocker;1) Handles displaying confirmation dialogs for external apps and protocols. For Desktop, we can keep as it is. For mobile, Android uses the concept of intents to load external apps[5] (in fact, it is known by deep linking). Orfox already disables external apps making the preference network.protocol-handler.external-default false. 2.1.7 Tor Startup Observer (contract id: @torproject.org/startup-observer;1) Sets up Tor Browser networking proxy settings and loads the content-policy and aboutTor scripts. For Desktop, we can keep as it is. For mobile, the proxy settings are made by the Orbot app using the vpn service[6], thus we just need to load the content-policy and aboutTor scripts. 2.1.8 Tor Check Service (contract id: @torproject.org/torbutton-torCheckService;1) Verifies if the Tor Service is up and running. For Desktop we can keep as it is. For Mobile, currently, we can use a hybrid approach where we use Android Intents to verify if Orbot is up and running[7] and the check service component for sanity checks. 2.2. Chrome Mostly of the chrome changes will require definitions by the UX team such as the [8]. 3. External Links [1] https://blog.mozilla.org/addons/2017/11/20/extensions-in-firefox-58/ [2] https://www.torproject.org/docs/torbutton/en/design/index.html.en [3] https://www.torproject.org/projects/torbrowser/design/#DesignRequirements [4] https://developer.android.com/guide/topics/ui/multi-window.html [5] https://developer.android.com/training/app-links/deep-linking.html [6] https://developer.android.com/reference/android/net/VpnService.html [7] https://github.com/guardianproject/tor-browser/blob/orfox-tor-browser-52.2.… [8] https://trac.torproject.org/projects/tor/ticket/24309

4 5

Re: [tbb-dev] Cloudflare's OPRFs
by Jeff Burdges 15 Jan '18

15 Jan '18

On Fri, 2018-01-12 at 08:53 +0000, Georg Koppen wrote: > Could you elaborate on the problem you see a bit? What exactly > would be the attack scenario given edge1, edge2, ..., edgeN and > why are DLEQ proofs not sufficient for that? What do you mean > by "your edge public key"? There is a secret scalar k used in CloudFlare's OPRF scheme which yields a public curve point K = g^k. https://blog.cloudflare.com/privacy-pass-the-math/ If different k are used for different clients then those clients are distinguished from one another later when using the tokens. In batching the DLEQ proofs, they prove that all tokens within a batch share the same k, but the important question is: How do you know if different users are given different K? George said K was originally simply pinned in the Privacy Pass plugin, which works fine. It's hard to know if CloudFlare wants to keep it that way, maybe they're okay with sharing the secret k among many servers, or maybe they've no choice base on how Tor users move. In general, CloudFlare's answer is an unspecified certificate transparency scheme. I'm nervous about nebulously saying certificate transparency here because it's problematic if CloudFlare starts using different k on different servers, which they might do if they want to protect k better. I think short version for Tor Browser is: You can deploy Privacy Pass with a pinned K safely, but.. Anytime CloudFlare updates Privacy Pass, Tor Browser folk should check if they change handling of K. If they do, then any new scheme requires careful review. Ideally Tor Browser users should not independently update to any new CloudFlare version. Jeff p.s. We might ask if a purely local certificate transparency logs work: If Tor is anonymous, then CloudFlare cannot detect when the same users withdraws some new batch, so if they give this user a new K and their client remembers the old K then their client can detect this and raise an alarm. I think this fails for several reasons: First, there are attacks on Tor, including attacks we believe many adversaries do not use due to cost, but Privacy Pass without an external certificate transparency magnifies these attacks effectiveness. Second, Tor is typically run in situations like Tails where its hard to persist a local certificate transparency log. p.s.2 Any such scheme runs into this problem. In Taler, denomination keys face similar problems, except our tokens already represent money, so we already have a full PKI for denomination keys, extensive error reporting, and our merchants provide a de facto certificate transparency scheme. In other words, an adversarial exchange must tell merchants all the denomination keys, make all auditors sign them all, and then tell a targeted user only about a subset. That said, Taler can any certificate transparency scheme used by Privacy Pass can also be used by Taler, presumably

1 0

Meeting on Monday
by Georg Koppen 12 Jan '18

12 Jan '18

Hi all, Alright, we have a new year and I forgot a national US holiday again which is on Monday. :/ As it is quite late to find a different meeting day/time next week let's keep the meeting as was planned. US-based folks feel free to take the day off and skip the meeting. (Thanks Isa for reminding me, I try to get better at that business, promised) Georg

1 0

Tor Browser team sync with UX team next wed jan 10?
by isabela 09 Jan '18

09 Jan '18

Hello Tor Browser team o/ Happy 2018! I am writing this email to see if we could have a sync TB and UX teams :) to talk about the upcoming work we will be doing. Don't know what I am talking about? One more reason to join the conversation :) But you might remember that we wrote a grant for Antonela to work on some UI changes for Tor Browser, we have already started to work on some of these activities. All these are listed on both teams roadmaps, but this sync can be another opportunity to make sure we are all on the same page for when things need to be ready for development etc. Also catch up on other work we are doing that is not necessary part of this grant. We normally host our team meetings with 'guests' on Wednesdays, I was wondering if you would be available next week for meeting with us and what would be a good time on your timezone? I was thinking of 1900 utc, Wednesday Jan 10th. Does this time works for you? I will be sharing a pad with all the tickets/items I would like us to review :) my main goal is to make sure this work is on your radar or better saying, your roadmap hehehe cheers, isabela

11 19

Fwd: Tor Browser Settings | WebExtensions
by Nathan Freitas 08 Jan '18

08 Jan '18

Forwarding this email from August related to the renewed tor browser mobile work ----- Original message ----- From: Thomas Rientjes <thomas(a)synz.io> Subject: Tor Browser Settings | WebExtensions Date: Mon, 14 Aug 2017 09:40:32 -0400 Hi everyone! I have been closely following the developments around the new WebExtensions APIs, and believe said interfaces are finally capable of powering new versions of Tor Browser Settings. Firefox (and Firefox for Android) 56 will be supporting a new [browserSettings API](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserS… that will allow us to modify browser settings, which is the most essential feature as far as I'm concerned. Also, if you now define a "browser_action" for your extension, Firefox for Android will automatically create a menu entry and a main menu button tap listener that runs a custom function. I'm still not completely sure if there's a way for our extension to get access to local config data of other extensions (e.g. NoScript), since settings are no longer saved as globally available values. If it turns out to be impossible, we might want to take the route of directly interacting with such extensions. This will likely require work on the side of developers of the other extensions as well. Note that the settings storage issue only applies to preferences of non-legacy extensions. So, this is not directly related to porting Tor Browser Settings, which will only put us in a better spot. This means that we can either use the browserSettings API to read and modify the settings of legacy extensions, or (once they switch to WebExtensions) have all the latest tools to interact. Please let me know what you guys think :) Cheers! Tom

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev January 2018