Our OCR endpoint signs a receipt, because the confidence the client sends us proves nothing

When a barcode is not found in the Munchable catalog, the app directs the user to the ingredients panel instead. The photo is sent to an OCR endpoint, the text is returned, and the row is saved. Contributors are compensated for their work with a subscription discount. The server only receives strings, including the ingredient text, a source field, and the read confidence.

An attack can be executed by posting plausible text twice from two accounts, reaching consensus without a photo, and collecting the discount. To prevent this, the receipt includes an HMAC over the account, a hash of the extracted text, the confidence of the read, and an expiry. This receipt is then verified, and if it is not verified, a 422 error is returned and no data is written.

The receipt binds three separate things: the account that performed the read, the exact text from the model, and the model's confidence. Version one of the receipt had issues, as it combined three strings with a separator, proving the strings' existence but not their respective fields. This could lead to incorrect verification, especially in an app managing allergies.

The fix is to hash named, length-prefixed fields, ensuring the digest commits to a field, not a position in a list. The confidence floor was incorrectly placed in the wrong function, causing low-confidence reads to be rejected when paying for contributions, even though they were genuine. Now, the verifier only returns the confidence and does not judge, allowing genuine low-confidence reads to save the row and not earn anything.

The receipt's format must be canonicalized with field names and lengths, or signed a format that is already unambiguous, before any production signature.