[guardian-dev] Orfox / Fennec browser build latest assessment

str4d str4d at i2pmail.org
Tue Apr 7 22:13:53 EDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Nathan of Guardian wrote:
> 
> Amogh got the latest Fennec code building, to get our Orfox effort 
> started again. I thought I would share some of his findings below.

Thanks for keeping us all updated on this exciting effort.

I feel this is an appropriate moment to raise the point of I2P
integration. (For the lists's benefit: I contacted Nathan just over a
year ago asking about the potential for I2P integration in Orfox
alongside Tor, and he was very supportive.) Based on the findings
below, I think it would be a good idea to discuss how the network
integration will go ahead, with consideration of the desired (to my
knowledge) goal of making Orfox a "privacy browser", rather than just
a "Tor browser".

I will say upfront that I am happy to contribute to a multi-network
effort. I am the developer of the I2P Android app (which this effort
would be directly leveraging), and can contribute I2P-specific
knowledge alongside Android development experience.

> 
> *****
> 
> After going through the source code for firefox for andoroid which
>  can be found at http://hg.mozilla.org/mozilla-central/ , these 
> were the network related findings that I've made. The application 
> uses maily 3 layers to work. 1) The core layer, written in C++. 2) 
> A JS layer with some more functional code. 3) A Java layer that 
> makes uses the Android API's and other code used for android.
> 
> Out of the 3 layers, 2 of them make network calls. 1) The C++ 
> layer. There is an advantage of this layer making the network calls
> as all the calls made by this layer are proxied. They obey the
> fennec settings for proxy that has currently been set at 
> mozilla-central/mobile/android/app/mobile.js . Hence, we do not 
> need to bother about setting proxy to these connections and calls.

Sounds promising. The I2P Android app has the same ability as the
desktop version to set up and run proxy tunnels that other apps
subsequently use, so an I2P socks proxy tunnel should be usable in the
same way as the Tor SOCKS proxy. The only issue here would be the
necessary multi-proxy support, which I gather would mostly be UI work.

> 
> 2) The Java layer. The Java code, the code run by android also has
>  many network calls but the problem is that these calls are not 
> done obeying the tor proxy and hence they are harmful. List of 
> places where these calls are made are: a) any class which imports 
> org.apache.* (commons.net.ftp.*, http.*): 
> build/mobile/sutagent/android/DoCommand.java 
> build/mobile/sutagent/android/SUTAgentAndroid.java 
> mobile/android/base/distribution/Distribution.java 
> mobile/android/base/favicons/LoadFaviconTask.java 
> mobile/android/base/tests/BaseRobocopTest.java

Is this saying that the network calls made here are not proxy-able, or
that they just need to be fixed to use the same proxy settings?
Further reading indicates that the org.apache.http.* APIs are
deprecated in API 22 [0] and is not recommended for Gingerbread and
higher [1]. The recommended API does support proxying [2,3]. The code
paths above do appear to be Android-specific, and could perhaps be
migrated upstream to the newer API.

One advantage that I2P may have here is that Android applications can
make direct use of its Java API, which includes a socket interface
analogous to java.net.Socket. This gives the application full control
over their tunnels and private keys. I am not yet sure if this will be
of any use for Orfox specifically, but it is worth thinking about
while we establish the means by which multiple networks would be
supported. Perhaps (speculating here) the I2P integration could be
made through a local java.net.Proxy run by Orfox itself, which would
enable it to leverage I2P-specific privacy features without
compromising its ability to support multiple networks.

Food for thought, but I am very excited at the prospect of a
well-implemented, general, privacy- and anon-aware Android browser.

str4d

[0]
https://developer.android.com/reference/org/apache/http/package-summary.
html
[1]
http://android-developers.blogspot.com/2011/09/androids-http-clients.htm
l
[2]
https://developer.android.com/reference/java/net/HttpURLConnection.html
[3]
https://developer.android.com/reference/java/net/URL.html#openConnection
%28java.net.Proxy%29

> b) The browser also seems to be using another library for network 
> communications and that lies at 
> mobile/android/thirdparty/ch/boye/httpclientandroidlib This library
> seems to have proxy support but the calls made to this library have
> not been proxied, a list of those are here: 
> mobile/android/base/background/bagheera/BagheeraClient.java 
> mobile/android/base/background/bagheera/BagheeraRequestDelegate.java
>
>
>
> 
mobile/android/base/background/bagheera/BoundedByteArrayEntity.java
> mobile/android/base/background/bagheera/DeflateHelper.java 
> mobile/android/base/background/fxa/FxAccountClient10.java 
> mobile/android/base/background/fxa/FxAccountClient20.java 
> mobile/android/base/background/fxa/FxAccountClientException.java 
> mobile/android/base/background/fxa/SkewHandler.java 
> mobile/android/base/background/fxa/oauth/FxAccountAbstractClient.java
>
>
>
> 
mobile/android/base/background/fxa/oauth/FxAccountAbstractClientExceptio
n.java
> mobile/android/base/background/fxa/oauth/FxAccountOAuthClient10.java
>
>
>
> 
mobile/android/base/background/healthreport/upload/AndroidSubmissionClie
nt.java

