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

Podemos dizer que SharedArrayBuffer teve uma aterrissagem brusca na na Web, mas as coisas estão se acalmando. Veja o que é necessário saber:

Em resumo

  • SharedArrayBuffer é compatível com o Firefox 79 e versões mais recentes e chegará ao Android Chrome 88. No entanto, só está disponível para páginas com isolamento de origem cruzada.
  • No momento, o SharedArrayBuffer está disponível no Chrome para computadores, mas no Chrome 92 ele será limitado a páginas isoladas de origem cruzada. Se você não acha que for possível fazer essa mudança antes, registre-se em um teste de origem para manter o comportamento atual até que o Chrome 113.
  • Se você pretende ativar o isolamento de origem cruzada para continuar usando SharedArrayBuffer avaliam o impacto disso em outras origens cruzadas elementos do seu site, como posicionamentos de anúncios. Verifique se SharedArrayBuffer é usado por qualquer um de seus recursos de terceiros para entender o impacto e orientação.

Visão geral do isolamento de origem cruzada

Você pode fazer com que uma página seja isolada de origem cruzada exibindo a página com estes cabeçalhos:

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

Depois que você fizer isso, sua página só poderá carregar conteúdo de origem cruzada, a menos que o recurso permitir explicitamente usando um Cross-Origin-Resource-Policy; cabeçalho ou cabeçalhos CORS (Access-Control-Allow-* e assim por diante).

Também há uma API de relatórios, pode 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 poderá fazer essas mudanças a tempo do Chrome 92, poderá registre-se em um teste de origem para manter o Chrome para computador atual até a versão 113 ou mais recente.

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 (julho de 2017, para quem pense no tempo nas datas em vez de nas versões do Chrome), e tudo foi ótimo. Por 6 meses.

Em janeiro de 2018, uma vulnerabilidade foi revelada em algumas CPUs populares. Consulte a aviso para obter detalhes completos, mas isso basicamente significava que o código poderia usar timers para ler a memória a que não deveria ter acesso.

Isso foi um problema para nós, fornecedores de navegador, porque queremos permitir que os sites executem na forma de JavaScript e WASM, mas controlam rigorosamente a memória pelo código do usuário. Se você entrar no meu site, não vou conseguir ler qualquer coisa do site de internet banking que você também tenha aberto. Na verdade, eu não deveria mesmo que você tenha um site de banco na Internet aberto. Esses são os fundamentos a segurança da Web.

Para atenuar isso, reduzimos a resolução de nossos timers de alta resolução, como performance.now(). No entanto, é possível criar um timer de alta resolução usando SharedArrayBuffer ao modificar a memória em um loop restrito em um worker e ler em outra conversa. Isso não poderia ser minimizado de forma eficaz sem afetar muito códigos bem-intencionados, por isso, SharedArrayBuffer foi desativado. completamente.

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 um processo desde o início (se lembra dos quadrinhos?), mas havia ainda casos em que os dados de vários sites podem 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 "legado" que permite que o conteúdo de outras origens seja usado sem a aceitação da outra origem. Essas solicitações são feitas cookies de outra origem, portanto, é uma sessão solicitação. Hoje em dia, as novas As APIs exigem que a outra origem aceite usando CORS:

Contornamos essas APIs antigas impedindo que o conteúdo entrasse nos processo de uma página da Web se ele parecesse "incorreto" e o chamasse de bloqueio de leitura de origem cruzada. Nos casos acima, não permitimos que JSON entrasse no processo, já que não é um formato válido para qualquer uma dessas APIs. Ou seja, exceto iframes. Para iframes, nós ou colocar o conteúdo em um processo diferente.

Com essas mitigações em vigor, reintroduzimos o SharedArrayBuffer no Chrome 68 (julho de 2018), mas apenas em computadores. Com os requisitos de processo extra, não podiam fazer o mesmo em dispositivos móveis. Também observamos que a solução do Chrome estava incompleta, porque estávamos bloqueando apenas os indicadores formatos de dados, enquanto possível (embora incomum) que CSS/JS/imagens válidos em URLs possíveis contêm dados privados.

As pessoas de padrões da web se uniram para criar uma versão mais completa para navegadores diferentes solução. A solução foi dar às páginas uma maneira de dizer: "Por meio deste documento, renuncio a 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 impõe isso e, em troca, a página ganha acesso ao SharedArrayBuffer e a outras APIs com capacidades semelhantes. Outras origens podem ativar a incorporação de conteúdo pelo Cross-Origin-Resource-Policy ou CORS.

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

Então, em janeiro de 2021, escrevi este artigo, e você o leu. Olá.

E é aqui que estamos agora. No Chrome 88, o SharedArrayBuffer volta para Android para páginas com isolamento de origem cruzada, e o Chrome 92 traz os mesmos para computadores, para fins de consistência e para obter o total de conversões isolamento.

Atrasar a alteração 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 permite SharedArrayBuffer sem que a página precise ser isolada de origem cruzada. A expira no Chrome 113, e a exceção só se aplica a Chrome.

  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: será algo parecido com isto:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Se você puder configurar seu servidor, também poderá adicionar o token usando um cabeçalho HTTP Origin-Trial. O cabeçalho de resposta resultante deve semelhante a:
      Origin-Trial: TOKEN_GOES_HERE

Leitura adicional

Foto do banner de Daniel Gregoire no Unsplash