# Tesla Self Driving Car fatality

**URL:** <https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827>\
**Category:** In My Humble Opinion\
**Created:** [June 30, 2016, 9:03pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827 "2016-06-30T21:03:07Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![Sam\_Lowry](https://avatars.discourse-cdn.com/v4/letter/s/e95f7d/32.png) [@Sam\_Lowry](https://boards.straightdope.com/u/Sam_Lowry)\
**Post date:** [July 1, 2016, 9:18pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/61 "2016-07-01T21:18:42Z")

</div>

> [@Dr.Strangelove](#):
>
> It actually has an always-on 4G internet connection, so it’s not impossible. But as I said, almost everyone gets this right. It’s the fact that they don’t run arbitrary programs that keeps it safe.
> 
> Tesla runs hacking challenges and the general view is that they have very good security practices. No one has come close to any kind of wireless hacking. The only security holes found so far have required substantial physical access, like wiring into the Ethernet system. As you say, with physical access they can also just cut the brake lines.

Okay, that makes sense. Wireless hacking is theoretically possibly, but so far hasn’t happened, and seems fairly unlikely based on how the system is set up. As an average person, I wouldn’t be too worried about hacking. I’d guess that politicians or others that fear assassination attempts might take the small theoretical chance of hacking into account and weigh it against the otherwise increased safety of cars with automatic driver assistance.

---

<div class="post-metadata">

**Author:** ![gigi](https://avatars.discourse-cdn.com/v4/letter/g/a587f6/32.png) [@gigi](https://boards.straightdope.com/u/gigi)\
**Post date:** [July 1, 2016, 10:19pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/62 "2016-07-01T22:19:00Z")

</div>

> [@panache45](#):
>
> Therein squats the toad.

Wait, there are self-driving robot toads now? I remain skeptical.

---

<div class="post-metadata">

**Author:** ![Stranger\_On\_A\_Train](https://avatars.discourse-cdn.com/v4/letter/s/13edae/32.png) [@Stranger\_On\_A\_Train](https://boards.straightdope.com/u/Stranger_On_A_Train)\
**Post date:** [July 2, 2016, 1:12am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/63 "2016-07-02T01:12:26Z")

</div>

> [@Dr.Strangelove](#):
>
> The vast majority of security holes come from running general-purpose software on computers. It is very difficult to close off all possible avenues for attack. But the Tesla doesn’t load general-purpose software (like a desktop PC or phone), so it’s not prone to these attacks.

Actually, the vast majority of security holes come from ignorant users giving away access codes, unlocking permissions, and doing other things that even a general purpose operating system shouldn’t allow. Locking down a dedicated embedded real-time operating system is not that difficult, and Internet or wireless secure communications using modern public key encryption systems are, barring intentional security flaws to leave a backdoor or the advent of quantum cryptocracking systems, can be made so secure that even a dedicated effort to introduce malicious code into the system would be an exercise in futility. In the extreme, a synchronous digital signature verification system could be permanently programmed into the embedded hardware (one time programmable read only memory) which would check and verify any attempt to upload new software to the system against a certified authority. Making the system robust against man-in-the-middle intrusion (e.g. introduction of a vulnerability into the software or hardware by someone involved in production) is a process engineering challenge, but aside from this you could make a secure embedded system absurdly secure. There are many, many challenges with assuring the robustness and reliability of software, but actual security isn’t one of them provided you control the source verification and operating hardware.

Stranger

---

<div class="post-metadata">

**Author:** ![scr4](https://avatars.discourse-cdn.com/v4/letter/s/59ef9b/32.png) [@scr4](https://boards.straightdope.com/u/scr4)\
**Post date:** [July 2, 2016, 2:11am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/64 "2016-07-02T02:11:42Z")

</div>

> [@Jackmannii](#):
>
> If you just smash into the side of the semi you’ll be A-OK.

Actually yes, on a modern car, you’re far better off driving into a low barrier than a high (windshield height) obstacle. The crumple zone does nothing if you drive into a high barrier, and the passenger cage isn’t designed to withstand that kind of impact.

But more importantly, if this trailer had side guards, the Tesla’s radar and camera would probably have detected it.

---

<div class="post-metadata">

**Author:** ![cochrane](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cochrane/32/10441_2.png) [@cochrane](https://boards.straightdope.com/u/cochrane)\
**Post date:** [July 2, 2016, 2:26am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/65 "2016-07-02T02:26:18Z")

</div>

> [@gigi](#):
>
> Wait, there are self-driving robot toads now? I remain skeptical.

Well, they’re not for everyone. I hear they give a pretty wild ride.

---

<div class="post-metadata">

**Author:** ![Dewey\_Finn](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dewey_finn/32/4222_2.png) [@Dewey\_Finn](https://boards.straightdope.com/u/Dewey_Finn)\
**Post date:** [July 2, 2016, 3:36am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/66 "2016-07-02T03:36:38Z")

</div>

> [@cochrane](#):
>
> The truck driver told the AP that the driver of the Tesla was driving while distracted.
> 
> > [@](#):
> >
> > Frank Baressi, 62, the driver of the truck and owner of Okemah Express LLC, said the Tesla driver was “playing Harry Potter on the TV screen” at the time of the crash and driving so quickly that “he went so fast through my trailer I didn’t see him.”
> > 
> > “It was still playing when he died and snapped a telephone pole a quarter mile down the road,” Baressi told The Associated Press in an interview from his home in Palm Harbor, Florida. He acknowledged he couldn’t see the movie, only heard it.
> > 
> > Tesla Motors Inc. said it is not possible to watch videos on the Model S touch screen. There was no reference to the movie in initial police reports.
> 
> [http://abcnews.go.com/Technology/wireStory/driving-car-driver-died-crash-florida-40260566](http://abcnews.go.com/Technology/wireStory/driving-car-driver-died-crash-florida-40260566)
> 
> This is an admittedly biased account, though, as the police reports don’t mention distraction on the Tesla driver’s part.

[Reuters reported](http://www.reuters.com/article/tesla-autopilot-dvd-idUSL1N19N12U) that a portable DVD player was found in the car. So even if it’s not possible to watch a movie on the Tesla’s screen, the driver might have been watching the Harry Potter movie on the portable DVD player.

---

<div class="post-metadata">

**Author:** ![Dr.Strangelove](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dr.strangelove/32/6613_2.png) [@Dr.Strangelove](https://boards.straightdope.com/u/Dr.Strangelove)\
**Post date:** [July 2, 2016, 4:38am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/67 "2016-07-02T04:38:03Z")

</div>

> [@Stranger\_On\_A\_Train](#):
>
> Actually, the vast majority of security holes come from ignorant users giving away access codes, unlocking permissions, and doing other things that even a general purpose operating system shouldn’t allow.

Security which depends on untrained end users for enforcement isn’t security at all. It’s an acceptable tradeoff for most purposes–the advantages of general-purpose computers outweigh the security risks most of the time. Obviously this risk isn’t acceptable for safety-critical systems like on a car.

> [@Stranger\_On\_A\_Train](#):
>
> In the extreme, a synchronous digital signature verification system could be permanently programmed into the embedded hardware (one time programmable read only memory) which would check and verify any attempt to upload new software to the system against a certified authority.

Not so extreme. Just about all field-patchable embedded systems do (more or less) this already. Gaming consoles, phones, tablets, and indeed Teslas use signed firmware. It’s easy enough to get right that I’m not aware of it having ever been the avenue of attack. The signing keys are easy to secure since very few parties need access to them; the released image doesn’t contain the information needed for an attack to work. The CPU will not execute the image unless it passes the sign checks. No information on an external pin will ever be useful in bypassing this (though with nation-state resources, you could conceivably physically modify the CPU to ignore the checks).

---

<div class="post-metadata">

**Author:** ![Maserschmidt](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/maserschmidt/32/18829_2.png) [@Maserschmidt](https://boards.straightdope.com/u/Maserschmidt)\
**Post date:** [July 2, 2016, 5:11am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/68 "2016-07-02T05:11:15Z")

</div>

> [@Sam\_Lowry](#):
>
> Okay, that makes sense. Wireless hacking is theoretically possibly, but so far hasn’t happened, and seems fairly unlikely based on how the system is set up. As an average person, I wouldn’t be too worried about hacking. I’d guess that politicians or others that fear assassination attempts might take the small theoretical chance of hacking into account and weigh it against the otherwise increased safety of cars with automatic driver assistance.

Yes, wireless hacking has occurred…

> **[Hackers Remotely Kill a Jeep on the Highway—With Me in It](https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/)**
>
> I was driving 70 mph on the edge of downtown St. Louis when the exploit began to take hold.

---

<div class="post-metadata">

**Author:** ![Stranger\_On\_A\_Train](https://avatars.discourse-cdn.com/v4/letter/s/13edae/32.png) [@Stranger\_On\_A\_Train](https://boards.straightdope.com/u/Stranger_On_A_Train)\
**Post date:** [July 2, 2016, 6:05am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/69 "2016-07-02T06:05:18Z")

</div>

> [@Dr.Strangelove](#):
>
> Not so extreme. Just about all field-patchable embedded systems do (more or less) this already. Gaming consoles, phones, tablets, and indeed Teslas use signed firmware. It’s easy enough to get right that I’m not aware of it having ever been the avenue of attack. The signing keys are easy to secure since very few parties need access to them; the released image doesn’t contain the information needed for an attack to work. The CPU will not execute the image unless it passes the sign checks. No information on an external pin will ever be useful in bypassing this (though with nation-state resources, you could conceivably physically modify the CPU to ignore the checks).

I’m not talking about single signed firmware but an actual external verification server which validates both the upload and the hardware, making it essentially impossible to even reverse engineer a firmware upgrade. The effort required to ‘hack’ such a system would be beyond any conceivable effort.

Stranger

---

<div class="post-metadata">

**Author:** ![GusNSpot](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/gusnspot/32/436_2.png) [@GusNSpot](https://boards.straightdope.com/u/GusNSpot)\
**Post date:** [July 2, 2016, 7:31am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/70 "2016-07-02T07:31:42Z")

</div>

I read some where that a blinding due to Sun angle/reflection or some such happened and a visual sighting was near impossible.

Nothing about why the radar or other systems did not detect it.

I personally am glad it is not common yet because the human factor will never be anywhere near good enough if there needs to be human attention.

My mileage is gonna stay on the back roads for the foreseeable future.

---

<div class="post-metadata">

**Author:** ![Dr.Strangelove](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dr.strangelove/32/6613_2.png) [@Dr.Strangelove](https://boards.straightdope.com/u/Dr.Strangelove)\
**Post date:** [July 2, 2016, 8:19am UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/71 "2016-07-02T08:19:04Z")

</div>

> [@Stranger\_On\_A\_Train](#):
>
> I’m not talking about single signed firmware but an actual external verification server which validates both the upload and the hardware, making it essentially impossible to even reverse engineer a firmware upgrade. The effort required to ‘hack’ such a system would be beyond any conceivable effort.

Fair enough, though overkill for this situation. Arguably, making it impossible to reverse engineer the firmware could result in a decrease in security, by making it more difficult for legitimate security researchers to investigate side-channel attacks. Verified hardware is interesting, but again not particularly useful in this situation.

---

<div class="post-metadata">

**Author:** ![Maserschmidt](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/maserschmidt/32/18829_2.png) [@Maserschmidt](https://boards.straightdope.com/u/Maserschmidt)\
**Post date:** [July 2, 2016, 12:47pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/72 "2016-07-02T12:47:10Z")

</div>

> [@Stranger\_On\_A\_Train](#):
>
> I’m not talking about single signed firmware but an actual external verification server which validates both the upload and the hardware, making it essentially impossible to even reverse engineer a firmware upgrade. The effort required to ‘hack’ such a system would be beyond any conceivable effort.
> 
> Stranger

> **[Black Hat USA 2015: The full story of how that Jeep was hacked](https://www.kaspersky.com/blog/blackhat-jeep-cherokee-hack-explained/9493/)**
>
> Recently we wrote about Jeep Cherokee hack incident. At Black Hat security researchers Charlie Miller and Chris Valasek finally explained, how exactly that hack was done

If I understand the Jeep hack correctly, they thought they could get to authorized firmware indirectly, through a different unprotected system that connected internally to it.

---

<div class="post-metadata">

**Author:** ![Stranger\_On\_A\_Train](https://avatars.discourse-cdn.com/v4/letter/s/13edae/32.png) [@Stranger\_On\_A\_Train](https://boards.straightdope.com/u/Stranger_On_A_Train)\
**Post date:** [July 2, 2016, 1:29pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/73 "2016-07-02T13:29:39Z")

</div>

> [@Dr.Strangelove](#):
>
> Fair enough, though overkill for this situation. Arguably, making it impossible to reverse engineer the firmware could result in a decrease in security, by making it more difficult for legitimate security researchers to investigate side-channel attacks. Verified hardware is interesting, but again not particularly useful in this situation.

Verification of hardware prevents users from modifying hardware (so-called ‘hard hack’) and then gaining access to firmware source. The transparency argument cuts both ways; yes, closed and secured hardware and firmware makes it difficult for independent researchers to evaluate vulnerabilities, but the same is true for malicious programmers. Any sufficiently complex system will inevitably have vulnerablities of some kind, especially if the malicious party can gain physical access to the device in question, and one way of preventing that is to lock the system down sufficiently that it is a virtual black box which has a very constrained set of interfaces. Companies may value Linux and OpenBSD for the community-supported robustness testing, but when they implement an actual Internet-facing server, they shut down all but the necessary external ports and then require authentication for any users or interfaces trying to access the system to limited the potential for probing attacks. Given that the hardware in this case is essentially available to anyone who purchases a vehicle (no degree of physical security will prevent a determined hacker from being able to get to the controller), a hardcoded limitation of the hardware to both verify firmware upgrades or physical modification is prudent and not difficult to implement.

> [@Maserschmidt](#):
>
> [https://blog.kaspersky.com/blackhat-jeep-cherokee-hack-explained/9493/](https://blog.kaspersky.com/blackhat-jeep-cherokee-hack-explained/9493/)
> 
> If I understand the Jeep hack correctly, they thought they could get to authorized firmware indirectly, through a different unprotected system that connected internally to it.

From the article that you linked to:Researchers discovered an opportunity to change firmware of the V850 controller for their maliciously crafted version through the connection to multimedia system’s controller. **This firmware ‘upgrade’ can be done without any checks or authorizations.** Even if there was authorization, researchers have found a couple of vulnerabilities that make possible taking control over this V850 controller.  
Automobile controllers are vulnerable because manufacturers didn’t anticipate that someone might attempt to maliciously exploit them, which again, argues for a need for a regulatory framework which requires specific security measures. This is not a new issue; aircraft and satellite manufacturers have been quietly dealing wih this for years by developing secure control and communications systems. There are several encryption systems being developed for implementation in CAN bus architectures to make them robust against third party intrusion or control. There is nothing particularly challenging about this; it just requires engineering discipline and thorough test verification.

Stranger

---

<div class="post-metadata">

**Author:** ![mascaroni](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mascaroni](https://boards.straightdope.com/u/mascaroni)\
**Post date:** [July 2, 2016, 1:49pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/74 "2016-07-02T13:49:07Z")

</div>

[QUOTE=Mr Albert Hammond on 15th September 1830]  
Someone has already been killed By [Stevenson’s locomotive](https://en.wikipedia.org/wiki/Opening_of_the_Liverpool_and_Manchester_Railway). These killer robots are not the future…  
[/QUOTE]

It’s not a new problem, is it?

---

<div class="post-metadata">

**Author:** ![AnalogSignal](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/analogsignal/32/1085_2.png) [@AnalogSignal](https://boards.straightdope.com/u/AnalogSignal)\
**Post date:** [July 2, 2016, 3:16pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/75 "2016-07-02T15:16:26Z")

</div>

This article speculates on a Tesla blindspot. The radar only sees things below the windshield. The bottom of the truck was too high for radar to pick it up. It true, they gotta fix this fast!

> **[Does Tesla's Autopilot Suffer From A Dangerous Blind Spot?](https://jalopnik.com/does-teslas-semi-autonomous-driving-system-suffer-from-1782935594)**
>
> A grim milestone has been set in the history of automobiles: the first person was killed while a semi-autonomous car was driving. While it will be up to the National Highway Traffic Safety Administration to officially determine what went wrong, this...

---

<div class="post-metadata">

**Author:** ![usedtobe](https://avatars.discourse-cdn.com/v4/letter/u/ec9cab/32.png) [@usedtobe](https://boards.straightdope.com/u/usedtobe)\
**Post date:** [July 2, 2016, 6:19pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/76 "2016-07-02T18:19:31Z")

</div>

Cars have been driving (almost) under trucks and and trailers for decades (See: Jan and Dean).

Maybe “Because robot cars can’t see them” will be the point which gets something done about it.

Then we can work on “Because you’re invisible in rain/fog” to do something about Silver color on cars - the “your ass is on the line” will work for small cars; larger ones may require more overt convincing.

---

<div class="post-metadata">

**Author:** ![aceplace57](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/aceplace57/32/3500_2.png) [@aceplace57](https://boards.straightdope.com/u/aceplace57)\
**Post date:** [July 2, 2016, 6:31pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/77 "2016-07-02T18:31:25Z")

</div>

He gives a good solution in that article.

I wonder how well Tesla sees animals? Like deer or a cow in the road? Deer cause many bad wrecks in my state.

I think, after these wrecks, Tesla should temporarily disable Autopilot until they have a system in place that insures that no object can impact the windshield area undetected. This could just be a software update, or it could require an upper radar unit, or perhaps the new camera setup will help.

---

<div class="post-metadata">

**Author:** ![usedtobe](https://avatars.discourse-cdn.com/v4/letter/u/ec9cab/32.png) [@usedtobe](https://boards.straightdope.com/u/usedtobe)\
**Post date:** [July 2, 2016, 6:32pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/78 "2016-07-02T18:32:04Z")

</div>

The “fix” for this could have cars stopping (default “solution”) when “seeing” an overhead sign.

A semi trailer up close has much the same geometry as an Interstate sign at 400 yards.

I’m guessing the truck driver did not see the car and turned immediately in front of it.

Approaching the “thing-which-turned-out-to-be-a-truck”, the cars saw a motionless object.  
When it turned, it saw “someting-darting-across-lane” (the cab of the truck) followed by something overhead consistent with “overhead sign”.  
None of these things signaled Emergency Braking.

I’m guessing the final outcome:  
Trucks can kill cars if they turn across the car’s lane at the last second.

The (non-)driver could not have done better than the robot.

I do hope it makes Tesla stop referring to its “driver assist technology” as “Autopilot”.

When your robotics can handle all the same kinds of situations a real Autopilot (see: Boeing and Airbus products), call it an “Autopilot”.  
For now, it is “Driver Assist Technology”.

---

<div class="post-metadata">

**Author:** ![aceplace57](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/aceplace57/32/3500_2.png) [@aceplace57](https://boards.straightdope.com/u/aceplace57)\
**Post date:** [July 2, 2016, 6:32pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/79 "2016-07-02T18:32:33Z")

</div>

That’s a quote. I can’t add the tags in Tapatalk

---

<div class="post-metadata">

**Author:** ![usedtobe](https://avatars.discourse-cdn.com/v4/letter/u/ec9cab/32.png) [@usedtobe](https://boards.straightdope.com/u/usedtobe)\
**Post date:** [July 2, 2016, 6:36pm UTC](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827/80 "2016-07-02T18:36:24Z")

</div>

“No Object”?  
If that is your criteria, expect a really, really long wait - some idiot with a quadcopter will still get through.  
Let alone a POTUS with Hellfire missiles…

How about something falling off the truck ahead?

95% can be easy. 100% is almost always impossible.

[Previous page](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827.md?page=3)

[Next page](https://boards.straightdope.com/t/tesla-self-driving-car-fatality/758827.md?page=5)
