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

Jake Archibald
Eiji Kitamura

Se podría decir que SharedArrayBuffer tuvo un aterrizaje un poco difícil en la Web, pero las cosas se están estabilizando. Tenga en cuenta lo siguiente:

En resumen

  • Actualmente, SharedArrayBuffer es compatible con Firefox 79 y versiones posteriores, y estará disponible en Chrome 88 para Android. 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 una prueba de origen y conservar el comportamiento actual hasta, al menos, Chrome 113.
  • Si planeas habilitar el aislamiento de origen cruzado para seguir usando SharedArrayBuffer, evalúa el impacto que tendrá en otros elementos de origen cruzado de tu sitio web, como las posiciones de anuncios. Comprueba si alguno de tus recursos de terceros utiliza SharedArrayBuffer para comprender el impacto y obtener orientación.

Descripción general del aislamiento de origen cruzado

Puedes hacer que una página esté aislada del origen cruzado si la publicas con los siguientes 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 explícitamente a través de un encabezado Cross-Origin-Resource-Policy o encabezados CORS (Access-Control-Allow-* y así sucesivamente).

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

Si crees que no podrás realizar estos cambios a tiempo para Chrome 92, puedes registrarte para una prueba de origen y conservar el comportamiento actual de Chrome para computadoras hasta Chrome 113, como mínimo.

Consulta la sección Lecturas adicionales que se encuentra en la parte inferior de esta página para obtener más orientación e información sobre el aislamiento de origen cruzado.

¿Cómo llegamos hasta aquí?

SharedArrayBuffer llegó en Chrome 60 (julio de 2017, para quienes piensan en el tiempo en fechas en lugar de versiones de Chrome), y todo fue genial. Durante 6 meses.

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

Esto era 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 controlar 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 el sitio de banca por Internet. Estos son los conceptos básicos de la seguridad web.

Para mitigar este problema, redujimos la resolución de nuestros temporizadores de alta resolución, como performance.now(). Sin embargo, puedes crear un temporizador de alta resolución con SharedArrayBuffer si modificas la memoria en un bucle ajustado en un trabajador y la lees en otro subproceso. Esto no se pudo mitigar de manera eficaz sin afectar en gran medida el código bien intencionado, por lo que SharedArrayBuffer se inhabilitó por completo.

Una mitigación general es garantizar que el proceso del sistema de una página web no contenga datos sensibles de otros lugares. Desde el principio, Chrome invirtió en una arquitectura de varios procesos (¿recuerdas la historieta?), 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 usar contenido de otros orígenes sin el consentimiento de estos. Estas solicitudes se realizan con las cookies del otro origen, por lo que son solicitudes completas de "acceso". Actualmente, las APIs nuevas requieren que el otro origen habilite CORS.

Para evitar el uso de estas APIs heredadas, impedimos que el contenido ingresara en el proceso de la página web si parecía "incorrecto", y lo denominamos bloqueo de lectura de origen cruzado. Por lo tanto, en los casos anteriores, no permitiríamos que JSON ingresara en el proceso, ya que no es un formato válido para ninguna de esas APIs. Es decir, excepto los iframes. En el caso de los elementos iframe, 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 adicionales del proceso significaron que no pudimos hacer lo mismo en dispositivos móviles. También se observó que la solución de Chrome era incompleta, ya que solo bloqueábamos los formatos de datos "incorrectos", mientras que es posible (aunque inusual) que los archivos CSS/JS/imágenes válidos en URLs adivinables contengan datos privados.

Los expertos en estándares web se reunieron para crear una solución más completa para todos los navegadores. La solución fue darles a las páginas una forma de decir "Por medio de este documento, renuncio a mi capacidad de incorporar contenido de otros orígenes en este proceso sin su consentimiento". 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 regla y, a cambio, la página obtiene acceso a SharedArrayBuffer y a otras APIs con capacidades similares. Otros orígenes pueden habilitar la incorporación de contenido a través de Cross-Origin-Resource-Policy o CORS.

Firefox fue el primer navegador en lanzar 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 trae de vuelta SharedArrayBuffer a Android para las páginas que están aisladas de origen cruzado, y Chrome 92 trae los mismos requisitos a las computadoras, tanto por coherencia como para lograr el aislamiento total de origen cruzado.

Retraso del cambio en Chrome para computadoras

Esta es una excepción temporal en forma de "prueba de origen" que les brinda a las personas 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 origin-trial <meta> al encabezado de cada página. Por ejemplo, podría verse así:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Si puedes configurar tu servidor, también puedes agregar el token con un encabezado HTTP Origin-Trial. El encabezado de respuesta resultante debería verse de la siguiente manera:
      Origin-Trial: TOKEN_GOES_HERE

Lecturas adicionales

Foto del banner de Daniel Gregoire en Unsplash