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ługaSharedArrayBuffer
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.
- Poproś o token dla Twojego punktu początkowego.
- 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
- Dodaj tag
Więcej informacji
- Przewodnik po włączeniu izolacji zasobów z innych domen
- Jak odizolować strony od zasobów z innych domen
- Dlaczego potrzebna jest izolacja zasobów z innych domen
Autor zdjęcia banera: Daniel Gregoire, Unsplash