Sebelumnya, cookie pihak ketiga telah digunakan untuk menyimpan dan menyampaikan informasi tentang status pengguna, seperti status login, informasi tentang perangkat yang mereka gunakan, atau apakah cookie tersebut dikenal dan dipercaya. Misalnya, apakah pengguna telah login dengan SSO, apakah pengguna memiliki jenis perangkat tertentu yang kompatibel, atau apakah pengguna dikenal dan dipercaya. Dengan tidak digunakannya lagi dukungan cookie pihak ketiga, banyak dari kasus penggunaan tersebut harus didukung dengan cara lain.
Token Status Pribadi menawarkan cara untuk berbagi informasi di seluruh web, tetapi dengan cara yang menjaga privasi melalui kontrol pada jumlah data yang benar-benar dapat dibagikan.
Token Status Pribadi (sebelumnya dikenal sebagai Token Kepercayaan) memungkinkan kepercayaan pada keaslian pengguna disampaikan dari satu konteks ke konteks lain, sekaligus membantu situs memerangi penipuan dan membedakan bot dari manusia sungguhan—tanpa pelacakan pasif.
Dokumen ini menguraikan detail teknis untuk menerapkan Token Status Pribadi (PST). Untuk ringkasan umum lainnya, lihat ringkasan PST.
Bagaimana cara kerja Token Status Pribadi?
Hubungan utama yang perlu dipahami dalam PST adalah antara penerbit dan penukaran. Penerbit dan penukaran dapat berada dalam perusahaan yang sama.
- Penerbit - Entitas ini memiliki beberapa sinyal tentang pengguna (misalnya, apakah pengguna tersebut adalah bot atau bukan) dan menyematkan sinyal tersebut ke token yang disimpan di perangkat pengguna (detail selengkapnya di bagian berikutnya).
- Pentukar - Entitas ini mungkin tidak memiliki sinyal tentang pengguna, tetapi perlu mengetahui sesuatu tentang pengguna tersebut (misalnya, apakah pengguna tersebut adalah bot atau bukan) dan meminta untuk menukarkan token dari penerbit guna memahami kepercayaan pengguna tersebut.
Setiap interaksi PST mengharuskan penerbit dan penukaran bekerja sama untuk membagikan sinyal di seluruh web. Sinyal tersebut adalah nilai kasar yang tidak cukup mendetail untuk mengidentifikasi individu.
Apakah Token Status Pribadi cocok untuk saya?
Perusahaan yang membuat keputusan kepercayaan dan ingin informasi tersebut tersedia dalam seluruh konteks dapat memanfaatkan PST. Untuk mengetahui informasi selengkapnya tentang potensi kasus penggunaan PST, lihat dokumentasi kami tentang kasus penggunaan PST.
Menerbitkan dan menukarkan token
Penerapan PST terjadi dalam tiga fase:
- Token yang menerbitkan
- Menukarkan token
- Penerusan data penukaran
Pada fase pertama, token dikeluarkan ke browser (biasanya setelah semacam validasi). Pada fase kedua, entitas lain akan membuat permintaan untuk menukarkan token yang telah dikeluarkan untuk membaca nilai dalam token tersebut. Pada fase terakhir, pihak yang menukarkan menerima data penukaran (RR) dengan nilai yang ada dalam token. Pihak yang menukarkan tersebut kemudian dapat menggunakan data tersebut sebagai pengesahan pengguna tersebut untuk berbagai tujuan.
Tentukan strategi token Anda
Untuk menentukan strategi token, Anda perlu memahami konsep kunci PST (token dan data penukaran), variabel, perilaku, dan batasan agar dapat mempertimbangkan potensi penggunaannya untuk kasus penggunaan Anda.
Token dan data penukaran: apa hubungan antara keduanya?
Setiap perangkat dapat menyimpan hingga 500 token per situs dan penerbit tingkat atas. Selain itu, setiap token memiliki metadata yang menginformasikan kunci mana yang digunakan penerbit untuk menerbitkannya. Informasi tersebut dapat digunakan untuk memutuskan apakah akan menukarkan atau tidak token selama proses penukaran. Data PST disimpan secara internal oleh browser di perangkat pengguna dan hanya dapat diakses oleh PST API.
Saat token ditukarkan, Data Penukaran (RR) akan disimpan di perangkat. Penyimpanan ini berfungsi sebagai cache untuk penukaran di masa mendatang. Ada batas dua penukaran token setiap 48 jam, per perangkat, halaman, dan penerbit. Panggilan penukaran baru akan menggunakan RR yang di-cache jika memungkinkan, bukan menyebabkan permintaan ke penerbit.
- Token baru diterbitkan (maks 500 per penerbit, situs, dan perangkat).
- Semua token disimpan di penyimpanan token di perangkat (serupa dengan penyimpanan cookie).
- Jika tidak ditemukan RR yang aktif, RR baru dapat dibuat setelah penerbitan (maksimum 2 setiap 48 jam).
- RR dianggap aktif hingga masa berlakunya habis dan akan digunakan sebagai cache lokal.
- Panggilan penukaran baru akan mencapai cache lokal (tidak ada RR baru yang dibuat).
Setelah menentukan kasus penggunaan, Anda harus menentukan masa aktif RR dengan cermat karena tindakan ini akan menentukan frekuensi penggunaan RR dalam kasus Anda.
Pastikan Anda memahami perilaku dan variabel penting berikut sebelum menentukan strategi:
| Variabel / perilaku | Deskripsi | Potensi penggunaan |
|---|---|---|
| Metadata kunci token | Setiap token dapat diterbitkan menggunakan satu dan hanya satu kunci kriptografis, dan di PST, ada batasan enam kunci per penerbit. | Salah satu cara potensial untuk menggunakan variabel ini adalah menentukan rentang kepercayaan terhadap token berdasarkan kunci kriptografis Anda (misalnya, kunci 1 = kepercayaan tinggi sedangkan kunci 6 = tidak ada kepercayaan). |
| Tanggal habis masa berlaku token | Tanggal habis masa berlaku token sama dengan tanggal habis masa berlaku kunci. | Kunci dapat dirotasi minimal setiap 60 hari dan semua token yang dikeluarkan dengan kunci yang tidak valid juga dianggap tidak valid. |
| Batas nilai penukaran token | Ada batasan dua penukaran token per perangkat dan penerbit setiap 48 jam. | Bergantung pada perkiraan jumlah penukaran yang diperlukan oleh kasus penggunaan Anda setiap 48 jam. |
| Jumlah maksimum penerbit per asal tingkat atas | Jumlah maksimum penerbit per origin tingkat atas saat ini adalah dua. | Tentukan penerbit setiap halaman dengan cermat. |
| Token per penerbit di perangkat | Jumlah maksimum token per penerbit di perangkat tertentu saat ini adalah 500. | Pastikan untuk menjaga jumlah token kurang dari 500 per penerbit. Pastikan untuk menangani error di halaman web Anda saat mencoba mengeluarkan token. |
| Rotasi komitmen utama | Setiap penerbit PST diwajibkan untuk mengekspos endpoint dengan komitmen kunci yang dapat diubah setiap 60 hari dan setiap rotasi yang lebih cepat dari itu akan diabaikan. | Jika masa berlaku kunci Anda akan berakhir dalam waktu kurang dari 60 hari, Anda harus memperbarui komitmen utama Anda sebelum tanggal tersebut untuk menghindari gangguan (lihat detail). |
| Masa aktif catatan penukaran | Masa pakai RR dapat ditentukan untuk menentukan tanggal habis masa berlaku. Karena RR di-cache untuk menghindari panggilan penukaran baru yang tidak perlu ke penerbit, penting untuk memastikan memiliki sinyal penukaran yang cukup baru. | Karena ada batas kapasitas penukaran dua token setiap 48 jam, penting untuk menentukan masa aktif RR agar dapat melakukan panggilan penukaran dengan sukses setidaknya selama periode waktu ini (masa aktif RR harus ditetapkan sebagaimana mestinya). Sebaiknya tetapkan masa aktif ini dalam urutan minggu. |
Contoh skenario
Skenario #1: Masa aktif RR adalah kurang dari 24 jam (t=t) dan penukaran dilakukan beberapa kali selama periode 48 jam.
Skenario #2: Masa aktif RR adalah 24 jam dan penukaran dilakukan beberapa kali selama periode 48 jam.
Skenario #3: Masa aktif RR adalah 48 jam dan penukaran dilakukan beberapa kali selama periode 48 jam.
Menjalankan demo
Sebelum menggunakan PST, sebaiknya siapkan demo terlebih dahulu. Untuk mencoba demo PST , Anda perlu menjalankan Chrome dengan flag untuk mengaktifkan komitmen kunci penerbit demo (ikuti petunjuk yang tersedia di halaman demo).
Dengan menjalankan demo ini, browser Anda akan menggunakan penerbit demo dan server penukaran untuk menyediakan dan menggunakan token.
Pertimbangan teknis
Demo akan berjalan dengan sangat baik jika Anda menerapkan langkah-langkah berikut:
- Pastikan Anda menghentikan semua instance Chrome sebelum menjalankan Chrome dengan tanda.
- Jika Anda menjalankan pada komputer Windows, baca panduan ini tentang cara meneruskan parameter ke biner Chrome yang dapat dieksekusi.
- Buka Chrome DevTools di bagian Applications > Storage > Private State Tokens saat menggunakan aplikasi demo untuk melihat token yang dikeluarkan/ditukarkan oleh penerbit demo.
Menyiapkan untuk adopsi
Menjadi penerbit
Penerbit memainkan peran penting dalam PST. Token menetapkan nilai pada token untuk menentukan apakah pengguna tersebut adalah bot atau bukan. Jika ingin memulai PST sebagai penerbit, Anda harus mendaftar dengan menyelesaikan Proses pendaftaran penerbit.
Untuk mengajukan permohonan menjadi penerbit, operator situs penerbit harus membuka masalah baru di repositori GitHub menggunakan template "Penerbit PST Baru". Ikuti panduan di repositori untuk mengisi masalah. Setelah diverifikasi, endpoint akan digabungkan ke repositori ini dan infrastruktur sisi server Chrome akan mulai mengambil kunci tersebut.
Server penerbit
Penerbit dan penukaran adalah aktor utama untuk PST; server dan token adalah alat utama untuk PST. Meskipun kami telah menyediakan beberapa detail tentang token dan di dokumentasi GitHub, kami ingin menawarkan detail lebih lanjut tentang server PST. Untuk menyiapkan sebagai penerbit PST, Anda harus menyiapkan server penerbit terlebih dahulu.
Men-deploy lingkungan Anda: server penerbit
Untuk mengimplementasikan server penerbit token, Anda harus membuat aplikasi sisi server sendiri yang mengekspos endpoint HTTP.
Komponen penerbit terdiri dari dua modul utama: (1) server penerbit dan (2) penerbit token.
Seperti semua aplikasi yang terhubung ke web, kami merekomendasikan lapisan perlindungan tambahan ke server penerbit Anda.
Server penerbit: Dalam contoh implementasi kami, server penerbit kami adalah server Node.js yang menggunakan framework Express untuk menghosting endpoint HTTP Penerbit. Anda dapat melihat kode contoh di GitHub.
Penerbit token: Komponen kriptografi penerbit tidak memerlukan bahasa tertentu, tetapi karena persyaratan performa komponen ini, kami menyediakan implementasi C sebagai contoh yang menggunakan library Boring SSL untuk mengelola token. Anda dapat menemukan contoh kode penerbit dan informasi selengkapnya tentang penginstalan di GitHub
Kunci: Komponen penerbit token menggunakan kunci EC kustom untuk mengenkripsi token. Kunci ini harus dilindungi dan disimpan dalam penyimpanan yang aman.
Persyaratan teknis untuk server penerbit
Sesuai dengan protokol, Anda harus mengimplementasikan setidaknya dua endpoint HTTP di server penerbit Anda:
- Komitmen kunci (misalnya,
/.well-known/private-state-token/key-commitment): Endpoint ini adalah tempat detail kunci publik enkripsi Anda akan tersedia untuk browser guna mengonfirmasi bahwa server Anda sah. - Penerbitan token (misalnya,
/.well-known/private-state-token/issuance): Endpoint penerbit token tempat semua permintaan token akan ditangani. Endpoint ini akan menjadi titik integrasi untuk komponen penerbit token.
Seperti yang disebutkan sebelumnya, karena tingginya perkiraan traffic yang akan ditangani server ini, sebaiknya Anda men-deploy-nya menggunakan infrastruktur yang skalabel (misalnya, di lingkungan cloud) agar dapat menyesuaikan backend Anda berdasarkan permintaan variabel.
Mengirim panggilan ke server penerbit
Implementasikan panggilan pengambilan situs ke stack penerbit Anda untuk mengeluarkan token baru.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Server penebus
Anda harus mengimplementasikan layanan penukaran token dengan membangun aplikasi sisi server Anda sendiri. Dengan begitu, Anda dapat membaca token yang dikirim penerbit. Langkah-langkah berikut menguraikan cara menukarkan token serta cara membaca data penukaran yang terkait dengan token tersebut.
Anda dapat memilih untuk menjalankan penerbit dan penebus di server yang sama (atau grup server).
Persyaratan teknis untuk server penukaran
Sesuai dengan protokol, Anda harus mengimplementasikan setidaknya dua endpoint HTTP untuk server penukaran:
/.well-known/private-state-token/redemption: endpoint tempat semua penukaran token akan ditangani. Endpoint ini akan menjadi tempat komponen penukaran token akan diintegrasikan
Mengirim panggilan ke server penukaran
Untuk menukarkan token, Anda harus menerapkan panggilan pengambilan situs ke stack penukaran guna menukarkan token yang dikeluarkan sebelumnya.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Lihat contoh kode.
Setelah menukarkan token, Anda dapat mengirim data penukaran (RR) dengan melakukan panggilan pengambilan lain:
// 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>]
}
});
Lihat contoh kode.
Men-deploy implementasi Anda
Untuk menguji implementasi Anda, pertama-tama buka halaman web tempat panggilan yang dikeluarkan dilakukan dan konfirmasi bahwa token dibuat dengan mengikuti logika Anda. Verifikasi di backend Anda bahwa panggilan dilakukan sesuai dengan spesifikasi. Kemudian, buka halaman web tempat panggilan penukaran dilakukan dan pastikan bahwa RR dibuat, mengikuti logika Anda.
Deployment dunia nyata
Sebaiknya pilih situs target yang merupakan bagian dari kasus penggunaan khusus Anda:
- Sejumlah kecil kunjungan bulanan (~ <1 juta kunjungan/bulan): Anda harus memulai dengan men-deploy API ke audiens kecil terlebih dahulu
- Anda memilikinya dan mengontrolnya: Jika perlu, Anda dapat dengan cepat menonaktifkan implementasi tersebut tanpa persetujuan yang kompleks
- Tidak boleh lebih dari satu penerbit: Untuk membatasi jumlah token agar dapat menyederhanakan pengujian.
- Tidak lebih dari dua penukaran: Anda perlu menyederhanakan pemecahan masalah jika terjadi masalah.
Pemecahan masalah
Anda dapat memeriksa PST dari tab Network dan Application di Chrome DevTools.
Pada tab Jaringan:
Pada tab Application:
Baca selengkapnya tentang integrasi DevTools ini.
Praktik terbaik dan pemecahan masalah server
Agar penerbit dan server penukaran dapat beroperasi secara efektif, sebaiknya terapkan praktik terbaik berikut untuk memastikan Anda tidak mengalami masalah akses, keamanan, logging, atau traffic untuk PST.
- Endpoint Anda harus menerapkan kriptografi yang kuat dengan menggunakan TLS 1.3 atau 1.2.
- Infrastruktur Anda harus siap menangani volume traffic variabel (termasuk lonjakan).
- Pastikan kunci Anda dilindungi dan aman, selaras dengan Kebijakan Kontrol Akses, Strategi Pengelolaan Kunci, dan Rencana Kelangsungan Bisnis.
- Tambahkan metrik kemampuan observasi ke stack untuk memastikan Anda akan memiliki visibilitas untuk memahami penggunaan, bottleneck, dan masalah performa setelah beralih ke produksi.
Informasi selengkapnya
- Tinjau dokumen developer:
- Mulailah dengan membaca ringkasan untuk mendapatkan informasi terbaru tentang PST dan kemampuannya.
- Tonton video intro PST.
- Coba demo PST.
- Baca juga penjelasan API untuk memahami detail lebih lanjut.
- Baca selengkapnya tentang spesifikasi saat ini API.
- Berkontribusi pada percakapan melalui masalah GitHub atau panggilan W3C.
- Untuk lebih memahami salah satu terminologi, tinjau glosarium Privacy Sandbox.
- Untuk mempelajari lebih lanjut konsep Chrome, seperti 'uji coba origin' atau 'flag Chrome', tinjau video singkat dan artikel yang tersedia di goo.gle/cc.