RomP

It was speeding. Bill is well-known for his love to fast cars. Later, in Seattle, he held the record of fastest Microsoft -> SEA airport drive, for a very long time. The legend says it was only beaten by someone illegally using HOV lanes, but Bill very justifiably refused to recognize that time.

Crashes Safari on iPad 2. Latest iOS.

This is simply unkind to the competition (and to the poles alike): "Tesla achieved this outcome by nesting multiple deep aluminum extrusions in the side rail of the car that absorb the impact energy (a similar approach was used by the Apollo Lunar Lander) and transfer load to the rest of the vehicle. This causes the pole to be either sheared off or to stop the car before the pole hits an occupant."

There's winning and there's crushing the opponents. One shouldn't gloat in the latter case, but this case deserves an exception.

Congratulations Elon and the team on tremendously nice engineering!

one word: synchronization

How about the following schema for adding a new key to the list of Authorized Keys when NO AUTHORIZED KEY IS PRESENT:

* the procedure requires a module produced and sold by the manufacturer() to any garage that can verify its identity and satisfy manufacturer's specified security requirements (e.g. owning a safe and having no history with local police);

each such module is unique. It contains unique public/private keys and its public key is singed by the manufacturer;

* the procedure of adding the key to the list of Authorized Keys requires the car (actually, its ECU) to only accept incoming requests signed by such modules whose public keys are signed by the manufacturer. When the key is added, the ECU stores:

the key info;

the module's unique ID (IMPORTANT);

timestamp + lat/long;

* if there are no old authorized keys present (very rare scenario, since most of the time the owners want to replace just one lost/stolen key, but not both), the ECU requires 15 minute grace period with the module attached at all times, during which the car is flashing its hazard lights and honks. It makes a small nuisance in the garage once in a while, but attracts enough attention in the middle of the night if somebody is stealing it.

Now, if the car is stolen and then recovered, the police would dump the list of authorization requests and identify the module used. If this module was stolen or copied, the garage who owned the module becomes responsible for the damage to the car's owner. The ID of the module is placed on the revocation list. The revocation list is broadcasted via Sirius/XM/FM/BMW Assist/OnStar/Intelsat/etc.

This allows independent garages working on the cars, but places enough responsibility on them for keeping the system secure, with the override mechanism in form of revocation lists.

This method would NOT prevent all types of thefts (thugs can put the car on the flatbed and do the swap in the middle of the desert, or they can swap the ECU unit completely, or do some manipulations with the stolen "good" key), but it makes it significantly more difficult to authorize a new key and drive away.

(*) in case the manufacturer ceases to exist, some other company (another car manufacturer, perhaps) inherits the master key and will be responsible for authorizing garages to do key management.

Can we just stop beating this dead horse for once please?

Obscured, mostly by our own galaxy.

I'm one of them. I asked this same question in my team a few weeks ago: I got very similar sampling. The team is composed of 7 hackers (native code, embedded speech-related software). In other words, I tend to believe the results we're getting so far.

I'm not an Airbus engineer and I'm not privy to their research (undoubtedly many thousands hours involving scenarios we can't even imagine) and the reasoning behind this design. This catastrophe is rooted in human-machine interface and we should wait for the official investigation report, which will come very shortly and will include recommendations to aircraft designers (including UI aspects), training procedures and crew management procedures, to mention just a few.

My layman view is that the first step in principle "fly-navigate-communicate" could be accomplished by placing the aircraft into the "pitch an power" configuration: 5 degrees nose up + TOGA. This didn't happen. But this is my layman view: I'm down here in a comfy chair with a cup of tea, and they were up there, in a thunderstorm with flashing warning lights, frozen pitot tubes and 228 souls behind their back. We shouldn't judge them: we should only learn.

Great narrative, but factually wrong on at least two accounts:

>If the pilots has switched a button to re-enable autopilot, everyone on board would have lived. But they didn’t. One co-pilot made a single, absurd mistake–for twenty full minutes–that brought the plane down.

First factual error: The button they should've switched is not the auto-pilot button (which they operate many times per flight), but the flight mode button (which most pilots never operate in their career). When the plane lost at least two of the three pitot tube readings, it went from the NORMAL "Law" to the ALT "Law", where the airplane doesn't guard itself against many pilot errors. When the pitots de-iced shortly thereafter, the plane did NOT go back to NORMAL "Law": it had to be switched there manually. The pilots did not do that and it seems to be the consensus so far (can't state that for certain before the official report is released) that they did not realize they were flying the plane in ALT and then DIRECT Law.

Second factual error: the "absurd mistake" lasted nowhere near 20 minutes. The first problem appeared at 2:10:03UTC and flying into the ocean occurred at 2:14:28UTC -- 4 minutes 23 seconds in all.