{"id":423,"date":"2024-02-21T19:55:49","date_gmt":"2024-02-21T19:55:49","guid":{"rendered":"https:\/\/blog.mozilla.org\/webrtc\/?p=423"},"modified":"2024-05-16T18:18:14","modified_gmt":"2024-05-16T18:18:14","slug":"end-to-end-encrypt-webrtc-in-all-browsers","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webrtc\/end-to-end-encrypt-webrtc-in-all-browsers\/","title":{"rendered":"End-to-end-encrypt WebRTC in all browsers!"},"content":{"rendered":"

Hi all, we haven’t blogged since the WebRTC API was standardized back in January of 2021<\/a>! But now in 2024 folks are asking us what’s up with all the new APIs? \u2014 We’re coming off an exciting second period of innovation and experimentation in WebRTC, so we’re brushing off the old blogging muscles to cover what’s new, in what’s promising to be a new series of posts.<\/p>\n

First, don’t worry. WebRTC 1.0 has been tremendously successful and has not fundamentally changed. Instead, its success has led to developers wanting to use it for a variety of things. This demand has driven continued collaboration in the W3C\u00a0 to standardize new functionality on top of the 1.0 baseline. Each new API exposes exciting new functionality, and each one deserves its own blog post, so let’s start right away with one of them:<\/p>\n

Today’s topic is End-to-End-Encryption (E2EE)<\/strong> in WebRTC.<\/p>\n

First, we should note that WebRTC is already peer-to-peer encrypted by DTLS<\/a>, so there’s no need to use additional APIs except to protect data against any middle-boxes your service might employ as WebRTC end-points. That said…<\/p>\n

Did you know all major browsers have an API to encrypt WebRTC calls end-to-end?<\/strong> They do! The caveat is the API shape differs slightly between browsers right now. But don’t despair! We’re here to cover that gap. If you’ve been with us for a while you know we’ve been here before, and this is how the sausage is made.
\n<\/p>\n

A worker-first API<\/h2>\n

Chromium experimented early with shipping APIs for this. Unfortunately the early APIs exposed the media pipeline on main-thread, subjecting it to risks of jank<\/a> given the nature of the JavaScript event model. The Working Group learned from these experiments, and settled instead on a “worker-first”<\/em> API, which means an API that is simpler to use in a worker than from main-thread.<\/p>\n

This standards-track API is RTCRtpScriptTransform<\/code><\/a>, and lets you transform encoded frames before sending, and back again on reception. The most obvious use-case is E2EE, but it can also be used for other things like adding metadata.<\/p>\n

See RTCRtpScriptTransform<\/code><\/a> in action below, XOR-ing data on send and receive (runs in all browsers):<\/p>\n

    \n
  1. Click Start!<\/code> and share your camera, and you’ll see two videos: what’s sent and what’s received by a peer<\/li>\n
  2. Uncheck \u2705 descramble<\/code> to skip XOR on receive for some spectacle (the garbage illustrates that the receiver was “decrypting” with XOR before!)<\/li>\n<\/ol>\n