What rides inside the QR label: a handshake, unpacked
People scan the pairing code at our counter and reasonably wonder what they just showed the other device. A password? A file? A link to somewhere? None of those. The label is a connection ticket — about 150 bytes that answer exactly three questions the other browser cannot answer for itself: who are you, how do I verify it's you, and where do I knock? Let's take one apart.
Field one: a doorman's passphrase
When two devices try to connect directly, they don't just start streaming — they first probe each other with little "are you really there?" packets, a protocol called ICE. The ufrag and password in the ticket are the session's temporary door-knock code: incoming probes that can't present them are ignored. They're generated fresh by the browser for every single pairing and expire with it. Reading an old ticket later gets you into nothing, which is why we can cheerfully print them on screen.
Field two: the wax seal
The middle field, 43 characters of packed base64, is a SHA-256 digest of the sending browser's self-generated encryption certificate. When the encrypted tunnel is negotiated moments later, each side checks that the certificate the wire presents boils down to exactly the digest the QR label promised. This is the step that makes the camera exchange more than a convenience: because you physically pointed one device at the other, you know — cryptographically, not hopefully — that the tunnel ends at that device and not at some other machine on the network playing man-in-the-middle. The label is a wax seal you verified in person.
Field three: where to knock
Then come the socket addresses. On modern Chrome you'll usually see something odd there: not a bare IP, but a token like *9b36eaac… — a compressed mDNS name. Browsers stopped exposing your raw LAN address to web pages years ago (it was a tracking goldmine) and hand out a per-session pseudonym instead; only devices on the same local network can resolve it back to a real address, which for our purposes is a feature twice over. A plain 192.168… address and port may follow. Whichever of these knocks succeeds first becomes the path your files take.
And the part that isn't there
A browser's raw connection offer — the SDP document — runs one to four kilobytes, which would demand a QR code so dense your camera would need a tripod and a prayer. Our in-house code reader tops out around 230 usable bytes for a comfortable scan, so shipping the document was never an option. The trick: almost all of that document is boilerplate. Both devices load the same page, so both carry an identical template of a data-channel-only session — one m=application section, same transport lines, same defaults. The receiving side slots the ticket's four fields into the template and regenerates the full document, character for character, exactly as the sender's browser would have written it. We keep that honest in an automated test: compress, rebuild, re-compress, and the ticket must come back byte-identical.
The last field, a single digit, is the humblest and my favorite: a salt. Some payloads happen to produce QR patterns that camera-decode less reliably — dense codes can contain runs that mimic the big corner finder squares. Before showing you any label, the page decodes its own rendering as a self-test; if the pattern misbehaves, it bumps the salt, every codeword in the QR reshuffles, and it tries again. You never see any of this. You just see a label that scans.
That's the entire cargo. No file data, no lasting identity, no account, nothing worth stealing an hour later. Watch it work at the beaming counter — or read why there's no server behind the curtain.