How we keep screen sharing end-to-end encrypted
Screen share is just another media track — and at Whatping the SFU relays it as ciphertext, exactly like camera and mic. Here's how, and how we prove it.
When you share your screen on a call, that video usually flows through a media server (an SFU) that fans it out to everyone else. The obvious question for a confidential meeting: can the SFU see my screen?
At Whatping, the answer is no — and screen share gets exactly the same treatment as your camera and microphone.
One key source: the room’s MLS group
Every Whatping room is an MLS (RFC 9420) group. From that group secret we derive the media key. The browser uses WebRTC insertable streams (a frame cryptor) to encrypt each outgoing media frame before it reaches the SFU, and to decrypt incoming frames after they leave it. The SFU only ever routes opaque, encrypted payloads.
Screen share is not special-cased. It’s published as another track, sealed with the same room key, so the SFU is just as blind to your screen as it is to your face.
Proving it, not asserting it
Claims are cheap, so we test the property directly. In one end-to-end test:
- Alice shares her screen.
- Bob, who holds the correct room key, subscribes and decodes the frames — he sees the screen.
- Carol, given a deliberately wrong key, subscribes to the same track and decodes 0 frames, while her decryption-error counter climbs.
If the SFU could see the screen, Carol’s wrong key wouldn’t matter. It does. The relay forwards ciphertext; only a participant with the room’s key can render the pixels.
Why it matters
“Encrypted calls” often quietly excludes screen content, recordings, or chat. For the meetings where you’re sharing a term sheet, a patient record, or source code, that exclusion is the leak. Treating every track — camera, mic, and screen — as equally untrusted to the server is the whole point.