Laporan Masukan - Kuartal 2 2023

Laporan kuartalan untuk K2 2023 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, Protected Audience, dan Attribution Reporting API.

Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum mendapatkan respons Chrome yang dipertimbangkan.

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

Tema Masukan Ringkasan Respons Chrome
Tata Kelola Data & Kepatuhan terhadap Peraturan Panduan ekosistem tentang penggunaan Privacy Sandbox sesuai dengan persyaratan peraturan. Seperti halnya teknologi baru lainnya, setiap perusahaan bertanggung jawab untuk memastikan bahwa penggunaan Privacy Sandbox-nya mematuhi hukum; Google tidak dapat memberikan saran hukum kepada pihak lain. Namun, kami menyadari bahwa ini adalah area utama yang menarik bagi ekosistem. Untuk setiap API, kami telah memublikasikan dokumentasi teknis yang ekstensif, yang akan memberikan dasar untuk melakukan penilaian hukum yang diperlukan, dan kami sedang berupaya menyediakan materi tambahan untuk mendukung upaya perusahaan dalam mematuhi persyaratan peraturan.
Proposal Pengujian Kuantitatif CMA Informasi selengkapnya tentang proposal pengujian kuantitatif CMA Kami bekerja sama dengan CMA untuk mendesain eksperimen yang akan memberikan gambaran tentang dampak penghentian penggunaan cookie pihak ketiga dan pengenalan proposal Privacy Sandbox pada ekosistem. Pada bulan April, CMA memublikasikan panduan umum tentang hal-hal yang akan terjadi selama periode Pengujian dan Uji Coba, diikuti dengan panduan mendetail pada bulan Juni. Sebaiknya bagikan pertanyaan atau masukan tentang proposal Pengujian Kuantitatif CMA langsung kepada CMA.
Mode pengujian yang difasilitasi Chrome Informasi selengkapnya dan klarifikasi tentang jadwal pengujian Kami memublikasikan postingan blog pada 18 Mei yang membagikan informasi selengkapnya tentang dua mode pengujian yang difasilitasi Chrome. Detail ini belum final, dan kami akan memublikasikan panduan penerapan lebih lanjut seiring progres kami pada Kuartal 3 tahun 2023.
Penyimpanan yang Dipartisi Apakah penyimpanan yang dipartisi akan digunakan selama pengujian yang difasilitasi Chrome? Partisi penyimpanan akan dikirim ke semua pengguna sebelum eksperimen penghentian cookie pihak ketiga. Oleh karena itu, fitur ini akan diaktifkan untuk semua grup eksperimen. Situs akan memiliki opsi untuk mengaktifkan uji coba penghentian penggunaan guna mendapatkan kembali penyimpanan yang tidak dipartisi selama jangka waktu ini.
Dukungan produksi Apa proses yang diterapkan untuk Chrome guna mendukung masalah teknis dan eskalasi Privacy Sandbox yang memengaruhi ekosistem? Google menyediakan berbagai saluran untuk memungkinkan teknologi iklan melaporkan masalah dan melakukan eskalasi yang diperlukan.
Lihat ringkasan masukan kami untuk mengetahui informasi selengkapnya tentang forum publik dan pribadi untuk masukan dan eskalasi.
Linimasa Pendaftaran Jangka waktu pendaftaran saat ini terlalu singkat Kami masih mengevaluasi batas waktu penerapan dan ingin mendengar dari ekosistem tentang linimasa yang lebih sesuai.
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 DUNS di situs Dun and Bradstreet. Persyaratan bervariasi bergantung pada pasar, jadi peserta harus memastikan untuk memeriksa situs untuk pasar tertentu yang mereka minati. Namun, secara umum, peserta harus memberikan informasi dasar tentang bisnis mereka, seperti nama bisnis, alamat, dan informasi kontak untuk pemilik atau pengelola bisnis. Peserta juga mungkin 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 Juli, penguji akan dapat mengakses API relevansi dan pengukuran dalam ketersediaan umum. Hal ini akan memberikan tumpang-tindih antara ketersediaan uji coba origin dan ketersediaan umum.
Studi AdExchanger Informasi selengkapnya tentang metodologi survei Survei ini meminta responden untuk memperkirakan rasio sinkronisasi dan pendapatan untuk bisnis mereka. Metodologi responden untuk menjawab pertanyaan masing-masing adalah pilihan mereka.
Parameter value Bagaimana nilai parameter seperti tingkat derau, nilai minimum anonimitas, dan anggaran privasi ditentukan? Penjelasan GitHub ini menetapkan prinsip yang lebih umum di balik Privacy Sandbox API. Banyak nilai yang masih dalam proses penyelesaian dan kami mengharapkan masukan tentang hal ini.

Menampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan Ringkasan Respons Chrome
Perlindungan Privasi Riset yang mengevaluasi Topics API terkait perlindungan privasi Kami secara aktif terlibat dengan komunitas riset, dengan mempresentasikan riset kami tentang properti privasi Topics API dalam makalah, laporan, dan presentasi workshop. Kami senang melihat lebih banyak anggota eksternal komunitas riset yang berinteraksi dengan area ini.

