On Mon, Jul 20, 2015, at 01:12 PM, Amogh Pradeep wrote:
On Jul 20, 2015, at 12:15 PM, Georg Koppen gk@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.
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.
Otherwise, Amogh and I will work through the Bug 1506 comments.
Thanks!
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@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/torbutto...
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=~...
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 -
Nathan Freitas