Re: Thoughts on current discussion around QR codes

On 2/16/20 12:24 PM, Manu Sporny wrote:
> On 2/16/20 11:52 AM, Daniel Buchner wrote:
>> Please jettison, forget, and generally bury the idea of an animated
>> QR code.
> 
> Phil, I think you make valid points wrt. QR Codes and their use in the
> supply chain. I agree with you there. However, those are not the use
> cases that animated QR Codes are meant to address in a DID or VC ecosystem.
> 
> Here's a counter-point:
> 
> We still use morse code to this day. I expect morse code is useless to
> GS1. It's very useful as a communication mechanism of last resort, or a
> communication mechanism that avoids the use of radio waves. In problem
> spaces where you want an air-gap, such as exchanging encryption keys,
> secret messaging, etc... where you need to exchange some cryptographic
> information, or want to do a peer to peer transmissions, animated QR
> Codes can get the job done for large-ish message sizes.
> 
> For example, let's say we meet up in person and I want to exchange an
> encryption key pair with you and be assured that it won't be intercepted
> (because I know that I'm transmitting it visually, and not transmitting
> it via the Internet). Or, let's say that we're both offline - like when
> a hurricane tears through Louisiana, but I still need to prove that I'm
> an emergency responder to the National Guard soldier that's guarding an
> area to get my access badge, and that I'm qualified to enter a
> particular emergency area.
> 
> Yes, we could try to use NFC or Bluetooth, but that stuff just isn't
> ready to go in a Web Browser yet... and it assumes there is a protocol
> in place already (which there isn't, I wish there was). So, what works
> for those use cases today are animated QR Codes... because they're the
> least common denominator at present, just as morse code is. We could
> cycle down to morse code, but QRCodes have enough deployment today to
> provide a universal solution via Web Browsers for this very particular
> use case.
> 
> Yes, this is low priority for most of us... and the tranmission speeds
> (30-50 seconds for 4KB) are terrible, but there are use cases that
> warrant exploring the space.

JFYI, my memory is that it's more like 5-10 seconds for 4KB with the
current tech (which runs in JS as opposed to native code via something
like the Shape Detection API). Nothing to write home about, but a
significant difference.

I do agree that the use cases are mostly constrained by how
long a human is willing to hold a scanner. If it's more than a few
seconds, the use cases do narrow quite significantly.

That being said, it is good to remember that this approach uses video
cameras on devices which are always improving; and that the "animations"
could potentially be ratcheted up to run at 60fps or more. That's 60
different QR codes per second -- and even with a loss rate of 50% that
would be ~12KB/sec with 400 byte QR codes.

That doesn't sound like a lot (it's not), but if you're not transferring
media files, there are a lot of use cases for data transfer (like VCs)
where a single QR code just won't do but several will get the job done.
Scans can be "fast" (a couple seconds) in these cases. In other words,
just as the number of use cases narrows the longer you wait, it also
increases with the size of the data you can transfer.

So, Phil's point that animated QR codes are a non-starter for many use
cases is well taken, but so is the counterpoint that there are use cases
where they could potentially fill a gap that can't otherwise be easily
filled today (pun intended). I don't see the approach as a long term
solution, but rather as a catalyst to drive better long term solutions
to become accessible in a Web browser.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Sunday, 16 February 2020 17:55:32 UTC