Laporan Masukan - Kuartal 2 2025

Laporan triwulanan untuk Kuartal 2 2025 yang merangkum masukan ekosistem yang diterima terkait proposal Privacy Sandbox dan respons Chrome.

Google telah menyiapkan laporan triwulanan 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 dalam menanggapi masukan tersebut.

Google telah memberi tahu CMA tentang progres proposal Privacy Sandbox dalam Rapat Status rutin 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. Info terbaru utama dibagikan di blog developer bersama dengan info terbaru yang ditargetkan yang dibagikan ke milis developer masing-masing.

Mempertimbangkan pengamatan yang dilakukan oleh pihak ketiga

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 Protokol Internet

openRTB

Bidding real-time

OT

Uji Coba Asal

PA API

Protected Audience API (sebelumnya FLEDGE)

PatCG

Grup Komunitas Teknologi Iklan Pribadi

RP

Pihak yang Mengandalkan (Relying Party)

RWS

Set Situs Terkait (sebelumnya Set Pihak Pertama)

SSP

Platform Sisi Penawaran

UA

String Agen Pengguna

UA-CH

Petunjuk Klien Agen Pengguna

W3C

World Wide Web Consortium

WIPB

Ketidakpedulian yang Disengaja terhadap IP

Masukan umum, tidak ada API/Teknologi tertentu

Tema Masukan	Ringkasan	Respons Chrome
Masa Depan Privacy Sandbox	Mengingat pengumuman untuk tidak melanjutkan pengenalan mekanisme pilihan pengguna untuk PC pihak ketiga, beberapa API lebih berguna daripada yang lain saat PC pihak ketiga ada dan yang lain perlu dikembangkan agar berguna. Ada potensi area investasi tambahan untuk Chrome di luar Privacy Sandbox API.	Kami menghargai masukan tersebut dan kami terus berinteraksi dengan pemangku kepentingan untuk mengevaluasi peran yang dapat dimainkan oleh API Privacy Sandbox ke depannya, serta untuk menjelajahi area baru untuk investasi di masa mendatang, sehubungan dengan pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Privacy Sandbox	Beberapa peserta ekosistem kecewa dengan pengumuman untuk tidak melanjutkan pengenalan mekanisme pilihan pengguna untuk 3PC, tetapi bangga dengan pekerjaan yang telah diselesaikan, mereka mengapresiasi tantangan teknis dalam Privacy Sandbox, dan telah menekankan nilai hubungan kerja kolaboratif mereka dengan Chrome dan kegunaan Hibah Pengujian Pasar.	Kami menghargai masukan tersebut dan setuju bahwa Chrome dapat dan harus berkolaborasi dengan developer untuk menciptakan teknologi yang meningkatkan privasi online sekaligus mempertahankan internet yang didukung iklan.
Berbagi Data Browser	Berbagi data yang dimediasi browser adalah teknologi menarik yang berpotensi mengatasi inefisiensi pasar dan masalah kepercayaan. Browser memiliki nilai sebagai konteks eksekusi pihak ketiga untuk kolaborasi.	Kami menghargai masukan tersebut dan setuju bahwa Chrome dapat dan harus berperan dalam membantu developer membuat teknologi yang meningkatkan kepercayaan antara developer dan pengguna yang berkolaborasi.
Traffic Chrome	Berapa pangsa traffic tanpa cookie di Chrome dan pangsa traffic untuk mode Samaran?	Seperti yang dinyatakan oleh CMA dalam "Notice of intention to release commitments", mode Samaran hanya memengaruhi sebagian kecil aktivitas penjelajahan. Di Inggris Raya dan EEA, mode Samaran Chrome mewakili: kurang dari 10% navigasi di perangkat yang menjalankan sistem operasi Android; dan kurang dari 10% navigasi di perangkat yang menjalankan sistem operasi Windows. Metrik ini hanya merujuk pada navigasi di Chrome berbasis Chromium di Inggris Raya dan EEA. Kami tidak membagikan data tentang browser yang memblokir 3PC. Developer dapat menentukan kapan cookie dipartisi menggunakan Header Akses Penyimpanan dan menggunakan mitigasi yang tersedia dengan tepat.
Label Pengujian Chrome	Apa rencana Chrome untuk 1% traffic tanpa cookie yang diaktifkan untuk pengujian pada tahun 2024?	Saat ini kami belum memiliki rencana untuk dibagikan, tetapi kami bermaksud membagikannya secara publik segera setelah tersedia.
Pengujian Chrome	Apakah penyiapan label pengujian saat ini mencakup perlakuan untuk skenario saat 3PC tersedia dan Privacy Sandbox API diaktifkan?	Penyiapan label pengujian saat ini mencakup perlakuan untuk API 3PC dan Privacy Sandbox dalam bentuk Mode A.
Privacy Sandbox	Sebagian pengiklan menganggap API Privacy Sandbox rumit dan merasa tidak tertarik karena latihan kesiapan sebelumnya, mempertanyakan cara mengukur keuntungan bagi pengguna awal, dan mencari informasi tentang efek penargetan ulang, pencarian prospek, dan pengukuran.	Kami menghargai masukan tersebut dan memahami sentimen tentang latihan kesiapan dan kompleksitas teknologi. Terkait pemahaman performa teknologi Privacy Sandbox saat ini, hasil pengujian kami menunjukkan bahwa partisipasi ekosistem adalah faktor penting dalam memahami performa solusi Privacy Sandbox. Pengujian dengan volume rendah tidak dapat mereproduksi dinamika marketplace dan insentif penggunaan teknologi dalam skala besar.