Topics API melindungi pengguna dari pelacakan umum di web dengan mempersulit pelacakan pengguna dalam skala besar. Makalah ini menunjukkan bahwa kami berhasil melakukannya dengan Topics API. Cookie ini lebih bersifat pribadi daripada cookie pihak ketiga dan melindungi pengguna sekaligus mendukung situs yang mereka sukai.
Taksonomi topik tidak cukup terperinci Taksonomi topik 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 dan menggabungkan banyak peningkatan berdasarkan masukan dari ekosistem. Sebagai bagian dari pekerjaan kami terkait taksonomi yang direvisi, kami telah bekerja sama dengan beberapa perusahaan di seluruh ekosistem, seperti Raptive (sebelumnya bernama CafeMedia) dan Criteo. Taksonomi yang diperbarui menghapus kategori yang menurut kami kurang berguna, dan diganti dengan 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 tentang perubahan tersebut.
Proses pembaruan taksonomi dan pengklasifikasi Informasi selengkapnya tentang taksonomi Topics dan ritme rilis pengklasifikasi serta cara perusahaan dapat mempersiapkan pembaruan tersebut. Seperti yang disampaikan dalam postingan blog terbaru, kami memperkirakan taksonomi akan berkembang seiring waktu, dan tata kelola taksonomi pada akhirnya akan bertransisi ke pihak eksternal yang mewakili pemangku kepentingan dari seluruh industri. Kami juga membagikan rencana peningkatan kapasitas di grup topics-announce.
Dampak pada sinyal pihak pertama Peningkatan jumlah Topik dalam pembaruan Taksonomi terbaru mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. Dalam laporan K1 2023, CMA berkomentar bahwa "Kami memahami bahwa Google telah membahas taksonomi baru yang diusulkannya dengan beberapa peserta pasar di seluruh rantai pasokan teknologi iklan. Meskipun beberapa penayang 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, terutama untuk kemampuan penayang yang lebih kecil untuk terus memonetisasi inventaris mereka setelah penghentian cookie pihak ketiga". Pandangan kami selaras dengan komentar yang dibuat oleh CMA ini.
Kegunaan 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 mendesain dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan memberikan preferensi sendiri pada bisnis Google, dan untuk mempertimbangkan dampak pada persaingan dalam periklanan digital serta pada penayang dan pengiklan, terlepas dari ukurannya. 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. Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA dalam memublikasikan catatan tentang desain eksperimen untuk memberikan informasi lebih lanjut kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan."
Topik Turunan Dengan kriteria pemilihan Topik adalah frekuensi kunjungan browser, apakah fragmentasi segmen akan menyebabkan topik turunan tidak pernah naik ke posisi teratas? Chrome saat ini mengevaluasi metodologi peringkat lainnya, dan mempelajari sinyal lain yang dapat meningkatkan peringkat. Kami akan menyampaikan rencana yang telah direvisi kepada ekosistem pada waktunya.
Sensitivitas Sasaran Topics API adalah untuk memastikan informasi pengguna yang diperoleh atau berasal dari Topics API harus kurang sensitif secara pribadi daripada yang dapat diperoleh menggunakan metode pelacakan saat ini. Kami yakin bahwa Topics API jauh lebih pribadi daripada teknologi saat ini, secara signifikan membatasi identifikasi ulang pengguna, dan dirancang untuk mengecualikan topik sensitif. Kami memahami bahwa topik dapat dikorelasikan atau digabungkan dengan data pihak pertama untuk membuat kategori sensitif, tetapi kami yakin bahwa Topics API adalah langkah maju untuk privasi pengguna dan kami berkomitmen untuk terus meningkatkan API ini.
Struktur Taksonomi Menambahkan ID, Pembuatan Versi, dan struktur metadata lainnya ke Taksonomi Topik Saat ini, dalam respons API, kami menyertakan ID taksonomi. Seiring dengan peralihan kami ke tata kelola jangka panjang, sebaiknya tinjau objek Topics dan sertakan metadata tambahan tentang pembuatan versi jika diperlukan.
Kontrol penayang Penerbit harus memiliki suara dalam menentukan Topik yang harus diklasifikasikan untuk situs mereka. Kesalahan klasifikasi situs dapat membuat sinyal Topik sedikit kurang berguna sebagai sinyal secara keseluruhan, tetapi situs tertentu yang salah diklasifikasikan tidak lebih atau kurang dirugikan oleh hal ini dibandingkan situs lainnya. Hal ini karena informasi kontekstual situs akan selalu tersedia untuk lelang di situsnya, yang akan memberikan informasi yang sebanding dengan topik yang benar, bahkan jika terjadi kesalahan klasifikasi. Kami menerima masukan tentang subjek ini di sini.

