Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I once heard someone create a QR code scanner to retrieve gigabytes of data, but the biggest problem is that cameras aren't powerful enough to handle it all. Essentially, the QR code needs to be downloaded to the device for loading; relying on the camera to retrieve it is very difficult. Am I wrong about this project? What's your solution?
  • Why not record with a standard high quality webcam and do the QR processing later? That’s how I would exfiltrate a large volume of data.
  • You could also do it the menial way; create multiple QR codes that can connect together. Not very practical for everyone except the very-motivated.
  • I've done a POC with the native QR reading code on iOS. The short answer is: it's not a problem at all, and you can drive very large QR codes for more efficient transfer.
  • I love the focus on giving a second life to old hardware. We often talk about 'local-first' for privacy, but this shows how local-first is also great for hardware longevity. It’s refreshing to see a tool that doesn't require a cloud connection or a functional Bluetooth stack to be useful.
  • Cool! Out of curiosity, since qr-codes can contain binary data -- rather than base64, have you tried inserting the file as-is? That way you could do away with the ASCII separator and have a binary header as well. This would spend less frames for the same amount of data, but I'm not sure if it would be computationally cheaper. The other alternative would be the alphanumeric mode of qr-codes, but then you lose lowercase.
  • Cool stuff. I’m fond of the “single HTML file” deployment option.
  • Cheers!
  • I love this type of stuff. Some years ago I did something similar, but instead of QR Codes it used a convoluted mess of audio frequency modulation to send data through sound between devices. This is much more practical if you have two cameras.
  • > a convoluted mess of audio frequency modulation

    Like a modem

    by xnx
  • I've wanted to use this for an air-gapped communication device.

    I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.

    I've daydreamed about also buying several different hardware random noise generators. XOR all of their bits together. Save a huge one time pad to each of our devices. And then also use public key crypto on top of it.

    I'm not really sure why I want this. But, it's my answer for how to reduce attack surface as much as possible, and have truly secret messages.

  • > I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device.

    Why do you need a separate device for this and not just an airgapped computer?

  • So two parts to a reply - first is, you don't need the encryption per se, but you can add that in the case that you give it some key and then it's encrypted. I don't see the value unless you're using this to generate frames for a video, which isn't current functionality but totally doable.

    Second part, Charlie Bennet said "the only entropy source is one you can trust" and the best entropy source is quantum fluctuations, so we built a fully open source phase diffusion QRNG at Quantum Village and released it. Link: https://github.com/QuantumVillage/EntropyLoop

  • I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.

    Congratulations. You just invented IrDA: https://en.wikipedia.org/wiki/IrDA

  • very nice list! Can I suggest adding my https://phntm.sh as well? itis a zero-knowledge file transmission system.
  • You should turn on github pages so we can see it live. Seems cool but I’m not at my pc rn
  • I also implemented a static web with that idea: https://github.com/anhldbk/get-beam
  • Single page file transfer using QR Codes and a browser. Sending device loads a file into the page, gets chunked. Receiver gets all the chunks through a camera, tosses lightly and reassembles, CRC to garnish. Designed to push data from an old phone that had broken comms after it took a swimming lesson in a coffee mug, it's been quite handy.
  • Interesting idea! A demo video would be great :)
  • This is wild. I made an identical program 24 hours ago. Mine just transfers text files
  • If the phone had broken comms, how did you get the code onto the phone to run?
  • This is cool and minimalistic!

    I've been noodling on https://qr-send.com which is a slightly more polished version of the "erasure fountain codes + stream of QRs"-idea, inspired by divan's Txqr posts but using Wirehair FEC for the fountain code (basically: you receive ~file size bytes via QR codes and it magically assembles them into the source file regardless of missed codes).

    It's an offline-first progressive web app and there are native & wasm builds for the sender. The browser-to-browser transfer falls up to WebRTC when possible because 30 MB/s over wifi beats a 100 kB/s QR stream. The QR scanner is a heavily-optimized WASM build of zbar, scanning at 60 fps on mobile & multiple QRs per frame (but it's finicky! Work in progress.)

    by kig
  • What is the fastest you can transfer data from ~10 meters away using a modern phone front camera and screen? Surely 100 kB/s is slow?
  • This looks like a nice polished implementation of the idea, but when I try and use it, I get to "file complete" but then.. nothing? And I see no way to report a problem or bug.
  • That sounds amazing!

    The WebRTC "fallback" basically means the QR code is just a handshake when both devices are on the same network?

  • This method of animated QR data transfer is quite efficient with fountain codes. I had PoC implementation back in the day - Txqr [1] [2]

    [1] https://divan.dev/posts/animatedqr/

    [2] https://divan.dev/posts/fountaincodes/

    Recently I rewrote it in Dart/Flutter and finally implemented RaptorQ codes (way more efficient than Luby used in original Txqr). Testing it internally now, prepareing Appstores/GooglePlay/Web deployment and new article.