> Why do you describe the interaction of Melissa in a capability
> environment as one which the user will be pestered with requests
> for individual privileges? (Sounds a bit like the Java security
> manager or the POSIX privilege model.) Am i wrong in thinking
> that you could simply have said that the mail reading program
> would never have been given privileges to make arbitrary outward
> network connections, and that the mail reading program would
> never have launched the embedded application in an environment
> with access to the address book capability or the mail-sending
> capability at all
There are many interesting questions with respect to User Interface to Capability Systems for Grandmothers. You certainly do not want the system asking her, "Should mail attachment 4312.exe be granted read-access to file mbx.idx?" I certainly do not want the system asking me this question, much less my grandmother :-)
I wouldn't be surprised if you were right that the defaults set on a capability-based mail reader would simply say, "Hey, if a piece of email asks for a capability, I'll just deny it and not bug the user". This would make the model of computation for email look like the Java sandbox. This would probably be just fine as a default for the people who attend the Introduction to Computing class at Mohave Community College...though I will play Devil's Advocate in a moment.
I could imagine another setting that the user can set which says, "Let me know if a piece of email wants to read a file, but don't ever let email get an Internet connection". After all, in this situation the email is confined; this configuration would allow people to send you analysis tools that would create graphs of your Quicken database yet still be safe.
However: One suspects that in a world rich with smart contracts, one wants even greater flexibility than this. If EROS-OS Inc. sent me email saying, "I'll pay you ten buck if you'll let me read your default configuration file and send the info back home," I'd like to be able to say "Sure!". I'd want my computer to walk me through the capabilities requested rather than making me go into some configuration panel and figure it out.
Granting capabilities doesn't have to be arduous: creative interface design can reduce its irritation till it is almost invisible. As the simplest example, if you drag/drop a file onto an application window, you can certainly implicitly grant the application read authority, and probably read/write authority (maybe with a popup window that appears when you drop). Using drag/drop to grant capabilities, you could make a rather fine-grained capability system easier to use than conventional insecure systems that rely on clunky file dialog boxes. If someone like IBM put a man-century of effort into designing user interface techniques for dozens of capability-granting scenarios, an enormous amount of it could be made simple, painless, and invisible. I have a few thoughts myself, but not enough to solve the problem on my own :-)
One of the most intriguing things about the Melissa story was that, when I would present it in these community college classes, people didn't mind the idea of having the system ask about granting read and comm capabilities. They were fine with these questions...and since these questions would presumably come up only very rarely, defaulting to ask the user is not really unreasonable. The instructions I would give in my Intro classes would be, "if a piece of email requests access to the internet or your files, just say no". They can follow that recommendation easily :-)
The sense of tension-released I would get in the room when I described the question/answer dialog for Melissa suggested that they minded the current situation--in which an executable can just get anything it wants without asking--a lot more. I know I certainly feel that way--there's always the question lurking in my mind, "what're those blasted executables doing out there behind my back?" I especially feel that way when I turn on the Installation/Setup executable for software from Microsoft :-) Having an occasional discussion with the computer as the price to pay for knowing what's going on seemed a price even my students were willing to pay.
--marcs