Laporan kuartalan untuk K1 2025 yang merangkum masukan ekosistem yang diterima tentang proposal Privacy Sandbox dan respons Chrome.
Google telah menyiapkan laporan kuartalan ini sebagai bagian dari Komitmennya kepada Competition and Markets Authority ('CMA') berdasarkan paragraf 12, 17(c)(ii), dan 32(a). Laporan ini mencakup progres Google terkait proposal Privacy Sandbox; perkiraan waktu yang diperbarui; penjelasan substantif tentang cara Google mempertimbangkan pengamatan yang dilakukan oleh pihak ketiga; dan ringkasan interaksi antara Google dan CMA, termasuk masukan dari CMA dan pendekatan Google untuk mengatasi masukan tersebut.
Google telah terus memberi tahu CMA tentang progres proposal Privacy Sandbox dalam Rapat Status reguler yang dijadwalkan sesuai dengan paragraf 17(b) Komitmen. Selain itu, tim ini mengelola dokumentasi developer yang memberikan ringkasan untuk fitur iklan pribadi inti dan perubahan cookie, beserta implementasi API dan informasi status. Update utama dibagikan di blog developer bersama dengan update yang ditargetkan yang dibagikan ke milis developer individual.
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 |
|---|---|---|
| Pilihan Pengguna | Belum jelas seperti apa pendekatan Google yang diperbarui untuk memperluas pilihan pengguna, bagaimana pendekatan tersebut akan ditampilkan kepada pengguna, dan rasio keikutsertaan/ketidakikutsertaan yang diperkirakan. Informasi lebih lanjut diperlukan untuk membedakannya dengan penghentian penggunaan cookie pihak ketiga. | Pada April 2025, Google memublikasikan postingan blog tentang Langkah berikutnya untuk Privacy Sandbox dan perlindungan pelacakan di Chrome, yang mengumumkan bahwa Google telah membuat keputusan untuk mempertahankan pendekatan saat ini dalam menawarkan cookie pihak ketiga kepada pengguna di Chrome, dan tidak akan meluncurkan perintah mandiri baru untuk cookie pihak ketiga. Kami akan memberikan informasi lebih lanjut jika tersedia. |
| Pelacakan Sidik Jari | Google tidak membagikan informasi kepada penayang atau pemasar tentang cara mereka dapat mengandalkan alternatif apa pun untuk Sistem Iklan Google tanpa menggunakan identitas konsumen yang lebih berisiko sebagai kunci pencocokan umum (yaitu sidik jari). | Kami telah menyoroti beberapa Sistem Iklan non-Google yang menawarkan solusi kepada penayang dan pemasar yang sebagian dibuat di Privacy Sandbox API. Hal ini mencakup Sistem Iklan non-Google di seluruh pasar dan saluran. Detail selengkapnya dan studi kasus tersedia di bagian Referensi Bisnis di privacysandbox.com di sini. |
| Privacy Sandbox | Privacy Sandbox API akan mengganti bahan data internet dengan produk jadi Google sendiri. Karena alternatif Google adalah API, Google menawarkan akses ke produk yang dimiliki dan dikontrolnya, serta produk yang tunduk pada persyaratan dan ketentuan yang menjadi pertimbangan Google. Hal ini bukan pengganti komponen yang digunakan oleh orang lain untuk membuat produk jadi mereka sendiri. | Privacy Sandbox API telah dikembangkan dan diterapkan setelah melakukan interaksi yang ekstensif dengan regulator dan berbagai pemangku kepentingan ekosistem. Seperti teknologi platform lainnya, Privacy Sandbox API harus mempertimbangkan bahwa API tersebut akan digunakan sebagai komponen dalam produk jadi pihak lain dan kami menyambut baik upaya ekosistem untuk mengembangkan teknologi tambahan yang dapat digunakan bersama Privacy Sandbox API. |
| Pilihan Pengguna | Meminta informasi tentang apakah pendekatan Google yang diperbarui untuk 3PC di Chrome akan memenuhi persyaratan peraturan tertentu, yang dapat memengaruhi pengalaman platform pengelolaan izin pemangku kepentingan. | Pada April 2025, Google memublikasikan postingan blog tentang Langkah berikutnya untuk Privacy Sandbox dan perlindungan pelacakan di Chrome, yang mengumumkan bahwa Google telah membuat keputusan untuk mempertahankan pendekatan saat ini dalam menawarkan cookie pihak ketiga kepada pengguna di Chrome, dan tidak akan meluncurkan perintah mandiri baru untuk cookie pihak ketiga. Kami akan memberikan informasi lebih lanjut jika tersedia. |
| Linimasa & Adopsi Privacy Sandbox | Teknologi iklan telah menjeda pengujian Privacy Sandbox API dan mencari alasan yang lebih kuat untuk berinvestasi kembali dalam teknologi ini untuk aktivitas produk dan pemasaran. Keputusan reinvestasinya sangat dipengaruhi oleh kebutuhan akan kejelasan yang lebih besar terkait linimasa Pilihan Pengguna, serta kekhawatiran seputar latensi Protected Audience API (PA API) dan roadmap B&A. Selain itu, ada kekhawatiran tentang peninjauan Komitmen CMA mendatang, terutama terkait peran Google sebagai pendorong utama teknologi Privacy Sandbox tanpa mengandalkan ID pihak ketiga, dan arah keseluruhan inisiatif di masa mendatang untuk menginformasikan strategi investasi. | Pada April 2025, Google memublikasikan postingan blog tentang Langkah berikutnya untuk Privacy Sandbox dan perlindungan pelacakan di Chrome, yang mengumumkan bahwa Google telah membuat keputusan untuk mempertahankan pendekatan saat ini dalam menawarkan cookie pihak ketiga kepada pengguna di Chrome, dan tidak akan meluncurkan perintah mandiri baru untuk cookie pihak ketiga. Kami akan memberikan informasi lebih lanjut jika tersedia. Lelang Chrome PA API 35% lebih cepat dari tahun ke tahun. Selain itu, kami melihat peningkatan yang signifikan dalam penggunaan lelang paralel, yang memberikan keuntungan yang lebih besar untuk lelang tersebut. Roadmap B&A kami saat ini tersedia di sini. |
| Linimasa Privacy Sandbox | Apa yang diperbarui di halaman Linimasa Privacy Sandbox? | Ringkasan untuk Topics API baru-baru ini ditambahkan ke halaman Linimasa Privacy Sandbox. |
| Privacy Sandbox | Apakah ada makalah riset tentang Privasi vs. Utilitas untuk membantu memahami dampak Privacy Sandbox terhadap pendapatan? | Studi Kasus Pasar yang Relevan yang membahas pertanyaan ini tersedia di sini dan hasil dari pengujian Privacy Sandbox API tersedia di sini. |
| Penerapan Privacy Sandbox | Pengguna awal melaporkan tantangan awal dengan Privacy Sandbox API karena lambatnya penerapan oleh perusahaan besar, yang memengaruhi peluncuran pengujian. Namun, meskipun demikian, pendekatan kolaboratif dan responsif tim Privacy Sandbox terhadap masukan sangat diapresiasi. | Kami menghargai masukan dari pengguna awal. Kami berkomitmen untuk berkolaborasi dengan pengguna awal dan akan terus berinteraksi dengan ekosistem serta mengumpulkan masukan saat kami mengevaluasi peran teknologi Privacy Sandbox dalam mendukung ekosistem. |
| Pengujian Chrome | Kekhawatiran terkait kemampuan untuk melanjutkan pengujian Privacy Sandbox secara efektif setelah penghapusan label pengujian yang menyoroti perbedaan kualitas traffic yang signifikan antara Chrome dengan 3PC dinonaktifkan (Mode B) dan pengguna yang secara pribadi menonaktifkan 3PC di setelan Chrome. | Respons kami serupa dengan kuartal sebelumnya: Tim Privacy Sandbox memahami bahwa perusahaan ingin terus menggunakan label penghentian penggunaan cookie. Proses untuk memperpanjang ketersediaan label mirip dengan memperpanjang uji coba origin. Dukungan untuk label telah diperpanjang beberapa kali. Kami berencana mengusulkan perluasan dukungan lebih lanjut untuk label penghentian penggunaan cookie dan akan membagikan info terbaru di blink-dev jika tersedia. |
Pendaftaran & Pengesahan
Tidak ada masukan yang diterima kuartal ini.
Menampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Memilih Ikut Serta/Tidak Ikut Serta | Apakah konfirmasi Google bahwa Google Penelusuran tidak akan menggunakan keputusan situs untuk memilih tidak ikut Topics API sebagai sinyal peringkat akan membatasi Google dalam menggunakan keputusan situs untuk memilih ikut Topics API sebagai sinyal peringkat? | Respons kami serupa dengan kuartal sebelumnya: Tim Privacy Sandbox belum berkoordinasi atau meminta organisasi Penelusuran untuk menggunakan peringkat halaman sebagai insentif bagi situs untuk mengadopsi Topics API. Google Penelusuran tidak akan menggunakan keputusan situs untuk mendukung (atau tidak mendukung) Topics API sebagai sinyal penentu peringkat. |
| Kemampuan Observasi Penggunaan | Meminta mekanisme visibilitas untuk SSP atau teknologi iklan umum agar dapat melihat apakah penerapan Topics API mereka digunakan di web. | Kami sedang mengevaluasi dukungan untuk fungsi ini, dan kami menyambut masukan tambahan dari ekosistem jika fitur ini memiliki prioritas tinggi. |
| Privasi | Pertanyaan tentang izin dan potensi identifikasi ulang. | Saat ini kami sedang membahas masalah ini di sini dan menerima masukan tambahan. |
Protected Audience API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| PA API & GAM/AdX | Google tidak akan mengirimkan permintaan GAM/AdX kepada penayang yang ingin mengandalkan server iklan penayang saingan. Google harus memungkinkan penayang saingan memilih penjual lelang PA API tingkat teratas alternatif untuk mengontrol lelang akhir. Informasi dari PA API akan tersedia untuk GAM, tetapi dibatasi untuk SSP saingan. Akibatnya, penayang tidak dapat membandingkan performa permintaan yang bersumber dari PA API di GAM, seperti dari AdX atau dari SSP yang terintegrasi ke dalam PA API. | Respons Chrome: Standar PA API dirancang agar fleksibel dan memungkinkan berbagai pihak menjalankan lelang tingkat teratas. Pilihan ini bergantung pada implementasi dan kemampuan spesifik yang ditawarkan oleh server iklan penayang (baik GAM maupun yang lain) dan perusahaan lain yang berpartisipasi dalam ekosistem. Desain PA API yang berfokus pada privasi membatasi pelaporan terperinci untuk semua peserta secara konsisten. Data spesifik yang dilaporkan dari lelang PA API itu sendiri tunduk pada aturan dan batasan pelindung privasi yang ditentukan API yang sama untuk semua peserta, termasuk SSP apa pun. Penerbit menggunakan laporan gabungan yang menjaga privasi dari PA API untuk mengevaluasi performa. Hal ini memungkinkan penilaian keseluruhan kontribusi permintaan yang bersumber melalui PA API dan memungkinkan perbandingan dengan saluran permintaan lainnya, yang konsisten dengan prinsip privasi berdasarkan desain API. Respons yang diberikan oleh Google Ad Manager: Penayang tidak diwajibkan untuk menggunakan fungsi server iklan GAM guna mengakses permintaan AdX. Selain itu, PA API tidak bergantung pada siapa yang memulai lelang baik dalam desain penjual tunggal maupun multi-penjual. |
| Penjual Tingkat Teratas | Penjual Tingkat Teratas (TLS) memiliki akses ke informasi yang tidak dimiliki oleh penjual komponen lainnya, sehingga menimbulkan kekhawatiran tentang akses yang tidak setara ke informasi. Meskipun entitas mana pun dapat menjadi TLS, untuk mengakses permintaan AdX, penayang diwajibkan untuk menggunakan GAM sebagai server iklan penayang. Hal ini menciptakan insentif untuk menggunakan GAM sebagai server iklan penayang, sehingga menciptakan keunggulan kompetitif bagi Google. | Respons Chrome: Desain PA API tidak menentukan entitas mana yang dapat bertindak sebagai TLS. Peran TLS memerlukan koordinasi lelang dan akses ke informasi lelang terkait sesuai dengan struktur API. Respons yang diberikan oleh Google Ad Manager: Kami telah mempertahankan fokus yang kuat pada keadilan lelang selama bertahun-tahun, termasuk janji kami bahwa tidak ada harga dari sumber iklan tanpa jaminan penayang, termasuk harga item baris tanpa jaminan, yang akan dibagikan kepada pembeli lain sebelum mereka mengajukan bid dalam lelang, yang kemudian kami tegaskan kembali dalam komitmen kami kepada Otoritas Persaingan Prancis. Untuk lelang PA API, kami bermaksud menepati janji kami dan tidak membagikan bid peserta lelang kepada peserta lelang lainnya sebelum lelang selesai di lelang multi-penjual. Untuk memperjelas, kami tidak akan membagikan harga lelang kontekstual dengan lelang komponen apa pun, termasuk lelang kami sendiri, seperti yang dijelaskan dalam pembaruan ini. Selain itu, kami tidak menggunakan informasi tentang konfigurasi lelang komponen, termasuk sinyal yang diberikan oleh pembeli ke SSP, sebagai bagian dari lelang kami sendiri. Selain itu, seperti yang dinyatakan di atas, GAM tidak mewajibkan penayang menggunakan fungsi server iklannya untuk mengakses permintaan AdX. Terakhir, seperti yang disebutkan sebelumnya dalam laporan Kuartal 2 / Kuartal 3 2024 Google, platform sisi beli Google – Google Ads (sebelumnya AdWords) dan DV360 – membeli tayangan iklan dari bursa non-Google, termasuk melalui PA API. |
| PA API & GAM/AdX | Penayang sulit memahami cara mengaktifkan PA API di 100% inventaris karena pelabelan opsi tidak menjelaskan tujuannya. Untuk SSP, yang cara utamanya mengakses inventaris sering kali melalui lelang multi-level dengan GAM yang bertindak sebagai TLS, tidak ada cara efektif untuk melakukan pengujian atau memonetisasi melalui PA API tanpa tunduk pada GAM. | Respons Chrome: Standar PA API menentukan peran teknis (seperti TLS dan penjual komponen) serta proses lelang, sehingga memungkinkan fleksibilitas dalam platform yang menjalankan peran ini. Aktivitas operasional—seperti konfigurasi, koordinasi, dan perjanjian—dikelola oleh pihak pelaksana (penayang, SSP, penyedia TLS) untuk memfasilitasi partisipasi menggunakan framework PA API. Respons yang diberikan oleh Google Ad Manager: Seperti yang dijelaskan di Pusat Bantuan kami, Ad Manager menawarkan kontrol kepada penayang untuk mengaktifkan pengujian dengan penjual komponen non-Google, seperti SSP lainnya, di 100% inventaris penayang tempat API tersedia untuk digunakan (mengganti sampling atau throttling yang mungkin diterapkan GAM). Jika penayang mengaktifkan kontrol ini, setiap kali penjual komponen non-Google memberikan konfigurasi lelang, GAM akan mencoba menjalankan lelang tingkat teratas dengan menyertakan lelang komponen yang diberikan, asalkan penayang telah mendapatkan izin pengguna yang diperlukan untuk melakukannya. GAM menjelaskan kepada penayang bahwa kontrol ini dapat memengaruhi performa, sehingga penayang dapat membuat keputusan yang tepat. |
| Sisi server vs. Di perangkat | Solusi sisi server, seperti Bidding dan Lelang (B&A), berpotensi untuk mengatasi pembentukan traffic sekaligus menjaga privasi. Solusi sisi server adalah satu-satunya jalur yang dapat ditempuh dan Google harus meninggalkan solusi di perangkat. | Privacy Sandbox bertujuan untuk mendukung solusi lelang sisi server (layanan B&A) dan di perangkat, yang memberikan opsi untuk memenuhi berbagai kebutuhan dan kasus penggunaan teknologi iklan. |
| Keamanan Lelang | Serangan terhadap bid PA API pada dasarnya membuat bidding dan lelang di perangkat tidak memenuhi syarat. Masalah ini tidak dianggap telah diselesaikan oleh pemangku kepentingan dan mereka terus meminta jaminan teknis untuk memastikan bid PA API tidak dimodifikasi serta mode debug yang lengkap untuk memberikan deteksi insiden real-time dan proses debug yang efisien. | Memastikan integritas lelang PA API, termasuk memitigasi potensi serangan, adalah fokus utama Privacy Sandbox. Desain API ini menggabungkan langkah-langkah integritas, dan kami menyambut diskusi teknis lebih lanjut tentang masalah tertentu. Kami mempresentasikan dan membahas daftar mendetail tentang potensi serangan pada PA API dan mitigasi kami selama pertemuan Grup Komunitas Anti-Penipuan W3C pada Mei 2024. Kami menerima diskusi dan masukan lebih lanjut tentang potensi 'serangan terhadap bid PA API' yang menjadi perhatian. |
| Traffic Tanpa Cookie | Apakah akan ada cara untuk mengaktifkan PA API hanya pada traffic tanpa cookie untuk pengujian atau tujuan lainnya? | Teknologi iklan dapat mengidentifikasi apakah 3PC ada atau tidak. Hal ini dijelaskan secara lebih mendetail di sini. |
| ID kursi | Sehubungan dengan proposal ID Kursi, pengetahuan tentang ID kursi sangat penting untuk sebagian besar permintaan bid yang menimbulkan kekhawatiran tentang pengikatan ID kursi ke pendaftaran materi iklan. Selain itu, apakah hal ini hanya berlaku untuk "iklan utama" atau juga untuk iklan komponen? | Proposal BuyerAndSellerReportingId mengatasi masalah terkait kurangnya ID Kursi pembeli selama pendaftaran materi iklan untuk iklan utama. ID ini bertujuan untuk menyampaikan ID Kursi pembeli kepada penjual. Kami sedang mengevaluasi dukungan untuk iklan komponen. |
| Pemantauan dan Pelaporan | Permintaan fitur untuk Pemantauan Real-Time (RTM) untuk (1) mengirim laporan RTM untuk lelang yang dibatalkan serta (2) bucket baru yang diisi browser untuk memperjelas jenis pembatalan yang terjadi. | RTM tampaknya bukan solusi yang sesuai untuk menyelidiki rasio partisipasi. RTM dirancang, sebagai API pemantauan latensi rendah, untuk mendeteksi pemadaman layanan sementara yang kritis dan tiba-tiba. Sebaliknya, rasio partisipasi tidak memerlukan pelaporan latensi rendah dan bukan merupakan pemadaman layanan sementara yang tiba-tiba dan penting. Kekhawatiran tentang rasio partisipasi paling efektif dijawab oleh penjual yang berkolaborasi dengan pembeli, dan bukan oleh pembeli yang menyelidiki melalui browser. Selain itu, karena lelang yang dibatalkan sangat umum terjadi, jika browser akan membuat laporan RTM dari setiap lelang yang dibatalkan, laporan RTM untuk pemadaman layanan yang sebenarnya dapat terhalang. |
| Dokumentasi Klarifikasi |
Laporan perbedaan dokumentasi di penjelasan PA API yang menyatakan bahwa nonce harus berupa string UUID, tetapi sebenarnya menampilkan promise. | Klarifikasi diusulkan di sini. |
| Konteks Beku |
Saat menggunakan konteks beku, opsi apa yang tersedia untuk mengatasi masalah dan tantangan terkait (1) pengelompokan, (2) library eksternal, dan (3) jenis data yang tidak didukung? | Kami telah memberikan respons atas pertanyaan ini di sini. |
| Spesifikasi | Private Aggregation API menambahkan operasi contributeToHistogramOnEvent umum. Akibatnya, definisi di PA API menjadi operasi yang kelebihan beban, dan operasi IDL Web "tidak boleh kelebihan beban di seluruh antarmuka, antarmuka parsial [...]", sehingga definisi tersebut kini tidak valid. | Masalah ini menunjukkan inkonsistensi sementara antara PA API dan spesifikasi Agregasi Pribadi saat kami menggabungkan perubahan serupa di keduanya. Kami telah menggabungkan permintaan pull untuk mengatasi masalah ini. |
| Grup Minat | Minta panduan tentang metode yang direkomendasikan dan hemat resource untuk mengakhiri partisipasi bidding Grup Minat (IG) saat kampanye berhenti. | Berikut beberapa saran yang dapat kami berikan: Kami yakin mekanisme pelepasan resource yang paling rendah latensinya, paling tidak permanen, tetapi juga paling sedikit adalah menggunakan sinyal bidding real-time untuk memberi tahu generateBid() untuk berhenti mengajukan bid. Opsi kedua yang menggunakan lebih sedikit resource adalah menetapkan prioritas negatif untuk IG tersebut dalam respons sinyal bidding real-time, karena hal ini akan menghentikan generateBid() agar tidak dipanggil. Opsi ketiga, yang menggunakan lebih sedikit resource, adalah menghapus iklan dari IG. IG tanpa iklan tidak akan memanggil generateBid(). Opsi keempat, yang menggunakan lebih sedikit resource, adalah menghapus biddingLogicURL dari IG. Pada tahap ini, IG masih dapat diperbarui/diikuti kembali untuk mengaktifkannya kembali. Opsi lainnya berkaitan dengan keluar dari IG, baik melalui leaveAdInterestGroup() atau clearOriginJoinedAdInterestGroups() atau melalui masa berlaku IG yang habis.Seperti yang disoroti di atas, opsi yang berbeda memiliki implikasi latensi dan konsumsi resource yang berbeda. Teknologi iklan dapat memilih opsi yang memiliki kompromi terbaik untuk kasus penggunaan spesifik mereka. |
| Audiens | Meminta mekanisme untuk menjalankan operasi logis pada audiens yang dibuat (misalnya, kemampuan untuk menargetkan persimpangan IG A & B) | Dengan PA API, Anda dapat menjalankan operasi logis pada audiens dari situs yang sama. Operasi logis audiens di berbagai situs saat ini tidak didukung karena pertimbangan privasi seperti yang dijelaskan dalam model privasi kami. Kami terus melakukan riset di bidang ini dan akan membagikan info terbarunya. |
| Permintaan Fitur | Proposal untuk menghapus batasan pada bid tambahan yang mengharuskan TLS diketahui terlebih dahulu. | Saat ini kami sedang mendiskusikan proposal ini di sini dan menerima masukan tambahan. |
| Pendekatan yang diperbarui untuk 3PC di Chrome | Apakah Privacy Sandbox API seperti PA API akan tetap tersedia secara umum untuk semua pengguna Chrome Stabil, atau apakah API (atau sebagian API) hanya akan tersedia untuk pengguna yang telah menolak 3PC? | Kami tidak ingin keputusan pengguna untuk menolak 3PC berdampak pada ketersediaan Privacy Sandbox API di Chrome Stabil. |
| Sinyal yang Ditingkatkan | Apakah ada rencana untuk menambahkan fungsi yang menunjukkan apakah TLS bermaksud menjalankan lelang PA API? | Kami sedang mengevaluasi dukungan untuk fungsi ini. Kami akan membagikan detail lebih lanjut tentang pengaturan waktunya jika tersedia dan kami mengharapkan masukan tambahan tentang permintaan ini. |
| ID Penawaran | Kekhawatiran bahwa persyaratan server KV dalam proposal ID Transaksi mungkin merupakan proses sisi server yang mahal dan memakan waktu. | Proposal ID Transaksi memungkinkan SSP mengkueri metadata ID transaksi yang dipilih dari server nilai kunci selama lelang PA, sehingga mereka tidak perlu memuat semua metadata terkait transaksi ke perangkat secara otomatis. Proposal ini sedang dikembangkan sebagai respons atas permintaan dari SSP, dan kami menerima masukan ekosistem tambahan di sini. Kami memahami bahwa ada pekerjaan yang diperlukan untuk menyiapkan server nilai kunci, tetapi secara keseluruhan masih menganggap ini adalah manfaat bersih bagi perusahaan teknologi iklan. Kami terus menerima masukan dan saran untuk mempermudah proses ini. |
| Pembatasan Frekuensi Lintas IG | Permintaan untuk pembatasan frekuensi lintas IG melalui PA API. | Pembatasan frekuensi lintas-IG memiliki karakteristik privasi yang sulit dan kami belum dapat menemukan solusinya. Kami menerima masukan tambahan dari ekosistem jika fitur ini memiliki prioritas tinggi. |
| Pelaporan ID Transaksi & ID Slot | Meminta kemampuan untuk mendapatkan ID kesepakatan atau kursi ke dalam pelaporan gabungan. | Fungsi ID pelaporan yang sedang kami kerjakan di sini akan memungkinkan pelaporan ID kesepakatan dan kursi. selectedBuyerAndSellerReportingId disediakan untuk reportResult(), sehingga cara termudah untuk melaporkannya adalah melalui pelaporan tingkat peristiwa (yaitu mengenkode ID Transaksi ke dalam URL yang diteruskan ke sendReportTo()). Jika pelaporan gabungan akan digunakan, hal itu juga dapat dilakukan. Fitur ID pelaporan saat ini aktif untuk 10% traffic saluran Stabil Chrome. Kami sedang mengevaluasi untuk memperluas peluncuran ini hingga 100%. |
| Grup Minat | Gunakan urutan prioritas yang sama dalam pemilihan dan evaluasi IG, serta gunakan urutan prioritas tersebut di semua mode evaluasi. | Saat ini kami sedang membahasnya di sini dan menerima masukan tambahan. |
| Grup Minat | Saran untuk menggunakan aktivasi dan delegasi audiens sebagai cara untuk meningkatkan penerapan Privacy Sandbox API. | Kami mengetahui permintaan ini dari beberapa pemangku kepentingan dan sedang meneliti solusinya. Kami menerima masukan tambahan dari ekosistem. |
| Grup Minat | Tantangan seputar pembuatan IG PA API, khususnya seputar delegasi dan kepemilikan saat bertindak untuk beberapa pembelian atau atas nama penayang. | 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 menerima masukan tambahan dari ekosistem. |
| Kinerja Sisi Klien | Minta panduan tentang cara memudahkan penyimpanan dalam cache sisi klien trustedBiddingSignals untuk mengoptimalkan biaya infrastruktur dan latensi. | Saat ini kami sedang membahasnya di sini dan menerima masukan tambahan. |
Protected Auction (Layanan B&A)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Layanan K/V | Bagaimana permintaan dari browser ke server KV penjual dikelompokkan? Untuk penjual, seperti apa permintaan dari browser - permintaan GET atau POST? Selain itu, diperlukan beberapa klarifikasi terkait persyaratan k-anonymity. | Untuk v1, Chrome mengirimkan permintaan GET ke layanan KV Penjual untuk mengambil trustedScoringSignalsURL dengan sinyal dalam parameter kueri permintaan. Parameter akan mencakup hostname, renderUrls, adComponentRenderUrls, dan experimentGroupId. Saat ini kami sedang bereksperimen dengan beberapa ekstensi untuk mengirim informasi tambahan guna pemindaian materi iklan, tetapi belum diluncurkan. Jika menetapkan maxTrustedScoringSignalsURLLength ke 0, Chrome berpotensi mengelompokkan semua sinyal ke dalam satu permintaan (mungkin melebihi batas panjang URL di servernya), tetapi hal ini tidak dijamin. Chrome saat ini memilih untuk menyertakan permintaan dalam batch yang sama jika siap dikirim dalam waktu 10 md dari satu sama lain, meskipun saat ini kami sedang menyelidiki cara mengoptimalkannya.Saat menggunakan trustedScoringSignals, sebaiknya ingat bahwa Chrome mematuhi header penyimpanan dalam cache. Header seperti header "Cache-Control" Stale-While-Revalidate dapat mengurangi latensi rata-rata dengan mengizinkan Chrome menggunakan salinan yang di-cache (dan memperbarui cache untuk lelang berikutnya), sehingga secara efektif menghapus pengambilan sinyal dari jalur kritis.Terakhir, terkait k-anonymity, bagian tertentu dari penjelasan tampaknya sudah tidak berlaku. Awalnya, kami akan mewajibkan URL sinyal tepercaya untuk menjadi k-anonim, tetapi persyaratan tersebut dihapus. Kami akan menghapus kalimat ini dari penjelasan. |
| Layanan B&A | Upgrade ke B&A versi terbaru memerlukan waktu yang lama. Waktu build yang lebih cepat atau image bawaan akan bermanfaat. | Teknologi iklan dapat membuat biner sendiri dan memvalidasi menggunakan hash yang disediakan. Kami akan mempertimbangkan untuk menyelidiki kemungkinan penyediaan artefak bawaan atau meningkatkan waktu build di masa mendatang. |
| Permintaan Fitur API | Meminta kompatibilitas macOS untuk skrip build, image container, dan alat pemanggilan Layanan Bidding & Lelang (B&A) untuk memfasilitasi pengembangan dan pengujian lokal. | Kami saat ini mendukung amd64 yang cukup untuk deployment ke platform cloud yang didukung (GCP & AWS). Kami mungkin akan menyelidiki dukungan untuk arsitektur lain pada masa mendatang. |
| AWS | Apakah pembuatan peran IAM merupakan persyaratan untuk build produksi? | Ya, peran IAM diperlukan untuk mendapatkan izin dan komunikasi yang tepat dengan Koordinator. Kunci ini digunakan untuk mendekripsi ciphertext ProtectedAudienceInput yang dibuat di perangkat seperti yang dijelaskan di sini. Selain itu, peran ini diperlukan untuk meneruskan pengesahan server/TEE build produksi dengan Koordinator yang sama. Hal ini dibahas secara lebih mendetail dalam panduan layanan mandiri kami. |
| Bendera B&A | Meminta definisi flag B&A yang tersedia untuk dicantumkan dalam dokumentasi mengingat saat ini definisi ini berada dalam kode Terraform, file cc, dan file proto, tetapi teknologi iklan akan mendapatkan manfaat dari dokumentasi tentang flag ini yang memanfaatkannya sebagai sumber tepercaya untuk memahami cara menyesuaikan deployment. | Kami sedang menyelidiki kemungkinan mendokumentasikan deskripsi flag Terraform dan menerima masukan tambahan di sini. |
| Layanan Bidding AWS |
Mencari panduan terkait layanan bidding di AWS serta perilaku dan konfigurasi logging default. | Untuk men-debug layanan bidding dalam TEE (seperti layanan Bidding), sebaiknya gunakan proses debug yang diizinkan Teknologi Iklan. Hal ini memungkinkan Anda mengaktifkan logging mendetail dan mengambil data permintaan/respons untuk permintaan pengujian tertentu langsung dari klien untuk membantu proses debug. |
| Dokumentasi TEE K/V |
Meminta klarifikasi terkait awal penegakan TKV seperti yang dinyatakan di situs developer. | Kami akan memberikan pemberitahuan yang memadai sebelum mewajibkan penggunaan TEE. Sebelum itu, Anda dapat terus menggunakan server Anda sendiri untuk sinyal nilai kunci real-time. |
| Pengujian& Analisis B &A | Analisis dan pengujian B&A tetap mahal dan tampaknya belum siap produksi. | Kami memerlukan informasi lebih lanjut tentang analisis biaya dan faktor yang menyebabkan penilaian kesiapan produksi untuk memeriksanya lebih lanjut. |
| Pengoptimalan Server Tepercaya | Proposal untuk menggabungkan parameter khusus untuk penjual komponen menjadi satu parameter inputsPerSeller, menggunakan string JSON untuk nilainya. | Kami sedang membahas proposal ini dan menerima masukan tambahan di sini. |
| Keamanan | Bagaimana risiko keamanan dari TKV dimitigasi dengan menggunakan B&A? | Anda dapat mencegah panggilan eksternal ke TKV. Fitur ini sepenuhnya didukung dan dapat dikonfigurasi di GCP saat ini. Untuk AWS, dukungan tambahan perlu dikembangkan karena penghentian AWS App Mesh, yang sebelumnya mengaktifkan hal ini. Kami menerima masukan tambahan di sini. |
| Layanan B&A | Meminta kejelasan tentang narasi/komunikasi terkait nilai Streaming HTTP untuk pengoptimalan B&A. | Privacy Sandbox mendukung kemampuan streaming dalam mentransfer data B&A untuk meningkatkan latensi bagi teknologi iklan yang memilih untuk menggunakannya. Ini adalah pengoptimalan performa opsional jika modenya campuran. |
| Pra-bid | Minta info terbaru tentang kontribusi ke library Pra-bid open source untuk mengaktifkan fitur B&A PA API untuk ekosistem. | Pada Maret 2025, Chrome meluncurkan pengoptimalan pilihan Pra-bid dalam versi stabil seperti yang didokumentasikan dalam roadmap publik B&A (lihat Maret 2025). |
| Pembentukan Traffic | Meminta mekanisme untuk mencatat sinyal kontekstual yang diterima oleh B&A untuk lebih memahami kapan IG diaktifkan dan meningkatkan logika "niat untuk mengajukan bid" dalam respons kontekstual. Hal ini memungkinkan penggunaan resource jaringan yang lebih baik untuk menghindari "traffic yang tidak berguna" (alias traffic shaping). | Saat ini kami sedang membahas proposal di sini dan menerima masukan tambahan. |
| Dokumentasi Klarifikasi |
Klarifikasi diperlukan terkait error 'Service/Vsock proxy is not reachable' yang ditemukan di penyiapan integrasi pengujian B&A. | Hal ini disebabkan oleh persyaratan memori minimum.Penjelasan konfigurasi AWS telah diperbarui untuk mencerminkan persyaratan ini. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Data Real-Time | Kurangnya data real-time memengaruhi semua orang di industri ini. Penundaan data real-time adalah masalah serius bagi pengiklan. Pembeli beralih ke platform yang memiliki Google Analytics karena ini adalah satu-satunya tempat mereka bisa mendapatkan bukti bahwa mereka menjangkau audiens. | Keterlambatan data real-time yang merupakan bagian dari Attribution Reporting API (ARA) diterapkan sebagai mekanisme perlindungan privasi untuk mengurangi kemampuan teknologi iklan dalam menggunakan laporan tingkat peristiwa untuk melacak pengguna di seluruh situs. Namun, ARA memberikan fleksibilitas dalam cara pengiriman laporan atribusi, dengan mengizinkan laporan tingkat peristiwa memiliki periode pelaporan minimum 1 jam dan dengan mengizinkan Laporan Gabungan memiliki opsi untuk dikirim langsung ke teknologi iklan tanpa penundaan. |
| Penggunaan API | Meminta konfirmasi terkait konfigurasi yang benar untuk alur atribusi Aplikasi Web Lintas, khususnya saat mengoperasikan atribusi web-ke-web dan web-ke-aplikasi secara paralel. | Saat menjalankan kampanye web ke web dan web ke aplikasi secara paralel, teknologi iklan hanya boleh memilih satu platform untuk mendaftarkan setiap sumber atau pemicu, guna mencegah penghitungan ganda. Sebaiknya gunakan Sistem Operasi (OS) jika memungkinkan, karena OS memiliki kemampuan untuk melakukan atribusi web-ke-web dan web-ke-aplikasi, selama sumber dan pemicu web telah didelegasikan dengan benar. Artinya, Anda harus merespons dengan header Attribution-Reporting-Register-OS-Source untuk sumber dan header Attribution-Reporting-Register-OS-Trigger untuk pemicu. Header Attribution-Reporting-Support dapat digunakan untuk mengidentifikasi apakah ada dukungan tingkat Chrome dan/atau Android. Header Attribution-Reporting-Info berguna jika tidak ada header Attribution-Reporting-Support dalam permintaan. Dalam hal ini, browser akan membuat keputusan pendaftaran platform berdasarkan ketersediaan dukungan platform di perangkat pengguna. |
| Spesifikasi API | Meminta klarifikasi tentang header permintaan HTTP Dukungan Pelaporan Atribusi yang ditetapkan oleh Attribution Reporting API dan apakah header tersebut dimaksudkan untuk berisi kunci web dan os, terlepas dari platformnya. | Header Dukungan Pelaporan Atribusi tunduk pada browser yang menambahkan parameter "GREASE", untuk memastikan server menggunakan parser header terstruktur yang sesuai dengan spesifikasi. Untuk header ini, hanya kunci kamus terstruktur yang harus ditafsirkan. Nilai dan parameter saat ini tidak digunakan. Lihat di sini untuk contohnya. |
| Pelaporan berbasis 3PC | Meminta panduan tentang cara memecahkan masalah perbedaan pengukuran antara ARA dan 3PC di kampanye iklan. | ARA mendukung dua jenis laporan debug yang dapat digunakan untuk memecahkan masalah dan men-debug perbedaan. Laporan debug atribusi-sukses dapat digunakan untuk membandingkan hasil ARA dengan hasil dari teknologi pengukuran lainnya dengan mudah, dan Laporan debug panjang dapat digunakan untuk menerima informasi selengkapnya dan memecahkan masalah potensial dalam pendaftaran atribusi. |
| Penggunaan API | Saat menguji ARA, masalah tertentu ditemukan: pelaporan terperinci yang tidak memadai sehingga menghasilkan data yang berisi derau dan pengoptimalan kampanye yang tidak fleksibel, nilai minimum yang tinggi yang mengecualikan pengiklan yang lebih kecil, dan kesulitan membandingkan kampanye karena Key Performance Indicators yang tidak konsisten. | ARA memberikan fleksibilitas dengan menyediakan beberapa parameter yang dapat disesuaikan oleh teknologi iklan untuk mencapai kasus penggunaan pengukuran tertentu. Laporan Tingkat Peristiwa mendukung pelaporan tingkat peristiwa yang fleksibel, yang memungkinkan teknologi iklan menyesuaikan periode pelaporan, jumlah laporan yang dapat diterima, dan data pemicu yang ingin diukur, yang dapat mengubah dampak derau pada data mereka dan memungkinkan mereka mencapai berbagai kasus penggunaan. Demikian pula, Laporan Gabungan memiliki cara yang berbeda bagi teknologi iklan untuk menyesuaikan konfigurasinya seperti jumlah dimensi yang dilacak, frekuensi pengelompokan, dan penggunaan anggaran kontribusi untuk mengubah dampak derau dan juga mencapai kasus penggunaan yang berbeda. |
| Spesifikasi API | Pertanyaan tentang dependensi ARA pada 3PC, khususnya terkait apakah ARA masih dalam fase pengujian yang memerlukan 3PC ini. | ARA diaktifkan secara terpisah dari 3PC, tetapi 3PC harus diaktifkan untuk memungkinkan pelaporan debug transisi ARA membandingkan hasil ARA dengan hasil atribusi berbasis cookie. |
| Penggunaan API | Permintaan tentang cara mendaftarkan sumber untuk atribusi aplikasi ke web di versi Android lama (11, 12, dan 13) menggunakan ARA. | ARA saat ini didukung di Android S dan yang lebih baru (12+). |
| Penggunaan API | Minta rasio keikutsertaan ARA dan detail distribusi. | Respons kami tidak berubah dari kuartal sebelumnya: "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" |
| Ketersediaan API | Saat ARA diaktifkan, apakah 3PC diaktifkan atau dinonaktifkan? | Jika diaktifkan di browser pengguna, ARA tidak akan memengaruhi setelan cookie pengguna. ARA dapat diaktifkan dan pengguna dapat mengaktifkan atau menonaktifkan cookie. |
| Pelaporan | Apakah ada daftar nilai standar yang dapat kami terima di header "Attribution-reporting-support"? | Seperti yang dijelaskan dalam panduan kami, nilai ini adalah kamus header terstruktur, yang semantiknya saat ini hanya ditentukan oleh keberadaan atau tidak adanya kunci OS dan web. Semua bagian header lainnya harus diabaikan. Dengan kata lain, penguraian memerlukan penggunaan parser header terstruktur, bukan pencocokan string sederhana. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Permintaan Fitur | Permintaan fitur untuk Layanan Agregasi: Integrasi server ke server, Pengukuran lintas perangkat, Mempermudah pelaporan kontribusi dan atribusi multi-sentuh, atribusi omnichannel, dan dukungan untuk loop pengoptimalan ML lanjutan (mis., Pelatihan Model Pribadi). |
Kami sedang mengevaluasi permintaan ini dan akan membagikan detail lebih lanjut jika tersedia. Kami menerima masukan tambahan dari ekosistem tentang apakah permintaan ini merupakan prioritas. |
| Permintaan Fitur | Permintaan untuk menetapkan parameter delete_on_termination EBS ke True di lingkungan terraform, untuk mengurangi masalah terkait reset saat mengupdate set layanan agregasi. | Kami sedang mengevaluasi permintaan ini dan akan membagikan detail lebih lanjut jika tersedia. Kami menerima masukan tambahan dari ekosistem tentang apakah permintaan ini merupakan prioritas di sini. |
| Dokumentasi Klarifikasi |
Meminta panduan tentang hal yang dapat diubah (misalnya, nilai minimum pemantauan) dan hal yang tidak boleh diubah. | Kami sedang mengevaluasi publikasi dokumentasi dan panduan tambahan tentang penyesuaian yang tersedia untuk layanan agregasi. |
| Deployment | Permintaan klarifikasi terkait deployment baru yang gagal pada perintah bazel. | Kegagalan deployment dapat terjadi karena versi bazel yang digunakan di lingkungan. Dokumentasi akan disesuaikan untuk mencakup proses debug pada kegagalan Terraform serta menunjukkan versi bazel yang diperlukan. |
Private Aggregation API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penggunaan API | Minta panduan tentang beberapa tantangan penerapan seperti potensi kehilangan data karena batasan Penyimpanan Bersama yang dilaporkan, kesulitan dengan kardinalitas tinggi yang memerlukan daftar yang diizinkan Layanan Agregasi yang kompleks (direkomendasikan karakter pengganti), dan pengujian yang melambat karena aturan "tidak ada duplikat" Layanan Agregasi. | Terkait batasan Shared Storage, batas 20 kontribusi (dijelaskan di sini) adalah per eksekusi, bukan per bulan. Selain itu, pemanggil API dapat mengganti batas ini. Batas ini diterapkan untuk membantu mengelola biaya pemrosesan laporan di layanan agregasi, bukan untuk membatasi utilitas pelaporan. Terkait kueri karakter pengganti, kami sedang mengevaluasi permintaan ini dan akan membagikan detail lebih lanjut jika tersedia. Terkait aturan "tidak ada duplikat", untuk mengaktifkan pengujian, kami sementara mendukung mode debug untuk tujuan mengabaikan aturan ini. Hal ini dijelaskan di sini secara lebih mendetail. |
| Memfilter ID & Bucket | Apakah bucket yang sama dengan dua ID pemfilteran yang berbeda dalam dua operasi agregasi terpisah dapat diminta ke layanan agregasi, yaitu, apakah ID pemfilteran dapat berfungsi sebagai partisi tambahan domain? | Ya, fitur ini didukung. Saat melakukan agregasi, hanya kontribusi dengan ID pemfilteran yang cocok dengan daftar dalam parameter tugas yang akan diproses, dan sisanya akan tetap tersedia untuk diproses dalam operasi terpisah. |
| Atribusi multi-sentuh | Permintaan klarifikasi terkait penerapan Multi-Touch Attribution (MTA): 1) Apakah ada batasan jumlah kontribusi jika nilai agregasi tidak melebihi 2^16? 2) Apakah ada batasan jumlah kunci agregasi (bucket) unik yang dapat disimpan untuk konteks tertentu? 3) Bagaimana cara Layanan Agregasi memproses laporan ringkasan jika setiap agen pengguna (browser) memiliki kunci agregasi unik, seperti yang mungkin terjadi di MTA? |
1) Kami telah menerapkan batas kontribusi default, tetapi ada opsi bagi pemanggil API untuk menggantinya seperti yang dijelaskan di sini. Tujuan pembatasan ini adalah untuk membantu pemanggil API mengelola biaya pemrosesan laporan di layanan agregasi. 2) Tidak ada batasan tersebut, meskipun teknologi iklan harus mempertimbangkan tingkat perincian kunci agregasi untuk meningkatkan rasio sinyal-derau, seperti yang dijelaskan lebih lanjut di sini. 3) Lihat panduan ini, terutama panduan sinyal-ke-derau yang dibahas di atas pada item 2). |
Membatasi Pelacakan Tersembunyi
Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Permintaan Fitur | Permintaan untuk menambahkan Sec-CH-UA-Robot ke User-Agent Client Hints (UA-CH) karena akan memungkinkan server mengidentifikasi traffic otomatis untuk adaptasi konten, keamanan, dan analisis. | Ini adalah kasus penggunaan penting yang sedang dibahas di grup standar lainnya (lihat di sini untuk detail lebih lanjut), dan kami akan merekomendasikan pihak yang berminat untuk berpartisipasi dengan memberikan masukan mereka. Namun, kami menganggap bahwa UA-CH mungkin bukan solusi yang tepat, mengingat header permintaan HTTP dapat dengan mudah dimanipulasi oleh traffic otomatis. |
Perlindungan IP (sebelumnya bernama Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Privasi Alamat IP | Membiarkan alamat IP tersedia untuk digunakan Google bertentangan dengan sasaran privasi yang dinyatakannya. Meskipun Google mengatakan bahwa mereka menganonimkan data melalui Perlindungan IP, pengguna harus login ke Chrome untuk menggunakan Perlindungan IP, sehingga Google tetap mempelajari identitas mereka. | Alasan login adalah untuk tujuan anti-penipuan dan penyalahgunaan, terutama pembatasan kapasitas akses ke proxy. Selain itu, untuk melindungi privasi pengguna dalam konteks persyaratan autentikasi, desain token kami ditandatangani secara buta, yang berarti token yang dikeluarkan selama login berbeda dengan token yang digunakan selama proxy, sehingga token yang dikeluarkan tidak dapat ditautkan ke identitas Google pengguna di lain waktu. Artinya, Google tidak mengetahui identitas pengguna saat traffic pengguna tersebut di-proxy dalam mode Samaran, meskipun ada persyaratan autentikasi untuk alasan anti-penipuan. |
| Privasi Alamat IP | Penggunaan IP adalah langkah yang salah. Data ini tidak dapat dihapus dari browser, seperti cookie, dan pengguna tidak memiliki kontrol transparansi yang sama seperti yang mereka miliki dengan cookie. Jika cookie dihapus, industri akan beralih menggunakan IP sebagai solusi alternatif, dengan memprioritaskan perlindungan diri daripada privasi. | Sebagai platform, Chrome bertujuan untuk menyediakan fitur yang meningkatkan pengalaman penjelajahan pengguna di web. Bagi pengguna Chrome yang memilih untuk menjelajah dalam mode Samaran, hal ini berarti memberikan perlindungan yang ditingkatkan terhadap pelacakan lintas situs dengan membatasi ketersediaan informasi alamat IP dalam konteks pihak ketiga. |
| Daftar Domain yang Disamarkan | Apa kriteria pemilihan di Daftar Domain yang Disamarkan (MDL)? | Chrome mengembangkan kriteria untuk mengidentifikasi domain mana yang harus ada di MDL dan karenanya menerima alamat IP yang disamarkan dalam konteks pihak ketiga. Google telah berpartner dengan Disconnect.me, pemimpin privasi internet terkemuka yang juga berkolaborasi dengan browser web lainnya. Chrome akan memanfaatkan Disconnect.me untuk mengidentifikasi domain yang sesuai dengan kriteria yang ditetapkan Chrome. Selain itu, Chrome telah mengembangkan metodologi untuk mengidentifikasi fungsi JavaScript yang banyak digunakan yang memberikan output yang konsisten dari API web yang stabil dan memiliki entropi tinggi sehingga dapat digunakan untuk membuat ID probabilistik entropi tinggi. Fungsi ini kemudian terdeteksi saat dimuat di situs dalam konteks pihak ketiga, sehingga menghasilkan daftar domain yang menayangkan skrip dengan karakteristik ini yang menjadi bagian dari MDL dan karenanya di-proxy. Pipeline deteksi yang mencari pola penyalahgunaan API ini mempertimbangkan semua domain, termasuk domain Google sendiri. |
| Pencegahan Penipuan | Masukan tentang Token Pengungkapan Probabilistik (PRT) bahwa penundaan pengungkapan 24 jam dan rasio pengungkapan yang diusulkan menghambat deteksi penipuan secara real time. Minta penundaan yang lebih singkat (penundaan 1 jam) dan tarif yang lebih tinggi (setidaknya dua digit). Saran lebih lanjut mencakup pengaktifan tarif diferensial berdasarkan sinyal risiko (VPN, browser otomatis), dan memungkinkan pengungkapan token tertentu yang ditargetkan. | Sebagian besar developer yang kami ajak bicara memberikan pelaporan per jam kepada pelanggan mereka, dan beberapa memperbarui daftar blokir IP sepanjang hari. Periode penundaan yang lebih singkat memungkinkan pembaruan yang lebih sering, dan kurang dari satu jam, akan mengaktifkan kembali pengukuran IVT dalam statistik per jam, tetapi juga berpotensi meningkatkan kemungkinan pengguna dapat diidentifikasi kembali. Kami terbuka untuk mempelajari cara mengurangi periode penundaan dan mengubah rasio pengungkapan berdasarkan studi ekosistem, serta masukan dari pemangku kepentingan dan menerima masukan tambahan di sini. |
| Daftar Domain yang Disamarkan | Pertanyaan terkait penyertaan domain di MDL meskipun tidak memiliki kasus penggunaan iklan. Kekhawatiran bahwa hal ini dapat memungkinkan "IP-bridging" untuk membuat profil berdasarkan alamat IP. | Kami menyadari pentingnya menerapkan proses banding untuk pendekatan berbasis daftar kami. Banding memungkinkan perusahaan membuat klaim bahwa domain mereka di MDL tidak memenuhi kriteria penyertaan dan harus dihapus, sehingga domain tersebut dapat terus menerima alamat IP asli pengguna dalam konteks pihak ketiga dalam mode Samaran. Kami kini telah meluncurkan proses banding untuk memberi pemilik domain waktu yang cukup untuk mengajukan banding dan menerima keputusan sebelum peluncuran Perlindungan IP dalam mode Samaran di Chrome Stabil. Detail selengkapnya tentang proses banding tersedia di sini. |
| Daftar Domain yang Disamarkan | Masukan bahwa penayang sedang menyelidiki implikasi dari penyertaan partner mereka dalam MDL. Mereka merasa yakin dengan ketentuan GeoIP dalam Penjelasan Perlindungan IP. | Chrome menyadari pentingnya mendukung kasus penggunaan berbasis geografis. Proxy akan menetapkan alamat IP yang mewakili lokasi kasar pengguna, termasuk negara. Informasi selengkapnya tersedia di Penjelasan Geolokasi IP. |
| Daftar Domain yang Disamarkan | Pertanyaan terkait MDL, apakah penargetan tingkat negara masih tersedia atau tidak. | Chrome menyadari pentingnya mendukung kasus penggunaan berbasis geografis. Proxy akan menetapkan alamat IP yang mewakili lokasi kasar pengguna, termasuk negara. Informasi selengkapnya tersedia di Penjelasan Geolokasi IP. |
| Deteksi Penipuan | Kekhawatiran tentang dampak Perlindungan IP terhadap sistem deteksi penipuan. Apakah pengguna akan melihat IP proxy atau header? Apakah SSP dan DSP akan melihat alamat IP proxy yang sama untuk penggunaan tertentu? Inkonsistensi dapat memengaruhi deteksi penipuan dan OpenRTB. | Pengguna yang menjelajah dalam mode Samaran dengan Perlindungan IP yang diaktifkan dan membuat permintaan ke domain di MDL akan menerima alamat IP proxy berdasarkan geofeed yang ditentukan. Organisasi dapat meminta PRT untuk diteruskan sebagai header tambahan pada traffic yang di-proxy, tempat sampel kecil IP asli dapat ditampilkan setelah periode penundaan. Kami menduga banyak SSP akan meneruskan alamat IP dengan proxy dalam permintaan bid sisi server ke partner permintaan mereka, tetapi DSP pemenang tidak dijamin akan melihat alamat IP proxy yang sama pada waktu tayangan. |
| Deteksi Penipuan | Pertanyaan tentang frekuensi pembaruan file geolokasi IP, waktu pembaruan untuk mengetahui detail tentang cara melaporkan perilaku dan PRT yang menipu, serta cara teknologi iklan mendeteksi aktivitas penipuan. | Penjelasan PRT sudah aktif, begitu juga dengan daftar alamat IP proxy dan region geografis yang dipetakan. Sebaiknya periksa file ini secara berkala untuk mengetahui pembaruan dan perubahan, karena alamat IP akan berganti seiring waktu. Alamat email publik untuk melaporkan penyalahgunaan akan diumumkan menjelang peluncuran. |
| Geolokasi | Meminta daftar alamat IP publik yang digunakan untuk proxy. | File yang memetakan alamat IP ke lokasi perkiraan untuk Perlindungan IP tersedia di sini. Perhatikan bahwa file ini diperbarui secara berkala. |
| Penggunaan API | Pernyataan bahwa Perlindungan IP tampaknya diaktifkan secara default dan pengguna tidak diberi opsi untuk memilih tidak ikut. | Perlindungan IP akan tersedia untuk pengguna dalam mode Samaran Chrome, di platform Android dan Desktop. Pengguna akan dapat menonaktifkan Perlindungan IP. Untuk versi Chrome yang dikelola perusahaan, Perlindungan IP dapat diaktifkan, tetapi akan dinonaktifkan secara default. |
| Penggunaan API | Kueri terkait ketersediaan tanda eksperimen untuk mengaktifkan dan menguji Perlindungan IP di rilis Chrome Canary dan Beta. | Saat ini, kami tidak memiliki flag eksperimen yang tersedia untuk menguji fitur Perlindungan IP lengkap. Eksperimen fungsional yang kami lakukan hanya memproses traffic proxy yang menuju ke domain Google. |
| Privasi Alamat IP | Bagaimana cara kerja setelan perintah 3PC saat browser beralih ke mode Samaran? | 3PC diblokir secara default dalam mode Samaran. |
| Mode Samaran | Meminta klarifikasi tentang apakah Perlindungan IP berfungsi dalam mode Samaran saat pengguna tidak login ke Chrome. | Perlindungan IP tidak aktif jika pengguna belum login ke Chrome sebelum meluncurkan mode Samaran. Alasannya adalah untuk tujuan anti-penipuan dan penyalahgunaan, yaitu membatasi akses ke proxy. Perlindungan IP akan menggunakan autentikasi klien untuk membatasi kemampuan pihak tidak bertanggung jawab dalam memanfaatkan proxy untuk meningkatkan serangan terhadap layanan di MDL. Oleh karena itu, Perlindungan IP hanya akan tersedia untuk pengguna yang telah diautentikasi menggunakan Akun Google yang digunakan untuk login di browser Chrome sebelum membuka jendela Samaran baru. |
| Mode Samaran | Permintaan untuk menilai dampak Perlindungan IP sebelum peluncuran, termasuk: (1) Proposal untuk menggunakan flag status browser atau pelaporan API gabungan untuk mengukur penggunaan mode Samaran; (2) Mengirim header Perlindungan IP selama jangka waktu tertentu sebelum mengaktifkan fitur; dan (3) Mengirim fitur ke sebagian kecil traffic yang diketahui untuk ekstrapolasi. |
Kami memahami minat ekosistem untuk dapat memahami dan mengukur skala serta dampak Perlindungan IP. Namun, Chrome berupaya menjaga kerahasiaan pilihan pengguna untuk menjelajahi web dalam mode Samaran. Chrome tidak mengekspos metode untuk mendeteksi pengguna yang menjelajahi dalam mode Samaran, dan telah mengambil langkah-langkah untuk membatasi sinyal lain yang dapat mengungkapkan mode penjelajahan pengguna. Kami sedang mempertimbangkan cara untuk memfasilitasi pengujian ini tanpa memengaruhi privasi pengguna yang menjelajah dalam Mode Samaran dan menerima masukan tambahan dari ekosistem. |
Mitigasi Pelacakan Pantulan
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Kepatuhan | Keengganan Google untuk mengizinkan penggunaan teknik Mitigasi Pelacakan Pantulan (BTM) yang mematuhi legislasi perlindungan data tidak memiliki dasar hukum dan membuat proses banding Privacy Sandbox tidak ada artinya. | Seperti yang kami jelaskan dalam laporan masukan sebelumnya, status kepatuhan tidak ada hubungannya dengan penerapan BTM dan Google tidak membuat keputusan apa pun terkait kepatuhan dalam menerapkan BTM. BTM, seperti perlindungan privasi Chrome lainnya, berfokus pada peningkatan kontrol pengguna atas apakah dan bagaimana data mereka dibagikan. Proses banding yang dikelola pihak ketiga yang dirujuk dalam Laporan Kuartal 2/Kuartal 3 CMA khusus untuk wilayah tempat Google membuat keputusan tentang penyertaan atau pengecualian setiap perusahaan dalam daftar. |
| Kepatuhan | Diskusi tentang cara browser memastikan kepatuhan terhadap tindakan yang diizinkan secara hukum dalam konteks GDPR yang menyoroti skenario saat browser mungkin menyembunyikan tindakan (seperti pengalihan atau setelan cookie) yang telah diizinkan secara eksplisit oleh pengguna, sehingga menimbulkan konflik antara izin hukum dan setelan privasi browser. | Browser tidak memiliki visibilitas tentang sifat hubungan antara pengguna dan situs. Selain itu, dengan perilaku BTM saat ini, sudah ada solusi bagi pengguna untuk memberikan izin eksplisit untuk pelacakan pantulan dari situs tertentu. Informasi lebih lanjut terkait kepatuhan tersedia di FAQ kepatuhan terkait privasi kami. |
| Situs Ganda | Ingin mengklarifikasi apakah transisi dari WebView atau aplikasi ke web (Chrome) akan dianggap sebagai "situs penggunaan ganda" berdasarkan BTM? | Browser tidak memiliki visibilitas tentang apakah rantai pantulan dimulai melalui transisi dari WebView atau aplikasi. Oleh karena itu, BTM tidak memberikan perlakuan khusus apa pun pada alur tersebut. Sebagai gantinya, peristiwa ini menafsirkan alur sebagai pantulan lintas situs yang dimulai dari "about:blank" dan melanjutkan dengan perilaku standar. |
Memperkuat batasan privasi lintas situs
Set Situs Terkait (sebelumnya Set Pihak Pertama)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penggunaan API | Kekhawatiran tentang potensi penyalahgunaan RWS bersama dengan Perlindungan IP. Mengekspos alamat IP kepada organisasi dalam set RWS dapat mendorong organisasi untuk bergabung ke beberapa set RWS guna mendapatkan akses ke data Alamat IP portabel untuk melacak pengguna Samaran. | Persyaratan yang ditetapkan untuk situs terkait, situs layanan, dan set secara keseluruhan, yang diterapkan oleh validasi otomatis, mengurangi potensi insentif untuk mencoba bergabung ke beberapa set. Menggabungkan aktivitas pengguna di seluruh set melalui alamat IP akan memerlukan penyertaan domain MDL dalam set, yang memerlukan koordinasi antara pemilik set dan pemilik domain. Risiko yang sama berlaku untuk satu situs (yaitu tidak ada RWS yang terlibat) yang berkoordinasi dengan domain MDL. Kami telah merespons pertanyaan ini secara lebih mendetail di sini. |
Fenced Frames API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Iklan Native | Masukan bahwa Bingkai Pagar, seperti yang dirancang saat ini, tidak kompatibel dengan model bisnis iklan native mereka, yang mengharuskan iklan beradaptasi secara fleksibel dengan konten di sekitarnya. | Kami terus melakukan penilaian terhadap kebutuhan ekosistem dan penawaran Bingkai Pagar saat ini. Apa pun kasusnya, seperti yang dinyatakan sebelumnya, Frame Pagar akan diperlukan paling cepat pada tahun 2026. |
Shared Storage API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Bug API | Melaporkan bahwa Chrome mencatat error saat mekanisme anggaran Shared Storage API mencegah operasi selectURL berjalan, meskipun ini adalah perilaku yang diharapkan. Minta Chrome mendowngrade level logging dari error menjadi peringatan atau info, karena error tersebut tidak dapat ditindaklanjuti oleh pemanggil. | Perubahan ini telah diterapkan dan disertakan dalam Chrome M134, yang tersedia sejak 4 Maret 2025. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Dokumentasi API | Klarifikasi diperlukan terkait perlindungan keamanan yang ditawarkan oleh cookie yang dipartisi dibandingkan dengan cookie SameSite=Lax/Strict. Saran bahwa dokumentasi harus secara eksplisit menyatakan bahwa cookie yang dipartisi tidak memberikan tingkat perlindungan yang sama terhadap serangan XSS dan CSRF seperti cookie SameSite=Lax/Strict. | Kami akan memperbarui penjelasan dan spesifikasi untuk memperjelas semantik dan perlindungan yang ditawarkan oleh cookie yang dipartisi. |
FedCM
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| UI & Keamanan | Masukan bahwa UI FedCM terlalu mirip dengan login sekali ketuk Google sebelumnya, sulit untuk mengukur performa FedCM karena kurangnya pelacakan presentasi pasif, dan rekomendasi untuk bahasa dokumentasi yang lebih kuat terkait PKCE. | Kami secara aktif berinteraksi dengan pemangku kepentingan untuk menindaklanjuti masukan mereka. Area diskusi yang sedang berlangsung mencakup cara memberikan metrik yang lebih baik kepada IdP agar mereka dapat melacak performa FedCM, dan kemungkinan peningkatan untuk menangani kasus penggunaan baru untuk FedCM seputar kasus penggunaan langganan. |
| Penggunaan API | Saat pengguna memuat ulang halaman dan memanggil navigator.credentials.get untuk login, jendela pop-up akan muncul, yang mengharuskan pengguna mengklik untuk melanjutkan, sehingga menyebabkan penundaan yang memengaruhi pengalaman pengguna. Dapatkah Pihak Penerima (RP) meng-cache token yang ditampilkan oleh navigator.credentials.get untuk meningkatkan pengalaman pengguna? | RP dapat menggunakan cookie mereka sendiri untuk menyimpan token. RP kemudian dapat memeriksa cookie mereka sendiri untuk menentukan apakah pengguna login sebelum memanggil navigator.credentials.get. Kami telah membahasnya secara lebih mendetail di sini. |
| Pemilihan Multi-IdP | Bagaimana browser akan menampilkan opsi login untuk beberapa penyedia identitas (IdP) di FedCM? | Dokumentasi developer memiliki informasi tentang cara beberapa IdP akan ditampilkan. Pemangku kepentingan dapat bereksperimen dengan fungsi ini dengan mengaktifkan tanda fedcm-multi-idp di chrome://flags. |
| Browser & IdP | Apakah browser, seperti Chrome, dapat bertindak sebagai IdP itu sendiri? Browser dapat menggunakan data akun dan profil yang disimpan sebagai sumber autentikasi tepercaya. | Karena browser dapat dimodifikasi (misalnya melalui ekstensi), klaim verifikasi email apa pun yang dibuat langsung oleh browser tidak dapat dipercaya tanpa verifikasi berbasis server tambahan. Oleh karena itu, solusi yang sepenuhnya berbasis klien tidak direkomendasikan. Kami telah membahas masalah ini secara lebih mendetail di sini. |
| Spesifikasi API | Diskusi tentang apakah parameter untuk algoritma IdentityCredential.disconnect() harus wajib atau opsional. | Hal ini sekarang telah diperbaiki. Detail selengkapnya dapat ditemukan di sini. |
| Keamanan API | Masalah terkait kebocoran token dalam proses login FedCM jika RP memiliki kerentanan XSS. Penyerang dapat mengeksekusi navigator.credentials.get dalam kode berbahaya untuk mendapatkan token. | FedCM tidak menimbulkan risiko XSS baru; risiko ini melekat pada aplikasi web dan protokol autentikasi yang ada. Untuk mengurangi risiko ini, RP harus memverifikasi klaim aud dalam token ID dan hanya menerima pernyataan yang dikeluarkan di origin-nya sendiri. Seperti yang telah dibahas di sini, ada praktik terbaik yang telah ditetapkan secara luas untuk mengamankan pertukaran token yang ada saat ini dan tersedia untuk digunakan dengan FedCM. Selain itu, Storage Access API dapat digunakan dengan FedCM, dan panggilan Storage Access API otomatis diberikan jika ada panggilan FedCM sebelumnya. Tindakan ini akan mengaktifkan alur pengalihan tersemat yang dibahas di masalah GitHub. |
| Spesifikasi API | client_metadata_endpoint adalah kolom wajib diisi dalam respons endpoint konfigurasi untuk FedCM. Objek kosong adalah respons yang valid, dan Chromium mengabaikan respons 404 secara diam-diam, yang menunjukkan bahwa endpoint diperlakukan sebagai opsional dalam praktiknya. | Kami setuju bahwa spesifikasi dapat diubah untuk mencerminkan hal ini dan menjadikan client_metadata_endpoint sebagai kolom opsional. |
| Penggunaan API | Kekhawatiran terkait kesulitan pengujian penerapan FedCM karena antarmuka pengguna yang dikontrol browser tidak dapat diakses melalui DOM. | Kami mendukung API otomatisasi browser untuk pengujian regresi, yang dapat mengatasi masalah ini. API ini didokumentasikan di sini. |
| Spesifikasi API | Parameter login_url, yang merupakan bagian wajib dari respons endpoint konfigurasi, tidak didokumentasikan dalam Bagian 3.2 spesifikasi. | Kami telah mengirimkan pembaruan ke dokumentasi untuk menyertakan parameter login_url di Bagian 3.2. |
| Spesifikasi API | Masalah terkait potensi vektor pelacakan di FedCM. IdP dapat menyisipkan ID sebagai parameter jalur ke endpoint yang ditentukan dalam respons endpoint konfigurasi (accounts_endpoint, client_metadata_endpoint) dan menggunakan ID ini untuk mengaitkan permintaan metadata akun dan klien. | Meskipun kami tidak memiliki bukti bahwa IdP menyisipkan ID ke endpoint ini, kami secara aktif mempertimbangkan mitigasi untuk mengatasi masalah ini di sini. |
Memerangi spam dan penipuan
Private State Tokens API (dan API lainnya)
Tidak ada masukan yang diterima kuartal ini.