Interfejs Storage Access API

Blokowanie plików cookie innych firm przez przeglądarki, ustawienia użytkowników i podział pamięci stanowi wyzwanie dla witryn i usług, które w kontekstach osadzonych polegają na plikach cookie i innych formach pamięci w przypadku ścieżek użytkowników, takich jak uwierzytelnianie. Storage Access API (SAA) umożliwia dalsze działanie tych przypadków użycia, jednocześnie maksymalnie ograniczając śledzenie w wielu witrynach.

Stan wdrożenia

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

Prace nad rozwiązaniem wszystkich pozostałych problemów z blokowaniem trwają, zanim interfejs API zostanie ustandaryzowany.

Czym jest interfejs Storage Access API?

Storage Access API to interfejs JavaScript API, który umożliwia elementom iframe żądanie uprawnień dostępu do pamięci masowej, gdy w innych przypadkach dostęp byłby odrzucany przez ustawienia przeglądarki. Elementy osadzone, których przypadki użycia zależą od wczytywania zasobów z innych witryn, mogą używać interfejsu API do proszenia użytkownika o zezwolenie na dostęp w razie potrzeby.

Jeśli żądanie dostępu do pamięci zostanie przyznane, element iframe będzie miał dostęp do swoich 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 przyznawanie dostępu do określonych plików cookie bez partycji i pamięci przy minimalnym obciążeniu użytkownika, a jednocześnie zapobiega ogólnemu dostępowi do plików cookie bez partycji i pamięci, który jest często wykorzystywany do śledzenia użytkowników.

Przypadki użycia

Niektóre osadzone elementy innych firm wymagają dostępu do plików cookie bez partycji lub pamięci, aby zapewnić użytkownikowi 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łady zastosowań:

• wbudowane widżety do komentowania, które wymagają szczegółów sesji logowania;
• przyciski „Lubię to” w mediach społecznościowych, które wymagają szczegółów sesji logowania;
• osadzonych dokumentów, które wymagają szczegółów sesji logowania;
• Wersja premium osadzonego filmu (np. brak reklam dla zalogowanych użytkowników, znajomość preferencji użytkownika dotyczących napisów lub ograniczenie niektórych typów filmów).
• wbudowane systemy płatności,

Wiele z tych przypadków użycia obejmuje zachowywanie dostępu do logowania w umieszczonych elementach iframe.

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

Interfejs Storage Access API jest jedną z alternatyw dla korzystania z niepodzielonych plików cookie i pamięci, dlatego ważne jest, aby wiedzieć, kiedy używać tego interfejsu API w porównaniu z innymi. Jest przeznaczona do przypadków użycia, w których spełnione są oba te warunki:

• Użytkownik będzie wchodzić w interakcje z osadzonymi treściami, tzn. nie będzie to pasywny ani ukryty element iframe.
• Użytkownik odwiedził wbudowaną domenę w kontekście najwyższego poziomu, czyli gdy nie była ona wbudowana w inną witrynę.

Istnieją alternatywne interfejsy API do różnych zastosowań:

