Interfejs Storage Access API

Chrome wycofuje obsługę plików cookie innych firm, aby ograniczyć śledzenie w witrynach. Stanowi to wyzwanie dla witryn i usług, które w kontekście osadzonym korzystają z plików cookie w celach takich jak uwierzytelnianie. Storage Access API (SAA) sprawia, że te przypadki użycia mogą działać bez przerw, przy jednoczesnym jak największym stopniu ograniczenia śledzenia w witrynach.

Stan implementacji

Obsługa przeglądarek

  • 119
  • 85
  • 65
  • 11.1

Źródło

Interfejs Storage Access API jest dostępny we wszystkich popularnych przeglądarkach, ale występują niewielkie różnice w implementacji. Różnice te zostały omówione w odpowiednich sekcjach tego posta.

Pracujemy nad rozwiązaniem wszystkich pozostałych problemów blokujących przed standaryzacją interfejsu API.

Czym jest Storage Access API?

Storage Access API to interfejs API JavaScript, który umożliwia elementom iframe żądanie uprawnień dostępu do pamięci, gdy dostęp byłby odmówiony przez ustawienia przeglądarki. Obiekty umieszczone w przypadkach użycia, które wymagają wczytywania zasobów z innych witryn, mogą w razie potrzeby prosić użytkownika o przyznanie uprawnień dostępu za pomocą interfejsu API.

Jeśli użytkownik zaakceptuje prośbę, element iframe będzie miał dostęp do swoich plików cookie pochodzących z innych witryn, które są też dostępne dla użytkowników odwiedzających witrynę najwyższego poziomu.

Interfejs Storage Access API umożliwia użytkownikowi dostęp do określonych plików cookie z innych witryn przy minimalnym obciążeniu użytkownika, a jednocześnie blokuje dostęp do ogólnych plików cookie z innych witryn, który jest często wykorzystywany do śledzenia użytkowników.

Przykłady zastosowań

Aby zapewnić lepsze wrażenia użytkownikom, niektóre elementy osadzone innych firm wymagają dostępu do plików cookie innych firm, co nie będzie dostępne po wycofaniu plików cookie innych firm.

Przykłady:

  • Umieszczone widżety komentarzy, które wymagają danych do sesji logowania.
  • przyciski „Lubię to” w mediach społecznościowych, które wymagają danych sesji logowania;
  • Umieszczone dokumenty, które wymagają szczegółów sesji logowania.
  • możliwość korzystania z dodatkowych funkcji dostępnych w umieszczonym filmie (np. w celu niewyświetlania reklam zalogowanym użytkownikom, poznawania preferencji użytkownika dotyczących napisów lub ograniczania określonych typów filmów);
  • Wbudowane systemy płatności.

W wielu z tych przypadków użycia utrzymuje się możliwość logowania w osadzonych elementach iframe.

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

Interfejs Storage Access API jest jedną z alternatywnych rozwiązań dla plików cookie innych firm, dlatego ważne jest, aby wiedzieć, kiedy należy używać tego interfejsu API w porównaniu z innymi. Ta funkcja jest przydatna w sytuacjach, w których spełnione są oba te warunki:

  • Użytkownik będzie wchodzić w interakcje z umieszczoną treścią – czyli nie jest to pasywny ani ukryty element iframe.
  • Użytkownik odwiedził umieszczone źródło w kontekście najwyższego poziomu, czyli gdy to źródło nie jest umieszczone w innej witrynie.

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

  • Pliki cookie w niezależnym stanie partycjonowania (CHIPS) pozwalają deweloperom dodać plik cookie do „partycjonowanej” pamięci masowej z osobnym kontenerem plików cookie dla każdej witryny najwyższego poziomu. Na przykład widżet zewnętrznego czatu internetowego może zapisywać informacje o sesji za pomocą pliku cookie. Informacje o sesji są zapisywane dla poszczególnych witryn, więc plik cookie ustawiany przez widżet nie wymaga dostępu do innych witryn, w których został również umieszczony. Interfejs Storage Access API jest przydatny, gdy osadzony widżet innej firmy wymaga udostępniania tych samych informacji w różnych źródłach (na przykład w przypadku szczegółów lub ustawień sesji po zalogowaniu).
  • Zestawy powiązanych witryn (RWS) to sposób organizacji na deklarowanie relacji między witrynami, dzięki czemu przeglądarki zezwalają na ograniczony dostęp do plików cookie innych firm w określonych celach. Witryny nadal muszą prosić o dostęp za pomocą interfejsu Storage Access API, ale w przypadku witryn z zestawu użytkownik może go przyznać bez pytania.
  • Federated Credential Management (FedCM) to rozwiązanie do obsługi tożsamości sfederowanej, które chroni prywatność użytkowników. Interfejs Storage Access API odpowiada za dostęp do plików cookie po zalogowaniu. W niektórych przypadkach FedCM stanowi alternatywne rozwiązanie dla interfejsu Storage Access API. Może być preferowanym rozwiązaniem, ponieważ wyświetla w przeglądarce prośbę o logowanie. Jednak wdrożenie FedCM zwykle wymaga wprowadzenia dodatkowych zmian w kodzie, na przykład obsługi punktów końcowych HTTP.
  • Istnieją również interfejsy API zapobiegające oszustwom, powiązane z reklamami i pomiary, a interfejs Storage Access API nie jest przeznaczony do radzenia sobie z tymi problemami.

