I recently became aware of a lobby to replace the textual food labels with QR codes. The food labels contain information about its ingredients, calories, vitamins and allergens, for example. Because food must be labelled in the language of the country in which it is sold, labelled food cannot easily be re-exported. In Europe this has led to artificial price differences on foods sold in neighbouring countries. Replacing textual food labels with a QR code that, when scanned, points to a website with the food label in your language of choice would break that barrier.
Consumer organisations are rightfully concerned about the accessibility of the information through a QR code for less tech-savvy consumers, or people that do not own sufficiently modern smartphones to scan the codes to access the information. On the other hand, people on specific diets or with allergies would be helped tremendously with an app that automatically warns them for any food that does not fit their diets or contains dangerous allergens.
The most straightforward implementation would indeed be one where the QR code contains a URL to a secure website (i.e. an https link) that contains the required information in many different languages. The scanner app would then display the information page in your language of choice. From a technical perspective, there is the immediate concern that the website pointed to by the QR code might be offline. Making it unavailable on purpose could be an interesting attack vector for malevolent entities. Especially if the sale of food is made conditional on accessibility of the required information. (After all, food labels are legal requirement for a reason.)
This implies that a more redundant implementation is in order, where the QR code does not contain a fixed URL, but rather a food information identifier (FII) that when scanned is used to look up the information in an online database that can be implemented in a redundant fashion over several servers. Larger supermarkets could even host a copy accessible over their local wireless network.
In this case, additional countermeasures are required to guarantee the authenticity of the information obtained be looking up the FII. One straightforward method would be to force food producers to commit to the food information and store the commitment in the QR code as well. Let h be a cryptographic hash function. Suppose the information is available in several languages, I1, …, In. Compute the hash over each description in each language, and compute the final commitment C as h(h(I1), …, h(In)). Let the QR code contain the FII as well as C.
When retrieving the food information after scanning the QR code, the scanning app obtains all hashes h(Ij) as well as the actual information Ij in the language of choice. It verifies Ij with its hash. And verifies that hashing all h(h(I1), …, h(In)) indeed returns the hash found in the QR code.
Added 2025-02-15: And as Emile van Bergen rightfully observed on LinkedIn, adding a URL to the QR code creates significant privacy issues as that would allow the producers to track the shopping behaviours of their customers. He argues that the contents of the full label could be added in compressed form to the QR code, perhaps using an extension to the E-code standard for food supplements, that could be translated to the language of choice in the app itself. Added 2025-02-17: Given that QR codes can actually contain a significant number of bytes (depending on their size, which may affect scan-ability on smaller food packets), this might actually work as well. Coding individual ingredients in 2 bytes (65536 options) and quantity in 1 (as a percentage), means you can list 50 ingredients in a 150 byte QR code. Like this (with medium error correction):
Added 2025-02-16: This privacy risk can be mitigated if the app to read the QR code does not send any personal identifier with the request to obtain the data associated with food information identifier (FII) in the URL. Perhaps the app should be certified to guarantee this. We assume the server hosting the food identifier database serves the requested information directly, i.e. no redirect to the actual food producer takes place. The analysis then only depends on how you are connected to the internet and how you obtained your IP address.
If you use the local WiFi of the store, and this WiFi network can be accessed without logging in, this yields no personal data to the store or the server hosting the food identifier database (we assume an https connection of course):
- The store only sees encrypted data, your IP address, your MAC address and the (fixed, product independent) FII server IP address. At best the store can determine how many QR codes you scanned. Assuming your MAC address is randomised (which it normally is these days), and by assumption the IP address is not linked to your identity, the store cannot track you across visits.
- The FII server sees your IP address, which is randomly assigned by the store. This does allow it to collect per store shopping statistics, and perhaps even compare how many times an item was scanned versus how many times it was actually sold. (Although that might not be as easy as it sounds as most people will actually check the food label to begin with.)
You could also be connected to the Internet through your cellular network. In that case:
- Your mobile network provider sees encrypted data, your IP address and the FII server IP address. Your mobile ISP knows your identity and can use this collect some information about your shopping habits, namely when you shop, and how many items you scanned an item each time you shop.
- The FII server sees your mobile IP address. Assuming this IP address changes regularly, this will not allow the FII server to track your long term shopping habits, but will allow it to learn all items you scanned each time you shop. This is the more tricky case, it seems.