Hi,
As part of working on the CT Gossip draft [0] I find myself thinking
about local trust anchors and how they might change browser behaviours.
My understanding is that Tor Browser behaves like Firefox wrt locally
added CA certs. If that's correct, do you know if FF treats pinning the
way the "What Is HPKP For?" post [1] describes it?
Another question that I find interesting is if TB could do better
regarding fingerprintability based on what TLS session the browser
accepts.
[0] https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/
[1] https://noncombatant.org/2015/11/24/what-is-hpkp-for/
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.