
Firefox does not have a well-designed privsep model - bigato
https://marc.info/?l=openbsd-misc&m=152872551609819&w=2
======
ddtaylor
> 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
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
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
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.

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

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

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

~~~
sp332
I don't know why you're getting downvoted since that's literally their
roadmap.
[https://bugzilla.mozilla.org/show_bug.cgi?id=1432593](https://bugzilla.mozilla.org/show_bug.cgi?id=1432593)
In addition to separating sites, they're breaking services out into their own
processes, like moving all network access to a separate process
[https://bugzilla.mozilla.org/show_bug.cgi?id=1322426](https://bugzilla.mozilla.org/show_bug.cgi?id=1322426)

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

~~~
taborj
Doesn't every email explaining the current state of <insert item here> become
more and more obsolete over time?

~~~
hundchenkatze
Not if <inserted item>'s state stops changing. :)

~~~
taborj
A good point

------
mfer
We, the consumers, have to make trade-offs.

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.

~~~
MBCook
Consumers are not in a position to make informed choices about the security
implications of the way a browser is implemented.

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

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

It’s not a fair fight.

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

~~~
cjhopman
privsep isn't "memory security".

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

------
acobster
privsep? W^X? Can someone post a link or two? :)

~~~
faho
[https://en.wikipedia.org/wiki/W%5EX](https://en.wikipedia.org/wiki/W%5EX):

>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](https://en.wikipedia.org/wiki/Privilege_separation).

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

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

------
noelwelsh
Famously outspoken developer is mildly outspoken? I am shocked!

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

~~~
jacob019
Some of us love Firefox and do not want webkit hegemony, even if it is open
source.

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

~~~
genghizkhan
I think they're working on servo for that. It'll be able to be dropped in
place of Chromium: it'll support the same API.

Or so I remember.

