Hello,
This will be me beating one of my favorite dead horses about how a TorLauncher extension shouldn't exist at all. Feel free to ignore it, because it doesn't directly pertain to all the API mapping things in the proposal, but if you're going to do a mountain of work, maybe think about fixing the design.
On Wed, 10 Jan 2018 15:10:21 +0000 Matthew Finkel matthew.finkel@gmail.com wrote:
From the mobile/Android perspective, TorLauncher is a strange requirement at this moment. On Android, Orbot controls and configures tor, and external Apps cannot configure tor which is the purpose of TorLauncher. In the future, we may prefer another design and integration, providing a better user experience.
The Android model is closer to being correct than anything involving TorLaucher or Firefox spawning children. Specifically, from the proposal:
Is there a way Tor Browser can further restrict access to a XPCOM service? Firefox's sandboxing makes difficult unprivileged access to internal services, but this risk remains when Tor Browser runs as a single process.
This risk remains until:
* The Firefox process is completely isolated from the tor process.
* The Firefox process does not have external network access or unfettered file system access.
* The Firefox process does not have free reign over absolutely everything the tor process does via the control port.
Eg: `SETCONF ClientTransportPlugin` should terrify people.
As mentioned earlier, sandboxing the controller and process manager into a sandboxed-child process would provide additional assurance the tor process would not reveal private information if a vulnerability is found in the Browser.
I don't think this helps much. It protects Firefox from tor, when they should be isolated and protected from each other. Just from history, the least trusted component in the pile of things that make up Tor Browser, should be the browser.
What are the implications of the browser having access to the full circuit information, including the User's guard?
Probably less bad than the implications of the browser having full control over the Tor process via arbitrary control port commands. As it stands now, by virtue of Tor Launcher needing to exist and function, Firefox has to be able to issue a lot more control port commands than it should be.
Though even with the better model, there's still a laundry list of things the Browser needs to be able to do to work such as setting the user's bridge that can be be abused by malicious entities.
Regards,