Mengizinkan penayang mengontrol klasifikasi mereka memiliki risiko. Situs mungkin secara tidak sengaja mengklasifikasikan situsnya, sehingga mengurangi utilitas untuk semua orang, atau mengenkode makna sensitif dalam topik yang kurang umum, sehingga membahayakan privasi pengguna.
Ekstensi Chrome Mengizinkan Ekstensi Chrome mengelola dan memfilter Topik, mirip dengan ekstensi Pengelolaan Cookie saat ini Hal ini seharusnya sudah dapat dilakukan, seperti yang dibahas di GitHub, tetapi kami menerima masukan tambahan dari ekosistem.
Transisi ke Ketersediaan Umum Apakah akan ada dampak pada Topics API saat bertransisi dari Uji Coba Origin ke Ketersediaan Umum? Data pengguna yang bertransisi dari Uji Coba Origin ke Ketersediaan Umum tidak akan hilang.
Privasi Nama Host dapat berisi informasi pribadi yang dapat diungkapkan oleh Topics API Kami memiliki sejumlah mitigasi untuk memastikan privasi, seperti yang diuraikan di sini.
Penipuan dan Penyalahgunaan Cara mencegah manipulasi Topik oleh kunjungan yang menipu Mitigasi dijelaskan di sini.
Pengklasifikasi topik Dapatkah situs meminta untuk mengubah klasifikasi Topiknya? Kami ingin mendengar pendapat dari ekosistem tentang topik ini dan menyambut masukan di sini.
Situs penyedia Topics Tetapkan situs tertentu yang menghosting konten untuk banyak Topik sebagai "Situs Penyedia Topik Khusus" dan latih pengklasifikasi berdasarkan tag yang diberikan di halaman web. Kami mendiskusikan proposal ini di sini, dan menerima masukan tambahan.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan Ringkasan Respons Chrome
Pembentukan Traffic Dampak performa pemfilteran berbasis SSP untuk mengoptimalkan beban kueri per detik (QPS) Kami telah menghabiskan banyak waktu untuk memikirkan pembentukan traffic dan rekomendasinya adalah agar SSP memanfaatkan penyimpanan dalam cache.
Menguji volume Sulit untuk menguji Protected Audience karena SSP dan DSP kesulitan mendapatkan volume traffic yang besar. Kami terus melibatkan partner SSP dan DSP untuk mengadopsi dan menguji Protected Audiences. Ketersediaan Umum telah dimulai dan kami yakin bahwa persentase traffic dengan PA yang diaktifkan akan membuat pengujian menjadi lebih mudah bagi partner.
Kompleksitas Mengimplementasikan solusi Protected Audience memerlukan upaya dan biaya yang cukup besar. Kami memahami bahwa teknologi baru sulit diadopsi, termasuk Privacy Sandbox. Tim Privacy Sandbox bekerja sama erat dengan berbagai pemangku kepentingan untuk mengedukasi dan mendukung upaya mereka, serta terus mengevaluasi akselerator lain untuk mendukung penerapan ekosistem.
Trusted Execution Environment Dukungan untuk Trusted Execution Environment (TEE) di lingkungan cloud non-publik Meskipun kami sedang mempelajari opsi yang berpotensi mendukung di luar solusi berbasis cloud, saat ini tidak memungkinkan untuk mendukung TEE on-premise mengingat batasan keamanan on-premise yang akan memerlukan evaluasi yang memakan waktu untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang ditimbulkan oleh deployment lokal, kami yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung GCP selain AWS) adalah hal yang paling bermanfaat bagi ekosistem. Namun, kami menyambut masukan tambahan tentang alasan persyaratan tersebut diperlukan.
Struktur Biaya Proposal Layanan Bidding & Lelang akan meningkatkan biaya dan kompleksitas untuk Teknologi Iklan dibandingkan dengan model sisi klien. Saat ini kami sedang mengembangkan panduan untuk memperkirakan biaya dukungan alur kerja bidding dan lelang di server Bidding & Lelang, yang akan berkorelasi dengan penggunaan teknologi iklan, sehingga memenuhi salah satu sasaran desain kami.
Linimasa K-Anon Kapan batasan k-anonymity yang direncanakan akan diterapkan di `renderUrl` ? Kami sedang menyiapkan penjelasan tentang linimasa penegakan kebijakan yang akan segera kami rilis.
Batasan runAdAuction Dapatkah Chrome membatasi runAdAuction agar hanya dapat dipanggil dari halaman atas? Meskipun desain kami sepenuhnya mendukung runAdAuction untuk dapat dipanggil dari halaman teratas, kami yakin akan lebih berbahaya bagi penayang jika membatasinya agar hanya dapat dipanggil dari domain teratas.

Kami telah mendengar secara khusus 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 menentukan cara kerja penayang dan teknologi iklan.

Dengan mengizinkan penayang memilih cara dan siapa yang memanggil runAdAuction di situs mereka, kami yakin kami menawarkan fleksibilitas kepada penayang untuk menemukan jalur terbaik bagi persyaratan mereka.
Dukungan penerapan Dapatkah Chrome mem-build atau berkontribusi pada implementasi open source lelang multi-penjual? Privacy Sandbox bertujuan untuk mengembangkan teknologi yang menjaga privasi dan tidak bergantung pada cookie pihak ketiga atau ID lintas situs lainnya. Kami ingin mendorong ekosistem yang sehat tanpa perlu menentukan cara kerja teknologi iklan.

Kami telah memublikasikan panduan tentang cara kerja API di repositori GitHub kami dan terbuka untuk mempelajari solusi dengan industri.

Kami tidak berencana untuk membuat implementasi tertentu karena tugas inti kami adalah membuat teknologi platform, bukan menentukan strategi untuk menggunakan teknologi tersebut. Teknologi kami akan membantu perusahaan teknologi iklan menayangkan iklan kepada pelanggan mereka dengan cara terbaik dengan pembatasan privasi yang tepat bagi konsumen.
Lelang multi-penjual Apakah Chrome akan memaksa berbagi pemenang "kontekstual" dengan 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 Adtech menanyakan kepada PA cara menerapkan pelacakan izin pengguna dengan benar Respons kami mencakup apa yang kami sampaikan di Pertanyaan 1:
"Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara pemilihannya."

