If there are 20,000 of these devices, they wouldn't have the bandwidth for all of them to be transmitting simultaneously. But that would be a stupid design anyway - it's not how you'd build such a device.

What you'd do is include an RFID-style receiver. You'd interrogate this from some roadside equipment (such as you'd find at tollbooths or on the approach to customs, or anywhere interesting things happen). The receiver responds with its ID, and if they want to enable that particular transmitter, they'd send back the enabling code. It would only then switch on and transmit for some limited time period.

In this way they'd be able to manage spectrum effectively, have the batteries last for years, and capture all the interesting and incriminating snippets of information as a car approaches customs.

Technically, all this is quite feasible - in fact it's really very easy with off-the-shelf technology. Whether this is what they actually did I can only speculate, but it's what I'd have built if I was tasked to do this (I wasn't, I should add).

BTW, a conference publication isn't considered a "journal" publication, and doesn't confer the same status.

This is incorrect for most of Computer Science.

Citeseer has rankings of publication venues for CS. All the top venues are conferences. BTW, the same is not true for Electronic Engineering though - in EE, journals carry more weight. This is always a bone of contention in fields that span both CS and EE.

Of course there are also plenty of useless conferences in CS, where no-one will ever read your paper, and you won't meet anyone interesting if you attend. The impact rating serve as a rough guide to where is likely to be interesting, but they're no good for new venues.

My citation count is currently around 25,000 according to Google Scholar or 7000 according to Citeseer, which uses a different methodology. So I'm probably doing something right. But I'm not in the top 100 most cited authors, so this also shows that there must be an awful lot of publications appearing somewhere. Have to assume most of those are rarely read.

Having implemented BGP, I do know how route damping works. For this particular attack, it does help, but only a bit. The paper looked into this in some detail. If you take out peerings that propagate enough routes, and do it in enough places, the per-peer per-route penalty is usually not exceeded, so relatively few routes end up being damped.

I think the paper got quite a few things wrong, but this isn't one of them.

I was quoted briefly in the New Scientist article. Here's the longer version of what I said to the reporter.

I've taken a quick look at this paper, and at the paper describing the actual attack on BGP sessions that this paper depends on (Zhang, Mao and Wang, 2007 (reference 74 in the paper).

For many years a number of us have speculated that it might be possible to bring down large parts of the Internet by inducing sufficient churn in BGP routing. In principle, it seems it might be possible, but doing it in practice is very different. The closest we've seen in the real world was Jan 25th 2003, when the SQL Slammer worm spread worldwide in a matter on minutes. It affected about 75,000 computers, and then each constantly tried to infect more victims. This causes widespread congestion, and the worldwide BGP routing table decreased in size from about 127,000 routes to 123,000. Some of this was probably due to congestion disrupting routing sessions, and some might have been due to people deliberately disconnecting to avoid further damage. In any event, the Internet backbone survived the event unscathed, but quite a few edge sites fell off the Internet.

The attack described in the paper supposes a larger number of compromised computers (250,000), but the Internet has got bigger and routers have got faster since 2003, so likely the relative traffic levels would be similar. The attack also proposes using the targetted attack described in Zhang, Mao and Wang, and targetting specific links to create maximum effect. So it's reasonable to suppose that if such an attack were successful, the impact would be greater than the Slammer event.

So, there are two questions:

• 1. could you disrupt routing associations in the way described.
• 2. if you could, would the effects be as described in the paper.

In answer to 1: Zhang, Mao and Wang describe in their paper how to defend against such attacks - by simply enabling prioritization of routing traffic - something that is possible on most commercial routers. If ISPs do this, then it seems that the attack in the paper would be thwarted. I don't know how many ISPs do enable this, but if such an attack were seen in the wild, I'm certain most of them would.

On 2: even if you could disrupt routing associations as described, I doubt the Internet would behave as described. The simulations in the paper make a lot of simplifying assumptions, which is necessary to simulate on this scale. But in hiding all the internal topology of ISP networks, they also hide bottlenecks that would make the attack less effective. And the way they model routers queuing routes internally is simply wrong - no router has a large enough queue size to delay processing by 100 minutes, as described in the paper. As a result I have no confidence in the predictions of how the global routing system responds to this attack.

To be clear: nobody knows if it's possible to bring down the global Internet routing system. The attack in the paper probably could cause significant disruption, at least until ISPs reconfigured their routers. But I doubt the attack would be successful in the way described in the paper.

You're correct - I forgot about that. But isn't it 12 months from publication, not 12 months from invention? I don't know if filing a Korean patent counts as publication, or only when the Korean patent is granted. Perhaps they filed the patent in Korea in 2003, were granted it in 2006 establishing the publication date, and filed the US patent.

Another posibility is they did also file a US patent in 2003/4, and the 2007 US patent is a continuation patent based on the 2003 material but with amended claims. That happens all the time.

But I'm not a lawyer - just successfully contested a coulple of patents in court as an expert witness.