• Cookies Having Independent Partitioned State (CHIPS) umożliwia programistom włączenie plików cookie do „partycjonowanego” miejsca na dane z osobnym magazynem plików cookie dla każdej witryny najwyższego poziomu. Na przykład widżet czatu online innej firmy może zapisywać plik cookie, aby zapisywać informacje o sesji. Informacje o sesji są zapisywane dla każdej witryny, więc plik cookie ustawiony przez widżet nie musi być dostępny w innych witrynach, w których jest on umieszczony. Interfejs Storage Access API jest przydatny, gdy umieszczony widżet zewnętrzny zależy od udostępniania tych samych informacji w różnych źródłach (np. szczegółów sesji po zalogowaniu lub preferencji).
• Partycjonowanie pamięci to sposób, w jaki ramki iframe z różnych witryn mogą korzystać z istniejących mechanizmów pamięci JavaScript, dzieląc pamięć bazową na poszczególne witryny. Zapobiega to dostępowi do pamięci osadzonej w jednej witrynie przez to samo osadzenie w innych witrynach.
• Zestawy powiązanych witryn to sposób, w jaki organizacja może deklarować relacje między witrynami, aby przeglądarki zezwalały na ograniczony dostęp do plików cookie bez partycji i pamięci do 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żytkownika.
• Federated Credential Management (FedCM) to podejście do usług tożsamości sfederowanych, które chroni prywatność. Interfejs Storage Access API umożliwia dostęp do plików cookie bez partycji i pamięci po zalogowaniu. W niektórych przypadkach FedCM stanowi alternatywne rozwiązanie dla interfejsu Storage Access API i może być preferowany, ponieważ wyświetla bardziej zorientowany na logowanie komunikat przeglądarki. Wdrożenie FedCM zwykle wymaga jednak dodatkowych zmian w kodzie, np. w celu obsługi punktów końcowych HTTP.
• Istnieją też interfejsy API zapobiegające oszustwom, związane z reklamami i pomiarami, a interfejs Storage Access API nie jest przeznaczony do rozwiązywania tych problemów.

Korzystanie z interfejsu Storage Access API

Interfejs Storage Access API ma 2 metody oparte na obietnicach:

• Document.hasStorageAccess() (od Chrome 125 dostępna też pod nową nazwą Document.hasUnpartitionedCookieAccess())
• Document.requestStorageAccess()

Jest też zintegrowany z interfejsem Permissions API. Dzięki temu możesz sprawdzić stan uprawnień dostępu do pamięci w kontekście podmiotu zewnętrznego, co wskazuje, czy wywołanie funkcji document.requestStorageAccess() zostanie automatycznie przyznane:

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

Użyj metody hasStorageAccess()

Gdy strona wczytuje się po raz pierwszy, 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 iframe dopiero po wywołaniu funkcji requestStorageAccess(),, więc funkcja hasStorageAccess() może początkowo zwracać wartość false, np. jeśli użytkownik domyślnie blokuje pliki cookie innych firm. (Jednak ustawienia użytkownika dotyczące konkretnej witryny mogą również zezwalać na dostęp do plików cookie w danej witrynie, nawet jeśli użytkownik domyślnie blokuje pliki cookie innych firm). Dostęp do pamięci za pomocą tego interfejsu API jest zachowywany w przypadku nawigacji w ramce iframe w ramach tej samej domeny, aby umożliwić ponowne wczytywanie po przyznaniu dostępu do stron, które wymagają plików cookie w pierwszym żądaniu dokumentu HTML.

Używaj klawisza requestStorageAccess()

Jeśli element iframe nie ma dostępu, może poprosić o niego 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 użytkownik po raz pierwszy poprosi o dostęp, może być konieczne zatwierdzenie go w oknie przeglądarki. Po tym obietnica zostanie spełniona lub odrzucona, co spowoduje wyjątek, jeśli użyto await.

Aby zapobiec nadużyciom, prośba w przeglądarce będzie wyświetlana tylko po interakcji użytkownika. Dlatego requestStorageAccess() musi być początkowo wywoływana z obsługi zdarzeń aktywowanych przez użytkownika, a nie natychmiast po wczytaniu elementu 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);

Prośby o uprawnienia

Gdy użytkownik kliknie przycisk po raz pierwszy, w większości przypadków automatycznie pojawi się w przeglądarce prośba o zezwolenie na powiadomienia, zwykle na pasku adresu. Zrzut ekranu poniżej pokazuje przykład komunikatu w Chrome, ale inne przeglądarki mają podobny interfejs:

W określonych okolicznościach przeglądarka może pominąć prośbę i automatycznie przyznać uprawnienia:

• Jeśli strona i element 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 w przypadku dostępu do pamięci.
• W przypadku przeglądarki Firefox pomijanie jest też włączone w przypadku znanych witryn (tych, z którymi użytkownik wchodził w interakcję na najwyższym poziomie) przez pierwsze 5 prób.

