> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs Tha

> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs That’s not really how the software/OS relationship works. By default OS’s run software in very unprivileged CPU security contexts, where they can’t really do anything beyond but operate on memory the OS allocated to the software, with CPU instructions can’t talk directly to other hardware, or read/write memory beyond the bounds the OS specified. To do literally anything else, like open a file, write to a file, talk to a network interface, talk directly to other hardware connected to the CPU. The software needs to use a syscall, and effectively ask the OS to perform the operation on its behalf. Every single dangerous operation you can perform is guarded by the OS, the OS doesn’t validate anything, it simply decides to perform the operations requested, or it decides not to perform those operations. The only reason why software expects so much unfettered access to a system is simply because OS have historical not limited what software was allowed to do, OS’s simply performed whatever operation was requested of them without question. It only in the last 20 years or so that security became a concern, and it occurred to us that allowing software to just do whatever it wants is probably a bad idea. But the genie is out of the bottle, and it’s proving hard to put it back in. So retroactive work to limit what software can do by default, without simply breaking everything, is slow and difficult. If you ever want to understand why you can do somethings on MacOS, but not iOS, then this is a pretty good place to start (if we ignore Apple’s brand and commercial reasons for a moment). iOS only ever supported tightly sandboxed apps, that had to play nice with a draconian permissions system, where as MacOS is more standard OS, that was originally developed in the age before security was really a concern. So it’s easy to enforce tight sandboxing on iOS, where software has always had to deal with it, but hard on MacOS, where for the majority of MacOS history, sandboxing simply didn’t exist. > rather than a source-based approach in which malware is never allowed to touch the processor. That’s a nice idea, but doesn’t really hold up to scrutiny. You need to look at the ever increasing number of supply chain attacks to realise that simply being open source does little to ensure malware doesn’t make it onto your machine. And that before we get into issues like heart bleed, where the OSS software on your machine may contain bugs or errors that allow remote parties to gain access to privileged data or credentials, via OSS software that isn’t malware, it just got bugs in it. At the end of the day, it doesn’t really matter what magical security boundaries you develop, someone will find a way around it. Which is why defence in depth is such an important principle. Simply relying on the idea that Open Source means no malware is foolish. You need proper OS defences regardless.