Txqr: Transfer data via animated QR codes | Hacker News Reader

Txqr: Transfer data via animated QR codes

github.com

171 pointskumaranvpl57 comments

"...written in Java, Python or JavaScript. That means the code is not cross-platform..." [1]

wat. I need an explanation how these implementations are not "cross-platform" yet his Go implementation is.

1 - from the author's blog post at https://divan.github.io/posts/animatedqr/

I can only suggest his definition of cross platform may actually mean "works on iOS in compliance with Apple policies".

While those all will work well on major PC OSes and for the most part on Android devices, Apple's policies are quite strict about running compilers and interpreters on device last I checked. Meaning you need compiled code in some way, shape or form.

Apple removed the blank ban on interpreters more than five years ago. The restriction now only applies to interpreters running user-provided/dynamic code. If you're bundling it with the application, as you would here, it's allowed -- and many popular games rely on this.

This isn't true at all. You still can't run Unity outside of AOT mode, for example.

Somehow Kivy applications are allowed permitting a bundled python interpreter... I've never looked into the rules but know of examples in the app store.

But you can surely run AOT compiled Java on iOS.

In fact, there at least 3 Java AOT compilers that support it.

> I need an explanation how these implementations are not "cross-platform" yet his Go implementation is.

OP here. I agree the wording is a bit unfortunate here, as all languages mentioned were designed to be cross-platform. I was referring rather to the practical complexity of using the code in different environments - native desktop, mobile (Android/iOS) and Web (JS/WASM).

With Go you can take normal Go code and build it for iOS/Android/Web in a few seconds with a minimal effort. I personally don't know if this even possible for Java/Python/JS, let alone with such an ease.

Hah, cool! This reminds me of an old 4chan thread where people were trying to get free file storage on YouTube by uploading video's of QR code sequences with files encoded into them. Much less useful than Txqr, but fun nonetheless.

I did something similar, but not with video. I used bandcamp to store binary files that I converted to wav sound files. I uploaded Arch Linux to it! (https://bullswillriot.bandcamp.com/album/arch-linux-07-01)

Here's my medium article on it: https://medium.com/@__Tux/using-bandcamp-as-a-backup-solutio...

YouTube is essentially "free file storage", just for a very specific file format.

Some software for the ZX Spectrum was distributed in a similar fashion, by being broadcast in audio format:

https://en.wikipedia.org/wiki/ZX_Spectrum_software#Others

I suppose if you uploaded a recording of that to YouTube you could do a similar thing, although I can't seem to find any examples at the moment.

> YouTube is essentially "free file storage", just for a very specific file format.

Right. A platform for audio/video or in this case extremely inefficient file storage.

> Some software for the ZX Spectrum was distributed in a similar fashion, by being broadcast in audio format:

That's fascinating, thanks for sharing!

Netflix did just that for an easter egg in Black Mirror: Bandersnatch.

https://www.youtube.com/watch?v=UBJNXzfZ4pw

There is some audio at the end that can be read into a ZX Spectrum emulator.

Holy crap, I remember that exact thread, I was part of it. The OP made a program that just encodes files into a series of QR codes, but I told them that with some additional effort, encoding it into a format that would get less manged by YouTube's compression would make it a lot better.

Another excellent library/system for data-transfer via QR codes is QRLoop: https://github.com/gre/qrloop

It comes with this nifty demo of text->animated QR code: https://qrloop.netlify.com/

Nice, thanks for the link – I did pretty extensive search, but haven't found this one. I like how similar was path from naive implementation to the fountain codes as with txqr.

Great stuff! QR code is optimized for low error rates when the channel is a digital camera-based, single photo capture. If one uses a code designed for multiple capture over time (some video code), the transfer speed could be increased significantly. Thinking of it like a very noisy fibre optic channel, there's plenty of room for improvement.

Also, as a practical aside, two mobiles devices could use their screens and front-facing cameras to negotiate a secure session for key-exchange, etc.

Isn't this essentially how Apple Watch pairing happens?

Nope. Apple Watch pairing is unidirectional and low-bandwidth, and uses extremely cool patented technique with hiding data in luminance changes. It's exploiting the fact that human eye is so much more sensitive to the chrominance changes, rather than luminance, but computers is not. http://www.iphonehacks.com/2015/05/new-apple-patents-explain...

I am reminded of QR codes for kernel panics.

https://lwn.net/Articles/503677/

This should be a standard and could be the Kermit of H2M and M2M systems.

It would be interesting to try bidirectional transfer using the front facing cameras with two phones pointed at each other.

I would also love to see a two-way version of this.

Bluetooth and wifi are way too finicky for local "data dump"-style communication, whereas every Android/iOS phone has a front camera and a screen.

P2P applications like Secure Scuttlebutt etc. could really use a reliable local exchange without the wireless headaches.

What’s the transfer speed, are there practical file size limits? Do you have to wait for it to loop or can the reader pick up in the middle of the stream?

Fountain codes are made so the receiver can pick up anywhere in a stream, and pick up the data with 0.1% to a few percent overhead (depending on luck and loss rate). This particular implementation loops the same set of encoded packets as QR codes, but with a faster processor you’d want to generate a pseudo infinite stream of encoded packets. If your data size was 1MB with 10kb packet size, readers can decode it with any 100(+ a couple percent) packets.

That's a good question! But for something under 100Kb it should be pretty quick. Curious to know how long it takes for a whole MB.

Update: Actually, I was too optimistic : https://divan.github.io/posts/animatedqr/

There was a follow-up post[1] where the author switched to fountain codes (a type of erasure coding that is perfect for this use-case) and apparently the speed is now closer to 25kbps. Pretty neat.

[1]: https://divan.github.io/posts/fountaincodes/

Reminds me of Backer32, a piece of hardware that stored data on VHS tapes as black and white squares.

https://youtu.be/TUS0Zv2APjU?t=815

Never knew about this, but of course it exists! In the digital video tape world, it was common to do backups to tape. The old Flame/Inferno systems would do archives to D1 by laying down all of the video elements including the mattes as video, and then save the actual project code as data afterwards. When played back, it would look like black&white snow/noise. Maybe it was at the beginning, don’t remember exactly. However, at the time, I had just assumed it was just noise, but now wonder if the black&white patterns was the data like a QR code. A blank VHS tape would display static as well, but a blank digital tape would not. That’s what made these archives stand out to me.

I understand the challenges involved, but if an algorithm were fault tolerant enough to handle a flip book of qr codes, one could manually animate a file transfer. :)

Print the QR codes in infrared or ultraviolet ink on the pages of a regular book and move information secretly across borders.

QR codes are fault tolerant enough that I was able to hand-draw (pen on paper) a 25x25 code as part of a christmas gift this year. I wasn't very precise either. For animation I think the main drawback is the slow speed of typical scanner apps.

Cool - I did something similar long ago although I don't maintain it anymore. https://itunes.apple.com/us/app/qrsplice/id513008119?mt=8

Reminds me of the Travelers TV show when the Historians are getting an update.

Me and a friend put together this basic idea a few years ago at a hackathon. At the time we thought it was very funny to code something so useless (no offense to OP). Looks like we missed out on some sweet HN karma!

https://github.com/AFFogarty/QRTransfer

This oddly overlapped with just learning about bitcoinfibre [1], which uses forward error correction (FEC) to fill packets with extra data to speed up network transfers by preventing retransmissions.

[1] http://bitcoinfibre.org

I had already begun using QR codes to provide signed urls to images (graphs showing data and the like). Something like this permits transferring the graph image directly. Walk up to a smart device and retrieve its data without any convoluted pairing process.

Back in the early days of smartphones (iPhone, iPhone 3, iPhone 3GS era), Marshall Field's flagship department store in Chicago experimented with this.

Each display window had a bunch of stickers on it, similar to QR codes. You could use the app on your phone to point your camera at one of the stickers and get more information about different products on display.

They also tried something similar with a different app and some kind of Bluetooth connection.

All of this was still early days, so it didn't work very well. It would probably be OK now that the technology has matured.

I’ve been contemplating writing this same thing for the past few years. Thanks! Although the security implications to many businesses that think they’ve locked down their end clients will be huge. Most SIEMs looking for data exfiltration will analyze email attachments, outbound network connections, etc. This is a new vector that’s extremely hard to police. Can you scale the QR codes up to higher resolution, increasing the bandwidth you can transfer over the video interface?

I can't think of any actually useful applications (the one given only makes vague sense if you pretend bluetooth doesn't exists), but it's a cool demo anyway and the linked blog posts are excellent.

Offline data sync from an old device to a new one. Many phone carriers provide for something similar in a QR code. My team has an app we developed that has a similar function because the private keys and all of the wallet items are exclusively offline. We show an qr code today. The issue we have hit lately is that the amount of data we have is more than a single code. Depending on the number of wallet items the users have. The animated QR is a good solution for this.

If someone is interested in how we got an amazingly small QR using base-91 and some other cool methods here is a good read with demo code

https://docs.google.com/document/d/1B7AJDVu5ei6c7ZuHRiTvQ_q8...

Why not just use a single code for bluetooth/wifi hand shaking? Wouldn't that be more efficient by any metric and almost as compatible? What device has a solid camera and no wireless communication?

Why not both? There is always the potential that there is an actual reason to upgrade - and borked motherboards where any such modules are damaged as a potential reason.

>Why not both?

User confusion and the fact that high quality camera tech and OCR aren't exactly cheap.

If this was more widespread or built into phones like QR code scanning is in the camera app, it could be an interesting way to share data with many people at once (something like a concert for example)

But I agree it's more interesting from a technical point of view over a practical one...

Bluetooth pairing isn't really as easy as this would be in theory (especially if we're talking about a situation where you want to send a message through a crowd of people -- so congestion will be pretty bad).

Bluetooth can be complex, finicky, and would add to the cost of a small device.

I could see this being used to share diagnostic information, certificates,condensed instruction manuals, &c.

Bluetooth is much cheaper than a screen or a camera.

A device would only need a camera to receive information, and yes, at the point you need bidirectional transfer, I'd concede that this isn't the best method.

However, adding a small lcd display allows the presentation of human readable data as well, and many devices already have screens on them.

(I always thought serial over TRS (headphone) cable would be an interesting option as well.)

Less robust and cheaper

Bluetooth LE is very robust. Much more so than a camera and screen.

Face-to-face key signing/exchange, or any other kind of in person secret sharing, perhaps?

BT/Wifi methods will broadcast data to anyone within radio range, but optical data exchange like this can take place under your coat, or using some easy means of protecting the transfer against 3rd party listeners.

A single QR code, or even a few words is sufficient for that.

Usually, yes. But cross-signed PGP keys, or certificates can easily exceed a single QRCode's capacity ...

It should have a multitude of applications where pairing is difficult, but physical presence of the device is necessary.

Some applications from the top of my head.

1. Access to buildings/restricted areas etc. can be made more secure, by using higher data content with animated codes, foregoing the requirement of the device having an internet connection. 2. Transfer data to a large crowd of people, say at a concert, etc. 3. Pairing of devices where one device cannot have bluetooth or other wireless hardware (due to power / security constraints)

Honestly, this is another channel of communication between devices and it's exciting.

from the top of my head, marketing gimmicks at some event, air gap jump and/or data exfiltration

> from the top of my head, marketing gimmicks at some event, air gap jump and/or data exfiltration

data distribution over normally visual broadcast channel (TV -> mobile device, billboards -> mobile)

Cool concept, but won't it cause epileptic attacks due to flashing images?

In the science fiction novel Snow Crash an image containing random white and black pixels contained a virus that could infect any developer that would see the image: https://www.amazon.fr/Snow-Crash-Neal-Stephenson/dp/14915150...

Reply on news.ycombinator.com