I agree with the sentiment about programming skill, but I think Toyota, not Honda, had the more significant unintended acceleration issues (according to CBS News and NHTSA, as many as 89 deaths).

The FBI is under the Department of Justice, not Treasury.

As an embedded systems (electronics/firmware) engineer, I was going to half-jokingly, half-seriously say, "Well, we'll just send a new firmware update to Curiosity to help with the problem." And then of course as I read the article, that was one of the proposed mitigations:

Changing driving software to reduce the forces experienced by wheels hanging up on pointy rocks. <snip> The rover can sense wheel currents, so it can sense when a wheel is sticking. <snip> By implementing a "smart controller" on the wheel current and allowing wheel rotation rates to vary intelligently in response to sensed conditions, they might be able to mitigate the damage.

I've been developing embedded systems for more than half my life, and I never get bored...

I have heard rumors at least twice, from two different people that I trust (sorry for the "cloak and dagger" bullshit) that Hastings has investigated creating an ISP, but that the hurdles and bullshit threshold is just too high. That makes me sad. There is so much opportunity for innovation, so much potential to move away from the shitty 6Mbps "broadband" in most of America, but the Verizons & Comcasts buy their way out of the problem every time. And yes, the government (both parties, I'm looking at you) is complicit.

I always thought "CO" was Central Office, not Communications Office.

I think the real issue is that people tend to use the same login info on multiple websites. So even if having access to the victim's CNN profile is no big deal, having access to Clarence's Amazon login credentials is a whole different matter.

What states are those? I travel around the U.S. *a lot*, and I've never seen this... I'm guessing it's going to be something like Wyoming, North Dakota, etc. (I'm asking sincerely - I think at one time some of those states had no real "upper speed limit" - the law was written to the effect "can't travel faster than the conditions allow" or something like that..)

I think it's literally called "Elephant" (as in, "an elephant never forgets").

(Honestly, at first I thought you might be thinking of Evernote (apologies!), but then I saw your UID & figured that was very unlikely...)

Agreed. And with a Toyota, the car might very well accelerate to 100 MPH, crash and burn all on its own.

"Cheaper than a New York taxi"... umm, "What is a bar of gold, Alex?"

OK something here doesn't make sense. The company "shut its doors". Maybe we define things differently, but to me that means filing for dissolution; not Chapter 13, not in hibernate mode - "shut the doors". I've personally been screwed over by a company that owed me a significant sum when they dissolved the company... at that point, you can go pound sand, the corporation is the equivalent of a dead body -- scream at it all you want, nothing's going to happen.

"Nice blimp ya got there. Sure would be a shame if something happened to it."

Ummmmm.... you might wanna be careful there. Especially the "dunno where they come from, I don't care." You should.

If some scammer from FooVille fills up a CD with images pulled from the internet, images he/she has no right to re-distribute (copyright assignment), you are exposed as well. Even if you can point to the CD, point to the scammer and say, "Here's the order, this person told me he owned all the rights, blah blah blah", I can assure you that the tenet "ignorance is no excuse" still holds. This would be considered mitigating factors, but you would still be on the hook. Particularly if the original source is Getty Images or the like, they'll go after you on principle alone.

Don't get me wrong, you're trying to do the right thing, and the whole flipping copyright law is buggered. I'm just telling you, you are still seriously exposed. Tread carefully!

The classic example of a compiler interfering with intention, opening security holes, is failure to wipe memory.

On a typical embedded system - if there is such a thing (no virtual memory, no paging, no L3 cache, no "secure memory" or vault or whatnot) - you might declare some local (stack-based) storage for plaintext, keys, etc. Then you do your business in the routine, and you return.

The problem is that even though the stack frame has been "destroyed" upon return, the contents of the stack frame are still in memory, they're just not easily accessible. But any college freshman studying computer architecture knows how to get to this memory.

So the routine is modified to wipe the local variables (e.g. array of uint8_t holding a key or whatever...) The problem is that the compiler is smart, and sees that no one reads back from the array after the wiping, so it decides that the observable behavior won't be affected if the wiping operation is elided.

My making these local variables volatile, the compiler will not optimize away the wiping operations.

The point is simply that there are plenty of ways code can be completely "correct" from a functional perspective, but nonetheless terribly insecure. And often the same source code, compiled with different optimization options, has different vulnerabilities.

Matt Green, the cryptographer leading the TC audit effort, had established contact with one or more developers (somehow) over the last year or so.

So, to most of us, the TC developers are still anonymous, but not to everyone...