Ignoring that, that ransomware wont' even exist for a number of reasons, the biggest being it wouldn't be profitable. Ransomware authors aren't going to get a payout, very few people are going to be able to buy Bitcoin in 30 minutes while unable to leave their car even if they wanted to. Not only that, it isn't remotely difficult to have a manual, physical, kill switch that physically stops the car in a life or death situation. Even if you didn't have a kill switch, you could simply call the police and they can lay down a spike strip.
>who are careful because they fear their own death just as much as I do.
LOL! That's a good one! Have you actually even been on the roads before!?! When I worked drive thru I had people who were so drunk they could hardly form a sentence come through my drive thru. That's just ONE example.
You share the road with these upstanding citizens who are clearly very careful and concerned for their own wellbeing: https://www.youtube.com/watch?v=DcnuIWNv8lw https://www.youtube.com/watch?v=9hddt4bWNns
> Road fatalities are already the number 1 killer of some age groups
You're hiding a weakness in your argument by not specifying the age groups. You're hiding a weakness in your argument by restricting to cross-sections of the population that support your argument. You're misleading your listener by hiding the fact that this statement isn't because traffic accidents are unusually high, but that other causes of death are unusually low.
> Around 40,000 in the US last year.
Careful using absolute numbers, using 40,000 which is a very small number compared to other kinds of deaths like hard disease (800,000 deaths last year) can be misleading because 40,000 sounds like a big number.
> its estimated that over a million people worldwide die on the roads every year
You're hiding the fact that the US has 4% of the world's automobile deaths but 20% of the world's cars. You're using aggregate data to smooth over deaths that are caused by dangerous driving environments, roads, or ineffective traffic laws and misleading your listener into assuming that they're caused by human error.
Total deaths is not a useful statistic. The deaths that could have been prevented by L4 autonomous cars but could have not been prevented by L1-L3 or more conventional safety practices is what you should be presenting.
Give as little surface area as possible to people who would use it to push back.
As for sharing roads with others who fear death as much as I do. That's a wonderful idea, however in my case a pipe dream. I share the roads with people who have no problem speeding, driving under the influence or even refusing to use seatbelts.
Ultimately I'm more optimistic about solving the ransomware problem than I am about putting the fear of death into other humans.
Such malware are only possible because the targeted system has vulnerabilities to begin with. One just has to ensure the absence of such vulnerabilities, possibly using machine checked proofs.
One obvious approach is to properly isolate the driving software and sensors from external input.
Or what if an actor uses something like this:
https://techcrunch.com/2016/06/29/now-you-see-me-now-you-don...
that confounds the car's sensors. Self-driving cars have a whole spectrum of attack vectors that human beings don't have.
Yes, hostile input will have to be taken into account. Fortunately, this is easily detectable (just look at the logs). And if people die as the result, it will count as murder. Finally, one does not simply jam sensors from across the planet. You need a physical presence on site, and that's riskier than a remote hack.
A lot of the current driving issues do suck, but they still will suck with self-driving cars, as any computerized system has its own vulnerabilities. It's just they might be systemic and affect a lot more people in ways they can't compensate for.
Of course even machine checked proofs will have trouble finding vulnerabilities that creep in during the specifications stage or exist in the realm of hardware.
How do you isolate your sensors from external input and expect to do anything?
I did say "very expensive". But yes, if we're serious about correctness, safety, and security, I don't see any other choice. We should scrap the crap and spend the $billions necessary to rebuild it right.
Ideally. We don't really need to go that far. Isolation is possible and not that hard, see Qmail: http://hillside.net/plop/2004/papers/mhafiz1/PLoP2004_mhafiz...
> Of course even machine checked proofs will have trouble finding vulnerabilities that creep in during the specifications stage or exist in the realm of hardware.
I'm no hardware specialist, but you can still prove the correctness of the design of such and such hardware. The actual chips can still fail the specifications, but that's easier to test once you know the design itself is correct.
Also, specifications themselves can be checked. Only the high-level properties must ultimately be decided and reviewed by hand. Not that they won't be complicated or numerous, but that's still much smaller and easier to deal with than the entire implementation.
> How do you isolate your sensors from external input and expect to do anything?
I wasn't talking about the normal sensor input, which of course can be tricked the same way human sensory input can (for instance with a big flash or something). I was thinking about sensor command, such as which way they should be oriented or something. Though I expect most sensors will have no such input, and will only output to the system.
I used to think that was unlikely. Then I had a few discussions with people about the state of C, and things that could be done to make it default to a slightly more deterministic case by changing how undefined behavior is dealt with in regards to optimization. Now I think it's impossible, because nobody is willing to give up even theoretical unknown performance increases for more security. At least for C. You would have to use something that's much more strict about behavior, like Ada with SPARK, or possibly Rust.
I'm willing to bet most the code already written for these projects is C or C++. Good luck getting that changed if so.
Correct software is expensive. But if we make sure incorrect software is even more expensive, we'll get correct software.
Once the industry is forced to get serious about correctness, they will move away from the C/C++ minefield real quick βor at least come up with safe ways of using C and C++.
Correct software can be compromised via the update process, or social engineering. It's necessary, but not sufficient to ensure integrity.
A cheaper, correct option would be a mechanical lever/breaker labelled "manual override" for licensed drivers or "emergency stop" like they have on every industrial robot or heavy machinery since the 60's. Sometimes the answer to a software problem isn't more/better software.
http://cdn.static-economist.com/sites/default/files/images/2...
Since 1970 total airplane casualties have halved, while there are now 7 times the number of passengers. Much of this improvement has been due taking decisions away from pilots and into the hands of 'unfeeling' automated systems.
And then the cops/secret-service would get involved. If there's a death involved (and reason to believe more will occur in the future, which would be necessary for ransom as a prolonged business model), then they will come down on any ransomware (and responsible negligent parties, such as auto companies with shitty security) like a TON OF BRICKS.
Plus, there's still a lucrative malware model that goes like this: Infect the car, then quietly make it steal itself in the middle of the night (or at your moment of choice). Bam, you now have a stolen car that you can't be connected to, and nobody will notice for a while.
People will pay a fair amount of money to avoid a major inconvenience, but "my car won't start" is a lot less likely to have the FBI beating down your door.
Internet infrastructure is decentralized in nature, making it hard to control. Though rogue individuals can have outsized effects: https://www.wired.com/2008/02/pakistans-accid/