Pada masa lalu, cookie pihak ketiga telah digunakan untuk menyimpan dan menyampaikan informasi tentang status pengguna, seperti status login mereka, informasi tentang perangkat yang mereka gunakan, atau apakah mereka dikenal dan terpercaya. Misalnya, apakah telah masuk dengan SSO, apakah pengguna memiliki jenis perangkat perangkat lunak, atau apakah pengguna dikenal dan dipercaya. Dengan dukungan cookie pihak ketiga tidak digunakan lagi, banyak dari kasus penggunaan ini perlu didukung dengan cara lain.
Token Status Pribadi menawarkan cara untuk berbagi informasi di seluruh web, tetapi dalam yang menjaga privasi melalui kontrol terhadap jumlah data yang benar-benar dapat dibagikan.
Token Status Pribadi (sebelumnya disebut Token Kepercayaan) memungkinkan kepercayaan keaslian untuk disampaikan dari satu konteks ke konteks lain sekaligus membantu situs melawan penipuan dan membedakan bot dengan manusia sungguhan—tanpa pelacakan pasif.
Dokumen ini menjelaskan detail teknis untuk menerapkan Status Pribadi Token (PST). Untuk garis besar yang lebih jelas, lihat Ringkasan PST.
Bagaimana cara kerja Token Status Pribadi?
Hubungan utama yang harus 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 (untuk misalnya, apakah pengguna itu bot atau bukan) dan menyematkan sinyal itu ke yang disimpan di perangkat pengguna (detail selengkapnya di bagian berikutnya).
- Penukaran - Entitas ini mungkin tidak memiliki sinyal tentang pengguna, tetapi perlu mengetahui sesuatu tentang mereka (misalnya, apakah pengguna itu adalah bot atau tidak) dan meminta untuk menukarkan token dari penerbit guna memahami kepercayaan dari pengguna tersebut.
Setiap interaksi PST mengharuskan penerbit dan penukaran untuk bekerja sama untuk berbagi sinyal di seluruh web. Sinyal tersebut merupakan nilai kasar yang tidak mendetail untuk mengidentifikasi individu.
Apakah Token Status Pribadi tepat untuk saya?
Perusahaan yang membuat keputusan kepercayaan dan menginginkan informasi tersebut yang tersedia dalam berbagai konteks bisa mendapatkan manfaat dari PST. Untuk mengetahui informasi selengkapnya tentang kemungkinan kasus penggunaan jumlah PST, lihat dokumentasi kami tentang kasus penggunaan PST.
Menerbitkan dan menukarkan token
Implementasi PST berlangsung dalam tiga fase:
- Token yang diterbitkan
- Menukarkan token
- Penerusan data penukaran
Pada fase pertama, token dikeluarkan ke {i>browser<i} (biasanya setelah beberapa validasi). Pada fase kedua, entitas lain akan membuat permintaan untuk menukarkan token yang telah dikeluarkan untuk membaca nilai dalam token tersebut. Di final pihak yang menukarkan akan menerima catatan penukaran (RR) dengan nilai yang yang terdapat dalam token. Pihak penukaran tersebut kemudian dapat menggunakan catatan itu sebagai pengesahan pengguna tersebut untuk berbagai tujuan.
Menentukan strategi token Anda
Untuk menentukan strategi token, Anda perlu memahami konsep kunci PST (token dan catatan penukaran), variabel, perilaku, dan batasan agar dapat pikirkan tentang potensi penggunaannya dalam kasus penggunaan Anda.
Token dan catatan penukaran: apa hubungannya?
Setiap perangkat dapat menyimpan hingga 500 token per situs dan penerbit tingkat atas. Selain itu, setiap token memiliki {i>metadata<i} yang menginformasikan kunci mana yang digunakan penerbit untuk menerbitkannya. Bahwa informasi dapat digunakan untuk memutuskan penukaran token atau bukan token selama penukaran {i>checkout<i}. Data PST disimpan secara internal oleh browser di perangkat pengguna dan hanya dapat diakses oleh PST API.
Saat token ditukarkan, Catatan Penukaran (RR) akan disimpan di perangkat. Penyimpanan ini berfungsi sebagai cache untuk penukaran di masa mendatang. Ada batasan dua penukaran token setiap 48 jam, per perangkat, halaman, dan penerbit. Penukaran baru akan menggunakan RR yang di-cache jika memungkinkan, bukan menyebabkan permintaan ke penerbit berita.
- Token baru diterbitkan (maks 500 per penerbit, situs, dan perangkat).
- Semua token disimpan di penyimpanan token di perangkat (mirip dengan penyimpanan cookie).
- Jika tidak ditemukan RR aktif, maka RR baru dapat dibuat setelah diterbitkan (maksimum 2 setiap 48 jam).
- RR dianggap aktif sampai kedaluwarsa dan akan digunakan sebagai di cache oleh pengguna.
- Panggilan penukaran baru akan mencapai cache lokal (tidak ada RR baru yang dibuat).
Setelah mendefinisikan kasus penggunaan, Anda harus menentukan masa aktif RR dengan cermat Cara ini akan menentukan berapa kali Anda akan dapat menggunakannya dalam ini masalahnya atau bukan.
Pastikan Anda memahami perilaku dan variabel penting berikut ini sebelum menentukan strategi Anda:
| Variabel / perilaku | Deskripsi | Potensi penggunaan |
|---|---|---|
| Metadata kunci token | Setiap token dapat diterbitkan dengan menggunakan satu kunci kriptografis saja dan di PST ada batasan enam kunci per penerbit. | Salah satu cara yang dapat dilakukan untuk menggunakan variabel ini adalah dengan menentukan rentang kepercayaan ke token Anda berdasarkan kunci kriptografis Anda (misalnya, kunci 1 = tingkat 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 setidaknya 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. | Tergantung pada perkiraan jumlah penukaran yang diperlukan oleh penggunaan Anda setiap 48 jam. |
| Jumlah maksimum penerbit per asal tingkat atas | Jumlah maksimum penerbit per asal tingkat atas saat ini adalah dua. | Tentukan penerbit setiap halaman dengan cermat. |
| Token per penerbit di perangkat | Jumlah maksimum token per penerbit pada perangkat tertentu saat ini 500. | Pastikan untuk menjaga jumlah token kurang dari 500 per penerbit. Pastikan untuk menangani error di halaman web Anda saat mencoba melaporkan masalah token kata. |
| Rotasi komitmen utama | Setiap penerbit PST wajib mengekspos endpoint dengan kunci komitmen yang dapat diubah setiap 60 hari dan rotasi apa pun dengan lebih cepat maka akan diabaikan. | Jika masa berlaku kunci Anda akan berakhir dalam waktu kurang dari 60 hari, kunci tersebut harus untuk memperbarui komitmen utama Anda sebelum tanggal tersebut guna menghindari gangguan (lihat detail). |
| Masa aktif catatan penukaran | Masa hidup RR dapat didefinisikan untuk menentukan berakhirnya masa berlaku tanggal. Karena RR di-cache untuk menghindari panggilan penukaran baru yang tidak perlu kepada penerbit, ini penting untuk memastikan bahwa Anda memiliki untuk mendapatkan sinyal penukaran. | Karena ada batas tingkat penukaran dua token setiap 48 jam, penting untuk menentukan masa hidup RR Anda agar dapat menjalankan panggilan penukaran yang berhasil selama setidaknya jangka waktu ini (RR masa aktif harus ditetapkan dengan tepat). Sebaiknya, tetapkan masa hidup berdasarkan urutan minggu. |
Contoh skenario
Skenario #1: Masa pakai RR adalah kurang dari 24 jam (t=t) dan penukarannya dilakukan beberapa kali selama jendela 48 jam.
Skenario #2: Masa pakai RR adalah 24 jam dan penukaran dilakukan beberapa kali selama jangka waktu 48 jam.
Skenario #3: Masa pakai RR adalah 48 jam dan penukaran dilakukan beberapa kali selama periode 48 jam.
Menjalankan demo
Sebelum menggunakan PST, sebaiknya siapkan demo terlebih dahulu. Untuk dicoba demo PST , Anda harus menjalankan Chrome dengan tanda untuk mengaktifkan penerbit demo komitmen utama (ikuti petunjuk yang tersedia di demo halaman).
Dengan menjalankan demo ini, browser Anda menggunakan penerbit dan penukaran demo server untuk menyediakan dan memakai token.
Pertimbangan teknis
Demo akan berjalan paling baik jika Anda menerapkan langkah-langkah berikut:
- Pastikan Anda menghentikan semua instance Chrome sebelum menjalankan Chrome dengan tanda.
- Jika Anda berjalan di komputer Windows, lihatlah dalam panduan ini tentang cara meneruskan parameter ke biner Chrome yang dapat dieksekusi.
- Buka Chrome DevTools di bagian Applications > Penyimpanan > Status Pribadi Token saat menggunakan aplikasi demo untuk melihat token yang dikeluarkan/ditukarkan oleh penerbit demo.
Menyiapkan untuk adopsi
Menjadi penerbit
Penerbit memiliki peran penting dalam PST. Mereka menetapkan nilai pada token untuk menentukan apakah pengguna adalah bot atau bukan. Jika Anda ingin memulai PST sebagai penerbit, Anda harus mendaftar dengan melengkapi Proses pendaftaran penerbit.
Untuk mengajukan permohonan menjadi penerbit, operator situs penerbit harus membuka domain baru edisi di GitHub repositori menggunakan "New PST Penerbit" {i>template<i}. Ikuti panduan di repositori untuk mengisi masalah. Setelah endpoint diverifikasi, endpoint akan digabungkan ke dalam 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 kunci untuk PST. Meskipun kami telah memberikan beberapa detail tentang token dan dokumentasi GitHub, kami ingin menawarkan detail lebih lanjut tentang server PST. Untuk melakukan penyiapan sebagai penerbit PST, Anda memerlukan untuk menyiapkan server penerbit terlebih dahulu.
Men-deploy lingkungan Anda: server penerbit
Untuk mengimplementasikan server penerbit token, Anda harus membangun sisi server Anda sendiri aplikasi yang mengekspos endpoint HTTP.
Komponen penerbit terdiri dari dua modul utama: (1) server penerbit dan (2) penerbit token.
Seperti pada semua aplikasi yang berhubungan dengan web, kami menyarankan lapisan perlindungan tambahan ke server penerbit Anda.
Server penerbit: Dalam contoh implementasi kami, server penerbit 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 kinerja komponen ini, kami menyediakan implementasi C sebagai contoh, yang menggunakan opsi 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 di penyimpanan aman.
Persyaratan teknis untuk server penerbit
Sesuai protokol, Anda harus menerapkan 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 bagi browser untuk dikonfirmasi bahwa server Anda sah. - Penerbitan token (misalnya,
/.well-known/private-state-token/issuance): Endpoint penerbitan token tempat semua permintaan token akan ditangani. Ini endpoint akan menjadi titik integrasi untuk komponen penerbit token.
Seperti yang disebutkan sebelumnya, karena tingginya lalu lintas yang diperkirakan, server ini akan tidak perlu ditangani, sebaiknya Anda men-deploy-nya menggunakan infrastruktur Anda (misalnya, di lingkungan cloud) untuk dapat menyesuaikan backend berdasarkan permintaan variabel.
Mengirim panggilan ke server penerbit
Terapkan panggilan pengambilan situs ke stack penerbit untuk menerbitkan panggilan baru token kata.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Server penukaran
Anda harus menerapkan layanan penukaran token dengan membangun token sendiri aplikasi sisi server. Hal ini akan memungkinkan Anda untuk membaca token yang dimiliki penerbit dikirimkan. Langkah-langkah berikut menguraikan cara menukarkan token serta cara membaca catatan penukaran yang terkait dengan token tersebut.
Anda dapat memilih untuk menjalankan penerbit dan penukaran di server yang sama (atau grup server tertentu).
Persyaratan teknis untuk server penukaran
Sesuai protokol, Anda harus menerapkan setidaknya dua endpoint HTTP untuk server penukaran Anda:
/.well-known/private-state-token/redemption: endpoint tempat semua penukaran token akan ditangani. Endpoint ini akan menjadi tempat token komponen penukaran akan diintegrasikan
Mengirim panggilan ke server penukaran
Untuk menukarkan token, Anda harus menerapkan panggilan pengambilan situs tumpukan penebus Anda untuk 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 catatan penukaran (RR) dengan melakukan panggilan ambil 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 penerapan Anda
Untuk menguji implementasi Anda, pertama-tama navigasikan ke halaman web tempat penerbitan panggilan dilakukan dan konfirmasi bahwa token dibuat mengikuti logika Anda. Verifikasi di backend Anda bahwa panggilan dilakukan sesuai dengan spesifikasi. Kemudian, buka halaman web tempat panggilan penukaran dilakukan dan konfirmasi bahwa RR dibuat, mengikuti logika Anda.
Deployment di dunia nyata
Sebaiknya Anda memilih situs target yang merupakan bagian dari penggunaan khusus Anda kasus:
- Jumlah 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 segera menonaktifkan implementasi tanpa persetujuan yang kompleks
- Tidak lebih dari satu penerbit: Untuk membatasi jumlah token agar dapat menyederhanakan pengujian.
- Tidak lebih dari dua penukar: Anda perlu menyederhanakan pemecahan masalah di yang sesungguhnya.
Kebijakan izin
Agar berfungsi dengan benar, PST API harus tersedia di halaman tingkat atas dan subresource apa pun yang menggunakan API tersebut.
Operasi permintaan token dikontrol oleh perintah private-state-token-issuance. Operasi token-redemption dan send-redemption-record dikontrol oleh perintah private-state-token-redemption. Secara default, daftar yang diizinkan untuk perintah ini ditetapkan ke mandiri. Artinya, fitur tersebut hanya tersedia untuk halaman tingkat teratas (dan iframe origin yang sama), dan tidak tersedia untuk iframe lintas origin tanpa delegasi eksplisit oleh halaman.
Anda dapat memilih untuk tidak ikut menerbitkan atau menukarkan token PST untuk halaman tertentu di situs Anda dengan menyertakan private-state-token-issuance=() dan private-state-token-redemption=() di header Permissions-Policy untuk setiap halaman.
Anda juga dapat menggunakan header Permissions-Policy untuk mengontrol akses pihak ketiga ke PST. Sebagai parameter untuk daftar asal header, gunakan self dan origin apa pun yang Anda izinkan aksesnya ke API. Misalnya, untuk sepenuhnya menonaktifkan penggunaan PST dalam semua konteks penjelajahan kecuali untuk asal Anda sendiri dan https://example.com, setel header respons HTTP berikut:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
Agar dapat mengaktifkan API untuk semua resource lintas asal, tetapkan daftar origin ke *.
Pelajari cara mengontrol fitur Privacy Sandbox dengan Kebijakan Izin atau pelajari lebih dalam cara memahami Kebijakan Izin.
Pemecahan masalah
Anda dapat memeriksa PST dari tab Jaringan dan Aplikasi Chrome DevTools.
Pada tab Jaringan:
Pada tab Application:
Baca selengkapnya tentang hal ini Integrasi DevTools.
Praktik terbaik klien
Jika fungsi penting situs Anda bergantung pada penerbit token tertentu, prioritaskan penerbit tersebut. Panggil hasPrivateToken(issuer) untuk penerbit pilihan ini sebelum memuat skrip lainnya. Hal ini penting untuk mencegah potensi kegagalan penukaran.
Jumlah penerbit per tingkat teratas dibatasi dua, dan skrip pihak ketiga juga dapat mencoba memanggil hasPrivateToken(issuer) untuk memprioritaskan penerbit pilihan mereka sendiri. Jadi, pastikan penerbit penting Anda terlebih dahulu untuk memastikan situs Anda beroperasi seperti yang diharapkan.
// 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).
Praktik terbaik dan pemecahan masalah server
Agar penerbit dan server penukaran Anda beroperasi secara efektif, sebaiknya menerapkan praktik terbaik berikut untuk memastikan bahwa Anda tidak mengalami tantangan akses, keamanan, logging, atau lalu lintas data untuk PST.
- Endpoint Anda harus menerapkan kriptografi yang kuat dengan menggunakan TLS 1.3 atau 1.2.
- Infrastruktur Anda harus siap menangani volume traffic yang bervariasi (termasuk lonjakan).
- Pastikan kunci Anda dilindungi dan aman, sesuai dengan Akses Anda Kebijakan Kontrol, Strategi Pengelolaan Utama, dan Rencana Kelangsungan Bisnis.
- Tambahkan metrik kemampuan observasi ke stack untuk memastikan Anda memiliki visibilitas untuk memahami penggunaan, bottleneck, dan masalah performa setelah lalu ke jalur 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 API penjelasan untuk lebih memahami secara detail.
- Baca selengkapnya tentang spesifikasi API.
- Berkontribusilah dalam percakapan melalui GitHub masalah atau W3C panggilan telepon.
- Untuk lebih memahami salah satu terminologi, tinjau Glosarium Privacy Sandbox.
- Untuk mempelajari konsep Chrome lebih lanjut, seperti 'uji coba origin' atau 'Tanda Chrome', tinjau video dan artikel singkat yang tersedia dari goo.gle/cc.