Dylan Tweney: Broken trust. The problem is that Palladium requires users to place a huge amount of trust in Microsoft. You don't get to decide what runs on your computer -- Microsoft does. You can't even open files unless you've been authorized by Microsoft, or by a third party. [Tomalak's Realm]
Many individuals are starting to take a look at Microsoft's Palladium. I guess corporations are going to love it. But the opposite is true for individuals.
If I understand Palladium correctly, it's about allowing certain system privileges for only trusted code. This is a good idea. It has been the standard operating procedure on Unix systems for decades. On Unix systems, there is a privileged user account (root) and there are non-privileged users accounts. By using a non-privileged user account for all computer activities except system administration, Unix users maintain some degree of safety. Why hasn't Microsoft adopted this idea? To some extent they have, but not for home users. Now they want to make a distinction between privileged code and non-privileged code, but they want to do this in a very heavy-handed way, even involving the hardware. I don't understand why they feel that hardware has to be involved, unless they feel they need to convince Hollywood and other interested parties that the system is so secure that even the computers' owners can't break the security.
I think that we as computer owners feel that we should be able to choose who we trust and who we don't trust. In particular, I think we should be able to trust ourselves. But part of Palladium is the idea that a computer's owner can't be trusted.
We want safer computing, but what about the alternatives to Palladium. Windows XP Home Edition does not allow file shares to be password protected. That is not a good idea in an increasingly connected world. Another way to achieve safer computing is to treat program code and data separately. Microsoft has allowed code and data to merge, through VBA code in Microsoft Office documents and through Active Scripting (Javascript, VBScript) in HTML documents. If we had separation of code and data, then we would only have to be sure that the applications (the code) were trusted, and we could open any data file. But when code and data are merged, it's no longer safe to open a data file, because it may contain dangerous code. Emacs is a good example to look at, because emacs got it right. Emacs allows customization through user-written program code (macros), but the macros come separate from the data files, and there is a separate step in which the macros are installed.
Posted by Doug Sauder at June 29, 2002 11:37 AM