W określonych okolicznościach metoda może zostać automatycznie odrzucona bez wyświetlania prompta:

• 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 dokument najwyższego poziomu, a nie w ramach elementu iframe. Oznacza to, że interfejs Storage Access API jest przydatny tylko w przypadku umieszczonych witryn, które użytkownicy odwiedzili wcześniej w kontekście witryny własnej.
• Jeśli metoda requestStorageAccess() jest wywoływana poza zdarzeniem interakcji użytkownika bez wcześniejszego zatwierdzenia prompta po interakcji.

Podczas pierwszego użycia użytkownik zobaczy prośbę o wyrażenie zgody, ale podczas kolejnych wizyt w Chrome i Firefoxie requestStorageAccess() może zostać rozwiązany bez wyświetlania prośby i bez interakcji ze strony użytkownika. Pamiętaj, że Safari zawsze wymaga interakcji użytkownika.

Dostęp do plików cookie i pamięci może być przyznawany bez wyświetlania prośby lub interakcji użytkownika, dlatego w przeglądarkach, które to obsługują (Chrome i Firefox), często można uzyskać dostęp do plików cookie lub pamięci bez partycji przed interakcją użytkownika, wywołując funkcję requestStorageAccess() podczas wczytywania strony. Może to umożliwić natychmiastowy dostęp do plików cookie bez partycji i pamięci oraz zapewnić pełniejsze wrażenia, nawet zanim użytkownik wejdzie w interakcję z elementem iframe. W niektórych sytuacjach może to być wygodniejsze dla użytkowników niż czekanie na ich interakcję.

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ą...”) chroniące prywatność, które nie opiera się na plikach cookie innych firm ani przekierowaniach nawigacyjnych.

Gdy użytkownik loguje się na stronie zależnej, która zawiera treści osadzone od zewnętrznego dostawcy tożsamości, za pomocą FedCM, osadzone treści dostawcy tożsamości mogą automatycznie uzyskać dostęp do pamięci własnych niepodzielonych plików cookie najwyższego poziomu. Aby włączyć automatyczny dostęp do pamięci masowej za pomocą FedCM, musisz spełnić te warunki:

• Uwierzytelnianie FedCM (stan logowania użytkownika) musi być aktywne.
• Dostawca tożsamości 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 zagnieżdżony w elemencie rp.example. Gdy użytkownik zaloguje się za pomocą FedCM, element iframe idp.example może poprosić o dostęp do pamięci w przypadku własnych plików cookie najwyższego poziomu.

rp.example wysyła wywołanie FedCM, aby zalogować użytkownika za pomocą 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',
    }],
  },
});

Po zalogowaniu się użytkownika dostawca tożsamości może wywołać funkcję requestStorageAccess() z poziomu elementu iframe idp.example, o ile strona RP wyraźnie na to zezwoliła za pomocą zasad dotyczących uprawnień. Element osadzony automatycznie uzyska dostęp do miejsca na dane w przypadku własnego pliku cookie najwyższego poziomu bez aktywacji przez użytkownika i bez konieczności wyświetlania kolejnego monitu o uprawnienia:

// 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 zostanie przyznane automatycznie tylko wtedy, gdy użytkownik jest zalogowany za pomocą FedCM. Gdy uwierzytelnianie jest nieaktywne, do przyznawania dostępu do pamięci masowej stosuje się standardowe wymagania SAA.

Interfejs Storage Access API do przechowywania danych innych niż pliki cookie

Możesz poprosić o dostęp do niepodzielonej pamięci lokalnej, przekazując parametr types do wywołania requestStorageAccess. Aby na przykład poprosić o dostęp do niepartycjonowanej pamięci lokalnej, możesz wywołać funkcję requestStorageAccess({localStorage: true}).

