Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Barcode Detection API

developer.mozilla.org

Post reply on HN
Print view View original

61–70 of 141 posts

Re: Barcode Detection API

#61

Post by Jcampuzano2 »

eertami wrote: post #22
PaulHoule wrote: post #9

Earlier quoted context omitted.

At this point in time it's a pain point for me that Android devices don't usually have built-in QR reader software. I can tell iOS users to just "scan the code with the Camera" app but I have to tell Android users to find a QR scanner app on the app store. My experience with an actual bottom-of-the-line prepaid phone was that the first QR scanner app I downloaded from Google Play worked right the first time but I had…

Honest question: for what reasons do you ever need to scan a random QR code? I think I've used them to sign in to some apps (eg, WhatsApp) while logged in on a PC, and other than that exactly 0 times. The Google camera app does support QR codes FWIW, but I don't know if any other vendors except Google use it.

You wouldn't be able to see a single menu nearly anywhere here in Mexico City without one.

Basically everywhere uses a QR code for something of importance

Re: Barcode Detection API

#62

Post by easrng »

PaulHoule wrote: post #9
miohtama wrote: post #2

As the page does not discuss the motivation behind the API, does anyone know why this is ”native” API and not just a generic image processing script implemented with JavaScript / WebGL / etc.?

At this point in time it's a pain point for me that Android devices don't usually have built-in QR reader software. I can tell iOS users to just "scan the code with the Camera" app but I have to tell Android users to find a QR scanner app on the app store. My experience with an actual bottom-of-the-line prepaid phone was that the first QR scanner app I downloaded from Google Play worked right the first time but I had…

My Motorola phone from 2017 has QR support in the Camera app.

Re: Barcode Detection API

#63

Post by judge2020 »

wyager wrote: post #48
dblohm7 wrote: post #42

Earlier quoted context omitted.

Basically, yes. Browser vendors have had an agreement for some time now to only expose new APIs in secure contexts in order to encourage HTTPS adoption.

I'm not sure I feel great about gating feature A behind completely unrelated feature B just because manufacturers like feature B. Even if feature B is concretely pretty good (which is debatable for https as it exists now), this seems bad on principle.

If it helps, it really doesn’t care what certificate the page it signed with, whether that be localhost, Mozilla CA participants, or maybe even a future CA fork for Russia if that happens. Plaintext HTTP is just not advisable even on a private network when some inline network device like LAN turtle could be passively exfiltrating traffic.

Re: Barcode Detection API

#64

Post by Nextgrid »

jorl17 wrote: post #58
wyager wrote: post #48

Earlier quoted context omitted.

I'm not sure I feel great about gating feature A behind completely unrelated feature B just because manufacturers like feature B. Even if feature B is concretely pretty good (which is debatable for https as it exists now), this seems bad on principle.

I'm interested: why do you think it is debatable if HTTPS is "concretely pretty good" as it exists now?

It's not always necessary. Think fully offline networks that can't/won't use a CA anyway, or networks where physical/machine access is the intended layer of security (a web server running on localhost).

In these scenarios a self-signed certificate will rarely improve security because most users will click through the warning anyway in case of an MITM attack.

Re: Barcode Detection API

#66

Post by schappim »

disillusioned wrote: post #56
bob1029 wrote: post #23

This stuff has been a nightmare for us for a long time. We have to scan pdf417 barcodes from physical identification as part of our offering. Recently, we stumbled upon some cheap USB keyboard emulator 2d scanners that can pick these up very reliably. For our product/customers, this is a viable path. We have tested probably 30 different webcams by this point. The only 2 that are as reliable as the handheld CCD scanne…

We ended up going with the purpose-built barcode sleds from Infinite Peripherals. The Linea Pro, I think. Extra battery, onboard illumination/laser guide, _really_ fast barcode engine in any orientation, and a few pretty simple SDK options. We ended up using "our custom webkit browser will fire a custom JS event on scan", which worked perfectly for our purposes. Everything else is measurably slower: waiting for focus…

We use the Linea Pro too w/ the SwipeTrack browser making them available in our web app. We've previously used both the Infinite Peripherals SDK w/ an iOS app, but SwipeTrack have a pretty good JS API [1].

Funnily enough, the Linea Pros have been going down hill. They swapped out the barcode engine and it is not fast / crisp. Sometimes faster to just use the iOS Camera (w/ Swipetrack) instead of the Linear Pro's sled.

[1] https://files.littlebird.com.au/SwipeTrackBrowserAPI_200-Yre...

Re: Barcode Detection API

#67

Post by chiph »

gruez wrote: post #40

>Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. What's the point of this? I understand why you might want this for APIs that expose private user information, but this just performs some computation. You could do the same thing with a js library or webassembly. Is this just to punish http sites?

pdf417 barcodes are commonly used on US driver's licenses, and contain private information like the person's address, height, eye color, full name, etc. For the API to do its work in detecting a valid barcode, it needs to be able to read the entire barcode to compute a checksum/checkdigit. Which means it has to read the data.

Re: Barcode Detection API

#68

Post by schappim »

jaxn wrote: post #54
bob1029 wrote: post #23

This stuff has been a nightmare for us for a long time. We have to scan pdf417 barcodes from physical identification as part of our offering. Recently, we stumbled upon some cheap USB keyboard emulator 2d scanners that can pick these up very reliably. For our product/customers, this is a viable path. We have tested probably 30 different webcams by this point. The only 2 that are as reliable as the handheld CCD scanne…

We also scan pdf417 from ID cards. In our case, it was much easier to just use hardware 2d scanners. We are a b2b SaaS and they are scanning IDs all day, so a hardware solution makes sense. The weird thing about pdf417 is that there is a lot of helpful info our there, up until a point. It's like everyone is collaborative and asking/answering questions up until the point they really figure it out, but those last few s…

What device are you using to scan? If you can use Android, Chrome supports pdf417.

Re: Barcode Detection API

#69

Post by imajoredinecon »

gruez wrote: post #40

>Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. What's the point of this? I understand why you might want this for APIs that expose private user information, but this just performs some computation. You could do the same thing with a js library or webassembly. Is this just to punish http sites?

There might be more to the privacy characteristics of an API like this than meets the eye. For instance, if a user grants camera permissions scoped to http://insecure.website in order to scan a QR code and get it detected, it might be surprising to the user that on-path attackers would be able to see the user’s camera snaps. Making the API work in a degraded mode in insecure contexts (e.g. by disabling particularly privacy-sensitive data sources) might be a plausible alternative, but at this point it’s arguably cleaner and less risky to just make the interface HTTPS-only in order to avoid making developers and users reason through these nuances.

Re: Barcode Detection API

#70

Post by makeitdouble »

dblohm7 wrote: post #42
gruez wrote: post #40

>Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. What's the point of this? I understand why you might want this for APIs that expose private user information, but this just performs some computation. You could do the same thing with a js library or webassembly. Is this just to punish http sites?

Basically, yes. Browser vendors have had an agreement for some time now to only expose new APIs in secure contexts in order to encourage HTTPS adoption.

I am in agreement with wyager, this feature looks like it could be heavily beneficial to a shipping company's internal web app for instance, or other applications that could be running completely isolated from the global network (or running on the machine itself for that matter).

Forcing https in these applications is a waste of time and money for orthogonal purposes. I guess it could be seen as a cost of dev. for any web based application from now on, but it's sad to me to see the barrier to entry get higher for these reasons.

Post reply on HN