Just in time v Just in case
Although the problem isn’t as bad now as it has been, a lot of software runs on your computers just in case it might be needed. Often it isn’t, and sometimes the PC is shut down or rebooted without it ever having been used. This wastes our time, wastes a little energy, and potentially adds functionality or weaknesses that can be exploited by hackers.
If it only loaded the essential pieces of software, risks would be minimised and initial delays reduced. There would be a slightly bigger delay once the code is needed because it would have to load then but since a lot of code is rarely used, the overall result would still be a big win. This would improve security and reliability. If all I am doing today is typing and checking occasional emails, a lot of the software currently loaded in my PC memory is not needed. I don’t even need a firewall running all the time if network access is disabled in between my email checks. If networking and firewall is started when I want to check email or start browsing, and then all network access is disabled after I have checked, then security would be a bit better. I also don’t need all the fancy facilities in Office when all I am doing is typing. I definitely don’t want any part of Office to use any kind of networking in either direction for any reason (I use Thunderbird, not Outlook for email). So don’t load the code yet; I don’t want it running; it only adds risks, not benefits. If I want to do something fancy in a few weeks time, load the code then. If I want to look up a word in a dictionary or check a hyperlink, I could launch a browser and copy and paste it. Why do anything until asked? Forget doing stuff just in case it might occasionally generate a tiny time saving. Just in time is far safer and better than just in case.
So, an ultra-simple computer should only load what is needed, when it is needed. It would only open communications when needed, and then only to the specific destination required. That frees up processors and memory, reduces risks and improves speed.
Storing software on hard disks or in memory lets the files be changed, possibly by a virus. Suppose instead that software were to be distributed on ROM chips. They can be very cheap, so why not? No apps, no downloads. All the software on your machine would be in read only memory, essentially part of the hardware. This would change a few things in computer design. First, you’d have a board with lots of nice slots in it, into which you plug the memory chips you’ve bought with the programs you want on them. (I’ll get to tablets and phones later, obviously a slightly different approach is needed for portable devices). Manufacturers would have a huge interest in checking their code first, because they can’t put fixes out later except on replacement chips. Updating the software to a new version would simply mean inserting a new chip. Secondly, since the chips are read only, the software on them cannot be corrupted. There is no mechanism by which a virus or other malware could get onto the chip.
Apps could be distributed in collections – lifestyle or business collections. You could buy subscriptions to app agencies that issued regular chips with their baskets of apps on them. Or you could access apps online via the cloud. Your machine would stay clean.
It could go further. As well as memory chips, modules could include processing, controller or sensory capabilities. Main processing may still be in the main part of the computer but specialist capabilities could be added in this way.
So, what about tablets and phones? Obviously you can’t plug lots of extra chips into slots in those because it would be too cumbersome to make them with lots of slots to do so. One approach would be to use your PC or laptop to store and keep up to date a single storage chip that goes into your tablet or phone. It could use a re-programmable ROM that can’t be tampered with by your tablet. All your apps would live on it, but it would be made clean and fresh every day. Tablets could have a simple slot to insert that single chip, just as a few already do for extra memory.
If your computer is based on algorithms encoded on read only memory chips or better still, directly as hardware circuits, then it could boot from cold very fast, and would be clean of any malware. To be useful, it would need a decent amount of working memory too, and of course that could provide a short term residence for malware, but a restart would clean it all away. That provides a computer that can easily be reset to a clean state and work properly again right away.
Another layer of defense is to disallow programs access to things they don’t need. You don’t open every door and window in your home every time you want to go in or out. Why open every possible entrance that your office automation package might ever want to use just because you want to type an article? Why open the ability to remotely install or run programs on your computer without your knowledge and consent just because you want to read a news article or look at a cute kitten video? Yet we have accepted such appallingly bad practice from the web browser developers because we have had no choice. It seems that the developers’ desires to provide open windows to anyone that wants to use them outweighs the users’ desires for basic security common sense. So the next layer of defense is really pretty obvious. We want a browser that doesn’t open doors and windows until we explicitly tell it to, and even then it checks everything that tries to get through.
It may still be that you occasionally want to run software from a website, maybe to play a game. Another layer of defense that could help then is to restrict remote executables to a limited range of commands with limited scope. It is also easy additionally to arrange a sandbox where code can run but can’t influence anything outside the sandbox. For example, there is no reason a game would need to inspect files on your computer apart from stored games or game-related files. Creating a sandbox that can run a large range of agreed functions to enable games or other remote applications but is sealed from anything else on the computer would enable remote benign executables without compromising security. Even if they were less safe, confining activity to the sandbox allows the machine to be sterilized by sweeping that area and doesn’t necessitate a full reset. Even without the sandbox, knowing the full capability of the range of permitted commands enables damage limitation and precision cleaning. The range of commands should be created with the end user as priority, letting them do what they want with the lowest danger. It should not be created with application writers as top priority since that is where the security risk arises. Not all potential application writers are benign and many want to exploit or harm the end user for their own purposes. Everyone in IT really ought to know that and should never forget it for a minute and it really shouldn’t need to be said.