> Other than aesthetics, what are the advantages of the point cloud? Higher bandwidth?

Higher information density, in that it can pass ad-hoc wifi network info and cryptographic keys. The animated "QR code" also contains a unique code in each frame that is then sent back during the pairing process. This allows them to measure the round trip time from display to camera to wifi back to the original device, preventing relay and replay attacks.

(This is based on my attempting to reverse engineer watch pairing for a few days)

Here is a good demo of a streaming qr solution. Not ours but a good demo of the concept.

https://youtu.be/_0djJ1aVEXs

We use a similar method for offline wallet transfers of private crypto keys. I’ll note a couple things. Keep the frame simple and not too dense. Be careful on ecc settings. Higher res camera androids to be slower in our testing. Be ready to loop the series to catch missed frames. Gives your frames and order context. If it’s really sensitive dat, encrypt it before encoding you QR. assume the video can be stolen from a camera. Inject noisy frames To help obfuscate.

Another animated QR data transfer that uses fountain codes: https://github.com/divan/txqr

Hey, I wanted to use your library to send data from computer A to computer B, but I don't speak Go yet.

How easy would it be to implement a txqr reader for desktop? Piping zbarcam's output could be the easiest way.

Have you got any directions for me to do it? It would be a great addition to txqr!

Thanks!

I'm actually planning to make Go+Flutter application, which will work on iOS/Android, Desktop and Web. Out of curiosity, what's your use case?

I would use this in a security context.

I want to use a one-time pad with a friend. That requires generating a fully random file that I then need to send to my friend (physically). I don't have an Ethernet port on my machine to send the file on the wire, and I don't want to rely on weaker cryptography (WiFI, aes) to send this file (basically, everything is weaker than a one-time pad). I also don't want to leave undeletable traces of my one-time pad on a flash drive.

So what's left is the actual screen of the device, provided I don't have any hidden cameras where I live.

I could use a hard drive and then shred the secrets, but nothing is proven regarding the actual deletion of the files, and QR codes are much cooler!

Did you consider using the front camera for bidirectional phone-to-phone communication? That could allow frame re-transmits which would increase the data rate a lot.

That'd be definitely a whole new level, yes, but I think the simplicity of one-way diode communication has its own benefits.

I've been wondering how one could efficiently and reliably pack arbitrary data into YouTube videos, a hacky way to get free and obfuscated data storage. Streaming QR codes has been the most promising way I can think of, particularly since they offer resilience against YouTube's video re-encoding process and are standardized for far larger codes, which could be easily fit in a video for later parsing out by a tool. You could probably embed even greater data densities with a color QR solution too.

Put your data into description and comments.

If I had to guess, the animated point cloud isn't tasked with transferring lots of (megabytes) data, but is probably a proprietary version of a QR code, both for aesthetics and security through obscurity. Its format may also have higher information density than a QR code, which would work well for encrypted data.

I imagine the heavy lifting is done on Apple's server. The data being transferred locally is likely a GUID/IMEI/etc + a nonce.

Data is actually transferred locally through Bluetooth, but the initial handshake appears to happen through the point cloud.

Bluetooth? I would assume direct wifi, ie Airdrop. Use Bluetooth to initiate it but handle the data transfer over high bandwidth wifi

Why initiate over BT? Wouldn't you bootstrap from QR to WiFi?

I just transferred a friend's iphone the other day and noticed this animated pattern. I presumed the QR-like code was just to transfer authentication so that the two phones could establish a secure wifi connection, since the QR recognition is fairly instantaneous and you don't have to keep the camera on the animation for long. (the process does ask you to keep the phones close, so the later transfer is probably by bluetooth, as you say)

One (possible) advantage could be that the animated nature means that someone taking a photograph of the animation won't capture enough data to steal the whole payload? And the use of tiny pixels might mean that even a video capture from anywhere but up-close might not have enough fidelity (after compression) to read the encoding either?

I bet its about the “opportunity cost aesthetics”—-Apple thinks QR codes are butt ugly. See also the round App Clips codes recently introduced, and the very late (I bet teeth-grittingly reluctant) introduction of QR scanning in the first-party iOS Camera app.

I could be completely off the mark, but would an animation make it difficult to spoof. I can't now just use a photo of the cloud? Of course it could be that it just looks cool :D

Not quite sure I understand what the question is. Calculating the QR is really CPU intensive and the settings on the site are for lowest quality. ANd even now its overloading.

OP asks about Apple’s animated "QR cloud" which was used in some iPhones and with the Apple watch:

https://apple.stackexchange.com/questions/301563/what-is-the...

https://www.quora.com/Has-somebody-tried-to-dynamically-gene...