71–80 of 141 posts
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.
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.
>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.
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 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…
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.
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.
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.
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
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
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.
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.
Browsers make an exception for localhost and treat it as a secure context. 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.
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…