[This is Dan]

Actually, that's how the Java version works -- you take strings, and subclass them into safe versions and unsafe versions. Then you combine, either through a vararg shell, or through sequential dot notation.

I'm not a big fan of either; I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it.

OK, I was actually there. Not, "I heard this from a guy." I mean, I'm Dan Kaminsky, who's named in the article.

This was kind of a silly situation. One of the guys in our group hit the ball and it sort of sailed into this guy's face. It's a styrofoam ball, the maximum speed of those things is maybe ten miles an hour. It's actually slower than a Nerf ball.

Anyway, the guy who actually hit the thing was sort of an awkward nerd, and laughed about it nervously. You know in the article when the guy's like, it was just one guy? That's because it was just him. There was certainly no mob taunting.

Really, this was a bunch of nerds and burners. There was no damage going on, just general silliness and large scale commerce with institutions that were each contacted in advance and specially staffed to seat all of us. I don't think it'll happen again, and that's sort of sad. Urban golf was a lot of fun for everyone.

I think he's going to burst his eardrums, and possibly some organs.

Look. this is going to be an enormous pressure wave that will saturate his body. He pops this barrier, it's going to rattle him pretty fierce.

They really should try this with a dummy first!

They can replay it within the absolute time of the RRSIG, which can be made relatively small (needs to be long enough to handle time drift).

A web site built on flat HTML pages is more likely to be secure than a web site built on PHP. The message is the medium.

So, I'm posting as somebody who has gotten critical fixes pushed into both IE and Firefox. (Technically, Chrome and Opera too, but those were the pure crypto vulns.)

It's genuinely hard to write a secure web browser. Forget plugins -- you have a complex internal object model, subject to all sorts of very fine grained rules ("the filename on an input type=file form must not be settable from Javascript"), which can be made into a pile of moving parts under the control of an attacker. What's happened somewhat recently is a lot more people have gotten into bashing Firefox. You know those "many eyes" theories of open source, and how they're usually kind of full of it?

Well, "many eyes" are visiting it now, and Mozilla to their credit is doing a lot of very hard work to deal with the influx. Good on them.

Use the PASCO gear, with their Datastudio app. It's great, and will take all sorts of data wirelessly.

http://store.pasco.com/pascostore/showdetl.cfm?&DID=9&Product_ID=53770&Detail=1

Uh, a few machines have eight cores. Core2Duo is doing OK, but really, the heat problem is not actually going away in any way shape or form.

(This is Dan)

It is true that DNSSEC increases aggregate bandwidth.

I'm not sure about the DNSCurve numbers right now, given that the implementation I've seen can only do about 5,000 encrypt/decrypts a second on hardware that'll do 15,000 DNS responses a second.

(This is Dan)

Yes, because browsing securely should look like UAC, with every new site throwing a prompt in your face as if you had enough information to go on.

No. We can, and need to stop imagining the user is some sort of god that can accurately judge risk of accepting unknown keys (or worse, keys 'recognizable' with some arbitrary sequence of hexadecimal characters). This is a lie we're telling ourselves, and I'm done with it.

You're right that Verisign controls .com. Guess what, they control it *today* -- they are the exclusive registrar for it. If Verisign screws up, you have accountability. When .info was filled with SPAM, Afilias (who also owns .org) cleaned it up, because they had accountability. The present system has no accountability, and so any CA -- and there's rather worse than RapidSSL out there -- has full ability to spoof everyone, in every domain. We can and should do better.

(This is Dan)

The point is that we can actually share DNSSEC responses across multiple nodes, not just a single node, using the existing framework. Yes, we will need clients that *can* go straight to the root. But they won't *have* to, which is a neat design element of DNSSEC.

Keep hitting me here though, maybe we can find a problem!

(This is Dan)

Excellent, excellent questions. This is the sort of stuff I was asking before I switched sides on the DNSSEC war.

The problem with SSL is it doesn't matter if *you* aren't paying a worthless CA; as long as a worthless CA is out there, he can corrupt every domain, everywhere. That sucks. So SSL becomes a matter of finding the least secure CA possible and compromising that.

Things are different in DNSSEC. Because of delegation, the root is the only entity with absolute power over everyone -- and the root rarely talks to anyone. Verisign is canonical for com, Afilias is canonical for org, and so on. There's no big mess of companies that can all step on eachother. There's one big mess, true, but that's it. Everything else is distributed. That is such a better situation than we have today!

Look. When some registrar had microsoft.co.nz stolen from it, it had a choice: Either clean up its act, or watch Microsoft move its registrar activity to someone that wasn't vulnerable. Microsoft had an actual response strategy. We need more systems with response strategies -- and I think DNSSEC has them.

It really is different. I can't emphasize this enough -- I wasn't a believer. Now I am.

Absolutely true. However, the ability to delegate/federate security is such a powerful force for lowering the costs of proper design and management that making this one technical change will facilitate the operational strength you correctly call out.