Palladium Explained
This is a long post, but it offers a very clear description of Microsoft's forthcoming Palladium technology and it's implications for us as users and creators of software. The original posting can be found here.
I am going to start an area on this site with links and resources on these and other threats to our rights as consumers, to our purity of essence. This article will most definitely be in there. Read on if you need to understand one of the bad things that are on the verge of happening:
Date: Fri, 10 Jan 2003 10:44:23 +0000
>There is a lot of speculation here which is not based on facts. PD will give you the capability to protect some subsets of your system from damage. Imagine having a fire proof safe in your house. Your house can still burn down and your safe will still protect your documents that are stored in there. Having the safe does not enable the people who sold you the safe know what is stored in there.
The problem is that in this case the safe salesman is the only person with unrestricted access to the safe. Let's keep in mind an important characteristic of a real safe: only the safe's owner can access its contents.
Let's talk about two system subsets: OS data and user data.
Pd protects OS data by only allowing MS-signed code to modify it. From a system-level standpoint, the OS must decide whether or not a specific process is allowed to access a certain data structure based on the information it has about that process. In a traditional system, the OS only has information about which user launched it, and so the process has the effective privileges of the user. This is a problem because a user can inadvertently run virus code just as easily as that user can run windows update. In a Pd system, the OS can also decide whether or not the software is MS-approved by looking at its digital signature. Note, however, that making MS's digital signature the sole possible "passport" to elevated privileges locks the user out of making any changes to the "protected areas", since the user does not have access to MS's private key.
In the context of the safe analogy, this would mean that the owner of the safe does not even have its combination. If the owner wants to open the safe and modify its contents, it must contact the safe's vendor, and ask that a representative of that company be sent out to dial open the safe. Even then, only the representative can go inside.
Fortunately, there is another way to prevent viruses while still allowing the user full access to the system owned by that user. Instead of creating a system where the OS must decide whether or not a piece of software may access system files based on whether or not it carries MS's digital signature, the OS could keep a list of approved signatures, modifiable by the user, that would grant a program proper permission to modify OS code and data. By guaranteeing that only the user can add digital signatures to that list and not programs (like it now guarantees that when the user presses ctrl-alt-delete, it really is the system responding with a login prompt), users could still have full access to the system without risking exposure to hostile code, at least without jumping through an elaborate set of hoops at the direct instruction of the (then unprivileged) malicious code.
Why didn't MS take this approach? Well, by only allowing code signed by MS access to the OS, MS has made itself a choke point for new drivers and hardware, as well as propped up its DRM system (which I'll get to later). Imagine that one day OpenGL 2.0 is ratified as a full standard. Once hardware engineers are able to tear their eyes away from the hordes of flying pigs outside the office, those engineers, at the suggestion of an aging but still active John Carmack, start work on the latest graphics card and accompanying drivers with support for OpenGL 2.0. After many years of hard work (hey, they happen to be the same people who worked on Duke Nukem Forever, it's to be expected), the new board is completely designed and ready for the market, and the drivers are written. OpenGL 2.0 apps perform between 5% and 10% better than Direct3D apps on the same system. This is what the designers had in mind, as everything coming out of Id Software is still OpenGL only, and Id is still very much on top of the 3D FPS engine industry. In a non-Pd environment, the company would have a viable product that they could put on the market themselves or sell to graphics card manufacturers. However, in a market where Pd is pervasive, they have a problem: their drivers aren't signed, and a Pd system won't install them without a signature. So they send them off to the Windows Hardware Quality Labs to get them certified at a cost of (say) a couple thousand dollars. Ka-Ching for MS. A month later, they get the reference card back in the mail, with a note that says:
"Direct3D support still has a few significant bugs. Please work them out and resubmit."
Right. Translation: "OpenGL is faster than Direct3D. This is not ok with us." Left without any recourse, the developers load up the source code for their drivers, add a few delay loops in the OpenGL code, and recompile. OpenGL performance is now 5% behind Direct3D. Again, the company submits the reference board to the WHQL along with the new drivers, and a month later they get a cd back in the mail. It's a signed binary, and a note that says, "Thank you for your cooperation. In the future, smaller driver binaries would be appreciated." Translation: "Don't bother including OpenGL support in your next card's drivers. They will not be signed."
It's a huge win for MS. Since every driver must be signed, the WHQL department can really rake in the dough, and competing (read: portable) technologies like OpenGL are eventually crushed. For media professionals, substitute an mpeg4 capture/encoder card for a graphics accelerator in the above example.
Even though users will feel the effects of such restrictions on hardware, Pd's iron-fisted control of OS software can affect users more directly. Take daemon tools, for example. When Diablo II first came out, consumers were in for a shock. It sported the latest version of a cd-based copy protection mechanism, and so duplication of the "Play Disc" was impossible at that time. This created an interesting dilemma: How could people who had legally purchased the game avoid having to risk scratching the original CD if they could not back up onto another CD-R and play from that? In a broader sense, how could anyone without a CD burner protect any of their discs? Anyone can learn to be exceptionally careful, but accidents are called accidents because they're not planned. Duplication for backup purposes was legal, but it didn't seem possible. Enter daemon tools -- a software package that would emulate a dvd-rom attached to a scsi adapter inside the computer. By reading the entire contents of the disc onto their hard drives with the help of comprehensive reading software, and then "mounting" this image with daemon tools, Diablo II players could enjoy D2 with the actual game CD tucked safely away inside its jewel case. If Pd had been around when D2 came out, this would not have been possible. Installation of daemon tools requires that its fake scsi driver be installed and recognized by windows.
Daemon tools is freeware, available at no charge from a group of dedicated developers who believe that people should be able to exercise their fair use rights. They don't have the money to pay for WHQL certification, and if by some miracle they were able to come up with it, MS could always decline to sign the driver.
And that's only what happens as a result of Pd's "protection" of OS files. What about user-level files? It's almost the same story.
I've already laid out the reasons why code must be signed in the Pd model in order to access "protected" data, so I won't repeat that here. Let's assume that the latest version of word uses Pd's protection to keep viruses from destroying a user's files. It can do this because word is signed by MS, and the system knows that it's ok to let the signed executable modify documents that the user owns. What will happen when a competitor to MS office, say OpenOffice, decides to add support for the upcoming XDocs file format? Even if MS fully opens up the structure of the file, I mean documentation and everything, and the OpenOffice crew implements it perfectly, they're still prevented from competing. Why? Their binaries, once again, won't be signed. A user would be able to open a word document in OpenOffice (assuming MS doesn't lock off read access to prevent dangerous worms from exposing private documents as certain worms have in the past), but would be unable to save her work. Quite a few commercial software packages out today ship "trial" versions that don't have a save feature. It kinda tends to cripple the product.
Of course, the above all hinges on whether or not there will be "protection" for user files. The TCPA specs make it pretty clear that there will be OS file protection as described above (because it's necessary to preserve system integrity), but says nothing about user data.
>And if you don't want to have the said safe, then don't use it! Same is true of PD.
Ah, and that's the kicker, isn't it: you can always turn it off. What about when you can't? What the MS promotional materials don't say is than when you turn off your "security components", certain important things break. This system behavior is necessary in order to make DRM "work". At this point I think it would be appropriate to define what DRM means, just for clarity. DRM, or Digital Rights Management (aka Digital Restriction Management) is technology that allows the entity that introduces information into a system implementing that technology to control what other entities are able to do with that information once it is transferred into hardware not under the direct control of the introducing entity. Basically, information control. Some possible applications:
-Online movie rental. The idea is that if a movie studio can have control over its content after it streams it to a customer, the movie studio can be comfortable with renting movies online. (This, incidentally, is very similar to the logic behind the misguided CBDTPA bill.) -Emails with timeouts and limitations. Users could send emails to other users that would delete themselves after a certain amount of time, or not allow copying or printing.
Now, set aside for a moment the issue of how turning off Pd affects the user experience, and consider the implications of such an email system. A boss could send an employee an email ordering him to take a risky business action, and have it deleted after recipient read it. A record, of course, would be kept in the boss's "sent" mailbox. This puts the employee in a double bind: if he doesn't follow the instructions in the email, his boss can proceed with disciplinary action as the boss would have proof the email was received. If he does follow the instructions, and the action is successful, his boss can take the credit. If he does follow the instructions and the action is unsuccessful, costing the company in some way or another, the employee has no record to prove that he was just following orders. His boss can delete the email, but the employee can't.
In any case, regardless of the negative experiences a user might have if victimized by a superior through Pd, there is still the issue of reduced functionality when Pd is deactivated with respect to DRM. Basically, the way Pd ensures that content stays in a trusted environment is by querying a machine to see if it is running a trusted OS on trusted hardware before it sends it any managed content. While I won't explain it in great detail here (it would take up _way_ too much space and the specs are freely available online for anyone who wants to read them), each machine contains a Trusted Platform Module (or TPM) which is a little chip soldered onto the motherboard. (Later it will become part of the CPU itself.) This chip contains a key pair generated for use with a public key cryptosystem, and although it can hold many keys in its limited memory, it ships with one already embedded. This sign-only key pair is signed by the hardware manufacturer, signifying that the signed key pair is actually part of a TCPA/Pd system. When TCPA/Pd is deactivated, either by user request or if the CRTM (Core Trusted Root for Measurement) detects that the user is trying to run untrusted software with elevated privileges (e.g. The user is trying to boot GNU/Linux), this chip refuses to give up it's private key to the cpu. This means that when a system with Pd enabled tries to send an email to a system with Pd disabled, the receiving system will not be able to participate in the trusted system challenge-handshake sequence and will not be able to receive the email. A similar sequence of events occurs in an online movie rental scenario when an untrusted system requests a stream, and the server requests verification that the client is running trusted software on trusted hardware.
So what won't work? Well, secure email, online movie rentals, and pretty much any other communication involving "managed" content. In other words, turning off Pd in an environment where Pd is widespread means not being able to get managed information from other systems. Once Pd becomes popular enough, MS can extend its control by causing systems with Pd enabled to treat everything as managed content, even simple things like web pages. Turning off Pd in 2003 is an option. Turning off Pd in 2010 won't be.
>As to the original comment regarding privacy, you are seeing our attempt to document any and all aspects of the system that could concern anyone. So you are going to see us telling a lot more about the capabilities of the player and this can appear overwhelming at first.
And this is a good thing. However, MS is just doing something it should have done a long time ago -- it's in debt to the public for past privacy violations. While I applaud MS for finally releasing a player that can be easily configured not to disclose a user's media viewing preferences, this is more than compensated for by the fact that Pd makes past and present privacy violations look like nothing it all. MS is, for the most part, halfway fixing the lesser of two evils.
>The good news is that you have full knowledge of what we do and the choice to turn one or more of these off if your privacy is more important than the functionality.
Why can't users have privacy and functionality? You know, like they do now if they know how to properly configure WMP's options?
>Competitors probably do the same thing but fail to warn you explicitly about them (and burry the detail in long EULAs).
From a WMP critical update EULA: "* Digital Rights Management (Security). You agree that in order to protect the integrity of content and software protected by digital rights management ("Secure Content"), Microsoft may provide security related updates to the OS Components that will be automatically downloaded onto your computer. These security related updates may disable your ability to copy and/or play Secure Content and use other software on your computer. If we provide such a security update, we will use reasonable efforts to post notices on a web site explaining the update. "
MS's _competitors_ are burying sneaky and unethical terms in EULAs? Realplayer may spew garbage all over my system, but at least Real doesn't demand the legal right to install software on my computer without first receiving my explicit permission or entirely disable software on my computer, all before I can get access to a patch to fix a bug in their software that was only there because they put buggy code on store shelves and sold it at full price.
Then again, maybe Real does do this. I haven't seen their license terms in a while.
>Here is a write-up from CNET on our privacy approach in media player: http://news.com.com/2100-1023-955514.html. As you see, it is being seen as a very positive move and not negative at all. Here is one quote: "If the final build looks like the software (that CNET News.com) described, the implication is that Microsoft is taking consumer privacy very seriously indeed and marks a big change for the company," said Jupiter Research analyst Michael Gartenberg."
This article is about WMP9, and notes that it still has a few bugs to work out in terms of privacy. It is not about TCPA/Pd, DRM, or the next version of windows.
5:31:07 PM 
|