Pendaftaran & Pengesahan

Tidak ada masukan yang diterima pada kuartal ini.

Menampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Minat Performa dan Utilitas di Topics API dengan Peningkatan	Masukan dari pemangku kepentingan sisi pembelian menunjukkan bahwa Topics API adalah sinyal yang berharga dan menghasilkan data Biaya per Tayangan Iklan (CPM) yang kompetitif dengan data untuk audiens 3PC, untuk kampanye pengiklan. Beberapa penayang menganggap sinyal Topics API memiliki kualitas yang lebih tinggi daripada sinyal web terbuka standar. Mengingat masukan ini tentang kegunaan Topics API, pemangku kepentingan meminta peningkatan, seperti meningkatkan fidelitas dan konsistensi taksonomi, serta memperluas kontrol penayang untuk mendorong adopsi yang lebih luas.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Kegunaan untuk berbagai jenis pemangku kepentingan	Karena pengklasifikasi Topik saat ini hanya menggunakan nama host halaman untuk menentukan topik yang sesuai, situs besar dengan beragam konten memberikan topik umum, sedangkan situs kecil memberikan topik khusus dengan nilai iklan yang lebih besar.	Respons kami serupa dengan kuartal sebelumnya: Seperti halnya 3PC, ada perbedaan nilai informasi yang diberikan oleh berbagai situs. Situs minat khusus tidak konsisten dalam kontribusi nilainya: tidak semua situs minat khusus memiliki konten yang bernilai komersial, sehingga memberikan kontribusi nilai yang lebih kecil. Berikut adalah situs yang akan mendapatkan manfaat dari Topics API. Kami telah mempertimbangkan kemungkinan klasifikasi tingkat halaman, bukan tingkat situs. Namun, ada sejumlah masalah privasi dan keamanan yang signifikan terkait klasifikasi tersebut.
Taksonomi topik tidak cukup terperinci	Topics API tidak memberikan perincian yang memadai untuk penayang berita dengan berbagai bagian konten dalam satu domain, sehingga berpotensi membatasi kegunaan API untuk penargetan iklan.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Peningkatan Pengklasifikasi	Mengizinkan penayang memberikan izin Chrome untuk mengklasifikasikan topik berdasarkan konten halaman (misalnya, head, body).	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan di sini.
Kebijakan	Permintaan klarifikasi tentang pedoman terkait penggunaan Topics API bersama dengan informasi 3PC.	Tidak ada kesulitan dalam menggunakan Topics API dan PC3, karena Topics API menyediakan subset fungsionalitas PC3.
Header Observe-Browse-Topics	Permintaan klarifikasi tentang penerapan header Observe-Browse-Topics, khususnya apakah terus-menerus menampilkan header akan menyebabkan masalah.	Terus-menerus menampilkan header Observe-Browse-Topics: ?1 tidak akan menyebabkan masalah teknis. Browser menangani sinyal ini secara efisien, cukup mencatat bahwa kunjungan halaman memenuhi syarat untuk penghitungan topik tanpa menyebabkan duplikasi atau error. Meskipun tidak diperlukan di setiap halaman, mengirimkannya sebagai header standar di semua dokumen tingkat teratas adalah strategi yang valid dan sederhana.
Kategori Taksonomi	Permintaan untuk memperbarui taksonomi Topik terbaru dengan topik baru.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem di sini.
Nilai Null	Permintaan panduan untuk meningkatkan performa Topics API dan memahami alasan di balik respons null, seperti pemfilteran atau sensitivitas.	Untuk memperjelas, respons null atau kosong dari Topics API adalah fitur privasi yang diharapkan, bukan error. Respons null dapat disebabkan oleh: • Aturan Privasi: Peluang null acak sebesar 5%, atau karena skrip Anda belum "mengamati" pengguna di situs yang terkait dengan topik tersebut. • Status Pengguna: Histori penjelajahan tidak memadai, penggunaan mode Samaran, atau pengguna telah memilih tidak ikut dalam setelan privasi iklan Chrome. • Error Teknis: Situs penayang harus mengirim header Observe-Browse-Topics: ?1, dan iframe yang memanggil apa pun memerlukan izin allow="Browse-topics". Untuk menyelidiki, gunakan halaman chrome://topics-internals penelusuran kesalahan untuk melihat topik apa yang telah dihitung oleh browser Anda dan alasannya. Meskipun fitur privasi mencegah rasio pengisian 100%, Anda dapat meningkatkan performa dengan: • Bekerja sama dengan Penayang: Pastikan partner Anda mengirim header Observe-Browse-Topics: ?1 dengan benar di situs mereka. • Memverifikasi Kode Anda: Jika Anda menggunakan iframe, pastikan kebijakan allow="Browse-topics" sudah diterapkan.

Protected Audience API

