Interfejs Storage Access API

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Blokowanie plików cookie innych firm przez przeglądarki, ustawienia użytkownika i partycjonowanie pamięci stanowią wyzwanie dla witryn i usług, które polegają na plikach cookie i innych danych przechowywanych w ramach wbudowanych kontekstów, np. w przypadku uwierzytelniania. Interfejs Storage Access API (SAA) umożliwia dalsze korzystanie z tych przypadków użycia przy jednoczesnym jak największym ograniczeniu śledzenia między witrynami.

Stan wdrożenia

Interfejs Storage Access API jest dostępny we wszystkich głównych przeglądarkach, ale występują niewielkie różnice w implementacji. Te różnice zostały wyróżnione w odpowiednich sekcjach tego wpisu.

Nadal pracujemy nad rozwiązaniem wszystkich pozostałych problemów z blokowaniem, zanim ujednoliwimy interfejs API.

Czym jest interfejs Storage Access API?

Interfejs Storage Access API to interfejs JavaScript API, który umożliwia elementom iframe żądanie uprawnień dostępu do pamięci masowej, gdy dostęp byłby odrzucony przez ustawienia przeglądarki. Elementy osadzone, których przypadki użycia zależą od wczytywania zasobów w różnych witrynach, mogą używać interfejsu API do żądania od użytkownika uprawnień dostępu w razie potrzeby.

Jeśli żądanie dostępu do pamięci zostanie spełnione, element iframe będzie miał dostęp do niepartycjonowanych plików cookie i miejsca na dane, które są też dostępne, gdy użytkownicy odwiedzają go jako witrynę najwyższego poziomu.

Interfejs Storage Access API umożliwia udostępnianie dostępu do określonych plików cookie bez partycji i dostępu do pamięci z minimalnym obciążeniem dla użytkownika, przy jednoczesnym zapobieganiu ogólnemu dostępowi do plików cookie bez partycji i dostępu do pamięci, które są często wykorzystywane do śledzenia użytkowników.

Przypadki użycia

Niektóre elementy osadzenia innych firm wymagają dostępu do plików cookie bez partycji lub pamięci, aby zapewnić użytkownikom lepsze wrażenia. Nie będzie to możliwe, gdy pliki cookie innych firm będą ograniczone, a partycjonowanie pamięci będzie włączone.

Przykładowe zastosowania:

• wbudowane widżety dodawania komentarzy, które wymagają zalogowania się;
• przyciski „Lubię to” w mediach społecznościowych, które wymagają podania danych logowania;
• osadzone dokumenty, które wymagają danych sesji logowania;
• Zaawansowane funkcje dostępne w ramach wbudowanego filmu (np. możliwość niewyświetlania reklam użytkownikom, którzy są zalogowani, poznawanie preferencji użytkownika dotyczących napisów lub ograniczanie wyświetlania niektórych typów filmów).
• wbudowane systemy płatności;

Wiele z tych zastosowań wymaga trwałego dostępu do logowania w osadzonych elementach iframe.

Kiedy warto używać interfejsu Storage Access API zamiast innych interfejsów API

Interfejs Storage Access API jest jedną z alternatyw dla plików cookie i miejsca na dane bez partycji, dlatego ważne jest, aby wiedzieć, kiedy używać tego interfejsu API w porównaniu z innymi. Jest przeznaczony do zastosowań, w których spełnione są oba te warunki:

• Użytkownik będzie wchodzić w interakcję z osadzonym elementem iframe, co oznacza, że nie jest to pasywny ani ukryty element iframe.
• Użytkownik odwiedził wbudowane źródło w kontekście najwyższego poziomu, czyli gdy to źródło nie jest wbudowane w innej witrynie.

Do różnych zastosowań dostępne są alternatywne interfejsy API:

