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

91–100 of 141 posts

Re: Barcode Detection API

#91

Post by unqueued »

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…

I found the most reliable barcode scanner to be an old Symbol usb scanner.

I also found that I could scan barcodes off of a screen with a laser scanner if I put a translucent white plastic bag over the screen. Maybe someone with more knowledge about optics could give some insight into why that trick works. My understanding is that laser scanners should only be able to scan by reflection, and shouldn't work off of a screen at all.

Re: Barcode Detection API

#92

Post by unqueued »

Nextgrid wrote: post #64
jorl17 wrote: post #58

Earlier quoted context omitted.

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.

Users should not have to rely on the network being isolated for security.

Even when I have an offline network, I still use SSH whenever possible.

Yes, I don't benefit from initial verification, but I pin the certificate from then on.

I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense.

I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way.

It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode.

Even the worst failure mode is no worse than a plaintext connection.

Re: Barcode Detection API

#93

Post by sevenf0ur »

marcjuul wrote: post #72

Does anyone happen to know where in the Chromium code base the implementation is hiding? The android version seems to use a library that's part of Google Play Services: /** * Implementation of mojo BarcodeDetection, using Google Play Services vision package. */ and // The vision library will be downloaded the first time the API is used // on the device; this happens "fast", but it might have not completed, // bail in…

Yeah, I haven't been able to find any decent open source DataMatrix libraries as well. If you find one I'd love to know.

This feature uses native libraries and only works on Chrome OS, Android, and MacOS currently according to this page:

https://chromestatus.com/feature/4757990523535360

Re: Barcode Detection API

#95

Post by WesleyJohnson »

egfx wrote: post #34
jacob019 wrote: post #15

I recently made a webapp for scanning barcodes using the phone camera for warehouse use. I used QuaggaJS. I disabled the barcode locator because it was too heavy, instead I just draw a box on the screen that the barcode is to be positioned in. The barcode detection and decoding happens entirely in the browser and it works very well.

I also built a web app for barcode scanning. For testing quaggaJS is fine but it’s highly inconsistent and requires an extreme degree of customization to get adequate results. I recommend scandit. It’s a good production ready library with a very nice web sdk.

My team was trying to get a JS solution working as well, using zxing-js. The barcode basically had to be perfect size, on a flat surface and no glare. we ended up swapping it out for ScandIT's Web SDK and have been very please with performance. As someone else said, it is quite expensive and being a public-facing web application, we had to get a per-scan license vs device license. We're going under contract for 1 year with a "shot in the dark" scan estimate and will renegotiate next year once we have usage statistics.

Would be nice to see if this new spec gets full adoption so we can avoid high licensing fees.

Re: Barcode Detection API

#96

Post by Nextgrid »

unqueued wrote: post #92
Nextgrid wrote: post #64

Earlier quoted context omitted.

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.

Users should not have to rely on the network being isolated for security. Even when I have an offline network, I still use SSH whenever possible. Yes, I don't benefit from initial verification, but I pin the certificate from then on. I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense. I have been really disappointed over the last few years deploying network conne…

Let’s say I sell a physical device that allows you to use a browser as its UI. You just plug an Ethernet cable and point your browser to its web server.

Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel.

HTTPS, with its current UX, would be a net negative in this case.

Re: Barcode Detection API

#97

Post by hhh »

arjvik wrote: post #75
jupp0r wrote: post #74

Earlier quoted context omitted.

If it's cheaper for you to run an http than an https server then you are holding it wrong.

Internal domains, where getting a certificate to client devices is painful

External wildcard cert? Maybe it’s different in smaller shops, but it’s just as easy for me to get an internal cert as it is to get an external cert. Only annoying part about our shop is a hard req fit EV certs, so no ACME.

Re: Barcode Detection API

#98

Post by tedunangst »

pests wrote: post #77
arjvik wrote: post #75

Earlier quoted context omitted.

Internal domains, where getting a certificate to client devices is painful

You can use a public CA like LetsEncrypt then. Exposes you to the certificate log but you should be secured already anyways. Just have to use the DNS challenge (unless you wanna poke a hole for certbot) to grab it

And people wonder why ioshit devices are all so cloud dependent. I just want my microwave to talk to my refrigerator (or whatever). But they have to use https, because. And the cert has to expire every 90 days, because. So now I provision a kitchen full of stuff with AWS creds so they can respond to DNS challenges to get those certs.

So much simpler for everything to revert to client only mode and route all messages through a server 3000 miles away. Until they pull the plug and nothing works at all.

Re: Barcode Detection API

#100

Post by makeitdouble »

jupp0r wrote: post #74
makeitdouble wrote: post #70

Earlier quoted context omitted.

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 an…

If it's cheaper for you to run an http than an https server then you are holding it wrong.

> you are holding it wrong.

For those whooshed by the reference, it's about the iPhone's antenna design flaw that Jobs poopooed on stage, to silently get it fixed on the next version.

It seems we're agreeing it's an actual issue that would merit to be fixed.

Post reply on HN