Oof, this is just drama-mongering, made worse by cherrypicking the grumpiest thing from the email to put in the title. Not much point bringing that drama for a re-warming here.
We've updated the title from ‘Theo de Raadt on Firefox security: “all I see is lipstick on a pig”’. We'd rather use a representative phrase from the message, if someone can suggest one.
Would love to see an official response. Mozilla has worked hard at adding multi-process, and improving security all over the place, such as at the level of internet protocols and infrastructure.
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.
> I doubt firefox will ever focus on security. The security mechanisms we
are talking about require breaking compatibility or performance. This
isn't the stuff one rearranges deck chairs for.
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.
W^X is simply the idea that code segments are either writable or executable, never both simultaneously. It does limit some attack surface area. That being said, while it'd be a welcome addition to V8, it almost definitely would come with some performance cost and a complexity increase, whereas Chrome has focused on sandboxing the JIT in such a way that gaining access to the JIT would not get you very far. So, while layered security is almost never a bad thing, I think that it's possible this trade-off is not a terrible one for Chrome security.
> 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.
"They seem to be willing to break compatibility as illustrated by them ditching their massive library of legacy extensions."
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?".
Moving a lot of critical code to a memory safe language will be a cool advantage for Firefox, performance benefits aside. That being said, I think it's easy enough to see why Chrome may have a lead given that it indeed was designed to be secure from the get-go. I hope Theo is wrong here, and that things are getting closer, but I guess time will tell.
Yes, I think rewriting Firefox core components in Rust should give Firefox an edge in some areas, but I still think Mozilla made was wrong to go with its "hybrid" approach for its multi-process architecture.
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.
> I hope Theo is wrong here, and that things are getting closer,
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.
>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.
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.
Chromium is an open source project, and we should treat it like one. Google paid for most of its development, but were able to pay many open source developers less because they were excited about working on an open source project (see the thread about compensation on today's Ask HN post about working for startups). Ditto for Android. Nobody should be shy about forking these projects. We don't owe Google for them, beyond what the license says. Fair is fair.
If we can treat Chromium like an open source project, maybe we can retire Firefox.
IF that was true, then perhaps more effort should be directed towards making Gecko a drop in engine?
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.
It definitely does. Chrome is borderline unusable on 8GB RAM - more than a few tabs open make it go into swap hell, while Firefox works well with thousands (Chrome doesn't even have the concept of unloading open tabs!). Also, you can't even disable tab shrinking in Chrome, let alone move tabs to the left border of the window, as I do with Firefox. This results in an UI that's practically unusable with the only way to navigate the tabs being the mouse wheel.
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.
I’m sure they have telemetry and know that almost nobody leaves hundreds of tabs open.
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.
I'm sure nobody leaves them open with Chromium as it's impossible.
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 think this is dependent on many factors. Right now I'm on a laptop with 8GB of RAM, I have a VMWare VM running locally taking up 3GB of RAM, and Chrome with 6 tabs open. Yes, I'm getting near swap territory, but everything is cruising along nicely...
>Chrome is borderline unusable on 8GB RAM - more than a few tabs open make it go into swap hell,
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.
It would still be terrible for the web, as a standard, to have less diversity. Chrome+chromium barely count as diversity since the standard-related code (rendering, js engine, layout, etc) is identical.
That, and Chrome tends to make some hardline, opinionated changes that aren't reciprocated by other browsers. "It works in Edge and Firefox, but it's broken in Chrome" is a a fairly common thing to hear where I work.
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.
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.
I'm exaggerating by saying "retire". I don't mean getting rid of it - major open source projects always live on. If things are as dire as this article, my experience trying to switch back to Firefox, and the "Through the Looking Glass" adware extension debacle suggest, a solid independent open source alternative could allow it to keep going where it unfortunately seems to be headed.
Firefox team has been making tons of effort for prolonged periods of time. I'd be extremely fond of them focusing on having a proper privsep model now.
As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, and while there will be continued utility pledge() is pretty quaint versus memory safety.
>As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust,
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]
> There's simply no way for C++ to compete with Rust
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.
They're not talking about popularity of the language. They're talking about two particular pieces of software, and which one will be ahead of the other based on the choice of implementation language.
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.
Frankly the idea of consumers making informed choice is hogwash from end to end. Either we do so on whims, or we pick whatever is in front of us because we can't go another day without. Neither allows for "informed" decisions in the sense the economics textbooks present.
Even if we study: I can only devote X hours per product while your average company has one or several full time company that know the market much better than I do and are also probably working on way to trick me, one way or another.
You can always use Chromium (premade build or make your own build), get the benefits of Chrome's security without the potential tracking.
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?
> You can always use Chromium (premade build or make your own build), get the benefits of Chrome's security without the potential tracking.
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:
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:
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.
Privsep is useful but I'm not sure I buy the argument that Firefox needs to go all in on it to be secure. Despite Chrome's engineering approach people still managed to privilege escalate all the way from their webassembly decoder (insecure C++) all the way to persistent root on Chromebooks, due to fundamental security engineering failures (multiple) that no amount of privilege separation could stop.
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
58 comments
[ 141 ms ] story [ 193 ms ] threadHis 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.
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?".
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.
>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.
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:
https://iridiumbrowser.de/
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.
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