Barcode capture without camera permission

[reillyeon]

Discussing adoption of this API with developers a challenge they face is that to capture a barcode in the real world you need to build a barcode scanner interface around this API which includes activating the user's camera and displaying a live camera feed. Since this must be implemented by the site itself camera permission is required, since the site could do anything it wants with the captured video.

For sites that want the user to take and upload a photo the <input type="file" accept="image/*" /> tag provides an option which doesn't require permission by putting the user in control over what is captured. Without proposing a specific API shape, a similar capability for a site to request that the browser present the user with a barcode scanning interface and return the decoded barcode to the site would be,

1. much easier to adopt because it requires less code,
2. lower-friction because the site doesn't need to ask the user to grant camera permission,
3. more privacy-preserving because the user does not need to share a live camera feed with the site.

To mitigate an attack where a site pops up the barcode scanner in an environment where it expects a barcode to be in front of the camera so it can be captured without further user interaction, browsers may have to implement some kind of friction to require the user to acknowledge that they want to scan a barcode. This is similar to the challenge faced by WebNFC, which needs to be sure that the user is aware that if they touch their device to an NFC tag the site will be able to read its content.

[tabatkins]

While the flow for obtaining the information currently involves getting an image from the user's machine and handing it to the page, I don't think this "barcode without camera permission" would want to do that, right? It just wants to trigger the browser+device's scanning functionality, and then hand the page the data from the barcode as an Array or ArrayBuffer.

So I think <input type=file> isn't the right UI for this. It seems like you instead would want something more like <input type=color> which triggers specialized UI but ultimately just gives the page a string. (And a JS ability to trigger the same, of course.)

[reillyeon]

Right, it would give the page the decoded value of the barcode, not the photo. If we tried to fit this into the <input> tag then type=file might be necessary since a barcode can contain arbitrary bytes and that might be the easiest way to represent that since you could represent the contents of the code as a "file" (really just a blob). type=text would be easier to work with but not cover that scenario cleanly.