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

Najnowsza wersja zestawów źródeł własnych jest gotowa do testowania flagi funkcji przez deweloperów w Chrome 108. Aktywnie pracujemy nad zestawami danych własnych, aby wprowadzić je do użytku. Dlatego będziemy uwzględniać opinie z tej fazy testów dla deweloperów do czasu wydania Chrome 111 na początku marca (7 marca 2023 r.).

Opinie dotyczące ekosystemu wskazują na przypadki użycia w wielu witrynach, które zostaną dotknięte, gdy pliki cookie innych firm nie będą już obsługiwane w Chrome. Propozycja dotycząca zestawów danych własnych analizuje i rozwiązuje problemy związane z zastosowaniami w wielu witrynach, w których powiązane ze sobą witryny mają relację, którą można przekazać przeglądarce, aby mogła ona podjąć odpowiednie działania w imieniu użytkownika lub skutecznie przedstawić mu te informacje.

Zaktualizowana propozycja używa 2 interfejsów API (Storage Access API i nowego interfejsu API o tymczasowej nazwie requestStorageAccessForOrigin), aby zapewnić witrynom aktywną metodę żądania dostępu do plików cookie w ramach zestawu danych własnych w różnych witrynach. Dzięki podanym niżej instrukcjom możesz przetestować i potwierdzić, jakie zbiory warto utworzyć dla swoich witryn i w jakich miejscach należy wywoływać 2 interfejsy API.

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

Zestawy źródeł własnych to mechanizm platformy internetowej, który umożliwia deweloperom deklarowanie relacji między witrynami, aby przeglądarki mogły używać tych informacji do umożliwienia ograniczonego dostępu do plików cookie w różnych witrynach w określonych celach związanych z użytkownikami. Chrome będzie używać tych zadeklarowanych relacji do podejmowania decyzji o tym, czy zezwolić stronie na dostęp do plików cookie w kontekście innych firm.

Ogólnie rzecz biorąc, zestaw źródeł własnych to zbiór domen, w których przypadku istnieje jeden „element domowy podstawowy” i potencjalnie wiele „elementów domostych”. Tylko autorzy witryn mogą przesyłać swoje domeny do zbioru. Muszą oni zadeklarować relację między każdym „elementem zbioru” a jego „elementem głównym”. Członkowie zbioru mogą obejmować różne typy domen z podzbiorami na podstawie przypadków użycia.

Aby ułatwić przeglądarce obsługę poszczególnych podzbiorów zgodnie z ich wpływem na prywatność, proponujemy wykorzystanie interfejsu Storage Access API (SAA) i interfejsu requestStorageAccessForOrigin w celu umożliwienia dostępu do plików cookie w ramach FPS.

Dzięki temu witryny mogą aktywnie prosić o dostęp do plików cookie w innych witrynach. Chrome automatycznie zatwierdzi żądanie, jeśli strona, która je wysyła, i witryna najwyższego poziomu znajdują się w tym samym FPS. Informacje o tym, jak inne przeglądarki przetwarzają wywołania interfejsu Storage Access API (SAA), znajdziesz w dokumentacji interfejsu Storage Access API (SAA).

Obecnie SAA wymaga, aby dokument uzyskał aktywację użytkownika przed wywołaniem metod interfejsu API.

Może to utrudnić stosowanie FPS w przypadku witryn najwyższego poziomu, które używają obrazów w różnych witrynach lub tagów skryptu wymagających plików cookie. Aby rozwiązać niektóre z tych problemów, proponujemy nowy interfejs API, requestStorageAccessForOrigin, który ułatwi deweloperom wdrożenie tej zmiany. Ten interfejs API jest też dostępny do testowania.

Ustaw przesyłanie

Kanoniczna lista FPS będzie publicznie dostępną listą w formacie pliku JSON przechowywanym w nowym repozytorium FPS na GitHubie, który będzie służył jako źródło prawdy dla wszystkich zestawów. Chrome będzie używać tego pliku do stosowania się do jego zasad.

Więcej informacji o proponowanym procesie i wymaganiach dotyczących przesyłania zestawów znajdziesz w wytycznych dotyczących przesyłania treści. Możesz też przesłać zestaw, aby przetestować różne kontrole techniczne, które zweryfikują przesłane dane. Pamiętaj, że wszystkie przesłane dane zostaną usunięte, zanim FPS będzie dostępny w stabilnych wersjach Chrome.

Proces przesyłania zbiorów jest nadal aktywnie rozwijany, dlatego do testowania lokalnego możesz tworzyć zbiory tylko na wierszu poleceń i przekazywać je bezpośrednio do przeglądarki. W przypadku testów lokalnych nie trzeba przesyłać zestawu do repozytorium GitHub, aby przetestować flagi funkcji.

