How pairing works — and why our server never sees your video
A QR code is not a magic trick. Here is exactly what happens between the scan and the live feed, what the pairing service does and does not carry, and why it physically cannot store your video.
“Direct, encrypted, the server never sees your video” is easy to say and easy to fake. This post is the full walk-through so you can check us on it.
The cast
- The extension in your browser, which needs to produce a camera stream for a website.
- The phone page (or Android app), which has the camera.
- The pairing service — a small server whose only job is letting the first two find each other.
- The website, which just wants a normal video track and will treat whatever we hand it as a webcam.
Step one: a code, not a credential
When you enable Phone as Camera, the extension asks the pairing service for a session and shows you a QR code plus a 6-digit fallback. The QR carries a 128-bit random token — not a password, not a key to anything you own, just a temporary session handle. The 6-digit code expires after five minutes. Sessions that go quiet are reaped by heartbeat.
Scan it and the phone says to the service: “I’m the device for session X.” The extension already said the same. That’s the entire security ceremony: two devices claiming the same throwaway handle, over HTTPS.
Step two: the handshake that matters
Now WebRTC takes over. The two devices exchange connection offers — IP candidates, encryption parameters — relayed by the service as opaque blobs. The service relays them; it doesn’t need to understand them, and it has no part in the keys.
Those parameters let your phone and your browser establish a DTLS-SRTP channel directly with each other. This is the same encryption every mainstream video call uses. The keys are negotiated between your devices, on your hardware, during the handshake — the server is mathematically locked out from this point on.
Step three: video, point to point
The phone encodes frames and sends them straight to the browser. Not “through us with encryption”: directly, the way a file share between two tabs on one machine doesn’t touch the internet. On the same Wi-Fi — the free tier’s assumption — the packets don’t even leave your router.
What does the server see? Session metadata: a random ID, two temporary network addresses, heartbeat timestamps. No frames, no audio, no images, no recordings. There is no storage for them, by design — there’s nothing to breach, subpoena, or leak.
The failure story is designed too
Calls live in the real world, so when the phone drops mid-call, the website doesn’t get a broken camera — it falls back to your Blank Screen feed, and the feed switches back when the phone returns. Pairing codes that expire do so quietly. A client that misbehaves hits per-IP rate limits, with the real client IP read at the moment of connection so shared networks are treated fairly.
Verify, don’t trust
You can watch this happen in any network inspector: with VirtualCam active in Phone mode, the traffic to our service is kilobytes of signaling, while the megabytes-per-minute media flow runs between your phone’s address and your PC’s address. The security page collects the whole design in one place.
Trust is cheaper when it’s checkable. That’s the idea.