and get instant process isolation and protection from these kinds of exploits.
Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowledge that), what it does technology-wise is an improvement for security.
The new Firejail app [1] may be worth exploring as it is designed to run locally installed apps like browsers and games in sandboxes, as opposed to more chroot oriented container managers like LXC, Docker or Nspawn. They all use namespaces.
If you want to use a chroot oriented container manager its better to use an unprivileged container so you are not running as root. Currently only LXC has support for unprivileged containers. We have an experimental GUI app container with Chrome that can be used in unprivileged mode. [2]
You can even run your own sandbox with a simple command like this 'unshare -fp --mount-proc' That gives you a bash shell in its own pid space. You can expand this command further to use more namespaces like mount, net, user to get yourself a sandbox.
That is what apps like firejail and container managers are using, but its useful to know what's happening underneath. We are currently working on a guide on how to use unshare that may help. [3]
Actually, the nature of this vulnerability would prevent any attacks against docker
>> The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.
Moreover, since it seems you believe that javascript is a liability in this case (as much as I loathe the language: it's not!)
be aware that you still need to interpret javascript to read all of the pdfs you can find: