Barcode Detection API(developer.mozilla.org) |
Barcode Detection API(developer.mozilla.org) |
That's mainly because of the expansiveness of MDN docs, but somewhat due to the funding distribution of Mozilla going to officers, not Firefox devs.
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 scanner are the iPad and my Canon DSLR tethered to my PC in automatic mode with a macro lens.
Resolution is a factor, but so is frame rate and environment. You have to consider the full UX stack. Someone is required to physically position the barcode in a particular way with certain lighting constraints, etc. With a handheld CCD scanner, you get a laser guide for precisely what distance to go for, and an ergonomic experience that is much more conducive to successful scans. Most offer on board illumination, so even in a pitch black room you will get a successful scan.
Everything else is measurably slower: waiting for focus in a dim room, low framerate, weird other issues.
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...
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 steps never much make it into open code.
A couple times a year I go searching to see if anyone has implemented solid pdf417 in WASM yet. It seems like a natural fit to me, and I am sure people have done it, but I have yet to see anything publicly available.
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.
Reading a linear barcode is quite easy, the shitty webcam of my 2010 macbook pro was enough for Delicious Library to pick most every article instantly, usually faster than I could even present the article.
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?
ZXing is pretty much abandoned now. It was anyway “kind of” from Google.
Would be nice to see if this new spec gets full adoption so we can avoid high licensing fees.
Object Detection for QR Code and Bar-Codes - https://universe.roboflow.com/new-workspace-mrc2b/optiscan-l...
another one for just QR Codes - https://universe.roboflow.com/lihang-xu/qr-code-oerhe
I've been thinking that building a basic scanner from scratch (i.e. only using vanilla cpp/python/whatever + image processing libraries, but nothing barcode-specific) could teach me a lot.
Good luck. ;-)
https://gist.github.com/derac/9dfa8884bb04df59ac498d3bac4a93...
https://htmlpreview.github.io/?https://gist.githubuserconten...
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.
*/
// 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 this case. Also, the API was disabled between and v.9.0 and
// v.9.2, see https://developers.google.com/android/guides/releases.
The desktop version references a third party library called "barhopper" here:
https://github.com/chromium/chromium/blob/e1e495b29e1178a451...
and barhopper seems to come from a non-public Google repo:
'src/third_party/barhopper': {
'url': 'https://chrome-internal.googlesource.com/chrome/deps/barhopper.git' + '@' + 'ad3c4382875afdd0340f1549f8b9c93cbbc16e37',
'condition': 'checkout_src_internal and checkout_chromeos',
},
I didn't realize that Chromium had missing APIs compared to Chrome but maybe that's always been the case? This appears not to be a W3C standard:
https://wicg.github.io/shape-detection-api/
I was interested in this because there are no really good open source DataMatrix decoders (to my knowledge) with the one in ZXing being basically unusable (last I checked) and libdtmx being ok but not comparable to commercial offerings.
I didn't made any changes since then. But it can be easily ported into a more modern framework (React.js etc)
Unfortunately, the csr was just keying them in and keyed mine in wrong so I was without internet for a few days.
Something to automatically pick it out would be a lot better.
Edit: guess it depends on the browser and OS.
I don't see anything this has to do with browsers. This could be implemented perfectly well in a library.
What it does not appear to do is further decode the raw value into logical data. E.g. data matrices commonly contain GS1 element strings that are not trivial to decode. There are libraries for that, though.
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.
If there was something sensitive in front of my camera, I wouldn't give any random site permission anyway.
File system access should definitely be secure only, the rest might not need it.
Of course if Mozilla actually did FlyWeb we could almost totally deprecate HTTP except for some public legacy sites.
Consider the following facts:
1. This was designed by Google
2. Google Play Services provides an API for detecting barcodes, faces and text https://developers.google.com/android/reference/com/google/a...
3. Chrome gets a shape detection API for detecting barcodes, faces and text https://web.dev/shape-detection/
Of course, it's a matter of perspective whether you want to see this as lovers of the free web helping webapps to feature parity with native apps; or Google churning out yet another low-effort standard that's easy for them and difficult for all their competitors.
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 to try six different apps before I found one that worked with my Samsung Tablet.
A web-based scanner would be a possible answer, though really Google and the phone makers and the carriers should have prioritized a "just works" solution years ago.
It's hidden, but I believe it's built in the default camera app now.
I've learned that my last 3 phones have had it built in.
My current phone (Nokia 3.4) doesn't have it, but previous one (Motorala One) did. Ironic, since I chose them for being about as close to stock as you can get, both in the 'Android One' programme (so also comparatively LTS).
The Google camera app does support QR codes FWIW, but I don't know if any other vendors except Google use it.
[0] or things like Google Play Services.
This feature uses native libraries and only works on Chrome OS, Android, and MacOS currently according to this page:
Well if you try the demo I just made [2] you can find out. Works pretty well in Chrome Version 99.0.4844.51 (Official Build) (arm64) and on my Pixel 2. Naturally won't work on my iPhone because #SafariIsTheNewIE
[1] https://developers.google.com/ml-kit/vision/barcode-scanning...
My Motorola One can do that as well and IIRC the "moto g4" I had before that too.
I didn't know Lens had it, I've never used it. (I have all Google apps disabled.)
After all, a modern cell phone could be producing 4k 30fps video, and high performance barcode decoders will detect linear barcodes with lines a single pixel wide, even in the presence of moderate noise/blur/overexposure (e.g. the barcode on a shiny can of coke)
Of course, I've got no idea if browsers will provide high performance barcode reading, or something simpler like zxing.
And I've got to say, it's not obvious to me why browsers would implement a barcode scanning API in preference to a more general accelerated image processing API. Plenty of other applications want to do real time video processing in the browser - such as video call background removal.
In the past two years, due to COVID, a lot of restaurants and dining establishments got rid of paper menus and left people with "here is a QR code, scan it to see the menu". This is the most common situation I've encountered this in. It wasn't just a few restaurants that did this, it was heavy majority of places here (Seattle).
- Lately it's been pretty common for restaurants to replace their physical menus with a QR code on the table that links to their online menu.
- When I've taken COVID tests recently, the site gives me a sticker with a QR code that links to my results page.
- I encoded my wifi network/password into a QR code and printed it out, so guests can just scan it to join, rather than have to scroll and find the right network and type in a password.
You can put up a QR code to point people to the web app which controls the IoT functions in a space, music system, etc.
They're popular for street-level advertisements for (concerts, events, clubs, jobs) to provide a link to more information without the consumer having to type a url into the browser. This is more important if you don't want to pay for a pithy high-level domain as a landing page for the thing you are advertising.
I have also seen them for easily entering WiFi credentials to your device on a new network.
They can be used in museums to link to self-guided tour information on the artwork/exhibits you are looking at. This used to be done more with rentable/loanable walkman+headset kind of devices, but makes more sense to do on one's own mobile device now.
So my use cases are (1) I am demoing the cards for people, and (2) I give the cards away for free (If it wasn’t for the supply chain crisis I’d be creating a new card design every day) or put up an installation somewhere and people interact with them. Either way I want it to be very easy for people.
Basically everywhere uses a QR code for something of importance
They're also in some restaurants where you can get to a menu to order from your phone.
You also scan QR codes for use in two factor authentication apps.
Covid has normalised QR code scanning in Australia - we have to do it at certain venues in order to show our vaccine passes.
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.
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.
It's also possible to get a certificate from a CA using any public IP address, and then reuse that cert for LAN. Certs are bound to domain names, not IP addresses.
Making all new API development available only when content is delivered via a mechanism that provides the foundation for the rest of web security is good engineering practice.
Maybe the state of the art has changed since the last time I looked, but it would be really nice to have something as easy as Lets Encrypt for private tools while at the same time not exposing internal network details.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure... Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely.
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.
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.
I would just replace "HTTPS" with "SSH", and see if that statement is still reasonable.
Even though SSH is not perfect when you can't verify the initial connection to a host on a local network, using TELNET instead is not a solution.
I have yet to hear a reason why HTTP is better than self signed and pinned HTTPS; why possibly insecure is worse than insecure.
The only justifications I have heard are UX justifications, and those are really just a critique of the UX, not the protocol.
> 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.
That is an extremely fragile solution.
By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it.
And many networks are semi-offline. You may need to have limited internet access. Or the network configuration may change in the future.
> By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it.
The reason for using Ethernet and browsers is that both are built into pretty much every computer, don't require any drivers, admin privileges or persistent software.
The idea is to replace USB, serial or some other point-to-point link which would require platform-specific drivers and client software. Most peripheral connections for printers, etc don't employ encryption on the control cables and the world hasn't ended, so physical security here is good enough in practice for the majority of purposes.
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.
So... lets... make the tech that powers it not suck, so we can stop with all this analog business.
The steps for an intranet or regular domain is exactly the same if you use the DNS challenge as the web server is no longer involved regardless.
The DNS methods we already mentioned does not involve any of that - just a simple zone file change or a few clicks in a web UI to add a new record.