Обновления SharedArrayBuffer в Android Chrome 88 и Desktop Chrome 92

Джейк Арчибальд
Эйдзи Китамура

Справедливо сказать, что SharedArrayBuffer пережил некоторые трудности в сети, но все налаживается. Вот что вам нужно знать:

Вкратце

  • SharedArrayBuffer в настоящее время поддерживается в Firefox 79+ и появится в Android Chrome 88. Однако он доступен только для страниц, изолированных от перекрестного происхождения .
  • SharedArrayBuffer в настоящее время доступен в настольном Chrome, но начиная с Chrome 92 он будет ограничен изолированными страницами из разных источников. Если вы не думаете, что сможете внести это изменение вовремя, вы можете зарегистрироваться для участия в пробной версии Origin , чтобы сохранить текущее поведение как минимум до Chrome 113.
  • Если вы намерены включить изоляцию между источниками, чтобы продолжать использовать SharedArrayBuffer оцените влияние, которое это окажет на другие элементы перекрестного происхождения на вашем веб-сайте, такие как места размещения рекламы. Проверьте, используется ли SharedArrayBuffer каким-либо из ваших сторонних ресурсов, чтобы понять влияние и рекомендации.

Обзор изоляции между источниками

Вы можете сделать страницу перекрестной изолированной , предоставив ей следующие заголовки:

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

Как только вы это сделаете, ваша страница не сможет загружать контент из разных источников, если только ресурс явно не разрешит это через заголовок Cross-Origin-Resource-Policy или заголовки CORS ( Access-Control-Allow-* и т. д.).

Также имеется API для создания отчетов , поэтому вы можете собирать данные о запросах, которые не удалось выполнить в результате применения Cross-Origin-Embedder-Policy и Cross-Origin-Opener-Policy .

Если вы не думаете, что сможете вовремя внести эти изменения в Chrome 92, вы можете зарегистрироваться для получения пробной версии Origin , чтобы сохранить текущее поведение Chrome для настольных компьютеров как минимум до Chrome 113.

Ознакомьтесь с разделом «Дополнительная литература» внизу этой страницы, чтобы получить дополнительные рекомендации и информацию об изоляции между источниками.

Как мы сюда попали?

SharedArrayBuffer появился в Chrome 60 (это июль 2017 года, для тех из вас, кто думает о времени в датах, а не в версиях Chrome), и все было великолепно. На 6 месяцев.

В январе 2018 года уязвимость была обнаружена в некоторых популярных процессорах. Подробности смотрите в объявлении , но по сути это означало, что код мог использовать таймеры с высоким разрешением для чтения памяти, к которой у него не должно быть доступа.

Это было проблемой для нас, производителей браузеров, поскольку мы хотим разрешить сайтам выполнять код в форме JavaScript и WASM, но строго контролировать объем памяти, к которой этот код может получить доступ. Если вы зайдете на мой сайт, я не смогу ничего прочитать с сайта интернет-банкинга, который вы также открыли. На самом деле, я даже не должен знать, что у вас открыт сайт интернет-банкинга. Это основы веб-безопасности.

Чтобы смягчить это, мы уменьшили разрешение наших таймеров с высоким разрешением, таких как performance.now() . Однако вы можете создать таймер с высоким разрешением, используя SharedArrayBuffer изменяя память в тесном цикле в рабочем процессе и считывая ее обратно в другом потоке. Это невозможно было эффективно смягчить без серьезного воздействия на код с благими намерениями, поэтому SharedArrayBuffer был полностью отключен.

Общее решение заключается в том, чтобы гарантировать, что системный процесс веб-страницы не содержит конфиденциальных данных из других источников. Chrome с самого начала инвестировал в многопроцессную архитектуру ( помните комикс? ), но все же были случаи, когда данные с нескольких сайтов могли попасть в один и тот же процесс:

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

Эти API имеют «устаревшее» поведение, которое позволяет использовать контент из других источников без согласия другого источника. Эти запросы выполняются с использованием файлов cookie другого источника, поэтому это полный запрос для входа в систему. В настоящее время новые API требуют, чтобы другой источник согласился на использование CORS .

Мы обошли эти устаревшие API, предотвратив попадание содержимого в процесс веб-страницы, если оно выглядело «неправильным», и назвали это блокировкой чтения из разных источников . Итак, в приведенных выше случаях мы не разрешим JSON войти в процесс, поскольку это недопустимый формат ни для одного из этих API. То есть, кроме iframe. Для iframe мы помещаем контент в другой процесс.

Приняв эти меры по снижению риска, мы вновь представили SharedArrayBuffer в Chrome 68 (июль 2018 г.), но только на настольном компьютере. Дополнительные требования к процессу означали, что мы не могли сделать то же самое на мобильных устройствах. Также было отмечено, что решение Chrome было неполным, поскольку мы блокировали только «неправильные» форматы данных, тогда как возможно (хотя и необычно), что действительные CSS/JS/изображения по угадываемым URL-адресам могут содержать личные данные.

Специалисты по веб-стандартам собрались вместе, чтобы разработать более полное кроссбраузерное решение. Решение заключалось в том, чтобы дать страницам возможность сказать: «Настоящим я отказываюсь от возможности включать в этот процесс контент другого происхождения без их согласия». Это объявление выполняется через заголовки COOP и COEP, обслуживаемые вместе со страницей. Браузер обеспечивает это, и взамен страница получает доступ к SharedArrayBuffer и другим API с аналогичными возможностями. Другие источники могут согласиться на встраивание контента через Cross-Origin-Resource-Policy или CORS .

Firefox был первым, кто выпустил SharedArrayBuffer с этим ограничением в версии 79 (июль 2020 г.).

Затем, в январе 2021 года, я написал эту статью, и вы ее прочитали. Привет.

И вот где мы находимся сейчас. Chrome 88 возвращает SharedArrayBuffer в Android для страниц, изолированных между источниками, а Chrome 92 предъявляет те же требования к настольным компьютерам, как для обеспечения согласованности, так и для достижения полной изоляции между источниками.

Отложенное изменение настольного Chrome

Это временное исключение в форме «пробной версии источника», которое дает людям больше времени для реализации изолированных страниц из разных источников. Он включает SharedArrayBuffer , не требуя изоляции страницы от разных источников. Срок действия исключения истекает в Chrome 113 и применяется только к Chrome для настольных компьютеров.

  1. Запросите токен для вашего происхождения.
  2. Добавьте токен на свои страницы. Есть два способа сделать это:
    • Добавьте тег <meta> origin-trial в заголовок каждой страницы. Например, это может выглядеть примерно так:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Если вы можете настроить свой сервер, вы также можете добавить токен, используя HTTP-заголовок Origin-Trial . Результирующий заголовок ответа должен выглядеть примерно так:
      Origin-Trial: TOKEN_GOES_HERE

Дальнейшее чтение

Фотография на баннере Дэниела Грегуара на Unsplash