Laporan kuartalan untuk K4 2024 yang merangkum masukan ekosistem yang diterima tentang 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 oleh 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 menyambut baik masukan yang diterima 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 menggabungkan jumlah masukan yang 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 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 dengan tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif tema yang muncul 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, khususnya terkait teknologi dan API Topics, PA API, dan Attribution Reporting API.
Masukan yang diterima baru-baru ini mungkin belum memiliki respons Chrome yang dipertimbangkan.
Glosarium akronim
- ARA
- Attribution Reporting API
- CHIP
- Cookie yang Memiliki Status Partisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Federated Credential Management
- IAB
- Interactive Advertising Bureau
- IDP
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Internet Protocol
- openRTB
- Bidding real-time
- OT
- Uji Coba Origin
- PA API
- Protected Audience API (sebelumnya FLEDGE)
- PatCG
- Grup Komunitas Teknologi Iklan Pribadi
- RP
- Relying Party/Pihak yang Mengandalkan
- RWS
- Set Situs Terkait (sebelumnya Set Pihak Pertama)
- SSP
- Platform Sisi Pasokan
- 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 |
|---|---|---|
| Komitmen | Bagian G dari Komitmen sangat penting untuk kelangsungan Privacy Sandbox. Tanpa jaminan bahwa bisnis iklan Google sendiri akan beroperasi secara eksklusif di teknologi Sandbox, risiko utilitas yang terus menurun akan meningkat, begitu juga kemungkinan divestasi teknologi oleh Google. Divestasi atau pengurangan utilitas tersebut akan menjadi ancaman eksistensial bagi kemampuan untuk dialamatkan yang mengutamakan privasi di web terbuka. | Komitmen ini tidak menjamin bahwa bisnis iklan Google sendiri akan beroperasi secara eksklusif di teknologi Privacy Sandbox. Google bermaksud menggunakan pendekatan portofolio untuk keterjangkauan, yang akan mencakup teknologi Privacy Sandbox, dengan cara yang sama seperti yang dapat dan digunakan oleh pihak ketiga. Kami memahami bahwa pendekatan portofolio umum di seluruh ekosistem iklan. Kami yakin bahwa developer tetap perlu memiliki alat dan teknologi yang menjaga privasi. Kami akan terus menyediakan Privacy Sandbox API dan berinvestasi pada API tersebut untuk lebih meningkatkan privasi dan utilitasnya. |
| Tata kelola | Model tata kelola yang diusulkan tidak menyertakan mekanisme khusus untuk akuntabilitas dalam proses banding atau konsultasi formal. | Jawaban ini salah. Baik (i) sistem pengambilan keputusan dan publikasi terkait maupun (ii) proses banding menyediakan mekanisme khusus untuk akuntabilitas. Selain itu, Pemegang Amanat Pemantauan akan mengawasi fungsinya secara mendetail. |
| Tata kelola | Masukan bahwa model tidak berisi ketentuan untuk pembuatan dan pemeliharaan standar lintas platform. | Tidak ada model tata kelola yang dapat memaksa aktor lain, dalam hal ini browser, untuk mengadopsi standar. Oleh karena itu, kami belum mengusulkan model yang memerlukan penerapan standar lintas platform. Google akan terus berpartisipasi dalam forum standar tempat membuat proposal dan berbagi pengalaman menerapkan proposal adalah aktivitas umum dalam prosesnya. |
| Tata kelola | Sebaiknya perpanjangan periode konsultasi dilakukan hingga minimal 2 bulan. Model tata kelola yang diusulkan tidak memberikan waktu yang memadai bagi ekosistem untuk menganalisis dampak dari perubahan yang diusulkan. | Periode tiga minggu bukanlah seluruh periode masukan untuk perubahan tertentu karena siklus masukan yang ada (yang jauh lebih lama) akan berlanjut. Sebagai gantinya, proses konsultasi menawarkan periode masukan formal baru dalam proses yang ada untuk keputusan strategis. Dengan demikian, pihak ketiga akan terus dapat memberikan input melalui berbagai forum (termasuk GitHub, W3C, dan lembaga standar iklan seperti IAB Tech Lab) selama pengembangan fitur. Dengan menyusun siklus masukan dengan cara ini, ekosistem akan memiliki kesempatan untuk menganalisis dan membagikan pandangan mereka tentang perubahan yang diusulkan tanpa penundaan yang signifikan pada proses pengembangan. |
| Tata kelola | Minta detail terkait rencana tata kelola mendatang. | Ringkasan model tata kelola yang diusulkan ditetapkan dalam laporan Kuartal 2/Kuartal 3 2024 CMA (halaman 3-5 di sini). |
| Permintaan Pengecualian | Meminta pengecualian untuk mengakses cookie pihak ketiga (3PC) bagi pengguna yang memberikan izin. | Memberikan izin untuk akses dan penyimpanan perangkat untuk tujuan pemrosesan data tertentu tidak berarti pengguna ingin mengganti setelan 3PC mereka di Chrome. Mengizinkan penggantian setelan 3PC pengguna di tingkat situs akan menciptakan potensi penyalahgunaan yang cukup besar, dan Chrome tidak dapat mengaudit semua perilaku situs yang mungkin menyebabkan permintaan pengecualian. |
| Privacy Sandbox | Meminta rasio keikutsertaan Privacy Sandbox API. | Kami tidak berencana untuk membagikan informasi ini kepada ekosistem. Developer dapat memanggil API tempat mereka men-deploy kode saat ini untuk memperkirakan ketersediaan Privacy Sandbox API. |
| Uji Coba Origin | Apakah ada rencana untuk memperpanjang uji coba origin? | Uji coba origin telah diperpanjang hingga 14 April 2025. |
| Privacy Sandbox | Minta penjelasan singkat dan non-teknis tentang Privacy Sandbox yang menyoroti nilai bisnisnya dan mendapatkan dukungan dari eksekutif. | Baru-baru ini kami menambahkan bagian Referensi Bisnis ke privacysandbox.com di sini yang memberikan informasi ini. |
| Mode B | Saat browser berada dalam "Mode B", apakah cookie jar saat ini (1PC, 3PC, penyimpanan lokal) akan tetap ada atau dihapus? | Cookie jar saat ini tidak akan dihapus. 3PC akan tetap dapat diakses dalam konteks pihak pertamanya. |
| Pendekatan yang diperbarui untuk 3PC di Chrome | Apakah 3PC akan dihapus sepenuhnya dari Chrome pada masa mendatang? | Kami mengusulkan pendekatan yang diperbarui yang mengakomodasi pilihan pengguna. Seperti yang dijelaskan di sini, daripada menghentikan penggunaan 3PC, kami akan memperkenalkan pengalaman baru di Chrome yang memungkinkan pengguna membuat pilihan tepat yang berlaku di seluruh penjelajahan web mereka, dan mereka dapat menyesuaikan pilihan tersebut kapan saja. Kami sedang mendiskusikan jalur baru ini dengan badan pengatur, dan akan melibatkan industri sebelum meluncurkannya. |
| Pengujian Chrome | Meminta ketersediaan Label Pengujian yang difasilitasi Chrome secara berkelanjutan. | Tim Privacy Sandbox memahami bahwa perusahaan ingin terus menggunakan label penghentian penggunaan cookie. Proses untuk memperpanjang ketersediaan label mirip dengan memperpanjang uji coba origin. Sebagai bagian dari proses ini, eksperimen hanya dapat diperpanjang untuk tiga tonggak pencapaian Chrome sekaligus. Misalnya, Intent to Extend Experiment (I2EE) terbaru Chrome untuk label penghentian penggunaan cookie diperpanjang untuk Chrome M130-M132, inklusif. Hal ini memungkinkan dukungan untuk label hingga rilis stabil M133 pada awal Februari. Ekstensi tambahan akan berjalan melalui proses yang sama, jadi sebaiknya ikuti perkembangannya di grup email blink-dev untuk mendapatkan info terbaru. |
Pendaftaran & Pengesahan
Tidak ada masukan yang diterima kuartal ini.
Menampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Spesifikasi | Apakah model pengklasifikasi dibagikan antara Android (menurut nama aplikasi) dan Chrome (menurut nama host)? | Tidak, keduanya adalah model terpisah karena memiliki taksonomi yang berbeda. |
| Perincian taksonomi Topik | Topik terlalu umum untuk berguna jika dimanfaatkan dengan informasi pihak pertama. | Taksonomi Topics berupaya menyeimbangkan utilitas dan privasi. Meskipun kami telah mengevaluasi kemungkinan mekanisme untuk membuat Topik lebih spesifik, pada akhirnya kami memutuskan untuk tidak melakukannya karena pertimbangan keamanan dan privasi, di antara masalah lainnya. Teknologi iklan dapat memberikan hasil terbaik dengan menggabungkan semua alat yang tersedia, seperti machine learning dan sinyal yang menjaga privasi dari API yang menjaga privasi, bersama dengan data kontekstual, data materi iklan, dan data pihak pertama. Panduan lebih lanjut tentang hal ini tersedia di sini. |
| Penggunaan API | Topics API memiliki cakupan yang rendah. | Alasan umum untuk cakupan yang rendah meliputi: - Kontrol pengguna/ketidakikutsertaan - Kontrol penayang/ketidakikutsertaan - Kelayakan situs (situs berikut tidak disetujui untuk dicocokkan dengan Topik: situs tidak aman; WebView; Chrome di iOS, dan mode Samaran) - Batasan pengguna (pengguna Chrome yang berusia di bawah 18 tahun atau yang menggunakan mode Samaran tidak dapat diamati dan diberi Topik) - Persyaratan pengamatan penjual (pemanggil harus pernah melihat pengguna di situs yang terkait dengan topik yang memenuhi syarat) - Keaktualan penerapan (memungkinkan ~4 minggu untuk meningkatkan pengamatan pemanggil agar dapat diskalakan) |
| Penggunaan API | Meminta informasi tentang penggunaan Topics API karena tab Jaringan tampaknya menunjukkan bahwa ada panggilan yang dikirim dan ditangkap, tetapi chrome://topics-internals/ tidak menampilkan observer yang direkam. | Saat menggunakan mekanisme header HTTP untuk berinteraksi dengan Topics API, topik dikirim dalam header permintaan Sec-Browsing-Topics, tetapi hanya diamati jika server membalas dengan header respons Observe-Browsing-Topics: ?1. Hal ini dijelaskan secara lebih mendetail di sini. |
| Keterlibatan Chromium | Untuk Desktop, apakah Chrome akan membagikan konteks pengamatan dan peringkat yang sama dengan browser lain yang berbasis Chromium? Untuk Seluler, apakah Android Chrome akan berbagi konteks pengamatan dan peringkat yang sama dengan browser Android lainnya yang berbasis Chromium / Chromium Dalam Aplikasi? |
Chrome tidak membagikan data Topics dengan browser lain di perangkat. |
| Spesifikasi | Bagaimana cara Topics API menentukan apakah kunjungan halaman oleh pengguna dianggap sebagai 'entri histori topik'? | Agar memenuhi syarat untuk penghitungan topik mingguan, kunjungan halaman harus memiliki panggilan 'observe' (dapat berasal dari pemanggil mana pun). Tanpa panggilan 'observe', kunjungan tidak akan dipertimbangkan untuk histori topik. |
| Keamanan | Bagaimana cara Topics API mencegah satu pemanggil mendapatkan topik pengamatan pemanggil lain? | Kami telah memberikan penjelasan di sini. |
| Taksonomi | Bagaimana taksonomi struktur hierarki dalam Topics API digunakan dalam pengamatan di setiap iterasi pelatihan? | Saat menghitung 5 topik teratas, algoritma ini hanya mempertimbangkan topik asli yang diberikan oleh pengklasifikasi, dan peringkat ditentukan oleh (i) frekuensi kunjungan halaman, dan (ii) skor prioritas (lihat spesifikasi). Saat menghitung topik yang diamati oleh pemanggil dari setiap 5 topik teratas, metrik ini mencakup pemanggil yang mengamati topik utama atau topik turunannya. |
| Spesifikasi | Meminta informasi tambahan terkait derau acak 5% pada respons. | Selalu ada 5 topik teratas untuk setiap epoch. Jika histori penjelajahan tidak menyediakan 5 topik, topik akan dipilih secara acak hingga ada 5 topik. Kami menyebutnya topik yang ditambahkan. Pemanggil tidak akan menerima salah satu topik yang ditambahkan secara acak ini kecuali jika mereka telah mengamati (memanggil API) pengguna di situs dengan topik tersebut dalam beberapa minggu terakhir. Saat API dipanggil, hash per pengguna, per situs, per iterasi pelatihan akan dihitung. Jika hash tersebut kurang dari probabilitas menampilkan topik yang di-noise, topik acak per pengguna, per situs, per epoch akan dipilih untuk ditampilkan. Namun, topik yang berisi derau hanya ditampilkan (misalnya, tidak difilter) jika pemanggil telah mengamati topik yang tidak berisi derau yang sesuai untuk pengguna/situs/epoch tersebut (lihat penjelasan). Pemfilteran ini memastikan bahwa topik yang berisi derau ditampilkan 5% dari waktu untuk pemanggil tertentu, terlepas dari kemampuan pengamatannya. |
| Spesifikasi | Bagaimana cara kerja topik duplikat lintas minggu? Apakah API memilih secara independen di antara minggu-minggu, lalu menggabungkannya? | Topik setiap minggu (epoch) dihitung secara independen. Topik tertentu yang dipilih untuk ditampilkan dari setiap epoch bergantung pada situs yang digunakan pemanggil. Kami tidak memperhitungkan bahwa topik mungkin diulang di seluruh epoch untuk pemanggil tertentu (dan oleh karena itu harus mempertimbangkan untuk memilih topik yang berbeda), tetapi kami menerima masukan tambahan tentang masalah ini di sini. |
Protected Audience API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pengujian A/B | Solusi Penyimpanan Bersama yang dijelaskan di sini menambahkan latensi dan memiliki tingkat kegagalan yang tinggi (yaitu, proporsi traffic yang signifikan berakhir tanpa ID populasi). ID entropi rendah (misalnya, 3 bit) dapat memadai untuk pengujian A/B yang efektif tanpa dampak privasi yang signifikan. | Kami yakin solusi Penyimpanan Bersama tetap merupakan pendekatan yang layak, tetapi kami mempertimbangkan permintaan ini dan menyambut masukan tambahan dari ekosistem jika fitur ini memiliki prioritas tinggi. |
| Pelaporan | Meminta bit tambahan di reportWin(), terutama karena pemahamannya adalah pelaporan klik dan tampilan baru di PA API akan menggunakan 6-8 bit, yang secara efektif mengurangi bit yang tersisa untuk pelaporan PA API lainnya. |
Kami tidak lagi mempertimbangkan untuk meningkatkan bit modelingSignals di luar 12 bit saat ini karena alasan privasi. Kami mengundang ekosistem untuk memberikan masukan tentang proposal Pelatihan Model Pribadi kami, yang bertujuan untuk mendukung kebutuhan pelatihan ML di lingkungan yang aman tanpa batasan bit yang diberlakukan oleh Privacy Sandbox. |
| Grup Minat | Meminta siklus proses 90 hari untuk Grup Minat (IG) karena 30 hari tidak cukup lama. | Seperti yang telah kami sebutkan dalam postingan blog kami, kami berencana untuk memperpanjang masa berlaku IG menjadi 90 hari, dan kami telah membuat penjelasan di sini. Kami sedang mengerjakan penerapannya, dan akan membagikan linimasa peluncuran jika sudah tersedia. |
| Grup Minat | Meminta pembaruan dinamis untuk delegasi IG. | Kami mengetahui permintaan ini dari beberapa pemangku kepentingan dan sedang meneliti solusinya. Kami akan membagikan info terbaru di GitHub seiring perkembangannya dan menerima masukan tambahan dari ekosistem. |
| Di Perangkat | Tunjukkan lebih banyak nilai bagi ekosistem untuk terus berinvestasi dalam solusi PA API di perangkat. | Tim Privacy Sandbox melanjutkan pengembangan API berbasis Privacy-Enhancing Technology (PET), termasuk PA API, untuk menawarkan lebih banyak opsi perlindungan privasi kepada developer di browser. Teknologi tersebut kini tersedia di seluruh browser Chrome dalam skala besar (bukan hanya 1% seperti yang disalahpahami oleh beberapa developer). Baik pengguna mengaktifkan 3PC maupun tidak, developer dapat memilih untuk menyertakan solusi berbasis PET ke dalam produk mereka, sama seperti banyak perusahaan yang memilih untuk mengadopsi solusi berbasis PET lainnya di luar browser. Bagi banyak developer, mereka sudah mendapatkan manfaat dari berinvestasi dalam solusi PA API di perangkat dengan memperluas sinyal audiens pihak pertama yang deterministik untuk meningkatkan jangkauan di seluruh situs. Kami memahami bahwa beberapa developer hanya akan memilih untuk menggunakan Privacy Sandbox API atau solusi berbasis PET lainnya jika lebih banyak 3PC dinonaktifkan, dan developer ini menunggu informasi yang memungkinkan mereka berspekulasi tentang jumlah browser yang akan mempertahankan 3PC. Kami menyadari bahwa developer tersebut akan menunggu hingga menemukan informasi yang mereka cari untuk membuat keputusan produk. |
| Grup Minat | Mengizinkan SSP memiliki bagian dalam pembuatan IG dan peran yang terkait dengannya. SSP menganggap hal ini sebagai bagian penting dari nilai tambah mereka, dan ingin dapat membantu penayang menjual IG melalui SSP mereka. | Kami telah menerima permintaan untuk mendukung delegasi IG yang lebih canggih dari beberapa pemangku kepentingan, dan kami melihat nilai tambah SSP yang berkontribusi pada proses ini. Kami sedang melakukan riset untuk menemukan solusi terbaik yang memungkinkan berbagai pihak berpartisipasi dalam proses perluasan audiens. Kami akan membagikan info terbaru di GitHub seiring perkembangannya dan menerima masukan tambahan dari ekosistem. |
| Pelaporan | Perbedaan jumlah laporan "bid non-nol" antara forDebuggingOnly dan Private Aggregation API. | Kami memperkirakan adanya perbedaan karena dua alasan: Pertama, mode debug Private Aggregation API hanya tersedia jika ada 3PC yang diizinkan di perangkat, sedangkan forDebuggingOnly API selalu tersedia tanpa sampel (perilaku terakhir ini pada akhirnya akan berubah seperti yang dijelaskan di sini). Kedua, Private Aggregation API memiliki batas kontribusi, sedangkan forDebuggingOnly tidak. Namun, masukan ini menunjukkan bahwa mungkin ada hal lain yang menyebabkan perbedaan yang tidak terduga dan kami sedang bekerja sama dengan pemangku kepentingan pihak ketiga untuk menyelesaikan masalah ini. |
| Kemudahan diklik | Seperti yang disebutkan dalam proposal yang diperbarui untuk sinyal klik, penayangan dan klik akan didaftarkan dengan menampilkan header respons HTTP baru ke permintaan yang dimulai oleh atribut "attributionsrc" yang memenuhi syarat", dan header respons ini akan menyertakan daftar asal yang dapat digunakan untuk menunjukkan pihak lain yang dapat menyertakan penayangan dan klik ini dalam jumlah gabungannya. Apakah ini berarti teknologi iklan dapat menetapkan asal secara sewenang-wenang? | Dalam penjelasan klikabilitas, disebutkan bahwa teknologi iklan yang berkontribusi pada peristiwa penayangan atau klik ke jumlah penayangan dan klik gabungan ("asal penyedia") dapat menyertakan parameter opsional dengan header respons yang memungkinkannya menentukan "satu atau beberapa asal pemilik IG yang peristiwanya dapat disertakan dalam jumlah penayangan dan klik yang dihitung yang akan diberikan ke pemanggilan generateBid() mereka di lelang Protected Audience" ("asal yang memenuhi syarat").Meskipun demikian, penayangan dan klik ini tidak otomatis disertakan dalam jumlah penayangan dan klik. Sebaliknya, setiap teknologi iklan harus menentukan, dalam IG-nya, kumpulan "asal penyedia" tempat peristiwa tampilan dan klik harus disertakan, dan hanya data dari asal penyedia ini yang berkontribusi pada jumlah tampilan dan klik yang ditampilkan ke panggilan generateBid() teknologi iklan tersebut.Mekanisme ini memerlukan kesepakatan di kedua belah pihak, dan mencegah pemain berbahaya memengaruhi jumlah penayangan dan klik untuk teknologi iklan lainnya. Hal ini juga berarti bahwa teknologi iklan "penyedia" yang menetapkan "asal yang memenuhi syarat" secara sewenang-wenang tidak akan berdampak pada jumlah penayangan dan klik asal yang memenuhi syarat tersebut, kecuali jika asal yang memenuhi syarat tersebut secara eksplisit dan sengaja menyertakan asal penyedia tersebut di IG mereka. |
| Pelatihan Model Pribadi | Ada kalanya DP-SGD (Privasi Diferensial - Penurunan Gradien Stokastik) akan membuat proses pelatihan menjadi jauh lebih lambat karena menghancurkan kelangkaan gradien yang dihitung selama backprop. Apakah ada teknik yang sedang dipertimbangkan untuk mengatasi masalah ini atau pendapat tentang masalah ini? | Kami mengetahui beberapa teknik untuk mempertahankan sparsitas di DP-SGD (misalnya, ini), dan kami sedang mempelajari dukungan untuk jenis teknik ini di infrastruktur pelatihan model pribadi. Kami akan membagikan info terbaru seiring perkembangannya dan kami menerima masukan tambahan di sini. |
| Penargetan Negatif | Minta info terbaru tentang peluncuran fungsi pemfilteran negatif IG yang dijelaskan di sini. | Seperti yang dijelaskan dalam respons kami di sini, kami berencana untuk mendukung IG negatif dalam bid PA API. Kami akan membagikan linimasa peluncuran jika sudah tersedia dan kami menerima masukan tambahan di sini. |
| Bidding | Apakah dapat menggabungkan beberapa IG saat mengajukan bid? | Saat ini, hal ini tidak dapat dilakukan dengan PA API. PA API didasarkan pada desain bahwa IG terkait dengan informasi yang diketahui satu situs tentang pengguna, yang telah menjadi inti dalam diskusi dengan ekosistem secara keseluruhan. Pendekatan ini memungkinkan teknologi iklan membuat berbagai solusi yang membantu pengiklan memperluas audiens pihak pertama mereka di seluruh web. Kami menyadari bahwa proposal Ads Selection API Microsoft memang mengusulkan desain yang berbeda, yaitu audiens didasarkan pada informasi di seluruh situs. Meskipun kami akan terus memantau pendekatan mereka, kami ingin melihat lebih banyak diskusi dari ekosistem, termasuk komunitas privasi, sebelum kami mempertimbangkan perubahan serupa pada Chrome. |
| Iklan Native | Kekhawatiran terkait apakah PA API dapat mendukung berbagai format dan persyaratan rendering Iklan Native secara memadai atau tidak, dan apakah PA API memungkinkan fleksibilitas dan pengoptimalan materi iklan yang diperlukan untuk iklan native yang efektif. | Kami secara aktif meneliti untuk memberikan dukungan lebih lanjut bagi Iklan Native, dan kami menerima masukan tambahan dari ekosistem. |
| Pelaporan | Permintaan untuk meningkatkan keandalan skrip pelaporan yang bersaing untuk mendapatkan resource dengan skrip bidding dan mungkin hilang saat frame lelang yang sedang berjalan dialihkan. | Kami berharap dapat segera memposting respons ke GitHub, tetapi kami tidak memperkirakan bahwa masalah ini akan secara signifikan memengaruhi pelaporan yang valid dalam praktiknya |
| Penggantian Makro | Penggantian makro yang diteruskan konfigurasi lelang tidak berfungsi dengan beberapa konfigurasi pihak ketiga. | Penyebab utamanya adalah tidak semua traffic berlabel Mode A/B mengaktifkan fitur ini. Baru-baru ini kami memutuskan untuk mengaktifkan fitur ini (dan fitur lainnya dalam situasi yang sama) di semua traffic berlabel Mode A/B. Kami memperkirakan perubahan ini akan dilakukan selama Kuartal 1 2025. Kami menerima masukan tambahan di sini. |
| Dokumentasi | Meminta klarifikasi karena tampaknya ada perbedaan dalam dokumentasi terkait satuan pengukuran untuk nilai keaktualan dalam objek browserSignals dalam generateBid(). |
Kami telah merespons hal ini secara lebih mendetail di sini dan memperbarui dokumentasi kami sebagaimana mestinya. Jawaban yang benar adalah satuan pengukurannya adalah milidetik. |
| Pelaporan | Meminta pelaporan pihak ketiga; meskipun DSP dan SSP menerima notifikasi tayangan dari Chrome, penyedia teknis lapisan tengah secara default tidak menerimanya. | Saat ini kami sedang membahas permintaan fitur ini di sini dan menerima masukan tambahan. |
| Grup Minat | Minta panduan tentang cara mengecualikan interestGroupBuyers secara dinamis saat menggunakan alur kerja lelang IG paralel. | Kami telah memberikan panduan tentang hal ini di sini. |
| Iklan Native | Lelang PA API independen untuk pemuatan halaman tertentu mencegah pemfilteran iklan di halaman yang sama. | Dukungan Iklan Native lebih lanjut, termasuk widget rekomendasi yang dikenal sebagai "native" dan memiliki beberapa iklan dalam satu unit, adalah area riset yang aktif dan kami menyadari bahwa desain saat ini mungkin tidak mendukung pemfilteran iklan di halaman yang sama, dan perlindungan lainnya seperti Frame Berpagar juga dapat mencegah hal ini lebih lanjut. |
| Iklan Native | Fitur PA API yang ada seperti pemindaian materi iklan, pelaporan, dll., yang mengandalkan sinyal berbasis URL mungkin perlu disesuaikan untuk menangani objek JSON yang digunakan dalam materi iklan native. | Dukungan Iklan Native lebih lanjut adalah area riset yang aktif dan kami sedang menilai kelayakan adaptasi PA API untuk membantu rendering iklan native. |
| Verifikasi Iklan | Keamanan merek pihak ketiga di PA API terpengaruh karena latensi dan batasan penyimpanan dalam cache perBuyerSignals, yang bermasalah untuk konten dinamis. | Kami memahami bahwa SSP dan DSP perlu menentukan TTL optimal untuk penyimpanan dalam cache yang menyeimbangkan sasaran pembentukan traffic dan TTL maksimum keamanan merek untuk memastikan data yang di-cache tetap relevan untuk keamanan merek. Kami sedang menyelidiki masalah ini dan akan membagikan kabar terbaru seiring perkembangannya. |
| Verifikasi Iklan | Penggantian makro FullpageURL oleh SSP diperlukan untuk melakukan pengukuran keamanan merek pasca-bid. | deprecatedReplaceInURN adalah saran saat ini untuk SSP agar memberikan sinyal ini. |
| Verifikasi Iklan | Kurangnya standarisasi dalam format makro yang digunakan oleh SSP untuk verifikasi pasca-bid berpotensi menyebabkan inkonsistensi dan error dalam pemrosesan dan analisis data. | SSP dan Pengverifikasi Iklan harus berkolaborasi secara langsung untuk menentukan pedoman dan spesifikasi yang jelas terkait penggunaan makro guna mendorong standarisasi format makro di seluruh SSP untuk memastikan konsistensi dan mencegah error dalam pemrosesan dan analisis data. Ini adalah aktivitas yang cocok untuk organisasi standar iklan seperti IAB Tech Lab. |
| Verifikasi Iklan | Pengiklan dan Pengverifikasi iklan memerlukan mekanisme untuk menautkan pemeriksaan pra-bid dan pasca-bid untuk konteks penayang yang sama guna proses debug dan pemecahan masalah. | Salah satu opsi untuk verifikasi pasca-bid adalah melalui sinyal berbasis lelang dan kampanye yang digabungkan ke dalam pelaporan tingkat peristiwa. Hal ini dapat memungkinkan penggabungan dengan log keputusan pra-bid. Kami sedang mempelajari kemungkinan pola untuk mencapai hal ini dan akan membagikan info terbaru saat fitur ini berkembang. |
| Verifikasi Iklan | Permintaan untuk mempelajari solusi server Nilai Kunci Tepercaya (TKV) (milik DSP dan milik Pengverifikasi Iklan) untuk pra-bid dan mengatasi batasan frame berpagar untuk pasca-bid. | Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem di sini untuk menemukan solusi yang dapat mendukung pengamanan merek pra-bidding, dan memudahkan persyaratan koordinasi antarpihak. |
| Iklan Native | Minta audit rendering pasca-bid sisi jual untuk iklan native. | Dukungan Iklan Native lebih lanjut masih dalam tahap riset aktif dan kami mempertimbangkan untuk menyesuaikan fitur yang ada seperti ini untuk membantu rendering iklan native. |
Protected Auction (Layanan B&A)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Latensi | Belum ada mitigasi yang memadai untuk latensi. Meskipun Layanan B&A dapat mengurangi masalah ini dalam jangka panjang, Google belum berkomitmen untuk menyediakannya secara luas sebelum perubahan pada 3PC di Chrome. | Kami telah melakukan beberapa peningkatan pada latensi di perangkat selama beberapa kuartal terakhir. Kami juga membuat dan menskalakan layanan B&A sesuai kebutuhan. Baru-baru ini kami memperbarui panduan praktik terbaik latensi yang menyertakan informasi selengkapnya tentang cara memanfaatkan fitur ini. Kami juga terus mengembangkan peningkatan latensi baru, beberapa di antaranya dapat dilihat di sini. |
| (Juga dilaporkan pada kuartal sebelumnya) Keamanan Lelang |
Meminta klarifikasi lebih lanjut tentang pendekatan untuk mencegah/memitigasi upaya untuk merusak lelang di perangkat (misalnya, termasuk apakah Google menganggap hal ini sebagai risiko yang signifikan). | Respons kami tidak berubah dari kuartal sebelumnya: "Mekanisme pelaporan iklan PA API mempertahankan informasi yang digunakan untuk membedakan traffic manusia dari traffic bot saat ini. Selain itu, teknik berbasis domain saat ini untuk menyertakan atau mengecualikan domain dapat digunakan di PA API. Hal ini dijelaskan secara lebih mendetail dalam respons kami terhadap laporan IAB Tech Lab tentang Privacy Sandbox." |
| Solusi Lokal | Kekhawatiran terkait bagaimana pemasok terbesar mungkin tidak mengadopsi Privacy Sandbox atau B&A karena kurangnya dukungan untuk cloud pribadi, dan roadmap yang panjang dan tidak jelas untuk mendukungnya. | Kami berkomitmen untuk memperluas infrastruktur tempat layanan Privacy Sandbox berjalan; baru-baru ini kami mengumumkan dukungan untuk cloud Azure dan melanjutkan penyelidikan kami terkait kemungkinan solusi untuk memberikan pengamanan privasi dan keamanan yang serupa untuk cloud pribadi. Sejak komunikasi kami pada bulan Oktober, kami telah membuat kemajuan saat terus meneliti potensi pendekatan untuk mengamankan privasi pengguna Chrome di Trusted Execution Environment (TEE) On-Premise. Sekarang, kami berada di tahap penelitian yang ingin memvalidasi berbagai pendekatan dengan pemangku kepentingan ekosistem, dan kami berencana untuk mulai mengumpulkan input pada Kuartal 1. Masukan dan kolaborasi ekosistem akan membantu meningkatkan kualitas solusi yang mungkin ada. |
| Pengujian | Apakah Anda dapat membuat TEE untuk menguji solusi pelaporan PA API (Real Time Reporting dan Private Aggregation)? | Untuk pengujian Layanan Agregasi, teknologi iklan dapat menggunakan data pengujian dan alat Pengujian Lokal untuk membuat laporan ringkasan pengujian fungsional. Lihat Codelab Pengujian Lokal di sini. Untuk menguji Agregasi di TEE, teknologi iklan harus menyelesaikan proses pendaftaran seperti yang disebutkan dalam prasyarat Codelab di atas. Kami menerima masukan tambahan tentang permintaan ini di sini. |
| Integrasi K/V Transaksi | Meminta kemampuan untuk mengambil informasi berbasis transaksi dari KV untuk kasus penggunaan bisnis. | Kami sedang mengevaluasi permintaan fitur ini dan akan memberikan info terbaru di GitHub. |
| Pengukuran Transaksi Tanpa Keuntungan |
Meminta sinyal atau kemampuan untuk memahami kapan SSP tidak menang dan alasannya. | Kami sedang mengevaluasi permintaan ini dan akan memberikan info terbaru di GitHub. |
| Permintaan Fitur | Meminta Privacy Sandbox untuk menyediakan struktur kamus guna membantu mencocokkan sekelompok iklan dengan kumpulan ID Transaksi masing-masing. | Kami sedang mengevaluasi permintaan ini, bersama dengan cara lain untuk mengurangi ukuran IG sehubungan dengan penyimpanan ID transaksi. Kami akan memberikan info terbaru di GitHub. |
| Performa | Solusi untuk mengukur kemungkinan peluang lelang iklan yang terlewatkan, mungkin karena ukuran skrip bidding. | Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan di sini. |
| Spesifikasi | Saat ini, B&A hanya membaca kolom prevWins, bukan kolom terbaru prevWinMs yang menggantikan prevWins dalam spesifikasi. | Memang benar bahwa B&A tidak meneruskan durasi dalam milidetik di prevWins ke generatebid(). Chrome mengirimkan durasi dalam detik untuk memastikan lebih sedikit overhead pada payload. Perbaikan di sini adalah agar B&A melakukan konversi dari detik ke milidetik. B&A akan menyediakan prevWins dan prevWinsMs di browserSignals agar kompatibel dengan lelang di perangkat.Perhatikan bahwa, bahkan untuk lelang di perangkat untuk web, prevWins dan prevWinsMs sesuai dengan nilai yang sama dan prevWinsMs = prevWins * 1000. Kami memprioritaskan perbaikan. |
| Dokumentasi | Dokumentasi tidak menjelaskan dengan jelas cara menguji Seller Front End (SFE). Sebaiknya ada panduan pengujian tambahan tepat setelah menyelesaikan deployment serta cara menggunakan Bazel untuk build. | Codelab ini telah dipublikasikan sebagai panduan untuk mempermudah ekosistem yang lebih luas dalam menguji SFE mereka. |
| Deployment | Apakah ada rencana untuk menyediakan biner bawaan untuk B&A? | Kami mempertimbangkan untuk menyediakan biner bawaan untuk B&A, tetapi kami tidak memiliki linimasa yang pasti untuk hal ini. Hingga saat itu, teknologi iklan dapat membuat biner sendiri dan memvalidasi menggunakan hash yang disediakan. |
| Deployment | Apakah semua jenis orkestrasi (server, klien, campuran) harus didukung atau apakah ada jenis yang harus diprioritaskan daripada yang lain? | Kami tidak memiliki rekomendasi spesifik tentang mode yang diterapkan teknologi iklan. Pilihan ini bergantung pada berbagai faktor, tetapi pada akhirnya, bergantung pada apa yang paling sesuai dengan minat pelanggan Anda. |
| Pengujian | Mencari klarifikasi terkait pengujian yang gagal selama build B&A. | Hal ini mungkin disebabkan oleh pengujian yang tidak stabil. Kami telah menyarankan teknologi iklan untuk menggunakan flag --no-tests ke semua perintah build build_and_test_all_in_docker untuk melewati pengujian. |
| Log | Mencari klarifikasi mengapa log di log explorer di GCP diberi tag ke instance VM yang menjalankan SFE saat dalam mode pengujian, tetapi dalam mode produksi, log tidak diberi tag ke instance VM. | Sulit untuk digeneralisasi karena bergantung pada apa yang sebenarnya dilihat, tetapi secara umum: - log dari non_prod mungkin adalah log stderr yang dialihkan oleh penyedia cloud (dalam hal ini, GCP) dan GCP menambahkan tag. - Log yang dihasilkan oleh VM umumnya diberi tag dengan instance VM, sedangkan log yang dihasilkan oleh biner tidak diberi tag oleh GCP. - log dari produk diekspor oleh Open Telemetry di TEE, yang memiliki tag yang berbeda. Berikut beberapa detail tentang apa yang tersedia di non_prod dan prod. |
| B&A | Error 403 pada secret yang tidak ada saat logging OTEL dinonaktifkan. | Masalah ini kini telah diperbaiki sejak update 4.1 dan dokumentasi telah diedit sebagaimana mestinya. |
| B&A | File outputs.tf tidak ada untuk konfigurasi terraform GCP sehingga menyebabkan error. | Hal ini sekarang telah diperbaiki. |
| Pengujian | Error saat mengambil kunci pribadi dalam mode pengujian. | Dalam hal ini, pastikan server berjalan dengan TEST_MODE=true. Lihat penjelasan di sini. |
| Roadmap | Apakah ada rencana untuk getInterestGroupAdAuctionData agar dapat menerima lebih dari satu origin penjual dan menampilkan peta origin penjual ke ciphertext payload B&A? | Ya, penambahan dukungan untuk mengizinkan navigator.getInterestGroupAdAuctionData() menerima beberapa penjual sedang direncanakan. |
| Spesifikasi KV | Dapatkah URL KV (trustedScoringSignalsURL) berpotensi dikirim sebagai promise? | Lihat penjelasan yang diberikan di sini. |
| B&A | Meminta pembuatan header platform baru untuk menunjukkan kepada sisi penjual B&A kemampuan yang diperlukan klien (browser) agar lelang pribadi dapat terjadi. | Saat ini kami sedang membahas permintaan fitur ini di sini dan menerima masukan tambahan. |
| Pembentukan Traffic | Proposal untuk mengurangi biaya inkremental dari hosting server B&A, terutama untuk DSP. | Saat ini kami sedang mendiskusikan proposal ini di sini dan menerima masukan tambahan. |
| Bring-Your- Own-Binary |
Pertimbangkan untuk memperbarui penjelasan untuk secara eksplisit menyatakan bahwa semua biner didukung. | Informasi ini sekarang diperbarui, lihat penjelasannya di sini. |
| Panggilan KV | Apakah generateBid() menunggu semua panggilan penyimpanan Nilai Kunci (KV) selesai, atau berjalan secara independen? Bagaimana pengaruh pengelompokan KV terhadap waktunya? |
Lihat penjelasan yang diberikan di sini. |
| Performa | Meminta dokumentasi tambahan tentang penggunaan kembali skrip bidding dan merekomendasikan setelan header cache control pada skrip. | Dokumentasi telah ditambahkan di sini. |
| Performa | Meminta untuk mempertimbangkan dan mempelajari kemampuan untuk memuat resource (misalnya, skrip bidding) secara asinkron untuk mengurangi latensi lelang di perangkat. | Saat ini kami sedang membahas permintaan fitur ini di sini dan menerima masukan tambahan. |
| Logging Izin | Klarifikasi diperlukan untuk error yang terlihat saat mencoba menggunakan logging izin dengan menetapkan CONSENTED_DEBUG_TOKEN. | Dalam kasus ini, pastikan CONSENTED_DEBUG_TOKEN ada di pengelola secret, ENABLE_OTEL_BASED_LOGGING ditetapkan ke true, dan TELEMETRY_CONFIG ditetapkan ke mode: PROD. Lihat penjelasan di sini yang merujuk ke sumber di sini. |
| Log | Apakah peristiwa forDebuggingOnly tersedia melalui B&A? | forDebuggingOnly untuk B&A telah tersedia untuk lelang penjual tunggal sejak April 2024. Rencana kami adalah segera mengaktifkannya untuk lelang multipenjual. |
| Log Worklet | Permintaan untuk membuat logging worklet kompatibel dengan ChromeDriver. | Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan di sini. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Laporan Debug | Bagaimana laporan Debug ARA akan tersedia untuk teknologi iklan setelah pendekatan yang diperbarui untuk 3PC di Chrome? Apakah teknologi iklan masih memiliki akses ke Laporan Debug ARA untuk pengguna yang mempertahankan 3PC dan mengaktifkan Privacy Sandbox API? |
Teknologi iklan akan memiliki akses ke solusi proses debug berbasis cookie dan tanpa cookie sehubungan dengan pengguna yang mengaktifkan 3PC dan ARA. Jika cookie dinonaktifkan, mereka hanya akan memiliki akses ke solusi debug gabungan. Detail selengkapnya tentang solusi debug tersedia di sini dan di sini. |
| Deteksi Fitur | Minta panduan tentang cara melakukan deteksi fitur untuk ARA di sisi server. | Saat ini, dukungan fitur ARA dapat diidentifikasi berdasarkan penggunaan versi Chrome yang terlihat di string agen pengguna. Kami menerima masukan ekosistem tambahan terkait hal ini. |
| Permintaan Fitur | Meminta agar source_registration_time yang digunakan di shared_info Agregat ARA menjadi lebih terperinci, misalnya dibulatkan ke bawah menjadi satu jam atau satu menit (bukan satu hari) serta dapat dikonfigurasi untuk mempertimbangkan zona waktu (saat ini hanya UTC). | Membulatkan kolom source_registration_time ke hari terdekat adalah mekanisme privasi yang digunakan untuk mengurangi kemampuan teknologi iklan agar dapat mengaitkan pengguna tertentu ke pendaftaran sumber tertentu. Saat ini, source_registration_time didasarkan pada UTC dan teknologi iklan dapat menyesuaikan laporan iklannya untuk memperhitungkan hal ini. Kami menerima masukan ekosistem tambahan terkait permintaan ini di sini. |
| Spesifikasi | Permintaan untuk memperjelas spesifikasi "trigger_data" dan "priority", terutama saat digunakan dengan nilai array. | Kolom ini tidak menerima nilai array. Tanda kurung siku di penjelasan tidak mewakili array, tetapi menunjukkan bahwa teks tersebut bukan contoh nilai, melainkan placeholder dengan deskripsi. Seperti yang ditunjukkan teks dalam tanda kurung siku: - trigger_data adalah int-64 - priority adalah int-64 bertanda tangan Kedua kolom tidak menerima nilai array. Sebaiknya pertimbangkan juga untuk menggunakan alat validator header untuk ARA guna bereksperimen dengan berbagai nilai dan mengalami error jika dokumentasi membingungkan. |
| Dukungan Iklan Accelerated Mobile Pages (AMP) | Apakah ARA mendukung iklan AMP? | Proposal kami tentang cara mendukung AMP tersedia di sini dan kami menerima masukan tambahan. |
| Spesifikasi | URL mana yang akan dianggap sebagai "situs sumber" untuk iklan tersemat multi-lapis untuk ARA? | URL dari situs level teratas. |
| (Juga dilaporkan pada kuartal sebelumnya) Permintaan Fitur |
Meminta agar nilai minimum event_report_window diturunkan dari 3.600 detik (1 jam) menjadi 1.800 detik (30 menit). | Menentukan periode pelaporan minimum memerlukan keseimbangan antara pertimbangan utilitas dan privasi. Periode pelaporan minimum 1 jam untuk laporan tingkat peristiwa sangat penting untuk menjaga privasi dan mengurangi jenis serangan rekonstruksi histori tertentu. Kami menerima masukan tambahan tentang permintaan ini di sini. |
| Derau | Mencari pemahaman yang lebih mendalam tentang cara derau diterapkan dalam laporan tingkat peristiwa ARA untuk memastikan interpretasi dan penggunaan data yang akurat. | Detail selengkapnya tersedia di sini dan di sini. |
| Pelaporan | shared_info Laporan Gabungan tidak lagi berisi source_registration_time secara default. | Hal ini disebabkan oleh perubahan API, dan dijelaskan secara lebih mendetail di sini. |
| Pelaporan | filtering_id tidak ada di tab "Laporan Gabungan" pada UI chrome://attribution-internals/. |
filtering_id saat ini terlihat di detail tab "Pendaftaran Pemicu" saat Anda mengklik baris, yang memungkinkan Anda mengonfirmasi validitasnya. Kami menyadari manfaat menampilkannya di tab "Laporan Gabungan", dan telah membahasnya di sini. |
| Sumber Atribusi | Minta klarifikasi tentang cara kerja sumber atribusi. | Penjelasan tersedia di sini. |
| Atribusi Aplikasi ke Web | Meminta panduan untuk penerapan jika ada ketidakpastian apakah sumbernya akan berupa OS atau web. | Panduan tersedia di sini. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Permintaan Fitur | Meminta waktu tunggu yang dapat dikonfigurasi untuk AgS dan/atau visibilitas yang lebih besar ke status tugas untuk operasi jangka panjang. | Kami sedang mempertimbangkan fitur untuk mendukung pemantauan tugas yang berjalan lama. Kami menerima masukan ekosistem tambahan terkait hal ini. |
| Terraform | Terraform mencoba mengubah Kebijakan IAM akun meskipun service_account_token_creator_list tidak ditetapkan. | Developer dapat menambahkan izin yang ditambahkan di file modul lokal/adtech_setup/main.tf. |
| Permintaan Dokumentasi | Meminta dokumentasi atau codelab yang menjelaskan cara memantau kondisi layanan agregasi. | Deskripsi alarm yang ada yang dapat digunakan untuk memantau kesehatan layanan dan tugas dapat ditemukan di file terraform operator yang relevan (alarms.tf dan monitoring.tf) di repositori coordinator-services-and-shared-libraries. Kami akan memublikasikan dokumentasi dan panduan tambahan tentang cara memantau tugas layanan agregasi. |
| Penskalaan | Bagaimana cara memantau masalah penskalaan? | Kami memublikasikan versi terbaru panduan ini yang mendokumentasikan skala Layanan Agregasi yang lebih tinggi. Saat ini tidak ada sinyal langsung yang menunjukkan kegagalan terjadi karena mesin tidak dapat mendukung skala tugas. Sinyal tidak langsung mencakup: konsumsi memori 90% sebelum kegagalan, tugas yang gagal berulang kali. Kami menerima masukan ekosistem tambahan terkait perlunya sinyal tersebut. |
| Spesifikasi | Berapa waktu proses batch laporan AgS yang biasa? | Lihat panduannya di sini. |
Private Aggregation API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Permintaan Fitur | Permintaan untuk mengizinkan kontribusi nilai float (termasuk nilai negatif) ke contributeToHistogramOnEvent dengan sensitivitas 2^16 | Saat ini kami sedang mendiskusikan proposal ini di sini dan menerima masukan tambahan. |
Membatasi Pelacakan Tersembunyi
Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna
Tidak ada masukan yang diterima kuartal ini.
Perlindungan IP (sebelumnya bernama Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Geolokasi | Meminta file geolokasi Perlindungan IP. | File yang memetakan IP ke lokasi perkiraan untuk Perlindungan IP tersedia di sini. Perhatikan bahwa file ini diperbarui secara berkala. |
Mitigasi Pelacakan Kembali
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Daftar yang diizinkan | Posisi yang diperbarui tidak lagi membahas daftar yang diizinkan atau mekanisme serupa yang akan independen dari proses pengambilan keputusan Google. | Google tidak berencana untuk memiliki daftar yang diizinkan yang terkait dengan mitigasi pelacakan pantulan (BTM); perlindungan diterapkan secara seragam ke semua domain. |
| Kepatuhan | ICO harus memiliki otoritas terkait kepatuhan terkait privasi. | Status kepatuhan tidak terkait dengan penerapan BTM dan Google tidak membuat keputusan apa pun terkait kepatuhan dalam menerapkan BTM. |
| Persaingan | Tampaknya Google dapat diizinkan untuk menutup akses pesaing PET menggunakan BTM (atau tindakan lainnya), lalu menggunakan kebijaksanaannya untuk mengizinkan mereka kembali ke pasar. Proses banding saat ini dapat mencegah pesaing PET untuk sementara menggunakan BTM atau tindakan serupa. | Proposal BTM saat ini ditujukan untuk pelacakan pantulan sebagai teknik. Meskipun Google berupaya untuk menghindari pelanggaran kasus penggunaan tertentu yang mungkin melibatkan teknik serupa, Google tidak berencana untuk memberikan pengecualian individual dari BTM. Dengan demikian, pertanyaan tentang Google yang menggunakan kebijaksanaan atas kehadiran pesaing tidak akan muncul. |
Memperkuat batasan privasi lintas situs
Set Situs Terkait (sebelumnya Set Pihak Pertama)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada kuartal sebelumnya) Batas Domain Set Situs Terkait (RWS) |
Batas saat ini untuk lima domain terkait tidak cukup tinggi untuk mencapai kasus penggunaan pengukuran lintas situs. | Respons kami serupa dengan kuartal sebelumnya: Saat ini, kami tidak berencana untuk menaikkan batas numerik. Batasan ini ditetapkan berdasarkan pertimbangan privasi pengguna, masukan dari pemangku kepentingan ekosistem di W3C, dan pertimbangan implementasi yang sebanding di browser lain. Untuk informasi tambahan, lihat postingan blog kami (1, 2). Sebaiknya periksa kasus penggunaan yang memerlukan akses cookie lintas situs di luar batas numerik, dan pertimbangkan untuk memanfaatkan panduan kami untuk kasus penggunaan identitas, penyematan yang diautentikasi, dan kasus penggunaan iklan. Kami menerima masukan tambahan tentang masalah ini di sini. |
Fenced Frames API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Iklan Native | Rendering iklan native di Frame Pagar menimbulkan tantangan karena mewarisi gaya penayang terbatas karena batasan komunikasi antara iframe dan halaman penayang. | Dukungan lebih lanjut untuk iklan native, termasuk dukungan setelah penerapan penerapan Frame Pagar, masih dipelajari secara aktif. Kami menerima masukan tambahan tentang masalah ini di sini. |
Shared Storage API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penggunaan API | Shared Storage API tidak tersedia di beberapa perangkat saat Privacy Sandbox API lainnya berfungsi. | Perilaku ini diharapkan untuk sebagian kecil pengguna (sekitar 1%) yang merupakan bagian dari eksperimen penahanan Penyimpanan Bersama. Penyiapan eksperimental ini digunakan untuk mengevaluasi performa dan adopsi API dalam berbagai skenario. |
| Penggunaan API | Apakah operasi tulis ke Shared Storage terjadi di origin penayang atau origin skrip bidding? Pengujian awal menunjukkan tidak ada operasi tulis saat origin penayang berbeda dengan origin skrip. | Masalah ini telah diselesaikan, dan hanya tetap terbuka jika ada kemungkinan bug devtools. Detail selengkapnya tersedia di sini. Penyimpanan Bersama menulis ke asal pembeli dalam konteks bidding panggilan generateBid. Operasi tulis tidak terikat dengan origin penayang, meskipun halaman penayang berada di domain yang berbeda. |
| Penggunaan API | Apa pengamanan yang diterapkan agar pihak tidak bertanggung jawab tidak dapat membaca laporan Penyimpanan Bersama? | Penyimpanan Bersama dipartisi dengan memanggil asal sehingga pelaku kejahatan atau teknologi iklan tidak dapat membaca data Penyimpanan Bersama dari teknologi iklan lain. Laporan Agregasi Pribadi dikirim langsung ke origin yang sama melalui TLS sehingga tidak dapat disadap. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Cookie yang Dipartisi | Ada penanganan cookie yang tidak konsisten di berbagai port localhost di Chrome dan Firefox, terutama saat menggunakan atribut Partisi. | Firefox memperlakukan localhost dengan port yang berbeda sebagai kunci partisi yang berbeda. Meskipun perilaku ini sesuai dengan prinsip keamanan, perilaku ini menyimpang dari spesifikasi dan pendekatan Chrome. Kami berharap dapat membahas hal ini dengan browser lain dalam diskusi spesifikasi HTML, dan akan memberi tahu ekosistem jika hal ini menyebabkan perubahan pada kunci partisi CHIPS. Kami menerima masukan tambahan tentang masalah ini di sini. |
| Cookie yang Dipartisi | Draf Clear-Site-Data salah mengizinkan penghapusan di luar partisi situs yang memunculkan, yang bertentangan dengan diskusi sebelumnya yang dirujuk di sini. | Ini adalah bug dalam dokumen spesifikasi standar, yang akan segera kami perbaiki. Perilaku yang benar ditentukan di bagian ini dalam penjelasan, dan selaras dengan perilaku yang selaras dengan browser lain di repositori penjelasan partisi penyimpanan. Penerapan Chrome sudah beroperasi dengan benar. |
FedCM
Tidak ada masukan yang diterima kuartal ini.
Memerangi spam dan penipuan
Private State Token API (dan API lainnya)
Tidak ada masukan yang diterima kuartal ini.