One thing that firefox does well is suspend pages you are not using and likely saving the state of the appllication to the disk. Another thing can be for when multiple pages use the same or similar javascript/css/external respurce files, they only need to be loaded once into memory. Another thing canbe that certain javascript globals would only be loaded when the getter asks for them. Something like AudioContext and RTCPeerConnection are not widely used, by changing the name in the global space to a getter that loads the libraries instead of providing them on start may reduce load.

There are many things that can be done

If that's that case I much rather my browser eat up more RAM than needlessly write to my SSD.

A lot of the improvement in the reliability of consumer grade SSDs is due to OS improvements in how they manage their write operations to the hard drive. Windows is considerably more conservative in how it uses it's page file and what does it write off to the SSD, linux has also made a lot of improvements in how it uses the swap partition if it uses it at all, other things like having to be able to suspend the PC in "hibernation" mode without actually having to write a "hibernation" file to disk by keeping the CPU at pretty much an off state but refreshing the ram also saves a lot of day to day write operations especially on mobile devices.

So overall I highly doubt that Firefox went with the suspend to disk route, because if it did it would be a pretty big step backwards.

Also as power conservation goes writing to SSD/HDD is more expensive than writing to RAM and keeping it refreshed, so using the SSD as a storage device instead of the RAM can also have negative effects on the battery life of mobile devices.

While I agree that I would rather my browser use more RAM than constantly suspend pages, I disagree with your notion that

>A lot of the improvement in the reliability of consumer grade SSDs is due to OS improvements in how they manage their write operations to the hard drive.

We're talking on the scale of writing 500gb to your SSD every single day for 10 years in order to reach their endurance limit (on average). Writing a few more gb at worst from your browser is hardly going to affect that. It's even doubtful that OS improvements change it much, as Windows 7, which a lot of people are still on, doesn't come SSD optimized.

last time I checked most SSD come with ~72TB warranty. Go above that and you are sol.

And my $800 phone has a 1 year warranty. What's your point? That warranties should equal how long a device actually lasts on average?

Meh. SSD write amounts matter if you're running a datacenter. They don't matter to a normal user on a laptop/desktop using a browser. SSD lifetime simply isn't an issue, as the other commenter pointed out.

Also, from a more philosophical standpoint - this isn't Mozilla's issue. They shouldn't have to worry about conserving SSD writes. That's not their problem. That's the OS / Disk firmware / manufacturer's problem. If I want to write files to the disk at a very reasonable rate, I should feel free to do that.

> A lot of the improvement in the reliability of consumer grade SSDs is due to OS improvements in how they manage their write operations

Do you have any references for this? I don't think I've ever heard a story of a consumer user running out their writes. Not saying it hasn't happened, but it's not enough of a common occurrence to be a major factor in reliability.

In my experience the overwhelming improvement in reliability is in the firmware of these drivers coming out of the perpetual beta phase (and the death of OCZ)

Yes, that is definitely possible. Chrome isolates data as much as possible between processes. A shared cache would be a big improvement in memory usage, but security is the biggest concern.

Duplicated memory and just overhead from running separate processes (Chrome), as opposed to shared memory and less overhead from a single process (IE? Old FF).

As for security, no, unless there's some unknown vulnerability now (or that they create), that will be ported over and somehow more effective between (potential) processes. So, I doubt it.

Chrome uses separate processes for sandboxing purposes, not just for the fun of it. So yes, protecting against "some unknown vulnerability" is the entire point behind it.

As a fun fact, separate virtual machines running under a VMWare ESXi hypervisor—which is about as "sandboxed" as you can get—still share memory: the hypervisor hashes the 'cold' pages of its VMs and, when it finds duplicate page content either within or between VMs, it merges the duplicated pages together into single copy-on-write pages. ESXi has never had a security vulnerability due to this optimization, AFAIK.

Ref: https://labs.vmware.com/vmtj/memory-overcommitment-in-the-es... (search "page sharing")

> ESXi has never had a security vulnerability due to this optimization, AFAIK.

Should be vulnerable to FFS, if I'm not mistaken: http://arstechnica.com/security/2016/08/new-attack-steals-pr...

