Se puede decir que SharedArrayBuffer tuvo un aterrizaje rápido en la Web, pero las cosas se están quedando sin problemas. Tenga en cuenta lo siguiente:
Resumen
- Por el momento,
SharedArrayBufferes compatible con Firefox 79 y versiones posteriores, y llegará a Chrome 88 para Android. Sin embargo, solo está disponible para páginas que están aisladas en orígenes cruzados. - Actualmente,
SharedArrayBufferestá disponible en Chrome para computadoras de escritorio, pero a partir de Chrome 92 se limitará a 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 deseas habilitar el aislamiento de origen cruzado para seguir usando
SharedArrayBuffer, evalúa el impacto que esto tendrá en otros elementos de origen cruzado en tu sitio web, como las posiciones de anuncios. Verifica si alguno de tus recursos de terceros usaSharedArrayBufferpara comprender el impacto y la orientación.
Descripción general del aislamiento de origen cruzado
Para que una página esté aislada de origen cruzado, publica la página 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 mediante un encabezado Cross-Origin-Resource-Policy o encabezados CORS (Access-Control-Allow-*, etcétera).
También existe 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 puedes realizar estos cambios a tiempo para Chrome 92, puedes registrarte para una prueba de origen y conservar el comportamiento actual de la versión para computadoras de escritorio de Chrome hasta al menos Chrome 113.
Consulta la sección Lecturas adicionales al final de esta página para obtener más información y orientación sobre el aislamiento de origen cruzado.
¿Cómo llegamos hasta aquí?
SharedArrayBuffer llegó a Chrome 60 (julio de 2017, para aquellos de ustedes que
piensan en las fechas en lugar de en las versiones de Chrome) y todo estuvo fantástico.
Durante 6 meses.
En enero de 2018, se reveló una vulnerabilidad en algunas CPUs populares. Consulta el anuncio para obtener todos los detalles, pero esencialmente significa que el código podía usar cronómetros de alta resolución para leer la memoria a la que no debería tener acceso.
Este era un problema para los proveedores de navegadores, ya que queremos permitir que los sitios ejecuten código en forma de JavaScript y WASM, pero controlen 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 tengas 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 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 cerrado en un trabajador y lo vuelves a leer en otro subproceso. Esto no se pudo mitigar de manera eficaz sin afectar significativamente el código con buenas intenciones, por lo que SharedArrayBuffer se inhabilitó por completo.
Una mitigación general consiste en garantizar que el proceso del sistema de una página web no contenga datos sensibles de otro lugar. Chrome invirtió en una arquitectura multiproceso 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 usar contenido de otros orígenes sin habilitar el desde otro origen. Estas solicitudes se realizan con las cookies del otro origen, por lo que es una solicitud completa para "acceder". Actualmente, las APIs nuevas requieren que el otro origen se habilite para usar CORS.
Para solucionar el problema de 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 de origen cruzado. 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. Para iframes, colocamos el contenido en un proceso diferente.
Con estas mitigaciones implementadas, volvimos a presentar SharedArrayBuffer en Chrome 68 (julio de 2018), pero solo en computadoras de escritorio. Debido a los requisitos adicionales del proceso, no podíamos hacer lo mismo en dispositivos móviles. También se señaló que la solución de Chrome estaba incompleta, ya que solo bloqueamos los formatos de datos "incorrectos", mientras que es posible (aunque inusual) que las imágenes de CSS/JS/imágenes válidas en URLs puedan adivinarse.
Los usuarios de estándares de la Web se reunieron para idear una solución más completa para varios navegadores. La solución fue dar a las páginas una forma de decir: "Por la presente, renuncio a mi capacidad de incorporar contenido de otro origen en este proceso sin que ellos lo acepten".
Esta declaración se realiza a través de los encabezados COOP y COEP que se entregan con la página. El navegador exige que la página obtenga acceso a SharedArrayBuffer y a otras APIs con capacidades similares a cambio de ella. 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 lo leíste. Hola.
Y ahí es donde estamos ahora. Chrome 88 vuelve a usar SharedArrayBuffer en Android para las páginas aisladas de origen cruzado, y Chrome 92 ofrece los mismos requisitos para las computadoras de escritorio, tanto para mantener la coherencia como para lograr el aislamiento total de origen cruzado.
Cómo retrasar el cambio de Chrome para computadoras de escritorio
Esta es una excepción temporal en forma de "prueba de origen" que les brinda a los usuarios más tiempo para implementar páginas aisladas de origen cruzado. Habilita SharedArrayBuffer sin necesidad de que la página esté aislada de origen cruzado. La excepción vence en Chrome 113 y solo se aplica a las versiones de Chrome para computadoras de escritorio.
- Solicita un token para tu origen.
- 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 tener el siguiente aspecto:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - Si puedes configurar el 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
- Agrega una etiqueta
Lecturas adicionales
- Guía para habilitar el aislamiento de origen cruzado
- Cómo aislar los orígenes cruzados en tus páginas
- Por qué es necesario el aislamiento de origen cruzado
Foto del banner de Daniel Gregoire en Unsplash