Tema Masukan	Ringkasan	Respons Chrome
Adopsi PA API Terhambat oleh Biaya dan Kompleksitas	Pengadopsi membatalkan prioritas atau mengembalikan integrasi Protected Audience API (PA API), dengan alasan biaya operasional, kurangnya permintaan pengiklan, dan volume inventaris yang rendah dari bursa. Beberapa masukan mencakup manfaat potensial PA API, seperti kemampuannya untuk menjangkau audiens yang tahan lama dan jangkauan yang lebih unggul karena tingkat kecocokan yang tinggi.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Fungsi lintas platform	Fungsi lintas platform harus didukung dengan memanfaatkan PA API di seluruh platform untuk membuka kemampuan penargetan ulang dan penargetan audiens yang lebih besar. Google harus mengaktifkan Grup Minat (IG) yang terdaftar di Chrome agar dapat diakses saat menayangkan iklan di lingkungan native atau dalam webview, dan grup minat yang terdaftar di Android harus tersedia di lelang Chrome.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
directFromSellerSignals	Dengan membatasi jumlah informasi yang tersedia di lelang kontekstual, peserta lelang selalu diarahkan melalui server iklan Google. Penayang harus memanggil semua partner exchange terlebih dahulu, lalu Google Ad Manager (GAM) kedua untuk menjalankan lelang kontekstual dan terakhir mengizinkan GAM memanggil lelang IG. Tanpa mengetahui hasil lelang kontekstual secara real time, tidak ada kompetitor yang dapat mengatur keputusan tingkat atas secara adil. Fitur directFromSellerSignals dalam PA API mungkin kurang transparan terkait informasi lelang, sehingga berpotensi menghambat kemampuan untuk mengakses data yang diperlukan. Google harus menghapus directFromSellerSignals atau memperbaruinya agar tidak dapat digunakan untuk menyembunyikan harga penyelesaian lelang server iklan. Misalnya, harga kontekstual dapat diteruskan melalui Chrome melalui kolom yang transparan, tidak dapat diubah, dan bertanda tangan yang dapat diakses dan diverifikasi oleh semua peserta lelang (dan penayang).	Respons kami tidak berubah dari kuartal sebelumnya: Respons Chrome: Informasi yang diteruskan ke runAdAuction() tidak diketahui berasal dari penjual, kecuali jika penjual memanggil runAdAuction() dari iframe-nya sendiri. Dalam lelang multi-penjual, semua penjual tidak dapat membuat frame yang memanggil runAdAuction(). directFromSellerSignals mengatasi masalah ini dengan memuat konten dari paket subresource yang dimuat dari origin penjual. Hal ini memastikan bahwa keaslian dan integritas informasi yang diteruskan ke lelang dari konfigurasi seller-auctions tidak dapat dimanipulasi. Jika penayang ingin menggunakan PA API untuk memahami informasi apa pun yang diteruskan oleh penyedia teknologi mereka ke lelang PA, mereka dapat meminta fungsi ini kepada penyedia teknologi tersebut. Respons 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 Protected Audience, kami bermaksud menepati janji kami dengan memanfaatkan directFromSellerSignals, dan tidak membagikan bid peserta lelang kepada peserta lelang lainnya sebelum lelang selesai dalam lelang multipenjual. Untuk memperjelas, kami juga tidak akan membagikan harga lelang kontekstual ke lelang komponen kami sendiri, seperti yang dijelaskan dalam info terbaru ini.
Pelaporan	Permintaan untuk menambahkan entitas analisis/pelaporan guna mengaktifkan pelaporan terpusat.	Kami sedang mendiskusikan permintaan ini di sini dan menantikan masukan tambahan.
K-Anonimitas di buyerReportingId	Kemampuan untuk menghapus bid berdasarkan k-anonimitas "buyerReportingId" untuk memfasilitasi seleksi audiens dan kewajiban pelaporan dengan penyedia data pihak ketiga.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Peningkatan Debug di Skrip generateBid	Meminta mekanisme untuk mengidentifikasi dengan cepat tahap atau "titik henti" tertentu dalam skrip generateBid tempat proses gagal.	Kami menyadari penggunaan yang diinginkan untuk Pengukuran Real-Time sebagai mekanisme penetapan titik henti sementara untuk lelang di perangkat. Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, sehubungan dengan pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Pemroses Peristiwa untuk Memantau Status runAdAuction	Usulan untuk menambahkan dukungan pemroses peristiwa ke fungsi navigator.runAdAuction PA API untuk meningkatkan pemantauan siklus proses lelang iklan.	Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem di sini.
Penggunaan API	Permintaan untuk mengklarifikasi cara PA API dan Attribution Reporting API (ARA) dapat mendukung kasus penggunaan iklan web tanpa adanya 3PC, terutama untuk pengguna yang telah menonaktifkan 3PC, tetapi tidak menonaktifkan API Privacy Sandbox, dan dalam skenario yang melibatkan sinkronisasi cookie yang gagal dan WebView?	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Latensi	Latensi yang terkait dengan PA API dapat menghambat adopsi, karena penayang dapat memilih untuk menonaktifkan PA API jika latensi terlalu tinggi.	Beberapa peningkatan pada latensi di perangkat telah dilakukan dalam beberapa kuartal terakhir. Pengembangan dan penskalaan layanan Bidding dan Lelang (B&A) berlanjut sesuai kebutuhan. Panduan praktik terbaik latensi kami telah diperbarui untuk menyertakan informasi selengkapnya tentang cara memanfaatkan fitur ini. Kami juga sedang mempelajari pengembangan peningkatan latensi baru, beberapa di antaranya dapat dilihat di sini.
Mencatat Perilaku di B&A (Pengujian vs. Produksi)	Klarifikasi terkait perbedaan perilaku logging antara mode pengujian dan produksi untuk layanan B&A. Khususnya, ketersediaan log cloud dan dampak mode produksi pada logging.	Pertama, penting untuk membedakan antara build prod vs. non-prod dan parameter TEST_MODE terpisah, yang hanya mengaktifkan kunci enkripsi pengujian yang dikodekan secara permanen. Penjelasan di bawah ini berfokus pada jenis build. Di build non_prod, server B&A memiliki tingkat kejelasan yang dapat dikonfigurasi untuk logging. Log mendetail ini ditulis ke aliran stdout/stderr standar. Di Google Cloud, log ini dapat diakses melalui antarmuka logging bawaan, dan di Amazon Web Services, log ini dapat ditemukan di log konsol terlampir. Untuk build produksi, perilaku logging lebih dibatasi. Tingkat kejelasan sudah ditetapkan dan tidak dapat diubah. Meskipun beberapa log yang tidak relevan dengan privasi, seperti pesan startup server dan sebagian besar error crash, masih dicetak ke stdout/stderr, tidak ada log khusus permintaan yang tersedia melalui saluran ini. Satu-satunya log per permintaan dari build produksi adalah untuk permintaan yang berisi token pen-debug-an yang disetujui, dan log ini diekspor secara eksklusif melalui OpenTelemetry. Anda harus menggunakan proses debug yang diizinkan seperlunya, karena traffic yang tinggi dapat menurunkan performa server dan menyebabkan kegagalan pemeriksaan kondisi. Mengenai metrik, semuanya diekspor melalui OpenTelemetry. Metrik yang tidak sensitif terhadap privasi selalu diekspor apa adanya, tanpa "noise". Sebaliknya, metrik yang sensitif terhadap privasi selalu "diberi noise" saat diekspor dari server yang berjalan dalam mode produksi. Konfigurasi telemetri tertentu menentukan apakah metrik yang sensitif terhadap privasi ini diekspor sebagai metrik yang diberi derau, tidak diberi derau, atau keduanya.
Menyertakan Jalur Halaman Lengkap dalam Sinyal Bidding Tepercaya untuk Keamanan Brand	Permintaan untuk memperbarui PA API agar menyertakan jalur URL lengkap halaman tingkat teratas, selain nama host, dalam permintaan pengambilan untuk trustedBiddingSignals. Kasus penggunaan utamanya adalah untuk mengaktifkan kontrol perlindungan merek yang lebih terperinci. Pengiklan sering kali perlu memblokir iklan agar tidak muncul di bagian tertentu dari domain (misalnya, situsberita.com/politik) meskipun mereka merasa nyaman dengan domain tersebut secara umum. Karena daftar blokir ini dapat berisi jutaan entri, daftar ini harus dievaluasi di sisi server. Spesifikasi saat ini, yang hanya mengirimkan nama host, membuat server trustedBiddingSignals tidak dapat melakukan evaluasi tingkat jalur yang diperlukan ini, sehingga membatasi kemampuan keamanan merek.	Saat ini kami sedang mendiskusikan masalah ini di sini, setelah diskusi sebelumnya yang panjang, yang dapat dilihat di sini, dan kami menerima masukan tambahan. Namun, kami ingin mengklarifikasi bahwa kami hanya mempertimbangkan untuk menambahkan informasi ini jika pengambilan trustedBiddingSignals dilakukan ke server yang berjalan di dalam Trusted Execution Environment (TEE).

