3 ms·

> I doubt firefox will ever focus on security. The security mechanisms we are talking about require breaking compatibility or performance. This isn't the stuf

> 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.

jchw 8y ago
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.
- ddtaylor 8y ago
  His email starts off with this claim: > 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.
  - jchw 8y ago
    To be more particular, though: - 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.
yellowapple 8y ago
"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?".

jchw 8y ago

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.

ddtaylor 8y ago
His email starts off with this claim: > 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.
- jchw 8y ago
  To be more particular, though: - 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.

yellowapple 8y ago

"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?".