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 acierto un poco en la en la Web, pero las cosas se están estabilizando. Tenga en cuenta lo siguiente:

Resumen

  • Por el momento, SharedArrayBuffer es compatible con Firefox 79 y versiones posteriores, y pronto se lanzará en Android. Chrome 88. Sin embargo, solo está disponible para las páginas que están aisladas por orígenes cruzados.
  • Actualmente, SharedArrayBuffer está disponible en Chrome para computadoras, pero desde Chrome 92 se limitará a páginas aisladas de origen cruzado. Si crees que no puedes hacer este cambio a tiempo, puedes registrarte en una prueba de origen para conservar el comportamiento actual hasta al menos Chrome 113.
  • Si deseas habilitar el aislamiento de origen cruzado para seguir usando SharedArrayBuffer evaluar el impacto que esto tendrá en otros orígenes cruzados en tu sitio web, como la posición de anuncios. Comprueba si SharedArrayBuffer se usa en tus recursos externos para comprender el impacto orientación.

Descripción general del aislamiento de origen cruzado

Para aislar el origen cruzado una página, 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 permite explícitamente mediante un Cross-Origin-Resource-Policy encabezado o encabezados CORS (Access-Control-Allow-*, etcétera).

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

Si cree que no puede hacer estos cambios a tiempo para Chrome 92, puede registrarse en una prueba de origen para conservar la versión actual de Chrome para computadoras de escritorio comportamiento 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 (en julio de 2017, para los usuarios que piensa en el tiempo en las fechas en lugar de en las versiones de Chrome), y todo salió bien. Durante 6 meses.

En enero de 2018, se reveló una vulnerabilidad en algunas CPU populares. Consulta la anuncio para ver todos los detalles, pero esto quería que el código usara imágenes de alta resolución cronómetros para leer la 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 controlan estrictamente la memoria código puede acceder. Si ingresa a mi sitio web, no debería poder leerlo cualquier elemento del sitio de banca en línea que también tenga abierto. De hecho, no debería incluso saber que tiene abierto su 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 los temporizadores de alta resolución, por ejemplo, como performance.now(). Sin embargo, puedes crear un temporizador de alta resolución usando SharedArrayBuffer a través de la modificación de la memoria en un bucle cerrado en un trabajador y la lectura de nuevo en otro subproceso. Esto no se podría mitigar de manera eficaz sin tenía un gran impacto en el código con buenas intenciones, por lo que se inhabilitó SharedArrayBuffer por completo.

Una mitigación general es asegurarse de que el proceso del sistema de una página web no contenga sensibles de otros lugares. Chrome había invertido en un proceso múltiple arquitectura popular desde el principio (¿recuerdas el cómic?), pero no había casos en los que los datos de varios sitios podrí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 componente "heredado" comportamiento que permite que el contenido de otros orígenes sin la habilitación del otro origen. Estas solicitudes se realizan con el cookies del otro origen, por lo que es un estado de “acceso” completo para cada solicitud. Hoy en día, los nuevos Las APIs requieren que el otro origen se habilite con CORS.

Para solucionar estas APIs heredadas, impedimos que el contenido ingresara al de la página web si parecía "incorrecto" y se lo denominaba bloqueo de lectura de origen cruzado. Por lo tanto, en los casos anteriores, no permitiríamos que JSON ingrese en el proceso, ya que no es un formato válido para cualquiera de esas APIs. Es decir, excepto los iframes. En el caso de los iframes, llevar el contenido a un proceso diferente.

Con estas mitigaciones implementadas, volvimos a incorporar SharedArrayBuffer en Chrome 68 (julio de 2018), pero solo en computadoras. Los requisitos adicionales del proceso implicaban no podría hacer lo mismo en dispositivos móviles. También se observó que la solución de Chrome estaba incompleto, ya que solo estábamos bloqueando el contenido “incorrecto”. formatos de datos, mientras que es posible (aunque inusual) que las imágenes/CSS/JS/imágenes válidas en URLs adivinables puedan contienen datos privados.

estándares de la Web se reunieron para crear una solución más completa para varios navegadores de Google Cloud. La solución era darles a las páginas una forma de decir "Por el presente, renuncio a mi incluir en este proceso contenido de otro origen sin su habilitación". Esta declaración se realiza con los encabezados COOP y COEP si se publica con la página. El navegador exige eso y, a cambio, la página obtiene Acceso a SharedArrayBuffer y otras APIs con potencias 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 versión 79 (julio de 2020).

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

Y ahí es donde estamos ahora. Chrome 88 vuelve a mostrar SharedArrayBuffer en Android para páginas que están aisladas de origen cruzado y Chrome 92 ofrece el mismo a las computadoras de escritorio, tanto para mantener la coherencia como para lograr el origen cruzado total de forma aislada.

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 da a las personas más tiempo para implementar páginas aisladas de origen cruzado. Permite SharedArrayBuffer sin requerir que la página esté aislada de origen cruzado. El la excepción vence en Chrome 113 y la excepción solo se aplica a las versiones de escritorio Chrome.

  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: esto puede ser similar a lo siguiente:
      <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 debe se verán así:
      Origin-Trial: TOKEN_GOES_HERE

Lecturas adicionales

Foto del banner de Daniel Gregoire en Unsplash