A Chrome developer's challenges
One of the biggest causes of instability on Windows is malware that mucks with Chrome's data on disk and tries to inject itself into Chrome processes. Shocking numbers of users have malware. The majority have no idea and blame Chrome when it's slow and crashy.
Peter Kasting at G+
That and buggy video drivers on OSX.
Seems to me that incentivising a free-for-all resource competition brawl apps ecosystem might not be the Best Thing Evar.
Evolutionary systems evolve toward what their environments reward, and require. Be careful what you incentivise for, you're likely to get it.
I ... tend to have sharp differences of opinion with Mr. Kasting on numerous points, not all regarding software (and was swinging by his profile to share some thoughts in that regard). But his comment on the hazards of the Windows dev environment are telling. It also gives me some respect for what Google are doing on Android, where applications tend to be sandboxed away from one another (though are also far too frequently given free reign to dip their paws in user-data troves).
The approach on Linux systems has been to have a central packaging (and, effectively, vetting) authority over software development. This isn't perfect either, but seems to work fairly well, and also tends to keep application proliferation for the sake of application proliferation somewhat in check. Why have 10,000 versions of a basic text editor if a mere ... 175 or so (seriously, I just counted) will do. That's Debian packages matching the search string "text editor", though it includes some duplicate and ancillary packages.
For the Google Play store, I get nearly 260 applications matching the same string (and can't simply run the output through
wc -l to get a line count, to boot). I believe there are over 2 million application in the store total.
As I've asked before: how is the user supposed to meaningfully search through and identify what's best or suitable from all that?
And, from the applications developer perspective, isn't sabotaging other applications, by whatever means necessary, a winning strategy? Even if you happen to do that inadvertantly?
After all, evolution is not teleological. In wetware or software.
How can software defend itself?
Supposing you were the producer of some large, widely-used, and vulnerable software application. What are your options?
Keep in mind that your adversary is other programs running under the sam account as yourself. That is, we've reached a situation, at least within the Microsoft Windows platform, if not elsewhere, where programs must consider other applications of the same user as potentially hostile. Extensions of trust are ... difficult.
(We'd crossed this Rubicon in the 1980s and 1990s when the concepts of cooperative memory allocation and microtasking proved flawed. Then the solutions were protected memory modes and kernel-allocated CPU timeslices, though things can still go wibbly when other resources are allocated. The issue now is disk state, rather than memory.)
You could attempt to create integrity tests within your own application, checking to see if disk contents are what they claimed to be. One of the useful properties of a Web browser is that much of that state is recoverable from original sources.
You could go into surveillance mode, and watch for (and tattle on) applications that muck with your stuff.
... Or attack them directly. Yay! Application-on-application warfare!
You could go into the antivirus / security space yourself and provide a utility that offered protections others aren't. This seems a longish game....
You could partner with existing AV vendors to up their longish game.
You could opt for a multi-user or similar application model, where the bulk of your application runs in a dedicated user-space and only a small stub is within the original (and presumably tainted) user environment. This may be where computing is generally headed.
You could wrap yourself in a VM, a'la Java or other tools. The general problem with this approach is that VMs operate at the mercy of the host OS, so you haven't done much to alleviate the more general problem.
You could work with the OS vendor to provide better inter-application robustness and/or security. Again, possibly where we're going anyway.
You could develop your own OS with much more stringent application-level isolation. Which also seems to be in process.
I suspect there's a growing literature on this field somewhere....