Administración de versiones

Magdalena Skarbińska

Demián Renzulli

Las apps web aisladas (IWA) ofrecen un entorno de ejecución seguro, de alta confianza, y con versiones discretas sobre la plataforma web. En los entornos de producción, en particular, dentro de las empresas administradas, los administradores y desarrolladores necesitan un control detallado sobre las implementaciones de software.

Para satisfacer estos requisitos, Chrome proporciona capacidades integrales de administración de versiones para las IWA, incluidos los canales de actualización, las versiones fijadas y el cambio a una versión anterior. Estas funciones permiten la previsibilidad de la implementación y los controles de recuperación rápida en toda tu base de usuarios.

Disponibilidad

El comportamiento de la administración de versiones depende de si la IWA la administra un administrador o si la instala directamente un usuario:

• IWA administradas: Las funciones administrativas (incluidas las versiones fijadas y los cambios a versiones anteriores basados en políticas) están disponibles a partir de Chrome 133.
• IWA no administradas (instaladas por el usuario): Las funciones orientadas al usuario (como la selección manual de canales) están disponibles a partir de Chrome 150.

Compatibilidad de tipos de sesión

Todas las funcionalidades de administración de versiones, incluidos los canales de actualización y las versiones fijadas, son totalmente compatibles con todos los tipos de sesión de ChromeOS. Esto incluye lo siguiente:

• Sesiones de usuario administradas estándar
• Sesiones de invitado administradas (MGS)
• Entornos dedicados al modo de kiosco

Nota: Para garantizar que las actualizaciones se reconozcan correctamente, las cadenas de versión deben seguir el formato de IWA válido. La plataforma admite versiones solo numéricas con un máximo de 4 componentes (por ejemplo, 1, 1.2, 1.2.4 o 111.22.3.4).

Nota: Si bien las versiones fijadas y la segmentación de canales son compatibles de forma universal en todos los tipos de sesión, es posible que, al principio, los cambios a versiones anteriores estén restringidos a los testers de confianza según el cronograma de implementación de la plataforma activa.

Actualizar canales

Con los canales de actualización, los desarrolladores pueden segmentar compilaciones de aplicaciones específicas para distintas audiencias de implementación y pruebas. Para configurar canales, agrega un campo de array de canales opcional a cada entrada de versión dentro del manifiesto de actualización de la aplicación. Estos nombres de canales no están restringidos a palabras clave de plataforma fijas (como canary o stable), sino que son identificadores arbitrarios definidos por el desarrollador que deben tener el formato de cadenas alfanuméricas ASCII en minúscula (que pueden incluir guiones o guiones bajos, pero no espacios). Si una entrada de versión omite el campo de canales por completo, Chrome establece de forma implícita su disponibilidad en el canal "predeterminado". En última instancia, el nombre del canal designado en la política administrativa debe coincidir exactamente con la cadena definida en el manifiesto. Cualquier error tipográfico o configuración no coincidente hará que no se identifique ninguna versión apta, lo que detendrá de manera efectiva las actualizaciones para esos clientes.

Configuración del manifiesto

Para configurar canales, agrega un array channels opcional a cada entrada de versión en tu manifiesto de la app web. Estos son algunos factores que se deben tener en cuenta:

• Asignación de canales: Si una entrada de versión define un array channels, esa versión solo es apta para la instalación en los canales especificados.
• Respaldo predeterminado: Si una entrada de versión omite el campo channels por completo, Chrome supone que la versión pertenece exclusivamente al canal default.
• Coincidencia exacta de cadenas: Los nombres de canales especificados en las configuraciones de políticas del cliente deben coincidir exactamente con las cadenas definidas en el manifiesto de actualización (distingue mayúsculas de minúsculas). Si ninguna versión coincide con el nombre del canal segmentado, la app no podrá encontrar actualizaciones aptas.

Ejemplo de manifiesto de actualización

En el siguiente ejemplo, se muestra un manifiesto de actualización que admite varios canales de versiones:

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

Según este manifiesto, las siguientes versiones están disponibles por canal segmentado:

• default: 0.2.0,0.4.0 (que no tiene un canal explícito y usa el valor predeterminado)
• delta: 0.1.0, 0.2.0, 0.3.0
• beta: 0.3.0

El motor de actualización de IWA admite la segmentación de canales de versiones específicos buscando un campo de canales dentro del manifiesto de actualización de la app.

Versiones fijadas

En entornos empresariales de alta conformidad o muy estables, los administradores deben asegurarse de que los dispositivos ejecuten versiones exactas de software fundamental para la empresa. Las versiones fijadas permiten que los administradores bloqueen una IWA en una versión específica, lo que detiene todas las actualizaciones posteriores en segundo plano. Esto proporciona a las empresas una forma muy confiable de mantener configuraciones estables y cumplir con las estrictas reglamentaciones internas o de la industria.

Para inmovilizar una app web aislada (IWA) en una compilación de lanzamiento específica, los administradores de empresas pueden configurar la propiedad pinned_version dentro de la IsolatedWebAppInstallForceList. Esta capacidad se administra principalmente a través de los controles de la IU interactiva en la Consola del administrador de Google en el panel de detalles de la aplicación siguiendo el flujo de trabajo de instalación de IWA estándar, aunque los administradores también conservan la flexibilidad para implementar estos valores de política directamente con configuraciones JSON sin procesar. Una vez que el administrador segmenta correctamente una cadena de versión válida, Chrome extrae ese paquete explícito y bloquea todas las actualizaciones automáticas posteriores.

Comportamientos y restricciones especiales

• Reanudación de actualizaciones (desfijación): Para restablecer las actualizaciones automáticas, quita la propiedad pinned_version o cambia su valor a una versión de destino más reciente.
• No se cambia a una versión anterior de forma predeterminada: Si se establece pinned_version en una versión inferior a la instalada actualmente, no se activará una reversión, a menos que allow_downgrades esté habilitado de forma explícita.
• Destinos de fijación no disponibles: Si falta la pinned_version configurada en el canal de actualización designado o es más antigua que la versión instalada (con los cambios a versiones anteriores inhabilitados), Chrome conservará la versión instalada actualmente y bloqueará cualquier actualización posterior.
• Implementaciones nuevas: Si aún no se instaló una IWA en un dispositivo administrado y no se puede recuperar la pinned_version especificada o falta en el manifiesto de actualización, no se instalará la IWA.

Es una versión anterior

Si una actualización recién implementada introduce un error o una vulnerabilidad críticos, es posible que los administradores deban revertir los dispositivos a un estado estable anterior. Chrome admite el cambio a una versión anterior de las IWA administradas ya instaladas a una versión inferior, una capacidad que antes no estaba disponible en la plataforma cuando solo se permitían las actualizaciones.

El cambio a una versión anterior solo es posible si se cumplen ambas de las siguientes condiciones de política:

1. pinned_version se establece en una versión válida y anterior.
2. allow_downgrades se establece de forma explícita como verdadera.

Cómo funcionan los cambios a versiones anteriores

• Mecanismo de activación: Las reversiones se procesan durante el ciclo de verificación de actualizaciones normal (que se ejecuta cada 4 a 6 horas).
• En segundo plano: Chrome realiza una reinstalación completa de la IWA con el paquete web anterior (.swbn) especificado en el manifiesto de actualización.

Advertencia: Pérdida irreversible de datos del usuario: Si se cambia a una versión anterior de una IWA, se borrarán por completo sus particiones de almacenamiento asociadas (incluidos IndexedDB, LocalStorage, caché y cookies). Para proteger los datos del usuario, reserva los cambios a versiones anteriores para situaciones de emergencia, como abordar vulnerabilidades de seguridad graves. Para las correcciones de errores no críticos, se recomienda compilar y publicar una actualización de versión secundaria nueva y con parches en lugar de revertir.

