La semana pasada mencioné la prohibición de Apple sobre los JITs (compiladores justo a tiempo) en el contexto de su rechazo a UTM SE, un emulador de PC de código abierto. La prohibición de Apple sobre los JITs, por motivos de seguridad, es un problema secundario en relación con UTM SE, ya que UTM SE es la versión de UTM que no utiliza un JIT. Pero debido a que no utiliza un JIT, es tan lento que el equipo de UTM no considera que valga la pena luchar con Apple respecto a su rechazo.
Sin embargo, en cuanto a esa prohibición de no utilizar JITs, vale la pena señalar que Apple incluso desactiva su propio JIT de confianza en WebKit cuando se activa el Modo de Bloqueo, que Apple describe ahora como “una protección opcional extrema diseñada para las muy pocas personas que, por quiénes son o lo que hacen, podrían ser objetivo personal de algunas de las amenazas digitales más sofisticadas. La mayoría de las personas nunca son objetivo de ataques de este tipo.” Anteriormente, Apple describía el Modo de Bloqueo como protección para aquellos que son objetivo de “empresas privadas que desarrollan software espía mercenario patrocinado por el estado”, pero recientemente ha eliminado el lenguaje “patrocinado por el estado”.
Así es como Apple describe el efecto del Modo de Bloqueo en la navegación web:
“Navegación web: Ciertas tecnologías web complejas son bloqueadas, lo que podría hacer que algunos sitios web carguen más lentamente o no funcionen correctamente. Además, es posible que no se muestren las fuentes web y que las imágenes sean reemplazadas por un icono de imagen faltante.”
El intérprete JIT de JavaScriptCore es una de esas “tecnologías web complejas”. Alexis Lours realizó algunas pruebas de rendimiento hace dos años, cuando iOS 16 estaba en beta, para medir el efecto de deshabilitar el JIT en el rendimiento de JavaScript (y también determinó una larga lista de otras características de WebKit que se desactivan en el Modo de Bloqueo, una lista que desearía que Apple publicara y mantuviera actualizada). Lours realizó varias pruebas de rendimiento, pero sospecho que Speedometer es la más relevante para el uso cotidiano. Las pruebas de rendimiento de Lours indicaron aproximadamente una reducción de dos tercios en el rendimiento de JavaScript con el Modo de Bloqueo habilitado en Speedometer.
Esto me lleva a BrowserEngineKit, un nuevo marco que Apple creó específicamente para cumplir con el DMA de la UE, que requiere que las plataformas de control permitan motores de navegador de terceros. Apple ha permitido navegadores de terceros en iOS durante más de una década, pero requiere que todos los navegadores utilicen el motor de renderizado WebKit del sistema. Una interpretación de la prohibición de Apple contra los motores de renderizado de terceros es que están protegiendo sus propios intereses con Safari. Más o menos que simplemente están siendo desagradables al respecto. Pero realmente hay un ángulo de seguridad en ello. Los motores de JavaScript funcionan mucho más rápido con la compilación JIT, pero los JITs inherentemente plantean desafíos de seguridad. Hay una sección completa en la documentación de BrowserEngineKit específicamente sobre la compilación JIT.
En mi opinión, Apple tenía tres opciones, en términos generales, para cumplir con el mandato de motores de navegador de terceros en el DMA:
1. Prohibir a los motores de navegador de terceros el uso de JITs. Esto claramente sería considerado malicioso por cualquier persona que realmente quiera ver navegadores basados en Chromium o Gecko en iOS. La ejecución de JavaScript sería entre un 65 y un 90 por ciento más lenta en comparación con WebKit.
2. Permitir que los motores de navegador de terceros en la UE utilicen la compilación JIT libremente sin restricciones. Esto abriría los dispositivos iOS que ejecuten dichos navegadores a vulnerabilidades de seguridad. El mensaje para los usuarios sería, efectivamente, “Si usas uno de estos navegadores, estás solo”.
3. Crear algo como BrowserEngineKit, que agrega complejidad en nombre de permitir la compilación JIT (y otras tecnologías potencialmente inseguras) de una manera más segura, y limitar el uso de BrowserEngineKit solo a desarrolladores de navegadores web de confianza.
Apple optó por la opción 3, y dudo que dieran una consideración seria a cualquier otra cosa. Prohibir que los motores de renderizado de terceros utilicen JITs no iba a funcionar, y permitirles ejecutar indiscriminadamente sería inseguro. El uso de BrowserEngineKit también requiere un permiso especial:
“Apple proporcionará a los desarrolladores autorizados acceso a tecnologías dentro del sistema que permitan funcionalidades críticas y ayuden a los desarrolladores a ofrecer motores de navegador modernos de alto rendimiento. Estas tecnologías incluyen compilación justo a tiempo, soporte multiproceso y más.”
“Sin embargo, dado que los motores de navegador están constantemente expuestos a contenido no confiable y potencialmente malicioso y tienen visibilidad de datos sensibles de usuario, son uno de los vectores de ataque más comunes para los actores malintencionados. Para ayudar a mantener seguros a los usuarios en línea, Apple solo autorizará a los desarrolladores a implementar motores de navegador alternativos después de cumplir con criterios específicos y comprometerse a cumplir con una serie de requisitos continuos de privacidad y seguridad, incluidas actualizaciones de seguridad oportunas para abordar amenazas y vulnerabilidades emergentes.”
BrowserEngineKit no es fácil, pero realmente no creo que ninguna solución buena lo sea. Los navegadores no necesitan un permiso especial o un marco complejo para funcionar en MacOS, es verdad, pero iOS no es MacOS. Para ponerlo en términos de Steven Sinofsky, el control es un aspecto fundamental de la promesa de marca de Apple con iOS.