It's nice to be home. Illness precluded lots of the hacking that I had wanted to do but I read a fair amount; I read Orwell's Homage to Catalonia, and worked halfway through German General von Mellenthin's Panzer Battles. Unlike a lot of war books, this isn't a story of battlefield guts and glory but a close tactical look at most the major Panzer campaigns from a staff officer who was there from Poland through to the last defense of the Ruhr Pocket. Despite what you might be prepared for he writes respectfully of his opponents when they perform well but doesn't pull any punches when the Allies make a stupid move like General Cunningham's thinning of the lines at Sidi Rezegh in North Africa. von Mellenthin has no problem speaking poorly of his own superiors when they make such lame-duck decisions as waiting until long into the Russian campaign to get rid of all wheeled vehicles from the Panzer divisions even though it had been blatantly obvious since Field Marshall Balck's offensive over Mount Olympus in Greece.

Hey, I'm now an EFF certified encryption researcher. Happy New Year everybody.

So after 4 days of antibiotics, I'm finally able to get a full night's sleep without waking up every other hour coughing my lungs out. Another Festivus Miracle!

BBum requested a Lisp PBX language specification so I whipped up one for Scheme but as I don't have the December Dev tools and refuse to download them over this 33.6 dialup connection, I can't actually test my new specs. Plus, AFAIK, PBX doesn't do parenthesis matching yet so I doubt anybody would actually use it to hack around in Scheme. Hmm, I wonder if I can get PLT Scheme to emit a list of it's keywords the same way Python will.



Joe Strummer passed away. He was 50 and in the middle of recording his third album with his new band.

I went to the doctor last night and discovered that I have an ear infection and a sinus infection. He gave me some antibiotics. It should be mostly cleared up by the time I get back to SF.

I haven't felt much like hacking on code but I did work on converting a scanner I wrote from understanding only ascii to understanding Unicode. Objective-C NSString's have no trouble with unicode, and the convenience method I'm using to load a file into a NSString understand's Unicode as well, I'm just struggling with idioms for dealing with individual characters inside an NSString. char* arrays here make more sense to me but only because that's what I'm used to.

I've been sicker than a dog since the Packers/49ers game Sunday where we were rained on for 3 quarters and half-time. Tomorrow I fly off to cold, cold Oregon. Hopefully this will clear up in a few days. I turned the Mozilla book on mozdev.org into PDF's for some XUL hackery while in Oregon. I also want to get a little work finished on my Blogger API 2.0 client in Cocoa. I came up with a whole new way of thinking about it.

This blog is now under a Creative Commons license. I chose the Attribution clause because I feel attribution is important to mixing the genepool. I found the CC implementation to be incredibly simple; perfect for wide adoption. Great work! [pre-launch uncovered by luke francl]

I found these Lecture Notes on finding substrings using both finite automata and KMP string matching. An important note from the second paper: "[KMP] can be thought of as an efficient way to build these [formerly mentioned string matching] automata". Some of the younger students out there might ask: "Why study a second subject which is simply thought to be generating the first?". It's all about simplification and many things in CS fall into this category but finite automata is especially rich in this area. Example: many people out there use regex's on a daily basis but most of them don't realize regex's are just building finite automata in the background. Learning automata doesn't seem particularly important to writing faster regex's although it's quite important when learning how to write things that are _faster_ than regex's for a particular (usually small) task.

My dad's in town this weekend; We're heading to the Packers v. 49er's game tomorrow. I'll have to pick up a Niners hat in the Stadium since he's wearing his Packer's gear. Dad told a couple on the plane down here who asked whether I was also a Packer's fan: "Of course, if he wasn't we would have made him live in the shed."

I bet SF over Green Bay 27-20.

Update: The Packers beat the 49er's 20-14 with SF failing to connect for a TD with 20 seconds left on a 4th down.

My pal Darius Bacon is having a holiday sale and has put up some real literary (and computer science) treasures for sale.

Tuesday I released pre-documentation for Blogger API 2.0 and in that documentation I mentioned a 'token' element to the Login struct which would have some amorphous "security" property. I then later dismissed the token element on the bloggerDev list as something I wouldn't be able to finish because I didn't define a threat model, wasn't happy with the work I had completed on the subject, and felt that it would need retooling of the return types to make it effective. I've changed my mind on that last point (no retooling of return types is necessary), which made me think of a threat model and then flesh out how protection against that threat might possibly work. Here we go:

Threat Model: Protect against somebody sniffing a user's password over unprotected XML-RPC traffic.

There'd be a module called blogger2.secure with a method named handshake(). It doesn't actually return a value, it initiates two DH key exchanges, so you now have two shared secrets. The first secret is used to hash the password and that new value is sent across the wire as the 'token' field in the Login struct. The second secret is then used to hash the first secret and the original first hash is now stored in the second field. Everytime you send a token, this happens again. This makes the authentication perfectly forward secret. I'm pretty tired so I might have missed something there.

There is one problem I forsee; what if by network failure or some other problem the two secrets become out of sync and the server no longer accepts "legitimate" (to the client) tokens from the client? You could just re-handshake() although you would want to know that the password was legitimate and this wasn't the reason for the token rejection. This brings up another point; when you send the initial handshake request; how does the server know who to associate these shared secrets with and how does it authenticate who that person is originally? Did I just make a house of cards?

I'm posting this here rather than the bloggerDev list because I'd like some opinions from people who aren't necessarily on the bloggerDev list. The question of original authentication is key and I'm sure it's been solved before. PFS isn't new, I bet I'm just missing something.

Update: I now see how it's possible to do initial authentication using another DH exchange and then sending across username/password with that first shared secret. -smj (2:30am).

Another Java paper: Sorry, I do program in it for a living after all. This one makes some really good points; one point in particular debunks the myth that ints are 32-bits wide in the JVM. Language lawyers will argue (and win) that ints are only specified within a range and that the JLS doesn't specify how wide an int is in the JVM but merely that the number can't be larger than 2147483648 (2^31) and therefore an int could be any width inside the VM. This paper also clarifies what a 'critical' section of code really is as opposed to what people usually call 'critical' sections of code.

[via Brandon Lee]

Dagnabbit, Wiseman scooped me on the Weinreb post:

Daniel Weinreb on Symbolics' decision to buy instead of build the keys for their keyboards:

We made our own monitor electronics, our own laser-printer electronics, we wrote the microcode, we wrote the operating system, and so on, but making our own keys was, finally, below the level of abstraction that demarked our build/buy line. We were really, really crazy, but we were not really, really, really, really crazy.

[via lemonodor originally from ll1-discuss]

Java has needed Generics for a long while now and 1.5 will get them according to this article [via just looking]

Here's a nice little example of what you can do with XUL. It's useful to note that the Mozilla browser interface is itself written in XUL and Mozilla Themes are commonly written by copying the main Theme, modifying that template's XUL, CSS, JavaScript, and images then repackaging it into a new jar file.

Also, I read the beta chapter on Servlets from O'reilly's upcoming Java Enterprise Best Practices. Not too bad, even for an Enterprise book.

Even though I'm not a Linux Kernel hacker I really enjoy KernelTrap's articles. This week they interview Ingo Molnar about his recent work on the O(1) scheduler in the 2.5 kernel and his history with the kernel. He makes a few comments on the BitKeeper controversy.

Joseph on Libertarianism

Joseph on about Libertarianism: Beware of beautiful philosophies of principal that are selectively cited in practice.

I'm not sure how Joseph stands on the subject, although he gets very close to stating his opinion, but I firmly believe that the Free Market Fantasy is one of the most dangerous concepts in play currently and the amount of airtime that this painful double-standard gets in Libertarian circles is the main reason I'm not one any longer.