|
|
|
|
|
by eslaught
2806 days ago
|
|
What bothers me is that this has to be designed under the assumption that the other car could be malicious and that any input received could be intentionally deceptive. I'm just not convinced that auto (or aerospace) companies have a high level of competency in thinking like this. They're used to thinking about physical defects, weather effects, bad users, and the like. It's very different if you have internet connected cars that could be (possibly in bulk) remotely hacked and given instructions to intentionally disrupt other cars. Everything I have ever seen about vulnerabilities in car software systems has indicated a very poor understanding of the threat landscape on the part of car manufacturers and an embarrassingly weak ability to competently deal with these threats. So far this has been understandable since cars have been minimally networked, but going forward, I agree with GP that the appropriate term is "terrifying". |
|
But if we can be certain based on the physics of the system that we are talking to the car in front of us, the fact is, there’s plenty of ways you can commit vehicular homicide today, and V2V doesn’t seem like a particularly “worse” way, and frankly, one of the most traceable ways you could probably try to hurt someone.
So while certainly you need to defend against broken and malfunctioning input, I’m not quite convinced the malicious input is actually a case that needs to be specifically defended against.
The vehicle will have a “flight envelope” based on its own local sensors and rules just like modern aircraft that don’t allow even bad inputs to stall the plane. The inputs from V2V would not let you leave the envelope any more than the autopilot inputs would. I believe the steering wheel would still be allowed to exceed the envelope, for as long as there is a steering wheel.