Jak przetestować lokalnie

Wymagania wstępne

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

Aby korzystać z nowych funkcji Chrome jeszcze przed ich udostępnieniem wszystkim użytkownikom, pobierz wersję beta lub do wczesnych testów przeglądarki Chrome.

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 oddzielonych przecinkami, o których mowa w tej sekcji, oraz podać zestaw powiązanych witryn jako obiekt JSON, który zostanie przekazany do --use-first-party-set.

Włącz FPS

FirstPartySets włącza FPS w Chrome.

FirstPartySets

Włączanie interfejsu Storage Access API

StorageAccessAPI

Włącza w Chrome interfejs Storage Access API (SAA), który umożliwia osadzonym elementom iframe korzystanie z interfejsu requestStorageAccess() do wysyłania żądań dostępu do plików cookie w kontekście wielu witryn, nawet gdy pliki cookie innych firm są blokowane przez przeglądarkę.

Pamiętaj, że gdy zostanie wywołana, requestStorageAccess() wymaga od użytkownika wykonania odpowiedniego gestu. W przyszłych wersjach Chrome mogą obowiązywać inne zestawy wymagań, ponieważ specyfikacja SAA wciąż się rozwija. Tutaj znajdziesz listę planowanych ulepszeń implementacji SAA w Chrome.

StorageAccessAPIForOriginExtension

Umożliwia witrynom najwyższego poziomu używanie requestStorageAccessForOrigin() do żądania dostępu do miejsca na dane w imieniu określonych źródeł. Jest to przydatne w przypadku witryn najwyższego poziomu, które używają obrazów lub tagów skryptów wymagających plików cookie w wielu witrynach. Rozwiązanie to rozwiązuje też niektóre z wyzwań związanych z wdrażaniem SAA.

Deklarowanie zbioru lokalnie

Zestaw źródeł własnych to zbiór domen, w których przypadku istnieje 1 „główna domena zestawu” i potencjalnie wiele „domen członkowskich”. Członkowie zbioru mogą obejmować różne typy domen z podzbiorami na podstawie przypadków użycia.

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

W przykładzie poniżej primary to domena główna, a associatedSites to domeny, które spełniają 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 możesz tworzyć zestawy tylko na poziomie wiersza poleceń i przekazywać je bezpośrednio do przeglądarki. Na potrzeby testów lokalnych nie będzie weryfikacji zestawów, ale gdy FPS zostanie udostępniony w stabilnych wersjach, wszystkie zestawy będą musiały zostać przesłane do repozytorium FPS na GitHubie i podlegać kryteriami weryfikacji.

Włącz interfejs FPS

PageInfoCookiesSubpage

Umożliwia wyświetlanie liczby klatek na sekundę w sekcji Informacje o stronie, do której można przejść z paska adresu.

PrivacySandboxFirstPartySetsUI

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

Sprawdź, czy pliki cookie innych firm są zablokowane

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

Zagadnienia związane z bezpieczeństwem

Ponieważ interfejs Storage Access API pozwala witrynom w wybranych przypadkach odzyskać dostęp do plików cookie innych firm, aplikacje internetowe mogą być podatne na ataki między witrynami i wyciek informacji. Witryny, które korzystają z plików cookie w kontekście wielu witryn, powinny być świadome ryzyka związanego z atakami CSRF i innymi atakami.

Planowane ulepszenia

Aby to poprawić, w przyszłych wersjach Chrome będą wymagane dodatkowe opcje zabezpieczeń, które zapewnią wyraźną zgodę na umieszczanie. Proponowane ulepszenia: przyznawanie dostępu tylko na poziomie ramki, wymaganie CORS w przypadku żądań z uprawnieniami oraz ograniczanie zakresu dostępu tylko 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 ustawieniem SameSite=None tylko w ramach kontekstów umieszczania na wielu stronach, w których przypadku interfejs Storage Access API jest istotny. Dopóki jednak wszystkie przeglądarki nie wycofają domyślnego dostępu do tych plików cookie, nie można zakładać, gdzie mogą być używane. Nie można zakładać, że dostęp będzie możliwy tylko w ramach FPS, i strony powinny nadal stosować standardowe sprawdzone metody zapewniania bezpieczeństwa.

Zaangażowanie i przesyłanie opinii

Testowanie lokalne to okazja do wypróbowania mechanizmu interfejsu Storage Access API w celu włączenia FPS oraz do podzielenia się opinią lub opisem problemów, które napotkasz. Dodatkowo przetestowanie procesu przesyłania zestawów w GitHubie to okazja do podzielenia się wrażeniami dotyczącymi procesu i kroków weryfikacji. Aby zaangażować się w proces i przesłać opinię na temat zaktualizowanej propozycji: