Vitanuova for 2002 August

<M <Y
Y> M>

DEF CON special edition diary post coming tomorrow! Watch this space (so to speak)!

I spent the weekend at DEF CON X in Las Vegas. It was fantastic!

After that, I spent the week at USENIX Security in San Francisco. That was fantastic too!

Thanks to both DEF CON and USENIX for donating conference admissions to EFF.

I'm sorry this entry is so late! It was a long time in the making, and it kept getting longer over the course of the week as things continued to happen.

Our crew at DEF CON was full of Praveen's friends, and more and more of them arrived all the time, by various methods. We drove to Las Vegas through the desert in a large van. We stayed at the Alexis Park, which is the DEF CON conference hotel. We were joined intermittently by lots of other people, many of them from New Mexico. Jennifer 8. Lee, a very friendly reporter for the New York Times Circuits section, hung around with us a lot, too.

I met Jenny at DEF CON last year, and she got involved in covering DMCA issues, so I had occasion to speak with her a few times after that. She covered one of the Free Dmitry marches in San Francisco. But lately she's been writing about technology for Circuits and not covering politics. My father (not knowing that I know her, as far as I know) sometimes sends me her articles in the mail.

The story of Jenny's name is interesting, and we talked about it a lot last year. But this year, it was old news (so to speak).

DEF CON generously donated a booth to EFF, and we had a bunch of volunteers staffing it throughout the weekend. Our booth was amazingly popular: we gave away 50 EFF secret decoder rings in the first hour of the con, and we ran out of essentially everything (t-shirts, stickers, hats, etc.) by the end of the first day. We got dozens of new members and hundreds of donations.

People at DEF CON really seem to like EFF a lot. I also got to talk about a lot of people about current and potential EFF cases, and hot topics in computer security.

I saw a dozen people I knew, or more.

We ate out a lot, generally at buffets and at a really cool restaurant downstairs at the Rio. I don't remember the name of the restaurant, but it was run by The Cheesecake Factory. Also Subway. I miss the Subway in Easthampton.

In one case, we watched the pirate battle at Treasure Island. This is performed several times each evening, using a tremendous aquatic set right out in front of the hotel. (I've never been to a Disney theme park; I bet they have very similar things.) The actors were talented, the stunts impressive, the special effects exciting. Pirate battles!

Q. How does a pirate Unix developer list the contents of a static library?

A. With ar ... -l!

Q. OK, so what does a pirate FCC Chairman call the state of broadcast television in 1961?

A. Avast! wasteland.

Q. OK, so what's a cryptographer's favorite kind of ice cream?

A. Heavenly Hash.

I played Scrabble with Robyn and Meghan. This game had been planned for weeks, and actually happened. I won one game, and lost another. At one point, I managed to play "PRIONS" on a triple word score. I was so pleased with this that I immediately wrote NO MORE PRIONS on my DEF CON badge.

Everybody, now!

NO! MORE! PRIONS!

NO! MORE! PRIONS!

NO! MORE! PRIONS!

We need to get Robyn to come up here for a rematch.

I also played Scrabble with Riana in the van on the way back, but that match was plagued by darkness, lost tiles, and motion sickness, and it was never completed, even though we moved the game off the printed board and into a text editor running on a laptop with a well-lit screen.

On a walk with Dave Weekly and friends, I was strolling down the Strip toward the New York New York, when suddenly we all caught sight of a helicopter, engine running, blades spinning, etc., just about 200 feet back from the Strip, in the middle of what looked like a helicopter. A sign said "HELICOPTER TOURS".

"Let's ride the helicopter!" said David. (If he didn't say so, that's what he thought, anyway.) Most of us, except for Riana (who had just recently flown on a helicopter) and I (who am a fraidy cat) immediately jumped at the opportunity and purchased their first-ever helicopter tickets. It took a lot of cajoling to get me to come along. "Will you regret it tomorrow?" David asked. Well, no, I didn't think so.

The helicopter ride turned out to be absolutely fantastic. It was much smoother and gentler than an airplane, and, unlike an airplane, it could hover. I hardly noticed when we took off, and we got a beautiful, memorable night-time tour of the Strip from above. (More than the Strip, actually; we saw Fremont Street, too.) We passed within about 150 feet of the Stratosphere and saw the people standing on top of it. We flew over famous hotels, and banked sharply so that the helicopter's great rounded glass window was the only thing between us and the Strip 1,000 feet below. (That was the only point at which I felt a twinge of fear. Helicopters can bank through very steep angles.)

All of a sudden, the ride was over; the pilot (who said he'd been flying helicopters for 29 years, and didn't learn in the military) set us down without even a bump. The whole ride had been about 15 minutes.

I went to only a few talks, and didn't feel deeply inspired by most of them. The most interesting was probably Lucky Green's on TCPA (partly because I was going to be on a panel with Lucky on that very subject the following week). I had a couple of gripes with it -- for example, S. 2048 (or "2^11" for short) doesn't mention TCPA or Palladium anywhere. Microsoft has also said that they don't want Palladium to be mandated by law; I'd still like to hear more about what they are doing to prevent that outcome.

There's a pretty interesting debate going on right now on the cryptography@wasabisystems.com list about Palladium. One of the interesting phenomena there is that Lucky will predict some very harsh and likely harmful-to-the-public use of Palladium, and other people will reply "You're just being paranoid! That's not in the spec!". And that answer is correct, in the sense that none of these things are in the spec. For example, the Document Revocation List (DRL) is not in the spec. (There is a side-discussion about the fact that there is no spec for Palladium, and in fact Peter Biddle said he's been referring people who ask for a spec here to Vitanuova!)