Importante: Inmovilización inmediata de la actualización: Si cambias allow_downgrades a verdadero, se inmovilizarán de inmediato todas las actualizaciones estándar, incluso si no defines una pinned_version. Una vez habilitado, el navegador bloquea las actualizaciones estándar hasta que asignes de forma explícita una pinned_version superior o vuelvas a cambiar allow_downgrades a falso.

Lógica de transición de canales

Cuando se cambia el canal segmentado de una app con una política, el motor de actualización se adhiere a comportamientos específicos:

Situación A: Cambio a un canal con versiones anteriores

• Si se permite el cambio a una versión anterior: Si pinned_version coincide con una versión anterior en el canal de destino y allow_downgrades es verdadero, se produce una reversión (y se borran los datos del usuario local).
• Si no se permite el cambio a una versión anterior: No se producirá ningún cambio a una versión anterior. El dispositivo permanecerá en su versión superior instalada actualmente y solo se actualizará cuando haya una versión más reciente disponible en el canal recién seleccionado.

Situación B: Cambio a un canal con una versión idéntica

• Sin cambios: Si el canal recién seleccionado apunta a un número de versión igual al instalado actualmente, Chrome no modificará el paquete instalado.
• Principio de identidad byte por byte: Los desarrolladores deben garantizar que los números de versión idénticos en diferentes canales contengan firmas de código idénticas que coincidan con los bytes. La implementación de diferentes bases de código con la misma cadena de versión en todos los canales puede generar estados de aplicación erráticos e inesperados.

Configuración de políticas administrativas

Los controles de versiones empresariales se aplican con la plataforma centralizada de la Consola del administrador de Google mediante el esquema de política IsolatedWebAppInstallForceList. Estos parámetros de configuración se pueden administrar directamente a través de los controles de la IU en la Consola del administrador o implementarse con configuraciones de políticas JSON sin procesar.
En el siguiente ejemplo de configuración de políticas administrativas, se muestran los canales de actualización, las versiones fijadas y los cambios a versiones anteriores:

Representación del valor de la política

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

Explicaciones de los parámetros del esquema

• channel (string, opcional): Indica a Chrome que solo evalúe las versiones asignadas a este canal en el manifiesto de actualización. Si se omite, Chrome evalúa el canal "predeterminado".
• pinned_version (string, opcional): Bloquea de forma explícita el dispositivo en la cadena de versión especificada. Se bloquean las actualizaciones automáticas posteriores en segundo plano.
• allow_downgrades (booleano, opcional): Habilita la capacidad de reversión. Si es verdadero y se vincula con una pinned_version válida y anterior, Chrome activará una reinstalación de cambio a una versión anterior. Advertencia: Si estableces este parámetro como verdadero, se bloquearán todas las actualizaciones estándar, incluso si se omite el campo pinned_version.

IWA no administradas (instaladas por el usuario) (a partir de la versión 150)

En el caso de las apps web aisladas no administradas instaladas por el usuario, el control de versiones funciona con interacciones manuales del usuario:

Paquete de instalación ──► El usuario selecciona el canal ──► Verificaciones automáticas en el canal seleccionado

Requisito previo del manifiesto para las actualizaciones automáticas

Para que las IWA instaladas por el usuario verifiquen y reciban actualizaciones periódicas automáticas en segundo plano, el manifiesto de la app web local (los metadatos empaquetados dentro del paquete en /.well-known/manifest.webmanifest) debe contener un campo update_manifest_url válido.

Si se omite esta URL del archivo de manifiesto local de la aplicación, el motor de actualización no administrado nunca realizará verificaciones en segundo plano, y la aplicación permanecerá inmovilizada de forma permanente en su versión de instalación inicial.

Selección manual de canales

