Malheureusement ça ne marchera pas pour l'instant... voir ci-dessous les détails techniques :
Markdown ci-dessous ## Comment fonctionne la protection — défenses en couches
Il y a **trois couches indépendantes**, dont chacune suffirait à elle seule. Ensemble, elles rendent le contenu pratiquement impossible à sauvegarder en pleine qualité sans la coopération du matériel CDM.
---
### Couche 1 — Chiffrement du transport (AES-GCM au niveau applicatif)
Chaque réponse HTTP du proxy (`/api/secure-proxy/…`) est chiffrée en AES-256-GCM **au niveau applicatif**, par-dessus le transport HTTPS normal. Le JavaScript du lecteur détient une clé de session, déchiffre le texte chiffré après son arrivée, et seulement ensuite transmet les octets bruts au navigateur. Si tu interceptes le réseau (Wireshark, HAR, proxy), tu récupères du texte chiffré inutile pour tout — playlists m3u8, segments init, segments média, tout.
**Ce que ça bloque** : toute interception réseau passive.
---
### Couche 2 — Watermarking (URLs de stream propres à chaque utilisateur)
Avant même que le déchiffrement compte, le serveur incruste un watermark visible en faisant passer chaque utilisateur par un chemin d'URL unique :
```
/api/secure-proxy/wm-stream/{64-char token}/{userId}/{resolution}/seg.m4s
```
Le segment `{userId}` dit au serveur d'incruster l'identifiant de l'utilisateur dans les images de la vidéo à l'encodage. Donc même si tu arrivais à capturer la vidéo, elle contiendrait les infos de ton compte — traçable jusqu'à toi.
Il existe aussi une version propre du même stream à :
```
/api/secure-proxy/stream/{64-char token}/{resolution}/seg.m4s
```
Les deux URLs sont valides et renvoient le même contenu, sans la superposition du watermark.
**Ce que ça bloque** : le partage de vidéo capturée (elle identifie le compte source).
---
### Couche 3 — DRM Widevine CENC (la partie incassable)
C'est la protection principale. Les segments fMP4 que le lecteur déchiffre depuis l'AES-GCM **ne sont pas de la vidéo en clair** — ils sont eux-mêmes chiffrés avec [Common Encryption (CENC)](https://www.w3.org/TR/eme-stream-mp4/) au niveau de l'échantillon. Chaque image vidéo est chiffrée individuellement avec une clé détenue par le Widevine CDM (Content Decryption Module).
Le CDM est un **plugin binaire natif** qui tourne dans une enclave isolée au niveau matériel. Il reçoit les échantillons chiffrés, les déchiffre avec les clés obtenues auprès du serveur de licences, et écrit les images décodées **directement dans le compositeur du GPU** — entièrement hors de portée de JavaScript. Les pixels déchiffrés n'existent jamais dans une mémoire adressable qu'une page web ou une extension pourrait toucher.
Tu peux le confirmer en regardant la structure brute du fMP4 :
- boîte `stsd` : le type d'entrée d'échantillon est `encv` (vidéo chiffrée), pas `avc1`
- boîte `moov` : contient une boîte `pssh` avec l'ID système de Widevine (`edef8ba9…`)
- Chaque `moof` (fragment média) contient des boîtes `senc`, `saiz`, `saio` — vecteurs d'initialisation et key IDs par échantillon
- Le payload `mdat` : les jeux de paramètres H.264 (SPS/PPS) sont en clair, mais chaque NAL unit de slice est chiffrée — entropie ≈ 5,7 bits/octet contre ≈ 7,9 pour des données totalement compressées
**Ce que ça bloque** : toute approche qui intercepte les données dans le moteur JavaScript du navigateur.
---
## Pourquoi c'est quasi impossible
```
Network wire
│ HTTPS (TLS) ← standard, rien de spécial
▼
Proxy server returns
│ AES-GCM encrypted blob ← Couche 1
▼
Player JS decrypts with session key
│ fMP4 segments ← accessible ici, mais…
▼
appendBuffer() ← c'est là qu'on a hooké
│ CENC-encrypted samples ← la Couche 3 est toujours active
▼
Widevine CDM (native, hardware-isolated)
│ Decrypted frames → GPU compositor ← la Couche 3 déchiffre ICI
▼
Screen pixels
```
La seule place où tu peux intercepter une **vidéo entièrement déchiffrée et affichable**, c'est après le compositeur du GPU — c'est-à-dire l'écran lui-même. C'est exactement ce que fait `chrome.tabCapture` : il capture la sortie rendue du compositeur. Mais là, tu ré-encodes ce qui est déjà à l'écran, donc tu perds une génération de qualité (et tu dois enregistrer en temps réel).
---
## Les étapes qu'on a suivies, dans l'ordre
| Étape | Ce qu'on a essayé | Résultat |
|--- | --- | ---|
| **1. Analyse HAR** | Examen du trafic réseau pour comprendre la structure des URLs | Trouvé le schéma d'URL `wm-stream` / `stream` et le chiffrement AES-GCM sur toutes les réponses |
| **2. Hook de fetch (première tentative)** | Interception de `window.fetch` pour réécrire les URLs `wm-stream` → URLs `stream` | Les réécritures étaient silencieusement ignorées — bug d'aliasing de `arguments` en strict mode : réaffecter le paramètre `input` ne mettait pas à jour `arguments[0]`, donc `.apply(this, arguments)` envoyait l'URL d'origine |
| **3. Correction du bug arguments** | Remplacé par `_origFetch.call(this, input, init)` au lieu de `.apply(this, arguments)` | La suppression du watermark marche enfin |
| **4. Erreur CSP** | L'extension injectait un
