demo · v141

E2E Encryption

The end-to-end encrypted media pipeline that webrtc-samples ships demonstrates the V2 API in action. Encoded video frames flow through a worker, get encrypted with a key the SFU never sees, then decrypted at the peer. Chrome 141's V2 API aligns the spec with Safari (2022) and Firefox (2023) so the code is cross-browser portable.

Heads up Requires Chrome 141+. This demo doesn't actually open a peer connection — it walks the worker pipeline structure that the canonical e2e-encryption sample uses, with snippets you can drop into a real RTCPeerConnection.

checking support…

local sender

Encoder produces frames. RTCRtpSender exposes an encodedStreams writable.

worker (encrypt)

A worker reads each frame, prepends a header, encrypts the body with AES-GCM, writes back.

peer receiver

RTCRtpReceiver exposes an encodedStreams writable too. Worker reverses the transform.

open the live webrtc-samples demo →

the V2 wire-up

// Main thread
const sender = pc.getSenders().find(s => s.track.kind === "video");
const stream = sender.transform = new RTCRtpScriptTransform(worker, {
  role: "encrypt",
});

// Worker
self.onrtctransform = (e) => {
  const { readable, writable } = e.transformer;
  readable
    .pipeThrough(new TransformStream({ transform: encryptFrame }))
    .pipeTo(writable);
};

why this angle

The chromestatus entry's sample link points directly at the end-to-end-encryption sample. It's the use case the API was designed around — third-party SFUs (Daily, LiveKit, custom) can route encrypted media without ever having the key, so user video and audio stay private even from the conferencing provider. V1 of the API had a worker-shape that diverged across browsers; V2 aligns the spec so a single codebase ships on all three engines.

scenario focus

Select a scenario to focus its rendered example and summary.