Perintah
Rancang enkripsi end-to-end sisi browser untuk rapat WebRTC multipihak. Media server meneruskan RTP tetapi tidak boleh membaca audio atau video. Pengirim dan penerima memproses encoded frame di worker. Jelaskan RTCRtpScriptTransform, RTCRtpScriptTransformer, distribusi kunci, keyframe, performa, pemulihan kegagalan, dan kompatibilitas. Bedakan transformasi encoded-frame dari transport TLS.
Apa yang sedang diuji oleh pewawancara
Tes ini menguji apakah Anda memahami batas pipeline media browser: transformasi setelah encoding dan sebelum decoding, mempertahankan urutan frame dari readable ke writable, memindahkan kriptografi per frame ke worker, dan menangani rotasi kunci, keyframe saat bergabung, frame yang hilang (dropped frame), serta browser yang tidak didukung. Mengatakan “enkripsi RTP” tanpa siklus hidup frame adalah jawaban yang tidak lengkap.
Pertanyaan klarifikasi
- Pihak mana yang harus dilindungi dari media server, dan apakah media server hanya boleh meneruskan paket?
- Apakah audio disertakan, bersama dengan berbagi layar dan perekaman?
- Apakah kunci didistribusikan melalui persinyalan end-to-end yang terautentikasi, dan bagaimana anggota yang keluar dicabut aksesnya?
- Matriks browser apa yang didukung? Apakah klien yang tidak didukung harus ditolak, diturunkan versinya (downgraded), atau dinonaktifkan E2EE-nya?
Kerangka kerja 30 detik
TLS melindungi tautan transport; ini tidak mencegah media server melihat plaintext. E2EE mengenkripsi setelah encoder pengirim dan mendekripsi sebelum decoder penerima. Cakup lima lapisan: deteksi kapabilitas, pipeline frame worker, kunci dan nonce, keyframe dan percobaan ulang (retry), serta downgrade/observabilitas. MDN menandai API ini sebagai Baseline 2025, tetapi matriks browser masih perlu diuji.
Desain langkah demi langkah
1. Deteksi kapabilitas dan lampirkan lebih awal
Konstruksikan RTCRtpScriptTransform dengan sebuah worker, penanda arah, dan MessagePort yang dapat ditransfer (transferable). Lampirkan ke RTCRtpSender.transform pada pengirim dan RTCRtpReceiver.transform pada penerima sebelum frame pertama. Pemeriksaan kapabilitas yang gagal adalah status eksplisit, bukan keberhasilan diam-diam dengan media plaintext.
2. Proses frame di dalam worker
Worker menangani rtctransform, membaca encoded frame dari event.transformer.readable, menjalankan TransformStream, dan menulis ke event.transformer.writable. Pertahankan urutan dan masukkan setiap frame ke antrean tepat satu kali; tutup stream dan laporkan status jika terjadi error. Thread utama mengirimkan konfigurasi dan handle kunci berumur pendek, bukan pekerjaan kriptografi per frame.
3. Tentukan ciphertext dan masa berlaku kunci
Buat konteks per rapat, pengirim, dan epoch kunci. Dapatkan nonce yang tidak pernah digunakan ulang dari penghitung frame ditambah identitas stream. Sertakan versi, epoch, dan tag autentikasi dalam ciphertext, serta verifikasi sebelum mendekripsi. Distribusikan kunci melalui persinyalan end-to-end yang terautentikasi, izinkan tumpang tindih dual-epoch singkat selama rotasi, dan cabut akses frame baru ketika seorang anggota keluar.
4. Pulihkan dengan keyframe
Peserta baru dapat menerima delta frame sebelum keyframe dan tidak dapat mendekodernya. Transformasi penerima dapat memanggil sendKeyFrameRequest() setelah kunci baru tiba atau decoding menjadi mustahil; transformasi pengirim dapat memanggil generateKeyFrame(). Keduanya mengembalikan promise, jadi periksa arah dan status video serta batasi laju (rate-limit) permintaan.
5. Anggarkan latensi dan memori
Minimalkan penyalinan dan garbage collection, gunakan kembali buffer frame jika aman, dan jaga agar konkurensi worker tetap terbatas. Ukur latensi transformasi, kedalaman antrean, tingkat frame drop, dan tingkat permintaan keyframe. Jika kriptografi melebihi anggaran latensi, turunkan kualitas video atau jeda track daripada memblokir thread UI.
6. Tangani error dan rekoneksi
Kunci yang kedaluwarsa, kegagalan autentikasi, crash pada worker, dan panggilan API yang ditolak masuk ke dalam state machine yang dapat diobservasi. Mulai ulang worker untuk kegagalan sementara dan lanjutkan epoch saat ini; hentikan track dan jelaskan statusnya ketika pemulihan gagal. Setelah renegosiasi PeerConnection, lampirkan transformasi baru alih-alih berasumsi bahwa worker lama mengikuti pengirim baru.
7. Tetapkan batasan kompatibilitas dan keamanan
MDN melabeli Encoded Transform sebagai Baseline 2025, namun browser dan perangkat lama mungkin tidak memilikinya. Kebijakan produk harus secara eksplisit menolak, menonaktifkan E2EE, atau mengizinkan media server tepercaya untuk melakukan transcoding. Dokumen W3C adalah Working Draft, sehingga stabilitas antarmuka dan perbedaan implementasi harus tetap terlihat dalam rencana peluncuran (rollout).
Contoh jawaban yang kuat
“Saya akan melampirkan RTCRtpScriptTransform setelah encoder pengirim dan sebelum decoder penerima. Sebuah worker membaca encoded frame dari readable, menerapkan enkripsi terautentikasi, dan menulis ke writable. Persinyalan end-to-end mengelola kunci per rapat, anggota, dan epoch; penghitung frame yang tidak pernah digunakan ulang membentuk nonce, dan penerima memverifikasi tag sebelum mendekripsi. Ketika anggota baru atau kunci baru tidak dapat mendekode delta frame, penerima membatasi laju sendKeyFrameRequest dan pengirim dapat melakukan generateKeyFrame. Kami mengukur latensi transformasi, kedalaman antrean, drop, dan kegagalan autentikasi; pemulihan yang gagal akan menghentikan track. Deteksi kapabilitas memilih penolakan, penurunan versi, atau penonaktifan E2EE, dan peluncuran mencatat status Baseline 2025 serta W3C Working Draft.”
Pola kegagalan umum
- Menganggap TLS sebagai enkripsi end-to-end media.
- Mengenkripsi setiap frame di thread utama atau mentransformasikan raw frame alih-alih encoded frame.
- Menggunakan kembali nonce, melewatkan pemeriksaan autentikasi, atau mengabaikan epoch dan pencabutan kunci.
- Mengabaikan keyframe, crash pada worker, rekoneksi, dan perbedaan browser.
- Mengklaim dukungan WebRTC tanpa memeriksa antarmuka Encoded Transform.
Arah tindak lanjut
Mengapa mentransformasi setelah encoding?
Encoded frame berukuran lebih kecil dan tetap berada di dalam pipeline RTP; mentransformasi raw frame menambah penyalinan dan komputasi sebelum encoding.
Apakah sendKeyFrameRequest() akan selalu mengirimkan permintaan?
Tidak. User agent dapat memutuskan bahwa hal itu tidak perlu dilakukan sambil tetap memenuhi promise tersebut, sehingga produk memerlukan penanganan tunggu dan batas waktu (timeout).
Bagaimana seharusnya kunci mencapai worker?
Teruskan handle berumur pendek melalui opsi atau MessageChannel yang dapat ditransfer; hindari mengekspos kunci berumur panjang ke skrip yang tidak terkait.
Bisakah browser yang tidak didukung diturunkan versinya secara diam-diam?
Tidak. Kebijakan pengguna dan rapat harus menyatakan dengan jelas apakah media saat ini menggunakan E2EE.
Bagaimana Anda membuktikan server tidak melihat plaintext?
Tangkap data pada node penerusan di lingkungan pengujian dan verifikasi bahwa hanya frame ciphertext yang terlihat; audit persinyalan, worker, layanan kunci, dan izin perekaman.
Referensi
MDN “Using WebRTC Encoded Transforms”, MDN “RTCRtpScriptTransformer”, dan W3C “WebRTC Encoded Transform” Working Draft.