Instrukcje testowania zestawów źródeł własnych

Najnowsza wersja zestawów źródeł własnych jest gotowa do testowania flagi funkcji dla programistów od Chrome 108. Pracujemy nad zestawami źródeł własnych w celu przejścia na dostawę, dlatego będziemy rozważać opinie na temat tego etapu testowania przez deweloperów aż do wprowadzenia Chrome 111, które nastąpi na początku marca (7 marca 2023 r.).

Opinie o ekosystemie wskazują przypadki użycia w różnych witrynach, na które wpłynie wyłączenie plików cookie innych firm w Chrome. Propozycja zestawów źródeł własnych analizuje i rozwiązuje grupę przypadków użycia w różnych witrynach, w których współzależne witryny są powiązane z przeglądarką w sposób możliwy do określenia, aby przeglądarka mogła wykonać odpowiednie działanie w imieniu użytkownika lub skutecznie zaprezentować mu te informacje.

Zaktualizowana oferta korzysta z 2 interfejsów API (interfejsu Storage Access API i nowego interfejsu API o wstępnie nazywanej „requestStorageAccessForOrigin”), aby zapewniać witrynom aktywną metodę wysyłania żądań dostępu do plików cookie z innych witryn w ramach zestawu źródeł własnych. Podane niżej instrukcje pozwolą Ci przetestować i sprawdzić, jakie zestawy możesz utworzyć dla swoich witryn, a także odpowiednie punkty do wywoływania tych 2 różnych interfejsów API.

Omówienie zestawów źródeł własnych

Zestawy źródeł własnych (FPS) to mechanizm platformy internetowej, który umożliwia deweloperom deklarowanie relacji między witrynami. Dzięki temu przeglądarki mogą używać tych informacji do ograniczonego dostępu do plików cookie z innych witryn w określonych celach widocznych dla użytkowników. Na podstawie tych zadeklarowanych relacji Chrome decyduje, kiedy zezwolić witrynie na dostęp do jej plików cookie, a kiedy zablokować jej dostęp do plików cookie firmy zewnętrznej.

Ogólnie zestaw źródeł własnych to zbiór domen, dla których istnieje 1 „ustawienie podstawowe” i potencjalnie większa liczba „zestawów elementów”. Tylko autorzy witryn mogą przesyłać swoje domeny do zbioru i muszą zadeklarować relację między każdym „elementem zestawu” a „ustawionym jako podstawową”. Elementy zestawu mogą obejmować wiele różnych typów domen z podzbiorami zależnie od przypadków użycia.

Aby ułatwić przeglądarce obsługę każdego podzbioru zgodnie z zasadami ochrony prywatności każdego z tych podzbiorów, zalecamy wykorzystanie interfejsów Storage Access API (SAA) i requestStorageAccessForOrigin w celu włączenia dostępu do plików cookie w ramach FPS.

Dzięki tej umowie witryny mogą prosić o dostęp z innych witryn do plików cookie. Chrome automatycznie spełni żądanie, jeśli witryna, która wysłała żądanie, i witryna najwyższego poziomu należą do tej samej liczby klatek na sekundę. Informacje o przetwarzaniu wywołań SAA przez inne przeglądarki znajdziesz w dokumentacji interfejsu Storage Access API (SAA).

Obecnie zgodnie z SAA dokument musi aktywować użytkownika przed wywołaniem metod interfejsu API.

Może to utrudniać wdrażanie technologii FPS w witrynach najwyższego poziomu, które używają obrazów z innych witryn lub tagów skryptu, które wymagają plików cookie. Aby rozwiązać niektóre z tych problemów, zaproponowaliśmy nowy interfejs API – requestStorageAccessForOrigin – który ułatwi deweloperom wdrożenie tej zmiany. Ten interfejs API jest też dostępny do testów.

Ustaw przesyłanie

Kanoniczna lista klatek na sekundę będzie widoczna publicznie w formacie pliku JSON i umieszczona w nowym repozytorium FPS na GitHubie, które będzie używane jako źródło danych dla wszystkich zbiorów. Chrome przetworzy plik, aby zastosować go do swojego działania.

Więcej informacji o proponowanym procesie i wymaganiach dotyczących przesyłania zestawów znajdziesz w wytycznych dotyczących przesyłania zestawów. Możesz też przesłać zestaw do przetestowania różnych testów technicznych, które pozwolą zweryfikować zgłoszenia. Pamiętaj, że wszystkie przesłane pliki zostaną wyczyszczone, zanim liczba klatek na sekundę będzie dostępna w stabilnych wersjach Chrome.

Ponieważ wciąż pracujemy nad procesem przesyłania zestawu, na potrzeby testów lokalnych możesz tworzyć zestawy tylko w wierszu poleceń i przekazywać je bezpośrednio do przeglądarki. W przypadku testów lokalnych nie musisz przesyłać zestawu do repozytorium GitHub, aby przetestować za pomocą flag funkcji.

Jak przeprowadzać testy lokalne

Wymagania wstępne

Aby przetestować FPS lokalnie, użyj Chrome 108 lub nowszej wersji uruchomionej z poziomu wiersza poleceń.

Aby zapoznać się z nadchodzącymi funkcjami Chrome jeszcze przed ich udostępnieniem wszystkim użytkownikom, pobierz przeglądarkę Chrome w wersji beta lub Canary.

Przykład

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Dowiedz się więcej o uruchamianiu Chromium z flagami.

Kroki

