An ID Number for Everything 391
jon323456 writes "Put this in your privacy pipe and smoke it. According to news.com, MIT researchers have cooked up a new barcode that has enough dataspace to include a unique serial number for everything. And in combination with RFID tags...."
Gillette (Score:4, Interesting)
Re:Wow this is pretty dumb.. slow news day? (Score:2, Interesting)
I was thinking "Passcode"... Dude it's a key why not use it as the ultimate key. Hack hack got nothing on me.
Now with 512k you'd have not just enough room to ID everything but enough room to breath.
Made it tight enough and someone will enter random codes just to get results.
And then there is the mistakes.. accadentally using the wrong code. It would be better if a defective ID tag gave an error than a false result.
UPC is redundant...IPv6 is here (Score:5, Interesting)
Little tiny chips on produce, too? (Score:1, Interesting)
Re:Barcode? (Score:2, Interesting)
Database (Score:2, Interesting)
Hey, Microsoft, maybe you'd like a shot at this one? Then everyone would be happy knowing that there data may not be secure, but when it crashes (not if), we all get to start over.
It'll never happen... (Score:3, Interesting)
Make a tag for each one.
Let's say for the sake of argument that the tags weigh 0.01 grams.
Now make all 2^96 of them. You have just created 792,281,625,142,643,375,935,439.50336 kg of tags.
That's a shitload of tags! For reference, Planet Earth has a mass of 5.972e24kg. Your tags would weigh 1/132 as much as the entire planet.
That's less than 1%, but that's still a MAJOR volume of tags. We'd be choking on them. They'd be everywhere.
At 1,000,000 tags per second, how long would it take to manufacture 2^96 tags? 7,922,162,514,264,337,593,543 seconds. That's 2,512,308,552,583,217 years.
Something I hadn't thought of... (Score:4, Interesting)
"Under EPC, every can of Coke would have a one-of-a-kind identifier."
It occured to me that it's quite possible that such unique id's on consumable items could later get tracked back to their purchasers, then automatically impose a littering fine on them if said Coke can is found empty and discarded on the ground somewhere.
I don't really see that as becoming a reality, but it's possible.
Re:And we wants this why? (Score:2, Interesting)
Admittedly you could have more bars to compensate.
Re:And we wants this why? (Score:2, Interesting)
This is true, but eventually, in maybe 10 or 20 years, the 14 digit codes will also run out. The people at MIT understand the costs of upgrades, so they figure why not do it only once.
Second, they ramble on about "labeling every can of coke" but they never mention how much it'd cost to label a 10c can of coke.Yes they do. They mentioned that MIT is working on reducing the cost per EPC/RFID pair from nickels and dimes to fractions of a penny, since consumers would rather not tolerate an across-the-board price increase.
Re:Applications in lost good recovery (Score:2, Interesting)
As many reading this, I imagine, can speak to, it hasn't done a great deal of good in recovering their cars.
-H
Tracing trash (Score:3, Interesting)
I'm sure we'll see a market for microchip destroying devices of some sort for home use if RFID's ever take off in significant numbers.
Uniqueness is not enough.... (Score:3, Interesting)
Re:Something I hadn't thought of... (Score:3, Interesting)
All it would take is a little wind to blow it out of the over-full trashcan it was carefully placed in, or a homeless man to accidentally drop the can on the way to the recycling center.
Re:96 bits??? (Score:5, Interesting)
Sure, for a while. Back in the 70's, I'm sure they figured that 12-bit barcodes were plenty. According to the article, they're now starting to run out.
It's called thinking ahead: Design a system that will last at least twice as long as you think you'll need. Yeah, 64 bits is incredibly huge. They're talking about serializing every product made by every company with a unique id. So say we plan on it lasting 100 years. That's still like 184,400,000,000,000,000 unique id numbers, per year (64bit). Actually, that does seem pretty damn excessive.
But who knows - maybe there will be other uses for this space as well. Using a few bits to encode sizing/weight information, color, hazards, if it's flamable, disposal instructions, etc, to allow simpler devices to read it without having to link to a database somewhere. A good example of this is the licence scanners some bars use: they swipe your drivers licence, and it shows the info encoded on the card, and they compare it against the info printed on the card. It doesn't link back to a database to verify anything, its just a simple device to help prevent fake id's. Same sort of thing could apply here for shipping purposes, and probably lots of other things, too.
It's a lot easier to just use 96 bits now, than switching to 64 now, and then having to switch to 96 again in a few (or many) years.
A few things I don't understand (Score:3, Interesting)
1. Why the article's title on CNET mentions "futuristic barcode" when the project is apparently in relation to low capacity (96bit) RFIDs or the like.
2. Why it took 5 years to develop. RFID technology is readily understood. Databases are readily understood, wireless communication is readily understood. Prototyping hardware and writing some connectivity software should not have taken 5 years for such a "group". I'm either dissapointed or confused.
3. Why give each tag a only specific serial number that MUST be looked up in the database to ID it. The current barcode mass-grouping is still valid even with more bits. A stripped down database could then be used for off-line reading and you would still know the manufacturer and possibly the product family. For example barcodes starting with "636920" are from O'Reilly; all barcodes starting with "05000" are from Nestle. Isn't that much easier than having NO idea what "aj380dk358fh3k8i" is?
4. Why access a database directly? Why not use the Internet and stanard DNS and HTML/XML? Purchase a domain and make simple IRLs that include the tag info: http://www.taginfo.org/044254 ? The server would see the code, and send back a response containing one of two things: 1: the product information in XML (including a link to more info from the manufacturer), 2: an error. Such a thin HTTP/HTML client could be written quite quickly and be embedded in almost anything. There are already many synconization and caching sytems in place for HTML.