Un runtime universal que ejecuta código escrito por cualquiera, en el teléfono de cualquiera, con acceso a pagos e identidad, no es primero un problema técnico: es un problema de confianza. Hace diez años China lo enfrentó de frente: WeChat y Alipay abrieron sus super-apps a millones de desarrolladores externos, y ese código ahora corre en unos mil millones de dispositivos, moviendo dinero real. Que esto no se haya convertido en un titular de filtración diario es la verdadera historia.
La lección no es "construir una sandbox". Es construir una pila de confianza, donde cada capa elimina una clase de desastre.
La pila de confianza que China realmente desplegó
| Capa | Qué hacen las plataformas | Riesgo que elimina | ¿Portable a un runtime universal? |
|---|---|---|---|
| 1. Aislamiento de motor | La lógica corre en un motor JS separado (JSCore / V8), el render en un WebView; cada mini-programa tiene su propio proceso o V8 Isolate | Código que escapa al host, robo de datos entre apps | Sí — a nivel de motor |
| 2. Sin DOM/BOM crudo | La capa lógica no tiene document, window ni localStorage; la UI solo cambia por data binding | Inyección de UI tras revisión, XSS, mutación silenciosa | Sí |
| 3. Lista blanca de red | Toda petición pasa por el host y solo HTTPS a dominios permitidos | Filtración de datos a servidores del atacante, phishing | Sí — a nivel de política |
| 4. APIs por niveles + consentimiento | Llamadas sensibles (cámara, ubicación, contactos) pasan por un puente del host y requieren autorización explícita | Recolección silenciosa de PII | Sí |
| 5. Paquete revisado | El código se sirve desde un CDN solo tras revisión de la plataforma, firmado y versionado | Cargas manipuladas o inyectadas, abuso de supply chain | Parcial — necesita una pipeline de revisión de catálogo |
| 6. Monitoreo en tiempo de ejecución | Detección de anomalías más un canal de reporte de usuarios | Abuso posterior a la publicación | Sí — telemetría |
Las primeras cuatro capas son ingeniería pura de runtime y se trasladan limpiamente a cualquier host. La capa 5 depende de tener un catálogo — una superficie de distribución curada y revisada —, que es precisamente la mitad del "catálogo abierto" de CrossMiniApp. La capa 6 es disciplina operativa.
Por qué importa para un runtime universal
La promesa de CrossMiniApp es "escribe una vez, ejecuta sobre el rail de cualquier host". Esa promesa solo vale algo si el runtime mismo impone la pila de confianza. Un WebView simple que carga código de terceros no es un runtime: es una superficie de ataque. El IP real es la ejecución sandboxeada: aislar el motor, prohibir el DOM crudo, forzar cada llamada de red por una política y cerrar las APIs sensibles tras un consentimiento.
Hay un segundo nivel: esta es la razón por la que un catálogo abierto funciona. Precisamente porque el runtime restringe lo que el código puede hacer, te puedes permitir que muchos desarrolladores publiquen. La restricción en el runtime es lo que hace segura la apertura en el catálogo.
La regla
Cuando ejecutas código de otro, la seguridad no es una función que agregas después. Es la base que entregas desde el día uno — aislamiento de motor, sin DOM crudo, listas blancas de red, APIs por niveles, código revisado, monitoreo en tiempo de ejecución. Las plataformas chinas demostraron que escala a mil millones de usuarios. Un runtime universal también puede.
