Hello, On 01/15/2018 10:40 AM, Georg Koppen wrote:

Hi!

Igor Oliveira:

...

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-cWFQwH1dgQsETUC7whKb7Hy46cPYZ... 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.

Thanks for starting this discussion!

...

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.

What do you mean with "be integrated within Tor Browser"? Do you have a plan on how to achieve that? If so, we should specify it and if not we should come up with one and specify it and include it in this proposal.

I am asking because one could think of different ways of achieving that. One way would be to treat the Torbutton code the same way as the pdf.js code which lives under browser/extensions and ends up in the browser omni.ja under chrome/pdfjs. Another one would be having it as a proper extension living the features dir like the e10s related extension. A third one as would be coding up just a bunch of not really connected JavaScript code modules which get included into omni.ja (say under /modules and /components if needed) and the related UI parts get put directly into the browser chrome.

Indeed, in my head, I was always thinking about the third option, Tor Button needs to access few XPCOM interfaces, so thinking about a long term solution, it would live under /modules and /components. The down side of that is the code is now spread in multiple different directories. (I will update the proposal).

Regarding the migration to XHTML, careful. I think we should follow the lead of the respective platform UI. Trying to get rid of XUL for desktop just to have all the Torbutton related parts coded in XHTML while the remainder of the browser UI still does XUL might lead to weird outcomes.

Yep, after the latest Monday meeting, the Arthur's idea of making progressive changes instead of refactoring everything at once make totally sense.

...

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.

It does nothing right now. I am inclined to drop it and if we want that functionality back we can think about how to achieve that in a good way.

Great, let's kill it.

...

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].

The UX part, yes, but there is the underlying code and we should think about what to do with it. Looking at the functionality provided by code in chrome it is at least

1) New Identity 2) New circuit for this site 3) The circuit display 4) The security slider 5) Tor Network Settings 6) Check for Tor Browser update... 7) Showing the state of Tor (green onion vs. crossed out onion) 8) Helpers for 1) - 7) 9) Things in torbutton.js doing e.g. window resizing on start-up

Few of these items are also affected by the tor launcher proposal.

So, starting with 2) and 3). That's covered by #24309 (Obj. 4.1 from the OTF proposal). I think we can make a decision after we finally decided what we want to do (I think we are close, Arthur, right?). One interesting aspect of that in is that the helpers for that part involve tor controller related code. My idea would be to take that part + the relevant tor-launcher parts into a code module put somewhere into /toolkit. That way not only Tor Browser but other projects (think of FUSION or Thunderbird) could use that and we would not have two extensions with pieces of controller code each.

oh cool, great idea.

1) and 4) could be part of the toolbar redesign proposal I am currently writing (Obj 2.1 from the OTF proposal). In fact, I think I plan to argue that both New Identity and the slider should be available as easy to click items on the toolbar. We could add the slider code as a module ending up in the browser omni.ja and integrate the remainings directly into browser JS code and XUL.

We also need to think where we are going to place them in the mobile version. If we keep the the identity in the Tor Button, it could be easily reused in the mobile version. However it can harm the Desktop version UX.

5) The network settings dialog is a Tor Launcher part. I am not sure what to do with that one yet (I have not read the Tor Launcher redo proposal yet either).

6) We might want to rethink the usefulness of the update check and flashing (in case the browser is outdated) behind the Torbutton menu during our work for a better Tor Browser update UI (Obj 3.1 from the OTF proposal). So, we could consider just removing this part/commenting it out for now.

7) Is already provided by the about:tor page. I think there is no need to have an .onion icon just for that use case. We could remove/comment the relavant code parts for now.

+1

9) That should be integrated directly into browser.js and the XUL files and I suspect there is a ton of stuff that we can get rid of (yay!).

Georg

Thanks for the feedback I will digest the feedback and update the proposal. Igor

...

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.0...

[8] https://trac.torproject.org/projects/tor/ticket/24309 _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev

_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev

On 1/15/18 1:13 PM, Arthur D. Edelstein wrote:

Hi everyone -- just to try to clarify that a little, here's a staged approach I would like to propose. In addition to being a step-by-step model, I see this approach as minimizing the risk of causing regressions in the existing desktop implementation, and, for the sake of efficiency, avoids re-implementing or forking code except where necessary:

* Stage 1 (Move and Fix): We move tor-launcher and torbutton into their own directories in tor-browser.git (similar to how pdfjs lives) without making any code changes or changes to the file structure except whatever is required to make them continue to work on desktop. My guess/hope is that the changes will be relatively small, because XUL and XPCOM still work internally in Firefox. This step solves the WebExtensions problem and thus needs to happen for desktop anyway for ESR60.

More accurately, this step *avoids* WebExtensions entirely and all of the issues associated with a move in that direction. Kathy and I agree with this approach; it seems more productive to work on Tor Browser things than to work on transitioning extensions to WebExtensions to add the features that what we need. Matt's proposal to use a hybrid approach is also a possibility, but it seems better to stick with XUL/XPCOM for now.

* Stage 2 (Extend to Android): The mobile team makes a series of patches to torbutton and tor-launcher to get each feature working on mobile, while making sure there aren't regressions on desktop. I imagine this would require refactoring to separate out business logic from UI, and then writing a separate UI part for mobile that talks to the same business logic.

Trying to keep things working on both desktop and mobile may slow down the mobile work a little, but it is important if we want to achieve the goal of a common codebase. This stage will also force us to cleanup the existing code. :) Those of us who have worked on Torbutton and Tor Launcher for the desktop may need to help with some of this; at the very least, we can review the refactoring work and help check for regressions.

* Stage 3 (Maintain): Once the Android code is fully working, both desktop and mobile teams continue to maintain and improve torbutton and tor-launcher code. Improvements to business logic will benefit both desktop and mobile. We can also continue to refactor, including moving files out from under torbutton or tor-launcher directories into other locations as needed. For example, as Georg suggests, we could refactor controller code into a module that is used by both torbutton and tor-launcher.

Over time, we can also consider moving some front-end pieces to WebExtensions or XHTML. As Mozilla moves away from XUL/XPCOM for their frontend code, we should do the same. In other words, we should try to follow their lead unless we have a good reason not to do so. -Mark