License Plate "NULL"

There was a DefCon talk by someone with the vanity plate "NULL." The California system assigned him every ticket with no license plate: $12,000.

Although the initial $12,000-worth of fines were removed, the private company that administers the database didn't fix the issue and new NULL tickets are still showing up.

The unanswered question is: now that he has a way to get parking fines removed, can he park anywhere for free?

And this isn't the first time this sort of thing has happened. Wired has a roundup of people whose license places read things like "NOPLATE," "NO TAG," and "XXXXXXX."

Posted on August 23, 2019 at 6:19 AM • 37 Comments

Comments

ID-10-tAugust 23, 2019 6:24 AM

For a moment, I thought someone was announcing an SQL injection attach against highway license plate scanners {grin}.

Petre Peter August 23, 2019 7:15 AM

From what I understand you can be sent to court in MA for a caret (') on your licence plate.

JuozasAugust 23, 2019 7:16 AM

He can park for free only in the cash terms. The time cost of dealing with all those looming fines probably outsets any gains he can make from free parking.

GrahamAugust 23, 2019 7:27 AM

This makes me think they have a poorly designed app, as in database terms, NULL does not equal NULL. (I assume they're entering the string "NULL".)

PaulAugust 23, 2019 7:43 AM

So the takeaway from the Wired article is that no-one fixed the problem, they just told ppl to write something different (IE, "none" instead of "no plate"). So if I get the personal plate "none" won't I be back in the same situation as the original person?

Random Internet UserAugust 23, 2019 8:04 AM

I'm finding myself visualizing someone with an SQL xp_cmdshell type of one liner taped to the front and back of their car, driving through the choke point into the capital city in the country I live in (which is guarded by a huge rack of cameras doing all sorts of stuff while driving in and out of the city).

E.M.H.August 23, 2019 8:10 AM

So is this a case of the ticket database improperly sanitizing its inputs? Or is it that they more properly filter them than we initially imagined? :D

KevinAugust 23, 2019 8:57 AM

As a counterpoint to the disadvantages: a friend of mine has the NULL plate in this state, and once claimed he never got bills from toll road plate readers because of it.

Peter A.August 23, 2019 9:12 AM

Evidently a problem with data input.

The form (paper or otherwise) for writing out the ticket should have a check box for the situation when the car has no plate on it and officers should be trained to use it. If there's no such check box and there's a common practice among officers to write 'none', 'no plate' or whatever else in the space provided for licence plate contents, and such tickets are later entered into the database, you have this problem of poisoning the data - and spilling that poison on a creative individual who chooses such vanity plate later.

Other countries do not have this problem, because the bureaucratic drones drafting the laws do not understand the idea of an unique identifier and do not even think of a possibility to allow people to choose one they like (as long as it's unique). They devise convoluted schemes of prefixes, suffixes or whatnot and assign them arbitrarily to administrative divisions, therefore needlessly limiting the identifier space and creating problems down the road, such as partial exhaustion of space and the need to make the scheme even more complicated and so on - not even mentioning the limitation of privacy, false assumptions of driver's residence based on plate number, prejudice against drivers having plates from particular area etc.

Ken WoodAugust 23, 2019 10:01 AM

I read in another source (can't recall to cite it) that the problem was in the database data. For tickets written by hand, some plate numbers were illegible and so the data-entry typist entered "NULL" as a string value. In other tickets, the video recognition failed (e.g., obscured view, dirt or damage to the plate) and the entered plate was "NULL" as a string value. So the solution, in part, is to clean up the data in the vendor database and define better procedures for entering data in difficult cases.

Impossibly StupidAugust 23, 2019 10:23 AM

@Sed Contra

One wouldn’t want to curtail this kind of creativity, but it’s odd the state systems approve plates they can not handle.

In this age of automation, it may not matter. If input is allowed simply by driving past a camera, anyone can print up a fake plate and it could end up in the system. It may even happen for bumper stickers that are sufficiently similar to license plates. There are all kinds of possible errors and exploits for these real-world systems that won't be uncovered until people start poking at them.

@Peter A.

The form (paper or otherwise) for writing out the ticket should have . . .

That also may not matter. Any complex system will have data translated and re-encoded into different representations as it moves around. What goes on to an initial paper form (or any other kind of data entry interface) will likely be different from how it is stored in the database, which will likely differ from printed reports. And any time you insert a human into the process, that's a whole separate set of ways that errors crop up.

I don't know that there's any ultimate solution to the problem, other than to have a process in place that allows for error detection and correction. Not so easy to do in a complex world when trying to get dumb machines to do the work, though.

GaryhAugust 23, 2019 12:18 PM

Ha ha! Reminds me of years ago where I worked .... there was an effort to convert an app from HPUX to SunOs. There were delays and a senior developer explained some of the problems were that HPUX was more forgiving of NULL pointer dereferences than was SunOs, as if dereferencing NULL pointers was an OK thing to do. :-)

MikeAAugust 23, 2019 12:47 PM

Heck, Lint expected more leniency on null pointer dereference, as I found out porting it to a system that mapped the first page not just "no write" but "no access". It had "worked before" because the first page of memory was set to zero, and not used, because otherwise some innocent data item might get assigned zero as an address. A linked list was being traversed, and a pointer in the linked struct was checked for NULL, but then the "p = p->next" was not checked for p now being NULL. The next check was whether p->some_pointer was null, which it would be if p was zero, which pointed at a zero.

I suspect this was an issue with PCC, but I discovered it feeding lint its own source.

AntistoneAugust 23, 2019 3:06 PM

If the government sends you a large number of invalid tickets, and you notify them of the error, and they agree it's an error, but then they continue to send you a large number of invalid tickets...that sounds like grounds for a harassment lawsuit?

AntistoneAugust 23, 2019 3:16 PM

@Sed Contra: "it’s odd the state systems approve plates they can not handle"

Presumably the person responsible for approving the plates was hitherto unaware of the fact that their system can't handle this one.

That could be because:

1) The programmers who created the system failed to realize that it does not correctly handle this case

2) The programmers realized, but failed to inform the state

3) The programmers informed some representative of the state, but the state failed to convey that bit of information to the specific person who needed it

