Zestawy powiązanych stron – nowa nazwa zestawów źródeł własnych w Chrome 117

W ramach przygotowań do wycofania plików cookie innych firm, które mają zostać wycofane w 2024 roku, interfejsy API Piaskownicy prywatności stają się ogólnie dostępne w wersji stabilnej Chrome. Niektóre z tych interfejsów API pomogą zachować kluczowe przypadki użycia plików cookie w różnych witrynach, np. CHIPS czy interfejs API, który obecnie nosi nazwę zestawów źródeł własnych (FPS). W tym poście przedstawiamy zestawy powiązanych witryn (ang. Related Websitesets, RWS) – naszą nową nazwę platformy, która lepiej odzwierciedla jej przeznaczenie – i przypominamy jej najważniejsze przypadki użycia, a także aktualizujemy limit powiązanych domen.

Zachowywanie najważniejszych ścieżek użytkowników

RWS zostało zaprojektowane tak, aby zminimalizować zakłócenia w działaniu określonych funkcji dla użytkownika, gdy Chrome zacznie domyślnie ograniczać dostęp do plików cookie innych firm. Naszym celem jest umożliwienie użytkownikom przeglądania internetu przy minimalnym nakładzie pracy przy jednoczesnym zachowaniu celów w zakresie prywatności Piaskownicy prywatności. Aby to osiągnąć, RWS kieruje reklamy na konkretne przypadki użycia związane z funkcjami witryny:

  • Przypadek użycia ccTLD dotyczy naruszeń takich jak przykład logowania podany w naszym publicznym narzędziu do śledzenia. Takie przypadki są często rozpatrywane w ekosystemie za pomocą wyjątków heurystycznych (patrz odniesienie 1).
  • Przypadek użycia domeny usługi dotyczy popularnej metody programistycznej, która polega na odizolowaniu funkcji poufnych (takich jak obsługa przepływu uwierzytelniania) od domen, z których korzystają użytkownicy. Takie przypadki mogą być rozwiązywane w ekosystemie za pomocą kierowanych wyjątków (patrz odniesienie 2).
  • Przypadek użycia powiązanej domeny zapewnia większą elastyczność w zakresie typów domen, które mogą wymagać dostępu do plików cookie innych firm w przypadku kluczowych ścieżek użytkownika (patrz ref. 3). W przypadku domen ccTLD i domen usług stosowane są rygorystyczne kontrole techniczne oparte na cechach domeny, które mają na celu zminimalizowanie nadużyć. W przypadku domen powiązanych z kontem obowiązuje limit liczbowy. Więcej informacji na ten temat można znaleźć w następnej sekcji.

Zwiększono limit powiązanych domen do 5 domen

Wcześniej zaproponowaliśmy w Chrome ograniczenie liczbowe do 3 domen dla powiązanego podzbioru (plus 1 domeny podstawowej), aby zgodnie z naszym celem zapobiec powszechnemu nadużyciom śledzenia. Z opinii uczestników zajmujących się standardami internetowymi dowiedzieliśmy się, że limit był za niski dla różnych typów przypadków użycia.

Zdecydowaliśmy się zwiększyć limit powiązanych domen do 5 domen (oraz 1 domeny podstawowej), które najlepiej pasują do najbardziej porównywalnej implementacji oferowanej przez inną dużą przeglądarkę (patrz odniesienie 4). Zmiana zacznie obowiązywać w Chrome od wersji 117.

Ponieważ RWS nie jest rozwiązaniem reklamowym, nie bierzemy pod uwagę opinii na temat tego, jak ulepszyć tę usługę w celu lepszego wyświetlania reklam. W przypadku reklam deweloperzy powinni zapoznać się z interfejsami Topics, Protected Audience i Attribution Reporting API, a następnie odpowiednio przesłać opinię na ich temat.

Użytkownicy mają możliwość wyboru w przypadku wydłużonych przypadków użycia obejmujących ponad 5 powiązanych domen

W przypadku elementów, które mają wpływ na użytkowników, a które nie są obsługiwane w ramach tego limitu, Chrome stosuje proces wyświetlania próśb o zgodę na wykorzystanie danych, który wykorzystuje też interfejs Storage Access API (SAA) akceptowany przez inne przeglądarki. W przypadkach, które wymagają więcej niż 5 powiązanych domen, zachęcamy deweloperów do oceny, jak może być obsługiwane SAA w kontekstach innych niż RWS. Proces wdrażania Blink tej funkcji przeprowadzamy osobno w przypadku tej funkcji, która będzie wdrażana w Chrome na komputery od wersji Chrome 117.

Dalsze kroki

Jesteśmy wdzięczni za opinie dotyczące ekosystemu, które do tej pory pomogły w kształtowaniu interfejsu API. Zainwestowaliśmy w RWS, by zapewnić deweloperom przewidywalność i kontrolę, a także zapewniać sprawne działanie strony. Z niecierpliwością czekamy na to, jak deweloperzy zaczną wdrażać i wykorzystywać RWS w miarę rozwoju. Proces przesyłania już trwa, a doskonałym punktem wyjścia do pomocy przy przesyłaniu jest generator plików JSON RWS.

Postępy możesz śledzić w wątku dotyczący zamiaru wysyłki. Wskazówki dotyczące implementacji znajdziesz w tych materiałach.

Odniesienia

  1. W różnych przeglądarkach panuje ogólna zgoda na to, że takie przypadki użycia plików cookie pochodzących z różnych witryn są niezbędne, ale w celu ich uruchomienia stosowano inne podejście. W przeglądarkach Firefox (kod) i Safari (kod) zaimplementowano heurystyczne wyskakujące okienka z problemami zaobserwowanymi, np. w procesie logowania Nintendo.
  2. Istnieje również wiele przykładów sytuacji, w których przeglądarki na stałe dodają wyjątki od kodu sztywnego, aby zminimalizować zakłócenia w pracy użytkowników. Firefox przyznaje dostęp do pamięci w procesach przekierowania między Microsoft Teams a login.microsoftonline.us.
  3. Firefox udostępnia „shim” (podkładkę „shim”), która wywołuje żądanie requestStorageAccessForOrigin w imieniu witryny facebook.com, gdy użytkownik loguje się na instagram.com. Przykład grupowania witryn znajdziesz też w zakodowanych na stałe wyjątkach w przeglądarce Safari, które dotyczą próśb o dostęp do miejsca na dane w wielu domenach.
  4. Firefox automatycznie przyznaje 5 pierwszych wywołań requestStorageAccess wykonanych przez witrynę innej firmy (kod), które użytkownik już wcześniej odwiedził. W Chrome pierwszych 5 domen wymienionych w powiązanym podzbiorze (oprócz domeny podstawowej tego samego zestawu) otrzyma automatycznie dostęp do plików cookie innych firm za pomocą RWS.