Zaptastic Author Misses the Point
May 19, 2005 by PingIt’s nice how The Internets have a way of offering me real-life examples, like a cat leaving a dead bird on the doormat, only moments after i’ve been talking about something. Thank you, Internets.
Recently, to demonstrate a security problem in the new Dashboard feature in Mac OS 10.4, Stephan Meyers created a “slightly evil” Dashboard widget and another “more evil” widget. These widgets are just bits of HTML and Javascript that you can drop onto your Dashboard, which appears at the press of a hotkey. If you use Safari, simply visiting a web page is enough to automatically install a widget on the Widget Bar, and the Widget Bar doesn’t let you remove widgets. The “slightly evil” widget just takes you to a particular website, but the “more evil” widget forces you to go to that website every time you activate the Dashboard and renders the Dashboard unusable. To recover, you have to delete the widget’s files from their installed location and reboot.
Stephan calls his widget “a blueprint for a widget of mass destruction,” because widgets can issue arbitrary commands, thereby exercising the user’s full authority, after the user agrees to a warning prompt. At that point, an automatically installed widget could conceivably do serious damage.
He is right that such a widget could be damaging. That fact should disturb us. Then again, any user-installed software is just as dangerous as a widget, and that fact should disturb us too. What is truly depressing, though, is his conclusion.
After describing the problem, Stephan concludes:
Ultimately, it all comes down to Gödel’s incompleteness theorem and Turing’s halting problem: you can’t predict what a program will do until you run it. There is ultimately no solution for this, and you have to strike a balance between usability and security. There will always be viruses, both in the real world and in the information world; that’s why humans have immune systems, and that’s why we get sick anyway.
No, no, no, and no. Like far too many others, Stephan Meyers has swallowed the entire false metaphor of software, hook, line, and sinker. This is exactly the type of mistaken comparison I was talking about in recent entries.
Viruses are dangerous when they enter your body because they have complete physical access to your body. There is no reason for software viruses to have such access. The analogy to getting sick despite having immune systems makes no sense in software — it only seems to make sense because the creators of operating systems and antivirus tools have propagated this deceptive fiction.
You don’t have to solve the halting problem to use software safely. The solution is to LIMIT AUTHORITY. You can’t limit the authority of a biological virus. You can limit the authority of installed software, and you should.
May 19th, 2005 at 08:25
But expressing consent and formalizing the limits of authority are really really hard. We can’t do it between humans; how can humans express that to computers? Programmers can’t manage it, how can users who are less able to formally communicate to a computer?
For instance, consider the lowly “download optimizer”. It’s a plausible piece of software. The user might want it. It doesn’t break their data. But it does take up their bandwidth. How much bandwidth is okay? How much confirmation from the user is necessary? What are the privacy implications? Is there any way at all to audit how it is preserving privacy from the outside? This is the subtle boundary between a helpful program and a trojan, and one that is crossed regularly these days.
May 25th, 2005 at 08:02
True, expressing and interpreting intentions are hard, but they may not be as hard as you think, or in as exceptional a way as you think. Expression and interpretation of intent happens all the time in every user interface.
For example, every time you choose a file from a file dialog box, you are specifying a limited transfer of file access authority, and it’s a pretty common operation.
I agree that when the software uses wide-ranging network access you’re dealing with a more difficult case. The bandwidth limit is easy — just drag a slider — but if you’re talking about something that prefetches, you’d have to give out access to your complete browsing trail.
May 25th, 2005 at 09:50
The file open dialog seems *more* complicated than the bandwidth one. What permission are you giving when you select a file? Read, write, delete, make public, send across network, delegate permissions to another user…? It doesn’t matter now, because the program could have done any of those if it wanted (or if it couldn’t, the dialog doesn’t change that). The file dialog grants no permissions now. But if it mattered, how could the distinctions be represented?
Would file selection become an operating system responsibility, with a secure way of informing the user what permissions would be granted? (Like “select a file for reading”) That’s possible, but putting security in the user interface is hard too — phishing has certainly shown us that.
And there’s *so many* levels of permission, more than the user can probably understand. I could spend hours talking about the possibilities with a user, and that’s human-to-human communication. Computers are hardly going to be better at it. An important problem, to be sure, but there’s no magic bullet. It’s not even an AI-complete problem — it’s harder than that, because we can’t do it for ourselves.
May 29th, 2005 at 01:11
Generally the file-open dialog has to know whether it’s being used to find a file to write or a file to read (and possibly also write), and it’s typically already provided either by the OS itself or by widely-shared libraries. “make public” is a special case that I never use file-open dialogs for. And once your program has access to the file, it can delegate that access to another user, at least as long as it continues to run.
Certainly you can imagine an unlimited number of ways to restrict permission — time of day, byte offsets within the file, read and write bandwidth limits, etc. — but you don’t need to go that far to make some progress. The perfect is the enemy of the good!