The US patent was filed in 2007, but the priority date is 2003 because LG hold a Korean patent dated 2003. The US has a "first to invent" patent system. The priority date on LG's US patent is the invention date - 2003 - not the filing date of 2007.

Maybe LG filed the US patent in 2007 because they could already see Sony infringed. But the US patent system allows that, so long as you can prove the invention date. Screwed up it may be, but that's the law in the US.

Most other places have a "first to file" system; they wouldn't get away with this on an EU patent for example.

While I prefer to live in what passes for a democracy, sometimes it's good to be in competition with countries like China that have different ways of doing things. Once a promising technology is developed, it tends to spread everywhere. Some technologies seem to be most successfully developed under the political/economic system in the West. The Internet comes to mind. But some may be better developed under the political/economic system in China, or other places. But wherever a technology is first developed, it tends to spread if it's successful, because otherwise countries don't stay competitive.

Just because the Western system works well for a lot of things, doesn't mean it's the best system for everything. In the long run, we benefit from a bit of international competition.

I was on a flight into San Francisco about ten years back that was hit by lightning. There was a bright blue flash and bang, and all the lights in the plane went out. A few people screamed. Most of us just looked somewhat startled. About 30 seconds later, the lights came back on again, and shortly afterwards the captain made an announcement something along the lines of "I'm sure you noticed, but we got hit by lightning just now. It does happen from time to time. It did reset a few things up here, but everything is fine now." I always wondered what precisely "a few things" were, and whether everything wasn't fine a couple of minutes before.

Yes but there also was no Windowed GUI system in common use before Windows came out

Windows 1.0 came out in 1985.

It's predated by Xerox Star, the Apple Macintosh, Sun's SunView, the W Window System from Stanford, and early releases of the X indow System. Probably a bunch more too - Symbolics comes to mind. Of those, the Mac and SunView at the very least were widely used.

Microsoft, as usual, were late to the party.

I don't view it the same way. I've fitted a lot in my life so far; done exciting things, been fascinating places, met incredible people, and done original research that's been cited thousands of times. And I've two great kids and a wife I love. Life is good, and I don't plan on throwing it away casually.

But I also believe that it matters less how many years you live than what you do with the time you have, however long that may be. My family may not agree of course.

Don't get me wrong; I fully expect to do something interesting and useful in my 60s and 70s, health permitting. But I don't fear death; we'll all go some day. I'd rather go out doing something that would really make a difference to how mankind sees itself, and which just might sow the seeds of a new world.

I'm in my early 40s. In 20 years time (when they'd be ready) I'll be in my early 60s. My kids will have left home, and I'll be looking forward to an unexciting retirement. I'm reasonably fit, I've got 20 years of experience as a scientist, some experience as a pilot, and I'm a pretty good general purpose engineer. I'm also pretty self-reliant. Probably roughly the sort of person they'd want.

Would I go? You bet I would. I'm quite serious. I'd far rather do something incredible and useful with the little time I have left than sit around gardening or playing golf.

I'd still go if I knew there were only enough resources to last me 6 months on Mars, and then I had to quietly pop the little red pill. Trading 6 months doing something completely amazing for 20 (expected) rather boring years going slowly senile seems a pretty good trade to me. I'll bet there are quite a few people like me out there.

Tcpcrypt is about 25x faster on the server than SSL.

Whether it prevents MITM attacks depends on what authentication you do over tcpcrypt using tcpcrypt's session IDs. There's a drop-in replacement for libssl that can do batch-signing using SSL certs. It provides equivalent protection from MITM attacks to SSL, but maintains the performance advantage.

Even for unauthenticated sessions, it means the attack needs to be MITM, rather than just passive eavesdrop, which raises the bar quite a bit in many situations.

What we really need is for tcpcrypt to be widely deployed. That would make the cost negligible.

Just hook your gas-powered generator trailer up to the tow hitch for that once-a-year trip where you need unlimited range. Leave it in the garage the rest of the year.

The crash of an airliner these days is rarely due to a single cause. There's a saying in the industry that a crash occurs when the holes in the Swiss cheese happen to line up. This appears to have been the case with this particular crash.

• The direct cause was that the pilots attempted to take off without setting take-off flaps.
• They were rushing because they'd had a technical issue, and returned to the terminal after previously taxiing to the runway and completing the take-off checks. So they accidentally skipped the critical check that the flaps were deployed when they lined up to take off the second time.
• There's a take-off configuration alarm that is supposed to alert the pilots, but it wasn't working.
• It wasn't working because the engineer removed the circuit breaker that powered it, in order to turn off a stuck heater on a pitot tube that was due to a malfunctioning switch.
• This particular fault had been noted on previous flights, so should have flagged a warning on the airline's fault monitoring system.
• The fault monitoring system had a trojan.

Yup, the holes in the cheese certainly lined up that day. None of these, by itself, would have caused the crash.