Chrome proponuje nowe rozwiązanie, które daje użytkownikom możliwość wyboru w sprawie plików cookie innych firm. Musisz przygotować swoją witrynę na potrzeby użytkowników, którzy zdecydują się na przeglądanie bez plików cookie innych firm.
Ta strona zawiera informacje o tym, na czym mogą polegać nadchodzące zmiany.
Typowe ścieżki użytkownika
Wiele procesów płatności i zakupów korzysta z plików cookie innych firm. W tabeli poniżej znajdziesz listę ścieżek użytkownika, które mogą zostać zakłócone, jeśli pliki cookie innych firm zostaną wyłączone, oraz sugestie dotyczące interfejsów API, których deweloperzy mogą użyć, aby uniknąć problemów. Ta lista może nie być wyczerpująca i może być aktualizowana w miarę udostępniania kolejnych rozwiązań Privacy Sandbox. Zachęcamy do przesłania opinii, jeśli natrafisz na inne scenariusze, na które ma wpływ ta zmiana.
Testowanie ścieżek użytkowników związanych z płatnościami
Najlepszym sposobem na sprawdzenie, czy ograniczenia dotyczące plików cookie innych firm wpływają na ścieżki użytkownika, jest przetestowanie ich przy włączonej opcji testowania plików cookie innych firm.
Aby się upewnić, że Twoja witryna działa zgodnie z oczekiwaniami, przetestuj tę procedurę z ograniczonym dostępem do plików cookie innych firm:
- Proces płatności w wielu witrynach: przetestuj procesy płatności, które korzystają z zewnętrznego dostawcy płatności (np. Płać za pomocą <nazwa-dostawcy>). Upewnij się, że:
- Przekierowanie zostało wykonane.
- Bramka płatności jest wczytana prawidłowo.
- Proces płatności może być zakończony bez błędów.
- Użytkownik zostaje przekierowany z powrotem do Twojej witryny zgodnie z oczekiwaniami.
- Panele płatności: sprawdź, czy widżety panelu transakcji działają zgodnie z oczekiwaniami, gdy pliki cookie innych firm są ograniczone. Sprawdź, czy użytkownik może:
- Otwórz panel.
- Wszystkie płatności są zgodne z oczekiwaniami.
- bezbłędnie poruszać się między różnymi sekcjami pulpitu (np. historia transakcji, szczegóły płatności);
- Zarządzanie formami płatności: sprawdź, czy widżety zarządzania formami płatności działają zgodnie z oczekiwaniami. Po zablokowaniu plików cookie innych firm sprawdź, czy:
- Dodawanie i usuwanie formy płatności działa zgodnie z oczekiwaniami.
- Nie ma to wpływu na płacenie za pomocą wcześniej zapisanych form płatności.
- Wykrywanie oszustw: porównaj działanie rozwiązania do wykrywania oszustw z wykorzystaniem plików cookie innych firm i bez nich.
- Czy blokowanie plików cookie innych firm powoduje konieczność wykonania dodatkowych czynności, które mogą utrudnić użytkownikom korzystanie z usługi?
- Czy nadal wykryje podejrzane wzorce, gdy pliki cookie innych firm są zablokowane w przeglądarce?
- Przycisk płatności spersonalizowany: sprawdź, czy przyciski płatności są wyświetlane prawidłowo, gdy pliki cookie innych firm są ograniczone.
- Czy użytkownik może nadal dokonywać zakupów, nawet jeśli spersonalizowany przycisk nie wyświetla jego preferowanej metody?
Płatność w wielu witrynach
Niektórzy dostawcy usług płatniczych mogą używać plików cookie innych firm, aby umożliwić użytkownikom dostęp do ich kont w wielu witrynach sprzedawców bez konieczności ponownego uwierzytelniania. Ta ścieżka użytkownika może być zaburzona w przypadku osób, które zdecydują się przeglądać internet bez plików cookie innych firm.
Wbudowane formularze płatności
Rozważ te domeny:
payment-provider.example
zapewnia usługi płatności w witrynach sprzedawców oraz przechowuje dane o płatnościach i sesjach użytkowników.merchant.example
to witryna, która zawiera formularz płatności udostępniony przezpayment-provider.example
.
Użytkownik właśnie zalogował się na stronie payment-provider.example
(np. podczas procesu płatności w innej witrynie). Użytkownik rozpoczyna proces płatności na stronie merchant.example
.
W przypadku dostępnych plików cookie innych firm formularz payment-provider.example
w ramach procesu płatności umieszczony na stronie merchant.example
miałby dostęp do własnego najwyższego poziomu plików cookie sesji ustawionych na stronie payment-provider.example
w kontekście najwyższego poziomu.
Jeśli jednak pliki cookie innych firm są zablokowane, element osadzony nie będzie miał dostępu do własnych plików cookie najwyższego poziomu.

