As I understand it, The key bits of data are in the QR code, they are just encoded as a URL - a highly structured URL that point of sale systems can decode without visiting the URL.
Doing it this way means the QR code is directly usable by consumers to get to a product info / marketing page, and directly usable by the POS systems.
This is correct. The canonical reference is: <a href="https://ref.gs1.org/standards/digital-link/uri-syntax/" rel="nofollow">https://ref.gs1.org/standards/digital-link/uri-syntax/
I am irrationally annoyed that this isn't <a href="https://ref.gs1.org/17/382834828282/21/28312384021" rel="nofollow">https://ref.gs1.org/17/382834828282/21/28312384021
Because the consumer has to be able to trivially scan it with their smartphone and get useful information out of it. In reality, that means it has to be a valid URL you can visit with a web browser, as forcing literally everyone to install a proprietary URN-handling app is a dealbreaker.
The whole point of it is that you can just say "scan the barcode with your smartphone to find out if your product is part of this recall".
URN that can be copied and put in any national recall website seems better to me. I don't understand who I am supposed to trust to keep domains with the right content on them instead of porn sites. Seems very high faith for clown town.
We have the technology to encode a short, plain human-readable description of an item into a 2D barcode, with born-on and/or sell-by dates, and/or things like serialization and/or lot codes, or other useful things.
Brevity is important; fields can have a standardized-but-flexible format that fits the particular item's needs.
A single-quantity small Fuji apple, picked today (October 3, 2026), with a PLU of 4129, and a magic-number lot code of b29sF, distributed by Stemilt Growers might present as such:
Apple Fuji Sm,B0261003,P4129,Lb29sF,MStemilt
A single 1.5 liter bottle of Crystal Geyser spring water with a UPC of 07514000500, a best-by date of January 12 of 2028, and a lot code of kek67:
Water Spring 1.5l,D0280112,U07514000500,Lkek67,MCG
We can even add more real information and still have less data to encode than:
...but, I mean: A coded URL for a website that might be designed to avoid being forthcoming with information isn't necessarily any better for consumers, long-term, than the UPC we've had for over 50 years. It's still just a pointer that relates to someone else's database. It has no informational value on its own.
Absolutely - I 100% expect the links to lead to feel-good marketing fluff at best and end up being useless for consumers, but the stated goals are at least good.
It's just that, sadly, we can no longer have nice things.
If items have unique (ie serialized) codes, then it's safe to assume that those codes will be recorded at purchase (since that's kind of the whole point), along with who bought them (yay discount cards and cashless society).
Now the contents of my pantry describe things like where I've been, when I was there, and/or who I hang out with. Fun times!
Even with cash and without discount cards: One random food label out of a recycling bin can relate all the way to photos of the purchaser's face at checkout, track them walking to their car, and see where that car went. This could happen months or years down the road.
Most of those pieces are already in-place: Our photos are already recorded alongside of our transaction details -- that's been going on in POS world for a long time. Tracking people to their vehicle is a function of Avigilon camera systems. Tracking the car itself is the primary purpose of Flock.
All that's missing right now is serialization records and a centralized database.
I'm sure that nobody will ever finish fitting these things together into a cohesive system and that nobody would ever use it with ill intent.
It probably would never happen anyway, since there's not a single retailer on Earth who would ever exchange this kind of data for an upgrade to their in-store surveillance systems and a monthly check. ;)
(And we still don't get directly-useful consumer information into or out of these new 2D barcodes. I love losing.)
This is already the case. Virtually every single food product comes with an expiration date label - which includes some kind tracking. You pretty much need to have that to do any kind of sensible recall when there's yet another poop lettuce outbreak. Looking at my pantry it usually seems to be include kind of lot number, time of production, and/or production line identifier.
I reckon they already have a pretty reasonable idea of which store it ends up going to, and with just-in-time resupply a pretty reasonable bound of when it will end up having been sold. Look at the overlap of a few dozen products and it should be quite easy to reduce the number of people who could've bought all of them to just you.
The QR codes just make this more explicit, and slightly easier to track. You're not wrong, but at least this time we could get, say, automated warnings in the Walmart app of a recall on something you bought out of it.
Today, with UPCs: We can reckon about whether or not the stuff we buy could be pinned down to a given store, or a transaction. There's lot codes and sell-by dates and stuff on the stuff in my pantry, too. But none of that was recorded when I purchased it.
So it's still a deductive process at best to correlate a lot number and a consumer. If all we have to go on is the implication of a limited range of lot codes, then the results are fuzzy.
Tomorrow, with unique serialization: The right person will absolutely be able to pin down exactly which store a particular can of beans was bought at, and when, and by whom. It's not just something that is made "slightly easier" -- it is instead a fundamental built-in capability of the concept. There's nothing to deduce or to guess at when this unique data is collected and correlated both deliberately, and automatically.
(RFID product tags, commonly known as EPCs, are also usually unique. This property reduces error from duplicate reads. When each tag is unique, it disambiguates a checkout involving 3 packs of #2 pencils from a checkout with just 1 pack of #2 pencils that was read 3 different times.
To pick one standard: SGTIN-96 is often used for EPCs on individual items and includes 38 bits for a serial number. That's enough bits for ~274 billion unique numbers. So with a haystack of 274 billion packages of #2 pencils sold and scattered around the world, the one in my desk drawer is very easy to identify.)
The advantage of using a hyperlink is that consumers do not need an application-specific decoder, they can use their standard reader. And manufacturers can provide additional data (in theory: user manuals, but in practice most likely 404s, tracking and ads).
As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.
As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.
Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.
There's ways to shrink the bit cost down, for sure. The commas in my example are particularly expensive, for instance, since commas aren't part of QR's alphanumeric set.
It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.
As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.
> We can even add more real information and still have less data to encode
The reason they're so verbose comes from a few facts.
First of all, it's an existing logistics labelling standard, they've just replaced brackets with forward slashes and put a domain name on the front. So <a href="https://example.com/01/09521207311511/21/1234ABDE1235" rel="nofollow">https://example.com/01/09521207311511/21/1234ABDE1235 is just a QR code version of those huge barcodes like (01)09521207311511(21)1234ABDE1235 you see on cases of products in the supermarket.
Second of all, the standard doesn't limit itself to a single date, so they can't identify dates with a simple ,D prefix. It's a kitchen sink standard [1] with 16 different types of date (production date, due date, packaging date, sell by date, best before date, expiration date, release date, first freeze date, harvest date, production date and time...) and just as many options for sizes and weights - so the identifier can be up to 4 digits. /11/ or /8008/
The third thing to know is QR codes pack different alphabets at different densities. Numbers at 3.5 bits per character, upper case letters and some symbols at 5.5 bits per character, ASCII at 8 bits per character. So the 13 characters of of "Apple Fuji Sm" uses about as much space in a QR code as a 29-digit number like "12345678901234567890123456789"
Fourth, you've replaced the 14-digit GTIN with an 11-digit UPC and replace the 13-digit serial number with a 5-digit lot code :)
IMHO the standard isn't going to take over the world, and anyone who says "Barcodes are about to go extinct" doesn't know what they're talking about. But it's not the information density, it's other reasons.
byte-sized-snac · · focus · HN ↗
Surely the actual data will be stored in the QR code and available offline
[deleted] · · focus · HN ↗
[deleted]
kiallmacinnes · · focus · HN ↗
Doing it this way means the QR code is directly usable by consumers to get to a product info / marketing page, and directly usable by the POS systems.
Edit: I looked it up. An example URL:
<a href="https://example.com/01/09521207311511/21/1234ABDE1235" rel="nofollow">https://example.com/01/09521207311511/21/1234ABDE1235
01 is a marker before the traditional barcode.
21 is a marker before the serial number.
There seems to be many other codes like 17 (expiry date) and 10 (batch number).
alex_suzuki · · focus · HN ↗
adastra22 · · focus · HN ↗
fragmede · · focus · HN ↗
williamtell · · focus · HN ↗
crote · · focus · HN ↗
The whole point of it is that you can just say "scan the barcode with your smartphone to find out if your product is part of this recall".
williamtell · · focus · HN ↗
ssl-3 · · focus · HN ↗
We have the technology to encode a short, plain human-readable description of an item into a 2D barcode, with born-on and/or sell-by dates, and/or things like serialization and/or lot codes, or other useful things.
Brevity is important; fields can have a standardized-but-flexible format that fits the particular item's needs.
A single-quantity small Fuji apple, picked today (October 3, 2026), with a PLU of 4129, and a magic-number lot code of b29sF, distributed by Stemilt Growers might present as such:
A single 1.5 liter bottle of Crystal Geyser spring water with a UPC of 07514000500, a best-by date of January 12 of 2028, and a lot code of kek67: We can even add more real information and still have less data to encode than: ...but, I mean: A coded URL for a website that might be designed to avoid being forthcoming with information isn't necessarily any better for consumers, long-term, than the UPC we've had for over 50 years. It's still just a pointer that relates to someone else's database. It has no informational value on its own.kiallmacinnes · · focus · HN ↗
It's just that, sadly, we can no longer have nice things.
ssl-3 · · focus · HN ↗
If items have unique (ie serialized) codes, then it's safe to assume that those codes will be recorded at purchase (since that's kind of the whole point), along with who bought them (yay discount cards and cashless society).
Now the contents of my pantry describe things like where I've been, when I was there, and/or who I hang out with. Fun times!
Even with cash and without discount cards: One random food label out of a recycling bin can relate all the way to photos of the purchaser's face at checkout, track them walking to their car, and see where that car went. This could happen months or years down the road.
Most of those pieces are already in-place: Our photos are already recorded alongside of our transaction details -- that's been going on in POS world for a long time. Tracking people to their vehicle is a function of Avigilon camera systems. Tracking the car itself is the primary purpose of Flock.
All that's missing right now is serialization records and a centralized database.
I'm sure that nobody will ever finish fitting these things together into a cohesive system and that nobody would ever use it with ill intent.
It probably would never happen anyway, since there's not a single retailer on Earth who would ever exchange this kind of data for an upgrade to their in-store surveillance systems and a monthly check. ;)
(And we still don't get directly-useful consumer information into or out of these new 2D barcodes. I love losing.)
crote · · focus · HN ↗
I reckon they already have a pretty reasonable idea of which store it ends up going to, and with just-in-time resupply a pretty reasonable bound of when it will end up having been sold. Look at the overlap of a few dozen products and it should be quite easy to reduce the number of people who could've bought all of them to just you.
The QR codes just make this more explicit, and slightly easier to track. You're not wrong, but at least this time we could get, say, automated warnings in the Walmart app of a recall on something you bought out of it.
ssl-3 · · focus · HN ↗
So it's still a deductive process at best to correlate a lot number and a consumer. If all we have to go on is the implication of a limited range of lot codes, then the results are fuzzy.
Tomorrow, with unique serialization: The right person will absolutely be able to pin down exactly which store a particular can of beans was bought at, and when, and by whom. It's not just something that is made "slightly easier" -- it is instead a fundamental built-in capability of the concept. There's nothing to deduce or to guess at when this unique data is collected and correlated both deliberately, and automatically.
(RFID product tags, commonly known as EPCs, are also usually unique. This property reduces error from duplicate reads. When each tag is unique, it disambiguates a checkout involving 3 packs of #2 pencils from a checkout with just 1 pack of #2 pencils that was read 3 different times.
To pick one standard: SGTIN-96 is often used for EPCs on individual items and includes 38 bits for a serial number. That's enough bits for ~274 billion unique numbers. So with a haystack of 274 billion packages of #2 pencils sold and scattered around the world, the one in my desk drawer is very easy to identify.)
cxr · · focus · HN ↗
petra · · focus · HN ↗
atvcatole · · focus · HN ↗
MayeulC · · focus · HN ↗
As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.
As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.
Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.
ssl-3 · · focus · HN ↗
It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.
As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.
[deleted] · · focus · HN ↗
[deleted]
michaelt · · focus · HN ↗
The reason they're so verbose comes from a few facts.
First of all, it's an existing logistics labelling standard, they've just replaced brackets with forward slashes and put a domain name on the front. So <a href="https://example.com/01/09521207311511/21/1234ABDE1235" rel="nofollow">https://example.com/01/09521207311511/21/1234ABDE1235 is just a QR code version of those huge barcodes like (01)09521207311511(21)1234ABDE1235 you see on cases of products in the supermarket.
Second of all, the standard doesn't limit itself to a single date, so they can't identify dates with a simple ,D prefix. It's a kitchen sink standard [1] with 16 different types of date (production date, due date, packaging date, sell by date, best before date, expiration date, release date, first freeze date, harvest date, production date and time...) and just as many options for sizes and weights - so the identifier can be up to 4 digits. /11/ or /8008/
The third thing to know is QR codes pack different alphabets at different densities. Numbers at 3.5 bits per character, upper case letters and some symbols at 5.5 bits per character, ASCII at 8 bits per character. So the 13 characters of of "Apple Fuji Sm" uses about as much space in a QR code as a 29-digit number like "12345678901234567890123456789"
Fourth, you've replaced the 14-digit GTIN with an 11-digit UPC and replace the 13-digit serial number with a 5-digit lot code :)
IMHO the standard isn't going to take over the world, and anyone who says "Barcodes are about to go extinct" doesn't know what they're talking about. But it's not the information density, it's other reasons.
[1] <a href="https://ref.gs1.org/ai/" rel="nofollow">https://ref.gs1.org/ai/