Firefox does not have a well-designed privsep model
marc.info
marc.info
They seem to be willing to break compatibility as illustrated by them ditching their massive library of legacy extensions.
He seems to somewhat contradict himself by saying Mozilla won't do things to improve security then describes a security feature they have implemented for JIT that Chrome has yet to provide.
> In a browser, there are 2 main security components you want: The main security advantage is privsep. The other is W^X jit. Other security effects will follow from those design choices, especially if you have privsep. For instance, the chrome privsep is nicely refined and pledge enforcements could be added.
EDIT: Just to be clear I'm not arguing against DEP/W^X but simply appears he is contradicting himself.
- W^X defends against a subset of attacks that privsep defends against.
- Privsep is a bigger architectural impact than W^X. The entire app, almost everything, is impacted by privsep. Only the JIT is impacted by W^X.
So while it is nice that Firefox has been doing W^X, it doesn't mean they're closer to huge steps like Chrome-level privsep of processes. I hope they are, though.
My guess is that Theo's talking less about the XUL → WebExtensions transition and more about breaking compatibility with actual websites (and specifically the Javascript running on / loaded by said websites).
"then describes a security feature they have implemented for JIT that Chrome has yet to provide."
And immediately afterward describes how that security feature is actually implemented in a way that's relatively easy to circumvent (Firefox's JIT uses two "views" around the relevant chunk of memory - one writable, one executable - in order to technically implement W^X for each of those views without actually enforcing it for the underlying memory itself).
That doesn't sound much like self-contradiction to me; that sounds more like preemptively addressing the inevitable argument of "well Firefox does W^X on OpenBSD so it's gotta be more secure than Chrome, right?".
More precisely limited capabilities for content processes, etc, are good but you also just need to write more secure, more stable code and Rust is a great investment towards that. I don't think Firefox needs to go all the way to Chrome's horribly slow 37-million-process-types model. The Chrome approach has significant downsides - any use of the GPU has measurable overhead which turns into higher battery usage (this is the main reason Edge uses less battery on Windows for things like video playback), and their privilege isolation turns cache hits for web content loads from <1ms to 20-60ms because of the multiple RPC trips and context switches necessary to load things out of the cache Because Security. Every decision made in Chrome probably had a reasonable security motivation but I don't think that necessarily justifies turning a page load from 0.5s to 2.0s just to protect against a hypothetical attack.
DISCLAIMER: I got paid to work on Firefox and Chrome, so I have some sort of bias here
Perhaps it's a win in the short-term, a win that maybe Firefox desperately needed to catch-up in performance, but they need to slowly transition away from that to a more secure model, as they start fixing other performance issues and fine-tune the browser more.
He kind of lost me when he said
> I doubt firefox will ever focus on security.
This just seems ridiculous. They just spent years working Firefox into a multiprocess design, in no small part for security. And the same for completely dropping the entrenched extension legacy model (thereby frustrating lots of devs and users). There are other past and current examples where Mozilla is focusing on and improving security in Firefox.
Not everything is fixable with rust. JS, for one, is JIT compiled, so Rust wouldn't help much there (it's one of the reasons it's not being oxidized).
"Also, Rust’s memory safety only applies to code written in Rust, but a JIT compiler also generates machine code and then jumps to it. That generated code does not benefit from rustc’s static analysis."[1]
[1]. https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgra...
There's no way for 8-track to compete with compact cassettes. There's no way for VHS to compete with Betamax. There's no way for C to compete with <insert any language>. Yet, against all odds, technical superiority does not always result in market dominance.
Call me when there's more Rust jobs than C++ jobs, or when they're not entirely posted to Rust mailing lists.
Compile-time memory safety does fsck all when it comes to actual runtime memory safety, especially when it comes to things like JIT compilers (which generate machine code that is not under the same guarantees as the language in which that JIT compiler was written).
Put differently: Rust does not replace pledge. Pledge is a line of defense when Rust's compile-time guarantees are insufficient for whatever reason (e.g. when the program in question is generating machine code on-the-fly, like - again - with JIT compilers).
Even for programs which don't generate and execute machine code during runtime, there's still the possibility for things like rustc bugs, memory corruption (whether on disk or in core, and whether caused by cosmic rays or an attacker deliberately corrupting memory through some other attack vector), etc. that are inherently immune to compiler-level defenses (whether because the compiler is the thing affected, like in the former case, or because the problem happens after the program is compiled, like in the latter case). It also doesn't do much against bugs that have little to do with memory safety (e.g. flaws in authentication/authorization checks, bad DIY crypto, etc.).
Assuming you don't need other safeguards because you're writing your programs in Rust is incredibly naïve, to say the least. Don't get me wrong: Rust is a fantastic step in the right direction, and does eliminate a large swatch of real-world bugs. It ain't a silver bullet, though, and it's unwise to treat it as such.
For example, Chrome sends your browsing habits back to Google who uses that data to "personalize" other services. I think of ads when I see this.
I wouldn't be surprised if using chrome caused google to get data on unreleased projects, corporate networks, and other bits leaked to them. I wonder how they use it.
In any case, you trade one risk for another. Different people are going to evaluate those differently.
I do like more disclosure to help people decide all around.
It’s not a fair fight.
Also, AFAIK Chrome doesn't send anything to Google if you disable corresponding options, I think the only thing that cannot be disabled is sending an unique installation ID when you first install it (so that they can track number of installations). Do you have some data on Chrome doing more than that which cannot be disabled from settings?
My understanding is that statement is false; let's be careful not to mislead people about these issues. And in that spirit, I should make clear that my understanding is based only on the following, not on direct knowledge:
* The ungoogled-chromium project, which aims to remove from Chromium the privacy threats from Google:
https://github.com/Eloston/ungoogled-chromium
A number of features or background services communicate with Google servers despite the absence of an associated Google account or compiled-in Google API keys. Furthermore, the normal build process for Chromium involves running Google's own high-level commands that invoke many scripts and utilities, some of which download and use pre-built binaries provided by Google. Even the final build output includes some pre-built binaries.
* There's also the Inox patchset, with similar aims:
https://github.com/gcarq/inox-patchset
Inox patchset is applied on the chromium source code and tries to prevent data transmission to Google to get a minimal Chromium based browser
* And finally, Iridium, a browser based on Chromium:
Chromium (which Iridium is based on) is a very secure browser, yes. But it does call home to Google and we did even more to enhance security to the maximum extent possible.
His focus on memory security is just his personal bias as a systems engineer writing in C, and this focus alone does not provide a comprehensive comparison.
>W^X ("Write XOR Execute"; spoken as W xor X) is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both.
"privsep" stands for "privilege separation", which is fairly self-explanatory. See https://en.wikipedia.org/wiki/Privilege_separation.
Have different processes / tasks do different things using different privileges.
Example: parsing HTML does not require access to the file system or graphics APIs. So you could parse HTML in a process that is allowed neither. If someone exploits your HTML parser, they can't do much.
If we can treat Chromium like an open source project, maybe we can retire Firefox.
The big "benefit" of webkit is that it is a engine without the whole "browser" thing tagging along.
But the last time i poked at getting gecko to stand on its own, albeit some time ago, it involved grabbing Firefox and giving it some configure (or whatever that python thing that is masking as configure that Mozilla is using these days) options to have it barf out only Gecko.
Or so I remember.
Chromium used to perform visibly better than Firefox with somewhere around one to five tabs open, so sometimes, if I didn't have the browser running and didn't want its full session to load, I've started Chromium just to quickly check one URL - however, recent versions of Firefox made it comparable in such cases, so the only use case for Chromium I have now is to deal with badly coded websites that assume it's the only browser out there.
When you tell me you open thousands of tabs, I wonder if you’re just stress testing the browser. I expect software not to work well when I stress test it.
My common browser usage is to have low hundreds of tabs open - right now it's a bit higher than usual, 1086, although it's not the record. It's just regular browsing, topic research, some social media and stuff left for later. Works well - under Firefox with Tab Center Redux, that is. I've tried switching to Chromium in the past, when Firefox used to be visibly slower, but I've never could use it for longer, always went back to Firefox as Chromium's UX was horrible. With recent versions, I don't even feel the need to check out Chromium ever again.
I'm currently using Chrome on a 4GB system with 10 tabs open with no performance issues or fans screaming. To claim that Chrome is borderline unusable on 8GB of RAM is a lie.
Or maybe people have different standards/expectations?
This includes things like weird rendering bugs, and extra "Chrome-only" features.
Amusingly, as of last week, Chrome Experiments worked fine in Edge and Firefox, but was broken in Chrome. Because of Chrome's opinionated, built in whitelisting for media content forgot to include the Chrome Experiments domain name.
Yikes. It's starting to sound a lot like old IE.
Mozilla, unlike Google, is not hostile to the idea of receiving patches from BSDs.
I love Firefox. I don't want it to retire and why would you want to limit choices for other people?
Also how do you make the case that Chromium can survive without Google continuous investment in Chrome?
Mozilla got money to continue Firefox to give competition. People can say whatever they want but Firefox is a good browser and the company have made many good moves to make the internet a good and open place where as others have attacked it. To tell a company to retire it main product that bring it money is beyond reason. Especially a company that aren't doing any harm to anybody.