Lelang Terlindungi (Layanan B&A)

Tema Masukan	Ringkasan	Respons Chrome
Menguji Ketersediaan	Informasi mengenai ketersediaan Key/Value (KV) v2 untuk pengujian di lingkungan Chrome dan B&A.	KV v2 tersedia di B&A dan Chrome. Panduan tambahan tersedia di sini.
Implementasi Server KV	Permintaan klarifikasi tentang penggunaan server KV, khususnya terkait pemetaan URL render materi iklan ke data permintaan, perlunya koordinasi antara SSP dan DSP untuk menentukan parameter dalam URL render, dan ketersediaan dokumentasi yang menguraikan koordinasi dan penyimpanan data yang diperlukan dalam mode KV.	Layanan KV menggunakan renderURL sebagai kunci. Jika URL baru, URL tersebut akan disimpan. Jika ada, nilainya akan ditampilkan untuk digunakan dalam scoreAd. Format yang ditampilkan bergantung pada penyiapan: "Bring Your Own Server" (BYOS) memungkinkan nilai apa pun, sedangkan layanan KV Tepercaya memerlukan Fungsi yang Ditentukan Pengguna. Meskipun tidak selalu diperlukan, koordinasi dengan DSP sangat penting untuk fitur seperti penggantian makro (misalnya, ${AD_WIDTH}) di renderURL, yang memungkinkan penyesuaian dan verifikasi iklan dinamis. Sebaiknya mulai dengan pengujian sederhana dengan satu DSP untuk menentukan tingkat koordinasi yang diperlukan. Kami juga sedang dalam proses memperbarui dokumentasi KV dan akan membagikannya secara publik setelah tersedia.
BYOS untuk B&A	Mengapa B&A tidak menawarkan mode BYOS yang serupa dengan mode BYOS KV?	B&A memerlukan TEE, sehingga mencegah model BYOS, karena menangani kombinasi data yang sangat sensitif yang memerlukan penerapan mekanisme privasi, seperti yang dijelaskan di bawah. Untuk DSP: B&A memproses konteks penayang (berpotensi URL lengkap jika dikirim secara eksplisit oleh penjual melalui auctionSignals / perBuyerSignals) yang digabungkan dengan data IG pengguna yang mendetail. TEE sangat penting untuk memproses kombinasi ini secara aman dan untuk mencegah potensi identifikasi ulang pengguna. Di KV BYOS, URL lengkap tidak dapat dikirim. Untuk SSP: Hanya dengan mengetahui kombinasi IG yang berpartisipasi (dan pemilik DSP-nya) dalam lelang dapat menghasilkan tanda tangan identifikasi. Di sinilah solusi pengecohan berperan, yang memerlukan penggunaan TEE. Oleh karena itu, pemrosesan aman sinyal sensitif gabungan ini dan penegakan mekanisme privasi memerlukan lingkungan yang dikontrol dan teruji dari TEE.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Kebijakan Kebisingan	Penerapan ARA telah bermanfaat bagi beberapa peserta pasar dan Google harus terus mempertahankan pelaporan tingkat peristiwa. Google harus mempertimbangkan untuk melonggarkan kebijakan kebisingan dalam skenario saat ARA dan 3PC tersedia. Pengiklan Performa semakin banyak menggunakan penerapan kolom 'nilai' saat ini dari peristiwa fleksibel ARA, dan kebijakan derau yang tidak terlalu ketat akan membantu mengurangi penundaan dan pelaporan yang tidak akurat.	Mekanisme ini merupakan bagian mendasar dari desain ARA, yang dimaksudkan untuk melindungi privasi pengguna dengan mencegah pelacakan individual. Kami mempertimbangkan masukan tentang tantangan pelaporan yang disebabkan oleh derau, saat kami terus mengevaluasi peran API Privacy Sandbox ke depannya, serta potensi peningkatan di masa mendatang, sehubungan dengan pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Roadmap dan Dukungan Jangka Panjang	Meminta peta produk untuk ARA, serta konfirmasi investasi dan dukungan jangka panjang mengingat pengumuman untuk tidak melanjutkan pengenalan mekanisme pilihan pengguna untuk 3PC.	Tim Privacy Sandbox berinteraksi dengan ekosistem untuk memahami peran yang akan dimainkan oleh Privacy Sandbox API ke depannya dan untuk mengevaluasi investasi apa pun di masa mendatang.
Pengukuran Lintas Lingkungan (Aplikasi ke Web)	Permintaan solusi yang melibatkan penggunaan ARA untuk memfasilitasi pengukuran lintas lingkungan, menawarkan alur data yang lebih bersih dan andal, serta meningkatkan kemampuan untuk menghubungkan interaksi pengguna di berbagai platform.	App-to-Web di perangkat yang sama sudah didukung oleh ARA. Anda dapat menemukan detail selengkapnya tentang solusi pengukuran lintas aplikasi dan web di sini dan di sini.
Atribusi Lintas Browser	Pendekatan ARA lintas browser yang terpadu akan secara signifikan meningkatkan kemampuan mengukur ROI di web terbuka dan memberikan alternatif yang stabil menjelang potensi perubahan peraturan. Chrome harus berkolaborasi dengan tim Safari untuk menemukan solusi seperti ini.	Kami sudah mempelajari API yang dapat beroperasi dengan vendor browser lain dalam grup PATCG dan PATWG di W3C. Mengingat bahwa pekerjaan ini masih dalam tahap awal, pemangku kepentingan dapat melihat progres kami di sini.
Pengukuran Lintas Perangkat/Offline	Ketidakmampuan untuk mendukung pengukuran konversi lintas-perangkat dalam ARA merupakan batasan yang signifikan. Mengukur konversi online ke offline juga sangat penting, dan browser dapat berperan dalam berkolaborasi dengan vendor pengukuran.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Atribusi Multi-Sentuh	Permintaan untuk mengizinkan pengiklan menggunakan data Privacy Sandbox sebagai "kebenaran nyata" yang tidak bias untuk memvalidasi dan mengalibrasi model atribusi yang ada. Hal ini dapat dicapai dengan menggunakan data yang disediakan browser ARA sebagai sinyal kalibrasi yang andal, sehingga menciptakan dasar kebenaran.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Pengukuran Traffic Tanpa Izin/Traffic yang Memilih Tidak Bersedia	Solusi yang menjaga privasi, seperti Atribusi Pribadi yang Interoperabel, akan memungkinkan pengukuran untuk traffic tanpa izin. Hal ini akan memungkinkan pemahaman yang lebih komprehensif tentang performa kampanye dengan menyertakan data dari pengguna yang telah memilih untuk tidak dilacak, sehingga mengatasi kesenjangan besar dalam pengukuran yang disebabkan oleh persyaratan izin.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Atribusi Server ke Server	Permintaan untuk mengizinkan teknologi iklan dengan infrastruktur sisi server yang canggih berintegrasi dengan ARA secara lebih fleksibel, mengakomodasi kasus penggunaan yang sulit dikelola hanya di sisi klien, sekaligus menjaga privasi pengguna.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Pendaftaran Multi-Domain	Mencari klarifikasi tentang batasan dan peringatan saat mendaftarkan beberapa domain dengan ARA, terutama terkait layanan agregasi dan atribusi lintas asal.	Berikut adalah batasan utama saat menggunakan ARA dengan beberapa domain: • Atribusi dicakup ke satu asal. Anda tidak dapat mencocokkan klik dari salah satu domain Anda dengan konversi di domain lain. Atribusi di-sandbox ke origin yang sama untuk sumber dan pemicu. • Layanan Agregasi tidak mendukung pengelompokan multi-origin. Laporan dari berbagai asal harus dikelompokkan dan diproses secara terpisah. Kami sedang mencari cara untuk mendukungnya pada masa mendatang. Singkatnya, meskipun beberapa domain dapat didaftarkan di satu entitas, semua fungsi ARA, seperti atribusi dan agregasi, saat ini harus ditangani berdasarkan per-origin.

Layanan Agregasi

Tidak ada masukan yang diterima pada kuartal ini.

Private Aggregation API

Tema Masukan	Ringkasan	Respons Chrome
Batas dan Tingkat Kebisingan	Kekhawatiran terkait batasan ukuran kunci agregasi dan nilai agregasi dalam Private Aggregation API.	Ukuran kunci dan nilai agregasi dipilih agar memiliki perincian yang tinggi sekaligus membatasi biaya jaringan dan penyimpanan. Sebaiknya gunakan hashing saat menetapkan kunci untuk memaksimalkan fleksibilitas. Meskipun ada faktor lain yang melindungi data pengguna, penambahan derau adalah bagian penting dari perlindungan privasi Private Aggregation API. Kami mempertimbangkan masukan tersebut dan akan terus mengevaluasi pilihan parameter yang sesuai seiring dengan pertimbangan kami terhadap peran yang akan dimainkan oleh API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.
Privasi vs. Kegunaan	Pendekatan Privacy Sandbox dapat memprioritaskan privasi daripada kegunaan, sehingga berpotensi menghambat adopsi. Saran untuk mengizinkan berbagi data yang lebih terperinci dengan izin pengguna untuk meningkatkan pengukuran dan personalisasi iklan.	Ukuran kunci dan nilai agregasi dipilih agar memiliki perincian yang tinggi sekaligus membatasi biaya jaringan dan penyimpanan. Sebaiknya gunakan hashing saat menetapkan kunci untuk memaksimalkan fleksibilitas. Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, sehubungan dengan pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.