Korzystanie z interfejsu Storage Access API

Interfejs Storage Access API ma 2 obiecane metody:

Integruje się też z interfejsem Permissions API. Dzięki temu możesz sprawdzić stan uprawnienia dostępu do pamięci w kontekście firmy zewnętrznej i wskazać, czy wywołanie do document.requestStorageAccess() zostanie przyznane automatycznie:

Za pomocą metody hasStorageAccess()

Po wczytaniu witryny może użyć metody hasStorageAccess(), aby sprawdzić, czy dostęp do plików cookie innych firm nie 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 via the Storage Access API.
    // Note on page load this will always be false initially so we could be
    // skipped in this example, but including for completeness for when this
    // is not so obvious.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Dostęp do pamięci jest przyznawany dokumentowi iframe tylko po wywołaniu przez niego funkcji requestStorageAccess(),, więc hasStorageAccess() zawsze na początku zwraca wartość false (fałsz), chyba że dostęp został już przyznany innym dokumentom z tej samej domeny w tym samym elemencie iframe. Przyznanie dostępu jest zachowywane w elementach nawigacyjnych z tej samej domeny w elemencie iframe, aby umożliwić ponowne ładowanie po udzieleniu dostępu stronom, które wymagają plików cookie w pierwszym żądaniu dokumentu HTML.

Za pomocą metody requestStorageAccess()

Jeśli element iframe nie ma dostępu, być może trzeba będzie 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;
  }
}

Przy pierwszym wysłaniu tej prośby użytkownik może zobaczyć prośbę o zatwierdzenie dostępu za pomocą komunikatu w przeglądarce. Gdy to nastąpi, obietnica zostanie rozwiązana lub odrzucona, co spowoduje powstanie wyjątku w przypadku użycia metody await.

Aby zapobiec nadużyciom, ten komunikat w przeglądarce wyświetli się tylko po interakcji użytkownika. Dlatego komponent requestStorageAccess() musi być początkowo wywoływany z modułu 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 above 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 przyznanie uprawnień

Gdy użytkownik kliknie przycisk po raz pierwszy, automatycznie pojawi się monit przeglądarki, zwykle na pasku adresu. Poniżej znajdziesz przykład komunikatu, który Chrome może wyświetlić, ale inne przeglądarki mają podobny interfejs:

Zrzut ekranu z prośbą o przyznanie dostępu do interfejsu Chrome Storage Access API
Prośba o uprawnienia do interfejsu Storage Access API w Chrome

Przeglądarka może pominąć prompt, a w pewnych okolicznościach uprawnienia zostaną automatycznie przyznane:

  • Czy strona i element iframe były używane w ciągu ostatnich 30 dni po zaakceptowaniu prośby.
  • Jeśli umieszczony element iframe jest częścią zestawu powiązanych witryn.
  • W Firefoksie prośba jest też pomijana w przypadku znanych stron internetowych (tych, z których wchodzisz w interakcje na najwyższym poziomie) w pierwszych 5 próbach.

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

  • Jeśli użytkownik nie odwiedził wcześniej witryny, do której należy element iframe, jako dokument najwyższego poziomu, a nie w elemencie iframe. Oznacza to, że interfejs Storage Access API jest przydatny tylko w przypadku umieszczonych witryn, które użytkownicy odwiedzili wcześniej we własnym kontekście.
  • Jeśli metoda requestStorageAccess() jest wywoływana poza zdarzeniem interakcji użytkownika bez uprzedniego zatwierdzenia promptu po interakcji.

Użytkownik zostanie poinformowany o tym przy pierwszym użyciu, jednak przy kolejnych wizytach może rozwiązać problem z requestStorageAccess() bez pytania i bez konieczności interakcji ze strony użytkownika w przeglądarkach Chrome i Firefox. Przeglądarka Safari zawsze wymaga interakcji użytkownika.

Dostęp do plików cookie może być przyznawany bez pytania lub interakcji użytkownika, dlatego często można uzyskać dostęp do plików cookie innych firm, zanim użytkownik wejdzie w interakcję z przeglądarką, która je obsługuje (Chrome i Firefox), wywołując requestStorageAccess() podczas wczytywania strony. Może to umożliwić natychmiastowy dostęp do plików cookie innych firm i zwiększyć ich wygodę, nawet zanim użytkownik wejdzie w interakcję z elementem iframe. W niektórych sytuacjach może to zapewnić użytkownikowi większy komfort niż czekanie na jego interakcję.

