W przeszłości pliki cookie innych firm były używane do przechowywania i przekazywania informacji o stanie użytkownika, takich jak stan logowania, informacje o urządzeniu, którego używa, lub informacje o tym, czy jest on znany i zaufany. Na przykład czy użytkownik zalogował się za pomocą logowania jednokrotnego, czy ma odpowiednie urządzenie, czy jest znany i uznany za godnego zaufania. Wycofanie obsługi plików cookie innych firm spowoduje, że wiele z tych zastosowań będzie wymagać obsługi w inny sposób.
Tokeny stanu prywatnego umożliwiają udostępnianie informacji w internecie, ale w sposób zapewniający ochronę prywatności dzięki kontrolowaniu ilości danych, które można udostępnić.
Tokeny prywatności (dawniej znane jako tokeny zaufania) umożliwiają przekazywanie informacji o autentyczności użytkownika z jednego kontekstu do drugiego, a zarazem pomagają witrynom zwalczać oszustwa i odróżniać boty od prawdziwych użytkowników – bez biernego śledzenia.
Ten dokument zawiera szczegółowe informacje techniczne dotyczące implementacji tokenów prywatności (PST). Ogólne informacje znajdziesz w artykule Omówienie plików PST.
Jak działają tokeny prywatności?
Najważniejsza relacja w PST to relacja między wydawcami a osobami, które korzystają z kart. Wydawcy i użytkownicy mogą należeć do tej samej firmy.
- Wydawcy – te podmioty mają pewien sygnał o użytkowniku (np. czy jest to bot) i wbudowują go w token, który jest przechowywany na urządzeniu użytkownika (więcej informacji znajdziesz w następnych sekcjach).
- Odbiorcy – te podmioty mogą nie mieć sygnału o użytkowniku, ale muszą wiedzieć o nim coś więcej (np. czy jest to bot), i proszą o wykupienie tokena od wydawcy, aby sprawdzić wiarygodność tego użytkownika.
Każda interakcja z PST wymaga współpracy emitenta i odbiorcy w zakresie udostępniania sygnałów w internecie. Te sygnały to wartości ogólne, które nie są wystarczająco szczegółowe, aby umożliwić identyfikację poszczególnych osób.
Czy tokeny prywatności są dla mnie odpowiednie?
PST mogą być przydatne dla firm, które podejmują decyzje dotyczące zaufania i chcą, aby informacje były dostępne w różnych kontekstach. Więcej informacji o potencjalnych zastosowaniach plików PST znajdziesz w dokumentacji dotyczącej przypadków użycia plików PST.
Wystawianie i wykorzystywanie tokenów
Wdrożenie PST odbywa się w 3 etapach:
- Przyznawanie tokenów
- Odbieranie tokenów
- Przekierowywanie rekordów wykorzystania
W pierwszej fazie przeglądarce są wydawane tokeny (zwykle po ich weryfikacji). W drugiej fazie inny podmiot prześle żądanie realizacji tokena, który został wydany w celu odczytania jego wartości. W ostatniej fazie strona korzystająca z oferty otrzymuje rekord wykorzystania (RR) z wartością zawartą w tokenie. Użytkownik może wykorzystać ten rekord jako potwierdzenie tożsamości użytkownika w różnych celach.
Określanie strategii dotyczącej tokenów
Aby zdefiniować strategię dotyczącą tokenów, musisz zrozumieć kluczowe pojęcia dotyczące PST (tokenów i rekordów wykorzystania), zmiennych, zachowań i ograniczeń, aby móc zastanowić się nad ich potencjalnym zastosowaniem w Twoim przypadku użycia.
Jaki jest związek między tokenami a rekordami wykorzystania?
Każde urządzenie może przechowywać do 500 tokenów na stronę najwyższego poziomu i wydawcę. Każdy token ma też metadane informujące, którego klucza użył wystawca, aby go wydać. Te informacje mogą być używane do podjęcia decyzji o wykorzystaniu tokena podczas procesu. Dane PST są przechowywane wewnętrznie przez przeglądarkę na urządzeniu użytkownika i są dostępne tylko dla interfejsu PST API.
Gdy token zostanie wykorzystany, rekord wykorzystania (RR) zostanie zapisany na urządzeniu. Ta pamięć masowa działa jako pamięć podręczna na potrzeby przyszłych realizacji. Obowiązuje limit 2 tokenów na każde urządzenie, stronę i wydawcę na każde 48 godzin. Nowe wywołania kodu będą używać w miarę możliwości buforowanych RR, zamiast wysyłać żądanie do wystawcy.
- Wygenerowano nowe tokeny (maksymalnie 500 na wydawcę, witrynę i urządzenie).
- Wszystkie tokeny są przechowywane w pamięci na urządzeniu (podobnie jak pliki cookie).
- Jeśli nie zostanie znaleziony aktywny rekord RR, nowe rekordy RR mogą zostać wygenerowane po wydaniu (maksymalnie 2 co 48 godzin).
- Odpowiedzi zwrotne są uznawane za aktywne do momentu wygaśnięcia i będą używane jako lokalny bufor.
- Nowe wywołania kodu będą trafiać do pamięci podręcznej (nie są generowane żadne nowe rekordy RR).
Po zdefiniowaniu zastosowania musisz dokładnie określić czas trwania RR, ponieważ to on określa, ile razy możesz użyć RR w danym przypadku.
Zanim określisz strategię, zapoznaj się z tymi ważnymi zachowaniami i zmiennymi:
| Zmienna / zachowanie | Opis | Potencjalne zastosowanie |
|---|---|---|
| Metadane klucza tokena | Każdy token może być wydawany przy użyciu jednego i tylko jednego klucza szyfrującego, a w PST jest ograniczenie do 6 kluczy na wydawcę. | Jednym z potencjalnych sposobów użycia tej zmiennej jest zdefiniowanie zakresu zaufania do tokenów na podstawie kluczy kryptograficznych (np. klucz 1 = wysokie zaufanie, a klucz 6 = brak zaufania). |
| Data ważności tokenu | Data ważności tokena jest taka sama jak data ważności klucza. | Klucze można zmieniać co 60 dni lub częściej, a wszystkie tokeny wydane przy użyciu nieprawidłowych kluczy są również uznawane za nieprawidłowe. |
| Limit częstotliwości wykorzystywania tokenów | Ograniczenie do 2 wymian tokenów na urządzenie i wystawcę co 48 godzin. | Zależy od szacowanej liczby aktywacji wymaganych w przypadku Twojego zastosowania co 48 godzin. |
| Maksymalna liczba źródeł na poziomie źródła najwyższego poziomu | Maksymalna liczba emitentów na pochodzenie najwyższego poziomu wynosi obecnie 2. | Uważnie określ wydawców każdej strony. |
| Tokeny na urządzeniu według wystawcy | Maksymalna liczba tokenów na wydawcę na określonym urządzeniu to obecnie 500. | Upewnij się, że liczba tokenów jest mniejsza niż 500 na wydawcę. Podczas próby wystawienia tokenów należy pamiętać o obsługiwaniu błędów na stronie internetowej. |
| Rotacja kluczy | Każdy podmiot wystawiający certyfikat PST musi udostępnić punkt końcowy z kluczowymi zobowiązaniami, które można zmienić co 60 dni. Każda rotacja szybsza niż co 60 dni zostanie zignorowana. | Jeśli klucze wygasną w ciągu 60 dni, przed tą datą musisz zaktualizować kluczowe zobowiązania, aby uniknąć zakłóceń (patrz szczegóły). |
| Okres ważności rekordu wykorzystania | Okres ważności RR można zdefiniować, aby określić datę wygaśnięcia. Odpowiedzi są przechowywane w pamięci podręcznej, aby uniknąć niepotrzebnych nowych wywołań do wydawcy, dlatego ważne jest, aby sygnały odkupu były wystarczająco aktualne. | Ze względu na limit 2 tokenów na 48 godzin ważne jest, aby zdefiniować czas trwania RR, aby móc z powodu skutecznie wykonywać wywołania dotyczące realizacji w ramach tego okresu (czas trwania RR powinien być odpowiednio ustawiony). Zalecamy ustawienie tego okresu na kilka tygodni. |
Przykładowe scenariusze
Scenariusz 1. Czas trwania RR jest krótszy niż 24 godziny (t=t), a wykorzystanie odbywa się wielokrotnie w ciągu 48 godzin.
Scenariusz 2. Okres ważności kodu rabatowego to 24 godziny, a kod jest wykorzystywany wielokrotnie w okresie 48 godzin.
Scenariusz 3. Okres ważności RR to 48 godzin, a wykorzystanie odbywa się wielokrotnie w tym oknie czasowym.
Uruchamianie wersji demonstracyjnej
Zanim zaczniesz korzystać z PST, zalecamy najpierw skonfigurowanie wersji demonstracyjnej. Aby przetestować wersję demonstracyjną PST, musisz uruchomić Chrome z flagami, aby włączyć zobowiązania klucza wystawcy wersji demonstracyjnej (wykonaj instrukcje dostępne na stronie wersji demonstracyjnej).
Podczas uruchamiania tej wersji demonstracyjnej przeglądarka używa serwerów wystawcy i odbiorcy wersji demonstracyjnej do dostarczania i wykorzystywania tokenów.
Kwestie techniczne
Demo działa najlepiej, jeśli wykonasz te czynności:
- Przed uruchomieniem Chrome z flagami zamknij wszystkie jego wystąpienia.
- Jeśli używasz komputera z systemem Windows, zapoznaj się z tym przewodnikiem, aby dowiedzieć się, jak przekazywać parametry do pliku wykonywalnego Chrome.
- Otwórz Narzędzia deweloperskie Chrome w sekcji Aplikacje > Pamięć > Prywatny stan Tokeny, korzystając z aplikacji demonstracyjnej, aby zobaczyć tokeny wydane/wykupione przez wystawcę demonstracyjnego.
Konfigurowanie upowszechniania
Zostań wydawcą
Instytucje wydające certyfikaty odgrywają kluczową rolę w PST. Przypisują one wartości do tokenów, aby określić, czy użytkownik jest botem, czy nie. Jeśli chcesz zacząć korzystać z PST jako wydawca, musisz się zarejestrować, korzystając z procesu rejestracji wydawcy.
Aby złożyć wniosek o uzyskanie statusu wystawcy, operator witryny wystawcy musi otworzyć nowe zapytanie w repozytorium GitHub, korzystając z szablonu „Nowy wystawca PST”. Aby wypełnić zgłoszenie, postępuj zgodnie z instrukcjami w repozytorium. Po zweryfikowaniu punkt końcowy zostanie scalony z tym repozytorium, a infrastruktura po stronie serwera Chrome zacznie pobierać te klucze.
Serwery wydawcy
Wydawcy i użytkownicy są kluczowymi podmiotami w przypadku PST, a serwery i tokeny są kluczowymi narzędziami w przypadku PST. Podaliśmy już kilka informacji o tokenach i w dokumentacji GitHub, ale chcielibyśmy podać więcej szczegółów na temat serwerów PST. Aby skonfigurować się jako wystawca PST, musisz najpierw skonfigurować serwer wystawiający.
Wdrażanie środowiska: serwery wystawcy
Aby zaimplementować serwer wystawcy tokenów, musisz utworzyć własną aplikację po stronie serwera, która udostępnia punkty końcowe HTTP.
Składa się on z 2 głównych modułów: (1) serwera wydawcy i (2) wydawcy tokenów.
Podobnie jak w przypadku wszystkich aplikacji internetowych, zalecamy dodatkowe zabezpieczenie serwera wystawcy.
Serwer wydawcy: w naszym przykładowym wdrożeniu serwer wydawcy to serwer Node.js, który używa platformy Express do hostowania punktów końcowych HTTP wydawcy. Przykładowy kod znajdziesz na GitHubie.
Wystawca tokena: komponent kryptograficzny wystawcy nie wymaga żadnego konkretnego języka, ale ze względu na wymagania dotyczące wydajności tego komponentu podajemy jako przykład implementację w C, która do zarządzania tokenami korzysta z biblioteki BoringSSL. Przykład kodu wystawcy i więcej informacji o instalacji znajdziesz na GitHubie
Klucze: komponent wystawcy tokenów używa niestandardowych kluczy EC do szyfrowania tokenów. Klucze te muszą być chronione i przechowywane w bezpiecznym miejscu.
Wymagania techniczne dotyczące serwerów wydawców
Zgodnie z protokołem na serwerze wystawcy musisz zaimplementować co najmniej 2 punkty końcowe HTTP:
- Key-commitment (na przykład
/.well-known/private-state-token/key-commitment): w tym punkcie końcowym informacje o kluczu publicznym szyfrowania są dostępne dla przeglądarek, aby potwierdzić, że Twój serwer jest autentyczny. - Wydawanie tokenów (na przykład
/.well-known/private-state-token/issuance): punkt końcowy do wydawania tokenów, w którym będą obsługiwane wszystkie żądania tokenów. Ten punkt końcowy będzie punktem integracji dla komponentu emitenta tokenów.
Jak już wspomnieliśmy, ze względu na spodziewany duży ruch, który ten serwer może obsługiwać, zalecamy jego wdrożenie za pomocą elastycznej infrastruktury (np. w środowisku chmurowym), aby można było dostosować backend do zmiennego zapotrzebowania.
Wysyłanie wywołania do serwera wystawcy
W celu wydawania nowych tokenów dodaj do zestawu narzędzi wydawcy wywołanie pobierania witryny.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Serwery Redeemer
Musisz zaimplementować usługę realizacji tokenów, tworząc własną aplikację po stronie serwera. Dzięki temu będziesz mieć możliwość odczytywania tokenów wysyłanych przez wystawcę. W tych instrukcjach dowiesz się, jak wykorzystać tokeny oraz jak odczytać powiązane z nimi rekordy wykorzystania.
Możesz uruchomić wystawcę i odbiorcę na tym samym serwerze (lub grupie serwerów).
Wymagania techniczne dotyczące serwerów redeemer
Zgodnie z protokołem musisz zaimplementować co najmniej 2 punkty końcowe HTTP dla swojego serwera obsługującego wykupywanie:
/.well-known/private-state-token/redemption: punkt końcowy, w którym obsługiwane jest wykupowanie tokenów. W tym punkcie końcowym zostanie zintegrowany element umożliwiający wykupienie tokena.
Wysyłanie wywołania do serwera obsługującego wykup
Aby wykorzystać tokeny, musisz zaimplementować wywołanie pobierania witryny do swojego zbioru elementów do wykupu, aby wykorzystać tokeny wygenerowane 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) przez wykonanie kolejnego wywołania 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 otwórz stronę internetową, na której wykonywane jest wywołanie issue, i sprawdź, czy tokeny są tworzone zgodnie z Twoją logiką. Sprawdź na zapleczu, czy wywołania zostały wykonane zgodnie ze specyfikacją. Następnie otwórz stronę internetową, na której jest wykonywane wywołanie kodu, i sprawdź, czy RR zostały utworzone zgodnie z Twoją logiką.
Wdrożenie w praktyce
Zalecamy wybranie witryn docelowych, które pasują do Twojego konkretnego przypadku użycia:
- Niewielka liczba wizyt miesięcznie (mniej niż 1 mln wizyt miesięcznie): najpierw wprowadź interfejs API w przypadku małej grupy odbiorców.
- Masz do nich dostęp i możesz nimi zarządzać: w razie potrzeby możesz szybko wyłączyć implementację bez konieczności uzyskiwania skomplikowanych akceptacji.
- Nie więcej niż 1 wydawca: aby ograniczyć liczbę tokenów i ułatwić testowanie.
- Nie więcej niż 2 osób: w przypadku problemów musisz uprościć proces rozwiązywania problemów.
Zasady dotyczące uprawnień
Aby działać prawidłowo, interfejs PST API musi być dostępny dla strony najwyższego poziomu i wszystkich zasobów podrzędnych, które go używają.
Operacja żądania tokena jest kontrolowana przez dyrektywę private-state-token-issuance. Operacje token-redemption i send-redemption-record są kontrolowane przez dyrektywę private-state-token-redemption. W Chrome 132 i nowszych wersjach domyślnie lista dozwolonych dla tych dyrektyw jest ustawiona na * (wszystkie źródła). Oznacza to, że funkcja jest dostępna na stronie najwyższego poziomu, w elementach iframe w tej samej domenie i w elementach iframe z innych domen bez wyraźnego delegowania.
Możesz zrezygnować z wydawania lub realizacji tokenów PST na konkretnych stronach w swojej witrynie, dodając wartości private-state-token-issuance=() i private-state-token-redemption=() do nagłówka Permissions-Policy na każdej stronie.
Możesz też użyć nagłówka Permissions-Policy, aby kontrolować dostęp innych firm do PST. Jako parametry listy źródeł nagłówka użyj wartości self i wszystkich źródeł, do których chcesz zezwolić na dostęp do interfejsu API. Aby na przykład całkowicie wyłączyć używanie PST we wszystkich kontekstach przeglądania z wyjątkiem własnego źródła i https://example.com, ustaw te nagłówki odpowiedzi HTTP:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
Aby włączyć interfejs API dla wszystkich zasobów w wielu domenach, ustaw listę źródeł na *.
Dowiedz się, jak zarządzać funkcjami piaskownicy prywatności za pomocą zasad dotyczących uprawnień, lub dowiedz się więcej o zasadach dotyczących uprawnień.
Rozwiązywanie problemów
PST-y możesz sprawdzać na kartach Sieć i Aplikacja w Narzędziach deweloperskich w Chrome.
Na karcie Sieć:
Na karcie Aplikacja:
Dowiedz się więcej o integracji z Narzędziami deweloperskimi.
Sprawdzone metody dotyczące klienta
Jeśli kluczowe funkcje witryny zależą od określonych wydawców tokenów, nadaj im priorytet. Zanim załadujesz inne skrypty, wywołaj hasPrivateToken(issuer) dla tych preferowanych wydawców. Jest to bardzo ważne, aby zapobiec potencjalnym niepowodzeniom podczas realizacji.
Liczba emitentów na najwyższym poziomie jest ograniczona do 2, a skrypty innych firm mogą też próbować wywoływać funkcję hasPrivateToken(issuer), aby nadać priorytety ulubionym emitentowi. Dlatego już teraz zabezpiecz kluczowych wydawców, aby mieć pewność, że Twoja witryna działa zgodnie z oczekiwaniami.
// Prioritize your critical token issuer.
document.hasPrivateToken('https://critical-issuer.example')
.then(hasToken => {
if (hasToken) {
// Use the token or perform actions based on its availability.
} else {
// Handle the case where the token is not available.
}
});
// Load third-party scripts or secure another token issuer (up to two in total).
Sprawdzone metody dotyczące serwera i rozwiązywanie problemów
Aby serwer wydawcy i serwer odbiorcy działały skutecznie, zalecamy stosowanie tych sprawdzonych metod, aby uniknąć problemów z dostępem, bezpieczeństwem, rejestrowaniem i ruchem w przypadku PST.
- Punkty końcowe muszą stosować silne szyfrowanie przy użyciu TLS 1.3 lub 1.2.
- Twoja infrastruktura musi być gotowa do obsługi zmiennych ilości ruchu (w tym nagłych wzrostów).
- Zadbaj o to, aby klucze były chronione i bezpieczne zgodnie z zasadami kontroli dostępu, strategią zarządzania kluczami i planami ciągłości działania firmy.
- Dodaj do swojego zbioru danych wskaźniki obserwowalności, aby mieć pełniejszy wgląd w używanie, wąskie gardła i problemy z wydajnością po przejściu do wersji produkcyjnej.
Więcej informacji
- Zapoznaj się z dokumentacją dla deweloperów:
- Najpierw przeczytaj omówienie, aby poznać PST i jego możliwości.
- Obejrzyj film wprowadzający do PST (w języku angielskim).
- Wypróbuj demo pliku PST.
- Aby dowiedzieć się więcej o tym interfejsie API, przeczytaj też artykuł na jego temat.
- Dowiedz się więcej o obecnej specyfikacji interfejsu API.
- Dołącz do rozmowy w GitHubie (problemy) lub W3C (zapytania).
- Aby lepiej zrozumieć pojęcia, zapoznaj się z glosariuszem Piaskownicy prywatności.
- Aby dowiedzieć się więcej o pojęciach związanych z Chrome, takich jak „testowanie origin” czy „flagi Chrome”, obejrzyj krótkie filmy i przeczytaj artykuły dostępne na stronie goo.gle/cc.