Letting users block injected third-party DLLs in Firefox

Unfortunately, the way these third party injected DLL's work, they have full access to all memory within the firefox process. When they go wrong, they can corrupt or change anything, so it is pretty hard to protect against them.

> Chrome has plugins and it rarely crashes with the plugins I typically use.

Chrome doesn't allow 3rd party DLL's either. Chrome plugins run inside the javascript VM.

They made the change 5+ years ago, and it really helped stopping crashes.

I know some people consider proper binary signing difficult on Windows and find the UAC prompts annoying, but those are multi-billion dollar companies, I'm pretty sure they can figure it out.

If anything, Firefox shouldn't be the one doing this, Windows itself should be preventing loading of unsigned/improperly signed DLLs without a UAC prompt.

You'd think they'd only need to hook into Explorer.exe but alas no, they show up in every process. I guess because of the file picker dialog which is an embedded Explorer window running in the host process.

And perhaps a reason why Mozilla wants to hurry and get off of Windows 7.

Then the OS has spoken. Having user space applications pretend to include security barriers that can be easily circumvented is not the way.

> Also that AV is far more apt to be guilty of injecting some bullshit into the process space.

Many AVs have a terrible track record, yes. Perhaps if Mozilla actually cared they should start their own and try to do better? At least it would run as a privileged process and have some chance at success.

They do block some by default, certainly, but only ones which in practice just crash Firefox (often because they are old).

Is there a way to unblock them as easily as blocking them?

Requiring a few hoops - and it sounds like e.g. requiring a developer edition sounds like such a hoop - to ensure a likely misconfiguration was actually intentional and the user is capable of dealing with the consequences is not a bad idea.

In particular, debugging when things go wrong can be an insurmountable task.

Better isolation of software components has been a trend for decades; to the point where I think we can safely say that the old unix and windows model of permissions was a fundamentally insufficient idea. Devs flock to using VMs and containers precisely because uncontrolled interaction between stuff even controlled by the same nominal "user" is a huge pain - and that's before malware and privacy concerns come in.

Were software more isolated by default, and interaction more controlled and/or explicit, then indeed I think the argument against this kind of controlling-the-"user" features would be stronger. But as is? The alternative is clearly much, much worse.

After all, certainly here and often in other cases too - it's not like it's actually impossible to circumvent these restrictions. It's simply technically inconvenient in a way that happens to also prevent many unintentional bugs and some malware vectors.

In an ideal world, a devs for a piece of software would be hard-pressed to even do this, let alone feel the need to do it. But that's just not the world we live in; we're not even really close yet - except on really locked down platforms that go much further than needed to prevent the risks, and into the territory of quite openly restricting the user, not the software.

Why not allow users to decide themselves?