Membatasi Pelacakan Tersembunyi

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tema Masukan	Ringkasan	Respons Chrome
Deteksi Spam	Jika permintaan pertama dari situs yang menggunakan sistem deteksi spam mengandalkan petunjuk klien, sistem pelacakan atau deteksi dapat gagal mengidentifikasi atau mengategorikan permintaan dengan benar.	Kasus penggunaan yang mengandalkan akses ke Client Hints Agen Pengguna (UA-CH) pada permintaan pertama harus menggunakan petunjuk klien penting.
Masukan API	Pertimbangkan untuk menghentikan penggunaan Sec-CH-USA-Wow64 karena tidak lagi relevan untuk web modern.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan di sini. Kami juga menerima masukan bahwa akan berguna untuk memperluas wow64 di luar Windows.

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
Kontrol	Permintaan untuk tombol Perlindungan IP agar situs dapat menggunakannya secara selektif di luar mode Samaran.	Kami menghargai masukan tersebut dan kami menerima masukan tambahan tentang masalah ini di sini.
Perbuatan yang tidak pantas	Apakah Token Pengungkapan Probabilistik (PRT) yang menghasilkan nilai NULL akan mencegah identifikasi pelaku saat polisi meminta pengungkapan alamat IP untuk pelanggaran platform?	Jika domain digunakan secara eksklusif untuk deteksi penipuan dan penyalahgunaan, domain tersebut kemungkinan tidak disertakan dalam Daftar Domain Bertopeng (MDL) dan oleh karena itu tidak terpengaruh oleh Perlindungan IP. Oleh karena itu, PRT tidak diperlukan untuk domain tersebut. Jika domain disertakan dalam MDL, saat ini PRT adalah satu-satunya cara untuk mengetahui alamat IP asli untuk permintaan yang di-proxy. Karena PRT dirancang khusus untuk mendukung analisis gabungan, bukan identifikasi individu, memang benar bahwa PRT tidak akan berisi alamat IP dalam sebagian besar kasus. Kami memperkirakan hal ini akan berdampak terbatas dalam skenario yang dijelaskan, namun, karena Perlindungan IP hanya berlaku dalam konteks pihak ketiga, yang berarti bahwa penayang akan terus menerima alamat IP yang tidak di-proxy untuk interaksi pihak pertama, seperti pengguna yang mengunjungi situs platform online.
Anti-Penipuan	Apa saja spesifikasi langkah-langkah anti-penipuan Google untuk Perlindungan IP, termasuk detail tentang pembatasan kecepatan akses ke proxy dan penerbitan token autentikasi, dan apa saja kasus penggunaan spesifik untuk PRT?	Kami mengonfirmasi bahwa pembatasan kapasitas dan token autentikasi di IP Protection dirancang untuk mencegah bot melakukan penipuan iklan dengan mengakses proxy secara berlebihan, seperti yang dijelaskan dalam strategi anti-penipuan dan anti-spam. Kasus penggunaan lebih lanjut untuk PRT diuraikan dalam dokumentasi penjelasan PRT di sini.
Mode Samaran	Apakah Perlindungan IP dalam mode Samaran masih direncanakan untuk Kuartal 3?	Saat ini tidak ada perubahan pada linimasa peluncuran Perlindungan IP pada Kuartal 3 dalam mode Samaran.

