Optical vs radio file transfer: the attack surface

Direct answer

Optical transfer keeps the bytes inside a light path between two devices in line of sight, so an observer needs physical proximity and a clear view of the screen. Radio links — Bluetooth, Wi-Fi Direct, AWDL, WebRTC over your network — radiate to anyone in range. Optical removes remote interception but implies no confidentiality or identity unless the payload is encrypted.

Key takeaways

Optical: an interceptor needs physical proximity and a clear line of sight to the sender's screen; no signal leaves the room to be captured.
Bluetooth and Wi-Fi Direct radiate, so observation requires a radio in range rather than a camera — and even a passive observer can log who talked to whom.
WebRTC over an existing network has no range of its own: the exposure is the network path plus the signalling channel that introduces the two peers.
No channel in this comparison authenticates the sender by itself; any screen can draw perfectly valid QRTP frames.
Safe Send encrypts the payload with AES-256-GCM through the Web Crypto API, under a key derived from the passphrase with PBKDF2-HMAC-SHA-256 (100,000 iterations), before the first frame is drawn.
The Wirehair fountain code detects corruption structurally, not cryptographically: the receiver recovers the original bytes only when the linear system is satisfied.

Four channels, four observation requirements

Bluetooth

Bluetooth carries a file over a paired radio link on 2.4 GHz. To observe the transfer you need a radio inside the nominal link range — tens of metres for a typical phone-to-laptop session, less through walls — plus either a sniffer that can follow the session or simply a device that joined it. A receiver can be spoofed: a hostile device advertising the same service class or device name looks like the intended peer to a user picking a target from a list. Identity guarantees come only from pairing, and only when the humans actually compare the code shown on both screens; a pairing step that displays nothing to compare supplies no machine-in-the-middle resistance.

Wi-Fi Direct and AWDL-style peer links

Wi-Fi Direct and Apple's AWDL-style peer links build an ad-hoc network between the two devices instead of routing through an access point. Observation is easier than with Bluetooth, because these are ordinary 802.11 frames at higher power: a radio in range with monitor mode sees management and association traffic, and nominal outdoor range is on the order of 100 m line of sight. The receiver is spoofable in the same way — SSIDs and device names are self-declared. Where a vendor adds a recipient allow-list, that list is an account-level policy, not a link-layer proof of who holds the other radio; the underlying question of which physical machine is on the other end is still answered by a name the far side chose.

WebRTC over an existing network

WebRTC does not radiate on its own; it runs over whatever IP path exists. What an observer needs is a position on that path — a compromised router, a mirror port, a hostile Wi-Fi network — or a seat in the signalling service that introduced the peers. Range is therefore unbounded: it is wherever the packets are forwarded, which is the entire internet if a relay or public signalling server is involved. The receiver is spoofable through that signalling channel, since the session or room identifier is the only handle the two sides share. The transport itself is encrypted (DTLS for data channels), so the payload is not readable by a passive on-path observer, but that only binds the traffic to a key, not to a person. Both sides must verify the connection's fingerprints out of band to turn "encrypted" into "who I think it is".

Optical QR link

The optical case inverts the radio one. QR Send draws the transfer as a stream of QR codes and the receiving camera decodes them, which is a unidirectional optical link: the bytes exist only as light between the screen and the lens. There is no radio emission and no network path, so observation requires physical proximity and an unobstructed view of the screen — an observer in another room, on the LAN, or upstream in the internet path sees nothing at all. What that does not buy is trust. A camera in the same room reads exactly the same frames the intended receiver reads, and the receiving device still has to trust what it captures: a rogue screen, or a replayed recording of one, can emit frames the decoder accepts. QRTP constrains the format — full frames carry an explicit stream header while squeezed frames imply stream_id = 0, and the 15-bit transfer_id uses its high bit to mark squeezed frames — but format conformance is not authentication. Nothing in the frame layout proves who drew it, which is why confidentiality must come from the payload itself. See air-gapped file transfer for where this property is the whole point.

large packet (368 B):  [ explicit stream header ][ transfer_id : 15 bits ][ wirehair block ]
small packet  (40 B):  [ transfer_id : 15 bits, high bit set → squeezed, stream_id = 0 ]
wirehair block:        [ block_id : 4 B ][ fountain block : packet_size − 4 B ], ≤ 64000 blocks

The four channels side by side

Channel	What an observer needs	Range	Receiver spoofable?	Identity guarantee
Bluetooth	A radio in range; sniffing for discovery, a session-following receiver for the payload	Tens of metres, class-dependent, 2.4 GHz	Yes — same service class or device name	Pairing and bonding, and only if the users compare the code
Wi-Fi Direct / AWDL-style	A radio in range plus monitor mode for management frames	Up to ~100 m line of sight at consumer power	Yes — self-declared SSID and device name	Vendor account allow-lists, not link-layer identity
WebRTC over an existing network	A position on the network path, or a seat in the signalling service	Wherever the IP path reaches — potentially the whole internet	Yes — the signalling session/room ID is the only handle	DTLS-encrypted transport to a key; fingerprints usually unverified
Optical QR	Physical proximity and a clear line of sight to the screen, plus a camera	The light path only; centimetres to a few metres depending on module size	Yes — any screen can draw valid frames	None at the link layer; only the payload's own crypto

