It unfortunately won't work for now... see below the tech details :
Markdown below ## How the protection works — layered defenses
There are **three independent layers**, each of which would be sufficient on its own. Together they make the content essentially impossible to save at full quality without cooperation from the CDM hardware.
---
### Layer 1 — Transport encryption (application-level AES-GCM)
Every HTTP response from the proxy (`/api/secure-proxy/…`) is encrypted with AES-256-GCM **at the application layer**, on top of the normal HTTPS transport. The player JavaScript holds a session key, decrypts the ciphertext after it arrives, and only then feeds the raw bytes to the browser. If you intercept the network (Wireshark, HAR, proxy), you get useless ciphertext for everything — m3u8 playlists, init segments, media segments, all of it.
**What this blocks**: any passive network interception.
---
### Layer 2 — Watermarking (user-specific stream URLs)
Before decryption even matters, the server burns a visible watermark by routing each user through a unique URL path:
```
/api/secure-proxy/wm-stream/{64-char token}/{userId}/{resolution}/seg.m4s
```
The `{userId}` segment tells the server to composite the user's identifier into the video frames at encode time. This means even if you somehow captured the video, it would have your account info embedded in it — traceable back to you.
There is also a clean version of the same stream at:
```
/api/secure-proxy/stream/{64-char token}/{resolution}/seg.m4s
```
Both URLs are valid and return the same content minus the watermark overlay.
**What this blocks**: sharing captured video (it identifies the source account).
---
### Layer 3 — Widevine CENC DRM (the unbreakable part)
This is the core protection. The fMP4 segments that the player decrypts from AES-GCM are **not plain video** — they are themselves encrypted with [Common Encryption (CENC)](https://www.w3.org/TR/eme-stream-mp4/) at the sample level. Each video frame is individually encrypted with a key held by the Widevine CDM (Content Decryption Module).
The CDM is a **native binary plugin** running in a hardware-isolated enclave. It receives the encrypted samples, decrypts them using keys obtained from the license server, and writes the decoded frames **directly to the GPU compositor** — entirely outside of JavaScript's reach. The decrypted pixels never exist in addressable memory that a web page or extension can touch.
You can confirm this by looking at the raw fMP4 structure:
- `stsd` box: sample entry type is `encv` (encrypted video), not `avc1`
- `moov` box: contains a `pssh` box with Widevine's system ID (`edef8ba9…`)
- Each `moof` (media fragment) contains `senc`, `saiz`, `saio` boxes — per-sample initialization vectors and key IDs
- The `mdat` payload: H.264 parameter sets (SPS/PPS) are in clear, but every slice NAL unit is encrypted — entropy ≈ 5.7 bits/byte vs ≈ 7.9 for fully compressed data
**What this blocks**: any approach that intercepts data inside the browser's JavaScript engine.
---
## Why it's nearly impossible
```
Network wire
│ HTTPS (TLS) ← standard, not special
▼
Proxy server returns
│ AES-GCM encrypted blob ← Layer 1
▼
Player JS decrypts with session key
│ fMP4 segments ← accessible here, but…
▼
appendBuffer() ← this is where we hooked
│ CENC-encrypted samples ← Layer 3 still active
▼
Widevine CDM (native, hardware-isolated)
│ Decrypted frames → GPU compositor ← Layer 3 decrypts HERE
▼
Screen pixels
```
The only place you can intercept **fully decrypted, displayable video** is after the GPU compositor — i.e., the screen itself. That's exactly what `chrome.tabCapture` does: it captures the rendered compositor output. But at that point you're re-encoding what's already on screen, so you lose one generation of quality (and you have to record in real time).
---
## The steps we took, in order
| Step | What we tried | Result |
|--- | --- | ---|
| **1. HAR analysis** | Looked at network traffic to understand the URL structure | Found the `wm-stream` / `stream` URL pattern and the AES-GCM encryption on all responses |
| **2. Fetch hook (first attempt)** | Intercepted `window.fetch` to rewrite `wm-stream` URLs → `stream` URLs | Rewrites were silently discarded — strict-mode `arguments` aliasing bug: reassigning the `input` parameter didn't update `arguments[0]`, so `.apply(this, arguments)` sent the original URL |
| **3. Fix arguments bug** | Changed to `_origFetch.call(this, input, init)` instead of `.apply(this, arguments)` | Watermark removal now actually works |
| **4. CSP error** | The extension was injecting a `