Aby włączyć FPS lokalnie, musisz użyć opcji --enable-features w Chrome z listą flag (rozdzielonych przecinkami) opisanych w tej sekcji oraz zadeklarować zbiór powiązanych witryn jako obiekt JSON do przekazania do --use-first-party-set.

Włącz FPS

FirstPartySets włącza klatki na sekundę w Chrome.

FirstPartySets

Włącz interfejs Storage Access API

StorageAccessAPI

Włącza w Chrome interfejs Storage Access API (SAA), dzięki któremu umieszczone elementy iframe mogą używać elementu requestStorageAccess(), by prosić o dostęp do plików cookie w kontekście innych witryn, nawet jeśli przeglądarka blokuje pliki cookie innych firm.

Pamiętaj, że wywołanie metody requestStorageAccess() wymaga gestu użytkownika w celu rozwiązania problemu. Ponieważ specyfikacja SAA wciąż się rozwija, kolejne wersje Chrome mogą mieć inne wymagania. Tutaj znajdziesz listę planowanych ulepszeń implementacji SAA w Chrome.

StorageAccessAPIForOriginExtension

Umożliwia witrynom najwyższego poziomu używanie requestStorageAccessForOrigin() do wysyłania próśb o dostęp do pamięci w imieniu określonych źródeł. Jest to przydatne w przypadku witryn najwyższego poziomu, które używają obrazów z innych witryn lub tagów skryptu wymagających plików cookie, a także rozwiązają niektóre problemy związane z wdrożeniem SAA.

Zadeklaruj zestaw lokalnie

Zestaw źródeł własnych to zbiór domen, dla których istnieje 1 ustawienie „Ustaw jako podstawową” i potencjalnie wiele „elementów zestawu”. Elementy zestawu mogą obejmować wiele różnych typów domen z podzbiorami zależnie od przypadków użycia.

Utwórz obiekt JSON zawierający adresy URL, które należą do zestawu, i przekaż go do funkcji --use-first-party-set.

W przykładzie poniżej primary zawiera domenę podstawową, a associatedSites zawiera domeny spełniające wymagania powiązanego podzbioru.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Przykład:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

W przypadku testów lokalnych zestawy można tworzyć tylko w wierszu poleceń i przekazywać je bezpośrednio do przeglądarki. Z uwagi na testy lokalne nie będzie określona walidacja. Jednak w przypadku wysyłania klatek FPS w wersji stabilnych wszystkie zestawy muszą zostać przesłane do repozytorium FPS na GitHubie i podlegać kryteriom weryfikacji.

Włącz interfejs FPS

PageInfoCookiesSubpage

Włącza wyświetlanie klatek na sekundę w sekcji PageInfo dostępnej z paska adresu URL.

PrivacySandboxFirstPartySetsUI

Włącza interfejs FPS „Zezwól powiązanym witrynom na dostęp do Twojej aktywności w grupie” w ustawieniach Chrome, w sekcji Prywatność i bezpieczeństwo → Pliki cookie i inne dane witryn (chrome://settings/cookies).

Jak sprawdzić, czy pliki cookie innych firm są blokowane

  1. W ustawieniach Chrome otwórz Prywatność i bezpieczeństwo → Pliki cookie i inne dane witryn lub wejdź na chrome://settings/cookies.
  2. W sekcji Ustawienia ogólne sprawdź, czy jest włączona opcja „Blokuj pliki cookie innych firm”.
  3. Sprawdź, czy włączona jest także podopcja „Zezwalaj powiązanym witrynom na dostęp do informacji o Twojej aktywności w grupie”.

Bezpieczeństwo

Interfejs Storage Access API umożliwia witrynom odzyskanie dostępu do plików cookie innych firm w niektórych przypadkach, dlatego aplikacje internetowe mogą być narażone na ataki między witrynami i wycieki informacji. Witryny, które używają plików cookie w różnych witrynach, powinny mieć świadomość ryzyka związanego z CSRF i innymi atakami.

Planowane ulepszenia

Aby to poprawić, kolejne wersje Chrome będą wymagać dodatkowych opcji zabezpieczeń. Dzięki temu użytkownicy będą mogli bez obaw dodawać użytkowników do swoich witryn. Proponowane ulepszenia: przyznawały dostęp tylko na poziomie ramki, wymagały CORS w przypadku żądań z danymi uwierzytelniającymi i zachowywały zakres dostępu wyłącznie do źródła. Więcej informacji znajdziesz w ostatniej analizie zabezpieczeń.

Zapoznaj się z listą planowanych ulepszeń implementacji SAA w Chrome.

Pamiętaj, że Chrome wysyła pliki cookie z oznaczeniem SameSite=None tylko w kontekście elementów osadzonych w innych witrynach, co ma zastosowanie do interfejsu Storage Access API. Dopóki wszystkie przeglądarki nie wycofają domyślnego dostępu do tych plików, nie można podejmować żadnych założeń dotyczących miejsc, w których plik cookie może być używany. Nie należy zakładać, że dostęp jest dozwolony wyłącznie w ramach FPS, a witryny powinny nadal stosować standardowe sprawdzone metody dotyczące bezpieczeństwa.

Angażuj i dziel się opiniami

Testy lokalne to okazja do wypróbowania mechanizmu interfejsu Storage Access API, który pozwala włączyć obsługę FPS, i podzielenia się opiniami lub informacjami na temat ewentualnych problemów. Dodatkowo możesz przetestować proces przesyłania zestawu na GitHubie, aby podzielić się wrażeniami z procesu i weryfikacji. Aby skontaktować się z nami i przekazać opinię na temat zaktualizowanej oferty pakietowej: