Planteamiento
Diseña el cifrado de extremo a extremo del lado del navegador para una reunión WebRTC multipartita. El servidor de medios reenvía RTP pero no debe leer audio ni video. El emisor y el receptor procesan fotogramas codificados en workers. Explica RTCRtpScriptTransform, RTCRtpScriptTransformer, la distribución de claves, los keyframes, el rendimiento, la recuperación ante fallas y la compatibilidad. Distingue las transformaciones de fotogramas codificados de TLS de transporte.
Qué evalúa el entrevistador
La prueba consiste en determinar si comprendes el límite del pipeline de medios del navegador: transformar después de codificar y antes de decodificar, preservar el orden de los fotogramas de readable a writable, trasladar la criptografía por fotograma a un worker y manejar la rotación de claves, los keyframes al unirse, los fotogramas perdidos y los navegadores no compatibles. Decir "cifrar RTP" sin un ciclo de vida de fotogramas está incompleto.
Preguntas para clarificar
- ¿Qué partes deben protegerse del servidor de medios y este solo puede reenviar paquetes?
- ¿Se incluye el audio, junto con la pantalla compartida y la grabación?
- ¿Las claves se distribuyen mediante señalización de extremo a extremo autenticada y cómo se revoca a los miembros que salen?
- ¿Qué matriz de navegadores es compatible? ¿Se debe rechazar a los clientes no compatibles, degradarlos o desactivar E2EE?
Un marco de trabajo de 30 segundos
TLS protege los enlaces de transporte; no evita que un servidor de medios vea texto en claro. E2EE cifra después del codificador del emisor y descifra antes del decodificador del receptor. Cubre cinco capas: detección de capacidades, el pipeline de fotogramas del worker, claves y nonces, keyframes y reintentos, y degradación/observabilidad. MDN marca la API como Baseline 2025, pero la matriz de navegadores aún requiere pruebas.
Diseño paso a paso
1. Detectar capacidades y asociar de forma temprana
Construye RTCRtpScriptTransform con un worker, un marcador de dirección y MessagePort transferible. Asócialo a RTCRtpSender.transform en el emisor y a RTCRtpReceiver.transform en el receptor antes del primer fotograma. Una verificación de capacidad fallida es un estado explícito, nunca un éxito silencioso con medios en texto en claro.
2. Procesar fotogramas en un worker
El worker maneja rtctransform, lee fotogramas codificados de event.transformer.readable, ejecuta un TransformStream y escribe en event.transformer.writable. Preserva el orden y encola cada fotograma exactamente una vez; cierra el flujo y reporta el estado ante errores. El hilo principal envía configuración y manejadores de claves de vida corta, no trabajo criptográfico por fotograma.
3. Definir el texto cifrado y los tiempos de vida de las claves
Crea un contexto por reunión, emisor y época de clave. Deriva un nonce que nunca se reutilice a partir de un contador de fotogramas más la identidad del flujo. Incluye la versión, la época y una etiqueta de autenticación en el texto cifrado, y verifica antes de descifrar. Distribuye las claves a través de señalización de extremo a extremo autenticada, permite una breve superposición de dos épocas durante la rotación y revoca el acceso a nuevos fotogramas cuando un miembro se va.
4. Recuperar con keyframes
Un nuevo participante puede recibir un delta frame antes de un keyframe y no poder decodificarlo. Una transformación del receptor puede llamar a sendKeyFrameRequest() después de que llega una nueva clave o de que la decodificación se vuelve imposible; una transformación del emisor puede llamar a generateKeyFrame(). Ambos devuelven promesas, por lo que debes verificar la dirección y el estado del video, y limitar la tasa de solicitudes.
5. Presupuestar latencia y memoria
Minimiza las copias y la recolección de basura, reutiliza los búferes de fotogramas donde sea seguro y mantén acotada la concurrencia del worker. Mide la latencia de transformación, la profundidad de la cola, la tasa de pérdidas y la tasa de solicitudes de keyframes. Si la criptografía excede el presupuesto de latencia, reduce la calidad del video o pausa una pista en lugar de bloquear el hilo de la interfaz de usuario.
6. Manejar errores y reconexiones
Las claves expiradas, las fallas de autenticación, los cierres inesperados de workers y las llamadas a la API rechazadas entran en una máquina de estados observable. Reinicia un worker para fallas transitorias y reanuda la época actual; detén la pista y explica el estado cuando la recuperación falle. Después de la renegociación de PeerConnection, asocia una nueva transformación en lugar de asumir que el worker anterior sigue al nuevo emisor.
7. Establecer límites de compatibilidad y seguridad
MDN etiqueta Encoded Transform como Baseline 2025; sin embargo, es posible que los navegadores y dispositivos más antiguos no la tengan. La política del producto debe rechazar explícitamente, deshabilitar E2EE o permitir que un servidor de medios confiable realice la transcodificación. El documento del W3C es un Working Draft, por lo que la estabilidad de la interfaz y las diferencias de implementación deben permanecer visibles en el plan de despliegue.
Ejemplo de una respuesta sólida
"Asociaría RTCRtpScriptTransform después del codificador del emisor y antes del decodificador del receptor. Un worker lee fotogramas codificados de readable, aplica cifrado autenticado y escribe en writable. La señalización de extremo a extremo gestiona las claves por reunión, miembro y época; un contador de fotogramas que nunca se reutiliza forma el nonce, y el receptor verifica la etiqueta antes de descifrar. Cuando un nuevo miembro o clave no puede decodificar un delta frame, el receptor limita la tasa de sendKeyFrameRequest y el emisor puede ejecutar generateKeyFrame. Medimos la latencia de transformación, la profundidad de la cola, las pérdidas y las fallas de autenticación; una recuperación fallida detiene la pista. La detección de capacidades elige el rechazo, la degradación o la desactivación de E2EE, y el despliegue registra Baseline 2025 además del estado de W3C Working Draft".
Errores comunes
- Tratar TLS como cifrado de medios de extremo a extremo.
- Cifrar cada fotograma en el hilo principal o transformar fotogramas sin procesar en lugar de fotogramas codificados.
- Reutilizar nonces, omitir comprobaciones de autenticación u omitir épocas y revocación.
- Ignorar los keyframes, los cierres inesperados de workers, las reconexiones y las diferencias entre navegadores.
- Afirmar compatibilidad con WebRTC sin verificar las interfaces de Encoded Transform.
Direcciones de seguimiento
¿Por qué transformar después de la codificación?
Los fotogramas codificados son más pequeños y permanecen en el pipeline de RTP; transformar fotogramas sin procesar agrega copias y cómputo antes de codificar.
¿sendKeyFrameRequest() siempre enviará una solicitud?
No. El agente de usuario puede decidir que es innecesario mientras sigue cumpliendo la promesa, por lo que el producto necesita manejo de esperas y timeouts.
¿Cómo deben llegar las claves al worker?
Pasa manejadores de corta duración a través de opciones o un MessageChannel transferible; evita exponer claves de larga duración a scripts no relacionados.
¿Pueden los navegadores no compatibles degradarse silenciosamente?
No. El usuario y la política de la reunión deben indicar claramente si los medios actuales cuentan con E2EE.
¿Cómo se demuestra que el servidor no ve texto en claro?
Captura datos en el nodo de reenvío en un entorno de prueba y verifica que solo sean visibles fotogramas de texto cifrado; audita la señalización, los workers, los servicios de claves y los permisos de grabación.
Referencias
MDN "Using WebRTC Encoded Transforms", MDN "RTCRtpScriptTransformer" y el Working Draft del W3C "WebRTC Encoded Transform".