Kami telah membahas sejumlah skenario terkait masalah ini selama Pertemuan Audiens yang Dilindungi WICG Mei dan kami menerima masukan dan diskusi tambahan tentang masalah ini.
Audiens Kustom Apakah kasus penggunaan SSP yang terkait dengan pembuatan Audiens Kustom akan didukung oleh Protected Audience API? Protected Audience API memungkinkan SSP dan penyedia teknologi iklan lainnya memiliki dan mengelola Audiens Kustom. Panduan lebih lanjut tentang cara SSP dapat berintegrasi dengan PA API sedang dikembangkan dan akan tersedia untuk SSP dan penyedia teknologi iklan lainnya guna 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 menyiapkan cara iklan ditayangkan melalui Protected Audience API. Artinya, pastikan tag penempatan dapat meneruskan URL dari iframe Protected Audience ke pemutar video. Untuk Frame Pagar, kami akan berupaya memenuhi kebutuhan video sebelum persyaratan untuk menggunakan Frame Pagar yang tidak lebih awal dari tahun 2026.
Kecepatan Bagaimana cara kerja kasus penggunaan Kecepatan dengan Protected Audience API? Kami menghargai masukan tersebut. Kami ingin melihat lebih banyak instance permintaan ini dengan detail lebih lanjut dari lebih banyak partner SSP karena hingga saat ini masalah ini sebagian besar terjadi pada DSP.
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 mengizinkan teknologi iklan menggunakan sinyal yang diperbarui dalam ritme yang berbeda seperti pencarian K/V.
Kontrol Kualitas 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-bid (yaitu daftar tolak berdasarkan label yang terkait dengan iklan). Kami menerima masukan tentang fungsi tambahan yang mungkin diperlukan ekosistem.
Proses Debug Kapan fungsi forDebuggingOnly akan dihapus? Kami berencana menghentikan forDebuggingOnly untuk peristiwa kehilangan karena penghentian penggunaan cookie pihak ketiga. Kami berencana untuk menghentikan penggunaan forDebuggingOnly untuk peristiwa kemenangan paling awal 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 di K1) Pemasaran Ulang Dinamis Apakah pemasaran ulang Dinamis masih dapat dilakukan dengan Protected Audience API setelah penghentian penggunaan cookie pihak ketiga? Kami yakin kasus penggunaan ini dapat dilakukan menggunakan Protected Audience, seperti yang dijelaskan di sini.
Klik data terkait Menambahkan data terkait klik ke browserSignals. Saat ini kami meminta klarifikasi tentang kapan klik terjadi untuk memberikan posisi awal.
(Juga dilaporkan pada Kuartal 4 2022) Fungsi yang ditentukan pengguna di Protected Audience Bagaimana fungsi yang ditentukan pengguna (UDF) akan didukung di Protected Audience API? Ini adalah fungsi yang dapat diprogram oleh pengguna akhir untuk memperluas fungsi API. Teknologi iklan yang mengangkat masalah ini juga menyebutkan bahwa mereka masih mengevaluasi apa yang dapat mereka lakukan dengan UDF sehingga belum ada masukan yang bisa ditindaklanjuti untuk ditanggapi, setidaknya hingga tersedia secara umum.
Mata Uang Jumlah mata uang tidak boleh direpresentasikan menggunakan floating point. Kami membahas masalah ini secara mendetail di sini.
Kemampuan pemilihan iklan non-DSP Apa peran Server Iklan dalam lelang Protected Audience API? Kami mengetahui permintaan agar Server Iklan terus menawarkan layanan pemilihan iklan pasca-bid / pengoptimalan materi iklan dinamis. Saat ini kami sedang menilai analisis kesenjangan mendetail yang ada antara Protected Audience API saat ini dan permintaan ini.
GenerateBid Dukungan untuk proposal Google Ads guna menampilkan lebih dari satu iklan kandidat per grup minat iklan dari generateBid dan memberi kandidat tersebut skor di `scoreAd`. Hal ini sedang dievaluasi. Kami menerima 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 agar Protected Audience API berjalan terakhir.
Navigasi yang tidak dimulai pengguna Mengekspos navigasi yang tidak dimulai pengguna Kami sedang meninjau permintaan ini dan mendiskusikannya di sini serta menerima masukan tambahan.
Menyimpan ke cache SSP tidak boleh membuat perBuyerSignals DSP tertentu dari cache jika status pengguna berubah. Kami memahami bahwa penyimpanan dalam cache tidak berfungsi untuk setiap kasus penggunaan sinyal perBuyer dan sedang mengevaluasi opsi lebih lanjut. Kami menerima masukan tambahan dari ekosistem tentang apakah penyimpanan dalam cache akan berfungsi untuk kasus penggunaan mereka.
Pelaporan Atribusi dan Protected Audience Bagaimana cara kerja Attribution Reporting API dan Protected Audience API? 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 peningkatan integrasi Protected Audience API dan Attribution Reporting 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 yang independen dari Server Agregasi Tepercaya yang digunakan untuk memproses laporan yang dikumpulkan dan diubah. Saat ini, kami tidak berencana melakukan perubahan pada 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. Komplikasi tambahannya adalah teknologi iklan yang berbeda kemungkinan akan memiliki strategi pengelompokan yang diinginkan yang berbeda. Kami menerima masukan tambahan di sini.
WebIDL Spesifikasi Protected Audience API saat ini tidak kompatibel dengan spesifikasi WebIDL. Kami sedang mengevaluasi masukan ini dan mendiskusikan masalahnya di sini.
Pengelolaan Izin Bagaimana cara penanganan penerusan sinyal izin di Protected Audience API? Informasi kontekstual tidak termasuk dalam cakupan Protected Audience API. Kami sedang mendiskusikan masalah ini dan menerima 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 mendukung kasus penggunaan tertentu ini, dan menyambut masukan tambahan tentang masalah ini dari ekosistem.
Lelang komponen Apa yang dinilai peserta lelang komponen? Lelang komponen tidak langsung memberi skor Grup Minat, tetapi memberi skor 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 di code base GitHub Server Kunci/Nilai. Kami ingin memperbarui proses yang relevan untuk mendukung kontribusi eksternal pada kode GitHub.
Ukuran Grup Minat Berapa jumlah maksimum kunci yang didukung oleh IG? Batas saat ini adalah 50 kb untuk ukuran satu IG dan kunci dihitung sebagai bagian darinya. Kami menyambut baik diskusi lebih lanjut tentang 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, data ini dapat di-cache di seluruh lelang komponen, dan juga di seluruh slot iklan di satu halaman.
Kontrol versi Dukungan untuk beberapa versi kode teknologi iklan Layanan Bidding dan Lelang akan mendukung beberapa versi kode teknologi iklan. Di 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 alasan kasus penggunaan tersebut penting bagi ekosistem.
Web ke aplikasi Mendukung berbagi grup minat dari web ke aplikasi. Web-to-app saat ini tidak dicakup dalam deployment Protected Audience API di Chrome dan Android, tetapi kami ingin mendengar dari ekosistem tentang pentingnya kasus penggunaan ini.
K-Anonymity Cara menangani penggantian K-Anonymity Kami sedang membahas masalah ini dan menerima 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 telah menerima beberapa masukan bahwa konfigurasi tingkat peristiwa saat ini tidak optimal dan kami meminta masukan tentang konfigurasi global yang optimal. Kami terbuka untuk masukan tambahan terkait hal ini dan yakin bahwa penjelasan tingkat peristiwa yang fleksibel kami juga membantu mengatasi hal ini.
Konfigurasi tingkat peristiwa fleksibel Apa status fitur konfigurasi tingkat peristiwa fleksibel? Kami telah membagikan dokumentasi tentang konfigurasi tingkat peristiwa fleksibel. Fitur ini masih dalam tahap proposal dan kami mencari lebih banyak masukan tentang apakah fitur ini akan bernilai bagi ekosistem.
Konfigurasi tingkat peristiwa fleksibel Bagaimana cara merekonsiliasi laporan yang bertentangan dari berbagai pihak? Sebagian besar skenario pelaporan ditangani melalui penggunaan laporan gabungan, sedangkan proposal konfigurasi tingkat peristiwa yang fleksibel secara khusus ditujukan untuk fleksibilitas tambahan bagi laporan tingkat peristiwa, yang paling sering digunakan untuk kasus penggunaan pengoptimalan. Kami 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 apa pun terkait masalah ini dan akan berupaya mengatasinya jika skenario ini tampaknya dihadapi oleh banyak teknologi iklan.
Bekerja dengan beberapa Agensi Iklan Bagaimana DSP dapat menggunakan Attribution Reporting API jika pengiklan bekerja sama dengan beberapa agensi iklan? API ini mendukung pengalihan sehingga dapat digunakan meskipun pengiklan bekerja sama dengan beberapa agensi iklan. Selain itu, ada beberapa batasan terkait pengalihan untuk memastikan bahwa API meningkatkan privasi. Kami juga telah mengidentifikasi potensi solusi yang menggunakan Shared Storage API untuk skenario spesifik yang telah diajukan oleh teknologi iklan. Kami menerima masukan tambahan apa pun terkait skenario ini dan akan terus melakukan iterasi berdasarkan masukan tersebut.
Batas Tujuan Iklan Kasus penggunaan iklan yang dimuat ulang secara otomatis dapat terpengaruh oleh adanya batas tujuan. Kami membahas masalah ini dalam pertemuan WICG 1 Mei dan mencari masukan tentang batas yang wajar. Kami telah menambahkan ke penjelasan Pelaporan Atribusi dengan laporan tingkat peristiwa yang menyatakan bahwa browser dapat membatasi jumlah eTLD+1 `tujuan` yang diwakili oleh situs sumber. (Lihat permintaan pull).
Pelaporan Atribusi dan Protected Audience Bagaimana cara kerja Attribution Reporting API dan Protected Audience API? 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 peningkatan integrasi Protected Audience API dan Attribution Reporting pada 1 Juni. Anda dapat membacanya di sini.
Konfigurasi tingkat peristiwa fleksibel Bagikan praktik terbaik untuk simulasi derau setelah parameter dapat dikonfigurasi. Kami memiliki kode bersama di GitHub yang dapat digunakan siapa saja untuk menilai peningkatan informasi dan dampak derau untuk konfigurasi tingkat peristiwa fleksibel apa pun yang ingin mereka uji. Kami ingin mendengar dari siapa saja yang memilih untuk menguji dengan kode 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 relevansi dan pengukuran di Chrome 115, Pengukuran Atribusi Web dan Lintas Aplikasi saat ini tidak direncanakan untuk mencapai ketersediaan umum dengan Chrome 115.
Menghapus duplikat konversi Bagaimana cara merekonsiliasi solusi pengukuran independen dengan ARA? Seperti praktik standar saat ini, pengiklan akan bekerja sama dengan penyedia pengukuran independen pihak ketiga untuk menghapus duplikat pelaporan konversi. Kami telah menawarkan referensi tentang cara menghapus duplikat konversi untuk pelaporan tingkat peristiwa.
Kehilangan data selama pembaruan database Pelaporan Atribusi Apakah akan ada kehilangan data saat Chrome memperbarui Database Pelaporan Atribusi seperti yang diumumkan? Mulai Chrome Stabil 115, kami akan mulai mengaktifkan Relevance dan Measurement API untuk sebagian pengguna Chrome secara default. Ketersediaan umum ini akan ditingkatkan saat kami memantau potensi masalah. Sasaran kami adalah mencapai ketersediaan 100% selama beberapa minggu, paling lambat Kuartal 3 2023. Hal ini akan bertepatan dengan akhir uji coba asal Relevansi dan Pengukuran. Mulai bulan Juli, penguji akan dapat mendaftar untuk mendapatkan akses ke API ini dalam ketersediaan umum. Hal ini akan memberikan 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 berakhir agar dapat bertransisi dengan lancar dari uji coba origin tanpa mengganggu pengujian yang sedang berlangsung.