Jeśli pliki cookie innych firm są włączone, ta metoda przyzna dostęp bez konieczności aktywacji przez użytkownika ani wyświetlania prośby o pozwolenie. Jeśli użytkownik wyłączył pliki cookie innych firm, przed przyznaniem dostępu do pamięci musisz go o to poprosić.

Najpierw sprawdź, czy przeglądarka ma już dostęp do pamięci:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

Jeśli pliki cookie innych firm są włączone, poproś o dostęp do pamięci masowej:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

Jeśli pliki cookie innych firm są blokowane (np. w trybie incognito), sprawdź uprawnienia do zapytań, aby zdecydować, czy wymagany jest komunikat dla użytkownika. navigator.permissions.query({name: 'storage-access'})Stan uprawnień może mieć te wartości:

• granted Użytkownik przyznał już dostęp. Wywołaj interfejs requestStorageAccess, aby uzyskać dostęp do niepodzielonej pamięci bez konieczności wyświetlania dodatkowego monitu dla użytkownika.
• prompt. Użytkownik nie przyznał jeszcze dostępu. Ustaw odbiornik kliknięć i po interakcji użytkownika ponownie wywołaj funkcję requestStorageAccess.
• error. To uprawnienie nie jest obsługiwane. Jeśli interfejs Storage Access API jest obsługiwany, to uprawnienie prawdopodobnie też jest obsługiwane.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

Pełny proces obsługi partycjonowanego miejsca na dane bez plików cookie można zaimplementować w ten sposób:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

Późniejsze wczytywanie za pomocą nagłówków Storage Access API

Nagłówki Storage Access to zalecany, bardziej wydajny sposób włączania wczytywania treści osadzonych, w tym zasobów innych niż iframe. Ta funkcja jest dostępna od Chrome 133. Dzięki nagłówkom dostępu do pamięci przeglądarka może rozpoznać, kiedy użytkownik przyznał już storage-access uprawnienia do domeny innej firmystorage-access w bieżącym kontekście, i może wczytywać zasoby z dostępem do niepodzielonych plików cookie podczas kolejnych wizyt.

Przepływ nagłówków dostępu do pamięci

W przypadku nagłówków Storage Access kolejne wizyty na stronach będą wywoływać ten proces:

1. Użytkownik odwiedził wcześniej witrynę website.example, która zawiera zasób calendar.example, i przyznał witrynie storage-access uprawnienia za pomocą wywołania document.requestStorageAccess().
2. Użytkownik ponownie odwiedza stronę website.example, na której jest osadzony zasób calendar.example. To żądanie nie ma jeszcze dostępu do pliku cookie, tak jak wcześniej. Użytkownik przyznał jednak wcześniej storage-access uprawnienia, a żądanie pobrania zawiera nagłówek Sec-Fetch-Storage-Access: inactive, co oznacza, że dostęp do niepodzielonych plików cookie jest dostępny, ale nieaktywny.
3. Serwer calendar.example odpowiada nagłówkiem Activate-Storage-Access: retry; allowed-origin='<origin>' (w tym przypadku <origin> to https://website.example), aby wskazać, że pobieranie zasobu wymaga użycia niepodzielonych plików cookie z uprawnieniem storage-access.
4. Przeglądarka ponawia żądanie, tym razem uwzględniając niepodzielone pliki cookie (aktywując uprawnienie storage-access dla tego i kolejnych pobrań).
5. calendar.example Serwer odpowiada spersonalizowaną treścią elementu iframe. Odpowiedź zawiera nagłówek Activate-Storage-Access: load, który wskazuje, że przeglądarka powinna wczytać treść z aktywnym uprawnieniem storage-access (czyli wczytać z dostępem do niepodzielonych plików cookie, tak jakby wywołano funkcję document.requestStorageAccess()).
6. Agent użytkownika wczytuje zawartość elementu iframe z niepodzielonym dostępem do plików cookie za pomocą uprawnienia storage-access. Po wykonaniu tego kroku widżet będzie działać zgodnie z oczekiwaniami.

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

W tabeli poniżej znajdziesz nagłówki interfejsu Storage Access API.

Na przykład nagłówki Storage Access Headers można użyć do wczytania obrazu z domeny innej firmy:

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

W tym przypadku server.example powinno wdrożyć po stronie serwera tę logikę:

  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')
  }
});

