Hi, everyone -- Happy New Year!
I've been thinking about our work on first-party isolation in Tor Browser and I am wondering if Mozilla's Electrolysis project presents a new opportunity.
Currently, we are using a number of isolation patches in Tor Browser: each patch prevents some browser feature (such the HTTP cache or DOM storage) from leaking information between URL bar domains. We're hoping that Mozilla will uplift these patches to mainline Firefox, but it's a very big task [1].
We have also disabled certain stateful features, including SSL Session IDs and TLS session tickets, SPDY, auto form-fill, third-party cookies and third-party HTTP authentication tokens. Disabling these features is straightforward, but somewhat degrades the browsing experience.
Meanwhile, Mozilla has been pursuing the Electrolysis (e10s) project, aka Multiprocess Firefox [2]. The first iteration (already implemented and deployed in Aurora) separates the browser into two processes: one process for chrome and one process for all content. The content process is launched by the chrome process; they are both instances of the `firefox` executable. Mozilla says "In future iterations, we expect to have more than one content process."
So, I'm thinking: could we use the Electrolysis mechanism to use a separate content process for each URL bar domain? In that case, any information in a given content process not explicitly shared with other processes or written to disk would be automatically isolated to the URL bar domain [3]. For example, there could be a separate in-memory cache in each content process.
This approach might have several benefits. It might (a) let us drop most or all of our existing isolation patches (b) permit us to re-enable a number of stateful features, (c) protect against cross-origin tracking attacks we haven't discovered, and (d) allow us to easily implement a "New Identity for this Domain" menu item [4]. I also think Mozilla might find our privacy model easier to adopt if it were implemented this way.
Any thoughts on this idea?
Thanks, Arthur
[1] Things for which we have already written patches for first-party isolation include the HTTP cache, the image cache, blob and media resource URLs, DOM storage, SharedWorkers, OCSP, favicons, and broadcast channels. We may also write further isolation patches for cookies, ServiceWorkers, and HSTS/HPKP, and likely other things. Dave Huseby at Mozilla is currently preparing the ground for attempting to uplift our patches.
[2] https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox
[3] Tor Browser already uses Private Browsing Mode and includes some additional settings and patches to try to prevent anything private from being written to disk.
[4] "New Identify for this Domain", the content process would be shut down and re-started, with a new Tor circuit.
On 2 January 2016 at 18:01, Arthur D. Edelstein arthuredelstein@gmail.com wrote:
So, I'm thinking: could we use the Electrolysis mechanism to use a separate content process for each URL bar domain? In that case, any information in a given content process not explicitly shared with other processes or written to disk would be automatically isolated to the URL bar domain [3]. For example, there could be a separate in-memory cache in each content process.
This may be a naive question but... are these memory stores _in_ the content process? It seems like Mozilla would want to put them in the chrome process for the same reason we want them in the content process - in their case, make things faster by sharing them across processes.
-tom
On Mon, Jan 4, 2016 at 1:11 PM, Tom Ritter tom@ritter.vg wrote:
On 2 January 2016 at 18:01, Arthur D. Edelstein arthuredelstein@gmail.com wrote:
So, I'm thinking: could we use the Electrolysis mechanism to use a separate content process for each URL bar domain? In that case, any information in a given content process not explicitly shared with other processes or written to disk would be automatically isolated to the URL bar domain [3]. For example, there could be a separate in-memory cache in each content process.
This may be a naive question but... are these memory stores _in_ the content process? It seems like Mozilla would want to put them in the chrome process for the same reason we want them in the content process
- in their case, make things faster by sharing them across processes.
It's a good question. I think at the moment they may be in the chrome process. Where memory stores go would presumably need to be part of the discussion with Mozilla. Maybe having the cache in the content process could be an option?
Georg correctly pointed out that 45 ESR is likely to have e10s. So this idea would only potentially apply to TBB/52 ESR.
On 1/4/16 8:51 PM, Arthur D. Edelstein wrote:
It's a good question. I think at the moment they may be in the chrome process. Where memory stores go would presumably need to be part of the discussion with Mozilla. Maybe having the cache in the content process could be an option?
The idea of somehow leveraging the E10s architecture to achieve isolation is an interesting one. We would need quite a bit of cooperation from Mozilla in order to make it work (e.g., per-content process caches) but we could see if they are interested in working with us / heading in a direction that would make this possible.
-
Arthur D. Edelstein -
Mark Smith -
Tom Ritter