Considering how many odd state issues I see these days (more often in Angular 1.x apps than anything else), don't underestimate the potential for problems there.
Already learned the joy of waiting for a Surface to drain, to force a reboot. Forbidding shutdown/reboot without authentication on the network was the proximate cause of the wait. But not being able to remove power, from a device that was not trusted, and could be doing anything in theory, was a sobering thought.
Should devices like tablets, with enclosed batteries, be required to have physical circuit breakers for power, as a security measure, if compromised?
We realized that we had to have a planned action to block MACs from the network, in response to any device having questionable integrity.
Even a small Faraday cage was considered - WiFi not the only radio on portables: laptops without removable batteries hop across LTE via VPN... so that was another policy to set a script to shut down.
Persistence, in this case of processes - or just not being able to remove a battery - is a threat that with good reason shocked us, because it is so ubiquitous. I believe the moment a unscheduled reboot or shutdown occurs, at the very least all LAN/WAN access needs to be automatically cut.
Won't OS just have a service to 0 out all the RAM, definitely on shutdown for security reasons, with a performance hit in time and write cycles on your sdd. Same mechanism at boot?
That assumes that the OS didn't crash. It also assumes that the data isn't valuable, in which case why not just use faster, cheaper ram?
There are workarounds, like adding a layer of faster, cheaper ram, but then this starts to look like a big perf improvement in a rather traditional system.
