Security model

1. 01

   Guest to Host

   The guest says hello

   Plain JSON inside the data channel, which WebRTC already encrypts with DTLS: protocol version 2, role, mode, a fresh 65-byte P-256 public key and a 16-byte random nonce, both in base64url.

   hello · guest to host

   {"t":"hello","v":2,"role":"guest","mode":"link","pub":"BCu4…","nonce":"q9Lm…"}

2. 02

   Host to Guest

   The host checks, derives and replies

   It refuses anything unexpected (another version, the wrong mode, missing or extra fields, a key that isn’t on the curve) with a reject message, then closes the connection. Otherwise it builds the transcript, derives the session keys and sends its own hello with its public key and a fresh nonce.
3. 03

   Guest to Host

   The guest proves it holds the secret

   It runs the same checks on the host’s hello, derives the same keys and sends “ready”: the first encrypted frame, sequence number 0, under the guest-to-host key. Only a browser with the right secret can produce it.
4. 04

   Host to Guest

   The host confirms

   Only once the guest’s ready decrypts. If it doesn’t, the host answers reject: invalid. If another guest got in first, it answers reject: busy. Otherwise it sends its own ready under the host-to-guest key.
5. 05

   Both browsers

   Session established

   The guest decrypts the host’s ready, and both screens show the safety code. If any step fails, or 15 seconds pass first, the attempt ends. A waiting host keeps waiting for the right guest.

{"t":"enc","s":42,"iv":"…","ct":"…"}

nb2|g2h|42

• A fresh IV for every frame

  96 random bits from the browser’s secure random generator, so a repeated IV under the same key is vanishingly unlikely.

• Strict order

  Sequence numbers start at 0 and rise by one in each direction. A replayed, dropped, reordered or altered frame ends the session.

• Direction bound in

  Each direction has its own key, and the direction is part of the associated data, so a frame can’t be reflected back to its sender.

• Bounded sizes

  Text frames over 256 KiB, chunks over 64 KiB and malformed frames close the session.

• Strict schemas

  Every message type has a fixed shape. Unknown types and extra fields are dropped before the app sees them.

• Careful with files

  File names lose path separators, control characters and invisible direction marks. Only common image types keep their type, for previews; everything else downloads as plain data.

1. 01

   256 bits of randomness

   32 bytes from crypto.getRandomValues, written as 43 characters. Far beyond any guessing.

2. 02

   Never sent to a server

   It lives in the URL fragment, after the #. Browsers leave fragments out of every request, so the website, the signaling server and the code service never receive it. Only the room ID in the path reaches the website.

3. 03

   Bound into the keys

   Without the secret, even a signaling server that tampers with the connection can’t finish the handshake. It can’t read your messages, and it can’t forge them.

4. 04

   Opened on purpose

   Joining takes a click on Join session, so link previews and email scanners that open links on their own can’t take the guest’s place.

5. 05

   Done after one use

   The join page removes the secret from the address bar. Once a guest is in, the host turns everyone else away, and when the session ends nothing answers the link.

1. T0

   Session starts

   New ECDH key pairs are made in each browser. Their private halves can’t be exported.

2. T1

   Handshake

   The shared secret becomes two session keys. Raw secret bytes are overwritten with zeros; the private keys and the link secret or code are let go.

3. T2

   Conversation

   Only the two AES keys remain, held in the memory of the two tabs.

4. T3

   Tab closed

   Everything is gone. No key that could decrypt a recording exists anywhere.

The link secret or the code alone is useless against a recording. The session keys also depend on the ECDH shared secret, and computing it takes one of the two private keys. Those never leave the browsers, and they are discarded as soon as the session is set up.

Yes

Protected.

If verifiedMitigatedPartial

Protected only if you do your part, or the risk is reduced but not removed.

No

Not protected. Plan around it.