Aktualizacje narzędzia SharedSlateBuffer w Androidzie 88 i komputerowej wersji Chrome 92

Jake Archibald
Jake Archibald
X Strona główna
Eiji Kitamura

Można powiedzieć, że SharedArrayBuffer niezbyt dobrze radzi sobie w internecie, ale sytuacja się stabilizuje. Oto, co musisz wiedzieć na ten temat:

W skrócie

  • SharedArrayBuffer jest obecnie obsługiwana w Firefox 79 i nowszych wersjach, a w Chrome na Androida pojawi się w Chrome 88. Jest ona jednak dostępna tylko w przypadku stron izolowanych od zasobów z innych domen.
  • SharedArrayBuffer jest obecnie dostępna w Chrome na komputery, ale od wersji 92 Chrome będzie ograniczona do stron z izolacją zasobów z innych domen. Jeśli nie masz pewności, czy uda Ci się wprowadzić tę zmianę na czas, możesz zarejestrować się na okres próbny źródła, aby zachować obecne działanie do co najmniej wersji Chrome 113.
  • Jeśli chcesz włączyć izolację między domenami, aby nadal korzystać z SharedArrayBuffer, sprawdź, jaki wpływ będzie to miało na inne elementy między domenami w Twojej witrynie, np. na miejsca docelowe reklam. Aby poznać wpływ i wskazówki, sprawdź, czy SharedArrayBufferjest używany przez jakiekolwiek zasoby zewnętrzne.

Omówienie izolacji od zasobów z innych domen

Aby strona była izolowana od zasobów z innych domen, możesz wysłać ją z tymi nagłówkami:

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

Po wykonaniu tej czynności strona nie będzie mogła wczytywać treści z innych domen, chyba że zasób wyraźnie na to zezwala za pomocą nagłówka Cross-Origin-Resource-Policy lub nagłówków CORS (Access-Control-Allow-* itd.).

Dostępny jest też interfejs API do raportowania, dzięki któremu możesz zbierać dane o żądaniach, które zakończyły się niepowodzeniem z powodu Cross-Origin-Embedder-Policy i Cross-Origin-Opener-Policy.

Jeśli nie uda Ci się wprowadzić tych zmian na czas, aby wprowadzić je w Chrome 92, możesz zarejestrować się w programie testów wersji natywnej, aby zachować obecne działanie Chrome na komputery do co najmniej wersji 113.

Więcej wskazówek i informacji na temat izolacji między domenami znajdziesz w sekcji Więcej informacji na dole tej strony.

Jak dotarliśmy do tego miejsca?

SharedArrayBuffer pojawiła się w Chrome 60 (czyli w lipcu 2017 r., jeśli myślisz o czasie w datkach, a nie wersjach Chrome), i wszystko było w porządku. Przez 6 miesięcy.

W styczniu 2018 r. wykryto lukę w zabezpieczeniach w niektórych popularnych procesorach. Więcej informacji znajdziesz w tym oświadczeniu, ale w podstawie oznaczało to, że kod mógł używać zegara o wysokiej rozdzielczości do odczytu pamięci, do której nie powinien mieć dostępu.

Był to problem dla dostawców przeglądarek, ponieważ chcemy umożliwić witrynom wykonywanie kodu w postaci JavaScript i WASM, ale ściśle kontrolować dostęp do pamięci, do której ma dostęp ten kod. Jeśli wejdziesz na moją stronę, nie będę mógł odczytać niczego z witryny banku internetowego, którą masz otwartą. Nie powinienem nawet wiedzieć, że masz otwartą stronę internetowego banku. To podstawy bezpieczeństwa sieci.

Aby temu zaradzić, zmniejszyliśmy rozdzielczość naszych zegarów o wysokiej rozdzielczości, takich jak performance.now(). Możesz jednak create zegar o wysokiej rozdzielczości za pomocą funkcji SharedArrayBuffer, modyfikując pamięć w ścisłej pętli w procesie roboczym i odczytując ją w innym wątku. Nie można było skutecznie ograniczyć tego problemu bez znacznego wpływu na kod napisany w dobrych intencjach, więc funkcja SharedArrayBuffer została całkowicie wyłączona.

