Gesaan
Reka bentuk penyulitan hujung-ke-hujung (end-to-end encryption) bahagian pelayar untuk mesyuarat WebRTC pelbagai pihak. Pelayan media memajukan RTP tetapi tidak boleh membaca audio atau video. Penghantar dan penerima memproses bingkai berkod (encoded frames) dalam worker. Terangkan RTCRtpScriptTransform, RTCRtpScriptTransformer, pengedaran kunci, bingkai kunci (keyframe), prestasi, pemulihan kegagalan dan keserasian. Bezakan transformasi bingkai berkod daripada TLS pengangkutan.
Perkara yang diuji oleh penemu duga
Ujian ini menilai sama ada anda memahami sempadan saluran paip (pipeline) media pelayar: mengubah selepas pengekodan dan sebelum penyahkodan, mengekalkan susunan bingkai dari readable ke writable, memindahkan kripto setiap bingkai ke worker, dan mengendalikan pemutaran kunci, bingkai kunci semasa menyertai, bingkai yang digugurkan serta pelayar yang tidak disokong. Menyatakan "sulitkan RTP" tanpa kitaran hayat bingkai adalah tidak lengkap.
Soalan penjelasan
- Pihak manakah yang mesti dilindungi daripada pelayan media, dan adakah ia hanya dibenarkan memajukan paket?
- Adakah audio disertakan, bersama perkongsian skrin dan rakaman?
- Adakah kunci diedarkan melalui pengisyaratan hujung-ke-hujung yang disahkan, dan bagaimanakah ahli yang telah keluar dibatalkan aksesnya?
- Apakah matriks pelayar yang disokong? Patutkah klien yang tidak disokong ditolak, diturunkan taraf, atau dinyahdayakan E2EE padanya?
Rangka kerja 30 saat
TLS melindungi pautan pengangkutan; ia tidak menghalang pelayan media daripada melihat teks biasa (plaintext). E2EE menyulitkan selepas pengekod penghantar dan menyahsulit sebelum penyahkod penerima. Rangkumi lima lapisan: pengesanan keupayaan, saluran paip bingkai worker, kunci dan nonce, bingkai kunci dan percubaan semula, serta penurunan taraf/kebolehcerapan. MDN menandakan API ini sebagai Baseline 2025, tetapi matriks pelayar masih memerlukan ujian.
Reka bentuk langkah demi langkah
1. Kesan keupayaan dan lampirkan awal
Bina RTCRtpScriptTransform dengan worker, penanda arah dan MessagePort yang boleh dipindahkan (transferable). Lampirkannya pada RTCRtpSender.transform pada penghantar dan RTCRtpReceiver.transform pada penerima sebelum bingkai pertama. Semakan keupayaan yang gagal ialah keadaan eksplisit, bukan kejayaan senyap dengan media teks biasa.
2. Proses bingkai dalam worker
Worker mengendalikan rtctransform, membaca bingkai berkod daripada event.transformer.readable, menjalankan TransformStream dan menulis ke event.transformer.writable. Kekalkan susunan dan masukkan setiap bingkai ke dalam baris gilir tepat sekali; tutup strim dan laporkan keadaan sekiranya berlaku ralat. Urutan utama menghantar konfigurasi dan pemegang kunci jangka pendek, bukan kerja kripto setiap bingkai.
3. Tentukan teks sifer dan jangka hayat kunci
Cipta konteks bagi setiap mesyuarat, penghantar dan epok kunci. Terbitkan nonce yang tidak pernah diguna semula daripada pembilang bingkai ditambah identiti strim. Sertakan versi, epok dan tag pengesahan dalam teks sifer, dan sahkan sebelum menyahsulit. Edarkan kunci melalui pengisyaratan hujung-ke-hujung yang disahkan, benarkan pertindihan dwi-epok pendek semasa pemutaran, dan batalkan akses bingkai baharu apabila ahli keluar.
4. Pulihkan dengan bingkai kunci (keyframe)
Peserta baharu mungkin menerima bingkai delta sebelum bingkai kunci dan tidak dapat menyahsukodkannya. Transformasi penerima boleh memanggil sendKeyFrameRequest() selepas kunci baharu tiba atau penyahkodan menjadi mustahil; transformasi penghantar boleh memanggil generateKeyFrame(). Kedua-duanya mengembalikan promise, jadi semak arah dan keadaan video serta hadkan kadar (rate-limit) permintaan.
5. Bajetkan kependaman dan memori
Minimalkan penyalinan dan pengumpulan sampah (garbage collection), guna semula penimbal bingkai jika selamat, dan pastikan konkurensi worker dihadkan. Ukur kependaman transformasi, kedalaman baris gilir, kadar pengguguran dan kadar permintaan bingkai kunci. Jika kripto melebihi bajet kependaman, turunkan kualiti video atau jeda trek daripada menyekat urutan UI.
6. Kendalikan ralat dan penyambungan semula
Kunci yang tamat tempoh, kegagalan pengesahan, ranap worker dan panggilan API yang ditolak memasuki mesin keadaan yang boleh dicerap. Mulakan semula worker untuk kegagalan sementara dan sambung semula epok semasa; hentikan trek dan terangkan keadaannya apabila pemulihan gagal. Selepas perundingan semula PeerConnection, lampirkan transformasi baharu dan bukannya menganggap worker lama mengikuti penghantar baharu.
7. Tetapkan sempadan keserasian dan keselamatan
MDN melabelkan Encoded Transform sebagai Baseline 2025, namun pelayar dan peranti lama mungkin tidak memilikinya. Dasar produk mesti secara eksplisit menolak, menyahdayakan E2EE, atau membenarkan pelayan media yang dipercayai melakukan transkod. Dokumen W3C ialah Draf Kerja (Working Draft), jadi kestabilan antara muka dan perbezaan pelaksanaan mesti kekal kelihatan dalam pelan pelancaran.
Contoh jawapan yang mantap
"Saya akan melampirkan RTCRtpScriptTransform selepas pengekod penghantar dan sebelum penyahkod penerima. Worker membaca bingkai berkod daripada readable, menggunakan penyulitan disahkan, dan menulis ke writable. Pengisyaratan hujung-ke-hujung menguruskan kunci bagi setiap mesyuarat, ahli dan epok; pembilang bingkai yang tidak pernah diguna semula membentuk nonce, dan penerima mengesahkan tag sebelum menyahsulit. Apabila ahli baharu atau kunci tidak dapat menyahsukod bingkai delta, penerima mengehadkan kadar sendKeyFrameRequest dan penghantar boleh menjalankan generateKeyFrame. Kami mengukur kependaman transformasi, kedalaman baris gilir, pengguguran dan kegagalan pengesahan; pemulihan yang gagal akan menghentikan trek. Pengesanan keupayaan memilih penolakan, penurunan taraf, atau E2EE dinyahdayakan, dan pelancaran merekodkan status Baseline 2025 serta Draf Kerja W3C."
Mod kegagalan biasa
- Menganggap TLS sebagai penyulitan hujung-ke-hujung media.
- Menyulitkan setiap bingkai pada urutan utama atau mengubah bingkai mentah dan bukannya bingkai berkod.
- Menggunakan semula nonce, melangkau semakan pengesahan, atau meninggalkan epok dan pembatalan.
- Mengabaikan bingkai kunci, ranap worker, penyambungan semula dan perbezaan pelayar.
- Mendakwa sokongan WebRTC tanpa menyemak antara muka Encoded Transform.
Arah tindakan susulan
Mengapakah transformasi dibuat selepas pengekodan?
Bingkai berkod bersaiz lebih kecil dan kekal dalam saluran paip RTP; mengubah bingkai mentah menambah salinan dan pengiraan sebelum pengekodan.
Adakah sendKeyFrameRequest() sentiasa menghantar permintaan?
Tidak. Ejen pengguna mungkin memutuskan bahawa ia tidak perlu sambil tetap memenuhi promise tersebut, jadi produk memerlukan pengendalian menunggu dan tamat masa (timeout).
Bagaimanakah kunci harus sampai ke worker?
Hantar pemegang jangka pendek melalui pilihan atau MessageChannel yang boleh dipindahkan; elakkan daripada mendedahkan kunci jangka panjang kepada skrip yang tidak berkaitan.
Bolehkah pelayar yang tidak disokong diturunkan taraf secara senyap?
Tidak. Dasar pengguna dan mesyuarat mesti menyatakan dengan jelas sama ada media semasa menggunakan E2EE.
Bagaimanakah anda membuktikan pelayan tidak melihat teks biasa?
Tangkap data pada nod pemajuan dalam persekitaran ujian dan sahkan bahawa hanya bingkai teks sifer yang kelihatan; audit pengisyaratan, worker, perkhidmatan kunci dan kebenaran rakaman.
Rujukan
MDN "Using WebRTC Encoded Transforms", MDN "RTCRtpScriptTransformer", dan Draf Kerja W3C "WebRTC Encoded Transform".