• Technologia Cookies Having Independently Partitioned State (CHIPS) umożliwia programistom dodanie pliku cookie do „partycjonowanego” magazynu z osobnym słoikiem z ciasteczkami dla każdej witryny najwyższego poziomu. Na przykład widget czatu internetowego innej firmy może używać plików cookie do zapisywania informacji o sesji. Informacje o sesji są zapisywane w poszczególnych witrynach, więc nie trzeba uzyskiwać dostępu do pliku cookie ustawionego przez widżet w innych witrynach, w których jest on również umieszczony. Interfejs Storage Access API jest przydatny, gdy wbudowany widżet zewnętrzny zależy od udostępniania tych samych informacji z różnych źródeł (np. szczegółów sesji lub preferencji).
• Partycjonowanie pamięci to sposób, dzięki któremu iframe na wielu stronach może używać istniejących mechanizmów przechowywania danych w JavaScript, dzieląc przy tym pamięć na poszczególne strony. Zapobiega to dostępowi do zasobów pamięci w ramach jednej witryny przez te same zasoby w innych witrynach.
• Zestawy powiązanych witryn (RWS) to sposób na deklarowanie przez organizację relacji między witrynami, dzięki czemu przeglądarki zezwalają na ograniczony dostęp do plików cookie bez partycji i do pamięci na potrzeby określonych celów. Witryny nadal muszą prosić o dostęp za pomocą interfejsu Storage Access API, ale w przypadku witryn w zestawie dostęp może być przyznawany bez wyświetlania komunikatów dla użytkowników.
• Federated Credential Management (FedCM) to podejście do usług tożsamości sfederowanej, które chroni prywatność. Interfejs Storage Access API umożliwia dostęp do plików cookie bez partycji i dostęp do pamięci po zalogowaniu. W niektórych przypadkach FedCM może być alternatywą dla interfejsu Storage Access API, ponieważ zawiera ono prompt logowania, który może być bardziej odpowiedni. Wdrożenie FedCM wymaga jednak zwykle wprowadzenia dodatkowych zmian w kodzie, np. w celu obsługi punktów końcowych HTTP.
• Istnieją też interfejsy API do zapobiegania oszustwom, reklam i pomiarów, a interfejs Storage Access API nie jest przeznaczony do rozwiązywania tych problemów.

Korzystanie z interfejsu Storage Access API

Interfejs Storage Access API udostępnia 2 metody oparte na obietnicy:

• Document.hasStorageAccess() (dostępne również pod nową nazwą Document.hasUnpartitionedCookieAccess() od wersji 125 Chrome)
• Document.requestStorageAccess()

Jest też zintegrowany z interfejsem Permissions API. Pozwala to sprawdzić stan uprawnienia dostępu do pamięci w kontekście aplikacji zewnętrznej, co wskazuje, czy wywołanie funkcji document.requestStorageAccess() zostanie automatycznie przyznane:

• navigator.permissions.query({name: "storage-access"});

Użyj metody hasStorageAccess()

Podczas pierwszego wczytywania witryna może użyć metody hasStorageAccess(), aby sprawdzić, czy dostęp do plików cookie innych firm został już przyznany.

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Interfejs Storage Access API przyznaje dostęp do pamięci dokumentowi w ramce iframe dopiero po wywołaniu requestStorageAccess(),, więc hasStorageAccess() może początkowo zwrócić wartość false, na przykład wtedy, gdy użytkownik domyślnie blokuje pliki cookie innych firm. Ustawienia użytkownika dotyczące danej witryny mogą jednak zezwalać na dostęp do plików cookie w konkretnej witrynie, nawet jeśli użytkownik domyślnie blokuje pliki cookie innych firm. Dostęp do pamięci za pomocą tego interfejsu API jest zachowany w przypadku nawigacji w ramach tego samego pochodzenia w elemecie iframe, aby umożliwić ponowne wczytywanie po przyznaniu dostępu do stron, które wymagają obecności plików cookie w pierwotnym żądaniu dokumentu HTML.

Używaj klawisza requestStorageAccess()

Jeśli element iframe nie ma dostępu, może poprosić o dostęp za pomocą metody requestStorageAccess():

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

Gdy dostęp jest wymagany po raz pierwszy, użytkownik może musieć zatwierdzić go w wyświetlonym przez przeglądarkę promptzie. W przeciwnym razie prośba zostanie odrzucona, co spowoduje wyjątek, jeśli użyto await.

Aby zapobiec nadużyciom, ta prośba w przeglądarce będzie wyświetlana tylko po interakcji użytkownika. Dlatego funkcja requestStorageAccess() musi być wywoływana z obsługi zdarzeń aktywowanych przez użytkownika, a nie natychmiast po załadowaniu ramki iframe:

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

Jeśli chcesz używać lokalnego magazynu zamiast plików cookie, możesz:

let handle = null;

