[guardian-dev] Orfox design and development questions

[Nathan of Guardian]

On Wed, Jul 15, 2015, at 12:35 AM, str4d wrote:
> In stock Fennec (Firefox for Android), the only way to configure a
> proxy is via about:config (or the now-deprecated ProxyMob plugin).
> Currently in Orfox, Orbot's SOCKS proxy is set by default in
> about:config, and Orbot's HTTP proxy is hard-coded into the Java
> settings. I have been poking around at Amogh's Orfox branch, and have
> made a patch set that collect together the various places that the
> HTTP proxy is hard-coded into a single location [0] (yet to be pulled).

SOCKS is the preferred proxy method, as it goes directly to Tor and
doesn't have to first go through the Polipo HTTP proxy we bundle into
Orbot. However, while the Gecko component supports SOCKS, the rest of
the Android Java app UI layer code only supports HTTP proxying. Our goal
is to eventually move it all over to SOCKS, but for this first release
it will be mixed.

Really happy to have your contribution to centralize the management of
the proxy settings!

> (My eventual goal is to help add I2P support to Orfox. Having
> hard-coded Tor dependencies scattered through the codebase doesn't
> help me :P )

Absolutely. Our goal is also to upstream the proxy support into the main
Firefox for Android codebase. Mozilla is on board with helping us do
this.

> Amogh pointed me to the existing ProxySelector code [1] and asked that
> I integrate my patches into this. However, when I looked into it
> further, I discovered that the ProxySelector code's purpose is that
> when "use system proxy settings" is selected, Firefox picks up the
> system proxy configuration from Android's APN or WiFi settings [2].
> This got me thinking more broadly about how Orfox will be used.

Yes, ProxySelector is bad news, and no app should depend on it. First,
it doesn't work consistently across devices, and any other app could
easily disable it. We should remove all dependence on it for Orfox.
 
> Ideally, we could set the proxy settings in a single place, and they
> would propagate everywhere. Amogh tells me that it is possible to have
> the Java layer listen to the Gecko layer. IMHO this should be default
> behavior and is probably a patch that needs to be sent upstream to
> Mozilla.

I think the Java layer should modify the Gecko layer, ultimately. We can
have our defaults in Orfox to use the Orbot/Tor ports, but if the user
opts to change them in a preference somewhere, then they should
propagate all the way down.

> But assuming that we _do_ get Orfox to this point, the next issue is
> how we select the proxy settings, or present them to the user. Do we:
> 
> - - force Orbot-only (the status quo)?
> - - leave users to delve around in about:config?
> - - listen to the system proxy settings?
> - - support multiple proxies (e.g. .i2p through I2P, .* through Tor)?
> - - bundle the NetCipher and/or I2P Android client libraries?

I think supporting a new UI capability to choose from built-in defaults
(Orbot, I2P, Psiphon, etc), and then be allowed to manually modify them
yourself could be possible.

We must avoid the HackingTeam attack vector which modified Tor Browser's
torrc file to change the SOCKS proxy setting from the local Tor one to a
malicious remote one.

> So, my question is: what is Guardian Project's design goal for Orfox?
> How do you envisage people using it, and how do you envisage them
> configuring it?

By default Orfox will always expect to be paired with Orbot. However, we
are happy to support your efforts at I2P, and even sense the fact that
I2P is installed/running instead of Orbot, and offer that as a proxy
destination. This is ultimately why Orfox is called Orfox and not Tor
Browser, at this point, as we may make some decisions that are different
from Tor Browser. I would rather take this route, then have you either
be left with a less secure browser for your users, and/or you have to
fork, manage and maintain your own fork of Orfox with your defaults.



+n


-- 
  Nathan of Guardian
  nathan at guardianproject.info