Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?
There are many things that can be done
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.
>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.
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.
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)
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.
Ref: https://labs.vmware.com/vmtj/memory-overcommitment-in-the-es... (search "page sharing")
Should be vulnerable to FFS, if I'm not mistaken: http://arstechnica.com/security/2016/08/new-attack-steals-pr...
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.
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...
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-...
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.
b) hosting some tabs in the same, sandboxed process is still stronger than hosting all of them in the parent process.
So you shouldn't assign too much weight to it.
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.
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?
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.
that said i think firefox's choice is more sensible.