Wersja demonstracyjna interfejsu Storage Access API osadza treści innych firm (w tym obraz niebędący elementem iframe) za pomocą nagłówków dostępu do pamięci.

Użyj zapytania o uprawnienie storage-access

Aby sprawdzić, czy dostęp można przyznać bez interakcji z użytkownikiem, możesz sprawdzić stan uprawnienia storage-access i wcześniej wywołać funkcję requestStoreAccess() tylko wtedy, gdy nie jest wymagana żadna czynność użytkownika. W przeciwnym razie wywołanie funkcji zakończy się niepowodzeniem.

Możesz też z wyprzedzeniem zająć się potrzebą wyświetlenia prośby, wyświetlając inne treści, np. przycisk logowania.

Poniższy kod dodaje do wcześniejszego przykładu sprawdzanie 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 trybie piaskownicy

Jeśli używasz interfejsu Storage Access API w piaskownicowych elementach iframe, wymagane są te uprawnienia piaskownicy:

• allow-storage-access-by-user-activation jest wymagane, aby zezwolić na dostęp do interfejsu Storage Access API.
• allow-scripts jest wymagane, aby zezwolić na używanie JavaScriptu do wywoływania interfejsu API.
• allow-same-origin musi zezwalać na dostęp do plików cookie i innych form przechowywania 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ą być ustawione z tymi 2 atrybutami:

• SameSite=None – jest wymagany do oznaczenia pliku cookie jako dostępnego w kontekście innych stron.
• Secure, co zapewnia dostęp tylko do plików cookie ustawionych przez witryny HTTPS.

W przypadku przeglądarek Firefox i Safari pliki cookie mają domyślnie ustawioną wartość 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 umożliwia dostęp do plików cookie innych firm w osadzonych elementach iframe.

Istnieją też inne przypadki użycia, w których strona najwyższego poziomu wymaga dostępu do plików cookie innych firm. Na przykład obrazy lub skrypty, do których dostęp jest ograniczony przez pliki cookie, a właściciele witryn mogą chcieć umieścić je bezpośrednio w dokumencie najwyższego poziomu, a nie w ramce 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 w przypadku zasobów najwyższego poziomu. Można go używać tylko w przypadku witryn w zestawie powiązanych witryn, aby zapobiec przyznawaniu 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ć dostęp do requestStorageAccessFor().

Czym różni się interfejs Storage Access API, gdy jest używany z RWS?

Gdy zestawy powiązanych witryn są używane z interfejsem Storage Access API, dostępne są pewne dodatkowe funkcje, które zostały opisane w tabeli poniżej:

Prezentacja: ustawianie plików cookie i uzyskiwanie do nich dostępu

Poniższa wersja demonstracyjna pokazuje, jak plik cookie ustawiony przez Ciebie na pierwszym ekranie wersji demonstracyjnej może być dostępny w ramce umieszczonej w drugiej witrynie wersji demonstracyjnej:

storage-access-api-demo.glitch.me

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

• Chrome w wersji 118 lub nowszej z ustawioną flagą chrome://flags/#test-third-party-cookie-phaseout i ponownie uruchomioną przeglądarką.
• Firefox
• Safari

Wersja demonstracyjna: ustawianie pamięci lokalnej

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

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

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

Zasoby

• Przeczytaj specyfikację dotyczącą dostępu do plików cookie innych firm lub zgłaszaj problemy.
• Zapoznaj się ze specyfikacją, która zapewnia dostęp do niepodzielonego miejsca na dane, lub zgłaszaj problemy.
• Dokumentacja API i przewodnik.
• Dokumentacja Chrome dotycząca korzystania z interfejsu Storage Access API w zestawach powiązanych witryn