That’s a good question.

As we should all know by now, delegating antivirus protection to 3rd party corps is a failed experiment, because those AV vendors do not have total control over the OS — this belongs to the OS vendor only (so Microsoft or Apple).*

Preliminary: Only when you know completely how the operating system works can you design an AV that doesn’t risk bricking your system on every update.

Now with the preliminary out of the way, let’s go about seeing how I would’ve done it:

Naturally, with the defensive security model that anti-malware uses today, you cannot completely stop all malware. So the most important priority of the AV would be to reduce the attack surface.

This involves doing stuff like locking down browser settings, control panel settings, restricting programs from using certain syscalls like those that execute new programs, and so on, in addition to the standard virus scanning in sensitive parts of the OS (so not an O(n^2) — space-taking full scan to preserve battery life.

This won’t really work well on Windows because users are responsible for making the application installers in the first place so they could just circumvent these restrictions and put viruses in obscure places. Windows Store is trying to stop that practice but nobody really uses it at all.

But Apple is in a unique position to actually design an efficient AV scanner, because the Mac App Store is gaining traction among the users.

Since they have a long history of killing parts of software and hardware (the SIM card tray, headphone jack, Rosetta, etc…) it would be child’s play for them to kill DMGs as well and centralize app installation at the Mac App Store, just like in i[Pad]OS.

With pesky unknown apps out of the way, Apple would then be able to moderate the apps that do get into the Mac App Store, in order to put a “sandbox” on them. And it doesn’t even have to be a fixed sandbox, it can be a customized one based on the needs of each app.

Example: A photos app does not need to use the internet, so access to networking syscalls and libraries should be shut off.

Or maybe specific software connects to only a single domain for updating itself and licensing — they could simple apply a restrictions profile that lets the app access only that particular site, and shut off its access to all others (including IP addresses).

That is to say the iOS sandbox is not a substitute for this — the sandbox needs to be customized for each app to make it as restricted as possible. This opens the path to scanning binaries and libs on the disk to dangerous code patterns, and those in the memory for dangerous data.

Thinking outside the box always works. Nobody has ever done this before, but that doesn’t mean it’s impossible.

*Appendix: I did not list Linux, as in its current state of development, it’s not possible for any of the corps or groups involve to moderate all the parts of Linux except perhaps for the distribution vendors — but even this is suboptimal because the time taken between reporting the security flaw upstream and a bug fix release being rolled out is prohibitively long, giving malware ample time to spread.