Mitigasi Pelacakan Pantulan

Tema Masukan	Ringkasan	Respons Chrome
Masukan API	Chrome harus memblokir akses cookie/penyimpanan, bukan mempartisinya, saat menerapkan Mitigasi Pelacakan Pantulan (BTM), dengan alasan perilaku yang tidak diinginkan dan kebingungan dari metode "partisi" Safari.	Kami menyambut baik saran ini. Saat ini, BTM tidak melibatkan partisi cookie/penyimpanan, tetapi menghapusnya setelah masa tenggang. Jika ada desain BTM selanjutnya yang melibatkan tindakan langsung terhadap cookie, kami bermaksud untuk lebih memilih memblokir cookie daripada mempartisinya.

Memperkuat batasan privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tidak ada masukan yang diterima pada kuartal ini.

Fenced Frames API

Tidak ada masukan yang diterima pada kuartal ini.

Shared Storage API

Tema Masukan	Ringkasan	Respons Chrome
Permintaan Fitur API	Permintaan untuk menambahkan tayangan iklan dan klik di Penyimpanan Bersama.	Kami mempertimbangkan masukan ini saat mengevaluasi peran API Privacy Sandbox ke depannya, mengingat pengumuman Google pada April 2025 bahwa pendekatan saat ini untuk menawarkan pilihan 3PC kepada pengguna di Chrome akan dipertahankan.

CHIP

Tema Masukan	Ringkasan	Respons Chrome
Pertanyaan API	Permintaan klarifikasi tentang cara kontrol 3PC Chrome berinteraksi dengan CHIPS, khususnya apakah cookie yang tidak dipartisi dikonversi menjadi cookie yang dipartisi saat 3PC dinonaktifkan, dan apakah cookie yang dipartisi tetap aktif.	Cookie yang tidak dipartisi tidak akan disimpan, diambil, atau dikirim dalam konteks pihak ketiga saat 3PC dinonaktifkan. Namun, cookie berpartisi akan terus disimpan, diambil, dan dikirim dalam konteks pihak ketiga, karena fungsinya tidak terpengaruh oleh setelan browser yang menonaktifkan 3PC.
Masalah Privasi	Kekhawatiran bahwa pihak yang disematkan dengan ID persisten, seperti untuk Single Sign-On, mungkin masih memungkinkan pihak yang menyematkan dan pihak yang disematkan mendapatkan ID digital global, meskipun dengan cookie yang dipartisi.	Meskipun pihak yang disematkan mungkin memiliki ID persisten, ID ini, saat disimpan dalam cookie yang dipartisi, hanya dapat diakses di situs tempat cookie ditetapkan oleh sematan. Penggabungan lintas situs ID ini akan memerlukan tindakan login, yang sudah memungkinkan pertukaran ID dalam bentuk token autentikasi, bahkan tanpa penggunaan cookie yang dipartisi.

FedCM