Seperti yang disebutkan dalam pengumuman ini, data yang terdaftar dari versi lama (M113 dan yang lebih lama) tidak akan dimigrasikan setelah update, sehingga mungkin ada kehilangan data. Kebocoran data ini tidak akan muncul dalam pelaporan debug, dan kami akan mencoba menghindari kebocoran data dari 114 ke 115.
Penagihan Menggunakan Pelaporan Atribusi untuk penagihan biaya per konversi Seperti yang dinyatakan dalam artikel ini, Attribution Reporting API mungkin tidak sesuai untuk kebutuhan penagihan biaya per konversi, karena adanya derau yang ditambahkan ke laporan tingkat peristiwa dan ringkasan. Sebaiknya pemain ekosistem membagikan masukan tentang dampak terhadap berbagai model penagihan oleh Attribution Reporting API di GitHub.

Layanan Agregasi

Tema Masukan Ringkasan Respons Chrome
Perubahan jeda 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 tentang proposal kami.
Solusi lokal Dapatkah Layanan Agregasi di-deploy di pusat data lokal? Meskipun kami sedang mempelajari opsi yang berpotensi mendukung di luar solusi berbasis cloud, saat ini tidak memungkinkan untuk mendukung TEE on-premise mengingat batasan keamanan on-premise yang akan memerlukan evaluasi yang memakan waktu untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang ditimbulkan oleh deployment lokal, kami yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung GCP selain AWS) adalah hal yang paling bermanfaat bagi ekosistem. Namun, kami menyambut masukan tambahan tentang alasan persyaratan tersebut diperlukan.
Memproses ulang laporan untuk jangka waktu yang berbeda Kemampuan untuk memproses ulang laporan untuk jangka waktu yang berbeda Kami telah menerima permintaan serupa agar dapat membagi batch untuk rentang tanggal yang berbeda. Salah satu proposalnya adalah mengizinkan kemampuan untuk memperluas ID bersama dengan label yang ditentukan teknologi iklan sehingga laporan dapat dibagi menjadi beberapa batch yang berbeda. Kami sedang dalam proses awal mengevaluasi proses ini dan akan terus memperbarui ekosistem seiring perkembangan proposal ini.
Implikasi Privasi 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 kami terus melakukan iterasi dan pengembangan.
Persyaratan Layanan Berapa batas waktu untuk menyetujui persyaratan layanan Layanan Agregasi? Meskipun kami belum menentukan batas waktu untuk menyetujui persyaratan dan ketentuan, sebaiknya perusahaan ekosistem menyetujui persyaratan dan ketentuan sesegera mungkin untuk mencegah keterlambatan pendaftaran. Kami mendorong perusahaan untuk menghubungi kami jika ada pertanyaan.
Penemuan Kunci Fitur penemuan kunci akan memungkinkan penguji membuat kueri laporan gabungan tanpa memerlukan daftar eksplisit kemungkinan kombinasi kunci untuk memproses laporan ringkasan atribusi lintas jaringan guna meningkatkan performa dan akurasi. Saat ini kami sedang mempelajari kemungkinan solusi dan solusi alternatif, 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.
Ruang kunci 128 bit Kejelasan tentang batasan ruang kunci 128-bit Kami akan membuat batasan ruang kunci ini lebih jelas dan menyelesaikan inkonsistensi di seluruh halaman. Sebaiknya gunakan strategi hashing agar tetap berada dalam ruang kunci ini.
Kontribusi maksimum per laporan Batas saat ini sebesar 20 kontribusi per laporan terlalu rendah. Daripada meningkatkan jumlah maksimum kontribusi, kami terbuka untuk mempertimbangkan pemisahan laporan, bukan pemotongan pada batas. Kami akan melibatkan ekosistem seiring berkembangnya proposal ini.
Pelaporan jangkauan Minta pelaporan jangkauan lintas platform/lintas perangkat. Jangkauan adalah metrik dasar periklanan merek. 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 telah meminta solusi alternatif setelah cookie pihak ketiga tidak digunakan lagi.
 Tim Privacy Sandbox sedang mempelajari fitur untuk mendukung metodologi jangkauan lintas-domain setelah penghentian penggunaan cookie pihak ketiga.
Kami menerima masukan tambahan dari ekosistem.

Membatasi Pelacakan Tersembunyi

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tema Masukan Ringkasan Respons Chrome
(Juga dilaporkan pada K1 2023) Petunjuk untuk faktor bentuk tambahan Permintaan untuk User Agent Client Hints (UA-CH) guna memberikan faktor bentuk tambahan seperti TV, VR Kami masih mengerjakan beberapa keputusan desain utama (baik untuk memberikan satu nilai seperti "TV", atau daftar kemampuan faktor bentuk), tetapi tetap tertarik untuk membuat prototipe ide ini.
Anggaran Privasi Batasan Privacy Budget dapat menyebabkan permintaan UA-CH menjadi non-deterministik jika terlalu banyak permintaan yang dikirim. Saat ini, kami tidak memiliki informasi terbaru tentang proposal Privacy Budget, tetapi kami 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 dapat mengakses situs. Ada kasus penggunaan yang valid untuk memiliki daftar merek, dan salah satunya adalah kompatibilitas. UA bebas memiliki beberapa merek untuk mengatasi masalah ini.

Perlindungan IP (sebelumnya bernama Gnatcatcher)

Tema Masukan Ringkasan Respons Chrome
Penipuan & Penyalahgunaan Bagaimana cara perusahaan menyiapkan langkah anti-penipuan dengan Perlindungan IP? Kami memahami pentingnya kasus penggunaan anti-penipuan dan kemungkinan dampaknya terhadap kasus penggunaan tersebut. Kami berencana untuk memublikasikan detail selengkapnya tentang dukungan anti-penipuan nanti pada musim panas ini. Kami mencari masukan ekosistem tentang cara kami dapat mendukung kasus penggunaan anti-penipuan dengan lebih baik.
GeoIP Informasi selengkapnya tentang linimasa pengujian dan deployment untuk GeoIP Chrome baru-baru ini memublikasikan informasi baru yang menjelaskan rencana GeoIP kami. Kami berencana memublikasikan informasi selengkapnya tentang linimasa deployment pada Kuartal 3. Kami berencana meluncurkan Perlindungan IP sebagai fitur keikutsertaan pengguna pada sebagian kecil traffic pada awalnya. Alasannya adalah kami menyadari bahwa proposal ini mungkin melibatkan beberapa perubahan signifikan bagi perusahaan, dan kami ingin memberi ekosistem waktu untuk menyesuaikan dan memberikan masukan sebelum fitur ini diluncurkan secara lebih luas.
Autentikasi akun Bagaimana cara kerja autentikasi akun dengan server proxy? Kami berencana untuk memublikasikan detail selengkapnya tentang autentikasi akun nanti pada musim panas ini, meskipun kami telah membagikan beberapa pertimbangan awal.

Mitigasi Pelacakan Kembali

Tema Masukan Ringkasan Respons Chrome
Panduan Pengujian Informasi tentang cara menguji mitigasi Pelacakan Kembali Kami memublikasikan postingan blog pada bulan Mei dengan informasi lebih lanjut tentang cara menguji Mitigasi Pelacakan Pantulan.
Dokumentasi Kejelasan dalam Proposal Pelacakan Pantulan Proposal saat ini masih dalam proses pengembangan dan Chrome terus memperbarui proposal tersebut untuk memberikan kejelasan dan informasi kepada ekosistem. Kami sedang berupaya memberikan detail selengkapnya dan menerima masukan tambahan apa pun.
Penghapusan cookie Apakah Mitigasi Pelacakan Pantulan akan menghapus semua cookie di domain? Mitigasi pelacakan pantulan (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 sebagian besar berfokus pada pengalihan tab yang sama, tetapi kami berencana untuk mengerjakan alur pop-up pada masa mendatang. Kami menerima masukan tambahan di sini.

Anggaran Privasi

Tema Masukan Ringkasan Respons Chrome
Penargetan Kedekatan Privacy Budget dapat memengaruhi kasus penggunaan penargetan kedekatan. Kami telah menerima masukan terkait masalah ini dan ingin mengetahui lebih lanjut potensi dampaknya dari ekosistem.

Memperkuat batasan privasi lintas situs

Set Pihak Pertama

Tema Masukan Ringkasan Respons Chrome
(Juga dilaporkan di kuartal sebelumnya) Batas Domain Meminta untuk memperluas jumlah domain terkait Chrome 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 pastinya untuk subset Terkait belum difinalisasi.
Kasus Penggunaan Tersemat Dukungan untuk kasus penggunaan Tersemat yang memerlukan Set Pihak Pertama, CHIP, dan penyimpanan bersama Chrome telah menerima masukan tentang kasus penggunaan ini, dan tim sedang menyelidiki 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 tentang kasus penggunaan ini. Tim kami sedang menyelidiki dan menerima masukan tambahan.
Edukasi Pengguna Chrome harus meningkatkan kesadaran 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 (dikaitkan dari UI Chrome) untuk tujuan ini. Chrome juga terus berinvestasi untuk mempelajari cara terbaik mengedukasi pengguna dalam konteks yang sesuai.
Post 3PCD Cookie pihak ketiga akan terus ada dalam Kumpulan Pihak Pertama setelah penghentian penggunaan cookie pihak ketiga. Meskipun requestStorageAccess dan requestStorageAccessFor memang membuat cookie pihak ketiga tersedia lagi untuk kasus penggunaan tertentu yang ditentukan dengan jelas, keduanya kini memerlukan pemanggilan aktif oleh situs, bukan tersedia secara default, seperti status cookie pihak ketiga saat ini (di Chrome).

Meskipun pemanggilan ini dalam satu set tidak akan memerlukan persetujuan pengguna, pengguna dapat mencegahnya dengan memilih tidak ikut dalam perilaku ini di Setelan.

Informasi selengkapnya tersedia bagi pengguna di artikel Pusat Bantuan (ditautkan dari UI Chrome). Kami berencana untuk memperluas panduan developer yang ada seiring FPS meningkat 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 tersebut dan menerima masukan tambahan di sini.

Fenced Frames API

Tema Masukan Ringkasan Respons Chrome
Pemblokiran Iklan Bingkai Pagar dapat mempermudah pemblokir iklan untuk memblokir iklan. Ekstensi dapat berinteraksi dengan frame berpagar mirip dengan cara berinteraksi dengan iframe. URL sebenarnya yang akan dituju oleh frame berpagar juga akan terlihat oleh ekstensi sehingga ekstensi dapat menerapkan aturan pencocokan URL untuk pemblokiran seperti yang dilakukan di iframe. Memblokir semua frame berpagar tanpa syarat dapat merusak kasus penggunaan non-iklan dari frame berpagar.

Shared Storage API

Tema Masukan Ringkasan Respons Chrome
Adopsi yang lebih luas Penyimpanan Bersama harus menjadi standar di seluruh industri yang tersedia di seluruh browser. Kami menerima dan menghargai masukan ini. Chrome terus berpartisipasi secara aktif dalam forum W3C untuk mendukung proposal, mencari masukan, dan mendorong adopsi.
Gate Output Gate output Penyimpanan Bersama terlalu terbatas. Kami mempertimbangkan masukan ini dan menerima masukan ekosistem tambahan tentang alasan gate output terlalu terbatas.
Kepatuhan terhadap Peraturan Bagaimana Penyimpanan Bersama akan menangani kepatuhan peraturan seperti kebijakan retensi data? Penyimpanan Bersama memberikan fleksibilitas untuk menerapkan dan menyesuaikan logika guna mengontrol masa aktif dan masa berlaku data yang disimpan. Teknologi iklan dapat memperbarui atau menghapus data Penyimpanan Bersama berdasarkan stempel waktu tulis.
Pengujian A/B Bagaimana cara melakukan pengujian A/B untuk Shared Storage dan Protected Audience API? Kami sedang berupaya memublikasikan panduan tambahan terkait masalah ini dan berharap dapat membagikan detail selengkapnya pada masa mendatang.
Batas Penyimpanan Bersama Apa yang akan terjadi setelah batas Penyimpanan Bersama tercapai? Jika batas tercapai, tidak ada input lebih lanjut yang akan disimpan.
Beberapa 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 tambahan hanya akan menambahkan nilai baru ke akhir nilai yang sudah ada.
Fungsi iframe Apakah Penyimpanan Bersama akan mendukung fungsi iframe tertentu setelah tidak berfungsi lagi setelah penghentian penggunaan cookie pihak ketiga? Setelah penghentian penggunaan cookie pihak ketiga, penyimpanan lokal di iframe akan dipartisi oleh situs tingkat teratas, tetapi iframe itu sendiri tidak akan diblokir. Data dalam penyimpanan lokal iframe tidak dapat direplikasi di beberapa situs tingkat teratas, tetapi penyimpanan lokal masih dapat digunakan dalam iframe.

CHIPs

Tema Masukan Ringkasan Respons Chrome
Batas partisi 10 KiB per situs yang dipartisi masih cukup besar dan ingin diturunkan. Firefox telah menunjukkan posisi positif di CHIPS. Untuk dukungan Webkit, sebaiknya developer memberikan masukan langsung kepada Apple 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 partisi yang berbeda memengaruhi penyematan yang diautentikasi. Kami ingin memanfaatkan Storage Access API (dengan perintah pengguna) untuk mendukung kasus penggunaan penyematan yang diautentikasi, dan baru-baru ini mengirimkan intent-to-prototype.
Kebijakan Seumur Hidup Apakah kebijakan masa berlaku potensial akan berlaku untuk cookie pihak pertama? Saat ini kami tidak berencana untuk menerapkan batasan masa berlaku pada cookie pihak pertama.

FedCM

Tema Masukan Ringkasan Respons Chrome
Dukungan Otorisasi OAuth Menyesuaikan otorisasi cakupan Oauth non-profil Kami secara aktif mencari masukan dari komunitas Web Identity melalui W3C FedID CG tentang cara terbaik untuk mendukung otorisasi di luar autentikasi dasar setelah penghentian penggunaan cookie pihak ketiga.
Dukungan untuk SAML Menyelaraskan persyaratan untuk dukungan SAML Tim kami secara aktif mencari masukan dari komunitas riset dan pendidikan tentang kebutuhan dukungan SAML (selain dukungan OpenID Connect) setelah penghentian penggunaan cookie pihak ketiga.

Memerangi spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan Ringkasan Respons Chrome
Menjelajahi sinyal baru Beberapa partner telah menyatakan sentimen positif terhadap eksplorasi sinyal integritas perangkat atau kepercayaan pengguna yang difasilitasi browser. Umumnya, mereka juga berhati-hati agar sinyal baru yang dibuat khusus cukup untuk mempertahankan tingkat deteksi penipuan saat ini. Kami senang dapat mempelajari proposal baru bersama dalam komunitas anti-scam dan keamanan web, serta mengakui dan memahami kekhawatiran mereka. Inilah alasan "memerangi spam dan scam" menjadi alur kerja inti Privacy Sandbox dan alasan kami terus memprioritaskan investasi dalam menjaga keamanan web saat kami meningkatkan privasi pengguna.
Masukan positif tentang PST Beberapa partner telah menyatakan minatnya untuk menguji atau menggunakan PST untuk berbagai kasus penggunaan anti-penipuan atau keamanan web. Kami senang mendengar dukungan dan minat Anda untuk mempelajari lebih lanjut solusi baru yang menggunakan PST. Kami memiliki referensi dan contoh kode yang tersedia melalui situs developer Chrome, dan menerima masukan lebih lanjut.
Penipuan dan Penyalahgunaan Panduan untuk Pencegahan / Deteksi Penipuan Iklan dalam pengukuran setelah penghentian penggunaan cookie pihak ketiga 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 anti-penipuan, tetapi dengan kontrol privasi baru yang diterapkan. Kami secara aktif berinvestasi dalam proposal anti-penipuan dan anti-penyalahgunaan baru untuk mempertahankan kemampuan dengan perubahan Privacy Sandbox lainnya.
Tarif informasi asal penerbit Rasio informasi penerbit ke asal cukup tinggi untuk mengidentifikasi pengguna unik. Kami telah memperbarui spesifikasi agar lebih jelas tentang data pengguna yang dapat disampaikan menggunakan Token Status Pribadi. Secara desain, hingga enam kunci publik dapat digunakan sekaligus, yang dapat mewakili "status" untuk pengguna tertentu. Kumpulan kunci ini hanya dapat diperbarui setiap 60 hari (kecuali dalam kasus yang jarang terjadi saat rotasi kunci darurat diperlukan), yang memperlambat potensi untuk menggabungkan data pengguna tambahan dari waktu ke waktu. Dengan API web baru, ada keseimbangan antara utilitas yang disediakan dan informasi pengguna baru bersih yang diberikannya. Kami memperkirakan bahwa PST mencapai keseimbangan yang sesuai dalam melindungi privasi pengguna sekaligus memungkinkan kasus penggunaan anti-penipuan utama yang terpengaruh oleh penghentian cookie pihak ketiga.
Mengambil Integrasi Integrasi fetch rumit dan tidak perlu. Ada pro dan kontra dalam penggunaan fetch, dan kami ingin mengejar standarisasi lebih lanjut dalam ekosistem web, tetapi kami rasa masih terlalu dini untuk melakukan perubahan ini hingga kami memiliki gambaran yang lebih jelas tentang tampilan standar tersebut. Jika dan saat standar muncul, kami juga berkomitmen untuk melakukan transisi 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 menunjukkan bahwa mereka lebih menyukai fleksibilitas untuk menyimpan kunci di URL umum, bukan di direktori .well-known. Format komitmen kunci di PrivacyPass tidak terlalu cocok untuk versi yang keyset-nya dimaksudkan untuk memungkinkan nilai "metadata publik" implisit. Jika varian PrivacyPass akhirnya distandarisasi dengan metadata publik (baik sebagai POPRF, blinding RSA parsial, atau kumpulan kunci), kami mungkin beralih ke PST versi mendatang untuk mendukungnya.
Implementasi header API Pertanyaan terkait penerapan header API Seiring API distandarisasi dan penggunaan ekosistem API ini semakin matang, semoga kami dapat mendukung versi non-header standar API ini dan pada akhirnya berpotensi menghentikan penggunaan versi header jika penggunaannya cukup rendah atau ada cukup alat/dukungan developer untuk cara standar yang mengaitkan permintaan penerbitan/penukaran dengan data lainnya. Kami membahas masalah ini di sini.
Pendaftaran Apakah meminta penerbit untuk mendaftar ke vendor browser praktis? Kami telah memperbarui spesifikasi untuk menjelaskan proses pendaftaran penerbit untuk Token Status Pribadi. Meskipun menggunakan prosesnya sendiri, proses ini mirip dengan rencana pendaftaran untuk seluruh pekerjaan Privacy Sandbox, yaitu kami meminta penerbit untuk membuat pernyataan publik tentang cara mereka ingin menggunakan PST dan untuk mengonfirmasi batasan teknis yang melindungi privasi pengguna.