Laporan kuartalan untuk K2 2022 yang 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) dari Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang tersedia di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menerima masukan yang diperoleh dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.
Tema masukan diberi peringkat berdasarkan prevalensi per API. Hal ini dilakukan dengan mengambil agregasi jumlah masukan yang telah diterima tim Chrome terkait tema tertentu dan mengaturnya dalam urutan menurun berdasarkan jumlah. 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, risalah rapat untuk rapat badan standar web telah ditinjau dan, untuk masukan langsung, catatan Google tentang rapat pemangku kepentingan 1:1, email yang diterima oleh setiap engineer, milis API, dan formulir masukan publik dipertimbangkan. Google kemudian berkoordinasi antara tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi tema yang muncul secara relatif sehubungan dengan setiap API.
Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat untuk masalah yang diajukan oleh pemangku kepentingan, dan menentukan posisi secara khusus untuk tujuan latihan pelaporan publik ini. Mencerminkan fokus pengembangan dan pengujian saat ini, pertanyaan dan masukan diterima, terutama sehubungan dengan Topics, Fledge, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum mendapatkan respons Chrome yang dipertimbangkan.
Glosarium akronim
- CHIP
- Cookie yang Memiliki Status Partisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Federated Credential Management
- FPS
- Set Pihak Pertama
- IAB
- Interactive Advertising Bureau
- IDP
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Internet Protocol
- openRTB
- Bidding real-time
- OT
- Uji Coba Origin
- PatCG
- Grup Komunitas Teknologi Iklan Pribadi
- RP
- Relying Party/Pihak yang Mengandalkan
- SSP
- Platform Sisi Pasokan
- TEE
- Trusted Execution Environment
- UA
- String Agen Pengguna
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Willful IP Blindness
Masukan umum, tidak ada API/Teknologi tertentu
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Linimasa yang lebih jelas | Jadwal rilis yang lebih jelas dan mendetail untuk teknologi Privacy Sandbox. | Kami menetapkan rencana saat ini untuk jadwal deployment di privacysandbox.com, dan memperbaruinya setiap bulan. Hal ini mempertimbangkan waktu pengembangan untuk 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 melalui beberapa langkah dari pengujian hingga rilis (peluncuran) dan waktu setiap langkah ditentukan oleh hal-hal yang kita pelajari dan temukan di langkah sebelumnya. Meskipun saat ini kami belum berkomitmen untuk merilisnya, kami akan memperbarui linimasa publik kami di privacysandbox.com jika sudah siap. |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Kekhawatiran bahwa teknologi Privacy Sandbox lebih mendukung developer yang lebih besar dan situs khusus (lebih kecil) berkontribusi lebih banyak daripada situs umum (lebih besar). | Kami memahami bahwa beberapa developer memiliki kekhawatiran tentang dampak teknologi Privacy Sandbox. Google telah berkomitmen kepada CMA untuk tidak mendesain atau menerapkan proposal Privacy Sandbox dengan cara yang mendistorsi persaingan dengan memberikan preferensi sendiri pada bisnis Google, dan untuk mempertimbangkan dampak pada persaingan dalam periklanan digital serta pada penayang dan pengiklan, serta dampak pada hasil privasi dan pengalaman pengguna. Kami terus bekerja sama dengan CMA untuk memastikan bahwa pekerjaan kami mematuhi komitmen ini.
Seiring pengujian Privacy Sandbox berlangsung, salah satu pertanyaan utama yang akan kami kaji adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan yang spesifik dan dapat ditindaklanjuti yang dapat membantu kami meningkatkan desain teknis lebih lanjut. |
| Linimasa penghentian penggunaan cookie pihak ketiga | Permintaan untuk menghindari penundaan lebih lanjut terkait penghentian cookie pihak ketiga | Kami telah mendengar dari beberapa pemangku kepentingan yang ingin Chrome melanjutkan penghentian penggunaan cookie pihak ketiga tanpa penundaan, dan kami telah mendengar dari pemangku kepentingan lainnya yang yakin bahwa lebih banyak waktu diperlukan untuk menguji dan mengadopsi teknologi Privacy Sandbox. Kami berkomitmen untuk melanjutkannya secara bertanggung jawab mengingat kompleksitas teknologi dan pentingnya ekosistem untuk melakukan hal yang benar. Masukan dari industri dan dari regulator sangat penting bagi proses ini. |
| Linimasa penghentian penggunaan cookie pihak ketiga | Permintaan untuk menunda penghentian penggunaan cookie pihak ketiga, dan untuk memberikan lebih banyak waktu guna menguji API. | Kami telah mendengar dari beberapa pemangku kepentingan yang ingin Chrome melanjutkan penghentian penggunaan cookie pihak ketiga tanpa penundaan, dan kami telah mendengar dari pemangku kepentingan lainnya yang yakin bahwa lebih banyak waktu diperlukan untuk menguji dan mengadopsi teknologi Privacy Sandbox. Kami berkomitmen untuk melanjutkannya secara bertanggung jawab mengingat kompleksitas teknologi dan pentingnya ekosistem untuk melakukan hal yang benar. Masukan dari industri dan dari regulator sangat penting bagi proses ini. |
| Permintaan dokumentasi | Meminta referensi lainnya yang menjelaskan cara mengelola pengujian, analisis, dan penerapan. | Kami berterima kasih karena developer merasa materi kami saat ini bermanfaat, dan kami berkomitmen untuk menyediakan lebih banyak materi, termasuk jam buka developer dan dokumentasi teknis, dalam beberapa minggu dan bulan mendatang agar developer dapat terus memahami cara kerja teknologi baru ini.
Kami juga telah mengadakan sesi Jam Buka developer eksternal publik untuk membagikan praktik terbaik dan demo serta sesi Tanya Jawab dengan pimpinan Produk dan Engineering untuk memungkinkan diskusi/pertanyaan secara live. |
| Keahlian industri | Tim Chrome yang berinteraksi 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 yang bekerja di ekosistem iklan mencapai ratusan. |
Menampilkan Konten & Iklan yang Relevan
Topik
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Kekhawatiran telah muncul terkait nilai yang dihasilkan dan distribusi nilai tersebut untuk situs, bergantung pada tingkat traffic atau seberapa khusus kontennya. | Kegunaan API akan dieksplorasi melalui pengujian. Chrome mengharapkan taksonomi dan parameter lainnya berkembang berdasarkan hasil pengujian. Evolusi taksonomi atau parameter mungkin tidak memerlukan perubahan yang tidak kompatibel dengan versi sebelumnya. Selain itu, Chrome berharap masukan akan terus memengaruhi evolusi Topics API setelah penghentian cookie pihak ketiga. |
| Taksonomi | Pemangku kepentingan industri ingin memiliki suara dalam memengaruhi taksonomi. | Chrome tetap terbuka untuk menerima masukan tentang taksonomi. Chrome sangat tertarik dengan masukan tentang model tata kelola untuk mengubah taksonomi, dan diskusi tentang bagaimana lembaga industri lainnya dapat berperan lebih aktif dalam mengembangkan dan mempertahankan taksonomi dalam jangka panjang. |
| Histori penjelajahan tidak cukup | Proposal untuk menampilkan topik yang telah dilihat pemanggil pada minggu sebelumnya jika pengguna tidak memiliki cukup histori penjelajahan untuk membuat 5 topik untuk minggu terbaru | Untuk desain saat ini, warna 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 penayang? | Ya, itulah cara kami mengharapkan Topics digunakan. |
| Potensi vektor serangan | Mengidentifikasi topik yang berisik | Berdasarkan masukan dari banyak orang dalam ekosistem, Chrome memilih untuk memfilter topik dan memasukkan derau. Keputusan ini dibuat dengan mempertimbangkan privasi - untuk membatasi akses ke informasi bagi pihak yang tidak akan memiliki akses ke informasi tersebut dan memperkenalkan penyangkalan yang masuk akal bagi pengguna. Kami menyadari bahwa keputusan tersebut memiliki kekurangan, seperti vektor serangan yang diuraikan 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 untuk pengguna, karena setelan browser atau faktor lainnya, meskipun mereka mengunjungi halaman web yang menyediakan token uji coba yang valid dan browser mereka disertakan dalam grup yang mengaktifkan uji coba.
Oleh karena itu, 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 mengajukan masukan untuk pendekatan guna menghindari iframe x-origin yang mahal dan lambat serta untuk proposal guna memisahkan Topics API sehingga mendapatkan topik tidak mengubah status penjelajahan. |
| Memisahkan fungsi Topics API | Memberikan kontrol lebih besar atas tiga aspek API yang berbeda | Kami memahami kasus penggunaannya dan telah mengusulkan kemungkinan cara untuk mengatasinya dalam GitHub. Saat ini kami sedang menunggu masukan lebih lanjut dari ekosistem terkait apakah akan mem-build fungsi tersebut. Lihat diskusi yang sedang berlangsung di sini. |
| Linimasa dan dokumentasi pengklasifikasi | Developer telah meminta informasi selengkapnya tentang pengklasifikasi. | Kami telah memberikan informasi selengkapnya tentang pengklasifikasi secara publik di sini.
Serta di sini Dan di sini. |
| Kontrol dan keamanan pengguna | Topik tertentu mungkin merupakan proxy untuk kelompok sensitif dan pengguna memerlukan lebih banyak kontrol untuk mencegah hasil negatif. | Topik merupakan langkah maju yang signifikan untuk transparansi dan kontrol pengguna. Pengguna akan dapat memilih tidak ikut 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 Topik mereka dengan menghapus histori penjelajahan. Kami menyambut baik diskusi berkelanjutan terkait kontrol pengguna yang lebih canggih, seperti yang disarankan oleh developer; namun, kami perlu memastikan bahwa untuk masalah yang diangkat dalam bug ini, tindakan tersebut benar-benar menghilangkan risiko (misalnya, menghapus hanya Topik 'studi bahasa asing', tetapi tidak menghapus 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 kami menggunakan Topics API di widget Rekomendasi (misalnya, Outbrain) | Kami tidak membatasi kasus penggunaan Topik yang diambil setelah API dipanggil (yang akan bergantung pada kebijakan data setiap developer). |
| Privasi / Kebijakan | Pertanyaan seputar tujuan pemfilteran respons oleh pemanggil jika beberapa pihak ketiga akan membagikan topik mereka kepada siapa pun yang menelepon. | Berdasarkan masukan dari banyak pihak dalam ekosistem, Chrome memilih desain ini untuk membatasi akses ke informasi bagi pihak yang tidak akan memiliki akses ke informasi tersebut. Tentu saja, penayang dan pihak ketiga yang menerima Topics dapat memutuskan sendiri informasi apa yang akan mereka bagikan kepada pihak lain di situs mereka. Jika mereka melakukan jenis berbagi ini, Chrome sangat menyarankan mereka untuk bersikap transparan kepada pengguna mereka tentang berbagi tersebut, dan menawarkan kontrol kepada mereka. |
| Sinyal berisik | Mengirimkan topik acak 5% dari waktu mungkin akan 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
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Menguji koordinasi | Menguji dampak performa dan pendapatan | Performa FLEDGE, dan cara terbaik kami 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 sedang berupaya untuk 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 standarisasi 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 turut memberikan masukan guna menciptakan standarisasi jika hal tersebut berguna bagi perusahaan anggota mereka. |
| Pembatasan frekuensi | Kontrol frekuensi per pengguna dalam kampanye & 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 intensif secara komputasi di lelang FLEDGE | Chrome sedang berdiskusi secara aktif dengan developer tentang potensi dampaknya terhadap performa situs. Chrome menyambut kesempatan untuk mempelajari lebih lanjut selama pengujian. |
| Menguji FLEDGE dengan fitur lainnya | Bagaimana cara kerja laporan tingkat peristiwa dari Attribution Reporting API dan FLEDGE? | Hal ini telah dibahas dalam panggilan WICG/conversion-measurement-api terbaru, dengan link ke notulen mendetail di sini.
Ringkasan rapat adalah bahwa desain saat ini untuk Pelaporan Iklan Bingkai Pagar memungkinkan Anda mengaitkan ID yang dibuat di dalam Bingkai Pagar dengan informasi kontekstual. Oleh karena itu, laporan tingkat peristiwa yang dihasilkan di dalam Frame Berpagar akan dapat digabungkan dengan informasi kontekstual yang sama di server (menggunakan 2 join sisi server, bukan 1). |
| Penghitungan tayangan | Metodologi penghitungan Tayangan iklan yang harus atau dapat digunakan antara pembeli dan penjual | FLEDGE API sudah mendukung penyelarasan metodologi antara penjual dan pembeli selama lelang. Kami telah menerima saran tentang implementasi alternatif tanpa masukan tentang alasan desain kami saat ini tidak dapat berfungsi untuk ekosistem. |
| Menampilkan Beberapa Iklan | Apakah satu iklan dapat menampilkan beberapa iklan dalam satu lelang di Frame Berpagar tertentu | Hal ini saat ini dapat dilakukan melalui iklan komponen (jangan dikelirukan dengan lelang komponen). Untuk melakukannya, semua iklan harus berada dalam grup minat yang sama. |
| Spesifikasi "Audiens yang Ditentukan Penjual (SDA)" dan FLEDGE | Dapatkah FLEDGE menjadi mekanisme untuk mencegah pembeli membuat profil dari SDA pada permintaan iklan? | FLEDGE dirancang untuk menghindari kebocoran informasi yang tidak relevan jika penayang sudah mengetahui SDA yang dikunjungi pengunjungnya dan penargetan adalah situs yang sama. Jika penting untuk mendukung pembelian di SDA dalam semua perlindungan yang disertakan dalam FLEDGE, salah satu solusinya adalah penjual meneruskan label SDA ke lelang di perangkat, dan teknologi iklan sisi beli 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 selain USD | Kami menghargai pemberitahuan ini dan telah menambahkan dukungan untuk mata uang lain dalam daftar permintaan fitur yang tertunda. Kami berharap fitur ini segera tersedia. |
| Dukungan untuk penargetan Grup Minat negatif | API untuk mendukung penargetan IG negatif: menampilkan iklan hanya jika pengguna bukan anggota IG. | Diskusi yang sedang berlangsung, termasuk beberapa opsi yang diusulkan untuk didukung, di masalah github. |
| Beberapa SSP di FLEDGE | Risiko mendukung Google saat menerapkan lelang multi-level di FLEDGE | Dukungan untuk beberapa SSP di FLEDGE ditambahkan untuk memberikan persaingan 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 menanggapi hal ini dengan serius, dan sangat terbuka untuk membahas kekhawatiran yang mungkin dimiliki pemangku kepentingan tentang aspek tertentu dari teknologi ini. Untuk informasi, Chrome telah mendokumentasikan mekanisme lelang komponen secara publik di sini. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Atribusi multi-sentuh | Penayang yang meminta dukungan untuk atribusi multi-sentuh | Metode atribusi multi-sentuh saat ini memerlukan penggabungan tayangan pengguna (dan identitasnya) di berbagai situs secara deterministik. Akibatnya, fungsi ini dalam bentuknya 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 (misalnya, dengan menggunakan prioritas acak berbobot) dapat dilakukan tanpa melacak setiap pengguna. |
| Pembuatan derau | Pertanyaan terkait tingkat derau dalam laporan | Eksperimen awal kami memungkinkan developer menetapkan nilai epsilon mereka sendiri sehingga mereka dapat mengalami perubahan laporan berdasarkan tingkat derau. Mulai sekarang, developer dapat memilih nilai epsilon hingga epsilon=64. Kami telah melakukan hal ini secara khusus untuk memudahkan developer menguji API dan memberikan masukan kepada kami tentang nilai epsilon yang sesuai.
Kami juga telah membuat permintaan publik untuk masukan tersebut. |
| Menguji koordinasi | Dapatkah alat pengujian lokal digunakan untuk OT? | Ya, alat pengujian lokal dapat digunakan selama OT. Alat pengujian lokal dapat digunakan dengan laporan debug selama cookie pihak ketiga tersedia. |
| Ergonomi Kueri | Mengaktifkan kueri agregat 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 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 slice data yang lebih kecil. Namun, metode seperti agregasi selama jangka waktu yang lebih lama dapat menyelesaikan masalah ini; tidak jelas juga apakah kesimpulan berdasarkan potongan data yang sangat kecil (seperti satu atau dua pembelian) bermakna bagi pengiklan. Selama uji coba origin, Chrome mendorong penguji untuk memanfaatkan kemampuan untuk bereksperimen dengan berbagai parameter privasi dan derau sehingga mereka dapat memberikan masukan yang lebih spesifik tentang masalah ini. |
Membatasi Pelacakan Tersembunyi
Pengurangan Agen Pengguna
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Perlindungan terhadap bot | Dampak UA-R terhadap perlindungan terhadap bot | Kami menghargai masukan ini dan sedang dalam proses mengumpulkan informasi tentang pendekatan perlindungan terhadap bot untuk menginformasikan desain kami di masa mendatang. |
| Dependensi Deployment | Menangani dependensi deployment Agen Pengguna Terstruktur (SUA) | Kami telah meluncurkan "Fase 4", alias pengurangan versi minor, kepada 100% pengguna Chrome dalam versi 101 dan yang lebih baru. Lihat update di sini. |
Petunjuk Klien Agen Pengguna
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Mengurutkan semua petunjuk yang didukung | Minat untuk memiliki cara terprogram guna mengetahui semua petunjuk yang didukung untuk browser. | Kami menghargai masukan ini dan sedang dalam proses mengevaluasi permintaan fitur. Kami ingin memahami apakah ini adalah kasus penggunaan yang umum. |
| Fleksibilitas UA-CH vs. header User-Agent | UA-CH terlalu preskriptif jika dibandingkan dengan fleksibilitas yang ditawarkan header User-Agent, seperti yang ditentukan oleh rfc7231. | Chrome melihat sifat preskriptif header UA-CH sebagai peningkatan penting atas fleksibilitas string UA, baik dari sudut pandang interoperabilitas lintas browser pada akhirnya maupun perlindungan privasi pengguna (dengan mencegah penambahan ID entropi tinggi secara arbitrer).
Masalah ini tetap terbuka jika ada orang lain yang juga memiliki kekhawatiran ini dan ingin memberikan masukan. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | Fitur tertentu yang mungkin hilang melalui UA-CH: Pelacak pengalihan klik, dan klik yang menipu. | Tim sedang menyelidiki potensi masalah ini dengan pemangku kepentingan anti-penipuan dan pengukuran. |
| Performa | Ada masalah terkait latensi untuk mendapatkan petunjuk melalui Critical-CH (pada pemuatan halaman pertama). | Chrome sedang menyelidiki cara untuk meningkatkan performa. |
Gnatcatcher (WIP)
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Masalah latensi | Menambahkan hop tambahan dapat memengaruhi latensi | Kami mempertimbangkan proxy dua hop dan mempelajari cara 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 yang kurang berkembang | Keselamatan adalah persyaratan inti saat kami mencari cara untuk meningkatkan privasi pengguna dengan cara yang bermakna, seperti melakukan proxy alamat IP. Proxy dua hop yang berpartner dengan perusahaan tepercaya memberikan privasi pengguna yang dapat diverifikasi. Kami juga sedang mengembangkan ide untuk sinyal baru guna membantu menyampaikan kepercayaan pengguna. |
| Kepatuhan terhadap hukum privasi setempat | Pelaporan data geografis tingkat negara mempersulit kepatuhan terhadap rezim lokal yang lebih terperinci | Kami telah memposting prinsip yang kami usulkan secara publik, yang mencakup potensi pendekatan yang akan memungkinkan situs tetap mematuhi persyaratan setempat. |
Memperkuat batasan privasi lintas situs
Set Pihak Pertama
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Dampak FPS untuk penayang kecil vs. besar | Sasaran utama Privacy Sandbox adalah meningkatkan privasi pengguna dengan mengganti praktik saat ini dengan solusi yang tidak bergantung pada mekanisme pelacakan lintas situs. Kami ingin solusi ini bermanfaat seluas mungkin bagi berbagai jenis dan ukuran pemangku kepentingan. Kami menerima masukan spesifik yang bisa ditindaklanjuti tentang cara meningkatkan solusi ini, dan kami berharap solusi ini akan terus berkembang dengan diskusi dan pengujian komunitas. |
| Meningkatkan privasi | Terlalu banyak situs dalam kumpulan yang sama dapat menghasilkan hasil yang serupa dengan cookie pihak ketiga | Kami menghargai masukan ini dan sedang mengevaluasi apakah batas yang tepat atau tidak, sekaligus mencoba memberikan perlakuan atau sinyal kepada pengguna dan developer agar mereka dapat memahami kapan batas tersebut tercapai. Kami belum memiliki proposal spesifik untuk dibagikan, tetapi kami berharap dapat segera melakukannya. |
| Dukungan ekosistem FPS | Kumpulan dukungan dan kekhawatiran untuk terus mengembangkan FPS di luar CG Privasi | Meskipun kami lebih memilih agar proposal Set Pihak Pertama tetap berada di PrivacyCG, kami berharap dapat terus mengejar proposal tersebut di WICG. Kami juga senang dengan banyaknya pernyataan dukungan untuk melanjutkan diskusi tentang Set Pihak Pertama dan kasus penggunaan yang ingin diatasi. Google tetap berkomitmen untuk menemukan solusi yang memungkinkan web terus berkembang dan maju dengan cara yang melindungi dan menghormati privasi pengguna. |
| Interoperabilitas browser | Penerapan oleh browser lain | Kami menyadari pentingnya interoperabilitas browser bagi developer dan akan terus berkolaborasi dengan browser lain untuk mengejar standarisasi FPS. |
| Persyaratan kebijakan privasi umum | Tidak mungkin untuk mempertahankan kebijakan privasi yang sama di semua produk, dan wilayah hukum yang harus menjadi bagian dari kumpulan yang sama. | Chrome masih menentukan persyaratan kebijakan kami; dan akan mempertimbangkan masukan ini. |
Fenced Frames API
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Permintaan dokumentasi | Perbedaan dengan iframe dengan sandbox | Kami menghargai masukan dan saran Anda. Saat ini ada diskusi tentang hal ini di GitHub, tempat kami berharap mendapatkan klarifikasi akhir tentang permintaan tersebut agar dapat mengevaluasinya sepenuhnya. Diskusi publik tersedia di sini. |
| Kemampuan Lintas API | Dukungan default untuk Pelaporan Atribusi dalam Bingkai Pagar | Kami meminta masukan tentang proposal untuk mengizinkan Attribution Reporting API dalam "mode iklan buram" dari frame berpagar secara default. Kami mendorong developer yang merasa bahwa hal ini bermanfaat untuk ikut serta dalam diskusi. |
Shared Storage API
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Batas data | Apakah akan ada batasan jumlah data yang dapat disimpan per partisi? | Ya, akan ada batasan. Lihat masalah github untuk mengetahui detail selengkapnya. Kita memerlukan kuota penyimpanan. Proposal kami saat ini adalah memiliki batas ukuran per entri sebesar 4 KB, kunci dan nilai akan dibatasi hingga 1.024 karakter char16_t, dan batas entri per origin sebesar 10.000 entri dengan mekanisme yang mencegah entri tambahan di-commit saat kapasitas origin penuh. Kami secara aktif mencari masukan tentang batas tertentu yang diusulkan di sini. |
| Transparansi pengguna | Transparansi pengguna untuk sumber data versus penggunaan data | Kami menghargai masukan ini, dan kami pikir ini adalah pendekatan yang menjanjikan dan layak untuk dipelajari. Secara khusus, kami sedang mengevaluasi apakah hal ini dapat dilakukan dengan cara yang menawarkan transparansi yang memadai kepada pengguna. |
CHIP
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Hambatan adopsi | Haruskah CHIPS terikat dengan nama host? (persyaratan tanpa Domain) | Kami menghapus persyaratan ini dari OT berdasarkan masukan dari peserta OT bahwa persyaratan ini menambah kompleksitas dan menjadi hambatan bagi penerapan 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 Iklan di satu situs? | Pelacakan pengguna dalam satu situs adalah kasus penggunaan yang diizinkan. Kami telah memperbarui artikel developer untuk menyoroti kasus penggunaan ini. |
| Penyematan yang diautentikasi | Apakah status login dipertahankan dengan CHIPS? | Status login saat ini tidak dipertahankan, tetapi bukan kasus penggunaan yang dimaksudkan untuk CHIPS. Kami mengetahui kasus penggunaan penyematan yang diautentikasi dan sedang berupaya mencari solusinya. |
| Menguji koordinasi | Apakah ada tindakan pengguna tambahan yang diperlukan untuk menguji partisi? | Selama token OT valid dan ada di header halaman yang dikunjungi, fitur ini akan tersedia untuk pengguna, tanpa memerlukan tindakan tambahan dari pengguna |
| Kompatibilitas browser | Minat untuk 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
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | 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 untuk mengizinkan beberapa IdP | Hanya satu IDP yang dapat ditampilkan dalam satu waktu | Kami meyakini pentingnya mendukung beberapa IDP, dan secara aktif berupaya mengembangkan pendekatan untuk mendukung |
| Ekspresi | Kekhawatiran bahwa karena browser merender bagian dari alur identitas gabungan, sulit untuk menangkap semua nuansa yang ingin ditampilkan IdP kepada penggunanya. | Chrome sedang mempelajari penyesuaian branding (misalnya, logo, warna) dan penyesuaian string (misalnya, "akses artikel ini", bukan "login dengan").
Chrome menyadari adanya kompromi ini dan akan terus bekerja sama dengan ekosistem untuk mencakup sebanyak mungkin hal dan membuatnya seekspresif mungkin. |
| Penerapan dan Interoperabilitas | Kekhawatiran bahwa browser lain tidak akan mengadopsi atau menerapkan FedCM. | Chrome juga telah bekerja sama dengan vendor browser lain untuk menemukan solusi umum untuk 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 memberi sinyal bahwa email, foto, dan nama mereka akan dibagikan akan lebih mengutamakan privasi
(2) Kasus penggunaan-pendaftaran memiliki pengalaman pengguna dan pemilihan klaim dari IdP yang jarang |
Kami setuju dan sedang mempelajari cara menerapkan masukan tersebut dengan cara yang lebih mudah bagi pengguna dan lebih menjaga privasi. |
| Interaksi pengguna dengan IdP | Kebutuhan interaksi langsung antara pengguna dan IdP jika nilai minimum risiko terlampaui | Kami sedang menyelidiki masukan ini secara aktif. |
Partisi Status Jaringan
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Performa | Mempartisi status jaringan dapat menyebabkan peningkatan koneksi yang membutuhkan banyak resource ke CDN | Kami masih menyelidiki karakteristik performa Partisi Status Jaringan, termasuk mengukur berbagai kemungkinan skema kunci. Kami belum membuat keputusan antara kompromi performa, keamanan, dan privasi dan perlu mengumpulkan lebih banyak data. |
Memerangi spam dan penipuan
Trust Tokens API
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Masukan peraturan | Kekhawatiran tentang investasi waktu dan sumber daya dalam Token Tepercaya tanpa sinyal yang jelas dari regulator tentang kelayakan jangka panjang | Tujuan kami adalah membangun teknologi yang sesuai untuk ekosistem, sehingga masukan dari industri dan pembuat peraturan sangat penting dalam proses ini. Kami akan terus berkonsultasi dengan regulator di seluruh dunia saat mengembangkan Privacy Sandbox dan menyediakan proposal ini kepada developer, termasuk Token Kepercayaan. Seperti semua teknologi baru, perusahaan harus membuat keputusan berdasarkan penilaian mereka sendiri terhadap persyaratan peraturan. |
| Waktu peluncuran | Kapan Token Kepercayaan akan diluncurkan ke versi GA? | Kami memberikan estimasi saat ini untuk peluncuran di linimasa publik kami di privacysandbox.com. Segera setelah kami membuat keputusan akhir tentang tanggal peluncurannya ke GA, kami akan mempostingnya secara publik melalui proses rilis Chrome dan memperbarui linimasa di situs. |
| Trust Token vs. lainnya | Peran apa yang dimainkan Token Kepercayaan mengingat token lain yang sedang menjalani standardisasi, seperti Token Akses Pribadi | Kami terlibat dalam diskusi standarisasi dan tujuan kami adalah menyelaraskan dengan upaya lain sebanyak mungkin, sekaligus memungkinkan berbagai kasus penggunaan yang diberikan oleh setiap teknologi. Misalnya, Token Kepercayaan dan Token Akses Pribadi mengandalkan protokol Privacy Pass. |
| Batas data | Maksimal 2 Penerbit untuk penukaran token per halaman yang berpotensi membatasi | Kami mencari opsi jangka panjang yang memungkinkan kami mengizinkan perusahaan menukarkan token dengan aman tanpa mempertaruhkan entropi pengguna yang lebih besar, mungkin dengan mempartisi akses ke penukaran token. |
| Batasan akses | Hanya origin yang disetujui (dan diverifikasi/bukan perujuk yang di-spoof) yang dapat memverifikasi keberadaan token dan menukarkan | Kami sedang mempelajari pendekatan untuk menentukan siapa yang dapat melihat dan menukarkan token. |
| Dukungan perangkat | Dependensi runtime JavaScript membatasi penggunaan di perangkat tertentu. Dapatkah dukungan TT diperluas agar berfungsi di berbagai jenis perangkat lainnya? | Hal ini dapat kami pertimbangkan untuk pengembangan di masa mendatang dan merupakan topik yang ingin kami dengar masukan lebih lanjut dari developer di forum W3C. Kami juga memiliki masalah terbuka untuk membahas penukaran token yang dipicu Header HTTP yang kami minta masukan. |
| Kasus penggunaan | Tidak jelas apa kasus penggunaan yang tepat untuk Token Kepercayaan. Kurangnya kejelasan tentang penggunaan yang diinginkan. | Tujuan kami adalah memfasilitasi inovasi dalam ruang anti-penipuan, dan memahami bahwa setiap perusahaan dapat menggunakan teknik eksklusif dengan token kepercayaan, itulah sebabnya kami belum memberikan petunjuk terkait penggunaan yang dimaksud. Namun, kami kemungkinan akan memperluas dokumentasi untuk menyertakan lebih banyak contoh sebagai titik awal bagi partner yang mempertimbangkan eksperimen atau penerapan. |
| Cakupan Trust Token | Menghapus kebijakan fitur 'penukaran token kepercayaan' ini akan meningkatkan cakupan token kepercayaan secara signifikan. | Hal ini sedang dipertimbangkan saat kami mengumpulkan masukan dari OT dan membuat keputusan tentang langkah berikutnya. |
| Kepercayaan penerbit | Mengapa kita harus memercayai situs yang menerbitkan token kepercayaan? | Tidak ada panduan untuk menjadi penerbit - siapa pun dapat melakukannya. Penayang diharapkan hanya bekerja sama dengan penerbit yang mereka percayai. Selain itu, pelaku yang sah lainnya di ekosistem iklan pada akhirnya akan memberikan diskon (atau berhenti membeli) traffic yang terkait dengan penerbit yang mencurigakan atau tidak dikenal. |
| Layanan tersemat pihak ketiga | Dapatkah layanan tersemat pihak ketiga menukarkan dan/atau meminta token kepercayaan? | Ya, layanan tersemat pihak ketiga dapat menerbitkan dan menukarkan Token Kepercayaan. |
| Ekosistem penerbit | Manfaat yang lebih besar dapat dicapai jika sinyal kepercayaan dapat dibagikan kepada perusahaan lain | Token Kepercayaan dirancang untuk menjadi primitif tingkat rendah, dan dapat digunakan oleh penerbit/penebus yang bekerja sama untuk membagikan sinyal kepercayaan/reputasi. |
| Overhead pemeliharaan | Implementasi kriptografi yang mendasari operasi Token Kepercayaan ada di BoringSSL; yang merupakan satu-satunya pengelola Google. Bagaimana pemeliharaan library akan dikelola? | Token Kepercayaan mengandalkan operasi kriptografi standar (lihat Protokol Privacy Pass) yang juga dapat diterapkan di library lain. Sebaiknya developer meminta/mengembangkan/memelihara dukungan untuk operasi ini di library pilihan mereka. |
| Overhead pemeliharaan | Tidak jelas berapa lama versi protokol akan didukung | Kami sedang mempertimbangkan untuk mengembangkan dan mendokumentasikan lebih spesifik tentang jangka waktu dukungan yang diharapkan untuk versi protokol. |
| Batas Penerbit | Jika Anda berada di bagian bawah rantai, peluang Anda untuk mengeksekusi Token Kepercayaan mungkin tidak muncul | Seiring semakin banyak organisasi yang mulai menggunakan token kepercayaan, kami semakin sering melihat jenis dinamika pengaturan waktu ini, dan sedang menyelidiki potensi solusinya. Seperti yang dijelaskan sebelumnya, kami mencari opsi jangka panjang yang memungkinkan kami mengizinkan perusahaan menukarkan token dengan aman tanpa mempertaruhkan entropi pengguna yang lebih besar, yang akan meminimalkan pentingnya lokasi di halaman atau urutan pemuatan. |
Solusi Anti-Penipuan Baru dalam Inkubasi
| Feedback Theme
(Diurutkan berdasarkan Prevalensi) |
Ringkasan Pertanyaan dan Masalah | Respons Chrome |
| Sinyal Pengesahan Integritas Perangkat | Dukungan yang umumnya kuat untuk mengejar sinyal integritas perangkat yang dibuktikan oleh platform dan tersedia untuk web | Kami akan terus mengumpulkan masukan dan melanjutkan 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 banknya) dapat membenarkan sinyal entropi yang lebih tinggi. | Kami cenderung memberikan 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/dimodifikasi? | Setiap sinyal baru harus mempertimbangkan akses universal sebagai prinsip utama dalam pengembangan, dan ini adalah 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 anti-penipuan terlalu mengandalkan browser dan platform
|
Setiap sinyal baru harus dilihat sebagai data tambahan, bukan indikasi "kepercayaan" dari browser. Kami sepenuhnya berharap perusahaan keamanan akan terus mengandalkan data, model, dan mesin keputusan eksklusif mereka sendiri dengan pengesahan perangkat sebagai input tambahan. Semoga sinyal baru apa pun akan meningkatkan upaya deteksi di seluruh ekosistem dan mempersulit pelaksanaan penipuan. |
| Sinyal Usia Cookie | Konsep yang menarik, tetapi mungkin memerlukan lebih banyak investigasi terhadap kasus penggunaan yang berlaku. | Bergantung pada tingkat minat, Chrome dapat melakukan perumusan ide lebih lanjut tentang konsep ini, dan membuatnya menjadi penjelasan untuk masukan ekosistem di masa mendatang. |
| Server Tepercaya untuk Anti-penipuan | Konsep yang menarik, tetapi mungkin memerlukan lebih banyak investigasi terhadap kasus penggunaan yang berlaku. | Bergantung pada tingkat minat, Chrome dapat melakukan perumusan ide lebih lanjut tentang konsep ini, dan membuatnya menjadi penjelasan untuk masukan ekosistem di masa mendatang. |