rozwiązanie dostosowane do potrzeb klienta z FedCM,
Usługa payment-provider.example
powinna rozważyć wdrożenie FedCM, aby działać jako dostawca tożsamości. To podejście może być odpowiednie, gdy:
payment-provider.example
jest umieszczony na niezwiązanych stronach zewnętrznych.payment-provider.example
jest umieszczony w co najmniej 5 powiązanych witrynach.
Główną zaletą FedCM jest to, że interfejs może zapewnić użytkownikom więcej kontekstu dotyczących ich wyborów. Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną korzystającą z usługi (merchant.example
) a dostawcą tożsamości (payment-provider.example
). Strona korzystająca z usługi może obsługiwać co najmniej jednego dostawcę tożsamości, a interfejs FedCM będzie wyświetlany tylko warunkowo.
W zależności od potrzeb deweloperzy mogą wybrać tryb pasywny, w którym prompt FedCM pojawia się automatycznie, gdy użytkownik jest zalogowany u dostawcy tożsamości, lub tryb aktywny, w którym proces logowania powinien zostać uruchomiony po wykonaniu przez użytkownika określonego działania, np. kliknięciu przycisku płatności.
FedCM pełni też funkcję sygnału zaufania dla interfejsu Storage Access API (SAA), który umożliwia elementowi embedowanemu dostęp do niezagregowanych plików cookie najwyższego poziomu po tym, jak użytkownik wyrazi zgodę na logowanie się u dostawcy elementu embedowanego, bez konieczności wyświetlania dodatkowego prompta.
Rozwiązanie skupiające się na dostępie do pamięci
Innym interfejsem API, który warto wziąć pod uwagę, jest Storage Access API (SAA).
W przypadku SAA użytkownik będzie proszony o zezwolenie na dostęp do plików cookie najwyższego poziomu w ramach usługi payment-provider.example
. Jeśli użytkownik wyrazi zgodę na dostęp, formularz może się wyświetlać tak samo jak w przypadku dostępu do plików cookie innych firm.
Podobnie jak w przypadku FedCM, użytkownik będzie musiał zatwierdzić prośbę w przypadku każdej nowej witryny, w której jest umieszczony element payment-provider.example
. Aby dowiedzieć się, jak działa interfejs API, obejrzyj demonstrację interfejsu SAA.
Jeśli domyślny prompt SAA nie spełnia Twoich potrzeb, rozważ wdrożenie FedCM, aby uzyskać bardziej spersonalizowane rozwiązanie.
Zmniejsz utrudnienia dla użytkowników na niewielkiej liczbie powiązanych witryn
Jeśli witryna sprzedawcy i dostawca płatności należą do tej samej firmy, możesz użyć interfejsu API powiązanych zestawów witryn (RWS), aby zadeklarować relacje między domenami. Może to pomóc w zmniejszeniu trudności dla użytkowników: jeśli na przykład insurance.example
i payment-portal-insurance.example
znajdują się w tym samym RWS, payment-portal-insurance.example
automatycznie uzyska dostęp do własnych plików cookie najwyższego poziomu, gdy zostanie przesłane żądanie dostępu do pamięci w ramach kodu embedowanego payment-portal-insurance.example
.
Inne rozwiązania eksperymentalne
Innym eksperymentalnym interfejsem API, który może być przydatny w tym scenariuszu, jest Partitioned Popins. Interfejs API jest obecnie w fazie aktywnego rozwoju.
W przypadku podzielonych popinów użytkownik może zostać poproszony o podanie danych logowania, aby zalogować się w aplikacji payment-provider.example
w otwartym przez nią popinie.merchant.example
Miejsce na dane zostanie partycjonowane przez osobę otwierającą merchant.example
. W tym przypadku element payment-provider.example
embed będzie mieć dostęp do wartości pamięci ustawionych w pop-inie. W ramach tego rozwiązania użytkownik musi zalogować się w witrynie dostawcy usług płatniczych.
Płatność za pomocą linku
Niektórzy dostawcy usług płatniczych oferują usługę generowania linku do płatności, który powoduje wyświetlenie niestandardowej strony płatności w witrynie sprzedawcy. Usługa linków do płatności i portal użytkownika dostawcy płatności są często wdrażane w różnych domenach, np. payment-provider.example
i payment-link.example
.
payment-link.example
umieszcza formularz płatności udostępniony przezpayment-provider.example
. To jest wariant wzorca osadzonego formularza płatności.
W tym przypadku warto też rozważyć FedCM, SAA i RWS.
Panele płatności
Niektóre aplikacje wyświetlają użytkownikom panele transakcji z różnych witryn, zapewniając im centralny widok ich działań finansowych. Wymaga to dostępu panelu do danych dotyczących użytkowników z różnych domen.
Rozważ te domeny:
earnings.example
udostępnia panel płatności, który można umieszczać w różnych aplikacjach internetowych. Ta usługa przechowuje dane o zarobkach użytkowników i informacje o sesji.catsitting.example
idogsitting.example
to osobne witryny, które zawierają panelearnings.example
.
Użytkownik loguje się na swoje konto earnings.example
. Gdy wejdą na stronę catsitting.example
lub dogsitting.example
, mogą sprawdzić swoje zarobki.
Wbudowany panel earnings.example
korzysta z plików cookie najwyższego poziomu i wyświetla spersonalizowane informacje o zarobkach użytkownika.
Podobnie jak w innych przykładach, gdy pliki cookie innych firm są wyłączone, kod earnings.example
nie będzie miał dostępu do plików cookie najwyższego poziomu.

Panele własne
Jeśli wszystkie 3 domeny należą do tej samej strony, rozważ użycie SAA w połączeniu z RWS.
Dzięki SAA usługa earnings.example
może uzyskać dostęp do pliku cookie najwyższego poziomu z uprawnieniami użytkownika. Jeśli ta strona używa earnings.example
w 4 lub mniej domenach,
deklarowanie relacji między nimi za pomocą RWS może zapewnić płynniejsze wrażenia użytkownika.
Jeśli ta sama osoba umieszcza widżet w większej liczbie niż 5 domen, nie może deklarować relacji między wszystkimi witrynami, w których widżet jest umieszczony, a domeną widżetu, ponieważ RWS obsługuje maksymalnie 6 witryn w zbiorze: jedną główną i 5 powiązanych.
Dystrybucja paneli skalowanych
W tych przypadkach SAA i RWS mogą nie być optymalnym rozwiązaniem:
- rozpowszechniasz rozwiązanie w postaci panelu dla witryn innych firm;
- masz więcej niż 5 witryn, które zawierają widżet panelu.
W takim przypadku earnings.example
powinna rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. Oznacza to, że użytkownik musi zalogować się w systemie dogsitting.example
przy użyciu konta zarządzanego przez earnings.example
.
FedCM udostępnia interfejs użytkownika, który można dostosować, aby wyraźnie informować użytkowników, które informacje są udostępniane. Dzięki usłudze FedCM aplikacja dogsitting.example
może poprosić aplikację earnings.example
o udostępnienie specjalnych uprawnień, np. dostępu do danych o transakcjach.
FedCM pełni też funkcję znaku zaufania dla interfejsu Storage Access API, a w przypadku osadzenia earnings.example
zostanie przyznany dostęp do miejsca na dane dla własnych plików cookie najwyższego poziomu bez dodatkowego pytania użytkownika podczas wywołania interfejsu SAA API.
Ustawienia panelu dotyczące witryny
Jeśli danych nie trzeba udostępniać w wielu witrynach, rozważ podzielenie plików cookie za pomocą CHIPS. Pliki CHIPS mogą być przydatne do przechowywania ustawień dotyczących konkretnych witryn, na przykład układu lub filtrów panelu.
Zarządzaj formami płatności
Innym typowym scenariuszem jest wyświetlanie i edytowanie form płatności przez użytkownika w ramach wbudowanego elementu bez konieczności opuszczania witryny hosta.
Rozważ ten proces:
payments.example
udostępnia narzędzie do zarządzania płatnościami, które można umieszczać w witrynach. Ta usługa przechowuje dane płatności użytkownika i informacje o sesji.shop.example
to witryna, która zawiera narzędziepayments.example
umożliwiające użytkownikom wyświetlanie, edytowanie i wybieranie preferowanych form płatności powiązanych z ich kontemshop.example
.
Dostawcy usług płatniczych, którzy implementują zarządzanie formami płatności, powinni też rozważyć zostanie dostawcą tożsamości za pomocą FedCM. Dzięki FedCM użytkownik będzie mógł zalogować się na konto strony korzystającej (shop.example
) za pomocą konta zarządzanego przez dostawcę tożsamości (payments.example
).
Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną ufającą a dostawcą tożsamości. Główną zaletą korzystania z FedCM jest to, że interfejs użytkownika może zapewnić użytkownikom więcej kontekstu dotyczącego ich wyborów. Jest on też sygnałem zaufania dla interfejsu Storage Access API, który umożliwia dostęp do plików cookie najwyższego poziomu.
Gdy pliki cookie innych firm są wyłączone, w ramach funkcji payments.example
nie będzie można uzyskać dostępu do plików cookie najwyższego poziomu. W takim przypadku SAA może pomóc zapewnić prawidłowe działanie, prosząc o dostęp do pamięci masowej.
Czasami informacje zawarte w zawartym embedzie nie muszą być udostępniane innym witrynom, w których jest on umieszczony. payments.example
może być konieczne przechowywanie różnych preferencji użytkowników w przypadku każdej konkretnej witryny, w której treści są umieszczane. W takim przypadku rozważ podzielenie plików cookie za pomocą CHIPS. W przypadku CHIPS plik cookie utworzony w ramach payments.example
osadzonego w shop.example
nie będzie dostępny dla payments.example
osadzonego w another-shop.example
.
Innym eksperymentalnym interfejsem API, który można potencjalnie wykorzystać w tym procesie użytkownika, jest Partitioned Popins.
Gdy użytkownik zaloguje się w payments.example
w wyskakującym okienku otwartym przez
shop.example
, miejsce na dane zostanie podzielone przez osobę, która otworzyła okno, a element payments.example
wbudowany w inne aplikacje będzie mieć dostęp do wartości miejsca na dane ustawionych w wyskakującym okienku. Takie podejście wymaga jednak od użytkowników wpisywania danych logowania w przypadku każdego dostawcy usług płatniczych.
Wykrywanie oszustw
Systemy analizy ryzyka mogą analizować dane przechowywane w plikach cookie w celu identyfikowania wzorców odbiegających od normy. Jeśli na przykład użytkownik nagle zmieni adres dostawy i dokona kilku dużych zakupów za pomocą nowego urządzenia, może to zwiększyć wynik potencjalnego oszustwa. Pliki cookie służące do wykrywania oszustw to zazwyczaj pliki cookie innych firm, które są ustawiane na stronach sprzedawców przez dostawców płatności lub widżety usług zapobiegania oszustwom.
Ograniczenia plików cookie innych firm nie powinny zakłócać działania systemów wykrywania oszustw, ale mogą powodować dodatkowe problemy dla użytkowników. Jeśli system nie może z pewnością potwierdzić, że użytkownik jest autentyczny z powodu zablokowanych plików cookie, może wymagać dodatkowych kontroli, takich jak weryfikacja tożsamości.
Aby wykrywać oszustwa, gdy pliki cookie innych firm są zablokowane, rozważ zintegrowanie interfejsu Private State Tokens API (PST) z rozwiązaniem do wykrywania oszustw. Dzięki PST dostawca płatności może zarejestrować się jako wystawca tokenów i przyznawać użytkownikom tokeny, które nie są oparte na plikach cookie innych firm. Tokeny te można następnie wykorzystać na stronach sprzedawców w celu sprawdzenia, czy użytkownik jest godny zaufania. Szczegółowe informacje o wdrożeniu znajdziesz w dokumentacji dla programistów dotyczącej PST.
Piaskownica prywatności eksperymentuje z innymi interfejsami API do zwalczania oszustw.
Spersonalizowany przycisk finalizacji
Przyciski płatności (np. Zapłać za pomocą <preferowanej formy płatności>) umieszczone na stronach sprzedawców często korzystają z informacji z wielu witryn ustawionych przez dostawcę płatności. Umożliwia to personalizację, a użytkownicy mogą płacić za pomocą preferowanej formy płatności. Jeśli w przeglądarce użytkownika są zablokowane pliki cookie innych firm, może to mieć wpływ na renderowanie spersonalizowanego przycisku płatności.
Chociaż SAA może umożliwiać dostęp do pamięci, wymagany komunikat może nie zapewnić użytkownikom optymalnych wrażeń.
Rozważamy potencjalne rozwiązanie, które jest przeznaczone do tego konkretnego przypadku użycia: Fenced Frames z dostępem do lokalnych danych bez partycjonowania. Interfejs API jest obecnie w aktywnej fazie rozwoju, a Ty możesz mieć wpływ na jego przyszłość. Wypróbuj to samodzielnie i przekaż opinię.
Pomoc
Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem w GitHub w repozytorium pomocy dla deweloperów dotyczącej Piaskownicy prywatności.