[tbb-dev] Orfox: Porting TorButton to Android

Tue Jul 21 02:03:15 UTC 2015

Nathan Freitas:
> On Mon, Jul 20, 2015, at 01:12 PM, Amogh Pradeep wrote:
> > 
> > > On Jul 20, 2015, at 12:15 PM, Georg Koppen <gk at torproject.org> wrote:
> > > 
> > > Nathan Freitas:
> > >> 
> > >> Amogh and I are trying to figure out the shortest path to getting
> > >> TorButton ported to Android, such that we can have the essential privacy
> > >> features without having to say, port all the XUl/user interface
> > >> components.
> > >> 
> > >> Our plan is to remove all XUL components (for now) since those would
> > >> need to be written for the mobile specific XUL on Android, and they seem
> > >> to be helpful but not absolutely required.
> > > 
> > > I don't think this is true. "New Identity" comes to mind which does not
> > > work if you just remove all XUL related things. Window resizing/Screen
> > > size spoofing is another feature. And there are probably a bunch of
> > > others as well.
> > 
> > The “New Identity” feature can be replaced for mobile, since Orbot
> > handles all the tor connections, I think it would be possible to add this
> > functionality through NetCipher’s OrbotHelper class[0].
> 
> Agreed. For now, Orbot does this, and we don't need to expose it inside
> of Orfox for now.

I think you're missing the difference between Tor's "New Identity" and
Torbutton's "New Identity". Torbutton's "New Identity" does more than
give you a new circuit - it basically performs the equivalent of
Firefox's "Clear Private Data" but covers quite a bit more
tracking-related browser state than Firefox does (especially
killing+closing all tabs).

See torbutton_do_new_identity() in the source:
https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutton.js#n1655

Control port access in general will be useful if you want to display the
current circuit for a site, but for that you also need the domain
isolation code in src/components/domain-isolator.js. The two are
independent though, and you have easily implement SOCKS domain isolation
without any UI or control port access.

> > >>> From there, hopefully all the code here:
> > >> https://gitweb.torproject.org/torbutton.git/tree/src/components
> > >> 
> > >> should work in the mobile context. However, there could be problems
> > >> based on not all of the JS/DOM API being the same. Since we also don't
> > >> run our own instance of Tor within Orfox, none of the control port
> > >> specific JS is relevant.
> > >> 
> > >> If anyone on this list can help us prioritize the JS components to
> > >> required vs nice to have, that would be helpful.
> > > 
> > > See the "Bug 1506 PX" comments where the "X" is in the range of 0-5 (0 =
> > > low prio, 5 = high prio) which got included a while a ago. This is,
> > > however, missing the latest Torbutton improvements. But it might be a
> > > good start and we could use the momentum to categorize the newer code
> > > accordingly as well.
> > 
> > Much of the extra control port JS could be modified to talk to the Java
> > layer which communicates with Orbot which in turn handles these
> > connections. This is a lot of work though, might be a good idea but.
> 
> We must decide which functionality is required or just nice to have.
> Screen size spoofing is complicated because mobile screens are radically
> different and change quite a bit, and inherently you want the screen to
> work with the display, else users will be annoyed. This may be an area
> where we just can't match Tor Browser's anti-fingerprinting features.

The zoom-based approaches in src/chrome/content/content-sizer.js might
help here so that we can use small amounts of zoom to normalize the
effective resolution, but I agree that this isn't top priority,
especially since we're still working out issues with this on the
desktop.

> Otherwise, Amogh and I will work through the Bug 1506 comments.

Here's a couple new things that weren't commented that you probably want
to pick up:

1. src/components/domain-isolator.js - This uses SOCKS username+password
   isolation to ensure that site content elements are isolated by circuit.
   It is important for third party tracking, as this isolation also
   prevents HTTP connection re-use. I think you want this in some form.
   You should be able to just copy most of this component as-is into a
   stripped down addon. Except for using the Torbutton log functions, it is
   standalone.

2. src/components/external-app-blocker.js - This code blocks external
   application launch. Most likely on android this happens via Intents, but
   there's a chance this code will work for that, too. Or you could
   handle Intents via custom Android code. Either way, users should be
   warned before a PDF/DOC is opened in their Android document reader and
   bypasses their Tor settings for content elements. (Related: What
   happens with the Download Manager with Firefox on Android?)

3. torbutton_check_progress() - This function actually resets
   window.name. We should convert this to a C++ patch, but we haven't yet.
   window.name can be used for cross-site communication/storage/XSS on a
   single tab. You might ignore this until we convert it to C++, or help
   us convert it.

4. tor-circuit-display.js - This will be nice to have to show the user
   the current circuit + exit IP address, but a fair amount of work, and will
   require control port support. I would save it for later. It also has
   some issues that we still need to iron out anyway :/.

Here's some existing Bug 1506 commented functions that I think you
should try to implement somehow:

1. torbutton_do_new_identity() and support code - This is very important
   IMO. Long term, we may want to work with Mozilla so that everything
   is handled by Clear Private Data via a single API we can use, but we're
   not there yet.

2. torbutton_set_timezone() - You probably do want to spoof timezone,
   though we could move this code to a native Firefox patch..

3. torbutton_prompt_for_language_preference() and
   torbutton_get_general_useragent_locale() - We spoof our locale to
   English and ask the user at startup. Maybe we want to do this by
   default always for mobile? We certainly shouldn't ask in a popup. :/

The rest of the high-level P comments appear to be control port things
that I agree you can probably skip for an initial release (modulo new
identity concerns).

One of our related deliverables is to convert several of the above items
into direct Firefox patches:
https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb-torbutton-conversion

This is a "Year 2" deliverable for us, so we are not likely to begin
work on those until November at the earliest (and some may be quite
involved), so we should probably figure out an interim strategy for
Android for them.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20150720/d424ba5d/attachment-0001.sig>