I think we can lower the risk of these kinds of attacks a lot by reducing the amount of "dangerous" code that runs on devices. There are several ways to do thi

I think we can lower the risk of these kinds of attacks a lot by reducing the amount of "dangerous" code that runs on devices. There are several ways to do this: run stripped-down embedded OSes and software that only have the bare minimum functionality they need to do what they do, transition as much C/C++ code as possible to Rust, Haskell, Agda, or whatever other higher level language is suitable to the requirements of the application, and use containers/capabilities/sandboxes to restrict potentially unsafe code from interacting with the rest of the system in ways that aren't absolutely necessary to the application. So, we do have some technical solutions that could greatly reduce the risk. I think the main barriers preventing these techniques from being used as widely as they should right now are that 1) secure and insecure products are basically indistinguishable to consumers, so there is little economic incentive on the part of product manufacturers to ensure their products are secure, 2) we have an entrenched programmer culture (especially in systems programming) that thinks the solution is to "be more careful" and "don't hire dumb programmers", and 3) we have a whole lot of really complicated C and C++ programs that work really well and people are happy with them whereas if you want to ship a product with, say, all of the code from the OS up written in Rust, you're sort of blazing your own trail and you'll have to write a lot of it yourself.