Leonard wrote the following humorous poem:
Fisherman, spare that mola mola!
Touch not its snout or dorsal!
Instead, try some granola
Or other tasty morsel.
A similar parody is the famous "Reclaimer, spare that tree", in the Great Quux Poem Collection, by Guy L. Steele.
Now Lessig has a blog. (I wrote to him about source code vs. object code. I made heavy use of Touretzky and some use of Tien.) He joins Felten in this pursuit.
Bookfinder reports that Edward Tufte likes their service. I don't blame him!
After looking back through old diary entries, I found my link to Paul Treanor's page, and read a number of his essays. They're very challenging. I'm trying to figure out what to make of his ideology.
The analog hole is now a commercial product!
I think we'll see more products like this. They are very useful, and the general public will start to get used to this idea (especially now that they know what an "MP3" is.)
Microsoft has posted a useful FAQ on Palladium.
One of the useful things about this FAQ is that was obviously written by people who were actually working on the project and were trying to provide specific information about it. That's a difference from a lot of corporate and industry-association FAQs, which are sometimes pure spin. This FAQ's tone is a refreshing change.
It's got the interesting explicit statement that
"Palladium" is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine.
(Why do they put "Palladium" in quotation marks throughout this entire document? Isn't that actually what the initiative is called?)
In some sense, this means that Palladium shouldn't be used by someone who wants to do any kind of DRM against an untrusted remote party. You might say "Oh, my data is only worth $7 to me, and it will cost $380,000 to do a successful hardware attack against Palladium, so I am OK". But we don't currently have any basis for estimating what a hardware attack against Palladium will cost. For all we know, it might be $50. (Indeed, a discussion in Bunnie's paper at CHES about my discussion of Palladium hardware security implies that some attacks might be mounted for under $100. Bunnie thought he could build what Lucky Green has been calling "instrumented RAM" at that price point. I believe him!) Unless there is some reason to claim that hardware attacks will actually cost over $100, I'm tempted to assume that they will cost under $100. Unless there is some reason to claim that they will require more sophistication than software attacks have required, I'm tempted to assume that they will require only as much sophistication as software attacks have required.
That doesn't mean that Palladium isn't useful (there are still lots and lots of useful bits), but it means that Palladium is not necessarily significantly more trustworthy than existing software DRM (like software implementations of DVD CSS, which were readily defeated even without physical hardware attacks, or Adobe eBooks, or Microsoft's WMA DRM). While Palladium does supposedly protect against "break-once run-anywhere" attacks, some security researchers I spoke to suggested that the typical way of implementing DRM on top of Palladium would still be vulnerable to such attacks.
I can't stop thinking that this makes Palladium very questionable as a DRM platform. Not that I mind that, of course -- I would personally be perfectly happy if Palladium were not an effective DRM platform. But the funny question is, if DRM is, in fact, a major application for Palladium, why would DRM customers (whether major publishers or ordinarily individuals) be satisfied with a system "not designed to provide defenses against hardware-based attacks"?
(I gave an interview to Elinor Abreu about Palladium today, and I spent a lot of time talking about this, partly because I had just written some of the above when she called. One of Lucky's predictions is that Palladium will be made dramatically more robust against hardware attacks in future versions -- for example, by moving the SCP and some RAM physically inside of the CPU, and/or applying bus encryption or memory encryption.)
Minor gripes with the (very useful and straightforward) FAQ:
Once the user of a machine accepts a set of policies, DRM systems are designed to enforce those policies even if the machine owner (or malicious software running on the user's machine) subsequently tries to subvert them.
I have a gripe about this. In "self-protecting content" DRM models, policies are enforced against a user who can't be deemed to have "accepted" those policies. For example, if you buy a DVD, the DVD CSS scheme attempts to enforce against you various restrictions to which you didn't "agree" (even in the funny pseudo-"agreement" sense of performing a post-sale action using your own property which a publisher has tried to define as "indicating consent"). Sometimes people are actually surprised to run up against these restrictions. For example, Cory has found that he can't take screenshots at all on his Macintosh when he has a DVD in the drive, even if it's not a CSS-encrypted DVD and it's not playing!
The sensible interpretation of the above sentence is that it claims that you "accept" restrictions by installing software which is designed to enforce those restrictions against you. (In an ideal DRM world, you are simply not allowed to access information at all without some kind of technical guarantee that the software you use will behave this way.) This is, however, a strange sense of "accept". A strange game. The only way to win is not to play.
Moving on:
"Palladium" itself is not a DRM system. DRM applications can, however, be built on top of "Palladium." What "Palladium" offers is a way to isolate applications (to avoid snooping and modification by other software) and store secrets for them while ensuring that only software trusted by the person granting access to the content or service has access to the enabling secrets. A DRM system can use this environment to help ensure that content is obtained and used only in accordance with mutually understood set of rules.
Similarly, "mutually understood" is kind of funny here. The infrastructure is such that DRM vendors (and publishers who are their customers) get to choose which policies will be enforced by the software they choose to trust. End-users do not normally directly have a choice about this, and, to the extent that software is distributed in a difficult-to-understand binary-only form (or with part of its code encrypted or sealed so that it completely resists analysis), users may not even be able to tell what the policies are if the vendors do not want to share that information with the users.
While "Palladium" enables DRM-style policy enforcement, it also can ensure that user policies are rigorously enforced on user machines. In addition, "Palladium" software can provide a mechanism to ensure that user interactions in unsafe environments (such as the Internet) can be safeguarded by software that the user trusts to protect his or her interests and wishes.
The first part is real and the second part is also real (although potentially limited a lot in practice by market forces). John Gilmore's example was that a hospital or a credit bureau will not accept personal information subject to conditions imposed by the end-user supplying such information. And the hospitals and credit bureaus and other users of personal information have the market power to determine which technical standards, software systems, and poliies are used by customers supplying them with information. The converse is not generally true.
Now, some people at Microsoft have envisioned a possibility of legislation, presented as consumer-protection legislation, which might somehow prevent some organizations which use personal information from refusing customers' trusted-computing-enforced demands that that information be treated in certain ways. But this seems like a pretty big "if".
Q: Isn't DRM just for the benefit of big studios and major labels that want to control access to content, restrict its usefulness and get bigger fees? Won't "Palladium" give them unreasonable control over users?
It's amazing how sensitive Microsoft is to the specific concerns of its skeptics and critics and the skeptics and critics of DRM. You don't see MPAA FAQs where the questions are like this!
A: Unfortunately, people tend to view DRM systems as being limited to functioning as copy-protection systems for commercial, mass market movies or music. While this is a valuable application that facilitates the digital distribution of content, there are much broader applications, particularly in the enterprise.
In fact, it's easy to imagine that enterprises will get excited about the ability to (e.g.) prevent document leaks outside of an organization, or "upstream" against an organizational policy-defined information-flow gradient. It's easier to imagine them understanding this capability and making use of it than it is to imagine the general public doing the same. But large organizations are always early adopters of almost any technology and have often captured a huge fraction of its benefits. And I think that's likely to happen with the trusted computing features in Palladium, which doesn't necessarily mean that all of these uses will mean a disadvantage to the public.
First, it is important to note that the technical mechanisms underlying DRM as employed by the motion picture industry can also be deployed to enforce restrictions on any private information used on a machine that is outside the control of the "owner" of that information (e.g., personally identifiable information such as medical records, corporate information, financial records and so on). In other words, DRM can provide a mechanism by which anyone can impose access control over remote networks and/or enforcement of user policy over sensitive information.
Of course, the economic and legal differences between situations make it unlikely that this technical parallelism will mean a clean parallelism in practice. But that's a whole other discussion which we still need to keep having.
Second, "Palladium"-enabled DRM systems can overcome the overly restrictive and sometimes consumer-unfriendly mechanisms that are creeping into closed, captive devices (such as some consumer electronic devices and cell phones), by providing a broad, interoperable and open platform for content. Unlike closed, captive platforms, "Palladium" allows any provider or even individual to build a trustworthy interoperable mechanism that is not in the exclusive control of a single entity.
Since Palladium allows DRM vendors to implement any policy they choose, I don't see a reason to assume that their policies will be less restrictive than the policies they might implement if they were designing DRM in a CE device.
A computer is more flexible than a single-purpose CE device, and it's my intution and most of my friends' intuition to say that "more flexible" means "better" or "superior". But we know that a Turing machine can emulate any other machine.
So the Mac can emulate a typewriter, and the PC can emulate a typewriter too, or a pocket calculator, or any one of the fixed-function boxes which are so far beneath the dignity of the noble general-purpose computer. And if the people who write your media software so desire, they can make it just as inflexible as any bad old CE device.
That might not happen, but it also might happen.
Third, unlike some antipiracy proposals endorsed by some content owners, no "Palladium" application can censor, monitor or disable another "Palladium" application - or in fact any software running on a user's machine - without the user's permission. This central principle of "Palladium," that machine owners, whether they are individual consumers or organizations, are in complete control of their machines and the programs they run, is in stark contrast with some current proposals that would mandate that all machines include monitoring systems that could arbitrarily disable content or programs. "Palladium" has no mechanism for filtering content, nor does it provide a mechanism for proactively searching the Internet for "illegal" content.
I think this is totally correct, and bears repeating, and I repeated it in my interview. Pd, for its lack of "proactivity", is unlike several of the technologies some publishers might prefer.
Similarly:
Q: So I won't be able to play any MP3s on my PC any more?A: You will. "Palladium" brings additional capabilities to the PC but does not interfere with the operation of any program that runs on current PCs. "Palladium" never imposes itself on processes that do not request its services; "Palladium" features must be requested by a program. So the MP3 player you have today will still work on a "Palladium"-enabled PC tomorrow.
OK:
Playing devil's advocate, one might then ask, "But you have to be running a Microsoft operating system, right?" Remember, we have defined the "Palladium" initiative as a "new set of features in a forthcoming version of Windows that, when combined with new hardware and software, enable . . ." What we refer to as "Palladium" incorporates a Microsoft operating system. For further discussion of other OSs and "Palladium," see the last two questions of this FAQ.
This glosses over the very important competition concerns a bit. The canonical example of this is the plight of Mac users and Linux users who sometimes found that proprietary software on the dominant Windows platform failed to interoperate with software (free or proprietary) available on their own preferred platforms. Sometimes this was accidental, but sometimes it was the deliberate plan of the developers of the majority-platform software. (It wasn't that they specifically wanted to exclude Mac or Linux users -- usually -- but that they wanted to exclude interoperability by rival developers' software.)
Palladium allows -- not requires, of course -- a developer who wishes to behave anticompetitively to write software with anti-interoperability misfeatures which will be extraordinarily hard for rival developers to overcome. By contrast, in other situations in the non-Palladium world in which a majority-platform developer accidentally or deliberately hindered interoperability, reverse engineers frequently stepped up to the plate and overcame the communications barriers. This process is still continuing, as, for example, support for Microsoft protocols and file formats on Linux is getting better all the time, even though Microsoft has so far published only some of them. In the Palladium world, an application developer is able to say (and is not at all required to say) that the software listening at the other end must be software produced by the same developer.
It will be possible, of course, to write applications that require access to one or more "Palladium" services in order to run. Such applications could implement access policies, enforced by a "Palladium" application, that would allow the application to run only if it has received some type of cryptographically signed license or certificate.
And that's only the beginning of what they can do along these lines, since the policies for the use of documents and network services, not just software, can be specified in an arbitrarily fine-grained manner!
Q: Some people have claimed that "Palladium" will enable Microsoft or other parties to detect and remotely delete unlicensed software from my PC. Is this true?A: No. As stated above, the function of "Palladium" is to make digitally signed statements about code identity and hide secrets from other "Palladium" applications and regular Windows kernel- and user-mode spaces. "Palladium" doesn't have any features that make it easier for an application to detect or delete files.
Maybe this suggestion could have been stated differently: "Palladium will enable Microsoft or other parties to prevent a single copy of an application from being installed and used on multiple PCs." And I think the infrastructure it provides can be used that way ... but it's not by any kind of remote snooping. It's by making "product activation" code actually work, and preventing people from just NOPing that code out in a debugging.
Q: Won't the FBI, CIA, NSA, etc. want a back door to "Palladium"?A: Microsoft would refuse to voluntarily place a back door in any of its products and would fiercely resist any government attempt to require back doors in products. From a security perspective, such back doors are an unacceptable security risk because they would permit unscrupulous individuals to compromise the confidentiality, integrity and availability of our customers' data and systems. From a market perspective, such products would not be marketable, either domestically or internationally. Equally important, deliberately inserting such vulnerabilities would undermine Microsoft's reputation in the marketplace as a trusted vendor of products. For these reasons and others, we would, as we did during the encryption debate, oppose any such government efforts.
Cool. Now, how can we guarantee that this doesn't happen in secret anyway (perhaps without the knowledge or consent of any of the engineers working on Palladium)? It seems that such things have been done in the past.
Q: I've seen claims that "Palladium" will undermine the GPL. Is that true?A: The claims that we've seen along these lines stem from the fact that the TCPA platform has some features that are accessible only to TCPA-certified software. So if you have source code to a piece of software that uses these features, and if you make changes to the source and recompile, you'd need to obtain a new license for the software from the TCPA: This concern is not an issue with "Palladium" because "Palladium" does not contain any restricted-access functions (except for functions restricted by the user); any nexus loaded into "Palladium" can access all "Palladium" security features for itself. Nexus B cannot access nexus A's secrets stored with "Palladium," but nexus B can always seal its own secrets without needing to hold a special license (from Microsoft or anyone else).
Of course, because "Palladium" exposes a programming model, it would be possible for someone to build a "Palladium" nexus that would restrict access to itself to some set of licensed applications. And, recursively, one could write an application on top of a nexus that restricted access to itself. But a firm design principle with "Palladium" is that the hardware and software itself will not have any such restrictions.
It doesn't necessarily matter whether Palladium implements a particular feature, if it allows application developers to implement it conveniently. The "document revocation list" seems to be the most famous example of this at this point. Palladium does not include a document revocation list feature or primitive. It does include features and primitives which would allow an application developer to create applications with mandatory DRL support. The fact that the DRL itself was not conceived or implemented by Microsoft does not mean that it would work any less effectively under Palladium, if application vendors wanted to implement it and could somehow induce users to accept software which supported it (or documents which were only readable with such software).
In the same way, somebody can use the Palladium programming model to build software which will only interoperate with other software which presents a particular certificate. (That's related to the anticompetitive stuff I discussed above.) In Ross Anderson's sense, this still seems to undermine the GPL, even though the GPL-undermining is not performed by Microsoft or Microsoft-written code.
I don't necessarily accept the argument that this "undermines the GPL", which seems like a very subtle question, but I think Palladium can be used by a particular programmer to do what Ross Anderson called "undermining the GPL", if that's that programmer's goal. I don't think the architectual differences between TCPA and Palladium will eliminate this possibility.
Riana found that USENIX is an anagram of UNISEX. (Now I have mentioned her somehow in every single substantive diary entry I've written in August.)
I had a great time at the Wil Wheaton vs. Barney benefit at the DNA Lounge. It was incredibly humorous and a lot of fun. (It has a long history, and was years and months in the making.)
Wil delivered a very stirring speech and got a very positive reaction from the crowd. (You can read his speech on his home page, if you want.)
In response to a bet from Robin, I refrained from using the letter "E" in my speech from about 9:00p until midnight, but kept up conversations with people for almost that entire time. I think Robin now owes me lunch...
I wrote most of this entry on a terminal at the DNA Lounge.
We've still got to do something about this age discrimination business.
Contact: Seth David Schoen