> mobile/android/base/browserid/verifier/AbstractBrowserIDRemoteVerifier
Client.java
>
>
>
> 
mobile/android/base/browserid/verifier/BrowserIDRemoteVerifierClient10.j
ava
> mobile/android/base/sync/GlobalSession.java 
> mobile/android/base/sync/jpake/JPakeClient.java 
> mobile/android/base/sync/jpake/stage/DeleteChannel.java 
> mobile/android/base/sync/jpake/stage/GetChannelStage.java 
> mobile/android/base/sync/jpake/stage/GetRequestStage.java 
> mobile/android/base/sync/jpake/stage/PutRequestStage.java 
> mobile/android/base/sync/net/AbstractBearerTokenAuthHeaderProvider.jav
a
>
>
>
> 
mobile/android/base/sync/net/AuthHeaderProvider.java
> mobile/android/base/sync/net/BaseResource.java 
> mobile/android/base/sync/net/BaseResourceDelegate.java 
> mobile/android/base/sync/net/BasicAuthHeaderProvider.java 
> mobile/android/base/sync/net/HMACAuthHeaderProvider.java 
> mobile/android/base/sync/net/HawkAuthHeaderProvider.java 
> mobile/android/base/sync/net/HttpResponseObserver.java 
> mobile/android/base/sync/net/MozResponse.java 
> mobile/android/base/sync/net/Resource.java 
> mobile/android/base/sync/net/ResourceDelegate.java 
> mobile/android/base/sync/net/SyncResponse.java 
> mobile/android/base/sync/net/SyncStorageCollectionRequest.java 
> mobile/android/base/sync/net/SyncStorageRequest.java 
> mobile/android/base/sync/net/SyncStorageResponse.java 
> mobile/android/base/sync/net/TLSSocketFactory.java 
> mobile/android/base/sync/repositories/Server11RepositorySession.java
>
>
>
> 
mobile/android/base/sync/setup/auth/AuthenticateAccountStage.java
> mobile/android/base/sync/setup/auth/EnsureUserExistenceStage.java 
> mobile/android/base/sync/setup/auth/FetchUserNodeStage.java 
> mobile/android/base/sync/stage/EnsureClusterURLStage.java 
> mobile/android/base/sync/stage/SyncClientsEngineStage.java 
> mobile/android/base/tokenserver/TokenServerClient.java 
> mobile/android/tests/background/junit3/src/sync/TestUpgradeRequired.ja
va
>
>
>
> 
This is the url for the query,
> https://dxr.mozilla.org/mozilla-central/search?q=ch.boye.httpclientand
roidlib&case=false&offset=700
>
>
>
> 
NOTE:
> Not all these classes make network calls, I will make a shorter 
> list of this in the next few days. 
> _______________________________________________ List info: 
> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To 
> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVJI7TAAoJEBO17ljAn7PgdP4P/jdgKC+r/bXzUr/QbcHMSsDj
8qOfJB0OOKAU5JekAtKmJ8JP630wSAZWvSL0uWST0tuU5WUaIhkUNJ+gXwlpIvMC
uXsm3YwM4tEqGkI0kp/ClUFPfpIKQvA13/m4PCVie1c79GC9QXDENtk5xwDDI6Ph
noVBnqg+/d8XpMZGeKnhGgf/ykSjhPW88Op2412PMxe4sUKCMaAzCUHpHRcsd77U
pR2QwoCiBGmCv3pEBYmODO6ByO/7ibEnNxAMwDjrjqw45aCVtusjFeSJNC3nO6+z
6PbF4WrAEG93JbbK1GQt0jHm6SVdnbUpWpTJx2ForsMU/b8UajjpNu3ad/0bzOe+
Dm3O6/FkAX2vUfNz+qEcgZkTEPYQCVaXLBSNkdJG0Pd0gtiR1mkqx9wG7yzw6C35
imsw5RtBoQJA4QqOURuLEp6LN3bIux3CdEPEIgW4zjZP6uBOp125qxm90KO3evYZ
/+MeyAtBvYvtdp9ql3H8Szez8bI+VQ6AxBDyCPZCtPFxkDKdFHqROs20wWdNvSo6
Z6nkEDlLj/32zrMT2Pt8o4TqsZYuXqwao61x8ElcQWDgE/DUGMTAXTi68MOCRpwk
H+kz/WNdkqUXWaE+gDipIwLrFOJVqRexGPIf3UuA2QY+C0DZb6tmRnVmhMFhb2b5
fFoKUBqOKXpE1o7uYqS8
=cnk6
-----END PGP SIGNATURE-----


More information about the guardian-dev mailing list