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

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

Witryna SharedArrayBuffer ma kłopoty z przejściem na strony w internecie, ale wszystko już się zaczyna. Oto, co musisz wiedzieć na ten temat:

W skrócie

  • Usługa SharedArrayBuffer jest obecnie obsługiwana w przeglądarce Firefox w wersji 79 i nowszych, a będzie dostępna na urządzeniach z Androidem w wersji 88. Są one jednak dostępne tylko w przypadku stron izolowanych od zasobów z innych domen.
  • Komponent SharedArrayBuffer jest obecnie dostępny w Chrome na komputery, ale od Chrome 92 będzie ograniczony do stron izolowanych z innych domen. Jeśli uważasz, że nie uda Ci się wprowadzić tej zmiany na czas, możesz zarejestrować się do testowania origin, aby zachować obecne działanie co najmniej do Chrome 113.
  • Jeśli zamierzasz włączyć izolację zasobów z innych domen, aby nadal korzystać z elementów SharedArrayBuffer, oceń, jaki to będzie miało na inne elementy z tych domen w Twojej witrynie, takie jak miejsca docelowe reklam. Sprawdź, czy usługa SharedArrayBuffer jest używana przez którekolwiek z Twoich zasobów zewnętrznych, aby poznać jej wpływ i wytyczne.

Omówienie izolacji zasobów z innych domen

Możesz ją izolować od zasobów z innych domen, wyświetlając ją z następującymi nagłówkami:

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

Gdy to zrobisz, Twoja 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-* itd.).

Dostępny jest też interfejs API do raportowania, który umożliwia gromadzenie danych 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 jesteś w stanie wprowadzić tych zmian w odpowiednim czasie, aby wprowadzić Chrome w wersji 92, możesz zarejestrować się do skorzystania z wersji próbnej origin. Pozwoli Ci to zachować obecne działanie Chrome na komputerach do czasu wprowadzenia Chrome 113.

Zapoznaj się z sekcją Więcej informacji na dole tej strony, aby uzyskać więcej wskazówek i informacji na temat izolacji zasobów z innych domen.

Jak dotarliśmy do tego miejsca?

SharedArrayBuffer pojawiło się w Chrome 60 (to lipiec 2017 r. dla tych, którzy zamiast Chrome preferują daty, a nie wersje Chrome) i wszystko jest w porządku. Przez 6 miesięcy.

W styczniu 2018 roku odkryliśmy lukę w zabezpieczeniach w niektórych popularnych procesorach. Szczegółowe informacje znajdziesz w ogłoszeniu, ale zasadniczo oznaczało to, że kod może używać liczników czasu o wysokiej rozdzielczości do odczytu pamięci, do której nie powinien mieć dostępu.

To był problem dla naszych dostawców przeglądarek, ponieważ chcemy zezwolić witrynom na wykonywanie kodu w formacie JavaScript i WASM, ale ściśle kontrolować pamięć, do której ten kod ma dostęp. Jeśli otworzycie moją witrynę, nie będę w stanie odczytać informacji z otwartej przez Was witryny bankowości internetowej. Nie powinienem nawet wiedzieć, że macie otwartą stronę bankowości internetowej. To podstawy bezpieczeństwa w sieci.

Aby temu zaradzić, zmniejszyliśmy rozdzielczość minutników o wysokiej rozdzielczości, takich jak performance.now(). Możesz jednak utworzyć licznik czasu w wysokiej rozdzielczości za pomocą SharedArrayBuffer, modyfikując pamięć w pętli w obrębie instancji roboczej i odczytując ją z powrotem w innym wątku. Nie udało się skutecznie ograniczyć tego problemu bez negatywnego wpływu na kod o dobrych intencjach, dlatego interfejs SharedArrayBuffer został całkowicie wyłączony.

Ogólne środki zaradcze polegają na zagwarantowaniu, że proces systemowy strony internetowej nie zawiera danych wrażliwych z innego miejsca. Chrome od samego początku inwestował w architekturę wieloprocesową (pamiętasz komiks?), ale zdarzało się, że dane z wielu witryn trafiały w ten sam proces:

<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 używanie treści z innych źródeł bez konieczności ich wyrażania. Żądania te są wysyłane z plików cookie z innego źródła, dlatego są to pełne żądania „zalogowane”. Obecnie nowe interfejsy API wymagają innego źródła, aby akceptacja za pomocą CORS.

Omieszliśmy te starsze interfejsy API, zapobiegając wchodzeniu treści na stronę internetową, jeśli wyglądały na nieprawidłowe. Właśnie to wprowadziliśmy blokowanie odczytu z innych domen. Dlatego w powyższych przypadkach nie zezwolimy na użycie kodu JSON, ponieważ nie jest to prawidłowy format dla żadnego z tych interfejsów API. z wyjątkiem elementów iframe. Elementy iframe umieszczamy w innym procesie.

Po zastosowaniu tych środków zaradczych ponownie wprowadziliśmy SharedArrayBuffer w Chrome 68 (lipiec 2018 r.), ale tylko na komputerach. Dodatkowe wymagania związane z procesem sprawiały, że nie możemy tego robić na urządzeniach mobilnych. Zauważono również, że rozwiązanie Chrome jest niekompletne, ponieważ blokujemy tylko „nieprawidłowe” formaty danych, podczas gdy prawidłowe kody CSS/JS/obrazy dostępne pod możliwych do odgadnięcia adresami URL mogą zawierać prywatne dane.

Członkowie standardów internetowych wspólnie wymyślili lepsze rozwiązanie dla różnych przeglądarek. Rozwiązaniem było umożliwienie stronom wskazania: „Nie zgadzam się z moją możliwością włączenia do tego procesu treści z innych źródeł bez ich zgody”. Deklaracja jest dokonywana za pomocą nagłówków COOP i COEP wyświetlanych ze stroną. Przeglądarka wymusza to, a w zamian strona zyskuje dostęp do interfejsu SharedArrayBuffer i innych interfejsów API o podobnych uprawnieniach. Inne źródła mogą wyrazić zgodę na umieszczanie treści za pomocą Cross-Origin-Resource-Policy lub CORS.

Firefox jako pierwsza oferował produkt SharedArrayBuffer z tym ograniczeniem w wersji 79 (lipiec 2020 r.).

W styczniu 2021 roku napisałam ten artykuł, a Ty go przeczytałam. Cześć.

To właśnie tutaj jesteśmy. Chrome 88 przywraca SharedArrayBuffer na Androidzie w przypadku stron, które są izolowane od zasobów z innych domen, a Chrome 92 wprowadza te same wymagania w przypadku komputerów zarówno w celu zapewnienia spójności, jak i całkowitej izolacji zasobów z innych domen.

Opóźnianie zmian w Chrome na komputerze

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

  1. Poproś o token dla Twojego punktu początkowego.
  2. Dodaj token do swoich stron. Możesz to zrobić na 2 sposoby:
    • Dodaj tag origin-trial <meta> w nagłówku każdej strony. Na przykład 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. Nagłówek odpowiedzi powinien wyglądać mniej więcej tak:
      Origin-Trial: TOKEN_GOES_HERE

Więcej informacji

Autor zdjęcia banera: Daniel Gregoire, Unsplash