As I noted yesterday, Lessig’s Red Herring piece on Palladium has generated a lot of interesting talk among techno-law-bloggers. (See e.g. Copyfight, Ernie the Attorney, Lessig, and Frank Field.)

This is all interesting, but it’s very speculative. As Bruce Schneier points out, in the best technical perspective on Palladium I’ve seen, we really know very little about how Palladium will actually work. When it comes to security, the devil is in the details; and we know only the barest outline of how Palladium will work.

Even if we did know the technical details of Palladium, it is far from obvious what effect it would have on the everyday practice of computing. My own view is that Palladium will make less difference than people expect. It won’t do much to prevent viruses and network attacks, since it doesn’t address the vulnerabilities that those attacks usually exploit.

More to the point, even if we assume that Palladium is totally bulletproof, I doubt that it will enable the kind of pervasive DRM that some people seem to want – at least, it won’t do so without making the PC essentially useless for ordinary computing tasks. (I plan to elaborate on this argument in a future posting.) A pervasive-DRM “computer” will be more like a CD player than like a computer.

Real computers are so useful that people will insist on having them, and the market will continue to provide them. Most likely it will provide them by pressuring software vendors into not using any draconian features of Palladium.

AP reports that China is no longer blocking Google. (Ben Edelman’s site at Harvard confirms this.)

The article on me and my pro-tinkering work, from the June 20th issue of the Economist, is now available on line.

Maximillian Dornseif offers another comment on my source code vs. object code posting.

He points out, correctly, that we can still define “source code” and “object code” reasonably. We can get some mileage out of these definitions, as long as we remember that a piece of code might be either source code, or object code, or both, or neither.

Dornseif raises another interesting question, about the boundary between “writing a program” and “using a program”. Consider a typical Excel spreadsheet. To me as a computer scientist, a spreadsheet is a program – it directs the computer to combine some inputs in a certain way to produce some outputs. Yet the typical spreadsheet author probably doesn’t think of what he or she is doing as programming.