... okay. I guess if a router is "properly supported", that means it doesn't have any bugs, so it will never need to be field-updated under any circumstances.

Also, if it's "properly supported", that means neither the manufacturer nor anyone in the supply chain will ever insert any kind of malware, so there's no reason to allow the code to be inspected for correctness.

Also, those 11 million VW diesel owners should have paid more for a properly supported car.

"Firmware" has multiple meanings. The thing you're talking about is indeed called "firmware", but it is a minuscule fraction of the firmware on a typical router, which is generally a linux/unix derivative and includes everything from device drivers to configuration UI. And which is usually riddled with security vulnerabilities and other flaws.

Even the minuscule bit you're talking about still needs to be inspectable and repairable, because devices always have bugs -- often already known by the time they're shipped and purchased -- and device manufacturers have (apparently) little to no economic interest in fixing them, and it's the owner of an RF device who is legally responsible for compliance. Unless you honestly expect everyone to throw their routers away and buy new ones every few months, or you simply don't care about security, performance, or FCC compliance, field updates are a necessity.

If an RF-controlling firmware component is nothing but the equivalent of a few jumper switches, then document them thoroughly. If it's functional software (which in fact it pretty-much always is), then publish it, and do so in a form so it can be recompiled to ensure that what's on the device is the same as what was published. Volkswagen has proved beyond any reasonable person's doubt that unverifiable software is not to be trusted.

(Disclosure: co-author/signatory to the FCC letter.)

Spoken like someone who wasn't around when Jon Katz was writing his "Voices From The Hellmouth" columns, after the LIttleton massacre when nerdy teens were suddenly public enemy #1. As an old-timer, this looks exactly like the sort of story I'd expect /. to link to and discuss.

I've been to Beijing, and I didn't look anywhere near as cool as a two-pack-a-day smoker.

Hey, 248 days is five dog-years.

No. DNSSEC keys are in stored in a vault and only brought out for signing ceremonies. As far as I can tell, bad guys will have gotten access to some potentially valuable identity information and passwords, and copies of TLD zone files; nothing related to DNSSEC.

A friend of mine was ticketed a few months ago for checking the map on her cell phone while she was stopped at a red light. Some things are just absurd.

This whole thread is really kind of hurting my feelings.

Google has not correctly implemented DNSSEC. If you send them a normal DNS query and the response is not validly signed, they just pass the answer back to you without any indication that it's invalid. They only tell you that the answer failed to validate if you set the DO ("dnssec okay") or AD ("authentic data") bits in your query, which almost no DNS clients currently do.

If the answer is invalid, a validating name server is supposed to respond with SERVFAIL, so that even if the client doesn't know anything about DNS security, it will still be protected against spoofing. Google is claiming to provide protection against spoofing, and then they aren't providing *any protection at all*.

If you want DNSSEC protection, you're still going to have to run a validating name server yourself: either BIND 9 or Unbound. (Disclosure: I'm a BIND 9 author.) It is, nowadays, extremely easy to configure a validating name server using BIND 9; in any version since 9.8.0, a one-line named.conf will do it:

options { dnssec-validation auto; };

Run named with that configuration and "nameserver 127.0.0.1" in resolv.conf and you're good to go. Google public DNS is not ready to trust yet.

In fact, you don't need a dynamic DNS provider at all. My home router (a Netgear WNDR3700, costs about $85) is running CeroWRT, which includes BIND 9, which takes care of dynamic DNS by itself. It also does DNSSEC validation, and serves a dozen or so DNSSEC-signed domains. It's also my web server, IPv6 tunnel endpoint, shell server, and a passel of other things. Current uptime 224 days. Consumer router hardware can do a lot these days.

(Full disclosure: I'm a BIND 9 author and helped with the CeroWRT port.)

'Cause I wouldn't have been able to resist the temptation to name it "Amazon Prime".

I totally recognize that this is a stupid reaction, but if service #1 costs X dollars and service #2 costs Y dollars, I want a little lagniappe if I purchase both--the bundle of services #1 and #2 should cost an amount less than X+Y.

If they'd announced that streaming was $9 and DVD's were $9 and the combination would be discounted to only $16, I would have been sad about the price increase but a lot less irked, even though it still would've been $16. At least it isn't $18, I'd think, and I'd pay up. But they made each service $8, and didn't discount the bundle at all, and so it grates on me.

Marketing fail on their part. Rationality fail on mine.

That's not correct. The locking bug had already been fixed in 9.7.3b1, a month before it was found to be exploitable as a DoS. When we did find that out, we consulted with vendors and decided to continue with the releases in progress.

Those of us who are a certain age and were geeky enough to read Danny Dunn books know exactly where the CIA got this idea.

(Luckily Danny was able to destroy Professor Bullfinch's notes so the CIA wouldn't be able to replicate the much better dragonfly he'd invented, so they had to fall back on tiny, impractical gasoline engines instead.)

A friend of mine said to me a while back: "I've decided I'm going to skip Facebook, and then skip the thing that comes after Facebook, and join the one that comes after that."

There is much wisdom in her plan.