Now, a conflict results because Lucky predicts with some confidence that Palladium will be used to do things like the DRL. But it's also the case that the DRL is not "part of Palladium". As far as I can tell, it's something which application vendors would be able to implement under Palladium. (I'm sure the relevant blinding, hashing, and public-key encryption algorithms aren't beyond the reach of protocol designers; when you sent a document to some other party, it could be encrypted with a key which could only be had by authenticating with a server out on the Internet, which demands a Pd certificate and then demands from the Pd-aware application a hash of the document before providing a decryption key.

Of course, you can do something like

{E(SHA1(SHA1(d)+secret), d), SHA1(d)}

Say you're implementing Microsoft Word with a DRL server. So when you want to "Save For Publication" (to the outside world; ordinary Save could still be cleartext), you simply tell a particular DRL server SHA1(d), where d is your document. The DRL server responds by concatenating SHA1(d) with its private secret, taking SHA1 of that, and returning the result to you (over a secure channel). You use this value as your symmetric encryption key, and you encrypt the document and publish it along with SHA1(d).

When you want to decrypt, you need to begin by authenticating yourself to the remote server, in order that the remote server may know that -- if it decides to give you a decryption key -- you will only process the document according to policy, and not, for example, export a cleartext copy. Then, having authenticated your application, and having had the integrity of your environment attested, you tell the appropriate DRL server that you want to decrypt a certain document which has has the hash SHA1(d) -- which you know, because that value was included with the plaintext. The remote server knows that you are an unmodified Microsoft Word running on a machine in trusted mode, because of your authentication steps. The remote server also knows its own private secret. Now it looks into its revocation list and determines whether or not SHA1(d) appears in the list. If so, it returns "Sorry, that document has been revoked because <reason>"; otherwise, it concatenates SHA1(d) with its private secret, calculates SHA1 of the result, and returns that. This is the decryption key needed to decrypt and display the document, and the application is guaranteed to process the document only according to its policy because it has already proved that it is the original, unmodified version of Microsoft Word, running in a trusted environment.

What interests Lucky about this is that it is possible to implement this within Palladium. "Check with a revocation server before displaying this document" is a possible policy, and Palladium allows you to implement and enforce any policy which you can specify in hardware. (The particular protocol above is very crude; I'm just giving it off the top of my head, and it can be improved a lot.) Lucky hypothesizes that such revocation policies will be implemented in Palladium, because application vendors' customers will desire them, and so the application vendors will have an incentive to use Palladium this way.

After all, somebody pointed out during the Dmitry Sklyarov case that Adobe's customers for most of its products, and especially Adobe eBook products, are not the end-users of the documents, but rather the publishers of the documents. In the eBook case, Adobe's customers are not eBook readers (they get the Adobe eBook Reader software for free) but rather eBook publishers (they pay lots of money for eBook publishing software). This is very clear if you read Adobe's statements about the case -- in response to questions about why Adobe eBook Reader restricts you from doing many things (which more useful software like AEBPR does not), Adobe answers, in effect, that such were the requirements of Adobe's real customers, the publishers.

So Lucky thinks that publishers' design requirements will drive implementations of application software implemented under Palladium. And that would mean that, if publishers think document revocability is a good thing, major document-processing application vendors will want to implement document revocability, in order to keep their customers happy.

Lucky's critics point out that such revocation is no part of Palladium, is not in the Palladium spec, has not been predicted or advertised or advocated by Microsoft, etc. And Lucky thinks this criticism is irrelevant, because he's confident that this capability will be used in this way once it exists.

What is the DRL idea? The idea is that an application opening a document first needs to check in with a server on the Internet which will tell the application whether that document has been revoked or not. If the document has been revoked, the application will refuse to open it. So Lucky imagines a particular document suddenly unusable all over the world because somebody has decided to unpublish it.

I also talked to a couple of people about the "responsible disclosure" movement. It seems that a number of people are working on legislation based on the "responsible disclosure" idea. That's exactly what I was worried about when I first heard of responsible disclosure. I thought that codifying responsible disclosure as a particular procedure, and fixing a particular number of days, would give strength to a proposal to create criminal liability for doing vulnerability disclosure any other way. And it looks like that's just what's happening now.

I haven't seen any legislation yet, but I understand lobbyists are already talking with members of Congress about it, and the response from the members of Congress has been quite positive. It's being painted as a "homeland security" or "infrastructure protection" issue (if people publish exploits, then the terrorists ... well, anyway).

Speaking of disclosure, I was pleased to get a chance to chat briefly with a representative of Snosoft, which had recently received a pretty well-known legal threat over disclosure.

It wouldn't be DEF CON without the cool t-shirts, and I bought several. For example, from Halibut Stuff, I got a shirt with a Shell Oil logo, with the caption "/bin/sh". They also have a great RegEx shirt, in the style of FedEx.

I didn't realize that Hacker Jeopardy was a drinking game, so I actually signed up for it, in a team with Lucky and Robyn. We called our team LFSR, because it was made up of Lucky, a Fictitious person, Seth, and Robyn. But once I found out that you had to drink alcohol to compete in Hacker Jeopardy, I dropped out, and that was the end of LFSR -- which is too bad, because I think we were a strong team and might have won.

I had a chance to go swimming a couple of times at the Alexis Park. The weather was always hot enough for it, even in the middle of the night, and even after midnight. It felt really good. That's one use of intense heat, like the heat out in the desert.

We tried to find a health food store -- since Las Vegas supposedly had finally acquired a Wild Oats store -- but when we got to the location we'd been given, there was no health food store in sight. We eventually found a little tiny health food store, which was pretty nice, but not quite a supermarket. The proprietor agreed with our guess that there weren't so many people looking for organic or vegetarian food in Las Vegas.

We left Las Vegas on Sunday, and had a long ride back. I tried playing Scrabble with Riana, as I mentioned above, until I started to feel motion-sick. After that, our conversation turned to lipography, and I ended up having a long conversation with Riana (at least 45 minutes, I think) during which I didn't use the letter "e" at all. (In the days which followed, I wrote a great deal of lipography in "e", which is an art I hadn't practiced since sometime last year, when I wrote some in this diary. It turns out to be lots of fun, and even a bit addictive.)

We also stopped briefly in Boron, CA, where I got a milkshake. Since it was Sunday evening, very little was open in Boron, and we couldn't, for example, buy any ulexite.

"The DMCA was a very flawed law," CEA President Gary Shapiro said. "We signed off on it, and it was a huge mistake."

(Gary Shapiro repents)

During our stay in Las Vegas, I talked to the people in our room about a puzzle I found on that interview riddles page. In this puzzle, there are three men; one always tells the truth, one always lies, and one answers at random. (You can imagine that the latter flips a coin to decide what answer to give, but of course you can't see the coin-flip taking place. You could also say, equivalently, that the coin-flipper always chooses the answer which is least helpful or most confusing to you.)

Now, you have to ask three yes-or-no questions and figure out which man is which. Each man knows who is who. You are not allowed to ask a question whose answer is unknown to the person you're asking.

One of the people in our group gave a proof that the puzzle can't be solved, but it turns out that his proof was incorrect. So I look around on the web and found a correct solution. You should ask person #1 "Is person #2 the truth-teller or person #3 the liar?".

If person #1 answers "yes", then you know that person #3 is not the coin-flipper.

If person #1 answers "no", then you know that person #2 is not the coin-flipper.

Ask the person who is known not to be the coin-flipper "Do you exist?" [or "Am I asking you a question?" or "Are you not the coin-flipper?"]; if he answers "no", he is the liar, and if he answers "yes", he is the truth-teller.

Now you can ask the person who is known not to be the coin-flipper about either of the other people (e.g., "Is the person to your left the coin-flipper?"), and you'll get an unambiguous answer which is either true or false (and you know which, since you know whether the person you're asking is the liar or the truth-teller).

This puzzle was hard (I didn't solve it myself), and the proof that it was unsolvable turned out to be wrong, which shows that you have to be very careful with proofs.

I went to the USENIX Security conference for a couple of days, and met some very famous cryptographers and security researchers, as well as some people I've known from Berkeley or from Linux or EFF connections.

Prof. Felten gave his freedom to tinker talk, which I found interesting (although I've heard large parts of it before). I referred to it as his "tinkertalk".

That talk made me think about the "substantial non-infringing use" rule; elsewhere I've written that we often act as though this represented a very general moral principle, even though the Supreme Court only intended it to describe one situation in which secondary copyright liability would not be found. I asked people at the talk whether they could think of an example of something which lacks a substantial non-infringing use (in the context of copyright infringement), and it didn't seem that anybody could come up with anything!

So I still think this is a pretty deep question. I also asked Felten and attendees a few other things and got interesting replies.

Felten's economic analysis of tinkering is a good start, but I think it needs a little work. It assumes that tinkering produces only positive externalities, whereas it seems that (for example) reverse engineering a DRM system will produce both positive and negative externalities, assuming copyright infringement is counted as a negative externality.

On Wednesday evening, I was on a panel of my own, with Lucky Green (the organizer and moderator) and Peter Biddle from Microsoft. (Peter showed up in the company of Brian A. LaMacchia.) Our panel was very lively, and very well-attended, even though we ran about an hour over our allotted time. Peter talked about how Palladium works, and Lucky talked about why Palladium is terrible, and I talked about why we think Palladium may be harmful in some ways. That made me the moderate on the panel! Can you imagine?

I had a nice time, and I got to give Peter the little Nub pin which Henry had tracked down. I think we had a fairly sophisticated discussion, although the alloted time was very short. I was honored that some very distinguished people chose to attend the panel.

I started off my presentation by saying

I'm going to use the letter 'e' in this discussion. I'm sorry.

About three people in the audience got it. Later on, when the presentations were over and we were about to take questions from the audience, I was sorely tempted to joke

So, before you begin with your questions, you should know that one of us on this panel always tells the truth, one of us always lies, and the other one gives answers at random. You, the audience, have to figure out who's who by asking us only three questions.

But I didn't actually make that joke.

I know some readers will want to know what was actually said during the panel, but I think this entry is already long enough, so I want to omit some of that material at this point. Peter gave a pretty concise and very technical overview of what Palladium's infrastructure is doing, and he said again that my blog entry was a good source of technical detail on the system. Lucky largely reprised his TCPA talk from DEF CON. (Above, I've made it sound as though Lucky gave a talk about Palladium at DEF CON. In fact, I'm just extrapolating his point; his talk at DEF CON was really about TCPA, not Palladium.) In the panel at USENIX, he made an effort to take out TCPA-specific things from his presentation and include points which should be applicable to both systems. That's difficult, at this point; I still want to know more about what the differences are, although I've got a handle on some of them.

There was also a mean joke which somebody else made about Palladium in the hallway. It had to do with the chemical element Palladium, and I think that will be a rich source of humor for the near future.

I had dinner with Biella, D. J. Bernstein, Stig Hackvan, and Dave Del Torto. That was the first time I'd met Bernstein. As you might expect, I talked to him about the Bernstein case a bit.

In economic analysis ... the goal is not to maximize the wealth of any individual ... [but] we can call that [belief] Valenti's fallacy.

(Felten)

On Thursday, I saw Ben Pfaff and Ben Laurie, and a few more talks. I didn't make it through the entire Formal Methods talk, but I got some useful discussion of protocol analysis there, including some of the risks of a naive analysis which doesn't consider all the ways an attacker could attack a protocol. It seems that formal protocol validation is making a lot of progress, and has reached the stage where it can sometimes find new protocol attacks which appear novel, clever, and surprising to human observers.

The other convention going on in parallel to USENIX Security at the San Francisco Marriott was an international convention of Forever Living. From just a few features of the convention and its attendees, I guessed that Forever Living might be a multi-level marketing company. It's true!

What surprises me is that Forever Living is extremely open about being an MLM enterprise. I'm used to seeing (and sometimes receiving) business prospects which insist that This is not multilevel marketing! And they say so because they realize that MLM is the subject of tremendously negative perceptions -- at least within certain communities.

What's wrong with MLM? The only specific objection I've heard is that most MLM enterprises (sometimes "MLM schemes", like "DRM schemes", you know?) aren't very good deals at all for most of their participants. This creates associations in people's minds between MLM and pyramid schemes. In fact, if you search for mlm pyramid, you can see that many people have made this association explicit.

In a pyramid scheme, participants are told to send their money "up" the pyramid and then to collect money from newly-recruited participants "below". There are many fewer people up on top than in the lower levels. And the people on top receive transfers from participants below. But the pyramid will have to collapse eventually, because no real value is being exchanged, and the money is simply being taken from the people on the lower levels and given to people on higher levels. Eventually, the world will run out of new prospects to be drawn into the base of the pyramid, and then the pyramid will collapse, leaving people on the lowest levels without their money.

The anti-MLM claim is that much of MLM works like a pyramid scheme, because people form "downlines", and constantly purchase in the hope of being able to sell to new resellers. If all buyers were resellers, then an MLM scheme would be essentially the same as a pyramid scheme. The pro-MLM claim is that, unlike a pyramid scheme, MLM actually involves the sale of an intrinsically valuable commodity. So real buyers will actually purchase the underlying item, and they will actually want it and benefit from it, and a useful transaction will have taken place. Since real commerce is going on, there is no reason for the pyramid to collapse -- goods are flowing down the pyramid and money is flowing up, and that situation isn't structurally different from more conventional multi-layer commerce in which there might be, for example, a wholesaler and a retailer, or maybe several wholesalers and several dealers. (In the rare book business, a book could be bought and resold by several dealers before it reaches its ultimate buyer -- and that buyer might actually be a collector who's hoping to make money as a result of building up a nice collection. Or the buyer might die and the buyer's heirs might sell the collection to another dealer.)

One reason to be skeptical of MLM is that some MLM schemes proliferate middlemen -- or "levels" -- for no apparent commercial reason. Each middleman may have to pay the people above, so there's an incentive for the people up above to keep piling them on. But that doesn't mean that the market will be any more efficient or effective at delivering things people want. (And the incentives may lead people to be misleading about the profit opportunities or the quality of the product, although I guess both of those things happen in ordinary business, too.)

Can anybody else think of other specific risks of MLM?

Why do I like to say "the public's rights in copyright" instead of just "fair use"? It's partly because some people forget that the public has rights in copyright, or treat those rights as an afterthought. For example, a Senator writes

I understand your concerns about ensuring that. This issue is very controversial because Congress must protect intellectual property rights while still allowing ordinary Internet users to have access to public domain content.

Yikes!

Fortunately, we are gaining protection for our digital rights every day, now that Don Marti has a blog.

Raymon Lull, who was really into anagrams, wrote a work called the Ars Magna. (I wrote about Lull back in the year 2000.) Remarkably, "Ars Magna" is an anagram of "anagrams"!

Check out what the People's Daily says about Taiwan. Wow.

The FCC went ahead and issued a Notice of Proposed Rulemaking on the broadcast flag today. So I am already working on EFF's comments. If you want to comment, your comments will be due by October 30. This is a big deal; if you don't know why, take a look through Consensus at Lawyerpoint, or ask me.

A fun thing about using mutt to send e-mail about the Federal Communications Commission: you can use the pseudo-header

Fcc: fcc

Our response to this NPRM is going to keep me busy for a long time, and it's going to be pretty interesting. I think it's shaping up to be a pretty interesting fight. The FCC is likely to take some of our concerns a bit more seriously than the BPDG took them the first time around. But we'll have to lay them out clearly and carefully. So here we go.

I've come down with a cold, and I missed the last day of USENIX Security as a result, which is really too bad, since it was such an exciting conference. I'm trying to get better quickly. I missed Pam Samuelson's DMCA talk, and I missed the closing keynote, which was supposed to appear to feature Vice President Cheney.

As I said above, I've been writing a whole bunch of lipograms in "e", mostly to Riana, and even carrying on extended conversations which are lipographic in "e", with various people. If you want to see some of this work, or you want to have a conversation with me in which I will refrain from using the letter "e", just let me know, and I'll be happy to oblige you. I've certainly been getting some good practice, and it gets easier with time. (And I found some nice vi macros to warn me in case I let an "e" slip in somewhere.)

My best-known published lipography to date appears in my diary from last year and comes mostly from a few list posts I made to CTY-L around then. But what I've done since DEF CON is probably an order of magnitude more text, some of it fairly amusing, some of it perhaps even impressive.

I thought of composing this entire diary entry without any "e"s, but then it would have been even later than it was. So I hope you enjoyed it as it was. Be therefore at ease!

I actually bought some heavenly hash ice cream before writing that cryptographer joke in my previous entry. I'd been writing about SHA1, and went to the supermarket, and somehow the ice cream jumped out at me, and then I got it home and said "Oh!".

Everybody who reads this will probably know already that E. W. Dijkstra is dead.

The phrase "Non est hic mercatus per corios multos!" ("This is not multi-level marketing!") comes from my Latin spam (which, like much real-world spam, contains several grammatical errors). Also, it should probably be "non est hoc mercatus, etc.".

Even though I got away, it still took me about a week to produce a new diary entry.

I escaped from my captors because they forgot to say "in the negative" instead of "'no'" when they were interrogating me with coercive logic. So I was able to answer "nope", which was a correct and consistent negative answer and nonetheless allowed me to get away.

Other prisoners were not so lucky, and were forced to sit at a desk for years, calculating by hand the explicit numerical value of the Gödel number of "This statement has no proof in Principia Mathematica".

We had what was nominally an LNX-BBC meeting, but it was really more of a social gathering, and people helped me clean up a bit.

Our home wireless network is called "catenary". When Andrew managed to get a laptop to detect it, we said:

"Way to go, robot! You found catenary!"

Quinn pointed to an article by Barbara Kingsolver from Kingsolver's new book of essays. It has an interesting perspective on genetic engineering. Among other things, it criticizes genetic engineering for its supposed disregard of the important of biodiversity. Allegedly, engineers want to create one true variety of any given organism, and then have people raise only that particular variety, at the expense of all others.

I don't think most genetic engineers have conscious ambitions anything like that, but on the other hand, that impulse is very real among technology enthusiasts. It is difficult for us to believe that a technical problem like adaptation can't be solved directly by Engineering effort. Diversity as a virtue is not very deeply ingrained (heh!) in technical culture. At least, you wouldn't think so if you heard people talk about operating systems. :-)

I've been doing a lot better against my cold, although I'm still congested.

I saw a huge number of people, including Riana, Michelle, Sumana, and my high school friends Josh and Michael. I also got to see Cody's Books and the Perseid meteor shower on Monday, thanks to Sumana's driving and sense of adventure.

Soon after the weekend, I got to meet EFF's client Bunnie and hear him give his Xbox paper at the CHES conference. I had a nice time at dinner with Bunnie and EFF folks after the conference. Bunnie's next project should be pretty interesting, too.

I was at LWCE briefly on Wednesday and for a while on Thursday.

LinuxWorld is still less fun than it was when it got started. I still remember the first LWCE very fondly. "We haven't had that spirit here since 1999." But it's interesting and still pretty well-attended by people I know.

The mix of companies exhibiting is changing. Some of the early exhibitors are out of business or in a different line of business. The processor vendors were out in force, as were some of the old-line IT companies. Perhaps it's just another trade show for them.

I saw the famous Microsoft booth and spent a little while looking at an implementation of Unix for the Windows NT kernel. It was pretty faithful, and far ahead of both MKS and Cygwin. You could write ksh scripts and you could run all the traditional Unix programs with their traditional options.

I fired up vi and typed

int main(void){
	printf("Hello, Microsoft world!\n");
}

and then ran gcc to compile my program. It worked fine, of course.

Notably absent from the distribution were GNU programs other than gcc. The exhibitor who was showing me the system said it was BSD-based (in fact, running strings on several of the binaries showed the string "OpenBSD" with some frequency) and that "We were trying to minimize the number of GPL components". So no seq (from GNU sh-utils) and no modern GNUish stuff like rsync. As Larry Augustin explains in Revolution OS (which I watched part of on Thursday), people who set up proprietary Unixes in the past would typically spend a lot of time downloading and compiling GNU tools. It would have added a bit to this particular proprietary Unix.

The Microsoft representatives weren't very interested in talking about free software. At one point I was told that the product I was looking at cost only $100. (Subsequently I got a time-limited demo disk which contained software of which the use was purportedly subject to a EULA.) "I make software which is a bit cheaper than that", I said.

"Well ... you don't get 24-hour support."

Anyway, it was funny to be reminded that the Unix world has split up into a free software component and a non-free component. Microsoft, of course, was long the world's leading PC Unix vendor! But, as Jim Dennis says, "Linux is the mainstream Unix now".

On another day, I walked back into the booth to ask about Palladium. (I didn't want them to see my name, because supposedly "The best technical description [of Palladium] is the summary of a meeting with Microsoft engineers by Seth Schoen of the EFF", and being Seth Schoen is therefore inconvenient when you want to ask basic and uninformed questions about Palladium.) I was told that nobody qualified to talk about Palladium had come along to LWCE, and I suggested that they should bring such qualified people to futher LWCEs, since the free software world was extremely interested in the subject.

The nice folks at Bradford Learning decided to pay for the printing of another batch of copies of LNX-BBC 1.618 (the version from one year ago, which is still the most recently released version). So we had copies in the EFF booth, and there are lots of other copies floating around. Some of them were branded as "Bradford Learning" BBCs -- with credit given to LNX-BBC for development -- and others were printed with the traditional LNX-BBC cover art. All of them, as far as I know, had identical contents.

On Wednesday, I had dinner at the 21st Amendment with Kragen, Danny, Yoz Grahame, and Lisa Rein.

On Thursday, we had a party here, which was well-attended and made me especially glad I'd managed to clean up over the weekend. I had food from Shiki (on Third Street, where I used to live) and from Zante's Indian Pizza. I'm nostalgic, but to be properly nostalgic, as I said, you have to have other people around.

Unfortunately, Something Wonderful, a Precita Eyes mural on one of the supports for the freeway overpass above Third Street near Harrison, is gone -- it's been painted over!

The mural used to say, in a speech bubble,

It is -- I just feel something wonderful is about to happen.

Riana suggests, or maybe I suggest, that people should form a posse: Something Wonderful Has a Posse. Like "17 Reasons Has a Posse".

It turned out that at least two people I know have moved away from the Bay Area, and I only found out because I invited them to a party and they replied with observations on just how difficult it would be for them to attend.

But today you closed the door and said
"We have to get a move on.
It's just that time of year when we push ourselves ahead,
We push ourselves ahead."

And it was cloudy in the morning,
And it rained as you drove away,
And the same things looked different.
It's the end of the summer,
It's the end of the summer,
When you move to another place...

(Dar Williams, "The End of the Summer")

I took an amazing hiking trip in the Sierra Nevada mountain range this past weekend to celebrate Ben's birthday. We drove to about 7,600 feet, hiked up through a mountain pass at about 11,600 feet, and then camped for two days just below the pass by a mountain lake at about 10,600 feet. I think it was the most physically strenuous thing I've ever done in my life.

The hike itself was only about 3 miles, as the crow flies, but the trails, where there were trails, constantly wiggled back and forth, and, as Ben predicted, the hike involved about 5,000 feet of changes in elevation, or nearly a mile.

For those who are curious, we started from a point called Mineral King and hiked into Sequoia National Forest, through Glacier Pass, and camped by Spring Lake.

I wrote a letter to Wolfgang (about 26 pages, and, in keeping with tradition, containing a detailed description of how a CRT works). I learned a lot about myself on that trip.

Other items [from among his memories] were put in order so that they established a natural progression. [...] The further the structure grew, and the more coherent, the more significant new items became and the easier it was to fit them in.

(Asimov, "Lest We Remember", in The Winds of Change ... And Other Stories, p. 186)

My horrible joke:

"Forsan et hike olim meminisse iuvabit."

My letter suggests that we camped at 36 deg 28.208' N, 118 deg 33.687' W (WGS84). Yes, we had a GPS with us. You can get a rough look at that neighborhood using TerraServer; they also have the corresponding site in an old USGS topo map, on which you can clearly see Spring Lake, the location of our campsite.

And EFF now has a "Fair use has a posse" sticker. It's great!

Picture of party

This picture, from Biella's site, shows the party I had during LinuxWorld last week, just before I set out on the camping trip.

A bunch of things happened in the computer world while I was away. Rather than providing links, I'm just going to post this entry and hope that you've followed the news for yourself over the weekend.

I do want to mention that Annalee was critical of us for being too ambivalent about trusted computing:

Even the EFF's resident geek, Seth Schoen, admits the Palladium technology is appealing in certain ways.

Annalee's concern here, I think, is that my writing about Palladium so far has shown a technologist's aesthetic, so that I admire Palladium's technical cleverness (especially the elegance of sealed storage, which I realize is a concept shared with TCPA), and have yet to focus on the possible risks to the public's rights in copyright, etc. (I've taken to saying "public's rights in copyright" in preference to "fair use", because the public has dozens of rights in copyright, and fair use is only one part of those. Other people find that phrase clunky or awkward.) And I am preparing some analysis for EFF about all that, and trying to be fair to everybody, but in the meantime, I've supposedly said mainly that the Palladium technology is neat.

I do say so. I hadn't expected to be seen as too soft on Microsoft, but I can understand why Annalee is concerned. I will say that Microsoft has been very helpful to us in letting us know how this technology works, sharing technical details, answering our questions, and not requiring an NDA.

What would be most impressive, if Microsoft wanted to show off its benign intentions, would be some further public statements against the CBDTPA and DRM mandates, as well as a show of agreement with Gary Shapiro's admission that "The DMCA was a very flawed law. We signed off on it, and it was a huge mistake." (This is actually mostly orthogonal to whether Palladium is a good idea. But many people I've spoken to have worried about what may happen to people who discover and publish Palladium security vulnerabilities. This is especially of concern in light of Scott Culp's "it's time to end information anarchy" essay and the reports that Microsoft is supporting the legislative end of the "responsible disclosure" movement.)

Also, send somebody to LinuxWorld who can talk about Palladium there.

(Thanks to Riana for finding the Guardian article.)

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.

The magic alphabet, the mysterious hieroglyph, come[s] to us only in an incomplete and garbled form, garbled either by the passage of time or by those with a vested interest in our ignorance; should we retrieve the letter which has been lost or the sign which has been effaced, should we reconstruct the dissonant scale, we shall regain our authority in the world of the mind.

(Gérard de Nerval (quoted by Paul Eluard, Poésie involontaire et poésie intentionnelle (quoted in Metagraphs to Georges Perec, A Void (trans. Gilbert Adair))))

"Poésie involontaire" is all over the place; I'm sure the Oulipo would have been thrilled by Danny's haiku discoverer, and much else computers have done for our understanding and enjoyment of language.

I was trying to remember who wrote

not ... by his pure morals, or excellent example merely -- but in a mysterious manner

by way of taking his religion seriously, and it turns out that it was S. T. Coleridge. (Coleridge was writing about how he believed Jesus had saved him.)

I thought of this quotation because I was thinking about how people like to be polite to one another. When one person has a strongly-held belief, especially about the efficacy of (let's say) a method of salvation, or perhaps a political or ethical doctrine, a second person, wanting to be polite, will often say, well, your religious leader was a great teacher, or your doctrine is a source of much inspiration. And in the hard-core old-school no-holds-barred old-fashioned whole-hearted style of believing things, that kind of politeness doesn't get you very far.

It's definitely more conducive to friendly co-existence. For example, when I was growing up, we tended to hear in Hebrew school that Jesus of Nazareth (not, of course, Christos) was a great teacher. In fact, this is a pretty conventional position among non-Christians living around Christian culture. (Take a look through J. D. Salinger's Franny and Zooey, and so on!)

I remember that C. S. Lewis spent a long time attacking the argument that Jesus was a great moral teacher. In fact, that was the whole point of the "Trilemma" argument, to undermine the respectability of the middle position or moderate position, in favor of a more extreme view. So Lewis was contending with a lot of liberals who were repelled by things like the symbolum Nicenum and had come to feel comfortable with the "great teacher" position. And he attacked that position mercilessly.

But that view, what Coleridge calls Jesus's "excellent example", was already fairly old in Coleridge's day. Deistic and skeptical writers had been attacking the supernatural elements of Christian stories for a hundred years. Very few of them suggested that Jesus was a bad guy. Instead, they typically said that what Jesus had to say was true and useful to humanity, and could be separated from the supernatural and theological dogmas which had grown up around them. (It was very important to C. S. Lewis to maintain that Jesus himself was responsible for making certain supernatural claims for himself, because then anybody who denied those claims would presumably be calling Jesus a "Liar" or a "Lunatic", which is to say, approximately, a bad guy, or an untrustworthy guy. So Lewis particularly tries to avoid any separation of Jesus's "moral" message from his (largely Johannine, not synoptic) theological claims.)

These days, I'm hearing similar vague praise of Islam from non-Muslims, that Islam contains useful moral lessons and that Mohammed was a great teacher. In some sense, this is a way to avoid giving offense, but it's still far off from Muslims' practice of considering Mohammed a prophet of God.

One thing I notice is that only a tiny percentage of people who call doctrines they don't believe inspirational will spend any significant amount of time studying them for inspiration. Hebrew school students who are told that Jesus was a great moral teacher (with "pure morals" and an "excellent example merely") aren't usually encouraged to go out and read gospels. How many people who've praised any tradition foreign to them have actually made themselves familiar with it in detail?

Is there a better way for people who think that something is effective "in a mysterious manner" (as Coleridge thought of Jesus, and as many other people are wont to think of other things) to talk to people who don't think so, or who haven't shared that experience?

Somehow a whole year has gone by since I started working at EFF, back in August 2001.

So, that Barney vs. Wil Wheaton fight on Thursday was great fun, and was recorded on lots of media by lots of attendees.

If you've got a QuickTime player, don't miss the Barney videos shot by Paul Weinstein. The NBC News coverage is great fun. It even briefly shows Kieran and Mae Ling. You can also see Wil grabbing Barney by the tail and swinging him around. (I'm still waiting for a movie of Wil leaping over Barney's light saber.)

(Note, re the NBC story, that EFF was not involved with the Rio lawsuit (RIAA vs. Diamond Multimedia); that was defended by Andrew Bridges of WSGR. Also, EFF does not expect to be sued in connection with our ridicule of Barney this past Thursday.)

The DNA Lounge also has its own pictures, which are very nice, and I've seen pictures published on-line at a couple of other sites.

I skinned my knee in a pre-benefit light-saber duel with John Gilmore. One thing I did not expect to do when I moved out to California was skin my knee fighting John Gilmore. But he's rather dextrous, and I could only get away by doing a full-body roll beneath a chain. Evildoers, beware!

In an earlier diary entry, I suggested that Palladium-based DRM implementations aren't looking so hot for publishers, because they can be defeated by a hardware attack which supposedly costs under $100 and requires little more expertise than current attacks against software-only DRM.

Fred von Lohmann explained why Palladium DRM would still be a good proposition for publishers, even if these assumptions were correct: publishers would get "a $100 hardware hurdle for the average couch potato". Fred thought that that kind of expense (and the effort of physically installing a mod-chip-style device) would eliminate 90% to 99% of the attackers who would be willing to attack DRM with software they could download from the Internet. He also claimed that, statistically, practically no computers users ever open their computers at all.

So the suggestion is that, if you think statistically, a $100 barrier is an extremely effective security measure, especially when you compare it to the (amortized) barrier of approximately $0 -- in the long run -- for defeating all extant software DRM schemes.

This again shows how DRM's security model is very different from traditional security (although Schneier seems to suggest that that, too, is a matter of costs traded off against benefits). In traditional security, if you heard that a $100 technology, the means of constructing which were well-known to everyone skilled in the art, and schematics for which had been openly published, could defeat your security, you would probably not want to claim that you were secure. In the DRM world, this may be considered a reasonable risk, because the measure is still guaranteed to be effective against most attackers. Yes, there. Now I've articulated a specific difference. In regular security, if any attacker succeeds, the security measure has failed. (Schneier, infra, will worry about how "well" it fails, but read that article.) In DRM security, if fewer than n% of attackers succeed, the security measure is good enough, and is satisfactory.

A strange paradox resulting from this is that the discovery publication of a practical and effective exploit against a system may not affect the system's "security" according to this definition! (If the exploit isn't appealing and easy and cheap enough for n% of attackers to use it, it will be deemed not to matter, even though any individual attacker is in principle able to use it at any time.)

A corollary of this is that you can create a system and publish your own exploits against your own system in advance (and not patch against them), and your system may still potentially be "secure". That is counterintuitive.

Michelle and Sarah visited me. (Sarah is Michelle's cousin.)

Michelle made use of Craigslist to buy a laptop, which looks like a nice laptop for a reasonable price (especially because it came with a Zip drive and a CD-RW drive). It was manufactured by Sharp, one of the BPDG dissenters (yay BPDG dissenters!). I currently need spare network adapters (100baseTX, 802.11b) and a modem, all in PCMCIA form factor, for Michelle.

I had a horribly complicated and very emotional dream on Saturday which involved being back in Massachusetts. It seemed to have gone on for hours, considering the number of topics touched upon, but I'm never sure how dream time and wall-clock time interact.

On the following night, I had a vivid nightmare in which I was a character in an action movie. it was a spy movie in which a bunch of technically-proficient former employees of an evil organization had to figure out how to break into that organization's lab (using their knowledge and perhaps their old access codes and tokens) in order to do something -- I think sabotage the lab's project.

I assumed that the effort would turn out all right because I had some kind of sense that I was in a movie and that movies always turn out all right, but I didn't know how it would work out. So I was one of the team which had to break in, and we were sitting around in some kind of camp we'd set up in a building on the outskirts of the lab compound we had to break into, arguing about technical issues related to how we would break in. One of the problems was that we had to acquire several objects without alerting the guards.

So at a certain point, I picked up one of the objects, and all of the other people there became angry at me, because that object had been alarmed, and they'd all known it and I hadn't. And the alarm went off, and I figured there would be a chase scene, but instead all of the guards showed up and captured us. So then I figured there would be a clever escape scene, but there wasn't, and instead a representative of the evil organization showed up, threatened us, and then put us into a scary "biometric-destroying machine". The idea of this machine was that it would physically reconfigure every aspect of each of our bodies which might have served as a biometric identifier, so that none of us could use any part of our bodies in the future to establish our identities. (Apparently some of our biometrics were still listed as "trusted" in the databases of various organizations, and the solution they'd decided on was not to delete our biometrics from the databases but to delete our biometrics from our bodies.)

The representative told us that the biometric-destroying machine didn't hurt, but none of us believed her.

As it turned out, the machine didn't hurt, but we were inside of it for several hours, and it was scary because all of our physical appearances changed somewhat, because the lengths of our bones were altered slightly! When we came out of the machine, none of us looked quite the way we had before, and it turned out that the movie was over, and had had a happy ending, but for a completely different reason, thanks to a different plot involving the actions of other characters. In other words, we weren't (as we had believed ourselves to be) the heroes of the movie; it was OK for the plot of the movie that we had been captured, because the success of our plan was superfluous in the end. So we were free and the movie had a happy ending, but all of our biometrics had been altered.

Nick and Duncan continued in their quest to get me set up with a DEC Multia running Linux. The Multia is a famous machine which DEC produced as a desktop workstation with an Alpha CPU. They were amazingly cheap after a little while, frequently available for free. (But I, paraphrasing Jamie Zawinski, said that "Multias are only free if your time has no value".)

Multias look something like this:

A different kind of Multia

(image from http://www.omroep.nl/nps/radio/supplement/99/0426/gfx/multia.jpg)

Oh, wait. That's a different kind of machine called a Multia. Actual DEC Multias are somewhat smaller...

The Multia is famous for having a 64-bit CPU on a workstation, which was relatively unusual when the Multia came out and is still unfamiliar to PC users. One of the cool things was the 64-bit time_t under Linux, so that GNU date could calculate the day of the week for an extremely long period of time into the future. (It's probably not right, because there will probably be a different number of leap days than the current formulas predict.)

These are funny!

Duncan: Do you have a SCSI cable?
Seth: I haven't discovered SCSI yet.
Nick: "Your scientists are currently researching SCSI."

Also:

Seth: Long live 64-bit time_t!
Nick: You mean long long live 64-bit time_t!

In Berkeley, I was asked how I would protect people if I were a safety officer. I took out a book and brought it down in a series of four chops, shouting "Don't! Commit! Rights! Violations!". Well, it was funny if you were there.

Nick persuaded me to install Debian on this iBook, so I wiped out MacOS completely, and now it's Debian all the way. I've never installed Debian onto a non-Intel machine, but I was surprised at how straightforward it was. The AirPort card and the sound card are supported; XFree86 runs (at only 800x600, alas), and I've got OpenSSH, sniffers, Mozilla, gcc, and all sorts of other good stuff -- probably comparable to what I'd have under MacOS X, but here I can apt-get source anything which strikes my fancy.

Having an iBook running Debian impresses people, somehow; they see it as incongruous, and they see it as hard-core. Some people are disturbed by it. Others didn't know it was possible.

Because Debian is a complete Operating System, the installation procedure may seem a bit unusual.

(debian/README.html)

Via Electrolite, there is a fascinating piece about Bruce Schneier, which talks about what security means, and how Schneier became increasingly skeptical about the efficacy of cryptography alone.

Gosh, but Guy L. Steele is clever.

I got a bit of an appreciation for what DJs do by watching several DJs at work with vinyl LPs this week (at a party of Andrew's, and at the DNA Lounge). I hadn't understood exactly what they were doing until I got to see it up close; for example, I'd heard of beat-matching before, but I didn't understand the theory. (DJs are actually able to mix two songs together -- changing the phase and tempo of both with their hands and their equipment -- in such a way that the songs' rhythms blend together and the transition is almost imperceptible. That's one of their tricks, and there are others.) So obviously modern art forms and disciplines are being created which couldn't have existed before, and human beings are still constantly showing off their skill and especially their versatility.

(I knew what a cross-fader was, I owned a cross-fader, I'd even used a cross-fader both at a party and on a live radio program, but I never heard the full potential of the cross-fader until just this week... and perhaps I still haven't.)

John Young is getting some strong responses for publishing the names of secret agents (something he's done repeatedly in the past, but which this time was the subject of some press coverage). The reactions are including death threats.

This article is meaningless, and I thought so even before I saw it linked from slashdot. Doesn't anybody have anything real to say about Linux and business and the free software movement?

You can get official information about China in Esperanto.

You can also get (not in Esperanto, but in English) Shakespearean apocrypha, including such texts as Arden of Feversham, The Merry Devill of Edmonton, and The Tragedy of Locrine.