Atualizações de SharedArrayBuffer no Chrome 88 para Android e Chrome 92 para computador

Jake Archibald
Jake Archibald
X Página inicial
Eiji Kitamura

Pode-se dizer que o SharedArrayBuffer teve um destino um pouco difícil na Web, mas as coisas estão se acalmando. Veja o que é necessário saber:

Em resumo

  • No momento, o SharedArrayBuffer é compatível com o Firefox 79 e versões mais recentes e será lançado no Android Chrome 88. No entanto, ele só está disponível para páginas com isolamento de origem cruzada.
  • No momento, o SharedArrayBuffer está disponível no Chrome para computador, mas no Chrome 92 ele será limitado a páginas isoladas de origem cruzada. Se você acha que não pode fazer essa mudança a tempo, inscreva-se em um teste de origem para manter o comportamento atual até pelo menos o Chrome 113.
  • Se você pretende ativar o isolamento de origem cruzada para continuar usando SharedArrayBuffer, avalie o impacto que isso terá em outros elementos de origem cruzada no seu site, como posicionamentos de anúncios. Confira se SharedArrayBuffer é usado por algum dos seus recursos de terceiros para entender o impacto e as orientações.

Visão geral do isolamento de origem cruzada

Você pode tornar uma página isolada de origem cruzada veiculando a página com estes cabeçalhos:

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

Depois disso, sua página não poderá carregar conteúdo de origem cruzada, a menos que o recurso permita explicitamente com um cabeçalho Cross-Origin-Resource-Policy ou cabeçalhos de CORS (Access-Control-Allow-* e assim por diante).

Há também uma API Reporting para coletar dados sobre solicitações que falharam como resultado de Cross-Origin-Embedder-Policy e Cross-Origin-Opener-Policy.

Se você acha que não vai conseguir fazer essas mudanças a tempo para o Chrome 92, faça um teste de origem para manter o comportamento atual do Chrome para computador até pelo menos o Chrome 113.

Confira a seção Leitura adicional na parte inferior desta página para mais orientações e informações sobre o isolamento de origem cruzada.

Como chegamos aqui?

O SharedArrayBuffer chegou ao Chrome 60 (em julho de 2017, para quem pensa em tempo em datas em vez de em versões do Chrome), e tudo foi ótimo. Por 6 meses.

Em janeiro de 2018, uma vulnerabilidade foi revelada em algumas CPUs populares. Consulte o anúncio para conhecer todos os detalhes, mas isso significava que o código poderia usar timers de alta resolução para ler a memória à qual não deveria ter acesso.

Isso foi um problema para nós, fornecedores de navegadores, porque queremos permitir que os sites executem códigos na forma de JavaScript e WASM, mas controlem estritamente a memória que esse código pode acessar. Se você acessar meu site, não conseguirei ler nada do site do internet banking que você também tiver aberto. Na verdade, eu nem deveria saber que você está com seu site de banco na Internet aberto. Esses são os fundamentos da segurança na Web.

Para atenuar isso, reduzimos a resolução dos nossos timers de alta resolução, como performance.now(). No entanto, é possível criar um timer de alta resolução usando SharedArrayBuffer, modificando a memória em um loop restrito em um worker e lendo-o de volta em outra linha de execução. Isso não poderia ser atenuado de forma eficaz sem impactar fortemente o código bem-intencionado, então o SharedArrayBuffer foi totalmente desativado.

Uma mitigação geral é garantir que o processo do sistema de uma página da Web não contenha dados sensíveis de outros lugares. O Chrome investiu em uma arquitetura de vários processos desde o início (lembre-se da história em quadrinhos?), mas ainda havia casos em que dados de vários sites podiam acabar no mesmo processo:

<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… -->

Essas APIs têm um comportamento "legado" que permite que conteúdo de outras origens seja usado sem a permissão da outra origem. Essas solicitações são feitas com os cookies de outra origem, portanto, é uma solicitação completa "conectada". Atualmente, as novas APIs exigem que a outra origem aceite o uso do CORS.

Contornamos essas APIs legadas para evitar que conteúdo entrasse no processo da página da Web caso pareça estar "incorreto", e chamamos isso de bloqueio de leitura de origem cruzada. Nos casos acima, não permitimos que JSON entre no processo, já que não é um formato válido para nenhuma dessas APIs. Ou seja, exceto iframes. Para iframes, colocamos o conteúdo em um processo diferente.

Com essas mitigações em vigor, lançamos novamente o SharedArrayBuffer no Chrome 68 (julho de 2018), mas apenas no computador. Os requisitos de processo extras significavam que não poderíamos fazer o mesmo em dispositivos móveis. Também notamos que a solução do Chrome estava incompleta, já que estávamos bloqueando apenas formatos de dados "incorretos", mas é possível (embora incomum) que CSS/JS/imagens válidas em URLs adivinhados possam conter dados particulares.

As pessoas que trabalham com os padrões da Web se uniram para criar uma solução mais completa para navegadores. A solução era oferecer às páginas uma maneira de dizer "Por meio deste documento, renuncio à minha capacidade de trazer conteúdo de outra origem para esse processo sem sua permissão". Essa declaração é feita pelos cabeçalhos COOP e COEP veiculados com a página. O navegador aplica isso e, em troca, a página recebe acesso a SharedArrayBuffer e outras APIs com poderes semelhantes. Outras origens podem ativar a incorporação de conteúdo por meio de Cross-Origin-Resource-Policy ou CORS.

O Firefox foi o primeiro a enviar o SharedArrayBuffer com essa restrição, na versão 79 (julho de 2020).

Depois, em janeiro de 2021, escrevi este artigo e você leu. Olá!

E é aqui que estamos agora. O Chrome 88 leva SharedArrayBuffer de volta ao Android para páginas com isolamento de origem cruzada, e o Chrome 92 traz os mesmos requisitos para computadores, tanto para consistência quanto para atingir o isolamento total de origem cruzada.

Adiar a mudança do Chrome para computador

Essa é uma exceção temporária na forma de um "teste de origem" que dá às pessoas mais tempo para implementar páginas isoladas de origem cruzada. Ela ativa o SharedArrayBuffer sem exigir que a página tenha isolamento de origem cruzada. A exceção expira no Chrome 113 e se aplica apenas ao Chrome para computador.

  1. Solicite um token para sua origem.
  2. Adicione o token às suas páginas. Há duas maneiras de fazer isso:
    • Adicione uma tag origin-trial <meta> ao cabeçalho de cada página. Por exemplo, isso pode ficar assim:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Se for possível configurar o servidor, também será possível adicionar o token usando um cabeçalho HTTP Origin-Trial. O cabeçalho de resposta resultante precisa ser semelhante a este:
      Origin-Trial: TOKEN_GOES_HERE

Leia mais

Foto do banner de Daniel Gregoire no Unsplash