Pliki cookie innych firm mogą być blokowane przez ograniczenia przeglądarki, ustawienia użytkownika, flagi dewelopera lub zasady firmy.
Twoja witryna lub usługa musi zapewniać komfort obsługi wszystkim użytkownikom, niezależnie od tego, czy pliki cookie innych firm są dostępne.
Na tej stronie znajdziesz informacje o scenariuszach związanych z tożsamością, które mogą być najbardziej podatne na ataki, a także informacje o możliwych rozwiązaniach.
Jeśli Twoja witryna obsługuje tylko przepływy w ramach tej samej domeny i jej subdomen, np. publisher.example i login.publisher.example, nie będzie używać plików cookie na wielu stronach, a proces logowania nie powinien być zależny od zmian w plikach cookie innych firm.
Jeśli jednak Twoja witryna używa osobnej domeny do logowania, np. logowania Google lub logowania Facebooka, lub jeśli Twoja witryna musi udostępniać uwierzytelnianie użytkownika w wielu domenach lub subdomenach, być może trzeba będzie wprowadzić w niej zmiany, aby zapewnić płynne przejście z plików cookie między witrynami.
Typowe ścieżki użytkownika
Wcześniej wiele procesów związanych z tożsamością polegało na plikach cookie innych firm. Tabela zawiera listę typowych ścieżek użytkowników oraz potencjalnych rozwiązań, które nie zależą od plików cookie innych firm. W następnych sekcjach wyjaśnimy, dlaczego te rekomendacje zostały wyświetlone.
Zalecane alternatywne interfejsy API do częstych zastosowań
w tabeli są na wczesnym etapie rozwoju. Twoja opinia jest dla nas cenna i pomoże nam udoskonalić nasze usługi. Podziel się opinią na temat tych interfejsów API: Partitioned Poppins.
| Ścieżka użytkownika | Zalecane interfejsy API |
|---|---|
| Logowanie się przez media społecznościowe |
Dostawcy tożsamości: wdrożenie FedCM Użytkownicy: skontaktuj się z dostawcą tożsamości |
|
W przypadku dostawców tożsamości lub rozwiązań niestandardowych:Powiązane zestawy witryn |
|
| Zarządzanie profilem użytkownika |
Storage Access API Powiązane zestawy witryn CHIPS FedCM + SAA |
|
Storage Access API Powiązane zestawy witryn CHIPS FedCM + SAA |
|
| Uwierzytelnianie |
Storage Access API FedCM Web Authentication API sciencePopins podzielone na partycje |
| W tych scenariuszach nie ma zazwyczaj zależności od plików cookie innych firm i nie powinny one być na nie narażone. |
Testowanie ścieżek użytkowników związanych z tożsamością
Najlepszym sposobem na sprawdzenie, czy zmiany w plikach cookie innych firm mają wpływ na proces logowania, jest przejście przez procesy rejestracji, odzyskiwania hasła, logowania i wylogowywania z włączoną flagą testowania plików cookie innych firm.
Oto lista kontrolna, którą warto przejrzeć po ograniczeniu plików cookie innych firm:
- Rejestracja użytkownika: tworzenie nowego konta działa zgodnie z oczekiwaniami. Jeśli korzystasz z zewnętrznych dostawców tożsamości, sprawdź, czy rejestracja nowych kont działa w przypadku każdej integracji.
- Odzyskiwanie hasła: odzyskiwanie hasła działa zgodnie z oczekiwaniami, od interfejsu internetowego, przez CAPTCHA, po otrzymywanie e-maila z odzyskanym hasłem.
- Logowanie: proces logowania działa w tej samej domenie i podczas przechodzenia do innych domen. Pamiętaj, aby przetestować każdą integrację logowania.
- Wylogowanie: proces wylogowania działa zgodnie z oczekiwaniami, a użytkownik pozostaje wylogowany po zakończeniu procesu wylogowania.
Sprawdź też, czy inne funkcje witryny, które wymagają zalogowania się użytkownika, działają bez plików cookie między witrynami, zwłaszcza jeśli wiąże się to z wczytywaniem zasobów między witrynami. Jeśli na przykład używasz CDN do wczytywania obrazów w profilach użytkowników, sprawdź, czy nadal działa. Jeśli masz kluczowe ścieżki użytkowników, takie jak płatność, które wymagają zalogowania, sprawdź, czy nadal działają.
Rozwiązania dotyczące logowania
W tej sekcji znajdziesz szczegółowe informacje o tym, jak te procesy mogą zostać zakłócone.
Logowanie jednokrotne (SSO) z wykorzystaniem zewnętrznych mechanizmów
Logowanie jednokrotne innej firmy umożliwia użytkownikowi uwierzytelnianie się za pomocą jednego zestawu danych logowania na jednej platformie, a następnie uzyskiwanie dostępu do wielu aplikacji i stron bez konieczności ponownego wpisywania danych logowania. Ze względu na złożoność wdrażania rozwiązania SSO wiele firm decyduje się na korzystanie z usług zewnętrznego dostawcy, aby udostępniać stan logowania między wieloma źródłami. Przykładami dostawców są Okta, Ping Identity, Google Cloud IAM lub Microsoft Entra ID.
Jeśli Twoje rozwiązanie korzysta z usług zewnętrznego dostawcy, może być konieczne wprowadzenie drobnych zmian, takich jak uaktualnienie biblioteki. Najlepszym rozwiązaniem jest zasięgnięcie porady u dostawcy na temat tego, jak pliki cookie innych firm wpływają na rozwiązanie i jakie podejście zaleca w przypadku danej usługi. Niektórzy dostawcy będą przechodzić na inne rozwiązania bez użycia plików cookie innych firm, w takim przypadku korzystające strony nie będą musiały wprowadzać zmian.
Wiele domen
Niektóre witryny używają innej domeny tylko do uwierzytelniania użytkowników, którzy nie kwalifikują się do korzystania z plików cookie na tej samej stronie. Przykładem może być witryna, która używa example.com w przypadku witryny głównej i login.example w przypadku procesu logowania. Może to wymagać dostępu do plików cookie innych firm, aby zapewnić uwierzytelnienie użytkownika w obu domenach.
Niektóre firmy mogą mieć wiele produktów hostowanych w różnych domenach lub subdomenach. Takie rozwiązania mogą udostępniać sesję użytkownika w tych usługach, co może wymagać dostępu do plików cookie innych firm w różnych domenach.
Możliwe ścieżki migracji w tym scenariuszu to:
- Aktualizacja w celu korzystania z własnych plików cookie („pochodzących z tej samej witryny”): zmiana infrastruktury witryny tak, aby proces logowania był hostowany w tej samej domenie (lub poddomenie) co główna witryna, która będzie używać tylko własnych plików cookie. W zależności od konfiguracji infrastruktury może to wymagać więcej pracy.
- Użyj zestawów powiązanych witryn (RWS) i interfejsu Storage Access API (SAA): zestawy powiązanych witryn umożliwiają ograniczony dostęp do plików cookie między niewielką grupą powiązanych domen. W przypadku RWS nie trzeba wyświetlać użytkownikowi żadnego prompta, gdy prosi się o dostęp do pamięci za pomocą interfejsu Storage Access API. Umożliwia to logowanie jednokrotne w przypadku tych dostawców usług, którzy są w tym samym RWS co dostawca tożsamości. Jednak RWS obsługuje dostęp do plików cookie w różnych witrynach tylko w przypadku ograniczonej liczby domen.
- Używanie interfejsu Web Authentication API: interfejs Web Authentication API umożliwia stronom korzystającym z usług (RP) rejestrowanie ograniczonego zestawu powiązanych źródeł, w których można tworzyć i używać danych logowania.
- Jeśli uwierzytniasz użytkowników w powiązaniu z ponad 5 powiązanymi domenami, zapoznaj się z FedCM (Federated Credential Management): FedCM umożliwia dostawcom tożsamości korzystanie z Chrome do obsługi procesów związanych z tożsamością bez konieczności korzystania z plików cookie innych firm. W Twoim przypadku „domena logowania” może pełnić rolę dostawcy tożsamości FedCM i służyć do uwierzytelniania użytkowników w innych domenach.
Uwierzytelnianie z poziomu elementów osadzonego
Załóżmy, że element iframe 3-party-app.example jest osadzony w witrynie top-level.example. W 3-party-app.example użytkownik może się zalogować za pomocą danych logowania 3-party-app.example lub innego zewnętrznego dostawcy.
Użytkownik klika „Zaloguj” i uwierzytelnia się w wyskakującym okienku 3-party-app.example. 3-party-app.exampleOkno wyskakujące ustawia własny plik cookie. Jednak iframe 3-party-app.example osadzony w witrynie top-level.example jest podzielony i nie ma dostępu do pliku cookie ustawionego w kontekście własnego w witrynie 3-party-app.example.
Ten sam problem występuje, gdy użytkownik jest przekierowywany z top-level.exampledo 3-party-app.example i z powrotem. Plik cookie jest zapisywany w kontekście własnych plików cookie witryny 3-party-app.example, ale jest podzielony na części i niedostępny w ramkach iframe witryny 3-party-app.example.
W przypadku, gdy użytkownik odwiedził ukrytą domenę w kontekście najwyższego poziomu, dobrym rozwiązaniem jest Storage Access API.
Aby przejść na rozwiązania, które nie opierają się na plikach cookie innych firm, dostawcy tożsamości powinni zastosować interfejs FedCM API. FedCM powinien być wywoływany z ramy wbudowanych elementów, a nie z wyskakujących okienek.
Innym proponowanym rozwiązaniem w tym przypadku jest partycjonowanie Poppinsów, które jest obecnie wdrażane.
Logowanie się przez media społecznościowe
Przyciski logowania takie jak Zaloguj się przez Google, Facebook Login i Zaloguj się przez Twittera są jednoznacznym sygnałem, że Twoja witryna korzysta z federowanego dostawcy tożsamości. Każdy dostawca tożsamości federacyjnej będzie miał własną implementację.
Jeśli używasz wycofanego interfejsu Google Sign-In JavaScript Platform, znajdziesz tu informacje o przechodzeniu na nowszą bibliotekę Google Identity Services do uwierzytelniania i autoryzacji.
Większość witryn korzystających z nowszej biblioteki Google Identity Services nie korzysta już z plików cookie innych firm, ponieważ biblioteka zostanie automatycznie przeniesiona na korzystanie z FedCM w celu zapewnienia zgodności. Zalecamy przetestowanie witryny z włączoną flagą testowania wycofania plików cookie firm zewnętrznych. W razie potrzeby możesz też skorzystać z listy kontrolnej migracji do FedCM.
Dostęp do danych użytkowników z osadzonych treści i ich modyfikowanie
Treści osadzone są często używane w trakcie ścieżki użytkownika, np. podczas uzyskiwania dostępu do danych o profilu użytkownika lub subskrypcjach i zarządzania nimi.
Użytkownik może na przykład zalogować się w usłudze website.example, która zawiera widżet subscriptions.example. Ten widżet umożliwia użytkownikom zarządzanie ich danymi, na przykład subskrybowanie treści premium lub aktualizowanie informacji rozliczeniowych. Aby modyfikować dane użytkownika, wbudowany widget może potrzebować dostępu do własnych plików cookie, gdy jest wbudowany w website.example. W sytuacji, gdy te dane powinny być odizolowane od website.example, funkcja CHIPS może pomóc zapewnić, że element osadzony będzie miał dostęp do potrzebnych informacji. Dzięki CHIPS widżet subscriptions.example umieszczony w witrynie website.example nie będzie mieć dostępu do danych subskrypcji użytkownika w innych witrynach.
Inny przykład: film z streaming.example jest umieszczony w website.example, a użytkownik ma subskrypcję premium streaming.example, o której musi wiedzieć widżet, aby wyłączyć reklamy. Jeśli ten sam plik cookie musi być dostępny w różnych witrynach, rozważ użycie interfejsu Storage Access API, jeśli użytkownik wcześniej odwiedził streaming.example jako witrynę najwyższego poziomu, oraz zbiorów powiązanych witryn, jeśli zbiór website.example jest właścicielem streaming.example.
Od wersji 131 Chrome FedCM jest zintegrowany z interfejsem Storage Access API. Dzięki tej integracji, gdy użytkownik zaakceptuje prośbę FedCM, przeglądarka przyzna dostawcy tożsamości dostęp do niepartycjonowanego miejsca na dane.
Więcej informacji o tym, który interfejs API wybrać do obsługi określonej ścieżki użytkownika z osadzonym treścią, znajdziesz w przewodniku po osadzeniu.
Inne ścieżki użytkowników
Ścieżki użytkowników, które nie korzystają z plików cookie innych firm, nie powinny być w żaden sposób dotknięte zmianami w sposobie obsługi plików cookie innych firm w Chrome. Istniejące rozwiązania, takie jak logowanie, wylogowywanie czy odzyskiwanie konta w kontekście usług własnych i 2 FA, powinny działać zgodnie z oczekiwaniami. Możliwe punkty złamania zostały opisane wcześniej. Więcej informacji o konkretnym interfejsie API znajdziesz na stronie stanu interfejsu API. Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem na GitHubie w repozytorium pomocy dla deweloperów Piaskownicy prywatności.
Audytowanie witryny
Jeśli Twoja witryna wdraża jeden z opisanych w tym przewodniku scenariuszy użytkownika, musisz się upewnić, że Twoje witryny są gotowe: przeprowadź audyt witryny pod kątem używania plików cookie innych firm, przetestuj, czy nie występują awarie, i przejdź na zalecane rozwiązania.