Confidentiality is not authenticity

"Is QR file transfer secure?" collapses two separate questions. Confidentiality asks who can read the bytes. Integrity and authenticity ask whether the bytes are the ones the sender produced, and whether they came from the sender at all. The optical link is better than radio on the first question's observation surface and neutral on everything else: whoever can see the screen reads the same modules the receiver does, and the link cannot tell the two apart.

Property	Question it answers	Mechanism that addresses it
Confidentiality	Who can read the file?	AES-256-GCM over the payload (Web Crypto), key derived from the passphrase with PBKDF2-HMAC-SHA-256 (100,000 iterations)
Integrity	Were the bytes altered?	The AES-GCM authentication tag; the fountain code's linear system as a structural check
Authenticity	Did the sender hold the key?	The same AEAD tag — proof of knowing the passphrase, not of a device identity

Confidentiality: AES-GCM over the payload

Safe Send encrypts the payload with AES-GCM via the Web Crypto API before the first QR frame is drawn, so what a nearby camera photographs is ciphertext. AES-GCM is authenticated encryption in the sense of RFC 5116: the ciphertext carries a tag that the receiver verifies before it will hand back plaintext. That means modification is not merely detectable after the fact — a tampered or invented frame stream fails to decrypt at all. Fully offline, the primitives are still the platform's own; there is no server to trust with a key. Details of the flow are in Safe Send encrypted transfer.

Key derivation: PBKDF2 from the passphrase

The passphrase never becomes the key directly. PBKDF2-HMAC-SHA-256 runs 100,000 iterations with a random 16-byte salt, so each guess costs real CPU time rather than the price of a single hash. This matters here more than on a TLS connection: there is no out-of-band key exchange on a unidirectional optical link, so the shared passphrase is the trust anchor, and the two people have to agree on it over a channel they already trust.

Integrity: what the fountain code does and does not prove

QRTP codes the file with Wirehair fountain codes, where each decoded block is a linear equation over the payload and the receiver reconstructs the original bytes only once the linear system is satisfied — that is, once enough independent equations have been collected with consistent block identifiers. Corruption generally fails to contribute a consistent equation, so damage shows up as "not yet decodable" rather than as silently wrong output. It is important to be exact about the scope: this is erasure and error handling, not authentication. An attacker who emits mathematically correct Wirehair equations with a valid block_id, or who replays a recording of the sender's screen, satisfies the decoder. The fountain layer protects you from a bad camera and a missed frame; the AEAD layer is what protects you from a hostile sender.

When optical is the wrong choice

Throughput matters. Optical rate is bounded by display frame rate and camera decode rate, not by a wire. Live media is streamed as MediaRecorder fragments and replayed at roughly 200–300 kbps with video scaled to about 360p — excellent for a verified call across an air gap, wrong for a 4 GB disk image when a healthy network path exists. If both machines are on the same network, the comparison in QR Send vs AirDrop is the more relevant one.
Nobody can see a screen. Headless servers, rack-mounted hardware and remote sites have no display to point a camera at; those calls for cables or a network path.
You need per-recipient access control. A screen is a broadcast medium. Anyone who can see it captures the ciphertext, so a single shared passphrase cannot separate two recipients; use distinct secrets per recipient.
You need non-repudiation or device identity. The optical link offers neither, and the AEAD tag proves only that someone knew the passphrase.
You did not intend the WebRTC upgrade. QR Send can negotiate a WebRTC/PeerJS connection through the network-metadata side stream, which moves the payload off the light path and onto the network path modelled above. If the optical guarantee is the requirement, that upgrade is a change of threat model, not a speed-up.

FAQ

Is QR file transfer secure?

Optical transfer narrows who can observe the transfer to people who can see the screen, but it does not by itself protect the contents. With Safe Send the payload is AES-GCM encrypted before it is drawn, so a camera in the room captures ciphertext.

Can someone photograph my screen and steal the file?

They can capture every frame you display, because a camera in view sees the same light the receiver does. What they get is either the raw file (unencrypted send) or ciphertext that requires the passphrase to open.

Does Bluetooth or Wi-Fi Direct encrypt the file?

The link layer can be encrypted, and WebRTC data channels always are. That protects the payload from a passive observer on the path, but it does not tell either side which physical machine is on the other end.

Does an optical link prove who sent the file?

No. The link is unidirectional, so the receiver never challenges the sender, and any screen can draw valid QRTP frames. Provenance comes from the AEAD tag, and only as far as the shared key goes.

Are fountain codes an authentication mechanism?

No. Wirehair reconstruction fails cleanly when the linear system is not satisfied, which detects corruption and loss, but a forged stream of mathematically valid blocks is accepted. Use encryption for authenticity and the fountain code for reliability.