Weź udział w testowaniu origin interfejsu Storage Access API z dostępem do miejsca na dane bez plików cookie

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

W Chrome 115 wprowadzono zmiany w skryptach pamięci, mechanizmach Service Worker i interfejsach API do komunikacji przez partycjonowanie w kontekstach innych firm. Interfejsy API dotyczące tego samego pochodzenia są izolowane przez zasady dotyczące tego samego pochodzenia, a interfejsy API używane w kontekście innych firm są również izolowane przez witrynę w kontekście najwyższego poziomu.

Witryny, które nie mają czasu na wdrożenie obsługi partycjonowania pamięci przez podmioty zewnętrzne, mogą wziąć udział w okresie próbnym wycofywania, aby tymczasowo cofnąć partycjonowanie (nadal izolować od tej samej domeny, ale usunąć izolację przez witrynę najwyższego poziomu) oraz przywrócić wcześniejsze zachowanie pamięci, mechanizmów Service Worker i komunikacyjnych interfejsów API w zawartości umieszczonej w witrynie. Ten okres próbny wycofywania zakończy się wraz z udostępnieniem Chrome 127 3 września 2024 r. Pamiętaj, że nie jest to okres próbny wycofywania dostępu do plików cookie innych firm – chodzi tu tylko o dostęp do miejsca na dane.

Jako długoterminowe rozwiązanie mające na celu rozwiązanie pewnych przypadków użycia zakłócanych przez partycjonowanie pamięci masowej niezwiązany z plikami cookie innych firm – Chrome proponuje firmom zewnętrznym żądanie dostępu do pamięci i komunikacji (zarówno plików cookie, jak i innych niż pliki cookie) przy użyciu interfejsu Storage Access API (dostawa od Chrome 117), który już umożliwia innym firmom wysyłanie próśb o dostęp do plików cookie.

Od wersji Chrome 120 ta oferta będzie dostępna do eksperymentowania w ramach testowania origin. Deweloperzy powinni wziąć udział w testowaniu origin, aby ocenić, jak proponowane rozwiązanie radzi sobie z ich przypadkiem użycia, co pozwoli im przygotować się na koniec okresu próbnego wycofywania.

Szczegóły wersji próbnej origin

Od wersji Chrome 120 Chrome będzie obsługiwać wersję próbną StorageAccessAPIBeyondCookies, aby umożliwić proponowane rozszerzenie interfejsu Storage Access API (zgodne wstecznie), by umożliwić dostęp do pamięci bez partycji (plików cookie i innych plików cookie) w kontekście innych firm.

Mechanika

Interfejsu API można używać w ten sposób (JavaScript działa w umieszczonym elemencie iframe):

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

Jeśli potrzebujesz dostępu tylko do konkretnego interfejsu API, a nie do interfejsu all, możesz przekazać tylko potrzebne nazwy nicków interfejsu API. Możesz na przykład przekazać adres {sessionStorage: true}, aby uzyskać dostęp do usługi Session Storage, lub {indexedDB: true, locks:true}, aby uzyskać dostęp do IndexedDB i blokad internetowych.

Poza wywołaniem tego dodatkowego rozszerzenia dostęp do miejsca na dane niewymagający plików cookie spełniłby obecne wymagania dotyczące dostępu do plików cookie za pomocą interfejsu Storage Access API. Na przykład w Chrome nie wyświetla się żaden komunikat, gdy źródła znajdują się w tym samym zestawie powiązanych witryn (RWS, czyli nowej nazwie zestawów źródeł własnych). Źródła, które nie są częścią tego samego RWS, podlegają wymogom dotyczącym powiadomień interfejsu Storage Access API w Chrome.

Czas działania

Testowanie origin będzie dostępne od wersji 120 do Chrome 125 (lub po 6 sierpnia 2024 r., na każdym etapie).

Zakres

W Chrome 120 dostępne są tylko dane DOM (pamięć i pamięć lokalna), Indexed DB oraz Web Locks.

W Chrome 121 dodano Cache Storage, Prywatny system plików źródła, Limit, Blob Storage i Kanał transmisji.

W Chrome 123 dodaliśmy współdzielone zasoby robocze oraz kontrolę nad dodawaniem plików cookie.

Dedykowane instancje robocze dziedziczą dostęp do niepartycjonowanych plików cookie, jeśli interfejs requestStorageAccess został wywołany przed utworzeniem instancji roboczej w Chrome 120 (nie wymaga to użycia uchwytu Storage Access API).

Twój udział

  1. ocenić, jak wykorzystujesz pliki cookie (i inne niż pliki cookie) w kontekście innej firmy; Przykładowe przypadki użycia pomogą Ci zdecydować, czy oferta odpowiada Twoim potrzebom.
  2. Uruchom Chrome w wersji 120 (lub nowszej) i upewnij się, że włączona jest flaga test-third-party-cookie-phaseout.
  3. Jeśli chcesz przetestować tę funkcję lokalnie bez uprzedniego konfigurowania tokena próbnego origin, możesz włączyć #enable-experimental-web-platform-features w przeglądarce.
    1. Po zakończeniu testowania lokalnego możesz register do wersji próbnej origin StorageAccessAPIBeyondCookies, aby uzyskać token dla swoich domen. Bardziej szczegółowe instrukcje znajdziesz w artykule Pierwsze kroki z testami origin. Przewodnik na temat rozwiązywania problemów z testami origin Chrome zawiera pełną listę kontrolną, która pozwala sprawdzić, czy token jest prawidłowo skonfigurowany.
    2. Umieść token próbny w elemencie iframe, w którym musisz użyć uchwytu interfejsu Storage Access API, korzystając z nagłówka HTTP, metatagu HTML lub automatycznie. Pamiętaj, że token musi być umieszczony w każdej ramce, która chce używać tego interfejsu API. Umieszczenie go w ramce nadrzędnej nie włączy interfejsu API w ramkach podrzędnych.
  4. Wywołaj document.requestStorageAccess(...), aby uzyskać uchwyt interfejsu Storage Access API w elemencie iframe z innej witryny. Wymagania dotyczące powodzenia tego wywołania znajdziesz w dokumentacji interfejsu Storage Access API.
  5. Przenieś pamięć powiązaną z elementem iframe, aby używać uchwytu interfejsu Storage Access API, jeśli jest dostępny. Na przykład połączenia z numerem window.sessionStorage.setItem(...) zmienią się na handle.sessionStorage.setItem(...).
  6. Otwórz swoją witrynę i sprawdź, czy uchwyt dostępu do pamięci masowej działa prawidłowo.
  7. Aby przestać korzystać z wersji próbnej origin, usuń token dodany w kroku 3.
  8. Prześlij opinię lub zgłoś napotkane problemy w repozytorium Storage Access API innym niż Cookie Storage na GitHubie.

Prezentacja: korzystanie z interfejsu Storage Access API w celu uzyskiwania dostępu do pamięci lokalnej bez partycji

Poniższa demonstracja pokazuje, jak uzyskać dostęp do niepartycjonowanych kanałów transmisji z elementu iframe innej firmy za pomocą interfejsu Storage Access API:

https://saa-beyond-cookies.glitch.me/

Wersja demonstracyjna wymaga przeglądarki Chrome 121 lub nowszej z włączoną flagą test-third-party-cookie-phaseout.

Dodatkowe materiały