I mean, the reason is almost certainly for performance reasons - would've been interesting to see the hit that sandboxing takes here to something like `npm install` (aka something that does lots and lots of file creates / writes)
We just got McAfee installed, and the performance is horrendous on `npm install`. Even something like kicking off headless Chrome to run unit tests now takes 5 mins instead of 30s.
So yes, this is probably a major concern for a product that actually cares about their user's performance.
Get it changed from "scan all files", which humorously scans things like .css and .jpg files for malware, to "scan executable files". This has a huge impact on McAfee's performance, and has for years.
How much wasted money could they save each year by changing this setting? You need to speak their language. If you can legitimately show that it costs 15k per year to have that checkbox on, they will act.
Performance is important when you are scanning all system IO for the "I Love You" virus.
The only sandbox I apply to this "realtime scanning" is to disable it wholesale. Instead of this waste of a Moore cycle Microsoft should add a few more patch days.
"Performance reasons" meanwhile I kid you not when I say that the Antimalware Executable of Microsoft swallows about half my CPU performance when I am downloading, unzipping, executing files. They could have implemented their antivirus in JavaScript and it wouldn't have mattered.
> The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers and cryptors, full system emulators and interpreters for various architectures and languages, and so on. All of this code is accessible to remote attackers.
> NScript is the component of mpengine that evaluates any filesystem or network activity that looks like JavaScript. To be clear, this is an unsandboxed and highly privileged JavaScript interpreter that is used to evaluate untrusted code, by default on all modern Windows systems. This is as surprising as it sounds.
I don't fully understand this - It isn't critical to virus scan files when reading or writing them. It's important to scan them between a write and a read.
That means many written files (which won't be read for a long time) can be scanned hours later.
Others can be checked for matching a "known good" hash whitelist which can be downloaded from the net. That should cover all kinds of files which are parts of software distributions etc.
That leaves very few files which really need real time scanning.