True! Rowhammer-based attacks are kind of unique, though; I expect they'll be treated as a hardware bug and solved by releasing better hardware, rather than through inventing even more layers of securinoia to keep in mind from now on.

It's sort of like when WebGL was first getting going, and the GPUs of the time didn't expect to be fed shaders directly from potentially-malicious web sources. Rather than severely restricting the WebGL API, we got a new generation of GPUs that fail safe.

> I expect they'll be treated as a hardware bug and solved by releasing better hardware

When Rowhammer was first announced, people said "it's okay, we have ECC". Then ECC was shown vulnerable. "It's okay, vendors have promised to fix it in DDR4", they said. Now DDR4 is out and vendors have not deployed the fixes systematically[1] and you have to benchmark every single RAM stick to make sure you're not vulnerable.

I'd really appreciate software workarounds as long as hardware vendors keep fucking up.

[1]: http://www.passmark.com/forum/memtest86/5395-rowhammer-mitig...

> Duplicated memory and just overhead from running separate processes

fork(2) does COW. With careful design† forking a new process only results in new and modified pages being not shared.

† Hard! But single-process threads + security is hard too.

http://unix.stackexchange.com/questions/58145/how-does-copy-...

Only on Linux, POSIX does not mandate CoW and Windows does not have a similar API.

While not mandatory, I always sort of assumed BSD and Darwin do the same...

Just wanted to point out that memory usage isn't necessarily inherent to multiprocess, but with a sizable portion of users on Windows the point is practically moot anyway.

a) your security should not rely on process isolation. the javascript engine etc. should be secure in the first place. if you can break out of the JS sandbox you can already attack addon scripts (think password managers)

b) hosting some tabs in the same, sandboxed process is still stronger than hosting all of them in the parent process.

So you mean the interpreter should be mathematically proven like SEL4 and generated from the proof? Otherwise I have no idea what "secure in the first place" means.

My point is that defense in depth is not all that great if the breach of the first line already gives you access to the loot.

So you shouldn't assign too much weight to it.

The point of defense in depth is that you should not rely solely in practice on a single defense element, but you still should strive the hardest when you design it to be sufficient if it was bug free (at least on points where it is possible given the security model, and what the technical item can address).

So splitting everything in sandboxed processes can play a big part in the security in a defense in depth approach. Of course you are not going to call it a day with just that, but still, it's extremely significant.

> extremely significant

How so? Are you saying that simply by being single-process currently firefox is orders of magnitude less secure than other browsers?

And that it would still be orders of magnitude less secure even with sandboxes, where just multiple tabs might share a sandbox?

It is to put approx on the same level as ASLR, DEP, Mandatory Integrity Controls, etc.

From a modeling POV it might actually be better than ASLR, DEP, etc, which are "only" mitigations for which multiple approaches are know to exploit other holes up to arbitrary execution and complete compromises in some cases, even if they are perfectly implemented (in limited conditions), while multiple sandboxed processes can be, at the model level, perfect. In practice (when you add bugs in the picture in all layers, and not just one, and when you actually don't isolate everything like crazy), it is obviously just another tool, but a very significant one (let's drop the "extremely" - it not about being an order of magnitude more "efficient", which would be a very blurry notion anyway -- I mean I guess at one point DEP even alone could maybe be considered orders of magnitude more secure, depending on your precise definition of everything).

What I want to convey about defense in depth is that it is about layering various mechanisms, independent if possible, to protect against various risks, while making the hypothesis that some will fail. You don't casually remove a layer (or pretend that a layer is equivalent to almost none because it does not protect you against one risk in some cases). Defense in depth is actual engineering, like the various safety components in any dangerous system. And the value of sandboxed processes is pretty clear. That it is not a silver bullet does not render it useless.

I thought extensions also mostly ran in their own processes, with messaging access into the tabs? So a password manager would have its critical code in its own process and only access the tab to look for fields to inject into, and hence be protected.

security is multi-layers. You should not rely on either process isolation (ie process sandbox) or logical sandbox or fault-free code...

that said i think firefox's choice is more sensible.