Korzystanie z zapytania o uprawnienie storage-access

Aby sprawdzić, czy można przyznać dostęp bez udziału użytkownika, możesz sprawdzić stan uprawnienia storage-access i wywołać requestStoreAccess() z wyprzedzeniem tylko wtedy, gdy nie jest wymagane żadne działanie ze strony użytkownika. Zamiast tego możesz wywołać błąd, gdy wymagana jest interakcja.

Dzięki temu możesz też wcześniej wyświetlać różne treści, np. przycisk logowania.

Ten kod dodaje kontrolę uprawnień storage-access do wcześniejszego przykładu:

// 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 older 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') {
            // Currently not used. See:
      // https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by one of above.
  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 elementach iframe w trybie piaskownicy, musisz mieć te uprawnienia piaskownicy:

  • Aby zezwolić na dostęp do interfejsu Storage Access API, musisz wykonać uprawnienie allow-storage-access-by-user-activation.
  • Element allow-scripts jest wymagany do wywoływania interfejsu API przy użyciu JavaScriptu.
  • Ustawienie allow-same-origin jest wymagane, aby umożliwić dostęp do plików cookie z tej samej domeny i innych elementów do przechowywania.

Na przykład:

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

Aby można było uzyskać dostęp do interfejsu Storage Access API w Chrome, pliki cookie w różnych witrynach muszą być skonfigurowane za pomocą tych 2 atrybutów:

  • SameSite=None – wymagany do oznaczenia pliku cookie jako pochodzącego z innej witryny.
  • Secure – zapewnia dostęp tylko do plików cookie ustawianych przez witryny HTTPS.

W Firefoksie i Safari domyślny jest atrybut SameSite=None, który nie ogranicza SSA do Secure plików cookie, więc te atrybuty nie są wymagane. Zalecamy jednoznaczne informowanie o atrybucie SameSite i zawsze używanie plików cookie Secure.

Dostęp do strony najwyższego poziomu

Interfejs Storage Access API służy do umożliwienia dostępu do plików cookie innych firm w ramach osadzonych elementów iframe.

Są też inne przypadki użycia, gdy strona najwyższego poziomu wymaga dostępu do plików cookie innych firm. Dotyczy to na przykład obrazów lub skryptów ograniczonych przez pliki cookie, które właściciele witryn mogą chcieć uwzględnić bezpośrednio w dokumencie najwyższego poziomu, a nie w elemencie iframe. Aby rozwiązać ten problem, Chrome zaproponował rozszerzenie interfejsu Storage Access API, które dodaje metodę requestStorageAccessFor().

Metoda requestStorageAccessFor()

Obsługa przeglądarek

  • 119
  • 119
  • x
  • x

Źródło

Metoda requestStorageAccessFor() działa podobnie do metody requestStorageAccess(), ale w przypadku zasobów najwyższego poziomu. Można go używać tylko w witrynach w zestawie powiązanych witryn, aby uniemożliwić przyznawanie ogólnego dostępu do plików cookie innych firm.

Aby dowiedzieć się więcej o korzystaniu z usługi requestStorageAccessFor(), przeczytaj przewodnik dla programistów o zestawach powiązanych witryn.

Zapytanie o uprawnienia top-level-storage-access

Obsługa przeglądarek

  • 119
  • 119
  • x
  • x

Podobnie jak w przypadku uprawnienia storage-access, istnieje uprawnienie top-level-storage-access umożliwiające sprawdzenie, czy można przyznać dostęp użytkownikowi requestStorageAccessFor().

Czym różni się interfejs Storage Access API w przypadku używania RWS?

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

Bez RWS Z systemem RWS
Wymaga gestu użytkownika w celu wysłania prośby o dostęp do pamięci
Wymaga od użytkownika odwiedzenia żądanego źródła pamięci w kontekście najwyższego poziomu przed przyznaniem dostępu
Prompt użytkownika po raz pierwszy można pominąć
Nie trzeba wywołać aplikacji requestStorageAccess, jeśli dostęp został wcześniej przyznany
Automatycznie przyznaje dostęp do innych domen w witrynie powiązanej witryny
Obsługuje requestStorageAccessFor dla dostępu do strony najwyższego poziomu
Różnice w korzystaniu z interfejsu Storage Access API bez zestawów powiązanych witryn i z nimi

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

Poniższy przykład pokazuje, jak można uzyskać dostęp do pliku cookie umieszczonego przez Ciebie na pierwszym ekranie prezentacji w ramce umieszczonej w drugiej witrynie:

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 ponownym uruchomieniem przeglądarki.
  • Firefox
  • Safari

Zasoby