> I know people really dislike how Apple restricts your freedom to use their software in any way they don't intend. But this is one of the times where they shine.

Yes, the problem here is that the system owners had too much control over their systems.

No, no, that's the EXACT OPPOSITE of what happened. The problem is Crowdstrike had too much control of systems -- arguing that we should instead give that control to Apple is just swapping out who's holding the gun.

> arguing that we should instead give that control to Apple is just swapping out who's holding the gun.

apple wrote the OS, in this scenario they're already holding a nuke, and getting the gun out of crowdstrike's hands is in fact a win.

it is self-evident that 300 countries having nukes is less safe than 5 countries having them. Getting nukes (kernel modules) out of the hands of randos is a good thing even if the OS vendor still has kernel access (which they couldn't possibly not have) and might have problems of their own. IDK why that's even worthy of having to be stated.

don't let the perfect be the enemy of the good, incremental improvements in the state of things is still improvement. there is a silly amount of black-and-white thinking around "popular" targets like apple and nvidia (see: anything to do with the open-firmware-driver) etc.

"sure google is taking all your personal data and using it to target ads to your web searches, but apple also has sponsored/promoted apps in the app store!" is a similarly trite level of discourse that is nonetheless tolerated when it's targeted at the right brand.

Perfectly stated!

This is good nuance to add to the conversation, thanks.

I think in most cases you have to trust some group of parties. As an individual you likely don't have enough time and expertise to fully validate everything that runs on your hardware.

Do you trust the OSS community, hardware vendors, OS vendors like IBM, Apple, M$, do you trust third party vendors like Crowdstrike?

For me, I prefer to minimize the number of parties I have to trust, and my trust is based on historical track record. I don't mind paying and giving up functionality.

Even if you've trusted too many people, and been burned, we should design our systems such that you can revoke that trust after the fact and become un-burned.

Having to boot into safe mode and remove the file is a pretty clumsy remediation. Better would be to boot into some kind of trust-management interface and distrust cloudstrike updates dated after July 17, then rebuild your system accordingly (this wouldn't be difficult to implement with nix).

Of course you can only benefit from that approach if you trust the end user a bit more than we typically do. Physical access should always be enough to access the trust management interface, anything else is just another vector for spooky action at a distance.

It is some mix of priorities along the frontier, with Apple being on the significantly controlling end such that I wouldn't want to bother. Your trust should also be based on prediction, and giving a major company even more control over what your systems are allowed to do has been historically bad and only gets worse. Even if Apple is properly ethical now (I'm skeptical, I think they've found a decently sized niche and that most of their users wouldn't drop them even if they moved to significantly higher levels of telemetry, due to being a status good in part), there's little reason to give them that power in perpetuity. Removing that control when it is absued hasn't gone well in the past.

Microsoft is also trying to make drivers and similar safer with HVCI, WDAC, ELAM and similar efforts.

But given how a large part of their moat is backwards compatibility, very few of those things are the default and even then probably wouldn't have prevented this scenario.

Microsoft has routinely changed the display driver model, breaking backward compatibility. They've also barred print drivers.

> large part of their moat is backwards compatibility

This is more of a religious belief than truth, IMO. They could strong-arm recalcitrant customers, but they don't.

> They could strong-arm recalcitrant customers, but they don't.

They really can't. When the customers have to redo their stack, they might do that in a way that doesn't need Microsoft at all.

These customers wouldn't be able to do that in time frames measured in anything but decades and/or they would risk going bankrupt attempting to switch.

Microsoft has far more leverage than they choose to exert, for various reasons.

I can't run a 10year old game on my Mac but i can run a 30 year old game on my windows 11 box. Microsoft prioritizes backwards compatibility for older software,

You can’t run a 30 year old driver in Windows, nor a 10 year old in all likelihood.

Microsoft prioritizes userspace compatibility, but their driver models have changed (relatively) frequently.

If you are a Crowdstrike customer you can’t run anything today.

For apple you just need to be an apple customer, they do a good job on crashing computers with their OSX updates like Sonoma. I remember my first macbook pro retina couldn’t go to sleep because it wouldn’t wake up till apple decided to release a fix for it. Good thing they don’t make server OSes.

I remember fearing every OSX update because until they switched to just shipping read-only partition images you had considerable chance of hitting a bug in Installer.app that resulted in infinite loop... (the bug existed since ~10.6 until they switched to image-based updates...)

30 years ago would be 1994. Were there any 32-bit Windows games in 1994 other than the version of FreeCell included with Win32s?

16-bit games (for DOS or Windows) won't run natively under Windows 11 because there's no 32-bit version of Windows 11 and switching a 64-bit CPU back to legacy mode to get access to the 16-bit execution modes is painful.

Maybe. Have you tried? 30 year old games often did not implement delta timing, so they advance ridiculously fast on modern processors. Or the games required a memory mode not supported by modern Windows (see real mode, expanded memory, protected mode), requiring DOSBox or other emulator to run today.

DOSBox runs on Mac too, incidentally.

A 10 year old driver would crash your system, and you can't install some VM like you can with some game. Not that great prioritization

If the user want remote code execution (auto updates are) in kernel space, let them.

Apple sell the whole hardware stack. I don't think limeting drivers would fly on Windows or Linux.

Pretty sure there's an exception for drivers but requires at minimum notarisation from Apple, but more likely a review as well.

They just developed a new framework that allows drivers to work just in user space https://developer.apple.com/documentation/driverkit

Well - recognition where it's due - that actually looks pretty great. (Assuming that, contrary to prior behavior, they actually support it, and fix bugs without breaking backwards compatibility every release, and don't keep swapping it out for newer frameworks, etc etc)

Ok what if they sold it off by default but there was a physical switch that could turn it on, that required hardware access?

Good compromise?

That’s exactly how macOS works (except it’s not a physical switch). You can disable SIP if you have hardware access to a machine.

I would be fine with jumpers, ye.