The technology sphere has been trying desperately for years to make the barcode a consumer necessity. Only problem it, nobody’s fully thought this through…
A notable attempt to put barcode technologies into the hands of consumers was the ill-fated CueCat, which assumed that people would find an advertisement so compelling that they would take their magazine or newspaper to their computer, initiate the dialing sequence of the modem, scan a barcode, and then watch as some type of advertising loaded over their 56K.
Eh, maybe not CueCat, a decade ahead of schedule.
More recently, every year is “the year”, when barcode scanners will be universal on mobile phones and everything will be tagged, marked, and hyperlinked to some overlay on the physical world.
Imagine it, Paris tourist destinations hyperlinked to their Wikipedia entries, street signs linked to traffic reports, and Christmas cards linked to your Facebook accounts. The technology exists to make pretty much any camera-phone do this without all the painful waiting of yesteryear, so let’s jump on it!
There’s only one problem folks, and it’s not about adoption or competing standards or any argument commonly put forth. The problem is the barcode itself.
Barcodes are designed to encapsulate information in the smallest amount of space possible, while still being usable. All barcodes work off some type of mapping of image (pixel) content through an algorithm, which then decodes it to relevant information. If you’re curious, here’s an awesome overview of the competing barcode standards, which I recommend you visit!
Barcodes are built to minimize the space they take up, and be machine readable. Let’s remember our history here: barcodes are designed to be machine readable, first and foremost. This is great, for machines.
What’s not so great is when a human tries to read a barcode. They are pretty much universally indecipherable and give no clue as to what content they contain. They could contain a link to http://pbskids.org, or http://somethingawful.com . You’d never know by looking at it.
So why not just print the URL next to the barcode? That would work in theory, except that you’d have no proof that the printed barcode and printed URL had anything to do with each other. You could still have a clean printed URL and a naughty destination.
As we are increasingly absorbing information from the ambient environment, we are beginning to place a pretty high level of “trust” in what’s there.
With no way to know where a barcode would be “headed” or what type of content your reading device would be receiving, you could do a pretty good job of culture jamming, spoofing, phishing, or otherwise generally raising mayhem by simply using a sticker to cover the intended barcode. Clever hackers could potentially “fill in” existing barcodes with a sharpie, then buy the new nonsense URL, and carry on their merry way. How is the unsuspecting Paris tourist to know that QRCode on the Eiffel Tower shouldn’t lead to an ad for a Paris strip-club?
Because there’s no human-readable aspect of the barcode, they can’t really be trusted.
In order to remedy the problem, a human-readable text would need to be included in the barcode. This text could be quickly verified by the human, then incorporated as part of the validation code within the machine logic. If the printed URL doesn’t match the destination, don’t decrypt. Then the problem becomes that you’ve made a barcode… not really a barcode.
Are you going to eat the apple, even if you don’t know what it does?

![1831911363_1550a62500_o[1] 1831911363_1550a62500_o[1]](http://rolfskyberg.files.wordpress.com/2010/01/1831911363_1550a62500_o1.png?w=140&h=140)