4) The system as designed does not contain this weakness, but the government is using the system in a manner contrary to its design (probably without realizing that this introduces a flaw). For instance, maybe the programmer told the government to use a particular value to represent that a plate was unknown or not present, but the workers actually using the system made up a different (unsafe) value to use instead.

It is of course also possible that the license plate approval guy was specifically told not to approve the plate "NULL" but screwed up and approved it anyway, but that strikes me as less likely than any of the above.

VinnyGAugust 23, 2019 3:28 PM

@Garyh re: OS conversion - Ugh, you brought back a bad memory. I once worked as a systems analyst for a company that designed and built large data switches. That company also had four different in-house systems that had a high degree of functional redundancy (not the beneficial kind) and was at this time in the process of acquiring a competitor with a fifth system. My responsibility there was for an IBM MAPICS II application set running on midrange iron. The head honchos determined that after the acquisition was completed, an existing, home-brew app set running on an HP 3000 would replace MAPICS (not an issue for me; I had already prepared to bail out of that lunatic asylum.) The guy I was working "for" in converting the MAPICS data was a not terribly sharp glorified query script writer who considered himself a programmer (this was before developer role definitions became hopelessly blurred.) I had to educate this guy (several times) that there could be (and were) differences in the stored representation of nulls, blanks, and zeroes. I don't think he ever actually believed me, let alone understood the concepts. Seems as if some of his intellectual heirs must be working in IT for some of these state motor vehicle agencies or their contractors...

Anon Y. MouseAugust 23, 2019 4:42 PM

Ah, weedhopper... you have not mastered the zen of programming until
you can distinguish between zero, blank, null, unspecified, and undefined.

JonAugust 23, 2019 6:19 PM

The problem here really is in-band signalling.

If you expect a license plate number as a string, and get a string, then it is a valid plate (subject to [rules]). If people are using 'special' strings to indicate conditions, then you need to be very consistent about what those 'special' strings are, and forbid them during typical data entry. And license plate issuance.

This, incidentally, is what let Cap'n Crunch blow a whistle into a phone and make free long-distance calls. It's a very old problem.

As Peter A. pointed out, there should be a tickbox that is entirely separate from the string to indicate 'there is no valid string in this field'. "Null" has been used by computers to indicate that - yet still NULL as a string gets accepted?

It should. It's a valid string. Colours completely inside the lines as far as license plate rules go (at least around here). But it's also a 'special' string, an encoded command. It's like naming a variable 'goto' - most computer language compilers/interpreters would object to (something like) that.

So the blame lands, as it typically does, on poorly specified systems run by people with dramatically different priorities. Again, it's an old problem. But the contractors get paid for providing a lousy system, and the administrators who bought the system get promoted. Everybody* wins...

Jon

* Except the people who have to put up with it, but they're an "externality". J.

1&1~=UmmAugust 23, 2019 6:34 PM

@Anon Y. Mouse:

"you have not mastered the zen of programming until you can distinguish between zero"

What about the three different zero's?

TatütataAugust 23, 2019 6:49 PM

Other patterns to avoid ?

0
-1
99
999
9999
invalid
zzzzzz
NaN

etc.

I just used today "xxx" as a place holder for missing data in a file, before reading this thread.

David AustraliaAugust 23, 2019 9:05 PM

brings to mind a number of things

firstly, I had the impression at least in Australia 'positive' speed camera/toll/red light images were human verified

secondly, I know it's not really the point of the post, but these cameras produce false readings ALL the time. I don't even have the energy to list all the technical ways they produce false readings, for better or for worse ( mostly for worse) It's longer than my arm.
I've read some of the user manuals for the non automated ones. The margin of error for interference is basically 100%. This is actually explained in the manual.

In Australia, the National Testing authority (NATA) has actually not approved ANY of the cameras. So, demanding to see the certification of authentication is sufficient to have a matter dismissed.

They use MD5 - I could go on and on but I digress

I met a North American once who had changed their name by deed poll to 'et cetera'. Supposedly this meant they got lost in 'the' database, never learnt anything more specific.

Also, someone who changed their name to Xtian , one word, just because they liked it.
They discovered the side effect certain manual databases literally couldn't process them, for example at the welfare office.

Their first inital was an X which voided the first name box and they didn't have a second name

name.withheld.for.obvious.reasonsAugust 23, 2019 10:49 PM

I have rotated the front plate on my vehicle, the normal (parallel with the horizon) reading is for example 9MXV696, and rotated 180 degrees, resembles 6WXA969. It is so close in apparent equivalence that I assume the LPR system will reboot on attempting to resolve the number (wishful thinking here, put not out of the realm of possibility). On systems that collect plate numbers, without verification, can easily be defeated. Other systems that attempt to resolve against a database are more prone to mis-resolving or not resolving the number. Objective achieved.

Ironically state vehicle code does not specify the exact orientation of the plate--only that it is clearly readable. If asked, I simple rotate my head approximately 120 degrees and say "clearly legible to me!".

This issue reminds me of the disconnect between traditional laws of identification and enumeration (passports, ID cards, etc.) where the law never contemplated the wholesale collection of this information in multiple domains. For example, the fourth amendment to the U.S. constitution never foresaw the many-to-many or one-to-many mappings of mailing address labels on envelopes, it merely assumed the one-to-one mapping as it would have been near impossible to physically catalog the mailing addresses of all receipts and all senders. No useful ledger could have been written that could allow for the tracking of individuals except specifically identified individuals, groups or sets of mailers and recipients.

Without centralized mailrooms in the 18th, 19th, and 20th century the ability to map identifiers was completely limited. Today, by way of centralized databases, the disparate physical location problem is overcome. Same applies to the LPR based systems.

Gerard van VoorenAugust 24, 2019 5:28 AM

The real problem is of course that they probably used a too low level language for the job. That combined with the problem of custom plates. In The Netherlands the latter problem is being solved with only allowing gov assigned plates. But that problem is of course international which makes it a lot harder than it should.

DavidAugust 24, 2019 10:39 PM

I used to have a UK passport number with two leading zeroes.
I found that a lot of databases could not handle them

Alyer Babtu August 24, 2019 10:56 PM

I’m sure all these examples of malicious database behavior could be the start and core of the third Jonas Jonasson novel about The 100-Year-Old-Man.

JohnKAugust 25, 2019 10:56 AM

Reminds me of one of the lessons in a university programming course, around 1976. The professor's story went that someone had returned a store purchase and had a zero balance, but kept getting monthly statements demanding payment of $0.00. The store's customer service advised sending a check for $0.00. Shortly thereafter the bank contacted the consumer about crashing their computer.

It's sad and frustrating that there are so many instances of broken processes, including ineffective or missing quality and process improvement procedures, at many businesses.

Bill PaxtonAugust 25, 2019 4:33 PM

Entirely understandable.

I assume the system is some Oracle. If forced to work with PL/SQL, I would rather avoid doing anything that makes me test the various edge cases too thoroughly. Just COALESCE anything nullable to a character value.

Oh myAugust 26, 2019 4:07 AM

Pairing "NULL" sting with real NULL is a bad program design. Unless it's paired by human, which is even worse system design.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.