It seems like the HN submission form truncated the # from the end of the URL I linked to, which linked to the relevant comment. I'll try that here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c82
and
I think its a growing issue, as they mature/migrate their older code base, issues become less frequent.
> > I would also like to add that this high CPU usage issue while using Firefox is not exclusive to Microsoft Defender. It's an issue for Norton's AV products also and should be the same for Symantec Endpoint products too.
> > So, you should also test them.
> It is true that we should analyze the situation with other AV vendors, however, given the numbers shared above, and given how relevant it is to keep track of memory protection changes in order to detect malicious behavior, it is very likely that the explanation for Windows Defender also applies (at least in part) to other AV vendors.
Can we get edit on the title?
It also has a bug(?) which makes method calls 100x slower in PowerShell 7:
I may have some of the details wrong.
https://source.chromium.org/chromium/_/chromium/v8/v8.git/+/...
I love thinking about the impacts of tiny improvements at scale like this, might do some napkin math on it later and see if I can come up with something in the right order of magnitude.
- require admin rights (which means that if they have vulnerabilities, it can take control of the entire machine, even if Firefox itself is sanboxed);
- monkey-patch the Firefox executable in memory, which works (when it does) as long as the version of the software tracks closely the version of Firefox, which may or may not be the case;
- ... and also decreases the memory-safety of Firefox, which makes it easier to pwn;
- ... and also makes the crash reports unreliable;
- install encryption certificates that are actually less trustworthy than Mozilla's, hence decreasing the security of https;
- block Firefox and add-on security updates, also decreasing security;
- install privileged add-ons, many of which are easy to exploit from any webpage;
- ...
Part of the work on Crash Scene Investigations was attempting to determine whether the crash was in Firefox or in code or in some bogus foreign code. Depressingly often, it was the latter.
In your case, it's entirely possible that malwarebytes was simply untested on Firefox.
I'm not so sure that running lights isn't a net positive, especially with the introduction of LED lights.
This one was a frustratingly common cause of crashes when I worked in gamedev. So many crashes would end up being some overlay or antivirus monkeying about with memory.
This has long been a leaky part of Windows security. If your malware can get its code running inside a highly privileged service or process, it can do more or less whatever it wants to the rest of the system. But even when not used for nefarious purposes, it is still an extremely dangerous capability in that it can be very easy to create problems .
Now that you raised it however, even if the system call used to be fast, Firefox is making an extremely high number of calls to that sytem call, and there's always going to be some overhead to that. There are almost certainly ways that Firefox could reduce the number of calls it needs to make.
https://learn.microsoft.com/en-us/windows/win32/procthread/p...
...and DRM.
Makes me wonder: Does windows Defender just double as another deliberate NSA backdoor?
The same is valid for Apple, Google, and every other US company.
Recent versions of Firefox allow you to block some stuff like that: https://support.mozilla.org/en-US/kb/identify-problems-third...
Though it's possible they use different code injection tricks to make blocking impossible. (You can't block Defender from listening to events for example)
Given that in many industries insurances and, in some cases like banking, the law requires companies to monitor HTTPS traffic of browsers for compliance, it might be better if browsers had a dedicated filter / monitor API.
Whether this provides any meaningful security is questionable unless you pair it with filesystem isolation to prevent malicious programs from modifying config files / bashrc / etc. Meanwhile it does make legit uses of ptrace more annoying.
[0] https://www.kernel.org/doc/Documentation/security/Yama.txt
Send a bug report to a five-person software company, their lead dev contacts you the same day and has a patched version ready to go in a week. Send a bug report to Microsoft / Citrix / Apple / etc, and you'll never hear back.
Firefox itself is at 4-5% and the whole machine is at 14%
Normal Firefox was also fine last I used it.
A shockingly large number of crashes and performance issues in PC gaming are related to poorly behaved overlay programs and overclocking tools like RivaTuner, Overwolf, and the Discord Overlay. I'd well believe your points.