I apologize to my readers for the lack of an update. I have a lot of things to write about and haven't found the time; there's going to be a description of the Dar Williams concert, N is a Number, more on trusted computing and our recent meetings about trusted computing projects, and perhaps my new trip to Washington. At the moment, I'm back in Washington, D.C., with Amy, planning to attend a meeting about fair use here on Tuesday.
When I last left you, I was off to a Dar Williams/String Cheese Incident concert in Berkeley with Sumana. This turned into a bit of an adventure when it was moved at the last minute from an outdoor venue to an indoor venue on account of fears of rain. (It didn't end up raining after all.)
Arriving a bit late, we heard the tail end of Dar's performance and found the crowd dominated by String Cheese fans, which we ourselves turned out not to be. The last couple of times I heard a Dar Williams concert, she was paired with another female singer-songwriter from a folk tradition (Noe Venable, who in turn was paired with fellow female singer-songerwriter Kris Delmhorst when I heard her again). But the String Cheese Incident is really extremely different musically, and I think promoters are taking a bigger gamble by linking them up.
Sumana and I got to hang out for a while, and I got to see her new place momentarily -- it turns out to be just downstairs from where Cristina and Michelle used to live. There is also a bar on Telegraph which serves good food and (oddly enough) a large line of alcoholic herbal teas. It's called the Bison Brewery, and we went there for dinner after we left the concert.
At the concert, I bought a copy of Dar's Out There Live album, which has live recordings of songs I'm already familiar with, but they're subtly different from the versions I know. There are changes in tempo or instrumental arrangement or (in what I think is only one case) a lyric. This makes me think of Nick's ridicule of musicians' attempts to revitalize old works by arranging them for a totally unexpected instrument. (I like that practice a lot better than Nick seems to, actually. One thing I still haven't gotten a sense of is how a choice of music instrument changes our experience of a melody. But it really can.)
That concert was Friday the 25th, if I remember correctly. On Tuesday the 29th, I went back to Berkeley to see the documentary N is a Number, about the life and work of the late Paul Erdös -- a really remarkable mathematician. Erdös's friend and fellow remarkable mathematician Ron Graham (a veritable master of the discrete) was there answering questions from the audience about Erdös and assorted topics. Erdös was funny in the movie, not to mention inspiringly dedicated to mathematics (and, like Borges's Funes, "memorious"). I need to go hear some lectures from some of our great living mathematicians. I remember missing Persi Diaconis on Riemann's zeta function (something I still fail to understand well, maybe because I never made it to complex analysis). These lectures are happening all the time, and even in the Bay Area it would be hard to go a month or even a week without some really remarkable mathematician sharing some really profound insight. But I'm out of the habit of going to hear it. I didn't even make it to any of the other films in the Cinemath series.
That makes me a bit depressed in general, to be reminded of all the wonderful opportunities out there which I haven't been taking advantage of. Aaron Swartz just complained about Chicago being boring (which I don't agree with -- Biella's there at the moment, so hang out with her and Chicago won't be boring!), but anyway San Francisco and everywhere else is interesting in proportion to the effort you put into taking advantage of it. I'm realizing that I haven't been making such a serious effort compared to what I could be doing -- seth-trips notwithstanding. (My recent trips to Portland and D.C. put me even more in mind of this; I've only been overseas once, but even the major cities of the U.S. call for a couple of lifetimes' worth of exploration. Amy was speculating about the proverb which claims that only boring people get bored -- there are corresponding proverbs which say that, if you're tired of <CITY>, you're tired of life.)
But, as I was saying, I got to see N is a Number, and ran into several people I knew -- Kragen, Beatrice, and Praveen, the LNX-BBC developer Curtis, and Rohit Khare, of FoRK fame, whom I hadn't met before. We went out to dinner and Rohit, a huge baseball fan, watched the final game of the World Series. (I think most of the rest of us were trying to ignore it; Kragen, in particular, positioned himself facing directly away from the television.)
Friday took me to D.C., where I visited Amy and hung out with lawyers. I continued to feel that D.C. looks a lot like Boston, except for the marble or faux-marble public buildings. I have a sense that it's difficult for me to believe in the reality of any major city I haven't either lived in or visited regularly. (Chicago was an exception. Elsewhere, though, I seem to visit a new city and say "Aha, this city looks like...", and supply the name of some other city I actually believe in.)
I also got to see my friend Cate from high school -- now well-established in the adult world. Wonderful! It's too bad I missed my reunion this year; I'd like to know what more of the people I knew in high school are up to. I guess there's no substitute for e-mailing them directly.
42,000 people marched against the war in San Francisco, and the protest in D.C. was described as the largest since the Vietnam War.
Riana's actual description of the contents of the gold room at Powell's is "literature that isn't taken seriously ... yet".
I still haven't written up notes from the second Microsoft meeting or from the TCPA or LaGrande meetings. (I'm sorry about that, because I know people want to read them.) But I did get interviewed for, and quoted in, a pretty good Associated Press story about trusted computing.
Seth Schoen, staff technologist at the Electronic Frontier Foundation, said incompatibility is the biggest threat posted by the trusted-computing initiatives."I don't think anyone can absolutely compel you to do anything in particular," he said. "What they can do is create an incompatibility or refuse to deal with you unless you meet a particular condition."
I tried to stress that nuance in the interview, and the interviewer reproduced it pretty accurately -- although it might be less significant than I've made it out to be (in the sense that the pressure to conform to a condition might be so strong that it would be difficult for many people to refuse).
I liked the AP story, though it's not technical. I gave a longer interview to Technology Review, which is doing a story which I hope is going to be a bit more technical.
I'm likely to start a new blog at EFF pretty soon containing my discussions of EFF-related issues and news items. (Once I do that, I'll link from here to what I write there, but probably move much of the actual writing to that new forum.)
My owner override idea was meant as a thought experiment to raise the question of whether trusted computing can be implemented in a way which makes it useful to allow you to trust your own computer and doesn't facilitate having your computer perform functions you don't want it to.
As security experts point out, "trust" has a different connotation in security than it does in everyday language. In Ross Anderson's FAQ:
Or take a civilian example: suppose you trust your doctor to keep your medical records private. This means that he has access to your records, so he could leak them to the press if he were careless or malicious. You don't trust me to keep your medical records, because I don't have them; regardless of whether I like you or hate you, I can't do anything to affect your policy that your medical records should be confidential. Your doctor can, though; and the fact that he is in a position to harm you is really what is meant (at a system level) when you say that you trust him. You may have a warm feeling about him, or you may just have to trust him because he is the only doctor on the island where you live; no matter, the DoD definition strips away these fuzzy, emotional aspects of `trust' (that can confuse people).
(Emphasis added.)
So, to be more precise, I should say that the thought experiment asks whether you can have a trusted computing system which helps make your computer more worthy of your trust, without allowing your computer to do things you don't want it to do. In the more technical sense, you already trust your own computer all the time, which doesn't have anything to do with whether your computer is secure. (If you trust an insecure computer -- for example, by typing a passphrase on a machine with a keylogger installed -- you might suffer some adverse consequence.)
The owner override idea is directed toward one part of that question, but the other part is also interesting. Is it reasonable to trust a computer which hasn't been under your physical control at all times? (At the airports, they've stopped asking whether your bags have been under your control at all times since you packed them.) Is it reasonable to trust a computer which is owned and regularly physically controlled by another person? People constantly do trust computer equipment which isn't theirs; by doing so, though, they expose themselves to certain risks. Can those risks be eliminated?
Here's another example: you go to a random terminal, and you want to use it to connect to your own computer. You will have to trust that the terminal will let you use services on your machine in a way which respects your privacy.
With something like Palladium, the machine can show you a user interface which suggests that it's trusted to be running a particular platform. (In our second Microsoft meeting, we talked a little more about the user interface question.) But if that user interface is widely known and standardized, it can presumably be faked -- and if a machine normally lights a LED or something to show that it's in a certain mode or running certain software, that LED can be faked, too. (It's easy enough to find the LED's leads and connect them to a power supply instead of to the pins on the motherboard which are supposed to be indicating something about the current CPU or chipset operating mode!) In some scenarios, the user interface can share a secret with the end-user, but that doesn't seem to help much if the end-user is currently using a physically different machine from his or her own home box! (Sharing a secret with the user interface is helpful only when the user interface is provided by a device which knows the secret, which is not the case in the remote login situation.)
However, there is a possibility which was suggested at one point by Microsoft: your machine can make a cryptographic challenge to try to determine some characteristics of the device from which you're trying to connect (so that, if you don't get a connection, you know something is up, and in any case access won't be granted). The terminal could still steal your password, but the use of one-time passwords (with trusted password-calculating devices) or other trusted authentication hardware, like smart cards, can prevent your password from being taken in this way.
In addition, Palladium is going to provide a secure I/O feature, so the client software on the terminal you're trying to use (which can prove its identity to your server) can read your keystrokes and your server can know (when it grants you access) that you're accessing it using a hardware and software combination which sends your keystrokes only to your server, and your server's responses only to your eyes. That sounds pretty good, and your server can enforce this policy by forbidding connections entirely from systems which fail the relevant challenges (which can't prove that they are running certain software in a certain mode with certain capabilities). So far, so good.
However, we already know that secure I/O can be defeated by hardware attacks. If a recording device is placed in hardware between the keyboard and the motherboard, or inside the keyboard itself, the fact that the motherboard and software haven't been modified won't protect you! So your server can correctly authenticate the hardware and software platform of the terminal you're using to connect, while knowing nothing of the hardware bug which has been placed inside the keyboard you're using to talk to the terminal.
So it might be that there is no ultimately reliable way to trust someone else's hardware (or, "don't make a phone call on someone else's embassy's telephone, even if it's a secure phone").
The idea of a world in which the end-user's PC is irrelevant, yet the user still has strong security assurances, seems implausible to me. Some of the trusted computing advocates who have come to talk to us have imagined that world, and suggested that you could use essentially any device to access essentially any service -- the individual computer would become more fungible. But because of the new platform authentication capabilities which would become available, the security properties of the resulting interactions would be verifiable, and verifiably what end users would want them to be.
But that doesn't make sense if people can and will modify hardware -- keyboards and monitors -- to subvert Palladium or LaGrande secure I/O! A device like KeyGhost will be really cheap soon. (In fact, the basic version is already under $100.) KeyGhost even sells entire keyboards with the monitoring hardware built into the keyboard -- and tries to make their keyboards look indistinguishable from any other keyboard. So in some sense it is really not going to be ultimately safe to trust someone else's equipment.
I say this realizing that the status quo is not any better, and is probably worse. I used ssh to connect during my trip to Portland and Walla Walla, so I can claim that my communications were "secure". I even memorized part of the ssh host key fingerprint for the machine I was connecting to. But I connected from at least five machines whose software configurations I had no way to verify at all and which could all easily have been running keyloggers or screen grabbers.
Trusted computing systems could raise the bar slightly. For example, they could require the use of a hardware keylogger instead of a software keylogger, which would then cost $89 instead of $0. But attackers can be fairly determined, and Bunnie argued that hardware attacks do not imply a fundamentally greater sophistication or skill, only an incrementally higher cost (for physical fabrication of a device, whereas the marginal cost to duplicate software approaches zero). I'm not sure that trusting hardware instead of software, when the hardware is owned by someone else and remains outside of your physical control or supervision, is going to be any better in the long run.
A better solution is probably to have a minimal amount of physically small hardware which you trust, with both input and output capabilities which you also trust -- something like a PDA or a laptop -- and an untrusted network to which it's always easy to attach that device.
This isn't always going to be practical.
I was talking to several people about my claim (which Felten linked to) that trusted computing systems don't diminish your computer's usefulness as a "general purpose computer". I said that a Palladium machine or a TCPA machine or whatever is definitely still in every sense a general-purpose programmable computer. (In fact, it's usually still a general-purpose computer even when it's running in a trusted mode -- although the argument is made even easier by the fact that these systems all are supposed to allow you to use the computer in a traditional mode with the trust features disabled.)
If you want to focus on DRM applications built on trusted computing, and see the technology as a conspiracy against users, I have an analogy which shows how you still keep general-purpose computing. This analogy makes a lot of sense to me, and maybe it will make a lot of sense to you. The analogy is partly metaphorical because it's not a technical description of the implementation of a trusted computing system; it's just a description of one outcome which is attainable.
Right now, you might have several different electronic devices at home; maybe one of them is a computer and another is a stereo, or a DVD player, or a VCR (preferably one which was manufactured some years ago and does not conform to the requirements of 17 USC 1201(k)). Each of these devices is shipped in its own separate box.
But, in the future, instead of having just "a computer" in one box and "a proprietary media player" in another box (like a DVD CCA-licensed DVD Video player, or DiscoVision), you can imagine that you get a computer as one component and a proprietary media player as a second component. These components are then bundled together in one box. You could implement this in such a way that the two components are entirely unaware of one another, but we'll assume instead that the components know of one another's existence. They can communicate via some kind of open standard interface, which we could imagine is PCI or FireWire. (That's not how this is actually implemented, but this is a metaphor, remember?)
In that case, when you want to use computer features, you just flip a switch or type a command or otherwise perform some action on some user interface so that you're talking to the "computer" component. And you can tell the "computer" component what you want it to do, and it will do it for you, just the way it does now. When you want to use some proprietary media, you flip the switch or perform the action so that you're talking to the "proprietary media player" component. Now you can ask it to play proprietary media, and it will do that, but you can't ask it to do certain other things for you, because that component isn't the computer component, and it doesn't understand how to do those things, or it isn't willing to do them. You can also use the two components together in certain ways. For example, you could use the computer component to download encrypted documents over the Internet. The computer component doesn't understand how to read these documents, because it doesn't have the decryption key, but you can ask the computer component to send these documents over to the proprietary media player, which may possibly have the appropriate decryption key and may be able to decrypt and display the contents of those documents, subject to various arbitrary and irritating restrictions.
The proprietary media player can thus make use of the computer to get certain (untrusted) network and communications services, and possibly certain (untrusted) storage services, and possibly certain user interface services, and so on. But the computer component in general doesn't trust the proprietary player component, and the proprietary player component in general doesn't trust the computer component. They are separate in design and separate in functionality, and neither one can see inside of the other and neither one can control the operations of the other. They can communicate only over a precisely-defined communications interface which doesn't put either device in control of the other device.
If you want, you can choose never to use the proprietary player, and only use the computer component. The computer component will continue to function normally as though the proprietary player weren't there at all; of course, it will continue to play non-proprietary media. If you get a copy of a suitable decryption key, or you run suitable decryption software, you can even use the computer component to decrypt and play proprietary, encrypted media. The proprietary player can't stop this -- it can't even tell that you're doing this, because it can't look inside the computer. And there's a corresponding limitation: the computer can't look inside the proprietary player to try to extract keys or to try to extract decrypted information. If you want to try to break an encryption system, using the computer component, you will be on your own; the proprietary player won't give you any additional information you didn't already have.
The point of this metaphor is that it's possible to have general-purpose computing functionality, which is under your control, packaged in the same box with some additional functionality which is not general-purpose and which is not under your control. And if you do this, you might get something which it is possible to see both as a benefit and as a disadvantage. The most obvious disadvantage is that, if the combination became widespread, publishers might eschew open standard formats which the computer component could read, in favor of proprietary formats which only the proprietary player component could read. (They wouldn't be able to get away with that if nobody had the proprietary player component in the first place!) This outcome would tend to give you less flexibility, power, and control, and diminish the benefits which you would otherwise have achieved with general-purpose computing. But you would still have general-purpose computing capability and the ability to write and run competing software.
As I argued a few days ago, you still have Turing-completeness (but for that little detail about needing an infinite amount of RAM) -- you can build a Turing machine and you can paint it blue, and it's still a Turing machine, or you can build a Turing machine and put it in a box with some other kind of machine, and it's still a Turing machine. Maybe the other kind of machine is something you find very distasteful, and maybe the other machine will be used for something you consider quite nefarious, but the Turing machine is still a Turing machine.
I had a lot of time to read while I was on trains and airplanes recently, so I read the entirety of Harmful to Minors, by Judith Levine. Levine's book is dedicated to arguing that children's sexuality and sexual experience is legitimate and can be a positive thing, and that attempts to suppress it or pretend it doesn't exist can have negative consequences.
I was surprised at how much of the book was dedicated to discussions of sex education. The other surprise was Levine's insistence that childhood sexual experience is reasonable and appropriate. (Less radical advocates often suggest that childhood sexual education, knowledge, fantasy, desire, discussion, etc., are appropriate, but physical contact may not be. For example, many people I know think that young people should be able to view explicit discussions and depictions of sexual acts, if they want to, but not necessarily to participate physically in those acts themselves. Levine has a much more radical sex-positive view and does not seem to want to be held to a sharp distinction between ideas, images, and acts.)
She spends a great deal of time talking about safe sex and birth control, which reminds me of the passage in Summerhill where Neill seems to suggest that he can't allow the young students at his school to have intercourse because they might become pregnant -- but he doesn't necessarily see an abstract reason why they shouldn't do so otherwise. (Neill wrote in an era when birth control and abortion were less widely available, and less reliable, than they are now, to say nothing of their unpopularity. Maybe if birth control and abortion services had been readily available, Neill would have chosen to permit his students to have sexual intercourse! When I attended boarding school, I felt subjectively that the school's attempts to discourage sexual contact were less a result of concern about sexual morality or emotional development and more a result of concern about pregnancy. This is in line with Neill's suggestion that pregnancy was his greatest fear for his students; I suspect that many schools would turn more of a blind eye to older teens' sexual activity if the "outward consequences" of pregnancy and STDs could be eliminated.)
Since I had more interest initially in topics like Internet censorship, I regretted that Levine spent so little time on them. She also gave too little attention to questions of emotional development and maturity (what liberals often worry about when thinking about young people's sexual activity), since she had such a strong focus on dissing conservatives' moral anxieties and promoting safe sex and sex-positive attitudes.
What do young people in the U.S. actually believe about sexuality, and why? What are the influences of religious and political belief, educational background, social class, temperament, personal and family experience? (There are many anecdotes about young people's beliefs, but usually in the service of some particular argument. And the statistics provided are more often about behaviors than about attitudes and beliefs. I wanted to know more about what sexuality means to people, a question Levine sometimes seemed to be neglecting.)
I also re-read From the Mixed-Up Files of Mrs. Basil E. Frankweiler, a children's book I'd read in elementary school. I think I found it more plausible, and more exciting, the first time around, although there are some parts which continue to be touching.
I'm now working on Lakoff's Moral Politics, which I got as a birthday present; I'll write more about that when I finish it. I've also borrowed some interesting books from Amy, and I'm hoping to keep working on Personal Knowledge, which I put aside a while back.
I was in D.C. for several days, and a lot of things happened, and I found my trip extraordinarily worthwhile.
Thanks!
"Fair Use" or "Lawful Use"? Oh, definitely call it "lawful"! Everybody in this town worries about what's lawful, but nobody cares about what's fair.(a D.C. journalist)
Happy birthday to Aaron.
I found out why it seemed that I had so little clothing: Ben came by and returned things to me from my Spring Lake camping trip. Now I have a more reasonable amount of clothing again.
It's rainy here, as it was rainy in D.C.
We had a BBC meeting in the East Bay, and I got to see Andrew and Duncan, aside from the more usual suspects. So that was nice. I was just very tired, because my sleep's been strange lately.
I also got some work done on the BBC, and, thanks to a tip from H. Peter Anvin, I think I may resolve the memtest86 problem very soon. We all concluded that the new BBC is almost ready. Nick revealed in a relatively public way the information I'd given the group: there are two organizations which want to use the BBC in connection with end-of-the-year fundraising purposes.
The BBC is really coming along well at this point.
Te totum applica ad textum:
rem totam applica ad te.(J. A. Bengel, preface to the hand-edition of the Greek New Testament, 1734 (quoted in D. Erwin Nestle, preface to Novum Testamentum Graece et Latine (Stuttgart: Privilegierte Württembergische Bibelanstalt, 1932)); also given, more elegantly, as "Te totum applica ad textum; textum totum applica ad te.")
and
... there we can shake off our label
and I'm not an artist
and you're just an angel.There we can finally relax
and the lines will erase
from your beautiful face
and we'll both find a love with no future or past.[...]
There we're going to shake off our label
and you're not a scientist
I'm still your angel.There we're going finally relax
and the lines will erase
from your beautiful face
and we'll both find a love with no future or past.(Atticus Scout, "Measure of Time")
I had the longest single basically uninterrupted conversation I've had in about two years.
I had a vacation on Monday on account of Veteran's Day. Brita came all the way across the Bay to visit me, and we got to eat sushi and go down to the SF MOMA. And after that I took a ferry across the Bay and then right back immediately. The Golden Gate Transit ferries are really cool.
When Brita and I went to the art museum on Monday, we spent most of our time in the exhibition "Gerhard Richter: Forty Years of Painting". I hadn't heard of Richter before (just as I haven't heard of most contemporary artists at all); some of his paintings were based on photographs and looked photographic, others were totally abstract, and others were realistic but out of focus. Brita and I kept wondering if our vision might be failing us, but the effect turned out to be deliberate.
One of Richter's most famous paintings is Onkel Rudi, which depicts his Uncle Rudi in a Nazi uniform. (Notes in the exhibition said that this painting was based on a picture in a family photo album.) I looked at it for a long time. What's particularly disconcerting about it is that it really looks like a picture from a family photo album. Rudi doesn't look evil or genocidal or menacing at all. He looks happy, he looks proud, and he looks for all the world like somebody's uncle.
I'm used to seeing pictures of Nazis fighting (in the movies) and murdering people (in books about the Holocaust). I'm not used to seeing them in photo albums. The exhibition went on to note that Rudi had just recently been commissioned when the photograph was taken, and died just a few days later.
A lot of families have Nazis and other traditional villains in their recent family history; some have pictures in photo albums and others may have surreptiously, quietly censored those albums. I know from talking to a high school friend that it can be particularly painful if you know about it; after a few conversations with her, I understood why many families have tried to alter or expurgate the historical record, and why many more lie to their children about the details of what particular people did. "What did you do in the war?"
In that generation, my family members were victims of the Nazis, or refugees from the Nazis. Some of them were very virtuous, and others perhaps were not. But I can't help thinking that there must be some generation, past or future, in which my family members are the villains.
This is a small part of what you might think about when you look at Onkel Rudi.
Our build developed some errors at the beginning of the week, but I think people managed to straighten them out. But the week turned out to be very turbulent for the LNX-BBC project. We moved to new hardware -- a very fast AMD Athlon -- for our build server, and Nick started to experiment with ccache, a "compiler cache" program which remembers the results of compiling particular sources, so that builds become faster after they've been run once.
As you might imagine, ccache is by Tridge. Go Tridge!
The new machine made builds (which used to take about eight hours) complete in two or three hours. The new machine together with ccache made builds complete in what seemed to be under an hour, which was very impressive (because it means that it would actually be possible to test the results of a particular small change by waiting for a new ISO image and burning it to CD).
Unfortunately, the new machine has turned out to be very unreliable; its memory becomes corrupt and we get intermittent compile failures, often with a sig11 error (something I hadn't actually experienced since I had some bad RAM in my old 486 machine). So the new server is down now, pending the availability of some hardware which will work reliably.
In the meantime, we managed to fix a number of bugs. I'm currently working on a system to allow various things to be downloaded from the network and to have their signatures checked with GPG. This is a part of having a better and more secure downloadable package infrastructure, and also allowing people to create custom BBCs more easily.
So I'm writing a shell script and trying to think of every possible case, including cases we don't use ourselves.
I'll be speaking at The Revenge of the Blog at Yale Law School on November 22, which is Friday.
I'm hoping to submit something to CFP 2003.
Thanks to Cory, I've now got one of NTK's new "Corrupt Disc Inferior Audio" t-shirts, which protest against corrupt CDs. It's very pretty.
Remember Moen's Law of Bicycles!
I wrote a letter to Wolfgang. It was surprisingly short (only about ten pages), but it took up a lot of energy and concentration to write it. I suppose it has extremely high entropy.
This joke is adapted from Riana:
Q. What does a Supreme Court justice who reviews laws subject to free speech challenges eat for dinner?A. Thyme, plaice, and manna.
(They ask us: What is plaice? We tell them: "Plaice \Plaice\, n. [F. plaise, plais, prob. fr. L. platessa flatish, plaice. See Place.] (Zoöl.) (a) A European food fish (Pleuronectes platessa), allied to the flounder, and growing to the weight of eight or ten pounds or more. (b) A large American flounder (Paralichthys dentatus); called also brail, puckermouth, and summer flounder. The name is sometimes applied to other allied species. [Written also plaise.]" (1913 Webster (gcide)))
Song parodies somebody ought to write: "The Promise of Leaven" (an Aaron Copland number about the end of Passover).
I've been asked to collect in one place a set of pointers to everything substantial I've written in public about trusted computing. So I've tried to do that below; I hope I'm not missing anything. In most cases, you'll have to skip over a substantial amount of unrelated material in each diary entry.
I have also written one piece about trusted computing which is probably not well-known to most readers here; this is a message to Nick Moffitt's "crackmonkey" mailing list, responding to an anti-trusted computing piece in Linux and Main. (Topics: running a non-Microsoft operating system on TCPA or Pd hardware; what is an "end-to-end security" measure; coupling policy enforcement to access to decryption keys; why this could put users at a disadvantage even though it gives them new functionality; DRM support in hard drives; document revocation; claims of scary features in Windows Media Player; network effects, interoperability, reverse engineering; CBDTPA; Palladium does not give Hollywood what it wants; incentives for users and companies.)
I'm soon going to start writing about technology on an EFF-sponsored web log, as I've already mentioned. That will probably mean that I'll write very little about technology here in the future.
By the way, I think my original post about epistemology was the most interesting of everything I've written about trusted computing. I know at least one other person who agrees with me.
That particular discussion also made its way into a science fiction story:
"It is like Descartes," Murray said, accelerating up a new hill."Yeah?" Liam said. "Who's God, then?"
"Crypto," Murray said.
More seriously, though, I think computers have given us a new kind of understanding of the problems of epistemology, much as they've given us new ways of thinking about psychology. This is not to say that the metaphors we take from computing are more accurate or ultimately more faithful to reality. But they're undeniably present.
When we think about thinking and about experience, we draw on what we know about computers and what we've encountered as programmers and as computer users. Turing, who had more knowledge of computing than any of his contemporaries, made this parallel explicit and started decades of academic debate about just how literally it ought to be taken. In the past, metaphors for simulation were always dreams (Chuang-tzu, Descartes), the theater and the arts (Plato), or games. But now we have actual simulations (physics experiments run entirely in software!) and emulation (hardware environments, tantamount to sensory experience, conjured up by emulator code). Just as nobody who has had a vivid dream can be quite sure of reality, nobody who has run a program under an emulator can have quite the same certainty about reality.
Only in our time could someone like Ed Fredkin seriously suggest that our universe was a computer simulation. The idea that it is a simulation is old; people used to say that the world was the dream of God, or, in Carroll, of the Red King:
"It's only the Red King snoring," said Tweedledee."Come and look at him!" the brothers cried, and they each took one of Alice's hands, and led her up to where the King was sleeping.
"Isn't he a lovely sight?" said Tweedledum. Alice couldn't say honestly that he was. He had a tall red night-cap on, with a tassel, and he was lying crumpled up into a sort of untidy heap, and snoring loud -- "fit to snore his head off!" as Tweedledum remarked.
"I'm afraid he'll catch cold with lying on the damp grass," said Alice, who was a very thoughtful little girl.
"He's dreaming now," said Tweedledee: "and what do you think he's dreaming about?"
Alice said, "Nobody can guess that."
"Why, about you!" Tweedledee exclaimed, clapping his hands triumphantly. "And if he left off dreaming about you, where do you suppose you'd be?"
"Where I am now, of course," said Alice.
"Not you!" Tweedledee retorted contemptuously. "You'd be nowhere. Why, you're only a sort of thing in his dream!"
"If that there King was to wake," added Tweedledum, "you'd go out -- bang! -- just llke a candle!"
"I shouldn't!" Alice exclaimed indignantly. "Besides, if I'm only a sort of thing in his dream, what are you, I should like to know?"
"Ditto," said Tweedledum.
"Ditto, ditto!" cried Tweedledee.
He shouted this so loud that Alice couldn't help saying, "Hush! You'll be waking him, I'm afraid, if you make so much noise."
"Well, it's no use your talking about waking him," said Tweedledum, "when you're only one of the things in his dream. You know very well you're not real."
"I am real!" said Alice, and began to cry. "You won't make yourself a bit realer by crying," Tweedledee remarked: "there's nothing to cry about."
"If I wasn't real," Alice said -- half-laughing through her tears, it all seemed so ridiculous -- "I shouldn't be able to cry."
"I hope you don't suppose those are real tears?" Tweedledum interrupted in a tone of great contempt.
Today, Alice would see a computer running an enormous simulation in place of the snoring King.
It's common to hear that software is different from mental processes because we can see exactly how software works, but can't do the same for mental processes. This may be true, but software can't see inside of itself any more than a person can really see the operation of his or her own mind.
Some programmers don't believe that. "I can read my program's code or disk, or even in memory while my program is running! That's how viruses work; they have to be able to read their own code in order to copy themselves!"
But anybody who's played A. K. Dewdney's Core War knows about the unreliability of programmatic introspection. Core War programs are fighting other programs in RAM, trying to corrupt and destroy and crash the enemy code, while protecting their own code. In the multithreaded version of Core War, it was common for programmers to implement a copying routine which tried to relocate code in memory, an integrity-checking routine which looked for errors introduced by writes from hostile code, or perhaps both (a routine to make multiple copies of a program and then constantly compare them against one another to try to detect the presence of errors as soon as they were introduced).
The trouble is that all such self-monitoring code runs in the same memory space as the rest of a Core Wars program. As such, it is itself vulnerable to attack. A checksumming routine could be disabled or altered in mid-checksum. A copying routine could be altered and induced to write a corrupted copy. An entire subroutine could be overwritten with a block of code performing an entirely different function. Any individual test can be reversed, turning "if x" into "if not x".
As I've discussed elsewhere, programs which examine themselves for reasons such as enforcing restrictions against a user are also vulnerable to modification. Perhaps a program checksums itself before running (as many programs do); the result of the checksum has to be examined somewhere, and that examination has to be performed by code, and that code is modifiable. Virus scanners also want to protect themselves against alteration, so they frequently run all kinds of self-tests. A clever virus which was specialized to attack a particular scanner would find the proper entry point to bypass the self-tests, but also initialize any relevant memory locations to indicate that the self-tests had completed successfully. If self-tests occur later on, during the virus scanner's actual execution, the virus would have to determine where these tests occur and overwrite their code, too. But there are at most a finite number of tests which can occur, and an attacker can ultimately locate and alter all of them.
We can actually get much sneakier than this. A program generally assumes that it can obtain and dereference pointers to (1) various system objects or data structures, and (2) its own code. This assumption is generally valid on most systems, subject to some kind of security policy. But there is no technical reason that the result of dereferencing a pointer has to be correct. There is no reason that the machine (if designed by or under the control of an attacker) need ever perform according to its specifications. It's entirely possible to create a virtual machine in which reads from memory occur successfully and describe a consistent but completely inaccurate memory state. Techniques like this are known to the authors of rootkits, which are now able to alter operating system kernels. You can imagine a rootkit which alters an operating system kernel so that software on the system no longer has access to read the memory where the rootkit resides, but believes it does; accesses to that memory could result in plausible but completely misleading results.
You can proliferate examples of what attacks like this might be capable of. The really interesting one for me is a program which is deceived about its own state in memory. It might go through and analyze itself and conclude "OK, my code has just done this" or "my code is about to do that" or "I can guarantee that my code will never execute the following instruction" or, as above, "my code has a valid checksum or signature, showing that it's unmodified from its original version". And the program can be justified in concluding any of these things, but it can still be totally wrong; it can't look at itself directly, but always and only through the mediation of the underlying system, which might be a completely deceptive virtual machine.
Of course, this kind of deception can occur for reasons other than an attack by a human or a rival Core Wars automaton. Imagine that you've written an implementation of an error-correcting code which looks at blocks of memory and finds and corrects errors resulting from hardware faults or cosmic radiation. Now, your error-correcting code also has to run in memory, and it can use the same error-correcting system and can try to correct errors within the ECC routine itself. But since the error-correcting code is running in memory, if a hardware fault occurs, the routine may give an inaccurate answer, and falsely claim that there is no error at all.
Our own thought processes are famously opaque to us, as are our emotions; even when we practice introspection, it seems that we don't really have reliable knowledge of how we think. (You can make an empirical claim about this, as George Lakoff seems to do regularly, and say that people's claims about their own thought processes are inconsistent with their behavior or with other things they say about themselves. You can also make a more abstract claim and delve into thought experiments in which consciousness is produced by a mechanism to which we have no access but includes the illusion of access to part of that mechanism. Feynman once had a dream that he had figured out some surprise aspect of how his mind worked, but when he woke up, his insight turned out to be totally baseless.)
In that sense, we are in the position of software: we can try to look at ourselves, but we can't have independent confirmation that what we see is really there. There is always a philosophical possibility that we are implemented somewhere or in some way we don't know about, that we have a particular feature we can't anticipate, and in general that any part of our experience, not just our senses, could be unreliable. A computer program implemented on reliable hardware which performs according to spec is guaranteed never to add 2 and 2 and get 5 (or to divide 4195835 by 3145727 and get 1.3337), but the software itself can't tell whether the results of instructions it requests are correct, having no truly independent way to verify them. "To them, reality would be the results of the execution of their opcodes." If a hardware flaw does occur, a program's results will be wrong, and the program will not necessarily have any way to tell. The same is true of humans; as sane people, we can see why 2 plus 2 equals 4, and see why it's impossible for 2 plus 2 to equal 5; but it's by no means impossible for a person to have the experience of believing that 2 plus 2 equals 5. There is no guarantee that we will remain sane and there is no ultimately certain way that we can test our own sanity at any chosen moment.
One strange result of insanity is that it is only sometimes apparent to the person afflicted with it. Many people with serious mental illness are aware of it, and understand its significance, but even this is not guaranteed to make the experience seem any less real. (Understanding that a phobia is unreasonable, for example, may not lessen its power at all.) Some people who become insane are adamant that they are sane and that everyone else is insane, and many people have been shaken by the plausibility of such claims. Your brain could change in such a way that almost any given aspect of your experience was altered; in fact, it may already have changed that way, and you may not know it, and you might never know it.
My observation is that computers have made such possibilities more present and more plausible to us, and given us a new way to think about them. They have made us speak of what we are "programmed" to do or to think, how little we know about our own "programming", and how little we can hope to control it.
The classic question in the face of this has been "Are you insane at this moment? How do you know?". This question seems to infect any epistemology which aims at absolute certainty; even if we assume that almost every conclusion of Descartes followed necessarily from what came before it, the possibility would still remain that he was insane and had simply imagined some particular detail, or systematically added or dropped a "not" at some point in the deductive process. (Imagine if you were selectively blind to a particular color; you wouldn't have any direct experience to indicate that you were missing anything. Only other people's disagreement with you would suggest a problem.) The existence of insanity is corrosive. People have struggled for a long time to try to redeem Cartesian arguments. I think they have never done so. If someone asked me how I know whether I'm insane, I would say that there's a lot of evidence for my sanity but that it's always possible that I'm totally delusional. I can't look inside my mind to see whether it's working properly; even if I could, I would still have to use my mind to make that evaluation, so that insanity could always alter my judgment to make itself undetectable -- just like a rootkit patching a kernel to conceal itself.
I should talk more about the possibilities of breaking the abstraction barrier which makes the "implementation" of our subjective experience opaque. It seems that we often think of this as disturbing or improper; we seem to feel that we ought to deal with our own consciousness only through its high-level interfaces (such as language). If you are actually analogous to software running on an interpreter, you have many different abstraction layers, and (like a complex software system) you can be affected on almost any of these, and (also like a complex software system) one layer may not have any real sense of what is happening at another layer. I think there is a real moral sense to this: when B. F. Skinner argued that we could work more directly on lower levels by taking advantage of insights from biology -- in particular, by practicing conditioning on people -- people were horrified, and, as he observed, complained that it was contrary to human dignity to do so. Maybe one meaning of human dignity is interacting with someone's mind on a very high level (say, at the level of dialogue and debate); violating human dignity would them mean interacting with someone at a lower level ("close to the machine", in some sense).
I've had a cold for the past several days. I hope I can get rid of it before I go to the East Coast!
If I get over my cold in time, I'm going to watch the Leonid meteor shower. But whether or not I get over my cold, you should watch the Leonids! "Best show in 50 years -- again!", etc., etc.
(If you don't have information about the shower yet, try a Google search for "Leonid", or, perhaps more usefully, a Google News search for "Leonid". Get out there and look up!)
My local Walgreen's drug store has a "holiday card" section. Most of the cards are Christmas cards with Christmas decorations and slogans written on them. One of the cards caught my eye; it had Hebrew text repeated over and over again on the outside. I guessed that it must not be a Christmas card; I looked a little more closely. So what did the card say?
L'shana tova tikatevu
That's right -- it's a Rosh Hashanah card.
This is trivial, but extremely useful:
#!/bin/sh KEYSERVER=pgp.dtype.org # you can also "gpg --search-key $1" instead of gpg --recv-key $1, # and then provide something like an e-mail address instead of keyid, # if you know that the identifying information you'll provide is # going to be unique with respect to your keyring gpg --keyserver $KEYSERVER --recv-key $1 && gpg --sign-key $1 && gpg --keyserver $KEYSERVER --send-key $1 if [ $? != 0 ] then echo 'failed for some reason -- run the program again?' exit 1 fi ADDR=$(gpg --list-keys $1 | head -1 | cut -d" " -f5-) (cat << MESSAGE This is an automatically-generated message to let you know that I have signed your key. My signature is included below. (I have also uploaded my signature to the keyserver $KEYSERVER.) MESSAGE gpg --export --armor $1) | mutt -s "I have signed your key" "$ADDR" && \ echo "Notification sent by e-mail to $ADDR"
Contact: Seth David Schoen