Durante la instalación inicial de una IWA no administrada, el navegador verifica el manifiesto de actualización y muestra las opciones de canales disponibles (por ejemplo, "Estable", "Beta") directamente al usuario si el desarrollador configuró varios canales.

Reglas clave del ciclo de vida

1. Origen de la primera instalación: Independientemente del canal que seleccione el usuario durante la instalación, la instalación inicial siempre implementa los archivos empaquetados dentro del paquete de instalación proporcionado.
2. Actualizaciones posteriores: Una vez instaladas, las actualizaciones futuras se consultan exclusivamente desde el canal elegido. La app se actualizará solo cuando se publique una versión superior a la instalada en ese canal segmentado.
3. Cambio de canales: Para cambiar a un canal de actualización diferente después de la instalación, el usuario debe desinstalar la IWA y volver a instalarla, y elegir el canal seleccionado durante el flujo de instalación.

Cómo probar implementaciones administradas

Para los administradores que administran dispositivos a través de la Consola del administrador de Chrome Enterprise o configuran políticas directamente, haz lo siguiente:

1. Navega al panel Detalles de la app en la configuración de la organización.
2. Aplica propiedades de configuración para probar las versiones fijadas y los destinos de canales. Debido a que estos controles son totalmente compatibles con las sesiones de usuario estándar, las sesiones de invitado administradas (MGS) y los kioscos, puedes verificar los comportamientos en todos los entornos de implementación de destino.
3. Para inspeccionar las verificaciones de actualizaciones de forma local, navega a chrome://web-app-internals en un cliente de prueba para forzar manualmente las verificaciones de actualizaciones y analizar los paquetes de manifiesto entrantes.

Conclusión

La arquitectura de seguridad de las apps web aisladas está diseñada para potenciar a los desarrolladores y, al mismo tiempo, mantener una previsibilidad y un control estrictos sobre los comportamientos del ciclo de vida de la aplicación. Si aprovechan las funciones de administración de versiones de Chrome, tanto los desarrolladores como los administradores de TI pueden crear canalizaciones de implementación sólidas que se alineen con los estrictos estándares de cumplimiento y los objetivos operativos.

Cuando diseñes y administres la estrategia de actualización de tu aplicación, ten en cuenta estos principios fundamentales:

• Usa canales progresivos: Los canales de actualización (como beta, dev o anillos personalizados) te permiten recopilar telemetría y comentarios de forma progresiva. Esto garantiza que las actualizaciones principales se sometan a una verificación rigurosa antes de llegar a la población general en el canal predeterminado.
• Fija para la estabilidad: En entornos empresariales altamente estructurados o basados en el cumplimiento, bloquea los extremos críticos en una pinned_version verificada y exacta para proteger las operaciones de interrupciones inesperadas o interrupciones del flujo de trabajo.
• Reserva los cambios a versiones anteriores para emergencias: Reconoce que el cambio a una versión anterior es una válvula de seguridad correctiva y potente que antes era imposible. Sin embargo, debido a que una reversión activa una reinstalación completa y borra todo el almacenamiento local del cliente (IndexedDB, LocalStorage, cookies), se debe reservar estrictamente para la corrección de seguridad crítica. Para los parches comunes, la estrategia ideal es implementar una actualización secundaria con visión de futuro.
• Comprende las marcas de políticas: Ten en cuenta los cambios administrativos. Si activas allow_downgrades, se detendrán todas las actualizaciones, incluso si no se define una versión fijada de forma activa.
• Establece la integridad byte por byte: Asegúrate de que los números de versión idénticos implementados en diferentes canales se asignen a paquetes idénticos que coincidan con los bytes para evitar estados de aplicación erráticos cuando los clientes realizan la transición entre canales.

Si integras estas funciones directamente en el manifiesto de actualización y el esquema de políticas empresariales, puedes garantizar un flujo de actualización confiable, auditable y seguro que preserve las garantías de alta confianza del ecosistema de apps web aisladas.