- Argument1 of 2›
A vehicle driven by software can be driven by someone other than its owner
The argument
The first disadvantage concerns what it means to put driving under software control. A conventional car can be stolen or sabotaged, but doing either requires physical access to that particular vehicle. A vehicle that receives updates, map data and traffic information over a network, and that is steered by the code those channels maintain, can in principle be reached without anyone going near it. Proponents of this position argue that the exposure is not an incidental weakness to be patched but a consequence of the design: the same connectivity that lets a fleet be improved centrally lets it be reached centrally. The second part of the argument concerns scale. The damage a tampered vehicle can do is bounded by that vehicle; the damage done to a shared system is bounded by the size of the fleet. Vehicles built in the same series run the same software, so a single defect or a single intrusion is present in every one of them at once, which is a kind of risk the road has not carried before. Proponents add that the problem is not limited to deliberate attack. A vehicle depending on sensors, maps and connectivity can be confused by altered road markings, obscured signs, severe weather or a map that is out of date, and an occupant is not placed to take over if they have not been driving and were never required to watch. On this account the disadvantage is the loss of the independence that made each vehicle a separate and self-contained risk.
Premises
Counter-arguments
Critics reply that the objection applies to connected vehicles rather than to automation, and that cars have been running networked software for years without the scenario described. They add that the risks named are the ordinary subject matter of security engineering: signed updates, separation of driving systems from entertainment and connectivity, staged rollouts and offline fallbacks all exist precisely to stop a remote instruction reaching a steering column. The fleet-wide argument also cuts the other way, since shared code can be corrected fleet-wide within hours while a mechanical recall takes months. On that view the concern is a reason to regulate how such vehicles are built rather than a disadvantage of letting them drive.
Rejecting the premises
[Rejecting P1] Networked software is already present in conventional vehicles, so the exposure described belongs to connectivity rather than to automated driving. [Rejecting P2] Separating driving systems from networked ones is standard engineering practice, so central reachability is a design choice rather than a consequence of central improvement. [Rejecting P3] Common software also permits a fleet-wide correction within hours, which is faster than any mechanical recall, so shared code is a mitigation as well as a risk. [Rejecting C] At most it follows that such vehicles must be built and regulated carefully, not that interference is a disadvantage of automating them.