- En iOS 26.2 o posterior, las apps para usuarios en Japón pueden usar motores de navegador distintos de WebKit, y se permiten dos tipos: aplicaciones de navegador completas y apps que usan un motor de navegador embebido
- Apple otorgará a los desarrolladores aprobados acceso a tecnologías del sistema para implementar motores de navegador de alto rendimiento, como compilación JIT y compatibilidad multiproceso
- Debido a los riesgos de seguridad, Apple solo concederá estos permisos a desarrolladores que cumplan estrictos requisitos de seguridad y privacidad y se comprometan a ofrecer actualizaciones de seguridad continuas
- Tanto las apps de navegador como las apps con navegación dentro de la app deben cumplir criterios detallados como tasas de aprobación en pruebas, seguridad de memoria, respuesta a vulnerabilidades y políticas de bloqueo de cookies
- La medida se interpreta como un cambio de política que amplía las opciones de motores de navegador en el mercado japonés mientras busca mantener la seguridad de los usuarios
Resumen del permiso de motores de navegador alternativos en iOS 26.2
- En iOS 26.2 o versiones posteriores, se permite el uso de motores de navegador distintos de WebKit para usuarios en Japón
- Se permiten dos tipos de apps:
- Apps de navegador dedicadas (ofrecen una experiencia completa de navegación web)
- Apps de navegación dentro de la app ofrecidas por el administrador del motor de navegador (usan un motor embebido)
- Apple otorga a los desarrolladores aprobados acceso a tecnologías clave del sistema, como compilación JIT y compatibilidad multiproceso
- Como los motores de navegador están expuestos a contenido malicioso y a datos sensibles de los usuarios, Apple solo aprobará a desarrolladores que cumplan ciertos criterios y mantengan requisitos continuos de seguridad
Web Browser Engine Entitlement (para apps de navegador dedicadas)
- Este permiso permite desarrollar apps de navegador que usan motores de navegador alternativos
- Antes de solicitarlo, es necesario revisar los requisitos y luego enviar la solicitud a Apple
- Apple ofrece como referencia técnica BrowserEngineKit, BrowserEngineCore y la guía de configuración del navegador predeterminado
Requisitos de elegibilidad
- La app debe distribuirse solo en iOS para Japón y estar compuesta como un binario separado de otras apps que usen el motor provisto por el sistema
- Debe contar con Default Browser Entitlement
- Requisitos funcionales:
- Aprobar 90% o más de Web Platform Tests y 80% o más de Test262
- Cumplir los mismos criterios incluso con JIT desactivado (por ejemplo, en Lockdown Mode)
Requisitos de seguridad
- Adoptar un proceso de desarrollo seguro y monitorear vulnerabilidades en la cadena de suministro
- Proporcionar una URL de la política de divulgación de vulnerabilidades y un canal de reporte de terceros
- Obligación de respuesta rápida, incluyendo medidas de mitigación en un plazo de 30 días
- Mantener una página pública de vulnerabilidades resueltas
- Publicar la política de certificados raíz y participar en el CA/Browser Forum
- Es obligatorio admitir los protocolos TLS más recientes
Requisitos de seguridad del programa
- Uso de lenguajes con seguridad de memoria o funciones de seguridad equivalentes
- Aplicación de tecnologías modernas de mitigación, como Pointer Authentication Codes (PAC) y Memory Integrity Enforcement (MIE)
- Separación de procesos y validación de IPC, con prioridad en la corrección de vulnerabilidades
- Prohibido usar bibliotecas sin actualizaciones de seguridad
Requisitos de privacidad
- Bloqueo de cookies de terceros por defecto, permitidas solo con consentimiento del usuario
- Aislamiento del almacenamiento por sitio y bloqueo del acceso entre sitios
- Prohibida la sincronización de estado entre apps, salvo con permiso explícito del usuario
- Prohibido compartir identificadores del dispositivo y es obligatorio el etiquetado en App Privacy Report
- Las API de acceso a PII requieren activación e consentimiento del usuario
Embedded Browser Engine Entitlement (para navegación dentro de la app)
- Permite embeber un motor de navegador alternativo dentro de la app para mostrar contenido web
- La navegación dentro de la app se limita a mostrar contenido accesible desde un navegador web
- La UI debe ocupar la mayor parte de la pantalla e incluir un botón para abrir en el navegador predeterminado y mostrar el dominio o la URL
Requisitos de elegibilidad
- El solicitante debe ser el responsable del motor de navegador (browser engine steward)
- Una organización que asume directamente la responsabilidad operativa y de seguridad del motor
- Debe tratarse de un motor separado con arquitectura independiente y soporte de Web API
Requisitos de la app
- Distribución exclusiva en iOS para Japón y sin permiso de navegador predeterminado
- Aprobar 90% de Web Platform Tests y 80% o más de Test262
- Cumplir los mismos criterios incluso con JIT desactivado
Requisitos de seguridad y del programa
- Proceso de desarrollo seguro, política de divulgación de vulnerabilidades, respuesta en 30 días, soporte de TLS, etc., iguales a los exigidos para apps de navegador dedicadas
- Obligación de usar lenguajes con seguridad de memoria, aplicar mitigaciones modernas de seguridad y priorizar la corrección de vulnerabilidades
- Prohibido usar bibliotecas sin actualizaciones de seguridad
Requisitos de privacidad
- Bloqueo de cookies de terceros, aislamiento del almacenamiento por sitio y prohibición de compartir identificadores del dispositivo
- Se requiere etiquetado en App Privacy Report y consentimiento del usuario para acceder a PII
Requisitos adicionales
- Al enviar la app, se debe indicar el nombre y la versión del motor embebido
- Tras publicarse una nueva versión del motor, se debe enviar una actualización de la app dentro de los 15 días
Materiales de referencia para desarrolladores y guía de seguridad
- Secure SDLC: se recomienda un desarrollo centrado en la seguridad, con modelado de amenazas, auditoría de código y pruebas de fuzzing
- Memory Safety: aprovechar la seguridad de memoria predeterminada de Swift,
std::span y la opción -fbounds-safety en C/C++
- Vulnerability Management: se requiere gestión de vulnerabilidades públicas basada en CVE-ID y distribución rápida de parches
- Network Security: se recomienda usar el Network framework y la SecTrust API del SDK de iOS
- Es obligatorio admitir TLS 1.2 y 1.3; si se usan protocolos antiguos, se debe advertir al usuario
Documentos y contratos relacionados
- Embedded Browser Engine Entitlement Addendum for Apps in Japan
- Web Browser Engine Entitlement Addendum for Apps in Japan
3 comentarios
No es por ser sarcástico, pero supongo que Safari sí está cumpliendo bien con todos esos muchísimos requisitos, ¿verdad?
Wow, también sorprende que haya empezado en Japón. Pensé que algo así iba a pasar primero en Europa o en Estados Unidos.
Opiniones de Hacker News
No creo que Apple vaya a bloquear a los navegadores competidores, pero sé que sí va a pasar
Siento que el iPhone es prácticamente el último bastión que impide un monopolio de Chrome/Chromium
Google no lo descuidaría como Microsoft, pero sí terminaría teniendo ese nivel de influencia
De verdad no quiero una situación donde la mayoría de los sitios solo funcione bien en Chrome
Al final, la terquedad de Apple, aunque sea sin querer, está frenando esa tendencia
Me parece exagerada la preocupación de que Chrome domine la web. Que se agregue una API nueva no significa que todos los sitios la vayan a usar
Firefox salvó la web incluso en la era de IE con 95% de cuota, así que no entiendo por qué ahora tendríamos que depender de una sola Apple
Esto se siente como una especie de indefensión aprendida
Además, la web móvil en sí misma se está reduciendo cada vez más alrededor de las apps
También está la tendencia de que la búsqueda con IA reemplace la búsqueda web, así que parece que la influencia de la web va a seguir bajando
Por ejemplo, como FaceTime no soportaba Firefox, usé Edge, pero al final tuve que cambiarme a Google Meet
El problema empezó cuando dejaron de innovar
Tecnologías como ActiveX, Flash y Silverlight causaron problemas de seguridad y arruinaron la web, y al final IE se volvió un infierno tanto para desarrolladores como para usuarios
Creo que el Mobile Safari de hoy heredó ese papel
Yo uso Firefox en PC y Android, pero en móvil me parece que un navegador basado en Chromium es una mejor opción
Me pareció interesante el requisito de las nuevas reglas de Japón sobre el “uso de lenguajes seguros en memoria”
Pero, ¿Apple misma cumple eso? WebKit está escrito en C++
También es ambiguo qué significa exactamente “funciones que mejoren la seguridad de memoria”
Sorprende que Apple todavía no lo haya abierto en todo el mundo
Mantener un sistema donde en un país se permite y en otro se bloquea al final va a generar confusión y costos
Para una multinacional, lidiar con este tipo de complejidad regulatoria es parte de la rutina
El control sobre los motores de navegador parece más un tema de mantener el control que de ingresos
La negociación con Japón fue mejor que con la UE, pero aun así siguen muy inconformes
Por eso no van a ceder tan fácilmente a nivel global
Parece que Apple está aplicando en Japón las mismas reglas para permitir motores de navegador de terceros que creó en la UE
Pero las condiciones son tan exigentes que en la práctica ni siquiera en la UE se ha lanzado un navegador con motor alternativo
La app tiene que hacerse como un binario completamente separado, así que para navegadores grandes como Chrome es difícil hacer el cambio
Esperaba que las leyes de Japón y la UE impulsaran cambios globales, pero las grandes empresas sí tienen margen para absorber ineficiencias por país
Por ejemplo, el iPhone restringe el acceso a tiendas de apps alternativas según la ubicación
Ver artículo relacionado
Apple ya ha recibido multas en dos países por ese popup
Viendo el requisito de “administrador de motor de navegador”, parece que en realidad solo Google y Mozilla califican
Incluso Microsoft quedaría fuera por estar basado en Blink
A los motores pequeños les costaría cumplir los requisitos de funciones básicas, así que en la práctica parece imposible entrar
Me pregunto si ahora sí se podrá usar Firefox real + uBlock Origin en iOS
Con requisitos complejos, APIs limitadas y bugs ignorados, los desarrolladores la van a pasar mal
No parece que alguna empresa vaya a invertir los recursos legales y de desarrollo necesarios para portar un motor completo solo para el mercado japonés
Artículo relacionado
Está bastante bien
Por ahora se puede usar uBlock Origin Lite para Safari u otro bloqueador de anuncios
Firefox también tiene su propia función de bloqueo de rastreadores
A menudo veo a gente temer que si Apple abre su ecosistema perderá su imagen de marca amigable con el consumidor
Pero la lógica de “si Apple no controla todo, llega el caos” es solo una falsa dicotomía
Necesitamos un punto intermedio entre el control absoluto de Apple y el abandono total al usuario
Si el mercado no funciona de manera competitiva, la regulación debe proteger a usuarios y desarrolladores
Que Apple bloquee el hardware es un precedente peligroso, y preocupa que otras empresas lo imiten
Si Apple no lo permite, nuevas funciones o apps simplemente no pueden existir
Servicios como Dropbox y GDrive también han perdido funciones por tener que adaptarse al backend lleno de bugs de Apple
Esta estructura no es normal
El requisito de Apple de usar binarios separados está casi al nivel de violar la ley
Prohibir compartir estados de sesión y forzar el bloqueo de cookies no es algo que deba hacer el SO
Incluso la propia Apple no cumple la regla de aplicar parches de seguridad en 30 días
Sorprende el esfuerzo extremo que hace Apple para dejar excepciones solo en ciertos países