Actualizaciones de SharedArrayBuffer en Chrome 88 para Android y Chrome 92 para computadoras de escritorio

Jake Archibald
Eiji Kitamura

Es justo decir que SharedArrayBuffer tuvo un aterrizaje un poco difícil en la Web, pero todo se está calmando. Tenga en cuenta lo siguiente:

En resumen

  • Actualmente, SharedArrayBuffer es compatible con Firefox 79 y versiones posteriores, y llegará a Chrome para Android 88. Sin embargo, solo está disponible para las páginas que están aisladas de origen cruzado.
  • Actualmente, SharedArrayBuffer está disponible en Chrome para computadoras, pero a partir de Chrome 92, se limitará a las páginas aisladas de origen cruzado. Si crees que no puedes realizar este cambio a tiempo, puedes registrarte para obtener una prueba de origen para conservar el comportamiento actual hasta, al menos, Chrome 113.
  • Si deseas habilitar el aislamiento entre orígenes para seguir usando SharedArrayBuffer, evalúa el impacto que esto tendrá en otros elementos entre orígenes de tu sitio web, como las posiciones de anuncios. Comprueba si alguno de tus recursos de terceros usa SharedArrayBuffer para comprender el impacto y la orientación.

Descripción general del aislamiento de origen cruzado

Para que una página sea aislada de varios orígenes, publícala con estos encabezados:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Una vez que lo hagas, tu página no podrá cargar contenido de origen cruzado, a menos que el recurso lo permita de forma explícita a través de un encabezado Cross-Origin-Resource-Policy o encabezados CORS (Access-Control-Allow-*, etcétera).

También hay una API de informes para que puedas recopilar datos sobre las solicitudes que fallaron como resultado de Cross-Origin-Embedder-Policy y Cross-Origin-Opener-Policy.

Si crees que no puedes realizar estos cambios a tiempo para Chrome 92, puedes registrarte para una prueba de origen para conservar el comportamiento actual de Chrome para computadoras de escritorio hasta, al menos, Chrome 113.

Consulta la sección Lecturas complementarias en la parte inferior de esta página para obtener más orientación e información sobre el aislamiento entre orígenes.

¿Cómo llegamos hasta aquí?

SharedArrayBuffer llegó a Chrome 60 (es decir, julio de 2017, para quienes piensan en el tiempo en fechas en lugar de versiones de Chrome) y todo fue excelente. Por 6 meses.

En enero de 2018, se reveló una vulnerabilidad en algunas CPUs populares. Consulta el anuncio para obtener todos los detalles, pero, en esencia, esto significaba que el código podía usar temporizadores de alta resolución para leer memoria a la que no debería tener acceso.

Esto fue un problema para nosotros, los proveedores de navegadores, ya que queremos permitir que los sitios ejecuten código en forma de JavaScript y WASM, pero controlamos estrictamente la memoria a la que puede acceder este código. Si llegas a mi sitio web, no debería poder leer nada del sitio de banca en línea que también tienes abierto. De hecho, ni siquiera debería saber que tienes abierto tu sitio de banca en línea. Estos son los aspectos básicos de la seguridad web.

Para mitigar esto, reducimos la resolución de nuestros temporizadores de alta resolución, como performance.now(). Sin embargo, puedes create un temporizador de alta resolución con SharedArrayBuffer si modificas la memoria en un bucle ajustado en un trabajador y lo vuelves a leer en otro subproceso. Esto no se podía mitigar de manera eficaz sin afectar en gran medida el código con buenas intenciones, por lo que se inhabilitó SharedArrayBuffer por completo.

Una mitigación general es garantizar que el proceso del sistema de una página web no contenga datos sensibles de otro lugar. Chrome invirtió en una arquitectura de varios procesos desde el principio (¿recuerdas el cómic?), pero aún había casos en los que los datos de varios sitios podían terminar en el mismo proceso:

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

Estas APIs tienen un comportamiento "heredado" que permite que se use contenido de otros orígenes sin la habilitación del otro origen. Estas solicitudes se realizan con las cookies del otro origen, por lo que es una solicitud completa de "acceso realizado". En la actualidad, las APIs nuevas requieren que el otro origen acepte el uso de CORS.

Para evitar estas APIs heredadas, evitamos que el contenido ingresara al proceso de la página web si se veía "incorrecto" y lo llamamos bloqueo de lectura entre orígenes. Por lo tanto, en los casos anteriores, no permitiríamos que JSON ingrese al proceso, ya que no es un formato válido para ninguna de esas APIs. Es decir, excepto los iframes. En el caso de los iframes, colocamos el contenido en un proceso diferente.

Con estas mitigaciones implementadas, volvimos a introducir SharedArrayBuffer en Chrome 68 (julio de 2018), pero solo en computadoras. Los requisitos de proceso adicionales significaron que no pudimos hacer lo mismo en dispositivos móviles. También se señaló que la solución de Chrome estaba incompleta, ya que solo bloqueábamos los formatos de datos "incorrectos", mientras que es posible (aunque inusual) que imágenes, CSS o JS válidos en URLs adivinables puedan contener datos privados.

Los especialistas en estándares web se reunieron para crear una solución más completa para varios navegadores. La solución fue darles a las páginas una forma de decir "Por el presente, renuncio a mi capacidad de incorporar contenido de otro origen en este proceso sin su aceptación". Esta declaración se realiza a través de los encabezados COOP y COEP que se entregan con la página. El navegador aplica esa restricción y, a cambio, la página obtiene acceso a SharedArrayBuffer y a otras APIs con poderes similares. Otros orígenes pueden habilitar la incorporación de contenido a través de Cross-Origin-Resource-Policy o CORS.

Firefox fue el primero en enviar SharedArrayBuffer con esta restricción, en la versión 79 (julio de 2020).

Luego, en enero de 2021, escribí este artículo y tú lo leíste. Hola.

Y ahí es donde estamos ahora. Chrome 88 vuelve a implementar SharedArrayBuffer en Android para las páginas que están aisladas de origen cruzado, y Chrome 92 trae los mismos requisitos a las computadoras de escritorio, tanto por coherencia como para lograr un aislamiento total de origen cruzado.

Cómo retrasar el cambio de Chrome para computadoras

Esta es una excepción temporal en forma de una "prueba de origen" que les da a los usuarios más tiempo para implementar páginas aisladas de origen cruzado. Habilita SharedArrayBuffer sin requerir que la página esté aislada de origen cruzado. La excepción vence en Chrome 113 y solo se aplica a Chrome para computadoras.

  1. Solicita un token para tu origen.
  2. Agrega el token a tus páginas. Existen dos maneras de hacerlo:
    • Agrega una etiqueta <meta> origin-trial al encabezado de cada página. Por ejemplo, puede verse de la siguiente manera:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Si puedes configurar tu servidor, también puedes agregar el token mediante un encabezado HTTP Origin-Trial. El encabezado de respuesta resultante debería ser similar al siguiente:
      Origin-Trial: TOKEN_GOES_HERE

Lecturas adicionales

Foto del banner de Daniel Gregoire en Unsplash