Tema Masukan	Ringkasan	Respons Chrome
Penggunaan API	Mediasi senyap gagal untuk pengguna dengan beberapa akun tanpa error tertentu.	Perilaku mediasi senyap adalah fitur menurut desain, karena ditujukan untuk kasus yang sangat spesifik dengan hanya satu akun yang tersedia. Sebaiknya gunakan mediasi "opsional", yang membuat FedCM melakukan penggantian ke tampilan pemilih akun kepada pengguna jika mediasi senyap tidak memungkinkan.
Penggunaan API	navigator.credentials.get menampilkan error umum, sehingga mencegah pengambilan alasan penolakan tertentu seperti penutupan oleh pengguna atau periode tunggu.	Ketidakmampuan developer untuk membedakan antara pengguna yang menutup dialog FedCM vs. error jaringan vs. FedCM yang berada dalam "periode tunggu" karena pengguna sebelumnya telah menutup dialog juga merupakan fitur menurut desain, yang dimaksudkan untuk menjaga privasi pengguna. Kekhawatirannya adalah kemampuan tersebut akan memungkinkan situs menyimpulkan status login pengguna di Penyedia Identitas (IdP) yang berbeda.
Login	Perilaku pemilihan akun yang tidak konsisten dengan beberapa akun yang login diamati.	Tidak jelas apakah ketidakmampuan sesekali untuk memilih akun tertentu dalam skenario beberapa akun yang login adalah bug sesekali di FedCM atau masalah yang melibatkan sistem pengujian. Kami sedang berupaya menyelesaikan masalah ini bersama pelapor, dan telah meminta detail lebih lanjut untuk lebih memahami masalah tersebut.
Penggunaan API	Jika pengguna menutup dialog saat memberikan otorisasi dengan FedCM, fakta bahwa mereka berada dalam status pendinginan tidak dilaporkan melalui error yang dapat ditangkap.	Ya, hal itu akan terjadi dan akan menghasilkan kode error generik untuk menjaga privasi pengguna.
Penggunaan API	Mengapa FedCM memasuki periode tenang selama 10 menit setelah "autentikasi ulang" otomatis berhasil?	Mengingat autentikasi ulang otomatis terjadi tanpa tindakan yang dimulai pengguna, jika pengguna ingin kembali ke situs, tetapi login dengan akun lain, mereka memerlukan jangka waktu saat FedCM tidak mengautentikasi ulang mereka secara otomatis. "Periode tenang" memberikan peluang bagi pengguna untuk login secara manual menggunakan akun lain. Postingan blog ini berisi detail lebih lanjut tentang "masa tenang" ini.
FedCM Ringan	Kekhawatiran bahwa proposal FedCM Ringan memperkenalkan kompleksitas tambahan bagi IdP karena kebutuhan untuk mendukung dua penerapan yang tidak kompatibel (FedCM vs. FedCM Ringan).	FedCM Ringan kompatibel dengan FedCM tradisional. IdP dapat memilih metode penerapan yang akan digunakan dan tidak diwajibkan untuk mendukung keduanya. FedCM Ringan adalah mekanisme push untuk FedCM. Jika IdP memilih untuk menggunakan fitur ini, IdP dapat mengirimkan informasi akun ke browser saat pengguna login, sehingga, saat Pihak Tepercaya (RP) memanggil FedCM, akun akan diambil dari browser, bukan dari endpoint akun IdP.
FedCM Ringan	Kekhawatiran tentang tereksposnya data pengguna pribadi seperti nama, email, dan foto profil ke RP dalam proposal FedCM Ringan.	Proposal untuk Lightweight FedCM telah diperbarui sejak menerima masukan ini, untuk menghapus nama, email, dan gambar profil dari respons metode.
FedCM Ringan	Mengelola beberapa akun yang login tampaknya terlalu kaku dalam proposal Lightweight FedCM. Saat ini, proposal tidak mendukung masa aktif sesi individual atau status login yang berbeda-beda per akun.	Masa berlaku saat ini terikat dengan IdP dalam objek kredensial. Kami telah mencatat masa berlaku per akun sebagai pertanyaan terbuka dan akan mempertimbangkan masukan ini untuk pengembangan selanjutnya.
FedCM Ringan	Perbedaan antara "login" dan "tersedia untuk dipilih" tidak ditentukan dengan jelas, yang dapat memengaruhi pengalaman pengguna untuk proposal FedCM Ringan.	Saat ini kami tidak mendukung kemampuan untuk membedakan apakah akun login atau logout di Antarmuka Pengguna (UI) FedCM. Akun yang telah logout tidak boleh dicantumkan. Jika akun logout dan tercantum, dan pengguna memilih akun yang tidak aktif login, Continuation API dapat digunakan untuk membuat pengguna login kembali.
Penggunaan API	Inkonsistensi antara kolom given_name di getUserInfo dan penggunaannya di UI FedCM.	Masalah ini dibahas lebih lanjut dengan Mozilla di sini, untuk menyelaraskan cara given_name harus ditangani di getUserInfo.
Penggunaan API	Tidak semua kolom yang digunakan di UI dari IdentityProviderAccount disediakan untuk getUserInfo, khususnya tel dan username, yang menunjukkan perlunya sinkronisasi.	Diskusi dengan Mozilla dan anggota FedID Community Group lainnya sedang berlangsung terkait masalah mencocokkan kolom mana dari IdentityProviderAccount yang dikirim ke getUserInfo.
FedCM untuk Perusahaan	Permintaan dukungan FedCM untuk kasus penggunaan IdP Enterprise.	Masalah utamanya adalah kebutuhan akan mekanisme yang tepercaya bagi IdP untuk memberi sinyal kepada browser bahwa administrator telah memberikan izin sebelumnya untuk mengizinkan pengguna mengakses RP tertentu yang tidak dapat ditiru dan/atau disalahgunakan oleh pelacak Web. Hal ini dibahas dalam rapat FedID CG pada 22 April (silakan temukan catatan rapat di sini) dan kombinasi ekstensi browser dan Kebijakan Perusahaan (untuk perangkat terkelola) diajukan sebagai solusi potensial. Kami menerima masukan tambahan tentang masalah ini di sini.

Mencegah spam dan penipuan

Private State Token API (dan API lainnya)

Tidak ada masukan yang diterima pada kuartal ini.