async function doClick() {
  if (!handle) {
    try {
      handle = await document.requestStorageAccess({localStorage: true});
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  // Use handle to access unpartitioned local storage.
  handle.localStorage.setItem('foo', 'bar');
}

document.querySelector('#my-button').addEventListener('click', doClick);

Prośby o uprawnienia

Gdy użytkownik kliknie przycisk po raz pierwszy, w większości przypadków automatycznie pojawi się prośba przeglądarki, zwykle na pasku adresu. Na poniższym zrzucie ekranu widać przykładowe okno w Chrome, ale inne przeglądarki mają podobny interfejs:

W pewnych okolicznościach przeglądarka może pominąć ten komunikat i automatycznie przyznać uprawnienia:

• czy strona i ramka iframe były używane w ciągu ostatnich 30 dni po zaakceptowaniu prośby.
• Jeśli wbudowany element iframe jest częścią zestawu powiązanych witryn.
• Jeśli FedCM jest używany jako sygnał zaufania do uzyskania dostępu do pamięci.
• W Firefoxie ten komunikat jest również pomijany w przypadku znanych witryn (z którymi użytkownik wejdzie w interakcję na najwyższym poziomie) przez pierwsze 5 prób.

W pewnych okolicznościach metoda może zostać automatycznie odrzucona bez wyświetlania promptu:

• Jeśli użytkownik nie odwiedził wcześniej witryny, która jest właścicielem elementu iframe, i nie wszedł z nią w interakcję, jako dokumentu najwyższego poziomu, a nie w elemencie iframe. Oznacza to, że interfejs Storage Access API jest przydatny tylko w przypadku ukrytych witryn, które użytkownicy odwiedzili wcześniej w kontekście witryny własnej.
• Jeśli metoda requestStorageAccess() jest wywoływana poza zdarzeniem interakcji z użytkownikiem bez wcześniejszego zatwierdzenia promptu po interakcji.

Użytkownik zobaczy prośbę o pierwsze użycie, ale w przypadku kolejnych wizyt requestStorageAccess() może się ona rozwiązać bez prośby i bez interakcji użytkownika w Chrome i Firefox. Pamiętaj, że Safari zawsze wymaga działania ze strony użytkownika.

Ponieważ dostęp do plików cookie i do pamięci może być przyznawany bez wyświetlania promptu lub interakcji z użytkownikiem, w przeglądarkach, które obsługują tę funkcję (Chrome i Firefox), często można uzyskać dostęp do plików cookie bez partycji lub do pamięci przed interakcją z użytkownikiem, wywołując requestStorageAccess() podczas wczytywania strony. Dzięki temu możesz natychmiast uzyskać dostęp do niepartycjonowanych plików cookie i miejsca na dane oraz zapewnić lepsze wrażenia, nawet zanim użytkownik wejdzie w interakcję z elementem iframe. W niektórych sytuacjach może to być wygodniejsze dla użytkownika niż oczekiwanie na jego reakcję.

FedCM jako sygnał zaufania w przypadku SAA

FedCM (Federated Credential Management) to podejście do usług tożsamości federacyjnej (takich jak „Zaloguj się za pomocą…”), które chroni prywatność i nie polega na plikach cookie innych firm ani przekierowaniach nawigacyjnych.

Gdy użytkownik loguje się na stronie zależnej, która zawiera treści z zewnętrznego dostawcy tożsamości (IdP) z użyciem FedCM, treści tego dostawcy mogą automatycznie uzyskać dostęp do pamięci na poziomie najwyższym dla plików cookie bez partycji. Aby włączyć automatyczny dostęp do miejsca na dane za pomocą FedCM, musisz spełnić te warunki:

• Uwierzytelnianie w FedCM (stan logowania użytkownika) musi być aktywne.
• RP wyraził zgodę, ustawiając uprawnienie identity-credentials-get, na przykład:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

Na przykład element iframe idp.example jest umieszczony w witrynie rp.example. Gdy użytkownik zaloguje się za pomocą FedCM, element iframe idp.example może poprosić o dostęp do plików cookie na najwyższym poziomie.

rp.example wysyła wywołanie FedCM, aby zalogować użytkownika u dostawcy tożsamości idp.example:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

Gdy użytkownik się zaloguje, dostawca tożsamości może wywołać funkcję requestStorageAccess() z poziomu elementu iframe idp.example, o ile usługa RP wyraźnie zezwoliła na to w zasadach dotyczących uprawnień. Elementowi embed zostanie automatycznie przyznany dostęp do pamięci dla własnego najwyższego poziomu plików cookie bez aktywacji przez użytkownika lub konieczności wyświetlenia kolejnego okna z prośbą o zgodę:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

Uprawnienie będzie przyznawane automatycznie tylko wtedy, gdy użytkownik jest zalogowany w Federowanym systemie zarządzania kampaniami. Gdy uwierzytelnianie jest nieaktywne, standardowe wymagania SAA mają zastosowanie do przyznawania dostępu do pamięci masowej.

Kolejne wczytywanie z użyciem nagłówków dostępu do pamięci

Nagłówki dostępu do Storage to zalecany, bardziej wydajny sposób umożliwiający wczytywanie treści umieszczonych w ramce, w tym zasobów innych niż iframe. Ta funkcja jest dostępna w Chrome 133. Dzięki nagłówkom dostępu do pamięci przeglądarka może rozpoznać, czy użytkownik przyznał już storage-access uprawnienia do zasobów zewnętrznych w bieżącym kontekście, i w następnych wizytach może wczytywać zasoby z dostępem do niezapartiony plików cookie.

Procedura nagłówków dostępu do pamięci

W przypadku nagłówków dostępu do pamięci masowej kolejne wizyty na stronach będą wywoływać następującą sekwencję:

1. Użytkownik wcześniej odwiedził stronę website.example, która zawiera zasob calendar.example. Użytkownik przyznał uprawnienia storage-access za pomocą wywołania document.requestStorageAccess().
2. Użytkownik odwiedza stronę website.example, która zawiera po raz kolejny osadzony zasób calendar.example. To żądanie nie ma jeszcze dostępu do pliku cookie, tak jak poprzednio. Użytkownik udzielił jednak wcześniej uprawnienia storage-access, a zapytanie fetch zawiera nagłówek Sec-Fetch-Storage-Access: inactive, co oznacza, że dostęp do plików cookie bez podziału jest dostępny, ale nieaktywny.
3. Serwer calendar.example odpowiada nagłówkiem Activate-Storage-Access: retry; allowed-origin='<origin>' (w tym przypadku <origin> będzie https://website.example), aby wskazać, że pobieranie zasobu wymaga użycia plików cookie bez partycji z uprawnieniami storage-access.
4. Przeglądarka ponownie wysyła żądanie, tym razem z uwzględnieniem plików cookie bez partycji (aktywując uprawnienie storage-access do tego i kolejnych pobrań).
5. Serwer calendar.example odpowiada spersonalizowanymi treściami w ramce. Odpowiedź zawiera nagłówek Activate-Storage-Access: load, który wskazuje, że przeglądarka powinna wczytać treści z aktywowanym uprawnieniem storage-access (czyli z dostępem do niepartycjonowanych plików cookie, tak jakby wywołano funkcję document.requestStorageAccess()).
6. Agent użytkownika wczytuje zawartość iframe z dostępem do plików cookie bez podziału, używając uprawnienia storage-access. Po wykonaniu tego kroku widżet może działać zgodnie z oczekiwaniami.

Używanie nagłówków dostępu do pamięci

W tabeli poniżej znajdziesz nagłówki dostępu do pamięci.

Na przykład nagłówki dostępu do Storage można użyć do wczytania obrazu z usługi zewnętrznej:

  // On the client side
  <img src="https://server.example/image">

W tym przypadku usługa server.example powinna zaimplementować tę logikę po stronie serwera:

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Demo interfejsu Storage Access API umieszcza treści innych firm (w tym obraz bez ramki IFrame) za pomocą nagłówków dostępu do pamięci.

Używanie zapytania o uprawnienia storage-access

Aby sprawdzić, czy dostęp może być przyznany bez interakcji z użytkownikiem, możesz sprawdzić stan uprawnienia storage-access i wykonać wywołanie requestStoreAccess() w wczesniejszym etapie, jeśli nie wymaga ono interakcji z użytkownikiem. W przeciwnym razie wywołanie może się nie udać.

Dzięki temu możesz też uniknąć wyświetlania prośby o pozwolenie, wyświetlając inną treść, np. przycisk logowania.

Poniższy kod dodaje do poprzedniego przykładu sprawdzenie uprawnień storage-access:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and earlier versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

Elementy iframe w piaskownicy

Aby korzystać z interfejsu Storage Access API w ramkach iframe w piaskownicy, musisz mieć te uprawnienia piaskownicy:

• Aby zezwolić na dostęp do interfejsu Storage Access API, wymagany jest allow-storage-access-by-user-activation.
• Aby umożliwić wywoływanie interfejsu API za pomocą JavaScriptu, musisz ustawić parametr allow-scripts.
• allow-same-origin jest wymagany, aby umożliwić dostęp do plików cookie i innych danych w tej samej domenie.

Na przykład:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Wymagania dotyczące plików cookie

Aby można było uzyskać do nich dostęp za pomocą interfejsu Storage Access API w Chrome, pliki cookie w wielu witrynach muszą mieć ustawione te 2 atrybuty:

• SameSite=None – wymagane do oznaczenia pliku cookie jako pliku cookie w wielu witrynach.
• Secure – co zapewnia dostęp tylko do plików cookie ustawionych przez witryny HTTPS.

W Firefox i Safari domyślnie pliki cookie są ustawione na SameSite=None i nie ograniczają SAA do plików cookie Secure, więc te atrybuty nie są wymagane. Zalecamy wyraźne określenie atrybutu SameSite i zawsze używanie plików cookie Secure.

Dostęp do strony najwyższego poziomu

Interfejs Storage Access API służy do włączania dostępu do plików cookie innych firm w ramkach osadzonych.

Istnieją też inne przypadki, gdy strona najwyższego poziomu wymaga dostępu do plików cookie innych firm. Na przykład obrazy lub skrypty ograniczone przez pliki cookie, które właściciele witryn mogą chcieć umieścić bezpośrednio w dokumentach najwyższego poziomu, a nie w ramkach iframe. Aby rozwiązać ten problem, Chrome zaproponował rozszerzenie interfejsu Storage Access API, które dodaje metodę requestStorageAccessFor().

Metoda requestStorageAccessFor()

Metoda requestStorageAccessFor() działa podobnie jak metoda requestStorageAccess(), ale dotyczy zasobów najwyższego poziomu. Można go używać tylko w przypadku witryn w ramach zestawu powiązanych witryn, aby zapobiec przyznaniu ogólnego dostępu do plików cookie innych firm.

Więcej informacji o używaniu requestStorageAccessFor() znajdziesz w przewodniku dla deweloperów dotyczącym zestawów powiązanych witryn.

Zapytanie o uprawnienia top-level-storage-access

Podobnie jak w przypadku uprawnienia storage-access, istnieje uprawnienie top-level-storage-access, które pozwala sprawdzić, czy można przyznać uprawnienia requestStorageAccessFor().

Czym różni się interfejs Storage Access API w przypadku korzystania z RWS?

Gdy zestawy powiązanych witryn są używane z interfejsem Storage Access API, są dostępne pewne dodatkowe funkcje, jak pokazano w tabeli poniżej:

Demo: ustawianie plików cookie i dostęp do nich

Ten pokaz demonstruje, jak można uzyskać dostęp do pliku cookie ustawionego przez Ciebie na pierwszym ekranie w ramce umieszczonej w witrynie na drugim ekranie:

storage-access-api-demo.glitch.me

Demonstracja wymaga przeglądarki z wyłączonymi plikami cookie innych firm:

• Chrome 118 lub nowszy z ustawionym flagą chrome://flags/#test-third-party-cookie-phaseout i ponownym uruchomieniem przeglądarki.
• Firefox
• Safari

Demonstracja: konfigurowanie pamięci lokalnej

Ten pokaz demonstruje, jak uzyskać dostęp do niepartycjonowanych kanałów transmisji za pomocą interfejsu Storage Access API z poziomu ramki iframe innej firmy:

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

Demonstracja wymaga Chrome w wersji 125 lub nowszej z włączoną flagą test-third-party-cookie-phaseout.

Zasoby

• Przeczytaj specyfikację, która umożliwia dostęp do plików cookie innych firm, lub zapoznaj się z problemami i prześlij zgłoszenie.
• Przeczytaj specyfikację dotyczącą dostępu do niepartycjonowanego miejsca na dane lub zapoznaj się z problemami i prześlij je.
• Dokumentacja API i przewodnik.
• Dokumentacja Chrome dotycząca korzystania z interfejsu Storage Access API w zestawach powiązanych witryn