Ogólne środki zaradcze to zapewnienie, aby proces systemowy strony internetowej nie zawierał poufnych danych z innych źródeł. Od samego początku Chrome korzysta z wieloprocesowej architektury (pamiętasz komiks?), ale nadal zdarzały się przypadki, w których dane z kilku witryn mogły trafić do tego samego procesu:

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

Te interfejsy API mają „stare” działanie, które umożliwia korzystanie z treści z innych źródeł bez konieczności wyrażenia zgody przez to źródło. Te żądania są wysyłane z użyciem plików cookie z innego źródła, więc jest to pełne żądanie „zalogowanego” użytkownika. Obecnie nowe interfejsy API wymagają, aby druga domena zaakceptowała żądanie CORS.

Ominięcie tych starszych interfejsów API polegało na zapobieganiu dostępowi treści do procesu strony internetowej, jeśli wyglądały na „nieprawidłowe”. Nazwaliśmy to blokowaniem odczytu między domenami. W wymienionych powyżej przypadkach nie zezwalamy na przekazywanie danych w formacie JSON, ponieważ nie jest to poprawny format dla żadnego z tych interfejsów API. Z wyjątkiem elementów iframe. W przypadku ramek iframe treści są przetwarzane w innym procesie.

Po wprowadzeniu tych środków zaradczych ponownie udostępniliśmy SharedArrayBuffer w Chrome 68 (lipiec 2018 r.), ale tylko na komputerach. Dodatkowe wymagania procesowe uniemożliwiły nam zastosowanie tej samej metody na urządzeniach mobilnych. Zauważyliśmy też, że rozwiązanie w Chrome jest niepełne, ponieważ blokowaliśmy tylko „nieprawidłowe” formaty danych, podczas gdy możliwe (choć nietypowe) jest, że prawidłowe pliki CSS/JS/obrazy pod adresami URL, które można odgadnąć, zawierają dane prywatne.

Specjaliści od standardów internetowych spotkali się, aby opracować bardziej kompleksowe rozwiązanie w różnych przeglądarkach. Rozwiązaniem było umożliwienie stronom określenia, że „zrzekamy na możliwość dodawania treści z innych źródeł do tego procesu bez wyrażenia zgody przez te strony”. Ta deklaracja jest przekazywana za pomocą nagłówków COOP i COEP wyświetlanych na stronie. Przeglądarka wymusza to, a w zamian strona uzyskuje dostęp do SharedArrayBuffer i innych interfejsów API o podobnych uprawnieniach. Inne źródła mogą zezwolić na umieszczanie treści za pomocą Cross-Origin-Resource-Policy lub CORS.

Firefox jako pierwszy wprowadził to ograniczenie w wersji 79 (lipiec 2020 r.).SharedArrayBuffer

Potem, w styczniu 2021 r., napisałem ten artykuł, który właśnie czytasz. Cześć.

I tutaj jesteśmy teraz. Chrome 88 przywraca na Androida funkcję SharedArrayBuffer w przypadku stron izolowanych od zasobów z innych domen, a Chrome 92 wprowadza te same wymagania na komputery, zarówno ze względu na spójność, jak i aby zapewnić całkowitą izolację zasobów z innych domen.

Opóźnienie zmiany w Chrome na komputery

Jest to tymczasowy wyjątek w postaci „testu pochodzenia”, który daje użytkownikom więcej czasu na wdrożenie stron izolowanych z innych domen. Umożliwia to SharedArrayBuffer bez konieczności izolowania strony od zasobów z innych domen. Wyjątek wygasa w Chrome 113 i dotyczy tylko wersji Chrome na komputery.

  1. Poproś o token dla swojego źródła.
  2. Dodaj token do swoich stron. Możesz to zrobić na 2 sposoby:
    • Dodaj tag origin-trial <meta> do nagłówka każdej strony. Może to wyglądać mniej więcej tak:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Jeśli możesz skonfigurować serwer, możesz też dodać token za pomocą nagłówka HTTP Origin-Trial. Wynikowy nagłówek odpowiedzi powinien wyglądać mniej więcej tak:
      Origin-Trial: TOKEN_GOES_HERE

Więcej informacji

Zdjęcie banera: Daniel Gregoire z Unsplash