That means "make it easy to use" should change to "make it easy to use safety". Yet the level of knowledge needed to use the PC is way lower than skills needed to use it safely, and IMO it borders on criminal negligence to deepen that trend. That's like making handguns lighter with less trigger pull required so that toddlers could use them "more easily".
To use a PC...
...you need to know how to press a button, click one of two mouse buttons, and familiarity with the alphabet so you can type. It's useful to know about "folders", but Vista seeks to remove even that semi-requirement. If you can click what you see, you can use the PC.
To use a PC safely...
...you need to know about file types and the levels of risk they represent, and that information is hidden from you by default. In fact, the UI that makes things "so easy" does nothing to help you assess risk, nor is it constrained to act within the risk indicators it displays.
You also need an unhealthy amount of de-spin and paranoia. Almost everything you see has to be reversed through the mirror of suspicion; "value" isn't, "free" can gouge you, "click to unsubscribe" means "don't click else you'll get more spam", and so on. The endless cynicism and lies can be damaging to the psyche, and I often wonder if usability studies into UI stress ever take this factor into account.
What we need to know
You wouldn't dream of wiring house so that it wasn't possible to know what sockets and wires were "live" or not, nor would you make firearms such that it was impossible to tell if they were loaded or not, had the safety catch on or not, or which way they were pointing.
So why do we accept computers that use the meaningless term "open" that hides what a file can do when used? Why do we use an interface that makes no distinction between what is on our PC and what is from some arbitrary system out on the 'net?
The basic things we need to know at all times are:
- Whether a file is "code" or "data"
- Whether something is on our PC or from outside the PC
- Where we are in the file system
As owners of our own PCs, we have the right to whatever we like with any file on our systems. We may not expect that right when we use our employer's PC at the workplace, but at home, there is no-one who should override our control.
History
In the old days of DOS, you had to know more to use a PC, but beyond that, all you needed to know was not to run files with names ending in .exe, .com or .bat or boot off strange disks. Hidden files weren't that hidden, and it was quite easy to manage risky files because they wouldn't be run unless triggered from one of two editable files. Only when viruses injected themselves into existing code files or boot code, did one need antivirus tools to clean up.
The first safety failure was loss of the data/code distinction, when Windows 95 hid file name extensions by default, and when MS Office applications started auto-running macros within "data" files. Windows 95 also hid hidden files, as well as where you were in the file system.
The second safety failure was when Internet Explorer 4 shell integration blurred the distinction between what was on your PC and what was not. Local material was often presented in a web-like way, while the local file browser could seamlessly display off-PC content. The new web standards also allowed web sites to spawn dialog boxes that looked as if they were part of the local system, as well as drop and run code on visitors' computers.
The third safety failure includes all mechanisms whereby code can run without user consent; from CDs that autorun when inserted, to code that gropes inside file content when all we wanted was to see a list of files, to "network services" that allow any entity on the Internet to silently initiate a machine dialog, as exploited by the Slammer, Lovesan and Sasser generations.
The fourth safety failure will be a loss of awareness as to where we are within the file system. As long as different files in different parts of the file system can present themselves as being "the same", we need to know the full and unambiguous path to a file to know which it is.
Vista
Vista tries to make computing easier by dumbing down "where things are", but makes "safe hex" as difficult as ever. File name extensions and paths are still hidden, as are hidden files and ADS. You still need to know an arcane list of file name extensions, you still need to bang the UI to actually show you these, and if anything the OS is more likely to ignore the extension when "opening" the file, acting on embedded information hidden within the file.
Just as the web enraptured Microsoft in the days of Internet Explorer 4, so "search" is enrapturing them now. Today's users may rarely type in a URL to reach a site; they are more likely to search for things via Google, and Vista brings the same "convenience" to your own PC. You're encouraged to ignore the namespace tree of locations and names, and simply type what you want so that the OS can guess what you want and "open" it for you.
The other growing risk in Vista, is that of automatic metadata processing. The converse of "any non-trivial code has bugs" is "if you want bugless code, keep it trivial". The traditional DOS directory entry is indeed trivial enough to be pretty safe, but I suspect the richer metadata embraced by NTFS is non-trivial enough to offer exploit opportunities - and that's before you factor in 3rd-party extensibility and malicious "metadata handlers".
Vista continues the trend of XP in that metadata and actual file content may be groped when you display a list of files, or when you do nothing at all (think thumbnailers, indexers etc.). If something manages to exploit these automatically-exposed surfaces, it allows loose malware files to run without any explicit integration you might detect and manage using tools such as HiJackThis or MSConfig. Removing such files may be impossible, if all possible OSs that can read the file system are also exploitable by the malicious content.
Exploitability
By now, we know that any code can be found to be exploitable, so that actual outcome of contact with material may bear no resemblence to what the code was supposed to do with it. Some have suggested this means we should abandon any pretence at a data/code distinction, and treat all material as if it posed the high risk of code.
IMO, that's a fatuous approach. Use of the Internet involves interaction with strangers, where identity is not only unprovable, but meaningless. That requires us to safely deal with content from arbitrary sources; only when we initiate a trust relationship (e.g. by logging in to a specific site) does identity start to mean something.
Instead, the message I take home from this is that any subsystem may need to be amputated at any time - including particular file types, irrespective of how safe they are supposed to be. For example, if .RTF files are found to be exploitable, I'd want to elevate expected risk of .RTF to that of code files until I know the risk is patched.
A pervasive awareness of exploitability dictates the following:
- No system-initiated handling of arbitrary material
- Strict file type discipline, i.e. abort rather than "open" any mis-labeled content
Making safety easier
Vista tries hard in the wrong places (user rights), though that approach is becoming more appropriately tuned - but that's another subject! What we need is:
Run vs. View or Edit
Let's see the death of "open"; it means nothing, in a context where we need meaning.
First, we need to re-create a simple data vs. code distinction, and force the OS to respect this so that we as users can trust what is shown to us.
Every time material is shown to use in a context that allows us to interact with it, we should be shown whether it is code or data. It's no use hiding this as a pop-up toolbar, extra column in detail view, some peripheral text in a status bar, or requiring a right-click and Properties.
Then we need to use terms such as Run or Launch to imply code behavior, as opposed to View or Edit to imply data behavior. You could View or Edit code material too, but doing so would not run it!
It would also help to show the file type as well, so that if a type that should be "data" becomes "code" due to code exploitability, we could avoid that risk. It's important that the system derives this type information in a trivial way (i.e. no deep metadata digging) and respects it (i.e. material is always handled as the type shown).
Safe handling and context awareness
Microsoft has juggled with various "My..." concepts for a while now, but there's no safety aspect to this as yet. Indeed, Microsoft encourages you to mix arbitrary downloads and incoming attachments with your own data files, as well as recommending the storage of infectable code fiels within "My Documents" as a way of hiding them from System Restore.
What we need is a new clue; that incoming material and infectable files are not safe to treat as if they were data files, nor should they be mixed with your data files that would be restored in the case of some system melt-down. I've applied this clue for many years now, and it does make system management a lot easier.
Once you herd all incoming and risky material into one subtree, you can add safer behaviors for that subtree - such as always showing file name extensions and paths, and never digging into metadata even to display imbedded icons.
These safer behaviours can be wrapped up as a "Safe View" mode, which can then be automatically applied to other hi-risk contexts, such as when new drives are discovered, or the system is operated in Safe Mode, or when one is running the maintenance OS from DVD boot.
Change the mindset
Currently, we encourage newbies to jump in and use everything. Then we suggest to interested survivors that they learn and apply some safety tips.
Newbies may see a suggestion to turn on the firewall, install and update an antivirus scanner, and swallow patches automatically - but we don't talk about file type risks, and we encourage them to send attachments without suggesting they should avoid doing so.
IMO, the first mention of sending email to more than one recipient should explain and recommend the use of BCC:, and users who know nothing about file types or the need for meaningful descriptive message text should not be shown how to send attachments.
In other words, safety should be learned at the same time as how to do things, rather than offered as an afterthought, and it should be as easy to operate a PC safely as it is to operate it at all.
