Laporan kuartalan untuk Kuartal 2 2023 yang merangkum masukan ekosistem yang diterima terkait proposal Privacy Sandbox dan respons Chrome.
Sebagai bagian dari komitmennya terhadap CMA, Google telah setuju untuk memberikan laporan tiga bulanan tentang proses interaksi pemangku kepentingan untuk Privacy Sandbox proposal (lihat paragraf 12 dan 17(c)(ii) dari Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima oleh Chrome dari berbagai sumber sebagaimana tercantum dalam bagian masukan ringkasan, termasuk, tetapi tidak terbatas pada: GitHub Masalah, formulir masukan yang tersedia di privacysandbox.com, pertemuan dengan industri pemangku kepentingan, dan forum standar web. Chrome menyambut masukan yang diterima dari ekosistem dan secara aktif mengeksplorasi cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.
Tema masukan diberi peringkat berdasarkan prevalensi per API. Hal ini dilakukan dengan mengambil gabungan jumlah masukan yang diterima tim Chrome sekitar tema tertentu dan mengaturnya dalam urutan kuantitas yang menurun. Masukan yang umum tema diidentifikasi dengan meninjau topik diskusi dari pertemuan publik (W3C, PatCG, IETF), masukan langsung, GitHub, dan pertanyaan umum muncul melalui tim internal Google dan formulir publik.
Lebih tepatnya, notulen rapat untuk rapat badan standar web ditinjau dan, untuk masukan langsung, catatan Google tentang pertemuan empat mata pemangku kepentingan, email yang diterima oleh tiap engineer, milis API, dan publik formulir umpan balik. Google kemudian berkoordinasi dengan tim dalam berbagai kegiatan penjangkauan ini untuk menentukan prevalensi tema yang muncul dalam kaitannya dengan setiap API.
Penjelasan atas respons Chrome terhadap masukan dikembangkan dari FAQ, tanggapan aktual yang dibuat terhadap masalah yang dikemukakan oleh para pemangku kepentingan, dan menentukan secara khusus untuk tujuan latihan pelaporan publik ini. Mencerminkan fokus pengembangan dan pengujian saat ini, pertanyaan, dan masukan diterima khususnya sehubungan dengan Topics, Protected Audience, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum respons Chrome yang dipertimbangkan.
Glosarium akronim
- CHIP
- Cookie yang Memiliki Status Terpartisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Pengelolaan Kredensial Federasi
- FPS
- Set Pihak Pertama
- IAB
- Interactive Advertising Bureau
- IDP
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Protokol Internet
- openRTB
- Bidding real-time
- OT
- 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 tertentu
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Tata Kelola Data & Kepatuhan terhadap Peraturan | Panduan ekosistem tentang cara menggunakan Privacy Sandbox yang mematuhi persyaratan peraturan. | Seperti teknologi baru lainnya, setiap perusahaan bertanggung jawab untuk memastikan bahwa penggunaan Privacy Sandbox mematuhi hukum; Google tidak dapat memberikan nasihat hukum kepada orang lain. Namun, kami menyadari bahwa ini adalah area kepentingan utama bagi ekosistem. Untuk setiap API, kami telah memublikasikan dokumentasi teknis ekstensif, yang akan memberikan dasar untuk melakukan penilaian hukum yang diperlukan, dan kami sedang berupaya menyediakan materi tambahan untuk mendukung perusahaan upaya untuk mematuhi persyaratan peraturan. |
| Proposal Pengujian Kuantitatif CMA | Informasi selengkapnya tentang proposal pengujian kuantitatif CMA | Kami bekerja sama dengan CMA untuk merancang eksperimen yang akan memberikan gambaran tentang dampak penghentian penggunaan cookie pihak ketiga dan pengenalan proposal Privacy Sandbox di ekosistem. Pada bulan April, CMA memublikasikan panduan tingkat tinggi tentang hal-hal yang akan terjadi selama periode Pengujian dan Uji Coba yang diikuti dengan panduan mendetail pada bulan Juni. Sebaiknya pertanyaan atau masukan mengenai proposal Pengujian Kuantitatif CMA disampaikan secara langsung kepada CMA. |
| Mode pengujian yang difasilitasi Chrome | Informasi dan klarifikasi selengkapnya tentang jadwal pengujian | Kami memublikasikan postingan blog pada 18 Mei untuk membagikan informasi lebih lanjut tentang dua mode pengujian yang difasilitasi Chrome. Detail ini belum final, dan kami akan memublikasikan panduan penerapan lebih lanjut seiring progres kami pada Q3 2023. |
| Penyimpanan yang Dipartisi | Apakah penyimpanan yang dipartisi akan digunakan selama pengujian yang difasilitasi Chrome? | Partisi penyimpanan akan dikirimkan ke semua pengguna sebelum eksperimen penghentian penggunaan cookie pihak ketiga. Oleh karena itu, fitur ini akan diaktifkan untuk semua grup eksperimen. Situs akan memiliki opsi untuk mengaktifkan uji coba penghentian penggunaan untuk mendapatkan kembali penyimpanan yang tidak dipartisi selama jangka waktu ini. |
| Dukungan produksi | Proses apa yang berlaku bagi Chrome untuk mendukung eskalasi dan masalah teknis Privacy Sandbox yang memengaruhi ekosistem? | Google menyediakan berbagai saluran untuk memungkinkan teknologi iklan melaporkan masalah dan mengaktifkan eskalasi yang diperlukan. Lihat postingan developer kami untuk mengetahui informasi selengkapnya tentang forum publik dan pribadi untuk mendapatkan masukan dan eskalasi. |
| Rentang Waktu Pendaftaran | Jangka waktu pendaftaran saat ini terlalu singkat | Kami masih mengevaluasi batas waktu penegakan kebijakan dan kami ingin mendengar dari ekosistem terkait jadwal mana yang lebih cocok. |
| Nomor D-U-N-S | Informasi selengkapnya tentang persyaratan nomor D-U-N-S untuk Pendaftaran dan Pengesahan | Peserta dapat menemukan persyaratan untuk mendapatkan Nomor D-U-N-S di situs Dun and Bradstreet. Persyaratannya bervariasi tergantung pasar, jadi peserta harus memastikan untuk memeriksa {i>website<i} untuk pasar tertentu yang mereka minati. Namun, secara umum, peserta harus memberikan informasi dasar tentang bisnis mereka, seperti nama bisnis, alamat, dan informasi kontak pemilik atau pengelola bisnis. Peserta mungkin juga diminta untuk memberikan informasi keuangan, seperti pendapatan tahunan bisnis. Setelah permohonan selesai, D&B akan meninjaunya dan menerbitkan Nomor D-U-N-S jika permohonan disetujui. |
| Bertransisi dari Uji Coba Origin ke Ketersediaan Umum | Apakah transisi dari Uji Coba Origin ke Ketersediaan Umum akan memengaruhi penguji Uji Coba Origin saat ini? | Mulai bulan Juli, penguji akan dapat mengakses API pengukuran dan relevansi secara umum pada saat ketersediaan umum. Hal ini akan menyebabkan tumpang tindih antara ketersediaan uji coba origin dan ketersediaan umum. |
| Studi AdExchanger | Informasi selengkapnya tentang metodologi survei | Survei tersebut meminta responden untuk memperkirakan tingkat sinkronisasi dan pendapatan untuk bisnis mereka. Responden metodologi untuk menjawab pertanyaan individu merupakan tugas mereka. |
| Parameter value | Bagaimana nilai parameter seperti level derau, nilai minimum anonimitas, dan anggaran privasi ditentukan? | Penjelasan GitHub ini menjelaskan prinsip-prinsip yang lebih umum di balik API Privacy Sandbox. Banyak nilai yang masih dalam proses penyelesaian dan kami menantikan masukan terkait subjek ini. |
Tampilkan Konten yang Relevan & Google Ads
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Perlindungan Privasi | Riset yang mengevaluasi Topics API terkait perlindungan privasi | Kami terlibat aktif dengan komunitas riset, menyajikan riset kami tentang properti privasi Topics API dalam makalah, laporan, dan presentasi workshop. Kami senang melihat lebih banyak anggota eksternal komunitas riset yang terlibat di bidang ini. Topics API melindungi pengguna dari pelacakan umum di web dengan mempersulit pelacakan pengguna dalam skala besar. Laporan ini menunjukkan bahwa kami berhasil melakukannya dengan Topics API. Metode ini lebih pribadi daripada cookie pihak ketiga dan melindungi pengguna sekaligus mendukung situs yang mereka sukai. |
| Taksonomi topik tidak cukup terperinci | Taksonomi topik yang luas tidak mencakup topik yang lebih terperinci, termasuk khusus wilayah. | Sebagai respons atas masukan sebelumnya dari ekosistem, kami memublikasikan postingan blog pada 15 Juni yang menjelaskan taksonomi baru yang diperbarui yang menyertakan berbagai peningkatan setelah masukan dari ekosistem. Sebagai bagian dari upaya kami pada taksonomi yang direvisi, kami telah bekerja sama dengan beberapa perusahaan di seluruh ekosistem, seperti Raptive (sebelumnya CafeMedia) dan Criteo. Taksonomi yang diperbarui menghapus kategori yang kami dengar kurang berguna, mendukung kategori yang lebih cocok dengan minat pengiklan, sekaligus mempertahankan komitmen kami untuk mengecualikan topik yang berpotensi sensitif. Kami mendorong ekosistem untuk meninjau taksonomi terbaru dan memberikan masukan terkait perubahan tersebut. |
| Proses pembaruan taksonomi dan pengklasifikasi | Informasi selengkapnya tentang taksonomi Topics dan ritme rilis pengklasifikasi serta cara perusahaan dapat bersiap untuk pembaruan tersebut. | Seperti yang dijelaskan dalam postingan blog baru-baru ini, kami berharap taksonomi berkembang dari waktu ke waktu, dan bagi tata kelola taksonomi pada akhirnya akan bertransisi ke pihak eksternal yang mewakili pemangku kepentingan dari seluruh industri. Kami juga membagikan rencana peningkatan di grup pengumuman topik. |
| Dampak pada sinyal pihak pertama | Peningkatan jumlah Topics dalam pembaruan Taksonomi terbaru mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. | Dalam laporan Q1 2023, CMA berkomentar bahwa "Kami memahami bahwa Google telah mendiskusikan usulan taksonomi barunya dengan beberapa peserta pasar di seluruh supply chain teknologi iklan. Meskipun beberapa penerbit besar mengatakan bahwa utilitas topik yang lebih besar akan meningkatkan tekanan persaingan pada solusi berbasis data pihak pertama mereka, pandangan awal kami adalah bahwa utilitas yang lebih besar lebih baik untuk persaingan secara keseluruhan – khususnya kemampuan penerbit kecil untuk terus memonetisasi inventaris mereka setelah penghentian cookie pihak ketiga". Pendapat kami selaras dengan komentar yang dibuat oleh CMA ini. |
| Kebergunaan untuk berbagai jenis pemangku kepentingan | Teknologi iklan yang bertindak sebagai SSP dan DSP mungkin memiliki keunggulan yang signifikan dibandingkan pemain ekosistem lainnya. | Respons kami tidak berubah dari kuartal sebelumnya: "Google telah berkomitmen kepada CMA untuk merancang dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, dan untuk memperhitungkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan, terlepas dari ukuran mereka. Kami terus bekerja sama dengan CMA untuk memastikan bahwa pekerjaan kami mematuhi komitmen ini. Seiring progres pengujian Privacy Sandbox, salah satu pertanyaan utama yang akan kami nilai adalah performa teknologi baru ini untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan yang spesifik dan dapat ditindaklanjuti yang dapat membantu kami lebih meningkatkan desain teknis. Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA yang memublikasikan catatan tentang desain eksperimen untuk memberikan lebih banyak informasi kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan." |
| Topik Turunan | Jika kriteria pemilihan topik adalah frekuensi kunjungan browser, apakah fragmentasi segmen akan menyebabkan topik turunan tidak pernah naik ke posisi teratas? | Chrome sedang mengevaluasi metodologi peringkat lainnya, dan mempelajari sinyal lain yang dapat meningkatkan peringkat. Kami akan menyampaikan rencana kami yang telah direvisi ke ekosistem pada waktunya. |
| Sensitivitas | Tujuan Topics API seharusnya adalah memastikan informasi pengguna yang diperoleh atau berasal dari Topics API tidak terlalu sensitif secara pribadi dibandingkan dengan yang dapat diperoleh menggunakan metode pelacakan saat ini. | Kami yakin bahwa Topics API jauh lebih pribadi dibandingkan teknologi saat ini, secara signifikan membatasi identifikasi ulang pengguna, dan dirancang untuk mengecualikan topik sensitif. Kami memahami bahwa topik dapat dikaitkan atau dikombinasikan dengan data pihak pertama untuk membuat kategori sensitif, tetapi kami yakin bahwa Topics API merupakan langkah maju untuk meningkatkan privasi pengguna dan kami berkomitmen untuk terus meningkatkan kualitas API. |
| Struktur Taksonomi | Menambahkan ID, Pembuatan Versi, dan struktur metadata lainnya ke Taksonomi Topik | Saat ini, kami menyertakan ID taksonomi dalam respons API. Seiring kami bergerak menuju tata kelola jangka panjang, sebaiknya tinjau objek Topics dan sertakan metadata tambahan terkait pembuatan versi jika diperlukan. |
| Kontrol penayang | Penayang harus memiliki keputusan terkait Topics yang sesuai untuk situs mereka. | Kesalahan klasifikasi situs dapat membuat sinyal Topics sedikit kurang berguna sebagai sinyal secara keseluruhan, tetapi situs tertentu yang salah diklasifikasikan tidak lebih dirugikan oleh hal ini dibandingkan situs lainnya. Hal ini karena informasi kontekstual situs akan selalu tersedia untuk lelang di situs mereka, yang akan memberikan informasi yang sebanding dengan topik yang benar, meskipun terjadi kesalahan klasifikasi. Kami menerima masukan terkait subjek ini di sini. Mengizinkan penerbit untuk mengontrol klasifikasi mereka berisiko. Situs mungkin salah mengklasifikasikan situs mereka secara sengaja, mengurangi kegunaannya untuk semua, atau mengenkode makna sensitif dalam topik yang kurang umum, sehingga membahayakan privasi pengguna. |
| Ekstensi Chrome | Izinkan Ekstensi Chrome mengelola dan memfilter Topics, mirip dengan ekstensi Pengelolaan Cookie saat ini | Hal ini seharusnya sudah dapat dilakukan, seperti yang dibahas di GitHub, tetapi kami siap menerima masukan tambahan dari ekosistem. |
| Transisi ke Ketersediaan Umum | Apakah akan ada dampak pada Topics API saat melakukan transisi dari Uji Coba Origin ke Ketersediaan Umum? | Tidak akan ada data yang hilang untuk pengguna yang bertransisi dari Uji Coba Origin ke Ketersediaan Umum. |
| Privasi | Nama Host dapat berisi informasi pribadi yang dapat diungkapkan oleh Topics API | Kami memiliki sejumlah mitigasi untuk memastikan privasi, seperti yang dijelaskan di sini. |
| Penipuan dan Penyalahgunaan | Cara mencegah manipulasi Topics oleh kunjungan penipuan | Mitigasi diuraikan di sini. |
| Pengklasifikasi topik | Dapatkah situs meminta untuk mengubah klasifikasi Topics-nya? | Kami ingin mendengar pendapat dari ekosistem tentang topik ini dan menerima masukan di sini. |
| Situs penyedia Topics | Menetapkan situs tertentu yang menghosting konten untuk banyak Topics sebagai "Situs Penyedia Topik Khusus" dan melatih pengklasifikasi berdasarkan tag yang diberikan di halaman web. | Kami membahas proposal tersebut di sini, dan menantikan masukan tambahan. |
Protected Audience API (sebelumnya FLEDGE)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pembentukan Traffic | Dampak performa pemfilteran berbasis SSP untuk mengoptimalkan pemuatan kueri per detik (QPS) | Kami telah menghabiskan banyak waktu untuk memikirkan pembentukan traffic dan direkomendasikan agar SSP dapat memanfaatkan penyimpanan dalam cache. |
| Menguji volume | Menantang untuk menguji Protected Audience karena SSP dan DSP kesulitan mendapatkan volume traffic yang besar. | Kami terus bekerja sama dengan partner SSP dan DSP untuk mengadopsi dan menguji Protected Audience. Ketersediaan Umum telah dimulai dan kami yakin persentase traffic yang mengaktifkan PA akan membuatnya lebih mudah diuji oleh partner. |
| Kompleksitas | Menerapkan solusi Protected Audience memerlukan upaya dan biaya yang besar. | Kami mengakui bahwa teknologi baru sulit diadopsi, termasuk Privacy Sandbox. Tim Privacy Sandbox bekerja sama dengan berbagai pemangku kepentingan untuk mengedukasi dan mendukung upaya mereka serta terus mengevaluasi akselerometer lain untuk mendukung penerapan ekosistem. |
| Trusted Execution Environment | Dukungan untuk Trusted Execution Environment (TEE) di lingkungan cloud non-publik | Meskipun kami sedang menjajaki kemungkinan opsi yang mendukung di luar solusi berbasis cloud, saat ini kami belum dapat mendukung TEE lokal karena adanya batasan keamanan lokal yang akan memerlukan evaluasi yang memakan waktu lama untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya mendukung GCP selain AWS) adalah upaya yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan pentingnya persyaratan tersebut. |
| Struktur Biaya | Penawaran & Proposal Layanan Lelang akan meningkatkan biaya dan kerumitan untuk Teknologi Iklan dibandingkan dengan model sisi klien. | Saat ini kami sedang mengembangkan panduan untuk memperkirakan biaya dukungan alur kerja bidding dan lelang dalam Bidding & Server lelang, yang akan dikorelasikan dengan penggunaan teknologi iklan, yang memenuhi salah satu sasaran desain kami. |
| Linimasa K-Anon | Kapan batasan k-anonymity yang direncanakan akan diterapkan pada `renderUrl` ? | Kami sedang menyusun penjelasan untuk jadwal penegakan yang akan segera kami rilis. |
| Pembatasan runAdLelang | Dapatkah Chrome membatasi runAdAuction agar hanya dapat dipanggil dari halaman atas? |
Meskipun desain kami sepenuhnya mendukung runAdAuction agar dapat dipanggil dari halaman atas, kami yakin akan lebih berbahaya bagi penayang untuk membatasinya agar hanya dapat dipanggil dari domain teratas.Kami telah secara khusus mendengar dari ekosistem bahwa Privacy Sandbox perlu meminimalkan beban bagi penayang dan pengiklan. Masukan tersebut selaras dengan prinsip umum pengembangan web bahwa pemilik situs dapat menggunakan alat pihak ketiga dalam menjalankan situs mereka. Tujuan Privacy Sandbox adalah mendorong ekosistem yang sehat tanpa perlu meresepkan cara kerja penayang dan teknologi iklan. Dengan memungkinkan penayang memilih cara dan siapa yang memanggil runAdAuction di situsnya, kami yakin kami menawarkan fleksibilitas kepada penayang untuk menemukan jalur terbaik sesuai kebutuhan mereka. |
| Dukungan penerapan | Dapatkah Chrome membuat atau berkontribusi pada implementasi open source lelang multi-penjual? | Privacy Sandbox bertujuan untuk mengembangkan teknologi yang menjaga privasi dan tidak mengandalkan cookie pihak ketiga atau ID lintas situs lainnya. Kami ingin mendorong ekosistem yang sehat tanpa perlu meresepkan cara kerja teknologi iklan. Kami telah memublikasikan panduan tentang cara kerja API di repositori GitHub kami dan terbuka untuk mengeksplorasi solusi dengan industri ini. Kami tidak berencana membangun implementasi tertentu karena tugas inti kami adalah membangun teknologi platform, bukan untuk mendikte strategi penggunaan teknologi tersebut. Teknologi kami akan membantu memungkinkan perusahaan teknologi iklan memberikan layanan terbaik kepada pelanggannya dengan perlindungan privasi yang tepat bagi konsumen. |
| Lelang multi-penjual | Apakah Chrome akan otomatis membagikan "kontekstual" pemenang pada lelang komponen? | Protected Audience API dirancang untuk menawarkan kemampuan bagi pihak yang memulai lelang multi-penjual untuk meneruskan informasi ke lelang komponen (catatan: hanya sebelum memulai lelang). Meskipun demikian, kami tidak melihat cara bagi browser untuk membedakan apakah suatu informasi merupakan pemenang kontekstual atau tidak, sehingga kami tidak dapat menerapkan pemblokiran atau mewajibkan informasi tertentu. |
| Preferensi pengguna untuk pelacakan izin | Teknologi iklan menanyakan cara menerapkan pelacakan izin pengguna dengan benar kepada PA | Respons kami mencakup hal yang kami katakan di K1: "Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang memiliki posisi terbaik untuk menawarkan kontrol terhadap materi iklan yang ditampilkan atau cara pemilihannya." Kita telah membahas sejumlah skenario terkait masalah ini selama Rapat Protected Audience WICG bulan Mei, dan kami menerima masukan dan diskusi tambahan terkait masalah ini. |
| Audiens Kustom | Apakah kasus penggunaan SSP yang terkait dengan pembuatan Audiens Kustom akan didukung oleh Protected Audience API? | Dengan Protected Audience API, SSP dan penyedia teknologi iklan lainnya dapat memiliki dan mengelola Audiens Kustom. Panduan lebih lanjut tentang cara SSP berintegrasi dengan PA API sedang dikembangkan dan akan tersedia bagi SSP dan penyedia teknologi iklan lainnya untuk mendukung upaya integrasi mereka. |
| Format | Apakah video didukung oleh Protected Audience API? | Iklan video ditayangkan dengan salah satu dari dua cara: sebagai XML VAST atau HTML (iklan outstream yang pada akhirnya juga dapat memuat XML VAST ke pemutar video). Pembeli dapat menampilkan salah satu format melalui renderURL. Spesifikasi VAST baru-baru ini diperbarui untuk mendukung Attribution Reporting API. Situs yang menayangkan iklan video harus mempersiapkan cara iklan ditayangkan melalui Protected Audience API. Artinya, tag penempatan dapat meneruskan URL dari iframe Protected Audience ke pemutar video. Untuk Frame Fenced, kami akan berupaya memenuhi kebutuhan video sebelum persyaratan untuk menggunakan Fenced Frames mulai tahun 2026. |
| Kecepatan | Bagaimana cara kerja kasus penggunaan Pacing dengan Protected Audience API? | Kami menghargai masukan tersebut. Kami tertarik untuk melihat lebih banyak contoh permintaan ini dengan detail lebih lanjut yang berasal dari lebih banyak partner SSP karena hal ini sebagian besar merupakan masalah DSP hingga saat ini. |
| Frekuensi pembaruan | Frekuensi panggilan dari dailyUpdate (maksimal 1 per grup minat per hari) mungkin tidak cukup untuk kasus penggunaan tertentu, seperti memperbarui informasi produk. |
Kami menghargai masukan tersebut. Ada solusi lain yang tersedia untuk memungkinkan teknologi iklan menggunakan sinyal yang diperbarui dalam berbagai ritme seperti pencarian K/V. |
| Kendali Mutu Iklan | Bagaimana cara penayang menerapkan kontrol kualitas iklan? | Saat ini, Protected Audience API menawarkan fungsi bagi penayang untuk memberi tahu SSP mereka tentang kontrol tertentu yang dapat mereka buat sebagai bagian dari konfigurasi lelang, pra-bidding (yaitu daftar tolak berdasarkan label yang terkait dengan iklan). Kami menerima masukan tentang fungsi tambahan apa pun yang mungkin diperlukan ekosistem. |
| Proses Debug | Kapan fungsi forDebuggingOnly akan dihapus? |
Kami berencana untuk menghentikan forDebuggingOnly karena peristiwa hilangnya oleh penghentian penggunaan cookie pihak ketiga. Kami berencana menghentikan forDebuggingOnly untuk acara yang menang pada tahun 2026. |
| Grup Minat Lintas Perangkat | Proposal untuk mengaktifkan grup minat lintas perangkat bagi agen pengguna yang diautentikasi | Kami sedang mengevaluasi proposal ini, tetapi kekhususan penargetan lintas-perangkat yang tinggi menimbulkan masalah privasi yang signifikan, seperti yang dibahas dalam Masalah GitHub ini. |
| (Juga dilaporkan pada K1) Pemasaran Ulang Dinamis | Apakah Pemasaran ulang dinamis masih dapat dilakukan dengan Protected Audience API setelah cookie pihak ketiga tidak digunakan lagi? | Kami yakin kasus penggunaan ini mungkin digunakan menggunakan Protected Audience, seperti yang dijelaskan di sini. |
| Klik data terkait | Tambahkan data terkait klik ke browserSignals. |
Saat ini kami meminta klarifikasi tentang kapan klik terjadi untuk memberikan posisi awal. |
| (Juga dilaporkan pada Q4 2022) Fungsi yang ditentukan pengguna di Protected Audience | Bagaimana fungsi yang ditentukan pengguna (UDF) akan didukung di Protected Audience API? Fungsi ini adalah fungsi yang dapat diprogram oleh pengguna akhir untuk memperluas fungsi API. | Teknologi iklan yang melaporkan masalah ini juga menyebutkan bahwa mereka masih mengevaluasi tindakan yang dapat dilakukan dengan UDF. Jadi, di sini belum ada masukan yang dapat ditindaklanjuti, belum sampai setidaknya Ketersediaan Umum. |
| Mata Uang | Jumlah mata uang tidak boleh ditampilkan menggunakan floating point. | Kami telah membahas masalah ini secara mendetail di sini. |
| Kemampuan pemilihan iklan non-DSP | Apa peran Server Iklan dalam lelang Protect Audience API? | Kami mengetahui permintaan Server Iklan untuk terus menawarkan layanan pengoptimalan materi iklan dinamis / pemilihan iklan pasca-bidding. Saat ini kami sedang menilai analisis kesenjangan mendetail yang ada antara Protected Audience API saat ini dan permintaan tersebut. |
| GenerateBid | Dukungan untuk Google Ads proposal untuk mengembalikan lebih dari satu iklan kandidat per grup minat iklan dari generateBid dan mendapatkan skor kandidat tersebut di `scoreAd`. |
Hal ini sedang dievaluasi. Kami menyambut baik masukan tambahan di sini. |
| Pesanan Lelang | Apakah Lelang Protected Audience API harus menjadi lelang terakhir yang dijalankan agar dapat mengambil input dari hasil semua lelang lainnya? | Tidak ada persyaratan teknis bagi Protected Audience API untuk berjalan terakhir. |
| Navigasi yang dimulai oleh non-pengguna | Mengekspos navigasi yang dimulai non-pengguna | Kami sedang meninjau permintaan ini dan membahasnya di sini serta menerima masukan tambahan. |
| Menyimpan ke cache | SSP tidak boleh membangun perBuyerSignals DSP tertentu dari cache jika status pengguna berubah. | Kami memahami bahwa penyimpanan cache tidak berfungsi untuk setiap kasus penggunaan untuk sinyal perPembeli dan sedang mengevaluasi opsi lebih lanjut. Kami menerima masukan tambahan dari ekosistem terkait apakah penyimpanan cache dapat berfungsi untuk kasus penggunaan mereka atau tidak. |
| Attribution Reporting dan Protected Audience | Bagaimana Attribution Reporting API dan Protected Audience Audience API bekerja sama? | Integrasi saat ini tersedia untuk Protected Audience API untuk kedua mode Attribution Reporting API (laporan tingkat peristiwa dan ringkasan). Kami telah membagikan informasi selengkapnya tentang integrasi Protected Audience API dan Attribution Reporting yang ditingkatkan pada 1 Juni. Anda dapat membacanya di sini. |
| Endpoint Server | Apakah endpoint server akan menjadi Server Agregasi Tepercaya dalam desain akhir? | Endpoint server adalah endpoint yang dikelola teknologi iklan dan tidak bergantung pada Server Agregasi Tepercaya yang digunakan untuk memproses laporan yang dikumpulkan dan diubah. Saat ini, belum ada rencana perubahan apa pun untuk endpoint pelaporan. Desain saat ini bertujuan untuk memastikan bahwa laporan agregat itu sendiri (dengan payload terenkripsi) tidak membocorkan data lintas situs, sehingga endpoint tepercaya tidak diperlukan. Detail tambahannya adalah teknologi iklan yang berbeda mungkin akan memiliki strategi pengelompokan yang berbeda pula yang diinginkan. Kami menyambut baik masukan tambahan di sini. |
| WebIDL | Spesifikasi Protected Audience API saat ini tidak kompatibel dengan spesifikasi WebIDL. | Kami mengevaluasi masukan ini dan membahas masalahnya di sini. |
| Pengelolaan Izin | Bagaimana penerusan sinyal izin ditangani di Protected Audience API? | Informasi kontekstual tidak termasuk dalam cakupan Protected Audience API. Kami membahas masalah ini dan menantikan masukan tambahan. |
| Pemasaran Berbasis Akun | Apakah kasus penggunaan pemasaran berbasis akun dapat dilakukan? | Protected Audience API mendukung berbagai kasus penggunaan pemasaran berbasis audiens. Kami terus memahami cara terbaik Protected Audience API dalam mendukung kasus penggunaan khusus ini, dan menerima masukan tambahan dari ekosistem terkait masalah ini. |
| Lelang komponen | Apa yang dinilai peserta lelang komponen? | Lelang komponen tidak menilai Grup Minat secara langsung, melainkan menilai iklan dan bid yang dikirimkan DSP dari fungsi generateBid. Fungsi generateBid() berjalan per grup minat, dan DSP menampilkan hal berikut saat menjalankan generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Kontribusi Eksternal | Permintaan untuk mendukung kontribusi eksternal pada code base GitHub Key/Value Server. | Kami ingin memperbarui proses yang relevan untuk mendukung kontribusi eksternal pada kode GitHub. |
| Ukuran Grup Minat | Berapa jumlah maksimum kunci yang didukung yang dapat didukung IG? | Batas saat ini adalah 50 kb pada ukuran satu IG dan kunci dihitung sebagai bagian darinya. Kami menyambut baik diskusi lebih lanjut terkait batas ukuran. |
| Pengelompokan | Bagaimana cara mengurangi jumlah panggilan server K/V? | Anda dapat menggunakan Header Cache-Control HTTP untuk mengurangi jumlah panggilan K/V. Misalnya, dapat di-cache di seluruh lelang komponen, dan juga di seluruh slot iklan pada satu halaman. |
| Kontrol versi | Dukungan untuk beberapa versi kode teknologi iklan | Layanan Bidding dan Lelang akan mendukung beberapa versi kode teknologi iklan. Dalam Bidding and Auction API, permintaan SelectAd dapat menentukan versi kode yang digunakan untuk permintaan lelang (yaitu untuk bidding / lelang dan juga pelaporan). |
| Penyimpanan Bersama | Mendukung penulisan ke Penyimpanan Bersama di Layanan Bidding dan Lelang. | Saat ini, Layanan Bidding dan Lelang tidak mendukung Penyimpanan Bersama, tetapi kami menerima masukan tambahan tentang mengapa kasus penggunaan semacam itu penting bagi ekosistem. |
| Web ke aplikasi | Mendukung berbagi web ke aplikasi grup minat. | Web ke aplikasi saat ini tidak tercakup dalam deployment Protected Audience API di Chrome dan Android, tetapi kami ingin mengetahui pentingnya kasus penggunaan ini dari ekosistem tersebut. |
| Anonimitas | Cara menangani penggantian K-Anonymity | Kami membahas masalah ini dan menantikan masukan tambahan. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Konfigurasi Laporan Tingkat Peristiwa VTC Alternatif | Masukan tentang konfigurasi laporan tingkat peristiwa VTC alternatif | Kami menerima beberapa masukan bahwa konfigurasi tingkat peristiwa saat ini tidak optimal dan kami meminta masukan tentang konfigurasi global yang optimal. Kami terbuka untuk menerima masukan tambahan terkait hal ini dan merasa bahwa penjelasan tingkat peristiwa yang fleksibel juga membantu mengatasi hal ini. |
| Konfigurasi tingkat peristiwa fleksibel | Apa status fitur konfigurasi tingkat peristiwa fleksibel? | Kami telah membagikan dokumentasi tentang konfigurasi tingkat peristiwa yang fleksibel. Fitur ini masih dalam tahap proposal dan kami mengharapkan masukan lebih lanjut terkait apakah fitur tersebut akan bermanfaat bagi ekosistem. |
| Konfigurasi tingkat peristiwa fleksibel | Bagaimana laporan yang bertentangan dari berbagai pihak dapat direkonsiliasi? | Sebagian besar skenario pelaporan ditangani melalui penggunaan laporan gabungan, sedangkan proposal konfigurasi tingkat peristiwa fleksibel ditujukan khusus untuk fleksibilitas tambahan bagi laporan tingkat peristiwa, yang paling sering digunakan untuk kasus penggunaan pengoptimalan. Kami siap menerima komentar/masukan ekosistem tambahan terkait skenario ini. |
| Pendaftaran sumber | Bagaimana jika pendaftaran sumber terjadi setelah pendaftaran pemicu? | Saat ini, jika pendaftaran sumber terjadi setelah pendaftaran pemicu, sumber dan pemicu tidak akan dapat diatribusikan satu sama lain. Tampaknya ini adalah skenario kasus ekstrem. Kami menerima masukan tambahan terkait masalah ini dan akan berupaya mengatasinya jika ini adalah skenario yang sering dihadapi banyak teknologi iklan. |
| Bekerja sama dengan beberapa Agensi Iklan | Bagaimana DSP dapat menggunakan Attribution Reporting API saat pengiklan bekerja sama dengan beberapa agensi iklan? | API ini mendukung pengalihan sehingga dapat digunakan bahkan saat pengiklan bekerja sama dengan beberapa agensi iklan. Selain itu, ada beberapa batasan yang diterapkan terkait pengalihan untuk memastikan bahwa API meningkatkan privasi. Kami juga telah mengidentifikasi potensi solusi menggunakan Shared Storage API untuk skenario tertentu yang telah dilaporkan oleh teknologi iklan. Kami menerima masukan tambahan terkait skenario ini dan akan terus melakukan iterasi berdasarkan masukan tersebut. |
| Batas Tujuan | Kasus penggunaan pemuatan ulang iklan secara otomatis dapat terpengaruh oleh adanya batas tujuan. | Kita telah mendiskusikan masalah ini dalam pertemuan WICG pada 1 Mei dan mencari masukan tentang batas yang wajar. Kami telah menambahkan ke Pelaporan Atribusi dengan penjelasan laporan tingkat peristiwa yang menyatakan bahwa browser dapat membatasi jumlah eTLD+1 `destination` yang diwakili oleh situs sumber. (Lihat permintaan pull). |
| Attribution Reporting dan Protected Audience | Bagaimana Attribution Reporting API dan Protected Audience Audience API bekerja sama? | Integrasi saat ini tersedia untuk Protected Audience API untuk kedua mode Attribution Reporting API (laporan tingkat peristiwa dan ringkasan). Kami telah membagikan informasi selengkapnya tentang integrasi Protected Audience API dan Attribution Reporting yang ditingkatkan pada 1 Juni. Anda dapat membacanya di sini. |
| Konfigurasi tingkat peristiwa fleksibel | Bagikan praktik terbaik untuk simulasi derau karena parameternya dapat dikonfigurasi. | Kami telah membagikan kode di GitHub yang dapat digunakan siapa saja untuk menilai perolehan informasi dan dampak derau untuk konfigurasi tingkat peristiwa fleksibel apa pun yang ingin diuji. Kami ingin mendengar masukan dari siapa saja yang memilih untuk menguji dengan kode ini dan ingin memberikan masukan. |
| Pengukuran Atribusi Lintas Aplikasi dan Web | Kapan pengukuran atribusi lintas aplikasi dan web akan tersedia? | Pada 9 Mei, kami mengumumkan eksperimen untuk Pengukuran Atribusi Lintas Aplikasi dan Web melalui Attribution Reporting API. Meskipun Ketersediaan Umum direncanakan untuk API pengukuran dan relevansi di Chrome 115, Pengukuran Atribusi Lintas Aplikasi dan Web saat ini tidak direncanakan untuk mencapai ketersediaan umum di Chrome 115. |
| Menghapus duplikat konversi | Bagaimana solusi pengukuran independen dapat direkonsiliasi dengan ARA? | Seperti praktik standar saat ini, pengiklan akan bekerja sama dengan penyedia pengukuran independen pihak ketiga untuk mencegah duplikasi pelaporan konversi. Kami telah menawarkan referensi tentang cara menghapus duplikat konversi untuk pelaporan tingkat peristiwa. |
| Kehilangan data selama pembaruan database Attribution Reporting | Apakah akan ada kehilangan data saat Chrome mengupdate Database Pelaporan Atribusi seperti yang diumumkan? | Mulai Chrome Stabil 115, kami akan mulai mengaktifkan API Relevansi dan Pengukuran untuk sebagian pengguna Chrome secara default. Ketersediaan umum ini akan meningkat seiring kami memantau potensi masalah. Target kami adalah mencapai ketersediaan 100% selama beberapa minggu, paling lambat pada Q3 2023. Tanggal ini akan bertepatan dengan akhir uji coba origin Relevansi dan Pengukuran. Mulai bulan Juli, penguji akan dapat mendaftar untuk mengakses API ini secara umum. Hal ini akan menimbulkan tumpang tindih antara ketersediaan uji coba origin dan ketersediaan umum melalui pendaftaran. Token uji coba origin Anda akan berlaku hingga 19 September, tetapi sebaiknya Anda mendaftar ke API sebelum masa berlakunya habis agar dapat bertransisi dengan lancar dari uji coba origin tanpa mengganggu pengujian yang sedang berlangsung. Seperti yang disebutkan dalam pengumuman ini, data yang didaftarkan dari versi lama (M113 dan yang lebih lama) tidak akan dimigrasikan setelah update, sehingga mungkin ada data yang hilang. Kehilangan data ini tidak akan muncul di pelaporan debug, dan kami akan mencoba menghindari kehilangan data dari versi 114 hingga 115. |
| Penagihan | Menggunakan Attribution Reporting untuk penagihan biaya per konversi | Seperti yang dinyatakan dalam artikel ini, Attribution Reporting API mungkin tidak sesuai untuk kebutuhan penagihan biaya per konversi karena derau yang ditambahkan ke laporan tingkat peristiwa dan ringkasan. Kami mendorong pemain ekosistem untuk memberikan masukan tentang dampak terhadap berbagai model penagihan oleh Attribution Reporting API di GitHub. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Perubahan penundaan laporan gabungan | Reaksi positif terhadap proposal untuk mengubah penundaan laporan agregat dari [10-60 menit] menjadi [0-10 menit] setelah masukan dari ekosistem | Kami senang melihat reaksi positif terhadap perubahan yang diusulkan, dan mendorong ekosistem untuk terus memberikan masukan terhadap proposal kami. |
| Solusi lokal | Dapatkah Layanan Agregasi diterapkan di pusat data lokal? | Meskipun kami sedang menjajaki kemungkinan opsi yang mendukung di luar solusi berbasis cloud, saat ini kami belum dapat mendukung TEE lokal karena adanya batasan keamanan lokal yang akan memerlukan evaluasi yang memakan waktu lama untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya mendukung GCP selain AWS) adalah upaya yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan pentingnya persyaratan tersebut. |
| Memproses ulang laporan untuk jangka waktu yang berbeda | Kemampuan untuk memproses ulang laporan untuk jangka waktu yang berbeda | Kami telah mendengar permintaan serupa agar dapat membagi batch untuk rentang tanggal yang berbeda. Salah satu proposal adalah memberikan kemampuan untuk memperluas ID bersama dengan label yang ditentukan oleh teknologi iklan, sehingga laporan dapat dibagi menjadi beberapa kelompok yang berbeda. Kami sedang dalam proses awal mengevaluasi proses ini dan akan terus memperbarui ekosistem saat proposal ini berkembang. |
| Implikasi Privasi dari Trusted Execution Environment | Sentimen positif terhadap implikasi privasi Trusted Execution Environment | Kami senang mendengar reaksi positif dari ekosistem terkait proposal kami, dan kami menerima masukan tambahan seiring upaya kami untuk terus melakukan iterasi dan pengembangan. |
| Persyaratan Layanan | Kapan batas waktu untuk menyetujui persyaratan layanan Layanan Agregasi? | Meskipun kami belum menentukan batas waktu untuk menyetujui persyaratan dan ketentuan, kami mendorong perusahaan ekosistem untuk menyetujui persyaratan dan ketentuan sesegera mungkin untuk mencegah penundaan pendaftaran. Sebaiknya perusahaan menghubungi Anda jika ada pertanyaan. |
| Penemuan Kunci | Fitur penemuan utama akan memungkinkan penguji membuat kueri laporan gabungan tanpa memerlukan daftar eksplisit kemungkinan kombinasi tombol guna memproses laporan ringkasan untuk atribusi lintas jaringan guna meningkatkan performa dan akurasi. | Saat ini kami sedang mempelajari kemungkinan solusi dan solusi serta menerima masukan tambahan dari ekosistem. |
Private Aggregation API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Asal Pelaporan | Bagaimana asal pelaporan ditentukan? | Asal pelaporan selalu merupakan asal skrip pemanggil Agregasi Pribadi. |
| Spasi kunci 128 bit | Kejelasan tentang batasan ruang kunci 128-bit | Kami akan membuat batasan keyspace ini lebih jelas dan mengatasi inkonsistensi di seluruh halaman. Sebaiknya gunakan strategi {i>hashing<i} agar tetap berada dalam keyspace ini. |
| Kontribusi maksimum per laporan | Batas saat ini sebanyak 20 kontribusi per laporan terlalu rendah. | Daripada meningkatkan jumlah maksimum kontribusi, kami terbuka untuk mempertimbangkan pemisahan laporan, bukan memotongnya pada batas. Kami akan melibatkan ekosistem saat proposal ini berkembang. |
| Pelaporan jangkauan | Permintaan untuk pelaporan jangkauan lintas platform/lintas perangkat. Jangkauan adalah metrik dasar iklan brand. Pengiklan mengandalkan perkiraan lintas platform/lintas perangkat untuk pelaporan Jangkauan dan Frekuensi guna menganalisis kampanye dan mengalokasikan pembelanjaan. Model jangkauan menggunakan cookie pihak ketiga sebagai sinyal untuk mengukur iklan yang ditampilkan di lingkungan pihak ketiga, sehingga teknologi iklan meminta solusi alternatif setelah cookie pihak ketiga tidak digunakan lagi. |
Tim Privacy Sandbox sedang mempelajari berbagai fitur untuk mendukung metodologi jangkauan lintas-domain setelah cookie pihak ketiga tidak digunakan lagi. Kami menantikan masukan tambahan dari ekosistem. |
Batasi Pelacakan Terselubung
Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada K1 2023) Petunjuk untuk faktor bentuk tambahan | Permintaan Petunjuk Klien Agen Pengguna (UA-CH) untuk menyediakan faktor bentuk tambahan seperti TV, VR | Kami masih mengerjakan beberapa keputusan desain utama (apakah akan memberikan nilai tunggal seperti "TV", atau daftar kemampuan faktor bentuk), tetapi tetap tertarik untuk membuat prototipe ide ini. |
| Anggaran Privasi | Batasan Anggaran Privasi dapat menyebabkan permintaan UA-CH menjadi tidak menentukan jika terlalu banyak permintaan yang dikirim. | Saat ini, kami tidak memiliki pembaruan baru terkait proposal Anggaran Privasi, tetapi kami telah berkomitmen untuk tidak membatasi permintaan petunjuk klien UA sebelum cookie pihak ketiga tidak digunakan lagi. |
| Kompatibilitas Situs | Situs menggunakan merek UA-CH untuk membatasi browser tertentu agar tidak mengakses situs. | Ada kasus penggunaan yang valid untuk memiliki daftar merek, dan salah satunya adalah kompatibilitas. UA dapat bekerja sama dengan beberapa brand untuk mengatasi masalah ini. |
Perlindungan IP (sebelumnya Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penipuan & Pelanggaran | Bagaimana perusahaan dapat menyiapkan tindakan antipenipuan dengan Perlindungan IP? | Kami memahami pentingnya kasus penggunaan antipenipuan dan kemungkinan dampaknya terhadap kasus penggunaan tersebut. Kami berencana untuk memublikasikan detail selengkapnya tentang mendukung antipenipuan nanti pada musim panas ini. Kami meminta masukan ekosistem tentang cara mendukung kasus penggunaan antipenipuan dengan lebih baik. |
| GeoIP | Informasi selengkapnya tentang jadwal pengujian dan deployment untuk GeoIP | Chrome baru-baru ini memublikasikan informasi baru yang menjelaskan paket GeoIP kami. Kami berencana untuk memublikasikan informasi selengkapnya tentang linimasa deployment pada Q3. Kami berharap dapat meluncurkan Perlindungan IP sebagai fitur keikutsertaan pengguna pada sebagian kecil traffic pada awalnya. Alasannya adalah karena kami menyadari bahwa proposal ini mungkin melibatkan beberapa perubahan signifikan bagi perusahaan, dan kami ingin memberikan waktu kepada ekosistem untuk menyesuaikan dan memberikan masukan sebelum fitur ini diluncurkan secara lebih luas. |
| Autentikasi akun | Bagaimana cara kerja otentikasi akun dengan server {i>proxy<i}? | Kami berencana untuk memublikasikan detail selengkapnya tentang autentikasi akun nanti pada musim panas ini, meskipun kami telah menyampaikan beberapa pertimbangan awal. |
Mitigasi Pelacakan Kembali
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Panduan Pengujian | Informasi tentang cara menguji mitigasi Pelacakan Pantulan | Kami memublikasikan postingan blog pada bulan Mei yang berisi informasi lebih lanjut tentang cara menguji Mitigasi Pelacakan Kembali. |
| Dokumentasi | Kejelasan dalam Proposal Pelacakan Pantulan | Proposal saat ini masih dalam proses pengembangan dan Chrome terus memperbarui proposal untuk memberikan kejelasan dan informasi pada ekosistem. Kami sedang berupaya memberikan detail selengkapnya dan menerima masukan tambahan. |
| Penghapusan cookie | Apakah Mitigasi Pelacakan Kembali akan menghapus semua cookie di domain? | Mitigasi pelacakan kembali (BTM) akan menghapus semua penyimpanan dan semua cache, seperti yang dijelaskan di sini. |
| Menghindari Mitigasi Pelacakan Kembali | Klasifikasi pelacak pantulan dapat diabaikan dengan melakukan pengalihan dengan pop-up atau tab baru. | Spesifikasi Mitigasi Pelacakan Kembali masih dalam proses. Sejauh ini kami berfokus pada pengalihan tab yang sama, tetapi kami berencana untuk mengerjakan alur pop-up pada masa mendatang. Kami menyambut baik masukan tambahan di sini. |
Anggaran Privasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penargetan Kedekatan | Anggaran Privasi dapat memengaruhi kasus penggunaan penargetan kedekatan. | Kami telah menerima masukan terkait masalah ini dan ingin mengetahui lebih lanjut dampak potensial dari ekosistem ini. |
Memperkuat batasan privasi lintas situs
Set Pihak Pertama
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada kuartal sebelumnya) Batas Domain | Permintaan untuk memperluas jumlah domain terkait | Chrome sedang mengevaluasi batas numerik yang sesuai untuk subset Terkait yang akan menyeimbangkan privasi dan utilitas untuk kasus penggunaan yang telah diidentifikasi. Sejak awal, Chrome menyampaikan bahwa jumlah pasti untuk subset Terkait belum diselesaikan. |
| Kasus Penggunaan yang Disematkan | Dukungan untuk Kasus penggunaan Tersemat yang memerlukan Set Pihak Pertama, CHIP, dan penyimpanan bersama | Chrome telah menerima masukan terkait kasus penggunaan ini, dan tim sedang menyelidikinya serta menerima masukan tambahan. |
| Pengelolaan Repositori | Informasi tentang kebijakan untuk menghapus Set Pihak Pertama dari repositori GitHub jika ada perbedaan atau kelalaian | Chrome telah menerima masukan terkait kasus penggunaan ini. Tim kami sedang menyelidiki dan menerima masukan tambahan. |
| Pendidikan Pengguna | Chrome harus meningkatkan awareness dan pemahaman pengguna tentang Set Pihak Pertama untuk mendorong adopsi. | Chrome berkomitmen untuk mengedukasi pengguna tentang Set Pihak Pertama, dan telah memublikasikan artikel Pusat Bantuan (ditautkan dari UI Chrome) untuk mendukung hal ini. Chrome juga berinvestasi untuk terus mempelajari cara terbaik mengedukasi pengguna dalam konteks yang sesuai. |
| Posting 3PCD | Cookie pihak ketiga akan terus ada dalam Set Pihak Pertama setelah cookie pihak ketiga tidak digunakan lagi. | Meskipun requestStorageAccess dan requestStorageAccessFor memang membuat cookie pihak ketiga tersedia lagi untuk kasus penggunaan tertentu yang didefinisikan dengan jelas, cookie tersebut kini memerlukan panggilan aktif oleh situs, bukan tersedia secara default, seperti dengan status cookie pihak ketiga saat ini (di Chrome).Meskipun panggilan dalam satu kumpulan ini tidak memerlukan persetujuan pengguna, pengguna dapat mencegahnya dengan memilih tidak ikut perilaku ini di Setelan. Informasi selengkapnya tersedia bagi pengguna di artikel Pusat Bantuan (ditautkan dari UI Chrome). Kami berencana untuk memperluas panduan developer yang sudah ada saat FPS ditingkatkan hingga 100%. |
| Pengiriman Set Pihak Pertama | Ganti nama .well-known/first-party-set yang diperlukan untuk menyertakan ekstensi .json. |
Kami telah melakukan perubahan ini untuk memastikan paket hosting web tertentu didukung. |
| Pendaftaran IANA | first_party_sets.JSON harus terdaftar di IANA |
Kami sedang mempertimbangkan proposal ini dan menerima masukan tambahan di sini. |
Fenced Frames API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pemblokiran Iklan | Bingkai Berpagar dapat memudahkan pemblokir iklan memblokir iklan. | Ekstensi dapat berinteraksi dengan frame dengan fence mirip dengan cara interaksinya dengan iframe. URL sebenarnya yang akan dibuka oleh frame dengan fence juga dapat dilihat oleh ekstensi, sehingga ekstensi dapat menerapkan aturan pencocokan URL apa pun untuk pemblokiran seperti yang dilakukan di iframe. Hanya memblokir semua frame dengan fence tanpa syarat dapat merusak kasus penggunaan non-iklan dari frame dengan fence. |
Shared Storage API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Adopsi yang lebih luas | Penyimpanan Bersama harus menjadi standar tingkat industri yang tersedia di seluruh browser. | Kami menerima dan menerima masukan ini. Chrome terus berpartisipasi secara aktif dalam forum W3C untuk memperjuangkan proposal, mencari masukan, dan mendorong penggunaan. |
| Gerbang Output | Gateway output Storage Bersama terlalu terbatas. | Kami mempertimbangkan masukan ini dan menantikan masukan ekosistem tambahan terkait alasan gateway output terlalu terbatas. |
| Kepatuhan terhadap Peraturan | Bagaimana Penyimpanan Bersama menangani kepatuhan terhadap peraturan seperti kebijakan retensi data? | Penyimpanan Bersama memberikan fleksibilitas untuk menerapkan dan menyesuaikan logika guna mengontrol masa berlaku dan masa berlaku data yang disimpan. Teknologi iklan dapat memperbarui atau menghapus data Penyimpanan Bersama berdasarkan stempel waktu penulisan. |
| Pengujian A/B | Bagaimana pengujian A/B untuk Shared Storage dan Protected Audience API dilakukan? | Kami sedang berupaya untuk memublikasikan panduan tambahan terkait masalah ini dan berharap dapat membagikan detail selengkapnya di masa mendatang. |
| Batas Penyimpanan Bersama | Apa yang akan terjadi setelah batas Penyimpanan Bersama tercapai? | Jika batas ini tercapai, tidak ada input lebih lanjut yang akan disimpan. |
| Multi-akses pada pemuatan halaman yang sama | Apa yang terjadi jika Penyimpanan Bersama diakses beberapa kali pada pemuatan halaman yang sama? | Cara terbaik untuk menangani hal ini adalah melalui fungsi window.sharedStorage.append(key, value). Daripada memperbarui nilai untuk setiap iklan, yang dapat menyebabkan konflik jika ada beberapa iklan. Fungsi add hanya akan menambahkan nilai baru ke bagian akhir yang sudah ada. |
| Fungsi iframe | Apakah Penyimpanan Bersama mendukung fungsi iframe tertentu setelah cookie pihak ketiga tidak lagi berfungsi? | Setelah cookie pihak ketiga tidak digunakan lagi, penyimpanan lokal di iframe akan dipartisi oleh situs tingkat atas, tetapi iframe itu sendiri tidak akan diblokir. Data dalam penyimpanan lokal iframe tidak dapat direplikasi ke beberapa situs tingkat atas, namun penyimpanan lokal masih dapat digunakan dalam iframe. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Batas partisi | 10 KiB per situs yang dipartisi masih besar dan saya ingin menurunkannya. | Firefox telah menunjukkan posisi yang positif di CHIPS. Untuk dukungan Webkit, sebaiknya developer memberikan masukan ke Apple langsung di masalah GitHub ini terkait kasus penggunaan mereka yang lebih memilih cookie yang dipartisi daripada penyimpanan yang dipartisi. |
| Penyematan yang diautentikasi | CHIP dapat memengaruhi alur login SSO saat ini karena adanya partisi yang berbeda yang memengaruhi sematan yang diautentikasi. | Kami bermaksud memanfaatkan Storage Access API (dengan perintah pengguna) untuk mendukung kasus penggunaan sematan yang diautentikasi, dan baru-baru ini mengirim intent-ke-prototipe. |
| Kebijakan Sepanjang Waktu | Apakah potensi kebijakan sepanjang waktu akan berlaku untuk cookie pihak pertama? | Saat ini, kami tidak berencana untuk menerapkan batas sepanjang waktu pada cookie pihak pertama. |
FedCM
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Dukungan Otorisasi OAuth | Menyelaraskan otorisasi cakupan Oauth non-profil | Kami secara aktif mencari masukan dari komunitas Web Identity melalui W3C FedID CG terkait cara terbaik untuk mendukung otorisasi di luar autentikasi dasar setelah cookie pihak ketiga tidak digunakan lagi. |
| Dukungan untuk SAML | Selaraskan persyaratan untuk dukungan SAML | Tim secara aktif mencari masukan dari komunitas riset dan edukasi tentang kebutuhan dukungan SAML (selain dukungan OpenID-connect) setelah penghentian cookie pihak ketiga. |
Mencegah spam dan penipuan
Private State Token API (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Mempelajari sinyal baru | Beberapa partner telah menyatakan sentimen positif terhadap pembahasan sinyal integritas perangkat atau kepercayaan pengguna yang difasilitasi browser. Secara umum, mereka juga berhati-hati tentang sinyal baru yang dibuat untuk tujuan tertentu, yang memadai untuk mempertahankan tingkat deteksi penipuan saat ini. | Kami sangat antusias untuk mengeksplorasi berbagai proposal baru bersama-sama dalam komunitas antipenipuan dan keamanan web, serta memahami dan menyampaikan kekhawatiran mereka - inilah alasan "melawan spam dan penipuan" telah menjadi fungsi inti Privacy Sandbox dan alasan kami terus memprioritaskan investasi dalam menjaga keamanan web seiring upaya kami meningkatkan privasi pengguna. |
| Masukan positif terkait PST | Beberapa partner telah menyatakan minatnya dalam menguji atau menggunakan PST untuk berbagai kasus penggunaan keamanan web atau antipenipuan. | Kami sangat antusias mendengar dukungan dan minat untuk mempelajari lebih lanjut solusi baru yang memanfaatkan PST. Kami memiliki referensi dan kode contoh yang tersedia melalui situs developer Chrome, dan kami menantikan masukan lebih lanjut. |
| Penipuan dan Penyalahgunaan | Panduan untuk Pencegahan Penipuan Iklan / Deteksi dalam pengukuran setelah cookie pihak ketiga tidak digunakan lagi saat ID tidak lagi tersedia. | Kami telah memperkenalkan alat seperti token status pribadi, yang membantu memulihkan beberapa sinyal yang hilang oleh cookie pihak ketiga untuk tujuan antipenipuan, tetapi dengan kontrol privasi baru. Kami secara aktif berinvestasi dalam proposal antipenipuan dan anti-penyalahgunaan baru untuk mempertahankan kemampuan dengan perubahan Privacy Sandbox lainnya. |
| Rasio informasi penerbit ke origin | Rasio informasi penerbit ke asal cukup tinggi untuk mengidentifikasi pengguna unik. | Kami telah memperbarui spesifikasi agar lebih jelas tentang data pengguna apa yang dapat disampaikan menggunakan Token Status Pribadi. Secara desain, hingga enam kunci publik dapat digunakan pada satu waktu, yang dapat mewakili sebuah "keadaan" untuk pengguna tertentu. Kumpulan kunci ini hanya dapat diperbarui setiap 60 hari (kecuali dalam kasus yang jarang terjadi ketika rotasi kunci darurat diperlukan), yang memperlambat potensi untuk menggabungkan data pengguna tambahan dari waktu ke waktu. Dengan API web baru, aplikasi ini menyediakan utilitas dan informasi pengguna baru yang seimbang. Kami memperkirakan bahwa PST mencapai keseimbangan yang sesuai dalam melindungi privasi pengguna sekaligus memungkinkan kasus penggunaan antipenipuan utama yang terdampak oleh penghentian penggunaan cookie pihak ketiga. |
| Ambil Integrasi | Integrasi fetch rumit dan tidak perlu. |
Ada pro dan kontra dalam menggunakan fetch, dan kami ingin mengejar standardisasi lebih lanjut dalam ekosistem web, tetapi menurut kami masih terlalu dini untuk melakukan perubahan ini sampai kami memiliki gambaran yang lebih jelas tentang seperti apa standar tersebut nantinya. Jika dan ketika standar muncul, kami juga berkomitmen untuk mengalihkan developer web secara bertanggung jawab ke standar tersebut. |
| Lokasi Penyimpanan | Konfigurasi kunci Token Status Pribadi harus disimpan di lokasi yang sama dengan PrivacyPass Protocol. | Saat melakukan pengujian selama Uji Coba Origin, developer menyatakan bahwa mereka lebih menyukai fleksibilitas untuk menyimpan kunci mereka di URL umum, bukan di direktori .well-known. Format komitmen utama di PrivacyPass tidak terlalu cocok untuk versi dengan keyset yang dimaksudkan untuk memungkinkan "metadata publik" implisit dengan sejumlah nilai. Jika salah satu varian PrivacyPass akhirnya distandardisasi dengan metadata publik (baik sebagai POPRF, blinding RSA parsial, atau keyset), kami mungkin akan beralih ke versi PST mendatang untuk mendukungnya. |
| Implementasi header API | Pertanyaan terkait implementasi header API | Seiring API ini distandardisasi dan penggunaan ekosistem API ini semakin matang, diharapkan kami dapat mendukung versi non-header standar API ini dan berpotensi menghentikan penggunaan versi header jika penggunaannya cukup rendah atau terdapat alat/dukungan developer yang cukup untuk cara standar menghubungkan permintaan penerbitan/penukaran dengan data lainnya. Kami membahas masalah tersebut di sini. |
| Pendaftaran | Apakah membuat penerbit mendaftar ke vendor browser bersifat praktis? | Kami telah memperbarui spesifikasi untuk menjelaskan proses pendaftaran penerbit untuk Token Status Pribadi. Meskipun menggunakan prosesnya sendiri, cara ini mirip dengan rencana pendaftaran untuk seluruh pekerjaan Privacy Sandbox, di mana kami meminta penerbit untuk membuat pernyataan publik tentang bagaimana mereka akan menggunakan PST dan untuk mengonfirmasi batasan teknis yang melindungi privasi pengguna. |