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 nie najlepiej przyjęto w internecie, ale sytuacja się stabilizuje. Oto, co musisz wiedzieć na ten temat:

W skrócie

  • SharedArrayBuffer jest obecnie obsługiwana w przeglądarce Firefox 79 i nowszych wersjach, a wkrótce będzie dostępna w Chrome 88 na Androida. Jest ona jednak dostępna tylko na stronach izolowanych od zasobów z innych domen.
  • SharedArrayBuffer jest obecnie dostępny w Chrome na komputery, ale od wersji 92 będzie ograniczony do stron z izolacją zasobów z innych domen. Jeśli uważasz, że nie zdążysz wprowadzić tej zmiany na czas, możesz zarejestrować się w programie testów źródła, aby zachować obecne działanie co najmniej do wersji Chrome 113.
  • Jeśli zamierzasz włączyć izolację między źródłami, aby nadal korzystać z SharedArrayBuffer, oceń, jaki wpływ będzie to miało na inne elementy między źródłami w Twojej witrynie, takie jak miejsca docelowe reklam. Sprawdź, czy SharedArrayBufferjest używany przez któreś z Twoich zasobów innych firm, aby poznać wpływ i uzyskać wskazówki.

Omówienie izolacji od zasobów z innych domen

Aby strona była odizolowana od innych domen, musisz wyświetlać ją z tymi nagłówkami:

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

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

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

Jeśli uważasz, że nie zdążysz wprowadzić tych zmian przed wydaniem Chrome 92, możesz zarejestrować się w programie testów źródła, aby zachować obecne działanie Chrome na komputery co najmniej do wersji 113.

Więcej wskazówek i informacji o izolacji między źródłami znajdziesz w sekcji Dodatkowe materiały na dole tej strony.

Jak dotarliśmy do tego miejsca?

SharedArrayBuffer pojawiło się w Chrome 60 (w lipcu 2017 r., dla tych, którzy wolą myśleć o czasie w kategoriach dat, a nie wersji Chrome), i wszystko było w porządku. Przez 6 miesięcy.

W styczniu 2018 r. wykryto lukę w zabezpieczeniach niektórych popularnych procesorów. Więcej informacji znajdziesz w ogłoszeniu, ale w zasadzie oznaczało to, że kod mógł używać timerów o wysokiej rozdzielczości do odczytywania pamięci, do której nie powinien mieć dostępu.

Był to problem dla dostawców przeglądarek, ponieważ chcemy zezwalać witrynom na wykonywanie kodu w postaci JavaScript i WASM, ale jednocześnie ściśle kontrolować pamięć, do której ten kod ma dostęp. Jeśli wejdziesz na moją stronę, nie powinienem mieć możliwości odczytania niczego ze strony bankowości internetowej, którą masz również otwartą. Nie powinienem nawet wiedzieć, że masz otwartą witrynę bankowości internetowej. To podstawy bezpieczeństwa w internecie.

Aby temu zapobiec, zmniejszyliśmy rozdzielczość naszych timerów o wysokiej rozdzielczości, takich jak performance.now(). Możesz jednak utworzyć timer o wysokiej rozdzielczości za pomocą SharedArrayBuffer, modyfikując pamięć w ciasnej pętli w procesie roboczym i odczytując ją w innym wątku. Nie można było skutecznie ograniczyć tego zjawiska bez poważnego wpływu na dobrze napisany kod, dlatego funkcja SharedArrayBuffer została całkowicie wyłączona.

Ogólnym sposobem na ograniczenie tego ryzyka jest upewnienie się, że proces systemowy strony nie zawiera danych wrażliwych z innych miejsc. Chrome od początku korzysta z architektury wieloprocesowej (pamiętasz komiks?), ale zdarzały się przypadki, w których dane z wielu witryn mogły trafiać 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ą „starsze” działanie, które umożliwia korzystanie z treści z innych źródeł bez zgody tych źródeł. Te żądania są wysyłane z plikami cookie z innego źródła, więc są to pełne żądania „zalogowanego użytkownika”. Obecnie nowe interfejsy API wymagają, aby inne źródło wyraziło zgodę na ich używanie za pomocą CORS.

Obejście tych starszych interfejsów API polegało na uniemożliwieniu wprowadzania treści do procesu strony internetowej, jeśli wyglądały one na „nieprawidłowe”. Nazwaliśmy to blokowaniem odczytu z innych domen. W powyższych przypadkach nie zezwalamy na użycie kodu JSON, ponieważ nie jest on prawidłowym formatem w żadnym z tych interfejsów API. Z wyjątkiem elementów iframe. W przypadku elementów iframe umieszczamy treści w innym procesie.

Po wprowadzeniu tych środków zapobiegawczych ponownie udostępniliśmy SharedArrayBuffer w Chrome 68 (lipiec 2018 r.), ale tylko na komputerach. Dodatkowe wymagania dotyczące procesu uniemożliwiły nam zrobienie tego samego na urządzeniach mobilnych. Zauważono też, że rozwiązanie Chrome jest niekompletne, ponieważ blokujemy tylko „nieprawidłowe” formaty danych, podczas gdy jest możliwe (choć nietypowe), że prawidłowe pliki CSS/JS/obrazy pod adresami URL, które można odgadnąć, mogą zawierać dane prywatne.

Specjaliści od standardów internetowych spotkali się, aby opracować bardziej kompleksowe rozwiązanie działające w różnych przeglądarkach. Rozwiązaniem było umożliwienie stronom deklarowania, że „zrzekają się możliwości włączania do tego procesu treści z innych źródeł bez zgody użytkownika”. Deklaracja jest dokonywana za pomocą nagłówków COOP i COEP przesyłanych ze stroną. Przeglądarka wymusza to zachowanie, a w zamian strona uzyskuje dostęp do SharedArrayBuffer i innych interfejsów API o podobnych możliwościach. Inne źródła mogą włączyć osadzanie treści za pomocą Cross-Origin-Resource-Policy lub CORS.

Firefox jako pierwsza przeglądarka wprowadziła to ograniczenie w SharedArrayBuffer wersji 79 (lipiec 2020 r.).

Następnie w styczniu 2021 r. napisałem ten artykuł, a Ty go przeczytałeś(-aś). Cześć.

I w tym miejscu jesteśmy teraz. W Chrome 88 przywróciliśmy obiekt SharedArrayBuffer na Androidzie w przypadku stron, które są izolowane od zasobów z innych domen. W Chrome 92 wprowadziliśmy te same wymagania na komputerach, aby zapewnić spójność i osiągnąć całkowitą izolację od zasobów z innych domen.

Opóźnienie zmiany w Chrome na komputer

Jest to tymczasowy wyjątek w postaci „testu pochodzenia”, który daje więcej czasu na wdrożenie stron izolowanych od zasobów z innych domen. Umożliwia korzystanie z SharedArrayBuffer bez konieczności izolowania strony od zasobów z innych domen. Wyjątek wygasa w Chrome 113 i dotyczy tylko 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 sekcji head każdej strony. Może to wyglądać np. 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 na banerze: Daniel Gregoire, Unsplash