Administración de versiones

Magdalena Skarbińska

Demián Renzulli

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

Para cumplir con estos requisitos, Chrome proporciona capacidades integrales de administración de versiones para las IWA, incluidos los canales de actualización, la fijación de versiones y la degradación de versiones. 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 el administrador gestiona la IWA o si el usuario la instala directamente:

• IWA administradas: Las funciones administrativas (incluidas las de fijación y reversión basadas en políticas) están disponibles a partir de Chrome 133.
• IWA no administradas (instaladas por el usuario): Las funciones para el usuario (como la selección manual de canales) están disponibles a partir de Chrome 150.

Compatibilidad de tipo de sesión

Todas las funciones de administración de versiones, incluidos los canales de actualización y la fijación de versiones, son totalmente compatibles con todos los tipos de sesiones de ChromeOS. Esto incluye lo siguiente:

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

Nota: Para garantizar que las actualizaciones se reconozcan correctamente, las cadenas de versión deben seguir el formato válido de IWA. 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 la fijación y la segmentación por canal se admiten de forma universal en todos los tipos de sesión, es posible que las versiones anteriores se restrinjan inicialmente a los verificadores 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 diferentes públicos de implementación y prueba. Para configurar los 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 fijas de la plataforma (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úsculas (que pueden incluir guiones o guiones bajos, pero no espacios). Si una entrada de versión omite por completo el campo channels, Chrome establece de forma implícita su disponibilidad en el canal "default". 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 que no coincida dará como resultado que no se identifique ninguna versión apta, lo que detendrá 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. Estas son algunas consideraciones que debes 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.
• Resguardo predeterminado: Si una entrada de versión omite por completo el campo channels, Chrome supone que la versión pertenece exclusivamente al canal default.
• Coincidencia exacta de cadenas: Los nombres de los 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 de destino, 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 de segmentación:

• default: 0.2.0,0.4.0 (que carece de un canal explícito y se establece de forma predeterminada en default)
• 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 alto cumplimiento o alta estabilidad, los administradores deben asegurarse de que los dispositivos ejecuten versiones exactas del software fundamental para la empresa. La fijación de versiones permite que los administradores bloqueen una IWA en una versión específica, lo que detiene todas las actualizaciones en segundo plano posteriores. Esto proporciona a las empresas una forma altamente confiable de mantener configuraciones estables y cumplir con las estrictas reglamentaciones internas o de la industria.

Para congelar una app web aislada (IWA) en una compilación de lanzamiento específica, los administradores empresariales pueden configurar la propiedad pinned_version dentro de la política IsolatedWebAppInstallForceList. Esta función se administra principalmente a través de los controles interactivos de la IU 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 de implementar estos valores de política directamente con configuraciones JSON sin procesar. Una vez que el administrador orienta 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

• Reanuda las 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 configuras pinned_version en una versión anterior a la instalada actualmente, no se activará una reversión, a menos que allow_downgrades esté habilitado de forma explícita.
• Objetivos de fijación no disponibles: Si falta el pinned_version configurado en el canal de actualización designado o es anterior a la versión instalada (con las versiones anteriores inhabilitadas), Chrome conservará la versión instalada actualmente y bloqueará las actualizaciones posteriores.
• Implementaciones nuevas: Si aún no se instaló una IWA en un dispositivo administrado y no se puede recuperar el parámetro pinned_version especificado o no se encuentra en el manifiesto de actualización, la IWA no se instalará.

Cambio a una versión anterior

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

La actualización a una versión anterior solo es posible si se cumplen ambas condiciones de la política que se indican a continuación:

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

Cómo funcionan las disminuciones de categoría

• Mecanismo de activación: Las reversiones se procesan durante el ciclo regular de verificación de actualizaciones (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 (incluidas IndexedDB, LocalStorage, Cache y Cookies). Para proteger los datos del usuario, reserva las 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 con parches en lugar de revertir.

Importante: Inmovilización inmediata de la actualización: Simplemente activar allow_downgrades como verdadero inmoviliza de forma instantánea todas las actualizaciones estándar, incluso si no defines un pinned_version. Una vez habilitada, el navegador bloquea las actualizaciones estándar hasta que asignes de forma explícita una pinned_version más alta o vuelvas a cambiar allow_downgrades a falso.

Lógica de transición de canales

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

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

• Si se permite cambiar 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 cambiar a una versión anterior, no se realizará ningún cambio. El dispositivo permanecerá en la versión superior instalada actualmente y solo se actualizará cuando haya una versión más reciente disponible en el canal seleccionado.

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

• Sin cambios: Si el canal seleccionado recientemente apunta a un número de versión igual al que está instalado, 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 byte por byte. Implementar diferentes bases de código con la misma cadena de versión en todos los canales puede generar estados de aplicación inesperados y erráticos.

Configuración de la política administrativa

Los controles de versiones empresariales se aplican con la plataforma centralizada de la Consola del administrador de Google a través del esquema de políticas 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 se pueden implementar con parámetros de configuración de políticas en formato JSON sin procesar.
En el siguiente ejemplo de configuración de la política administrativa, se muestran los canales de actualización, la fijación de versiones y las 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 (cadena, 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 se establece como verdadero y se vincula con un pinned_version válido y anterior, Chrome activará una reinstalación de una versión anterior. Advertencia: Si configuras este parámetro como verdadero, se bloquearán todas las actualizaciones de reenvío estándar, incluso si se omite el campo pinned_version.

IWA no administradas (instaladas por el usuario) (desde la versión 150)

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

Paquete de instalación ──► El usuario selecciona el canal ──► Se realizan 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 de la app (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á congelada 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 canal 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 en el momento de 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 posterior a la instalada en ese canal de destino.
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 las implementaciones administradas

Para los administradores que gestionan dispositivos a través de la Consola del administrador de Chrome Enterprise o configuran políticas directamente:

1. Navega al panel Detalles de la app en la configuración de la organización.
2. Aplica propiedades de configuración para probar la fijación y los destinos de los 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 empoderar a los desarrolladores y, al mismo tiempo, mantener una previsibilidad y un control estrictos sobre los comportamientos del ciclo de vida de las aplicaciones. Aprovechando 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 estándares de cumplimiento estrictos 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 importantes se sometan a una verificación rigurosa antes de llegar a la población general en el canal predeterminado.
• Fija para obtener estabilidad: En entornos empresariales altamente estructurados o impulsados por el cumplimiento, bloquea los extremos críticos en una pinned_version exacta y verificada para proteger las operaciones de interrupciones inesperadas o interrupciones del flujo de trabajo.
• Reserva las versiones anteriores para emergencias: Reconoce que la reversión de versiones 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), debe reservarse estrictamente para la corrección de seguridad crítica. Para los parches comunes, implementar una actualización menor con visión de futuro siempre es la estrategia ideal.
• Comprende los indicadores de políticas: Ten en cuenta los interruptores administrativos; activar allow_downgrades detendrá todas las actualizaciones futuras, incluso si no se define un pin 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 byte por byte para evitar estados de aplicación erráticos cuando los clientes realicen la transición entre canales.

Si integras estas funciones directamente en tu manifiesto de actualización y en el esquema de la política empresarial, 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.