W przeszłości pliki cookie innych firm były używane do przechowywania i przekazywania informacji o stanie użytkownika, np. o stanie zalogowania się, urządzeniu, z którego korzysta, oraz o tym, czy użytkownik jest znany i zaufany. Mogą to być na przykład informacje o tym, czy użytkownik zalogował się za pomocą logowania jednokrotnego, czy ma zgodny typ urządzenia oraz czy użytkownik jest znany i zaufany. W związku z wycofaniem obsługi plików cookie innych firm wiele z tych przypadków użycia będzie musiało być obsługiwane w inny sposób.
Tokeny prywatności umożliwiają udostępnianie informacji w internecie przy zachowaniu ochrony prywatności dzięki kontrolowaniu ilości danych, które można faktycznie udostępnić.
Tokeny prywatności (dawniej nazywane tokenami zaufania) pozwalają przekazywać zaufanie do autentyczności użytkownika z jednego kontekstu do drugiego, a jednocześnie pomagają witrynom w walce z oszustwami i odróżnianiu botów od prawdziwych ludzi bez konieczności pasywnego śledzenia.
Ten dokument zawiera szczegóły techniczne dotyczące wdrażania tokenów prywatności (PST). Ogólne informacje znajdziesz w omówieniu PST.
Jak działają tokeny prywatności?
Relacja między wydawcami a osobami realizującymi cele jest kluczowa w przepisach PST. Wystawcy i wydawcy mogą należeć do tej samej firmy.
- Wystawcy – te elementy przekazują informacje o użytkowniku (np. czy jest botem) i umieszczają ten sygnał w tokenie przechowywanym na urządzeniu użytkownika (więcej informacji znajdziesz w następnych sekcjach).
- Użytkownicy realizujący płatności – te podmioty mogą nie mieć sygnału o użytkowniku, ale muszą coś o nim wiedzieć (np. czy jest botem) i poprosić o wykorzystanie tokena od wydawcy, aby poznać jego wiarygodność.
Każda interakcja z PST wymaga, aby wydawcy i osoby wysyłające karty wspólnie udostępniały sygnały w internecie. Sygnały te to przybliżone wartości, które nie są wystarczająco szczegółowe, aby zidentyfikować poszczególne osoby.
Czy tokeny prywatności są dla mnie odpowiednie?
Firmy, które podejmują decyzje w zakresie zaufania i chcą, aby te informacje były dostępne w różnych kontekstach, mogą odnieść korzyści z PST. Więcej informacji o potencjalnych przypadkach użycia plików PST znajdziesz w dokumentacji dotyczącej przypadków użycia plików PST.
Wydawanie i wykorzystywanie tokenów
Wdrożenie pliku PST obejmuje 3 fazy:
- Wydawanie tokenów
- Wykorzystanie tokenów
- Przekierowanie rekordu wykorzystania
Na pierwszym etapie tokeny są wydawane do przeglądarki (zwykle po pewnym czasie weryfikacji). W drugim etapie inny podmiot wyśle żądanie realizacji tokena, który został wystawiony, aby odczytać w nim wartość. Na końcowym etapie strona korzystająca z oferty otrzymuje rekord realizacji (RR) z wartością podaną w tokenie. Strona dokonująca zakupu może następnie wykorzystać ten rekord jako potwierdzenie danego użytkownika w różnych celach.
Zdefiniuj strategię dotyczącą tokenów
Aby zdefiniować strategię dotyczącą tokenów, musisz poznać kluczowe pojęcia dotyczące tokenów i rejestrów wykorzystania plików PST oraz zmienne, zachowania i ograniczenia, aby móc zastanowić się nad ich potencjalnym wykorzystaniem w Twoim przypadku.
Tokeny i rejestry wykorzystania – jaka jest relacja między nimi?
Na każdym urządzeniu można przechowywać do 500 tokenów na witrynę najwyższego poziomu i jedną stronę wydawcy. Każdy token ma też metadane określające, którego klucza użył wydawca. Te informacje mogą posłużyć do podjęcia decyzji o wykorzystaniu tokena podczas realizacji oferty. Dane PST są zapisywane wewnętrznie przez przeglądarkę na urządzeniu użytkownika i są dostępne tylko za pomocą interfejsu PST API.
Po wykorzystaniu tokena na urządzeniu jest przechowywany rekord wykorzystania (RR). Działa ona jako pamięć podręczna na potrzeby przyszłych ofert. Na urządzeniu, stronie i wydawcy może być wykorzystywane 2 tokeny co 48 godzin. Nowe wywołania związane z wykorzystaniem środków w miarę możliwości będą w miarę możliwości korzystać z pamięci podręcznej stanu strony internetowej, a nie wysyłać żądanie do wydawcy.
- Wydaje się nowe tokeny (maksymalnie 500 na wydawcę, witrynę i urządzenie).
- Wszystkie tokeny są przechowywane na urządzeniu (podobnym do magazynu plików cookie).
- Jeśli nie zostanie znalezione żadne aktywne RR, można wygenerować nowe raporty RR po wystawieniu (maksymalnie 2 co 48 godzin).
- RRSO są uznawane za aktywne do czasu ich wygaśnięcia i będą używane jako lokalna pamięć podręczna.
- Nowe wywołania wykorzystania będą trafiły do lokalnej pamięci podręcznej (nie są generowane nowe raporty RR).
Po zdefiniowaniu przypadku użycia musisz dokładnie zdefiniować okres ważności RR, ponieważ określi to, ile razy będzie można z nich korzystać w danym przypadku.
Zanim zdefiniujesz strategię, zapoznaj się z tymi kluczowymi zachowaniami i zmiennymi:
| Zmienna / zachowanie | Opis | Potencjalne wykorzystanie |
|---|---|---|
| Metadane klucza tokena | Każdy token może być wydany przy użyciu 1 klucza kryptograficznego, a w PST obowiązuje limit 6 kluczy na wydawcę. | Jednym z potencjalnych sposobów wykorzystania tej zmiennej jest określenie zakresu zaufania do tokenów na podstawie kluczy kryptograficznych (np. klucz 1 = wysoki poziom zaufania, a klucz 6 = brak zaufania). |
| Data ważności tokena | Data ważności tokena jest taka sama jak data ważności klucza. | Klucze mogą być poddawane rotacji co najmniej co 60 dni. Wszystkie tokeny wydane z nieprawidłowymi kluczami również są uznawane za nieprawidłowe. |
| Limit częstotliwości wykorzystania tokenów | Obowiązuje limit 2 wykorzystania tokenów na urządzenie i wydawcę co 48 godzin. | Zależy od szacunkowej liczby wykorzystanych ofert wymaganych przez Twój przypadek użycia co 48 godzin. |
| Maksymalna liczba wydawców na źródło najwyższego poziomu | Maksymalna liczba wydawców na źródło najwyższego poziomu wynosi obecnie 2. | Uważnie zdefiniuj wydawców każdej strony. |
| Liczba tokenów na urządzeniu według wydawcy | Maksymalna liczba tokenów na wydawcę na konkretnym urządzeniu to obecnie 500. | Liczba tokenów jednego wydawcy musi być mniejsza niż 500. Pamiętaj o rozwiązywaniu błędów na stronie, gdy próbujesz wysyłać tokeny. |
| Rotacja zobowiązań kluczowych | Każdy wydawca pliku PST musi udostępnić punkt końcowy z zobowiązaniami kluczy, które można zmieniać co 60 dni, a każda rotacja szybciej niż ta będzie ignorowana. | Jeśli Twoje klucze wygasną za mniej niż 60 dni, musisz przed tą datą zaktualizować zobowiązania na klucz, aby uniknąć przerw w działaniu usługi (zobacz szczegóły). |
| Okres ważności kodu do wykorzystania | Czas ważności RR może zostać określony w celu określenia daty wygaśnięcia. RRSO są przechowywane w pamięci podręcznej, aby uniknąć niepotrzebnych nowych wywołań związanych z wykorzystaniem ofert do wydawcy, dlatego ważne jest, aby mieć wystarczającą liczbę aktualnych sygnałów dotyczących wykorzystania kodu. | Ponieważ istnieje limit wykorzystania 2 tokenów co 48 godzin, ważne jest określenie okresu ważności RR, aby możliwe było realizowanie wywołań wykorzystania przez co najmniej ten okres (należy odpowiednio ustawić okres ważności RR). Zalecamy ustawienie tego okresu w kolejności tygodniowej. |
Przykładowe scenariusze
Scenariusz 1. Okres ważności RR jest krótszy niż 24 godziny (t=t), a wykorzystanie występuje kilka razy w ciągu 48 godzin.
Scenariusz 2. Okres ważności RRSO wynosi 24 godziny, a wykorzystanie jest realizowane wiele razy w ciągu 48 godzin.
Scenariusz 3. Okres ważności RR to 48 godzin, a wykorzystanie jest realizowane wiele razy w ciągu 48 godzin.
Uruchom wersję demonstracyjną
Zanim wdrożysz PST, zalecamy wcześniejsze przygotowanie się do wersji demonstracyjnej. Aby wypróbować demonstrację pliku PST , musisz uruchomić Chrome z flagami włączającymi zobowiązania na klucz wydawcy wersji demonstracyjnej (postępuj zgodnie z instrukcjami dostępnymi na stronie demonstracyjnej).
Po uruchomieniu tej wersji demonstracyjnej przeglądarka korzysta z wydawcy wersji demonstracyjnej i serwerów spełniających warunki, aby udostępniać i wykorzystywać tokeny.
Kwestie techniczne
Wersja demonstracyjna działa najlepiej, gdy wykonasz te czynności:
- Zanim uruchomisz Chrome z flagami, zatrzymaj wszystkie instancje Chrome.
- Jeśli używasz komputera z systemem Windows, zapoznaj się z tym przewodnikiem, aby dowiedzieć się, jak przekazywać parametry do pliku binarnego wykonywalnego Chrome.
- Otwórz Narzędzia deweloperskie w Chrome w sekcji Aplikacje > Pamięć > Tokeny prywatności w aplikacji demonstracyjnej, aby wyświetlić tokeny wydane/wykorzystane przez wydawcę wersji demonstracyjnej.
Skonfiguruj do wdrożenia
Zostań wydawcą
Wystawcy odgrywają kluczową rolę w PST. Przypisują one wartości do tokenów, aby określić, czy użytkownik jest botem. Jeśli chcesz zacząć korzystać z pliku PST jako wydawca, musisz zarejestrować się, przechodząc proces rejestracji wydawcy.
Aby zgłosić się do wydawcy, operator witryny wydawcy musi otworzyć nowy problem w repozytorium GitHub, korzystając z szablonu „New PST Issuer”. Aby rozwiązać problem, postępuj zgodnie ze wskazówkami w repozytorium. Po zweryfikowaniu punktu końcowego zostanie on scalony z tym repozytorium, a infrastruktura po stronie serwera Chrome zacznie pobierać klucze.
Serwery wystawcy
Wystawcy i podmioty dokonujące wykorzystania to kluczowe podmioty wpływające na plik PST, a serwery i tokeny to kluczowe narzędzia dla pliku PST. Więcej informacji o tokenach i dokumentacji na GitHubie przedstawiliśmy już, ale chcieliśmy przekazać więcej informacji na temat serwerów PST. Aby skonfigurować wydawcę jako wydawcę PST, musisz najpierw skonfigurować serwer wydający.
Wdrażanie środowiska: serwery wydawców
Aby wdrożyć serwer wydawcy tokenów, musisz utworzyć po stronie serwera własną aplikację ujawniającą punkty końcowe HTTP.
Komponent wydawcy składa się z 2 głównych modułów: (1) serwera wystawcy i (2) wydawcy tokena.
Tak jak w przypadku wszystkich aplikacji internetowych, zalecamy dodatkową warstwę zabezpieczeń dla serwera wydawców.
Serwer wystawcy: w naszej przykładowej implementacji jest to serwer Node.js, który korzysta z platformy Express do hostowania punktów końcowych HTTP wystawcy. Przykładowy kod znajdziesz na GitHubie.
Wystawca tokena: komponent kryptograficzny wydawcy nie wymaga konkretnego języka, ale ze względu na wymagania dotyczące wydajności tego komponentu udostępniamy jako przykład implementację C, która do zarządzania tokenami wykorzystuje bibliotekę Boring SSL. Przykładowy kod wydawcy i więcej informacji o instalacji znajdziesz na GitHubie
Klucze: komponent wystawcy tokenów używa niestandardowych kluczy EC do szyfrowania tokenów. Te klucze muszą być chronione i przechowywane w bezpiecznym miejscu.
Wymagania techniczne dotyczące serwerów wydawców
Zgodnie z protokołem trzeba wdrożyć na serwerze wydawcy co najmniej 2 punkty końcowe HTTP:
- Zatwierdzenie klucza (np.
/.well-known/private-state-token/key-commitment): w tym punkcie końcowym widoczne są szczegóły publicznego klucza szyfrowania, które są dostępne dla przeglądarek, aby potwierdzić wiarygodność serwera. - Wystawianie tokenów (np.
/.well-known/private-state-token/issuance): punkt końcowy wystawiający tokeny, w którym będą przetwarzane wszystkie żądania tokenów. Ten punkt końcowy będzie punktem integracji komponentu wydawcy tokena.
Jak wspomnieliśmy wcześniej, ze względu na oczekiwany duży ruch, który będzie mógł obsługiwać ten serwer, zalecamy wdrożenie go za pomocą skalowalnej infrastruktury (np. w środowisku chmury), co pozwoli dostosowywać backend do zmiennych zapotrzebowania.
Wyślij połączenie do serwera wydawcy
Zaimplementuj wywołanie pobierania z witryny do stosu wydawców w celu wystawiania nowych tokenów.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Serwery realizacji programów
Musisz wdrożyć usługę realizacji tokenów, tworząc własną aplikację po stronie serwera. Umożliwi Ci to odczyt tokenów wysłanych przez wydawcę. Poniżej opisujemy, jak wykorzystać tokeny i odczytywać powiązane z nimi rejestry wykorzystania.
Wydawca i podmiot korzystający z oferty możesz umieścić na tym samym serwerze (lub w grupie serwerów).
Wymagania techniczne dotyczące serwerów podmiotów dokonujących wykorzystania
Zgodnie z protokołem musisz wdrożyć dla serwera realizacji oferty co najmniej 2 punkty końcowe HTTP:
/.well-known/private-state-token/redemption: punkt końcowy, w którym będzie obsługiwane wykorzystanie wszystkich tokenów. W tym punkcie końcowym zostanie zintegrowany komponent odczytujący tokeny.
Wyślij połączenie do serwera realizującego ofertę
Aby wykorzystać tokeny, musisz zaimplementować wywołanie pobierania z witryny do stosu podmiotów realizujących w celu wykorzystania wystawionych wcześniej.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Zobacz przykładowy kod.
Po wykorzystaniu tokena możesz wysłać rekord wykorzystania (RR), wykonując kolejne wywołanie pobierania:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
Zobacz przykładowy kod.
Wdrażanie implementacji
Aby przetestować implementację, najpierw przejdź na stronę internetową, na której wykonywane jest wywołanie, i sprawdź, czy tokeny zostały utworzone zgodnie z zastosowaną logiką. Sprawdź w backendzie, czy wywołania zostały wykonane zgodnie ze specyfikacją. Następnie otwórz stronę internetową, na której odbywa się wywołanie realizacji, i zgodnie z logiką upewnij się, że utworzono raporty RR.
Rzeczywiste wdrożenie
Zalecamy wybranie witryn docelowych związanych z Twoim przypadkiem użycia:
- Mała liczba miesięcznych wizyt (około 1 miliona wizyt w miesiącu): zacznij od wdrożenia interfejsu API na małej grupie odbiorców
- Należy do Ciebie i masz nad nią kontrolę: w razie potrzeby możesz szybko wyłączyć implementację bez złożonych zatwierdzeń
- Nie więcej niż jeden wydawca: ograniczenie liczby tokenów w celu uproszczenia testowania.
- Nie więcej niż 2 użytkowników korzystających z oferty: musisz uprościć rozwiązywanie problemów.
Rozwiązywanie problemów
Pliki PST możesz sprawdzać na kartach Sieć i aplikacja w Narzędziach deweloperskich w Chrome.
Na karcie Sieć:
Na karcie Application:
Dowiedz się więcej o tej integracji z Narzędziami deweloperskimi.
Sprawdzone metody dotyczące serwerów i rozwiązywanie problemów z nimi
Aby zapewnić skuteczne działanie wydawcy i serwera realizującego token, zalecamy wdrożenie tych sprawdzonych metod. Pozwoli to uniknąć problemów z dostępem, zabezpieczeniami, logowaniem czy ruchem w plikach PST.
- W punktach końcowych należy stosować silną kryptografię z wykorzystaniem protokołu TLS 1.3 lub 1.2.
- Twoja infrastruktura musi być gotowa do obsługi zmiennych natężenia ruchu (w tym gwałtownych skoków).
- Zadbaj o to, by Twoje klucze były chronione i bezpieczne oraz zgodne z zasadami kontroli dostępu, strategią zarządzania kluczami i planami ciągłości działania.
- Dodaj do stosu wskaźniki dostrzegalności, aby móc zrozumieć problemy związane z wykorzystaniem, wąskimi gardłem i wydajnością po przejściu do produkcji.
Więcej informacji
- Zapoznaj się z dokumentacją dla deweloperów:
- Zacznij od zapoznania się z omówieniem, aby zapoznać się z mechanizmem PST i jego możliwościami.
- Obejrzyj film wprowadzający do PST.
- Wypróbuj prezentację PST.
- Zapoznaj się też z objaśnieniem interfejsu API, aby dowiedzieć się więcej.
- Dowiedz się więcej o bieżącej specyfikacji interfejsu API.
- Weź udział w rozmowie za pomocą problemów z GitHubem lub wywołań W3C.
- Aby lepiej zrozumieć terminologię, zapoznaj się z słowniczkiem Piaskownicy prywatności.
- Aby dowiedzieć się więcej o pojęciach związanych z Chrome, takich jak „origin test” czy „flagi Chrome”, przejrzyj krótkie filmy i artykuły na stronie goo.gle/cc.