Laporan triwulanan untuk Kuartal 2 2022 merangkum masukan ekosistem yang diterima terkait proposal Privacy Sandbox dan respons Chrome.
Sebagai bagian dari komitmennya kepada CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox-nya (lihat paragraf 12 dan 17(c)(ii) Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima oleh Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang disediakan di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menyambut masukan yang diterima dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.
Tema masukan diberi peringkat menurut prevalensi per API. Hal ini dilakukan dengan mengambil agregasi jumlah masukan yang telah diterima tim Chrome seputar tema tertentu dan mengaturnya dalam urutan kuantitas dalam urutan menurun. Tema masukan umum diidentifikasi dengan meninjau topik diskusi dari rapat publik (W3C, PatCG, IETF), masukan langsung, GitHub, dan pertanyaan umum yang muncul melalui tim internal Google dan formulir publik.
Lebih khusus lagi, menit rapat untuk rapat badan standar web ditinjau dan, untuk masukan langsung, catatan Google terkait pertemuan pemangku kepentingan 1:1, email yang diterima oleh masing-masing engineer, milis API, dan formulir masukan publik juga dipertimbangkan. Google kemudian berkoordinasi dengan tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif dari tema yang muncul sehubungan dengan setiap API.
Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat terhadap masalah yang diajukan oleh pemangku kepentingan, dan menentukan posisi khusus untuk tujuan latihan pelaporan publik ini. Dengan mencerminkan fokus pengembangan dan pengujian saat ini, kami menerima pertanyaan dan masukan khususnya sehubungan dengan Topics, Fledge, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum memiliki respons Chrome yang dipertimbangkan.
Glosarium akronim
- CHIP
- Cookie yang Memiliki Status Dipartisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Pengelolaan Kredensial Federasi
- FPS
- Set Pihak Pertama
- IAB
- Interactive Advertising Bureau
- IDP (IDP)
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Protokol Internet
- openRTB
- Bidding real-time
- lewat batas waktu
- Uji Coba Origin
- PatCG
- Grup Komunitas Teknologi Periklanan Pribadi
- RP
- Pesta Santai
- SSP
- Platform Sisi Suplai
- TEE
- Trusted Execution Environment
- UA
- String Agen Pengguna
- UA-CH
- Petunjuk Klien Agen Pengguna
- W3C
- Konsorsium World Wide Web
- WIPB
- Kebutaan IP yang Disengaja
Masukan umum, tidak ada API/Teknologi spesifik
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Rentang waktu yang lebih jelas | Jadwal rilis yang lebih jelas dan mendetail untuk teknologi Privacy Sandbox. | Kami menetapkan rencana kami saat ini untuk jadwal deployment di privacysandbox.com, dan memperbaruinya setiap bulan. Hal ini mempertimbangkan waktu pengembangan bagi developer Chrome dan web, serta masukan yang kami terima dari ekosistem yang lebih luas terkait waktu yang diperlukan untuk menguji dan mengadopsi teknologi baru. Setiap teknologi melewati beberapa langkah mulai dari pengujian hingga rilis (peluncuran) dan waktu dari setiap langkah didasarkan pada apa yang kami pelajari dan temukan di langkah sebelumnya. Meskipun saat ini kami tidak memiliki rilis pasti, kami akan memastikan untuk memperbarui linimasa publik kami di privacysandbox.com. |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Kekhawatiran bahwa teknologi Privacy Sandbox mengutamakan developer yang lebih besar dan bahwa situs khusus (lebih kecil) berkontribusi lebih besar daripada situs generik (lebih besar). | Kami memahami bahwa beberapa developer memiliki kekhawatiran tentang dampak teknologi Privacy Sandbox. Google telah berkomitmen kepada CMA untuk tidak merancang atau menerapkan proposal Privacy Sandbox dengan cara yang mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, dan mempertimbangkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan, serta dampaknya terhadap hasil privasi dan pengalaman pengguna. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini.
Seiring berjalannya pengujian Privacy Sandbox, salah satu pertanyaan utama yang akan kami nilai adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan spesifik dan dapat ditindaklanjuti yang dapat membantu kami meningkatkan desain teknis lebih lanjut. |
| Jadwal penghentian penggunaan cookie pihak ketiga | Permintaan untuk menghindari penundaan lebih lanjut terkait penghentian penggunaan cookie pihak ketiga | Kami telah menerima masukan dari beberapa pemangku kepentingan yang ingin Chrome melanjutkan penghentian cookie pihak ketiga tanpa penundaan, dan kami telah mendengar dari beberapa pemangku kepentingan yang meyakini bahwa diperlukan lebih banyak waktu untuk menguji dan mengadopsi teknologi Privacy Sandbox. Kami berkomitmen untuk menindaklanjuti secara bertanggung jawab mengingat kompleksitas teknologi dan pentingnya ekosistem untuk melakukan segalanya dengan benar. Masukan dari industri dan badan pengatur sangat penting untuk proses ini. |
| Jadwal penghentian penggunaan cookie pihak ketiga | Permintaan untuk menunda penghentian penggunaan cookie pihak ketiga, dan memberikan lebih banyak waktu untuk menguji API. | Kami telah menerima masukan dari beberapa pemangku kepentingan yang ingin Chrome melanjutkan penghentian cookie pihak ketiga tanpa penundaan, dan kami telah mendengar dari beberapa pemangku kepentingan yang meyakini bahwa diperlukan lebih banyak waktu untuk menguji dan mengadopsi teknologi Privacy Sandbox. Kami berkomitmen untuk menindaklanjuti secara bertanggung jawab mengingat kompleksitas teknologi dan pentingnya ekosistem untuk melakukan segalanya dengan benar. Masukan dari industri dan badan pengatur sangat penting untuk proses ini. |
| Permintaan dokumentasi | Permintaan untuk lebih banyak resource yang menjelaskan cara mengelola pengujian, analisis, dan implementasi. | Kami menghargai bahwa developer merasa materi kami saat ini bermanfaat, dan kami berkomitmen untuk menyediakan lebih banyak materi, termasuk waktu konsultasi developer dan dokumentasi teknis selama beberapa minggu dan bulan mendatang, sehingga developer dapat terus memahami cara teknologi baru dapat berguna bagi mereka.
Kami juga telah mengadakan sesi Office Hours developer eksternal publik untuk berbagi praktik terbaik dan demo beserta sesi Tanya Jawab dengan pemimpin Produk dan Engineering untuk memungkinkan diskusi/pertanyaan langsung. |
| Keahlian industri | Tim Chrome yang terlibat dengan badan standar tidak memiliki keahlian dalam ekosistem iklan yang diperlukan untuk menyeimbangkan privasi dan utilitas dengan benar. | Kami menyadari bahwa kami memiliki tanggung jawab besar, dan kami bergantung pada masukan spesifik untuk melakukannya dengan benar. Kami juga menganggap privasi dan efektivitas sebagai kriteria desain yang penting dan diperlukan. Di seluruh tim yang mengerjakan Privacy Sandbox untuk Web, jumlah total tahun bekerja dalam ekosistem iklan berjumlah ratusan. |
Tampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Terdapat kekhawatiran tentang nilai yang dibuat dan distribusi nilai tersebut untuk situs, bergantung pada tingkat traffic atau seberapa khusus konten situs tersebut. | Kegunaan API akan dieksplorasi melalui pengujian. Chrome mengharapkan taksonomi dan parameter lainnya berkembang berdasarkan hasil pengujian. Evolusi taksonomi atau parameter mungkin tidak memerlukan perubahan inkompatibilitas mundur. Selain itu, Chrome mengharapkan masukan untuk terus memengaruhi evolusi Topics API setelah cookie pihak ketiga tidak digunakan lagi. |
| Taksonomi | Pemangku kepentingan industri ingin memiliki suara dalam memengaruhi taksonomi. | Chrome tetap menerima masukan pada taksonomi. Chrome sangat tertarik dengan masukan tentang model tata kelola untuk memodifikasi taksonomi, dan diskusi tentang cara lembaga industri lain dapat memainkan peran yang lebih aktif dalam mengembangkan dan memelihara taksonomi dalam jangka panjang. |
| Histori penjelajahan tidak cukup | Proposal untuk menampilkan topik yang telah dilihat penelepon pada minggu sebelumnya jika pengguna tidak memiliki cukup histori penjelajahan untuk membuat 5 topik selama seminggu terakhir | Untuk desain kita saat ini, mereka dipilih secara acak. Kami akan menyelidiki korelasi dengan topik sebelumnya dan mempertimbangkan apakah ada kemungkinan untuk menyertakannya. Namun, korelasi mungkin memiliki pertimbangan privasi yang merugikan yang perlu diperhitungkan. |
| Memanggil Topics atas nama penayang | Dapatkah penyedia layanan pihak ketiga membagikan Topics kepada penerbit? | Ya, itu adalah cara yang kami harapkan dari Topics yang akan digunakan. |
| Potensi vektor serangan | Mengidentifikasi topik yang bising | Berdasarkan masukan dari banyak pengguna dalam ekosistem, Chrome memilih untuk memfilter topik dan memperkenalkan derau. Keputusan ini dibuat dengan mempertimbangkan privasi - untuk membatasi akses ke informasi bagi mereka yang tidak memiliki akses ke informasi tersebut dan masing-masing akan menimbulkan penolakan yang masuk akal bagi pengguna. Kami menyadari bahwa keputusan tersebut memiliki kelemahan, seperti vektor serangan yang dijelaskan di sini. Namun, penilaian kami adalah bahwa manfaat privasi lebih besar daripada potensi risikonya. Kami menyambut baik diskusi publik tentang keputusan ini. |
| Kelayakan Uji Coba Origin | Apakah ada cara untuk mendeteksi apakah pengguna memenuhi syarat untuk Uji Coba Origin? | Fitur uji coba origin mungkin tidak tersedia bagi pengguna karena setelan browser atau faktor lainnya, meskipun jika mereka mengunjungi halaman web yang menyediakan token uji coba yang valid dan browser mereka disertakan dalam grup tempat uji coba diaktifkan.
Karena alasan tersebut, deteksi fitur harus selalu digunakan untuk memeriksa apakah fitur uji coba origin tersedia, sebelum mencoba menggunakannya. |
| Dampak performa | Masalah overhead dan latensi dengan Topics | Kami meminta masukan terkait pendekatan untuk menghindari iframe x-origin yang mahal dan lambat, serta untuk proposal untuk menguraikan Topics API sehingga mendapatkan topik tidak mengubah status penjelajahan. |
| Fungsi Split Topics API | Memberikan kontrol lebih besar atas tiga aspek API yang berbeda | Kami memahami kasus penggunaan dan telah mengusulkan cara yang memungkinkan untuk mengatasinya dalam GitHub. Kami saat ini sedang menunggu masukan lebih lanjut dari ekosistem terkait apakah akan mem-build fungsi atau tidak. Lihat diskusi yang sedang berlangsung di sini. |
| Dokumentasi dan linimasa pengklasifikasi | Developer telah meminta informasi lebih lanjut tentang pengklasifikasi. | Kami telah memberikan informasi lebih lanjut tentang pengklasifikasi di sini secara publik.
Juga di sini Dan di sini. |
| Kontrol dan keamanan pengguna | Topik tertentu mungkin merupakan proxy untuk grup sensitif dan pengguna memerlukan kontrol lebih besar untuk mencegah hasil negatif. | Topik mewakili langkah maju yang signifikan untuk kontrol dan transparansi pengguna. Pengguna dapat memilih untuk tidak mengikuti topik, meninjau topik yang telah ditetapkan untuk mereka, menghapus topik, dan memahami perusahaan mana yang berinteraksi dengan topik mereka di halaman tertentu. Selain itu, pengguna juga dapat memengaruhi Topics mereka dengan menghapus histori penjelajahan mereka. Kami menyambut baik diskusi berkelanjutan mengenai kontrol pengguna yang lebih canggih, seperti yang disarankan oleh developer; namun, kami perlu memastikan bahwa untuk masalah yang diangkat dalam bug ini, hal itu benar-benar menghilangkan risiko (misalnya, menghapus hanya 'studi bahasa asing' Topik, tetapi bukan situs yang menghasilkan Topik dari Histori Penjelajahan tidak sepenuhnya melindungi pengguna). |
| Penggunaan topik di situs dengan prebid.js | Dapatkah Topics API digunakan di situs dengan prebid.js? | Jawaban singkatnya adalah ya. Informasi selengkapnya telah dipublikasikan di sini. |
| Penggunaan Topics API di widget rekomendasi | Dapatkah kita menggunakan Topics API di widget yang Direkomendasikan (misalnya Outbrain) | Kami tidak membatasi kasus penggunaan Topics yang diambil setelah API dipanggil (hal itu akan bergantung pada setiap kebijakan data developer). |
| Privasi / Kebijakan | Pertanyaan seputar tujuan pemfilteran respons menurut penelepon jika beberapa pihak ketiga akan membagikan topik mereka kepada siapa pun yang menelepon. | Berdasarkan masukan dari banyak orang dalam ekosistem, Chrome memilih desain ini untuk membatasi akses ke informasi bagi mereka yang tidak memiliki akses ke informasi tersebut. Tentu saja, penayang dan pihak ketiga yang menerima Topics dapat memutuskan sendiri informasi apa yang akan dibagikan dengan pihak di situs mereka. Jika mereka melakukan jenis berbagi ini, Chrome sangat mendorong mereka untuk bersikap transparan kepada pengguna terkait fitur berbagi tersebut, dan menawarkan kontrol kepada mereka. |
| Sinyal berisik | Mengirimkan topik acak dengan frekuensi 5% dari waktu tersebut dapat menghasilkan terlalu banyak derau / sinyal palsu. | Derau adalah metode penting untuk melindungi privasi pengguna, dan tingkat derau versus kegunaan topik akan dieksplorasi melalui pengujian. |
FLEDGE
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Koordinasi pengujian | Menguji dampak performa dan pendapatan | Performa FLEDGE, dan cara terbaik untuk mendukung pengujian ekosistem selama Uji Coba Origin serta Ketersediaan Umum, sedang dibahas secara aktif dalam rapat WICG publik. |
| Server Tepercaya untuk FLEDGE | Kapan Server Tepercaya akan tersedia untuk pengujian? | Kami menghargai masukan ini dan secara aktif berupaya membuat rencana yang lebih mendetail yang dapat kami bagikan untuk penggunaan server tepercaya di FLEDGE. |
| Standardisasi protokol | Apakah akan ada protokol umum untuk meneruskan data antara SSP dan DSP, seperti label umum untuk grup minat? | Kami menerima masukan dari DSP, SSP, dan ekosistem iklan yang lebih luas terkait potensi standardisasi spesifikasi. Untuk tujuan pengujian awal saat ini, sebaiknya Anda bekerja sama langsung dengan partner pengujian karena mereka sedang dalam proses bereksperimen dengan berbagai pendekatan. Kami juga mendorong, dan berencana untuk terus bekerja sama dengan, organisasi perdagangan iklan untuk ikut mempertimbangkan guna menciptakan standardisasi jika berguna bagi perusahaan anggotanya. |
| Pembatasan frekuensi | Kontrol frekuensi per pengguna dalam kampanye dan grup iklan. | FLEDGE juga akan mendukung pembatasan frekuensi untuk lelang di perangkat dan kampanye kontekstual / branding. Penyimpanan bersama dan batas khusus situs juga dapat digunakan untuk kontrol pembatasan frekuensi tambahan. |
| Dampak FLEDGE terhadap performa | Bidder yang menggunakan banyak komputasi di lelang FLEDGE | Chrome aktif berdiskusi dengan developer tentang potensi dampaknya terhadap performa situs. Chrome menyambut baik kesempatan untuk mempelajari lebih lanjut selama pengujian. |
| Menguji FLEDGE dengan fitur lain | Bagaimana laporan tingkat peristiwa dari Attribution Reporting API dan FLEDGE akan saling melengkapi? | Hal ini telah dibahas dalam panggilan WICG/conversion-measurement-api baru-baru ini, dengan link ke menit mendetail di sini.
Ringkasan rapat tersebut adalah bahwa desain saat ini untuk Pelaporan Iklan Frame Berpagar memungkinkan mengaitkan ID yang dibuat di dalam Frame dengan Fence dengan informasi kontekstual. Laporan tingkat peristiwa yang dihasilkan dalam Fenced Frame akan dapat digabungkan dengan informasi kontekstual yang sama di server (menggunakan 2 gabungan sisi server, bukan 1). |
| Penghitungan tayangan | Metodologi penghitungan Tayangan yang harus atau dapat digunakan antara pembeli dan penjual | FLEDGE API sudah mendukung keselarasan metodologi antara penjual dan pembeli selama lelang. Kami telah menerima saran tentang implementasi alternatif tanpa masukan mengapa desain kami saat ini tidak cocok untuk ekosistem. |
| Menampilkan Beberapa Iklan | Apakah seseorang dapat menampilkan beberapa iklan dalam satu lelang dalam Fenced Frame tertentu atau tidak | Saat ini hal tersebut dapat dilakukan melalui iklan komponen (berbeda dengan lelang komponen). Untuk melakukannya, semua iklan harus berada di grup minat yang sama. |
| Spesifikasi dan FLEDGE "Audiens yang Ditetapkan Penjual (SDA)" | Dapatkah FLEDGE menjadi mekanisme untuk mencegah pembeli membuat profil dari SDA terkait permintaan iklan? | FLEDGE dirancang untuk menghindari kebocoran informasi yang tidak relevan saat penayang sudah mengetahui SDA yang diikuti pengunjungnya dan penargetannya adalah situs yang sama. Jika mendukung pembelian di SDA dalam semua perlindungan yang disertakan dalam FLEDGE penting untuk dilakukan, salah satu solusi mungkin bagi penjual untuk meneruskan label SDA ke lelang di perangkat, dan teknologi iklan sisi beli untuk membuat Grup Minat mereka sendiri yang logika bidding-nya menyatakan "Saya ingin membeli Audiens X". |
| Dukungan untuk mata uang selain USD | Dukungan untuk menguji FLEDGE dengan mata uang di luar USD | Kami menghargai pengajuan ini dan telah menambahkan membangun untuk mendukung mata uang lain dalam backlog permintaan fitur kami. Kami harap fitur ini segera tersedia. |
| Dukungan untuk penargetan Grup Minat negatif | API untuk mendukung penargetan IG negatif: menampilkan iklan hanya jika pengguna bukan merupakan anggota IG. | Diskusi yang berkelanjutan, termasuk beberapa opsi yang diusulkan untuk didukung, dalam masalah github. |
| Beberapa SSP di FLEDGE | Risiko lebih memilih Google saat menerapkan lelang multilevel di FLEDGE | Dukungan untuk beberapa SSP di FLEDGE ditambahkan untuk menghadirkan ruang bermain yang adil dan setara. Berdasarkan Komitmen, Google telah berjanji untuk tidak mendesain, mengembangkan, atau menerapkan proposal Privacy Sandbox dengan cara yang akan mendistorsi persaingan dengan memprioritaskan produk dan layanan iklannya sendiri. Google menganggap hal ini serius dan sangat terbuka untuk mendiskusikan kekhawatiran apa pun yang mungkin dimiliki pemangku kepentingan tentang aspek spesifik teknologi tersebut. Sebagai informasi, Chrome telah mendokumentasikan mekanisme lelang komponen secara publik di sini. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Atribusi multi-sentuh | Penayang yang meminta dukungan untuk atribusi multi-sentuh | Metode atribusi multi-sentuh saat ini memerlukan penggabungan tayangan pengguna (dan juga identitas) secara deterministik di berbagai situs. Akibatnya, fungsi yang ada saat ini tidak selaras dengan sasaran Privacy Sandbox, yang bertujuan untuk mendukung kasus penggunaan iklan utama tanpa pelacakan lintas situs. Dalam beberapa kasus, perkiraan penetapan kredit (mis., dengan menggunakan prioritas acak berbobot) dapat dilakukan tanpa melacak pengguna individual. |
| Pembuatan derau | Pertanyaan mengenai tingkat derau dalam laporan | Eksperimen awal kami memungkinkan developer menetapkan nilai epsilon mereka sendiri sehingga mereka dapat mengalami bagaimana laporan berubah berdasarkan tingkat derau. Untuk saat ini, developer dapat memilih nilai epsilon hingga epsilon=64. Kami melakukan hal ini secara khusus untuk memudahkan developer menguji API dan memberi kami masukan tentang nilai epsilon yang sesuai.
Kami juga telah mengajukan permintaan publik untuk memberikan masukan tersebut. |
| Koordinasi pengujian | Apakah alat pengujian lokal dapat digunakan untuk OT? | Ya, alat pengujian lokal dapat digunakan selama durasi OT. Alat pengujian lokal dapat digunakan dengan laporan debug selama cookie pihak ketiga tersedia. |
| Ergonomi Kueri | Aktifkan kueri gabungan kunci | Kami setuju bahwa hal ini tampaknya meningkatkan ergonomi API dengan sedikit atau tanpa biaya privasi yang jelas. Kami akan membuat proposal dan melihat apakah ada konsensus luas bahwa proposal tersebut layak didukung. |
| Data yang kurang akurat untuk situs kecil | Situs atau kampanye yang lebih kecil mungkin menerima data yang kurang akurat. | Chrome menyadari bahwa perlindungan privasi berbasis derau memiliki dampak yang lebih besar pada bagian data yang lebih kecil. Namun, mungkin saja metode seperti agregasi data dalam jangka waktu yang lebih lama akan menyelesaikan masalah ini. Namun, tidak jelas apakah kesimpulan yang didasarkan pada potongan data yang sangat kecil (seperti satu atau dua pembelian) bermanfaat bagi pengiklan. Selama uji coba origin, Chrome mendorong penguji untuk memanfaatkan kemampuan bereksperimen dengan berbagai parameter privasi dan derau sehingga mereka dapat memberikan masukan yang lebih spesifik tentang masalah ini. |
Batasi Pelacakan Terselubung
Pengurangan Agen Pengguna
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Perlindungan bot | Dampak UA-R terhadap perlindungan bot | Kami menghargai masukan ini dan sedang dalam proses mengumpulkan informasi terkait pendekatan perlindungan bot untuk menginformasikan desain kami di masa mendatang. |
| Dependensi Deployment | Mengatasi dependensi deployment Agen Pengguna Terstruktur (SUA) | Kami telah meluncurkan "Fase 4", atau pengurangan versi minor untuk 100% pengguna Chrome pada versi 101 dan yang lebih baru. Lihat pembaruan di sini. |
Petunjuk Klien Agen Pengguna
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Menghitung semua petunjuk yang didukung | Tertarik memiliki cara terprogram untuk mengetahui semua petunjuk yang didukung untuk browser. | Kami menghargai masukan ini dan sedang dalam proses mengevaluasi permintaan fitur tersebut. Kami ingin mengetahui apakah ini adalah kasus penggunaan umum. |
| Fleksibilitas header UA-CH vs. Agen Pengguna | UA-CH terlalu preskriptif jika dibandingkan dengan fleksibilitas yang ditawarkan header Agen Pengguna, seperti yang ditetapkan oleh rfc7231. | Chrome melihat sifat preskriptif header UA-CH sebagai peningkatan penting atas fleksibilitas string UA, baik dari sudut pandang interoperabilitas lintas browser dan perlindungan privasi pengguna (dengan mencegah penambahan arbitrer ID entropi tinggi).
Masalah ini tetap terbuka jika orang lain juga memiliki kekhawatiran yang sama dan ingin memberikan masukan. |
| UA-CH: Masalah Anti-Penipuan / Anti-Penyalahgunaan | Fitur tertentu yang mungkin hilang melalui UA-CH: Pelacak pengalihan klik dan klik palsu. | Tim sedang menyelidiki potensi masalah ini dengan pemangku kepentingan pengukuran dan antipenipuan. |
| Performa | Ada masalah tentang latensi untuk mendapatkan petunjuk melalui CH Penting (pada pemuatan halaman pertama). | Chrome sedang menyelidiki cara untuk meningkatkan performa. |
Penangkap Anggur (WIP)
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Masalah latensi | Menambahkan hop ekstra dapat memengaruhi latensi | Kami mempertimbangkan proxy dua hop dan mencari cara untuk menemukan keseimbangan yang tepat antara privasi pengguna dan latensi. Kami terbuka untuk menerima masukan dan ingin berdiskusi lebih lanjut di forum W3C. |
| Perlindungan terhadap penipuan dan bot | Dampak terhadap perlindungan terhadap penipuan dan bot, termasuk di negara-negara kurang berkembang | Keamanan adalah persyaratan utama saat kami mencari cara untuk meningkatkan privasi pengguna dengan cara-cara yang bermakna, seperti menggunakan proxy alamat IP. Proxy dua hop yang berpartner dengan perusahaan terkemuka memberikan privasi pengguna yang dapat diverifikasi. Kami juga mengumpulkan ide-ide untuk sinyal baru guna membantu menyampaikan kepercayaan pengguna. |
| Kepatuhan terhadap hukum privasi setempat | Pelaporan data geografis tingkat negara mempersulit kepatuhan terhadap sistem lokal yang lebih terperinci | Kami telah memposting prinsip yang diusulkan kepada publik, yang mencakup pendekatan potensial yang akan memungkinkan situs tetap mematuhi persyaratan lokal. |
Memperkuat batas privasi lintas situs
Set Pihak Pertama
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Dampak FPS untuk penayang kecil vs. besar | Tujuan utama Privacy Sandbox adalah meningkatkan privasi pengguna dengan mengganti praktik saat ini dengan solusi yang tidak mengandalkan mekanisme pelacakan lintas situs. Kami ingin solusi ini berguna seluas mungkin untuk berbagai jenis dan ukuran pemangku kepentingan. Kami menyambut baik masukan spesifik yang dapat ditindaklanjuti terkait cara meningkatkan kualitas solusi ini, dan kami berharap solusi tersebut akan terus berkembang seiring dengan diskusi dan pengujian komunitas. |
| Meningkatkan privasi | Terlalu banyak situs dalam kumpulan yang sama dapat menimbulkan hasil serupa dengan cookie pihak ketiga | Kami menghargai masukan ini dan sedang mengevaluasi apakah batas yang tepat sudah tercapai atau belum, sekaligus mencoba memberikan perlakuan atau sinyal kepada pengguna dan developer sehingga mereka dapat memahami saat batas tersebut tercapai. Kami belum memiliki proposal spesifik yang akan dibagikan, tetapi kami berharap dapat segera melakukannya. |
| Dukungan ekosistem FPS | Pengumpulan dukungan dan kekhawatiran untuk terus mengembangkan FPS di luar Privacy CG | Meskipun kami lebih memilih proposal Set Pihak Pertama tetap berada dalam PrivacyCG, kami berharap dapat terus mengupayakan proposal tersebut di WICG. Kami juga terdorong oleh banyaknya pernyataan dukungan untuk diskusi berkelanjutan tentang Set Pihak Pertama dan kasus penggunaan yang ingin ditangani. Google tetap berkomitmen untuk menemukan solusi yang memungkinkan web terus tumbuh dan berkembang dengan cara yang melindungi dan menghormati privasi pengguna. |
| Interoperabilitas browser | Implementasi oleh browser lain | Kami menyadari pentingnya interoperabilitas browser bagi pengembang dan akan terus berkolaborasi dengan browser lain untuk mengejar standardisasi FPS. |
| Persyaratan kebijakan privasi umum | Anda tidak dapat menjaga kebijakan privasi yang sama di semua produk dan wilayah hukum yang perlu menjadi bagian dari kumpulan yang sama. | Chrome masih menentukan persyaratan kebijakan kami; dan akan memperhatikan masukan ini. |
API Fenced Frames
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Permintaan dokumentasi | Perbedaan dengan iframe sandbox | Kami menghargai masukan dan saran Anda. Saat ini terdapat diskusi tentang hal ini di GitHub, di mana kami berharap mendapatkan kejelasan akhir tentang permintaan agar dapat mengevaluasinya sepenuhnya. Diskusi publik tersedia di sini. |
| Kemampuan Lintas API | Dukungan default untuk Attribution Reporting dalam Fenced Frames | Kami meminta masukan terkait proposal untuk mengizinkan Attribution Reporting API dalam "mode iklan buram" untuk frame dengan fence secara default. Kami mendorong pengembang yang menganggap hal ini bermanfaat untuk ikut serta dalam diskusi. |
API Penyimpanan Bersama
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Batas data | Apakah akan ada batasan jumlah data yang dapat disimpan per partisi? | Ya, akan ada batasan. Lihat masalah github untuk detail selengkapnya. Kita memerlukan kuota penyimpanan. Proposal kami saat ini adalah memiliki batas ukuran per entri sebesar 4 KB, baik kunci maupun nilai akan dibatasi hingga 1024 char16_t karakter masing-masing, dan batas entri per origin sebanyak 10.000 entri dengan mekanisme yang mencegah entri tambahan dilakukan saat kapasitas origin penuh. Kami secara aktif mencari masukan terkait batasan spesifik yang diusulkan di sini. |
| Transparansi pengguna | Transparansi pengguna untuk sumber data versus penggunaan data | Kami menghargai masukan ini, dan menurut kami ini adalah pendekatan yang menjanjikan yang patut dipelajari. Secara khusus, kami mengevaluasi apakah hal ini mungkin dilakukan dengan cara yang menawarkan transparansi yang memadai kepada pengguna. |
CHIP
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Hambatan adopsi | Haruskah CHIPS terikat dengan nama host? (persyaratan no-Domain) | Kami menghapus persyaratan ini dari OT berdasarkan masukan dari peserta OT bahwa persyaratan ini menambah kerumitan dan berfungsi sebagai penghambat adopsi CHIPS.
Kami akan membahas persyaratan ini di Grup Komunitas Privasi sebagai bagian dari inkubasi standar di sini. |
| Kasus penggunaan iklan untuk CHIPS | Dapatkah CHIPS digunakan untuk kasus penggunaan Google Ads di satu situs? | Pelacakan pengguna dalam satu situs adalah kasus penggunaan yang diizinkan. Kami telah memperbarui artikel developer untuk menyoroti kasus penggunaan ini. |
| Sematan terautentikasi | Apakah status login dipertahankan dengan CHIPS? | Status login saat ini tidak dipertahankan, tetapi bukan kasus penggunaan yang dimaksudkan untuk CHIPS. Kami mengetahui kasus penggunaan sematan terautentikasi dan sedang berupaya untuk mencari solusi. |
| Koordinasi pengujian | Apakah ada tindakan pengguna tambahan yang diperlukan untuk menguji partisi? | Selama token OT valid dan ada di header halaman yang dikunjungi, fitur tersebut harus tersedia bagi pengguna, tanpa memerlukan tindakan pengguna tambahan |
| Kompatibilitas browser | Minat dalam memahami cara browser lain menangani atribut cookie yang dipartisi. | Chrome terus bekerja dalam grup standar publik seperti W3C untuk mengidentifikasi desain dan implementasi yang dapat berfungsi di seluruh browser. |
FedCM
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Potensi vektor serangan | Potensi vektor serangan melalui dekorasi link dan serangan pengaturan waktu | Kami secara aktif mengumpulkan masukan publik dan menyelidiki kemungkinan cara untuk mengatasi masalah ini. |
| UX yang memungkinkan beberapa IDP | Hanya satu IDP yang dapat ditampilkan dalam satu waktu | Kami meyakini dukungan terhadap banyak IDP, dan secara aktif berupaya melakukan pendekatan untuk memberikan dukungan |
| Eksprestivitas | Perlu diperhatikan bahwa karena browser merender bagian dari alur identitas gabungan, sulit untuk menangkap semua nuansa yang ingin ditampilkan oleh IDP kepada pengguna mereka. | Chrome melakukan eksplorasi dalam menyertakan penyesuaian branding (mis. logo, warna) dan penyesuaian string (mis., "akses artikel ini", bukan "login dengan").
Chrome menyadari konsekuensinya dan akan terus bekerja sama dengan ekosistem untuk mencakup sebanyak mungkin aspek yang dapat dilakukan dan membuatnya seekspresi mungkin. |
| Penerapan dan Interoperabilitas | Kekhawatiran bahwa browser lain tidak akan mengadopsi atau menerapkan FedCM. | Chrome juga bekerja sama dengan vendor browser lainnya untuk menemukan solusi umum federasi di FedID Community Group. |
| Saran untuk menghapus persyaratan data pribadi dalam alur pendaftaran | (1) UX yang menunjukkan kepada pengguna IdP mana yang mereka pilih, tanpa memberikan sinyal bahwa email, gambar, dan nama mereka akan lebih mengutamakan privasi
(2) Pengalaman pengguna dan pemilihan klaim dari IdP biasanya jarang dilakukan |
Kami setuju dan sedang mempelajari cara menerapkan masukan dengan cara yang lebih mengutamakan pengguna, privasi, dan ramah. |
| Interaksi pengguna dengan IdP | Perlu interaksi langsung antara pengguna dan IdP jika batas risiko terlampaui | Kami menyelidiki masukan ini secara aktif. |
Partisi Status Jaringan
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Performa | Mempartisi status jaringan dapat menyebabkan peningkatan koneksi intensif resource ke CDN | Kami masih menyelidiki karakteristik kinerja Partisi Status Jaringan, termasuk mengukur kemungkinan skema keying yang berbeda. Kami belum membuat keputusan antara keseimbangan performa, keamanan, dan privasi, serta perlu mengumpulkan lebih banyak data. |
Memerangi spam dan penipuan
API Trust Tokens
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Masukan peraturan | Kekhawatiran terkait menginvestasikan waktu dan resource pada Trust Token tanpa sinyal yang jelas dari badan pengatur tentang kelayakan jangka panjang | Tujuan kami adalah membangun teknologi yang sesuai untuk ekosistem periklanan, dengan mendapatkan masukan dari industri dan badan pengatur yang penting bagi proses tersebut. Kami akan terus berkonsultasi dengan badan pengatur di seluruh dunia selama kami mengembangkan Privacy Sandbox dan menyediakan proposal kepada developer, termasuk Trust Token. Seperti teknologi baru lainnya, perusahaan harus membuat keputusan berdasarkan penilaian mereka sendiri terhadap persyaratan peraturan. |
| Waktu peluncuran | Kapan Trust Token akan diluncurkan ke GA? | Kami memberikan perkiraan terkini untuk pengiriman pada linimasa publik kami di privacysandbox.com. Segera setelah kami membuat keputusan akhir mengenai tanggal pengirimannya ke GA, kami akan mempostingnya secara publik melalui proses rilis Chrome dan memperbarui linimasanya di situs. |
| Trust Token vs lainnya | Peran Trust Token terkait dengan token lain yang melalui standardisasi, seperti Token Akses Pribadi | Kami terlibat dalam diskusi standardisasi dan tujuan kami adalah untuk menyelaraskan dengan upaya lainnya sebanyak mungkin, sekaligus memungkinkan berbagai kasus penggunaan yang ditawarkan setiap teknologi. Misalnya, Trust Token dan Private Access Token keduanya bergantung pada protokol Privacy Pass. |
| Batas data | Maksimal 2 Penerbit untuk penukaran token per halaman yang berpotensi membatasi | Kami sedang mencari opsi jangka panjang yang memungkinkan perusahaan menukarkan token dengan aman tanpa membahayakan entropi pengguna lainnya, mungkin dengan mempartisi akses ke penukaran token. |
| Batasan akses | Hanya asal yang disetujui (dan perujuk terverifikasi/bukan perujuk) yang boleh memverifikasi keberadaan token dan menukarkan | Kami sedang mempelajari pendekatan terkait siapa yang dapat melihat dan menukarkan token. |
| Dukungan perangkat | Dependensi runtime JavaScript membatasi penggunaan pada perangkat tertentu. Dapatkah dukungan TT diperluas agar berfungsi di jenis perangkat lainnya? | Ini adalah sesuatu yang dapat kami pertimbangkan untuk pengembangan di masa mendatang dan topik yang kami ingin mendengar lebih banyak masukan dari para pengembang di forum W3C. Kami juga memiliki masalah terbuka terkait penukaran token yang dipicu Header HTTP yang kami minta masukannya. |
| Kasus penggunaan | Tidak jelas apa kasus penggunaan yang tepat untuk Trust Token. Kurangnya kejelasan tentang penggunaan yang dimaksudkan. | Tujuan kami adalah memfasilitasi inovasi dalam bidang antipenipuan, dan memahami bahwa setiap perusahaan dapat menggunakan teknik eksklusif dengan trust token. Itulah sebabnya kami tidak memiliki preskriptif terkait penggunaan yang dimaksudkan. Namun, kami mungkin akan memperluas dokumentasi kami untuk menyertakan lebih banyak contoh sebagai titik awal bagi partner yang mempertimbangkan eksperimen atau adopsi. |
| Cakupan Token Kepercayaan | Menghapus kebijakan fitur 'trust-token-redemption' ini akan meningkatkan cakupan token kepercayaan secara signifikan. | Hal ini menjadi pertimbangan saat kami mengumpulkan masukan dari OT dan membuat keputusan untuk langkah selanjutnya. |
| Kepercayaan penerbit | Mengapa kami harus memercayai situs yang mengeluarkan trust token? | Tidak ada pedoman untuk menjadi penerbit - siapa pun bisa melakukannya. Penerbit tersebut diharapkan hanya akan bekerja sama dengan penerbit yang mereka percayai. Selain itu, pelaku sah lainnya dalam ekosistem iklan pada akhirnya akan mendiskon (atau berhenti membeli) traffic yang terkait dengan penerbit yang mencurigakan atau tidak dikenal. |
| Layanan sematan pihak ketiga | Dapatkah layanan sematan pihak ketiga menukarkan dan/atau meminta trust token? | Ya, layanan sematan pihak ketiga dapat menerbitkan dan menukarkan Trust Token. |
| Ekosistem penerbit | Utilitas yang lebih besar dapat dicapai jika sinyal kepercayaan dapat dibagikan kepada perusahaan lain | Trust Token dirancang untuk menjadi primitif tingkat rendah, dan dapat digunakan oleh penerbit/penukaran yang bekerja sama untuk berbagi sinyal kepercayaan/reputasi. |
| Overhead pemeliharaan | Penerapan kriptografi yang mendasari operasi Trust Token berada di BoringSSL; yang satu-satunya pengelola dari Google. Bagaimana pemeliharaan perpustakaan akan dikelola? | Trust Token mengandalkan operasi kriptografi standar (lihat protokol Privacy Pass) yang juga dapat diterapkan di library lain. Sebaiknya developer meminta/mengembangkan/mempertahankan dukungan untuk operasi ini di library pilihan mereka. |
| Overhead pemeliharaan | Tidak jelas berapa lama versi protokol akan didukung | Kami sedang mempertimbangkan pengembangan dan dokumentasi yang lebih spesifik tentang jangka waktu dukungan yang diharapkan untuk versi protokol. |
| Batas Penerbit | Jika Anda jauh dari rantai, peluang Anda untuk mengeksekusi Trust Token mungkin tidak muncul | Dengan semakin banyaknya organisasi yang mulai menggunakan trust token, kami semakin dapat melihat jenis dinamika waktu ini, dan sedang menyelidiki solusi potensial. Seperti yang dijelaskan sebelumnya, kami mencari opsi jangka panjang yang memungkinkan perusahaan menukarkan token dengan aman tanpa risiko entropi pengguna yang lebih banyak, yang akan meminimalkan pentingnya lokasi di halaman atau urutan pemuatan. |
Solusi Anti-Penipuan Baru dalam Inkubasi
| Tema Masukan
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Kekhawatiran | Respons Chrome |
| Sinyal Pengesahan Integritas Perangkat | Umumnya dukungan kuat untuk mengejar sinyal integritas perangkat yang dibuktikan oleh platform dan tersedia untuk web | Kami akan terus mengumpulkan masukan dan mengajukan proposal melalui desain dan iterasi publik. |
| Sinyal Pengesahan Integritas Perangkat | Pertanyaan tentang seberapa banyak entropi pengguna yang dapat disampaikan melalui sinyal baru, dan apakah kasus penggunaan tertentu (seperti pengguna yang login ke bank mereka) dapat membenarkan sinyal entropi yang lebih tinggi. | Kami cenderung menyediakan sinyal bernilai tinggi dengan entropi pengguna sesedikit mungkin untuk menjaga privasi pengguna. |
| Sinyal Pengesahan Integritas Perangkat | Apakah sinyal ini akan membatasi akses untuk perangkat lama atau platform open source/yang diubah? | Setiap sinyal baru harus mempertimbangkan akses universal sebagai prinsip utama dalam pengembangan, dan ini merupakan pertanyaan penting yang harus dijawab di awal saat kami melanjutkan inkubasi. |
| Sinyal Pengesahan Integritas Perangkat | Ada beberapa kekhawatiran jika sinyal baru menyebabkan perusahaan keamanan dan antipenipuan terlalu mengandalkan browser dan platform
|
Setiap sinyal baru harus dipandang sebagai data tambahan dan bukan indikasi "kepercayaan" dari browser. Kami sepenuhnya berharap perusahaan keamanan dapat terus mengandalkan data, model, dan mesin pembuat keputusan milik mereka sendiri dengan pengesahan perangkat sebagai input tambahan. Diharapkan, setiap sinyal baru akan meningkatkan upaya deteksi di seluruh ekosistem dan membuat penipuan lebih sulit dijalankan. |
| Sinyal Usia Cookie | Konsep yang menarik, tetapi kemungkinan memerlukan penyelidikan lebih lanjut dalam kasus penggunaan yang berlaku. | Bergantung pada tingkat minat, Chrome dapat melakukan pemunculan ide lebih lanjut tentang konsep ini, dan menjadikannya penjelasan untuk masukan ekosistem di masa mendatang. |
| Server Tepercaya untuk Antipenipuan | Konsep yang menarik, tetapi kemungkinan memerlukan penyelidikan lebih lanjut dalam kasus penggunaan yang berlaku. | Bergantung pada tingkat minat, Chrome dapat melakukan pemunculan ide lebih lanjut tentang konsep ini, dan menjadikannya penjelasan untuk masukan ekosistem di masa mendatang. |