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

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

Справедливо будет сказать, что 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 , изменив память в тесном цикле в worker и прочитав ее обратно в другом потоке. Это нельзя было эффективно смягчить без серьезного воздействия на код с благими намерениями, поэтому SharedArrayBuffer был полностью отключен.

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

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

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

С учетом этих мер по смягчению мы повторно представили 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. Добавьте токен на свои страницы. Есть два способа сделать это:
    • Добавьте тег origin-trial в заголовок каждой страницы. Например, это может выглядеть примерно так:
    • Если вы можете настроить свой сервер, вы также можете добавить токен с помощью заголовка HTTP Origin-Trial . Результирующий заголовок ответа должен выглядеть примерно так:
      Origin-Trial: TOKEN_GOES_HERE

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

Фотография баннера от Daniel Gregoire на Unsplash