[mike-cardwell]

"In one scenario, it appears, a driver is looking for a parking space and drives over a giant QR code on a street or in a parking garage. The QR code might either have exact directions to a specific parking spot, or it might link to a parking garage database of which parking slots are open."

This strikes me as ripe for abuse.

[patrickod]

Surely the technical part is no more open to abuse than normal parking signs in cities listing the amount of available spaces in certain car parks.

The QR codes would contain very little information I would imagine but rather a key that is used by the car as an argument for further operations. Leaving all the directional data on the road would be way too easy to abuse.

[mike-cardwell]

You're thinking too small.

"it might link to a parking garage database of which parking slots are open"

Imagine creating a QR code, (or copying one that already exists) which tells the car to fetch information from http://your.competitor.example.com/. Then imagine going out late at night and sticking it on a busy motorway.

DOS by traffic.

Also. You better hope that your car doesn't have any vulnerabilities that can be abused by a specially crafted QR code, or by fetching specially crafted data that a QR code prompts it to fetch.

[VBprogrammer]

You're thinking way too tin hat.

While we're there we better do something about all those people using radio jammers to down auto-landing aircraft.

Also, you better hope their are no vulnerabilities in the automatically driven mono-rail / train system you are riding in.

These type of issues are going to be discussed to the end of the earth but I can't wait to see driverless cars make their way from the lab to the car dealer.

As far as introduction, I would bet these features will be added to high-end luxury models and quite possibly initially limited to main roads (motorways / interstates) where the chances of encountering something unusual are lower. With the addition of a fair splattering of warning labels.

[nitrogen]

Quote from VBprogrammer:

You're thinking way too tin hat.

I very, very rarely resort to ad hominem, least of all on HN, but your nickname says it all (if indeed VB refers to Visual Basic). Far too many computer problems of yore were created by VB programmers not being nearly "tin hat" enough. When engineering systems which can damage other systems or cause bodily harm, one's responsibility is to anticipate, mitigate, and prevent the worst case scenario to the maximum extent possible.

[VBprogrammer]

Well VBprogrammer is a moniker I've used since I was 14. I now work for a company building websites which have thousands of hits a minute, require PCI compliance and use a variety of tools, none of which are Visual Basic.

Given that you resorted to ad hominem I assume you have no other reasonable arguments against what I said.

[nitrogen]

I understand the desire to keep an old handle. Regarding your last paragraph, I believe my second sentence stands on its own, and that others have said anything else I might care to express. Basically, with something that has the potential to maim and kill (like self-driving cars), I expect engineers to take every precaution.

[mike-cardwell]

It's called speculation. I am fully aware that they will prevent issues like this from happening. It's still interesting to consider them though. In the end, somebody has to take these issues into consideration.

[thomaslangston]

If that's all it takes to DOS your competitor, well, I don't think you have much to worry about from them. Even a busy motorway doesn't have that many cars passing over it per minute.

Also you're going out on a highway, at night, to lay down a big sticker. That's dangerous, suspicious, and illegal (before we even considering what the sticker does). If you want to DOS a competitor there are much more effective and safe ways to do so.

[tvon]

Also consider that with self driving cars, passengers will likely pay a decreasing amount of attention to what's going on outside of the vehicle.

[buro9]

Why?

Could you not have the QR codes generated against a private key and the vehicle verify it against the public key to determine whether the instruction came from a trusted source?

Just because it's plain text data in a QR code doesn't mean that it's inherently ripe for abuse.

[adaml_623]

The instruction might be from a trusted source but how do you guarantee that it is in the correct place.

How could people resist creating a loop of instructions...

[devicenull]

I guess you could encode the GPS coordinates of the marker within it, and have the car verify that. Still not a great way of doing it though.

[arethuza]

If you know your location via GPS and connection to the net, why not just look up the instructions relevant to that location?

[mike-cardwell]

And when the key is compromised, have fun replacing every single QR code.

[buro9]

But if the signs are electronic, as in... providing the location of the nearest empty parking space... then updating them should be effortless.

Lots of assumptions here from everyone about how the signs are implemented and what the QR codes contain, but the general gist is that they could be secured. Assuming otherwise is also an assumption.

[Someone]

a) I do not see how having 'electronic signs' would be a good idea. Why bother updating a LCD or so with a QR code if you could just as well use BlueTooth to communicate? The latter likely is more robust and cheaper.

b) The idea is not to have electronic QR signs, it is to have QR signs that contain something like a URL that contains up-to-date info about a place. Replace that URL by your own, and have fun :-)

[JonnieCache]

>This strikes me as ripe for abuse.

Yeah. The obvious first idea is to sign the codes, but then when the private key gets stolen (100% certain to happen sooner or later,) you have to repaint every road.

[damoncali]

It also wont work when it snows.