November 22, 2024

Schoen vs. Stallman on "Trusted Computing"

Seth Schoen raises two interesting issues in his response to Richard Stallman’s essay on “trusted computing.” (To see Seth’s posting, click here and scroll down to the “Trusted computing” heading.)

Stallman says

[Trusted computing] is designed to stop your computer from functioning as a general-purpose computer.

Schoen responds:

Neither of these concerns is applicable at all to Palladium (as Microsoft has described it to us) or to TCPA (as the TCPA has specified it and as it has been implemented). While Microsoft could be misleading us about Palladium, the TCPA specification is public and implementations of it have already been made.

It’s possible that some other trusted computing system could have such a misfeature, but the design of TCPA and Palladium doesn’t require these properties at all, as far as I can tell, and they seem to be more or less independent.

Schoen is right here – Palladium and TCPA do not do what Stallman says it does. Stallman seems too eager to blame Microsoft for the sins of others.

The conversation then moves on to the connection between Palladium and the Hollings CBDTPA. The Hollings bill mandates that some kind of “trusted computing” restrictions be made mandatory in essentially all digital devices. But what kind of restrictions would be mandated?

Stallman implies strongly that the CBDTPA would mandate the use of Palladium. Schoen disagrees, saying that he is “not convinced that something like Palladium is the infrastructure contemplated by the CBDTPA.”

Here I don’t know who is right. The CBDTPA is cleverly constructed so that it doesn’t say what it is mandating – it leaves that to be decided later, either by the FCC or by a vaguely-specified industry consortium. This gives CBDTPA advocates a way to dodge hard questions about the bill’s effects, by invoking a hoped-for perfect technical solution that is just around the corner. Given the track record of copy restriction and its advocates, I think we should insist on taking a test drive before we buy this used car.

Costs of a GPL Ban: An Example

Many people have criticized the recent proposal from some congressmen to ban the use of the GNU Public License (GPL) on federally funded software projects. There’s one disadvantage of this proposal that I haven’t seen discussed. I’ll illustrate it with a real example.

Brent Waters and I are currently doing research on a method for improving certain cryptographic operations. (I’ll spare you the details, which don’t matter here.) As part of this project we wanted to build a proof-of-concept implementation, by modifying the code of an existing state-of-the-art encryption package to add our improvement to it. We surveyed the packages that are out there and chose a package called GPG as the only viable starting point for our implementation.

At this point, there are three things that can happen:
(1) we don’t write any code,
(2) we add code to GPG but don’t release that code, or
(3) we add code to GPG and release that code under the GPL.
Anything else is prohibited by GPG’s license, which is dictated to us by the authors of GPG.

Number (3) is clearly the best choice for us, for other researchers, and for industry. But if a GPL ban were in place, we would be forced to choose (1), or possibly (2).

I want to emphasize that we did not pick GPG because we wanted to create GPL’ed code. We chose GPG because it was the only product that both (a) offered the required features and (b) had a license that allowed us to create and distribute modified versions of the source code.

It’s rare for a software researcher to create an entirely new piece of software from scratch. Our scenario, where researchers build on a large, existing product, is much more common. In situations like ours, the effect of a GPL ban often would be to ensure that no code is released at all. Surely this can’t be what the congressmen had in mind.

Edison's World

Lately I’ve been reading a biography of Thomas Edison, one of history’s great tinkerers. (I recommend the book: Edison by Matthew Josephson.)

I’m amazed at how little the basic nature of the high-tech business has changed since Edison’s day. The products are different, but the business seems very much the same. Edison coped with – and used – vaporware, FUD, standards wars, and ruthless venture capitalists. He fought “bugs” and “piracy.” He and his employees worked insane hours to rush products to market, driven by the same familiar yet mysteriously powerful creative urge that we see throughout the industry today. From this turmoil emerged products that changed the world.

It’s fashionable to say that today’s technology products and businesses are different, and vastly more sophisticated, than anything that came before. I suspect that if Edison saw today’s industry, he would disagree.

[Glossary for non-techies: “Vaporware” means announcing a product well before it is ready, so as to intimidate competitors and delay customers’ purchases until your product is ready. “FUD” means to spread misleading Fear, Uncertainty, and Doubt about competitors’ products. A “standards war” is a battle between competing vendors to dictate and control technical standards.]

Paper on Copy-Protected CDs

Alex Halderman, a senior here at Princeton, has written a very interesting paper entitled “Evaluating New Copy-Prevention Techniques for Audio CDs.” Here is the paper’s abstract:

Several major record labels are adopting a new family of copy-prevention techniques intended to limit “casual” copying by compact disc owners using their personal computers. These employ deliberate data errors introduced into discs during manufacturing to cause incompatibility with PCs without affecting ordinary CD players. We examine three such recordings: A Tribute to Jim Reeves by Charley Pride, A New Day Has Come by Celine Dion, and More Music from The Fast and the Furious by various artists. In tests with different CD-ROM drives, operating systems, and playback software, we find these discs are unreadable in most widely-used applications today. We analyze the specific technical differences between the modified recordings and standard audio CDs, and we consider repairs to hardware and software that would restore compatibility. We conclude that these schemes are harmful to legitimate CD owners and will not reduce illegal copying in the long term, so the music industry should reconsider their deployment.

The paper will appear in the proceedings of the ACM’s DRM Workshop. It’s currently available, but only in PostScript format, on the Workshop’s site. (It’s available in PDF format here.)

It’s rare to see a workshop like this accept a single-author paper written by an undergraduate; but this paper is really good. (Grad schools: you want this guy!)

More on the Almost-General-Purpose Language

Seth Finkelstein and Eric Albert criticize my claim that the fallacy of the almost-general-purpose computer can best be illustrated by analogy to an almost-general-purpose spoken language. They make some good points, but I think my original conclusion is still sound.

Seth argues that speech (or a program) can be regulated by making it extremely difficult to express, even if it isn’t strictly impossible to say. I’m skeptical of this claim for human languages, since it seems to me that no usable language can hope to prevent people from creating new words and then teaching others what they mean. I think my skepticism is even more valid for computer languages. If a computer language makes something difficult but not impossible, then some programmer will create a library that provides the difficult functionality in more convenient form. This is the computer equivalent of creating a new word and defining it for others.

Eric argues that advancing technology might make it possible to restrict what people can say online. I’m skeptical, but he may be right that restrictions on, say, porn may become more accurately enforceable over time. Still, my point was not that mega-censorship is impossible, but that mega-censorship necessarily causes huge collateral damage.

There’s another obvious reason to like the 1984 analogy: using it puts the anti-computer forces into the shoes of the 1984 government. (I don’t think they’ll spend a lot of time comparing and contrasting themselves with the 1984 government.)

You may say that this is cheap rhetorical trick, but I disagree. I believe that code is speech, and I believe that its status as speech is not just a legal technicality but a deep truth about the social value of code. What the code-regulators want is not so different from what the speech-regulators of 1984 wanted.