Laporan Masukan - Kuartal 1 2024

Laporan kuartalan untuk Kuartal 1 2024 yang merangkum masukan ekosistem yang diterima tentang proposal Privacy Sandbox dan respons Chrome.

Sebagai bagian dari komitmennya terhadap CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox (lihat paragraf 12 dan 17(c)(ii) Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima oleh Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang disediakan di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menyambut masukan yang diterima dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.

Tema masukan diberi peringkat menurut prevalensi per API. Hal ini dilakukan dengan mengagregasi jumlah masukan yang telah diterima tim Chrome seputar tema tertentu dan mengaturnya dalam urutan menurun. Tema masukan umum diidentifikasi dengan meninjau topik diskusi dari rapat publik (W3C, PatCG, IETF), masukan langsung, GitHub, dan pertanyaan umum yang muncul melalui tim internal Google dan formulir publik.

Lebih khusus lagi, menit rapat untuk rapat badan standar web ditinjau dan, untuk masukan langsung, catatan Google tentang pertemuan pemangku kepentingan 1:1, email yang diterima oleh masing-masing engineer, milis API, dan formulir masukan publik dipertimbangkan. Google kemudian berkoordinasi antartim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif dari tema yang muncul dalam kaitannya dengan setiap API.

Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat untuk masalah yang diajukan oleh pemangku kepentingan, dan menentukan posisi khusus untuk tujuan latihan pelaporan publik ini. Dengan mencerminkan fokus pengembangan dan pengujian saat ini, kami menerima pertanyaan dan masukan khususnya sehubungan dengan Topics, Protected Audience, dan Attribution Reporting API.

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

Glosarium akronim

ARA

Attribution Reporting API

CHIP

Cookie yang Memiliki Status Terpartisi Independen

DSP

Platform Sisi Permintaan

FedCM

Pengelolaan Kredensial Federasi

FPS

Set Pihak Pertama

IAB

Interactive Advertising Bureau

IDP

Penyedia Identitas

IETF

Satu Tugas Internet Engineering

IP

Alamat Protokol Internet

openRTB

Bidding real-time

lewat batas waktu

Uji Coba Origin

API PAT

Protected Audience API (sebelumnya FLEDGE)

PatCG

Grup Komunitas Teknologi Periklanan Pribadi

RP

Pesta Santai

RWS

Set Situs Terkait (sebelumnya Set Pihak Pertama)

SSP

Platform Sisi Suplai

TEE

Trusted Execution Environment

UA

String Agen Pengguna

UA-CH

Petunjuk Klien Agen Pengguna

W3C

Konsorsium World Wide Web

WIPB

Kebutaan IP yang Disengaja

Masukan umum, tidak ada API atau Teknologi tertentu

Tema Masukan	Ringkasan	Respons Chrome
Tata kelola	Minat terhadap periode komentar publik untuk perubahan tata kelola pada Privacy Sandbox.	Kami menerima masukan dari pemangku kepentingan yang wajar terkait perkembangan signifikan terkait Privacy Sandbox, termasuk tata kelola Privacy Sandbox di masa mendatang.
Pengujian	Fase pengujian tambahan untuk 3PCD selain Pengujian yang difasilitasi Chrome sebesar 1% saat ini.	Kami tidak bermaksud untuk menawarkan pengujian yang difasilitasi Chrome di luar 1% traffic Chrome saat ini yang telah diaktifkan sejak awal Januari.
Web ke Aplikasi	3PCD di perangkat seluler tidak seharusnya terjadi sebelum interoperabilitas penuh antara web dan aplikasi tercapai.	Kami setuju bahwa hal yang diinginkan untuk mendukung interoperabilitas aplikasi dan web, serta telah meluncurkan pengukuran atribusi lintas aplikasi dan web, serta sedang mengeksplorasi solusi penargetan web ke aplikasi. Namun, kami tidak berencana menunda 3PCD di web seluler. Kami tidak memiliki sasaran cakupan 100% di akhir 3PCD. Namun, kami mengharapkan kompatibilitas di Android untuk pengukuran lintas aplikasi dan web cukup tinggi pada 3PCD dan akan meningkat seiring waktu saat pengguna mengupdate ponsel mereka.
Peran Browser	Chrome tampaknya mengambil peran sebagai server iklan atau SSP.	Chrome tidak berperan sebagai server iklan atau SSP. Dengan PA API, Chrome menyediakan container bagi server iklan, SSP, DSP, dan teknologi iklan lainnya untuk menggunakan logika bidding dan penskoran mereka sendiri.
Panduan Kasus Penggunaan	Panduan yang lebih jelas tentang kasus penggunaan yang akan didukung oleh API Privacy Sandbox.	Pada awal project Privacy Sandbox, dokumentasi developer terutama berfokus untuk mengajak developer ke dalam proses diskusi dan masukan untuk semua proposal. Artinya, struktur konten secara umum disusun untuk memahami motivasi dan konsep di balik project, diikuti detail pengembangan awal dan detail pengujian untuk setiap proposal. Hal ini efektif dalam membangun kolaborasi ekosistem yang nyata dalam mengembangkan proposal, tetapi seiring perkembangan API hingga ketersediaan umum, ada audiens developer baru yang berada di sini terutama untuk membangun API, bukan berkontribusi pada pengembangan yang mendasarinya. Baru-baru ini kami memperbarui navigasi developer.google.com/privacy-sandbox Pendekatan berbasis kasus penggunaan terhadap dokumentasi tersebut akan terus kami lanjutkan.
Lingkungan Pengembangan Lokal	Bagaimana cara kami terus mengembangkan dan menguji frontend secara lokal di http://localhost saat cookie SameSite=Secure dan backend di-fronted oleh CDN?	Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan dari ekosistem.
Mitigasi 3PCD	Apakah ada cara terprogram untuk mengetahui bahwa 3PC diblokir atau ketika heuristik aktif?	Di Chrome, deteksi fitur dan document.hasStorageAccess yang dipanggil dalam iframe memungkinkan developer untuk mengetahui apakah origin dalam iframe memiliki akses ke 3PC.
Pengujian Video	Saat ini tidak dapat menguji iklan video di Privacy Sandbox.	Chrome memposting diskusi dan demonstrasi tentang beberapa kemungkinan cara menyelesaikan video dengan PA API saat ini (lihat 242 dan 254 di repositori demo kami di GitHub). Perlu diketahui bahwa hal ini tidak dimaksudkan sebagai kode contoh yang akan diadopsi oleh teknologi iklan secara grosir, melainkan sebagai bukti konsep dan demonstrasi teknik yang dapat mendukung rendering video VAST dengan PA API. Dalam diskusi ini, juga semakin jelas bahwa meskipun rendering video sudah mungkin dilakukan saat ini, ada perubahan yang dapat dilakukan Chrome yang akan menyederhanakan penerapan dengan PA API. Misalnya, pembaruan pada penggantian makro (dibahas di sini) yang sudah kami rencanakan untuk diatasi berdasarkan masukan tentang kasus penggunaan keamanan merek pemverifikasi iklan pihak ketiga, juga akan menanggapi masukan dalam kasus penggunaan video, saat pembeli mencari makro penjual mana yang akan digunakan dalam rendering. Sebagian besar diskusi hingga saat ini secara khusus difokuskan pada rendering iklan video VAST. Rendering iklan Native dapat menggunakan pendekatan yang sama, dan dalam banyak hal lebih mudah. Iklan native saat ini tampaknya kurang mendapatkan perhatian dibandingkan video, tetapi ini hanyalah pertanyaan prioritas industri teknologi iklan, bukan kendala teknis apa pun terhadap penerapan.
Pengukuran non-iklan	3PCD dapat memengaruhi solusi pengukuran audiens yang tidak terkait dengan iklan.	API pengukuran tidak mengharuskan kasus penggunaan terkait iklan. Meskipun ARA lebih spesifik untuk perjalanan periklanan biasa, Agregasi Pribadi adalah tujuan umum. Kedua elemen penyusun ini dapat digunakan untuk menangani berbagai aktivitas pengukuran.
Kreator Konten	Privacy Sandbox disusun untuk mendorong kreator konten membuat lebih banyak konten untuk YouTube dan lebih sedikit konten di situs mereka sendiri.	Inisiatif Privacy Sandbox berfokus menjaga aktivitas pengguna agar tetap pribadi di internet terbuka dan gratis. Kami tahu penayang mengandalkan iklan untuk memproduksi konten dan menyediakannya seluas mungkin. Pengiklan membantu orang menemukan produk atau penawaran baru yang mungkin mereka inginkan. Fitur Privacy Sandbox memungkinkan semua jenis situs, termasuk situs yang bekerja sama dengan kreator konten, untuk menampilkan iklan yang bermanfaat kepada orang-orang berdasarkan aktivitas mereka di berbagai pihak, tanpa mengungkapkan identitas pengguna kepada pihak tersebut.
Linimasa yang Lebih Jelas	Jadwal rilis yang lebih jelas dan mendetail untuk teknologi Privacy Sandbox.	Dokumentasi Privacy Sandbox API mencakup status dan halaman ketersediaan API. Halaman ini mencantumkan fitur mendatang dan linimasanya (mis. PA API, ARA). dapat dilihat gambaran utama status-status ini di sini.
Machine Learning	Teknologi iklan tidak dapat melatih model machine learning dengan benar hingga 3PCD melebihi 1%.	Memperluas 3PCD ke lebih banyak browser untuk pengujian tidak akan menjamin bahwa API akan mengalami lebih banyak penggunaan, yang mungkin dicari oleh teknologi iklan untuk melatih model machine learning lebih lanjut. Jika penggunaan ekosistem yang lebih luas bukanlah yang dicari teknologi iklan untuk melatih model machine learning lebih lanjut, tidak ada alasan untuk memperluas 3PCD karena teknologi iklan yang ingin melatih model pada lebih banyak traffic dapat melakukannya saat ini tanpa peningkatan 3PCD. Hal ini dapat dilakukan tanpa Chrome muncul untuk melanjutkan pada 3PCD sebelum penghentian Standstill.
Kasus Penggunaan yang Tidak Didukung	Kasus penggunaan DSP mandiri saat ini tidak dipertimbangkan.	Ada beberapa DSP layanan mandiri yang secara rutin memberikan masukan publik tentang API. Beberapa DSP tersebut yang memberikan masukan publik rutin juga telah mendaftarkan diri mereka sebagai penguji. Selain itu, Chrome secara aktif membahas topik DSP layanan mandiri umum seperti server iklan pihak ketiga dan video. Panggilan PA API mingguan terbaru telah membahas topik ini.
Uji Coba Origin	Permintaan OT untuk situs yang menginginkan peningkatan dan cakupan pengujian yang lebih agresif untuk 3PCD.	Chrome saat ini sedang mengembangkan OT pihak pertama, yang akan memungkinkan origin memilih ikut serta dalam perilaku penghentian 3PC. 3PC asal tingkat atas yang mendaftar untuk uji coba ini dan men-deploy token akan diblokir seolah-olah perangkat pengguna mengaktifkan perlindungan pelacakan. OT ini akan memberikan peluang berharga bagi situs untuk melakukan pengujian alternatif jangka panjang yang lebih luas terhadap 3PC, sebelum penghentian 3PC yang dijadwalkan akan berlangsung setelah berkonsultasi dengan CMA. Kami masih berupaya menyelesaikan linimasa peluncuran OT.
Laporan IAB Tech Lab	Masukan tentang Privacy Sandbox diterima dari IAB Tech Lab Report.	Kami merespons laporan IAB Tech Lab secara mendetail di sini. Kami juga mengakui bahwa "laporan ini menimbulkan pertanyaan seputar dokumentasi yang terfragmentasi, persyaratan komersial, audit pihak ketiga, akreditasi industri, skalabilitas, transparansi, dan tata kelola masa depan, yang akan kami libatkan dengan ekosistem dan memperbarui FAQ publik kami sebagaimana mestinya". Kami menangani dokumentasi yang terfragmentasi sebelumnya. Kami menangani persyaratan komersial dalam "Jaminan Data" di sini dan beberapa produk Google Ads telah membagikan pendekatannya. Kami membahas audit pihak ketiga di bagian "Jaminan Integritas Algoritma" di sini. Terkait akreditasi, kami berharap lembaga tersebut terus memberikan akreditasi produk, termasuk penggunaan teknologi, bukan teknologi itu sendiri. Terkait skalabilitas, kami terus terbuka terhadap data dari developer yang menunjukkan masalah. Terkait transparansi dan tata kelola, kami terus mengembangkannya secara terbuka di GitHub dan di forum seperti W3C sambil berinteraksi dengan CMA berdasarkan Komitmen.
Login dengan Google	Login dengan Google akan menyebabkan Google memiliki kemungkinan untuk menggunakan data login identifikasi silang yang bertentangan dengan Komitmen.	Login dengan Google tidak memungkinkan Google menggunakan data yang bertentangan dengan Komitmen.
Kompatibilitas	Apa yang rencana untuk dukungan Privacy Sandbox API serta kompatibilitas maju / mundur?	Setelah Chrome meluncurkan fitur untuk ketersediaan umum, kami ingin mempertahankan dukungan untuk fitur tersebut. Tentu saja, tidak selalu mungkin untuk mempertahankan kompatibilitas mundur. Dalam kasus seperti ini, kami memiliki proses yang jelas untuk penghentian penggunaan dan penghapusan fitur yang ada, yang dijelaskan di sini. Kami berharap dapat terus menambahkan lebih banyak fitur ke Privacy Sandbox API seiring waktu, sebagai respons terhadap masukan ekosistem tentang kasus penggunaan yang akan mendapatkan manfaat dari peningkatan dukungan. Dalam kasus seperti ini, kami cenderung menyertakan semacam teknik Deteksi Fitur, sehingga teknologi iklan yang tertarik untuk bereksperimen dengan fitur baru dapat langsung menanyakan kepada browser apakah fitur tersebut didukung atau tidak. Ini lebih baik daripada meminta developer untuk memeriksa nomor versi Chrome tertentu, karena beberapa fitur mungkin tidak diluncurkan ke semua pengguna Chrome secara bersamaan. Misalnya, cara kerja deteksi fitur kami untuk PA API dapat ditemukan di sini.
Implementasi Server	Daripada mengaitkan ke implementasinya sendiri, Chrome harus menentukan perilaku yang harus dipenuhi oleh implementasi Server Sinyal Tepercaya, Server Agregasi, dan komponen non-browser lain yang diperlukan. Hal ini akan memungkinkan inovasi dalam batasan privasi yang dapat diterima.	Kami mengapresiasi dan menyambut baik keinginan untuk berinovasi dari pihak eksternal. Untuk semua API dan layanan, kami berupaya memberikan fleksibilitas kepada teknologi iklan untuk menerapkan fungsinya. Misalnya, kami mengizinkan teknologi iklan untuk menggunakan informasi bisnis rahasia dalam mendesain logika bidding untuk lelang. Selain itu, kami terus menerima masukan dari teknologi iklan dan, jika dibenarkan, memasukkannya ke dalam desain kami. Agar orang lain dapat menjalankan kode mereka sendiri di Lingkungan Eksekusi Tepercaya, Privacy Sandbox perlu meninjau kode (dan setiap perubahan) untuk memastikan bahwa kode tersebut memenuhi jaminan privasi. Tindakan ini akan memerlukan upaya signifikan dari tim Privacy Sandbox. Oleh karena itu, kami ingin memahami manfaat apa yang ingin dicapai oleh pemangku kepentingan, yang saat ini belum terpenuhi.
Heuristik	Apa saja rencana jangka panjang untuk heuristik?	Sesuai dengan hal yang ditunjukkan browser lain, kami pada akhirnya bermaksud untuk menghentikan heuristik ini karena solusi alternatif digunakan secara luas, dengan tunduk kepada analisis kelayakan lebih lanjut. Kami telah membagikannya di sini.
Menguji Volume	Volume traffic yang berbeda saat membandingkan dimensi yang berbeda.	1% eksperimen memiliki kriteria pengecualian yang menyebabkan perbedaan kelayakan untuk eksperimen, di antara populasi klien Chrome yang berbeda. Misalnya, eksperimen mengecualikan pengguna Chrome Enterprise, sehingga bagian traffic dengan label eksperimen diperkirakan akan lebih tinggi pada akhir pekan. Melihat persentase traffic yang berbeda di berbagai bagian data yang berbeda (seperti geografis, tanggal, dan platform) adalah hal yang wajar, dan ini sejalan dengan apa yang kami lihat dalam data Chrome.
Mengaktifkan Ulang 3PC secara Manual	Apakah situs dapat mengetahui jumlah pengguna (%) yang telah mengaktifkan kembali cookie secara manual setelah 3PCD diterapkan?	Pengguna akan dapat mengaktifkan kembali akses 3PC di tingkat situs melalui Pengabaian Pengguna jika mereka mengalami kerusakan. 3PC juga dapat diaktifkan kembali dengan tindakan lain seperti Storage Access API. Ada tindakan teknis, seperti hasStorageAccess(), yang memungkinkan situs mendeteksi apakah 3PC diaktifkan atau dinonaktifkan. Namun, Chrome tidak akan memfasilitasi cara bagi situs untuk mengetahui alasan pengaktifan kembali.
FItur Anti-Pelacakan	Berapa lama fitur UI Perlindungan Pelacakan Chrome akan tersedia?	UI Tracking Protection di kolom URL diperkirakan akan tetap ada setelah 3PC tidak digunakan lagi.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan Lintas Browser	Vendor browser lain yang mengadopsi Privacy Sandbox API.	Vendor browser lainnya, seperti Apple, Mozilla, dan Microsoft, merupakan peserta aktif dalam forum publik yang membahas prinsip-prinsip privasi dan pendekatan berbasis browser. Kami terdorong oleh diskusi kolaboratif di forum seperti pertemuan TPAC Tahunan W3C baru-baru ini dan forum PATCG W3C yang sedang berlangsung di mana kami melihat tanda-tanda konvergensi. Misalnya, Microsoft Edge baru-baru ini mengumumkan rencananya yang "bertujuan untuk memaksimalkan kompatibilitas sintaksis" dengan PA API dan ARA sekaligus menawarkan fitur tambahan bagi developer.
Opsi penggantian untuk sematan yang tidak kompatibel setelah 3PCD	Berikan hook API untuk mendeteksi apakah iframe / sematan pihak ketiga mematuhi 3PCD atau tidak.	Kami mendiskusikan permintaan tersebut di sini dan menerima masukan tambahan dari ekosistem.
Pengujian	Meminta tanda tambahan dalam instance Chrome terkelola yang menonaktifkan perilaku yang disesuaikan untuk sementara.	Kami mempertimbangkan permintaan ini untuk instance Chrome terkelola dan menerima input tambahan dari ekosistem jika tanda tersebut akan berguna.

Pendaftaran & Pengesahan

Tema Masukan	Ringkasan	Respons Chrome
Verifikasi Pengesahan	Bagaimana Google akan memastikan keaslian pengesahan?	Semua pendaftar harus menyimpan file pengesahan saat menggunakan API. Google memvalidasi bahwa file sudah ada dan sintaksisnya benar, tetapi Google tidak memvalidasi perilaku teknologi iklan sehubungan dengan bahasa pengesahan.
Proses Pendaftaran Private Aggregation API	Apakah ada cara untuk memeriksa status pendaftaran Private Aggregation API?	Semua pendaftar yang disetujui akan diberi tahu melalui email dari tim dukungan Pendaftaran setelah pendaftaran divalidasi. Jika pendaftar memiliki pertanyaan selama proses ini, mereka dapat menghubungi tim dukungan (yang terhubung dengan mereka setelah mengirimkan formulir pendaftaran). Tim dukungan akan menanggapi dan menjawab pertanyaan serta memberikan panduan tambahan yang diperlukan.

Tampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Linimasa dan Dokumentasi Pengklasifikasi	Harus ada beberapa bentuk mekanisme agar klasifikasi ditinjau atau setidaknya transparansi tambahan tentang bagaimana mode klasifikasi menentukan kategori.	Respons kami tidak berubah dari kuartal sebelumnya: "Kesalahan klasifikasi situs dapat membuat sinyal Topics menjadi sedikit kurang berguna sebagai sinyal secara keseluruhan, tetapi situs tertentu yang salah diklasifikasikan tidak lebih dan tidak kurang dirugikan oleh situs ini dibandingkan situs lainnya. Hal ini karena informasi kontekstual situs akan selalu tersedia untuk lelang di situs mereka, yang akan memberikan informasi yang sebanding dengan topik yang tepat, meskipun terjadi kesalahan klasifikasi. Kami menantikan masukan terkait topik ini di sini."
Google Ad Manager	Google Ad Manager sudah disematkan di sebagian besar situs dan akan memiliki informasi yang lebih luas tentang topik pengguna dibandingkan dengan pesaing yang muncul di situs yang lebih sedikit.	Persyaratan pengamatan ada untuk memastikan Topics API tidak mengakibatkan data pengguna dibagikan ke lebih banyak entitas daripada teknologi yang diganti oleh API (termasuk 3PC). Solusi industri lainnya seperti Prebid berfungsi dengan 10.000 situs dan memungkinkan peserta pasar memanggil Topics API melalui teknologi mereka. Lebih lanjut, perlu dicatat bahwa batas hingga 5 topik teratas per minggu mungkin memiliki efek penyetaraan, karena peserta pasar yang hadir di banyak situs yang mungkin dapat mempelajari lebih dari 5 topik yang setara menggunakan 3PC akan dibatasi hingga 5.
(Juga dilaporkan pada kuartal sebelumnya) Manfaat untuk berbagai jenis pemangku kepentingan	Kekhawatiran tentang nilai yang dibuat dan distribusi nilai tersebut untuk situs bergantung pada tingkat traffic atau seberapa khusus konten mereka.	Kami mengakui bahwa situs yang spesifik lebih cenderung mengkontribusikan topik yang lebih terperinci daripada domain minat umum. Namun, tidak semua situs khusus menyumbangkan topik yang berharga secara komersial. Selain itu, dinamika ini mencerminkan status quo dan sepenuhnya tidak bergantung pada akhir dukungan untuk 3PC di Chrome. Dalam kondisi saat ini, beberapa situs juga memberikan nilai lebih dibandingkan situs lainnya dalam sistem relevansi iklan berbasis 3PC. Selain itu, topik di antara situs khusus dapat saling menguntungkan karena pengiklan yang beragam dapat menjalankan kampanye di beragam kumpulan topik dan logika bidding dapat mengamati nilai di berbagai topik.
Nama Host vs URL Lengkap	Apakah klasifikasi berdasarkan nama host situs cukup efektif dan apakah hal ini mengurangi risiko privasi jika dibandingkan dengan URL lengkap?	Kami mempertimbangkan untuk menggunakan URL informasi atau judul halaman selain nama host, dan menyimpulkan bahwa potensi manfaatnya akan lebih penting dibandingkan risiko pada privasi dan keamanan pengguna. Contoh risiko privasi pengguna mencakup klasifikasi informasi sensitif yang disertakan dalam URL atau judul halaman ke dalam topik pengguna.
Topik sebagai Sinyal	Minta panduan tentang cara menggabungkan Topics dengan sinyal lain, dan sinyal lain yang mungkin berguna.	Solusi teknologi iklan dapat memberikan hasil terbaik dengan menggabungkan semua alat yang tersedia, seperti machine learning dan sinyal yang menjaga privasi dari API yang menjaga privasi, bersama dengan data kontekstual, data materi iklan, dan data pihak pertama. Panduan lebih lanjut tentang hal ini tersedia di sini.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan	Ringkasan	Respons Chrome
Menguji Volume Traffic	Penguji melaporkan volume respons bid yang rendah untuk lelang API PA.	1. Kepadatan bid berhubungan dengan partisipasi ekosistem di PA API, yang kami perkirakan akan terus meningkat sepanjang tahun 2024 dan seterusnya. Pada akhirnya, terserah pengiklan, agensi, dan penyedia teknologi mereka untuk menentukan cara mengalokasikan anggaran kampanye. Kami memperkirakan beberapa peserta ekosistem dapat menunda investasi mereka dalam berbagai solusi "tanpa cookie", termasuk PA API hingga setelah 3PCD. Saat itu, kami berharap dapat meningkatkan alokasi anggaran kampanye untuk solusi tersebut. 2. Volume permintaan bid di lelang PA API dapat dipengaruhi oleh (1) karena penayang dan penyedia teknologi iklan mereka dapat memutuskan untuk tidak memulai lelang API PA jika mereka merasa permintaannya rendah. Penayang dapat menentukan prioritas untuk memperbarui halaman dan berpartisipasi. Kami memperkirakan penayang akan memerlukan waktu untuk menguji dan meningkatkan traffic secara bertahap karena alasan ini. Laporan ini juga berisi respons dari Google Ad Manager terkait kontrol penayangnya untuk partisipasi PA API.
(Juga dilaporkan pada kuartal sebelumnya) Penipuan / Penyalahgunaan	Bagaimana ekosistem dapat mengurangi risiko dan mencegah pihak tidak bertanggung jawab atau pembeli memosisikan diri sebagai audiens yang diinginkan?	Mekanisme pelaporan iklan PA API menyimpan informasi yang digunakan untuk membedakan traffic manusia dari traffic bot. Selain itu, teknik berbasis domain saat ini yang menyertakan atau mengecualikan domain dapat digunakan di PA API. Hal ini dijelaskan secara lebih mendetail dalam respons kami terhadap laporan IAB Tech Lab tentang Privacy Sandbox.
Pembatasan Asal yang sama di pemilik IG dan URL logika bidding	Dengan persyaratan origin yang sama, endpoint untuk pemilik IG akan dipaksa untuk melalui load balancer yang sama, yang dapat menyebabkan pengalihan ditolak.	Persyaratan origin yang sama untuk pemuatan skrip merupakan perlindungan keamanan yang penting. Terdapat beberapa detail tentang solusi yang diusulkan di sini yang menyeimbangkan masukan ekosistem dan pertimbangan lainnya di sini.
Lelang Pribadi Multi-Slot	Ada banyak ruang untuk mengizinkan Lelang Pribadi Multi-Slot dalam batas privasi menggunakan derau dan integrasi yang lebih ketat dengan praktik iklan saat ini.	Kami mempertimbangkan masukan ini dan mengevaluasi permintaan untuk lelang multitag terhadap peningkatan risiko kompleksitas dan privasi yang terkait dengan fitur ini. Kita telah membahas masalah ini lebih lanjut selama panggilan PA API Web Incubator Community Group (WICG) di sini.
Penjual Tingkat Atas	Struktur PA API saat ini memberikan data dan pemahaman yang jauh lebih banyak kepada penjual tingkat atas tentang nilai tayangan relatif dibandingkan penayang atau penjual komponen.	Dalam lelang multi-penjual, setiap penjual akan memiliki bid terbaik. Selain itu, kami telah mempelajari dari ekosistem bahwa penayang mungkin ingin mempertimbangkan permintaan yang dijual langsung di samping bid terbaik dari setiap penjual yang bekerja sama dengan mereka. Melihat semua potensi peluang monetisasi ini diperlukan untuk menentukan iklan mana yang akan ditayangkan. Situasi ini ketika beberapa aktor perlu melihat kumpulan opsi lengkap untuk memilih iklan untuk ditayangkan, sebelum PA API. PA API berupaya mendukung lelang multi-penjual dan keinginan penayang untuk mempertimbangkan bid terbaik dari setiap penjual di samping kampanye iklan yang dijual langsung, yang berlaku jika kedua hal tersebut berlaku. Artinya, perlu ada mekanisme untuk memilih di antara peluang monetisasi tersebut seperti yang ada saat ini. Kami merasa tidak seharusnya memilih iklan mana yang akan ditayangkan oleh browser. Oleh karena itu, konsep penjual tingkat atas diperlukan untuk memilih iklan pemenang dari berbagai kemungkinan. Logika penjual tingkat teratas tersebut harus dapat mempertimbangkan bid terbaik dari setiap penjual yang bekerja sama dengan penayang. Logika penjual tersebut juga dapat memilih untuk memberikan informasi tentang kampanye penayang yang dijual langsung tempat informasi tersebut tersedia. Semua informasi ini dapat dipertimbangkan dalam logika pemilihan iklan tingkat atas. Artinya, logika tingkat teratas melihat bid terbaik dari lelang PA API dan, jika berlaku, setiap opsi iklan yang dijual langsung dari penayang untuk menentukan pemenang. Google Ad Manager menjelaskan penerapan PA API sebagai penjual tingkat teratas dalam laporan ini dengan tema "Akses ke Informasi".
Pemisahan Iklan Kompetitif	Meminta pemisahan iklan kompetitif, seperti mencegah iklan dari merek pesaing agar tidak muncul berdampingan.	Kami tidak mengetahui cara untuk memastikan pemisahan kompetitif dalam ekosistem periklanan digital yang terprogram, di-bid, dan multi-penjual saat ini. Namun, PA API memungkinkan penjual mengambil sinyal real-time tambahan berdasarkan kombinasi renderURL dan nama host (mewakili domain penayang) yang dapat digunakan selama scoreAd() saat menilai materi iklan. Hal ini dapat digunakan oleh penjual untuk mencegah iklan dari merek yang bersaing muncul berdampingan satu sama lain, dengan asumsi bahwa penayang ingin menerapkan aturan ini.
Informasi Terbatas	PA API mengurangi informasi yang tersedia bagi penayang, seperti nilai iklan, nama pembeli komponen, nama pengiklan, URL halaman landing, ukuran materi iklan, waktu respons, rasio bid, serta bid yang kalah.	Kami telah mengusulkan beberapa solusi potensial di sini dan menerima masukan tambahan dari ekosistem.
Pelaporan tingkat peristiwa	Penayang tidak bisa mendapatkan informasi yang cukup tentang iklan yang ditayangkan setelah penghentian PA API pelaporan tingkat peristiwa.	Kami menyadari berbagai kasus penggunaan pelaporan yang harus terus kami dukung saat pelaporan tingkat peristiwa dihentikan. Oleh karena itu, kami telah menargetkan penghentian pelaporan tingkat peristiwa paling cepat tahun 2026. Selama waktu tersebut, kami mengundang partisipasi aktif seiring kami berinteraksi dengan ekosistem untuk melalui jalur yang andal dan dapat mencakup ide-ide baru untuk memperoleh informasi dengan cara yang menjaga privasi.
Beberapa SSP	Nilai tambah jika memiliki beberapa SSP akan terlalu rendah bagi penayang.	Kami tidak yakin bahwa ini benar dan kami akan menerima masukan tambahan dari ekosistem untuk memahami alasan pernyataan ini.
Aktivitas Seleksi	Aktivitas seleksi tidak dapat dilakukan dengan PA API.	Kami telah menerima masukan terkait kemampuan penjual untuk menggunakan PA API guna menyediakan informasi audiens mereka kepada pembeli di seluruh web (alias ekstensi audiens). Kami yakin hal itu memungkinkan saat ini, dengan menggunakan fungsi delegasi PA bersama dengan perjanjian bisnis. Secara bersamaan, kami secara aktif mempertimbangkan apakah dan bagaimana kami dapat mengakomodasi jenis kasus penggunaan ini dengan lebih baik.
Ketidakikutsertaan Pembeli	Ketidakikutsertaan pembeli secara default kemungkinan akan menyebabkan hasil yang lebih rendah untuk lelang komponen.	Baik menentukan lelang PA penjual tunggal atau multi-penjual, penjual harus mencantumkan pembeli secara eksplisit di kolom interestGroupBuyers di AuctionConfig. Hal ini didasarkan pada masukan ekosistem bahwa penjual memiliki perjanjian kontrak dengan beberapa pembeli dan bukan yang lain, sehingga akan memerlukan kontrol eksplisit atas pembeli mana yang akan disertakan dalam lelang. Kami menyambut baik diskusi lebih lanjut di GitHub.
Ukuran iklan	Tidak dapat melakukan pra-filter berdasarkan ukuran iklan dan adSlotSize.	Kami sedang berupaya menambahkan kemampuan ini, dan detail lebih lanjut tersedia di sini.
Dukungan untuk penargetan IG negatif	API untuk mendukung penargetan IG negatif: menampilkan iklan hanya jika pengguna bukan anggota IG.	Masalah GitHub ini mengusulkan cara alternatif untuk menerapkan penargetan negatif, yang mana browser secara langsung memberi tahu server iklan aturan penargetan negatif mana yang harus berlaku untuk permintaan iklan tertentu. Meskipun ini tampak seperti pendekatan yang menarik, semua versi dari ide yang telah kami selidiki ternyata memungkinkan server untuk mengidentifikasi pengguna secara unik.
Digital Services Act	Bagaimana cara penerbit menggunakan Fenced Frames, tetapi juga mencegah respons yang berisi informasi yang tunduk pada Digital Services Act agar tidak dirender?	Seperti teknologi baru lainnya, setiap perusahaan bertanggung jawab untuk memastikan bahwa penggunaan Privacy Sandbox mematuhi hukum; Google tidak dapat memberikan saran hukum kepada pihak lain. Untuk setiap API, kami telah memublikasikan dokumentasi teknis lengkap, yang akan menjadi dasar untuk melakukan penilaian hukum yang diperlukan. Frame dengan Fence tidak diwajibkan untuk digunakan di PA API mulai tahun 2026, sehingga memberikan waktu tambahan bagi pemangku kepentingan untuk memastikan bahwa penggunaan teknologi ini mereka mematuhi semua legislasi yang relevan.
Dokumentasi	Apakah updateAdInterestGroups() sementara?	Kami belum mengumumkan rencana untuk menghentikan penggunaan updateAdInterestGroup. Di masa mendatang, kami mungkin menerapkan perlindungan privasi serupa seperti yang telah dibicarakan secara publik untuk mekanisme update IG lainnya, misalnya menggunakan alamat IP serta proxy dan menambahkan beberapa penundaan sebelum update terjadi.
Dukungan kepemilikan logika dan metadata sisi beli untuk non DSP	Meminta cara untuk bertindak sebagai proxy DSP.	Kami mengetahui masukan ini dari segmen non-DSP dan sedang mempertimbangkan permintaan ini. Kami menantikan masukan tambahan dari ekosistem ini.
Pelaporan	Meminta penambahan fitur pengendali kustom untuk bucket / nilai sinyal dalam pelaporan Agregasi Pribadi.	Kami telah mengetahui dan permintaan fitur ini sedang berada dalam antrean kami untuk penemuan lebih lanjut. Kami menantikan masukan tambahan dari ekosistem di sini.
Dokumentasi	Apakah ada link yang memungkinkan untuk melihat semua header respons yang perlu ditetapkan oleh pengiklan dan domain pemilik (yang didelegasikan)?	Kami merencanakan pembaruan dokumentasi untuk mengklarifikasi hal ini dan menerima masukan tambahan dari ekosistem.
Bidding Multi-Menara	Minta penjelasan tentang alur kerja (pelatihan dan inferensi) melalui diagram arsitektur / blok tentang bagaimana pendekatan multi-menara dibayangkan dalam konteks PA API.	Terima kasih atas masukannya. Kami memiliki beberapa presentasi tentang topik tersebut yang akan kami buat dokumentasi tambahannya.
Penargetan Negatif	Kemampuan Privacy Sandbox untuk melindungi audiens sensitif dan anak di bawah umur dari iklan yang tidak pantas, misalnya perjudian.	PA API tidak mempertimbangkan konten iklan yang ditampilkan. Hal ini dikontrol oleh developer teknologi iklan yang menggunakan PA. Secara umum, penayang dan penyedia teknologi iklan mereka dapat memblokir materi iklan dalam lelang Protected Audience menggunakan informasi kontekstual dari halaman serta kumpulan aturan penayang. Hal ini mencerminkan pemahaman kami tentang pendekatan ekosistem terhadap tantangan tersebut saat ini. Untuk pembeli, fungsi penargetan IG negatif juga mungkin berguna untuk beberapa kasus penggunaan kepatuhan.
Desain API	Google menolak dan ingin teknologi iklan menggunakan fungsi bidding Universal sehingga meningkatkan latensi, bukan biddingLogicURL berbeda di IG berbeda yang diizinkan.	Selama diskusi kita tentang latensi lelang, kami telah menyoroti bahwa menggunakan kembali skrip yang sama di semua IG pembeli akan membuat bidding pembeli berjalan lebih cepat. Hal ini diuraikan lebih lanjut di sini, bersama dengan rekomendasi kami yang lain untuk meningkatkan latensi lelang PA API.
Pemasaran Berbasis Akun	PA API bukanlah API sederhana untuk kasus penggunaan pemasaran berbasis akun.	Kami menyambut baik masukan dari ekosistem terkait kasus penggunaan tertentu yang mereka yakini tidak mungkin dan akan mendorong peserta ekosistem untuk melanjutkan diskusi ini melalui repositori GitHub publik atau panggilan mingguan kami.
Pengujian A/B	Jika PA API dikonfigurasi di GAM untuk penayang, saat ini API tersebut harus diaktifkan untuk semua inventaris atau tidak sama sekali. Hal ini membatasi kemampuan penayang untuk menjalankan pengujian A/B yang layak.	Respons yang diberikan Google Ad Manager: Kontrol PA API dalam Google Ad Manager (GAM) memengaruhi kemampuan GAM untuk menggunakan API, asalkan API tersebut tersedia untuk digunakan. Oleh karena itu, penayang dapat menjalankan pengujian A/B dengan menggunakan fungsi kebijakan izin Chrome untuk menonaktifkan penggunaan API pada sebagian traffic untuk digunakan sebagai grup kontrol untuk pengujian A/B.
Machine Learning	Penayang memerlukan kontrol lebih besar atas penggunaan machine learning oleh GAM.	Respons yang diberikan Google Ad Manager: Pada Januari 2024, kami meluncurkan kontrol yang menawarkan kepada penayang kemampuan untuk menonaktifkan pembatasan machine learning kami, dan mengaktifkan lelang API PA dengan penjual non-Google di semua traffic mereka. Detail selengkapnya tentang kontrol ini dapat ditemukan di pusat bantuan kami.
(Juga dilaporkan pada kuartal sebelumnya) Lelang tingkat teratas	Kemampuan untuk menggunakan server iklan penayang Google tanpa memberikan kontrol atas lelang PA API tingkat teratas kepada GAM.	Respons yang diberikan Google Ad Manager: Karena alasan yang dijelaskan dalam laporan Kuartal 3 2023 Google, rencana GAM untuk integrasi PA API-nya tidak menyertakan dukungan penayang yang menggunakan GAM sebagai server iklan penayang mereka tanpa kontrol lelang tingkat atas.
Akses ke Informasi	GAM memiliki akses ke informasi berharga dari para pesaing, termasuk harga lelang kontekstual, sinyal yang diberikan oleh pembeli ke SSP untuk lelang PA API, dan parameter konfigurasi dari SSP.	Respons yang diberikan oleh Google Ad Manager: Kami telah terus berfokus pada keadilan lelang selama bertahun-tahun, termasuk janji kami bahwa tidak ada harga dari sumber iklan apa pun yang tidak dijamin milik 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 ingin memenuhi janji kami dan tidak membagikan bid dari peserta lelang mana pun kepada peserta lelang lainnya sebelum lelang selesai di lelang multi-penjual. Untuk lebih jelasnya, kami tidak akan membagikan harga lelang kontekstual ke lelang komponen apa pun, termasuk milik 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. Bahkan, kami akan menerima perubahan pada PA API yang memungkinkan penjual komponen menentukan konfigurasi lelang komponen mereka dengan cara yang di-obfuscate dari penjual tingkat teratas.
Lelang Komponen	Sebagai lelang tingkat teratas, GAM akan mengontrol SSP mana yang menjalankan lelang komponen untuk setiap peluang iklan.	Respons yang diberikan oleh Google Ad Manager: Sebagai server iklan penayang, GAM menawarkan API ringan untuk SSP yang mungkin digunakan penayang untuk menentukan konfigurasi lelang komponen mereka melalui Google Publisher Tag (GPT) API. Detail selengkapnya dapat ditemukan di sini. Jika SSP menyediakan konfigurasi lelang komponen melalui API ini, SSP akan disertakan dalam daftar lelang komponen untuk peluang iklan tersebut. GAM tidak menerapkan batasan apa pun pada lelang komponen yang disertakan. Semua SSP yang ingin menjalankan lelang komponen akan dapat melakukannya, asalkan penayang telah mengizinkan mereka untuk mengeksekusi kode yang diperlukan di halaman penayang.
Lelang Komponen	GAM dapat menerapkan nilai minimum spesifik dan tidak diungkapkan untuk setiap bid pemenang lelang komponen.	Respons yang diberikan oleh Google Ad Manager: GAM telah mempertahankan fokus yang kuat pada keadilan lelang selama bertahun-tahun. Sebagai bagian dari mempertahankan lelang yang adil dan transparan, kami tidak mendukung harga minimum yang hanya berlaku untuk segmen permintaan tertentu. Itu adalah prinsip yang konsisten dalam produk kami dan akan terus berlaku untuk lelang API PA.
Server Iklan Pihak Ketiga	Server iklan pihak ketiga tidak akan memiliki akses ke partisipasi Google dalam lelang tingkat yang lebih tinggi, sehingga membatasi kemampuannya untuk mendapatkan manfaat dari permintaan Google SSP dalam konteks PA API.	Respons yang diberikan oleh Google Ad Manager: Saat ini, GAM mendukung pengujian PA API dengan beberapa penjual di GAM melalui API yang dijelaskan di sini. Partisipasi GAM sebagai lelang komponen di lelang tingkat teratas lainnya saat ini tidak didukung.
(Juga dilaporkan pada kuartal sebelumnya) Performa Lelang API PA	Melaporkan dari penguji bahwa lelang PA API memiliki latensi tinggi.	Kami telah mendengar kekhawatiran tentang latensi dan ini merupakan bagian dari alasan kami mengembangkan sejumlah fitur sebagai bagian dari PA API yang memungkinkan SSP menetapkan batas latensi DSP serta melakukan peningkatan yang dapat mengurangi latensi. Baru-baru ini kami memperbarui panduan praktik terbaik latensi yang mencakup informasi lebih lanjut tentang cara memanfaatkan fitur-fitur ini. Kami juga terus mengembangkan peningkatan latensi baru, beberapa di antaranya dapat dilihat di sini.
(Juga dilaporkan pada kuartal sebelumnya) Rendering Video	Dukungan untuk rendering video menggunakan PA API dan Fenced Frames.	Pada bulan Januari, kami memublikasikan demo tentang kemungkinan cara kerja video in-stream dalam lelang PA, dengan detail tambahan tentang pendekatan alternatif. Kami juga melihat para pemain ekosistem mulai mengusulkan cara kerja rendering video untuk partner yang terintegrasi dengan mereka, seperti proposal GAM tentang konstruksi renderURL yang kompatibel dengan video atau proses E2E lengkap. Selain itu, kami mendengarkan masukan ekosistem tentang perubahan yang dapat kami lakukan untuk meningkatkan adopsi, dan satu perubahan tersebut diuraikan di GitHub. Kami tetap aktif terlibat dengan ekosistem untuk mengidentifikasi hambatan lain dalam penerapan yang mungkin kami hadapi dan mengatasinya secara tepat waktu.
(Juga dilaporkan pada kuartal sebelumnya) Kebijakan Penanganan Data	Bagaimana kebijakan penanganan data untuk IG / PA API?	Dalam desain PA API, semua data yang disimpan di IG, atau tentang orang-orang yang ada di IG, baik (i) tetap berada di perangkat atau (ii) diproses di Layanan Bidding dan Lelang (B&A) yang berjalan di dalam Trusted Execution Environment (TEE). Dalam kedua kasus tersebut, data tidak dapat dibaca oleh pihak lain, atau digunakan dengan cara apa pun selain untuk menghasilkan bid di lelang. Beberapa peningkatan privasi yang sedang dijelajahi Chrome melibatkan interaksi dengan server k-anonymity yang dijalankan Google. Interaksi tersebut dirancang dengan cermat untuk menghindari pembagian informasi tentang pengguna, dan dijalankan secara TEE untuk memastikan kesetaraan informasi di seluruh ekosistem iklan. Google telah berkomitmen kepada CMA untuk mendesain dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan mementingkan sendiri bisnis Google sendiri, serta mempertimbangkan dampak pada persaingan dalam periklanan digital serta penayang dan pengiklan. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi kewajiban ini.
(Juga dilaporkan pada kuartal sebelumnya) Masa aktif IG	Permintaan untuk memperpanjang masa aktif IG dari 30 menjadi 90 hari.	Perubahan tersebut memerlukan evaluasi yang cermat, yang mempertimbangkan manfaat industri terhadap industri tersebut dibandingkan dengan dampaknya terhadap pengguna Chrome dan pemangku kepentingan lainnya. Kami mempertimbangkan permintaan ini dan menerima masukan tambahan di sini.
(Juga dilaporkan pada kuartal sebelumnya) modelingSignals	Minta kolom baru selain pemodelanSignals yang hanya dapat mengenkode informasi tampilan dan klik.	Kami telah merespons masukan ini dengan proposal tanggapan di sini. Kami secara aktif terlibat dengan industri untuk memahami pandangan mereka terhadap proposal kami, dan saat ini mempertimbangkan manfaatnya bagi industri terhadap dampak pada pengguna Chrome dan pemangku kepentingan lainnya.
Bit tambahan dalam reportWin()	Menyediakan bit tambahan dalam reportWin() dari batas saat ini sebesar 12 sebelum 3PCD.	Saat ini kami sedang mempelajari beberapa pendekatan untuk mendukung kasus penggunaan ini. Hal ini memerlukan waktu karena kami juga mencari pendekatan yang dapat membantu memastikan bahwa kami memiliki rencana privasi jangka panjang.
Desain Lelang	Permintaan untuk satu lelang yang menampilkan URL render dengan skor yang sesuai.	Membagikan beberapa renderURL, dan skor masing-masing, dari satu lelang PA adalah sesuatu yang kami pertimbangkan, tetapi tidak kami terapkan karena masalah privasi. Kami memahami keinginan untuk tidak menampilkan iklan yang sama beberapa kali kepada pengguna di satu halaman dan menyambut diskusi lebih lanjut di GitHub.
reportWin	kolom arbitrer dalam fungsi reportWin().	Hal ini sudah terjadi selama periode pengujian. Setelah Chrome mengakhiri dukungan untuk 3PC, versi API forDebuggingOnly akan dimigrasikan untuk mengaktifkan proses debug dengan pengurangan sampel, yang ditentukan di sini.
Penjual Komponen	Memiliki mekanisme independen untuk menghitung tayangannya sendiri dan peristiwa lainnya dan tidak harus hanya dapat bergantung pada laporan teknologi iklan.	Permintaan fitur ini sedang dalam antrean kami untuk penemuan lebih lanjut. Kami tidak memperkirakan masalah ini akan ditangani selama periode pengujian yang difasilitasi Chrome.
Penagihan Biaya per klik	Terapkan penagihan biaya per klik di PA API.	Kami sedang mempertimbangkan permintaan ini di sini, dan saat ini kami melihatnya sebagai permintaan saran tentang cara menerapkannya dengan platform API saat ini.
browserSignals	Menambahkan masukBidInSellerCurrency ke pelaporan spesifikasi browserSignals untuk penjual.	Kami mempertimbangkan permintaan ini dan menerima masukan tambahan di sini.
Dukungan kepemilikan logika dan metadata sisi beli untuk non DSP	Desain API saat ini dapat menyebabkan perubahan yang signifikan dalam kampanye penargetan ulang tingkat produk karena kampanye mungkin perlu dimigrasikan ke platform yang berfungsi sebagai penyedia DSP dan DCO.	Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Dukungan kepemilikan logika dan metadata sisi beli untuk non DSP	Berikan contoh jika DSP bukan pemilik IG.	Kami memahami bahwa non-bidder ingin menggunakan beberapa fungsi IG, tetapi tidak yang lainnya. Kami secara aktif mengevaluasi berbagai opsi untuk menangani kasus penggunaan tersebut dan menerima masukan tambahan di sini.
Kontrol Waktu Tunggu	Penayang harus dapat menentukan jumlah IG yang dapat berpartisipasi dan waktu tunggu tingkat atas / waktu tunggu global.	Kami memahami adanya keinginan untuk meningkatkan kontrol waktu tunggu dan visibilitas antara penjual tingkat teratas dan komponen dan kami sedang mempertimbangkan permintaan ini.
Ukuran Multi-Iklan	Dukungan PA API untuk kasus penggunaan Multi Ukuran.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Dokumentasi	Apakah ada daftar atribut IG yang tunduk pada k-anon?	Kami telah menjawab pertanyaan ini di sini.
Proses debug	Peningkatan kemampuan proses debug untuk PA API.	Kami menyadari pentingnya alat proses debug yang andal bagi developer yang bekerja dengan PA API. Kami berkomitmen untuk meningkatkan pengalaman developer dengan mencari cara untuk mengintegrasikan pengambilan file .well-known secara lebih baik dengan alat developer. Tujuan kami adalah memberikan kemampuan pemecahan masalah dan visibilitas yang lebih baik di lingkungan pengembangan. Kami mendiskusikan masalah ini lebih lanjut di sini dan menerima masukan tambahan.
Label	Apakah semua pengguna dalam label perlakuan mode B telah mengaktifkan API Privacy Sandbox?	Penetapan grup eksperimen Chrome ditentukan secara acak dan tidak bergantung pada setelan Chrome yang dikonfigurasi pengguna. Meskipun API ini mungkin tersedia bagi pengguna dalam grup perlakuan tertentu (misalnya perlakuan_1.*), fungsinya dapat diubah atau dinonaktifkan melalui setelan Chrome. Grup control_2 Mode B: Penyertaan dalam grup ini secara inheren menonaktifkan API pengukuran dan relevansi di Privacy Sandbox, dan setelan ini tidak dapat diganti oleh pengguna dalam setelan Chrome.
Penggunaan API	Apakah panggilan ke reportWin() dan rendering iklan terjadi secara paralel atau berurutan?	reportWin() dipanggil langsung setelah penyelesaian runAdLelang(). Pada saat yang sama, proses rendering iklan dapat dimulai saat hasil lelang ditempatkan dalam iframe atau Fenced Frame. Setelah reportWin() menyelesaikan eksekusi dan iklan mulai dirender, URL yang diberikan ke sendReportTo() akan diambil.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan A/B Testing	Minta dukungan untuk pengujian A/B PA API.	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan.
Pembentukan Lalu Lintas	Proposal dari Google untuk mengelola pengambilan keputusan yang diperlukan melalui server KV tidak membantu, karena penjual tidak dapat berinteraksi dengan backend mereka, sehingga pembentukan traffic menjadi sulit.	Seperti yang telah dibahas dalam masalah GitHub, mengungkap apakah suatu DSP tertentu memiliki IG dapat menimbulkan masalah pelacakan sidik jari pengguna. Kami telah menyarankan alternatif lain dalam masalah ini dan menerima saran lebih lanjut.
Pembentukan Lalu Lintas	Mekanisme penyimpanan dalam cache menambahkan lapisan kerumitan yang signifikan dan mencegah DSP mengetahui bentuk traffic sebenarnya yang akan mereka ajukan bid-nya.	Mekanisme penyimpanan dalam cache hanya ditawarkan sebagai saran. Teknologi Iklan dapat memilih untuk menggunakan saran yang sesuai dengan kasus penggunaan mereka dan kami menyambut baik diskusi tambahan di sini.
Label	Chrome harus membagikan label sebagai parameter dalam permintaan ke server tepercaya pembeli dan penjual.	Hal ini tampaknya merupakan permintaan yang wajar karena tampaknya secara luas selaras dengan tujuan penggunaan data IG yang bertanggung jawab. Namun, kami sedang mempertimbangkan permintaan tersebut, yang tunduk pada peninjauan internal, dan akan memberikan pembaruan publik mengenai masalah ini seiring kemajuan diskusi.
Penggunaan API	Mengklarifikasi definisi eksplisit grup "control_1" dalam dokumen "Panduan CMA tambahan untuk pihak ketiga yang terkait pengujian". Secara khusus, ada kekhawatiran bahwa perubahan susunan kata mungkin disalahartikan sebagai mewajibkan pengecualian semua API Privacy Sandbox dari control_1.	Kami telah menyampaikan pandangan kami tentang hal ini di thread GitHub ini. Meskipun demikian, kami tidak berwenang untuk berbicara untuk CMA dan sebaiknya sampaikan masalah apa pun terkait interpretasi panduan pengujian mereka secara langsung dengan CMA.
Penggunaan API	Apakah Chrome akan mengizinkan pemanggilan joinAdInterestGroup() pada halaman kosong saat mengalihkan ke resource lain?	Jika pengguna mengunjungi situs tertentu, pemilik situs dapat mendelegasikan kemampuan untuk memanggil joinAdInterestGroup ke pihak ketiga. Delegasi ini memungkinkan pihak ketiga membuat IG tanpa perlu menambahkan jenis pengalihan apa pun melalui halaman kosong. Kami menerima masukan terkait alasan tertentu untuk membuat IG di tengah pengalihan, bukan menggunakan mekanisme delegasi yang dimaksudkan.
Penggunaan API	Bursa harus dapat menulis IG ke halaman milik penayang yang bekerja sama dengan mereka dan mereka kemudian dapat mendelegasikan izin untuk mengajukan bid pada IG tersebut kepada pembeli atau DSP tertentu.	Kami telah menerima masukan tersebut dan sedang mengevaluasi apakah permintaan tersebut dapat didukung atau tidak. Kami menantikan masukan tambahan dari ekosistem ini.
Penggunaan API	Tidak ada notifikasi kekalahan proses debug jika tidak ada yang memenangkan lelang PA API.	Fungsi reportWin dan reportResult Chrome dirancang untuk pelaporan kemenangan tingkat peristiwa dalam sistem Lelang Privasi (PA). Jika semua bid ditolak selama lelang PA, fungsi ini tidak diharapkan akan dipanggil karena tidak ada pemenang yang ditentukan. Update Chrome terbaru mungkin menjelaskan perbedaan apabila URL yang diteruskan ke forDebuggingOnly.reportAdAuctionLoss() tidak muncul di panel Jaringan DevTools. Sebaiknya verifikasi fungsi ini menggunakan build Chrome Canary atau Saluran Dev.
Penggunaan API	Dapatkah adCost yang ditampilkan dari generateBid menjadi negatif (sudah dibulatkan secara stokastik menjadi 2 byte)?	AdCost adalah biaya klik atau konversi pengiklan yang diteruskan dari generateBid() ke reportWin(). Nilai ini bisa berupa Null atau ganda. Nilai negatif akan diabaikan dan tidak akan diteruskan. Nilai akan dibulatkan secara stokastik saat diteruskan.
Peningkatan API	Dapatkah server Eksekusi Tepercaya dan Terenkripsi digunakan untuk menangani penargetan / kohor / atribusi dan lelang, bukan browser Chrome?	Sebaiknya pelajari komponen dan opsi berbasis TEE di PA API (mis. server KV dan Layanan B&A) serta komponen berbasis TEE dari Attribution Reporting dan Agregasi Pribadi (mis. Layanan Agregasi) yang menjawab pertanyaan ini.
Peningkatan API	Apakah respons lelang Privacy Sandbox dapat menjadi respons bid (seperti bidding header) dan bukan respons iklan (seperti tag iklan)?	Perubahan jenis ini pada dasarnya mengubah properti privasi PA API, jadi kami tidak mempertimbangkannya.
Kontrol Penayang	Dapatkah penayang memblokir materi iklan API PA di halaman mereka?	Chrome memiliki proposal untuk pemindaian materi iklan real-time yang belum tersedia untuk pengujian. Meskipun belum tersedia, kami mengamati sebagian besar SSP telah membuat solusi untuk mengaktifkannya.
Penggunaan API	Berapa batas ukuran di perBuyerSignals?	Dalam bentuk klasiknya, perBuyerSignals tidak memiliki batasan ukuran yang melekat di Chrome. Batasan utamanya adalah data tetap dapat diserialisasi JSON dan tidak menyebabkan konsumsi memori yang berlebihan. Namun, perlu diperhatikan bahwa perBuyerSignals yang sangat besar dan kompleks dapat berdampak negatif pada performa. Ada metode alternatif untuk meneruskan perBuyerSignals melalui directFromSellerSignalsHeaderAdSlot. Pendekatan ini mengirimkan perBuyerSignals dalam header, sesuai dengan batas ukuran maksimum 10 kb untuk seluruh respons header. Selain itu, server individual dapat memberlakukan pembatasannya sendiri pada ukuran header maksimum.
Dokumentasi	Dokumentasi tentang panggilan registerAdBeacon dari dalam generateBid perlu diubah.	Kami memperbarui dokumentasi ini pada 17 Februari.
Penggunaan API	Bagaimana cara reportEvent memilih URL beacon yang tepat dari beberapa opsi terdaftar?	Setiap lelang menghasilkan konfigurasi terpisah, yang nantinya menghasilkan peta pelaporan terpisah. Masing-masing lelang (dan frame yang dihasilkannya) benar-benar terpisah satu sama lain, dan tidak membagikan data. Penjelasan "Pelaporan Iklan Frame dengan Fence" memberikan detail selengkapnya tentang topik ini.
UI Chrome	Tambahkan filter di tab "Application -> "Interest groups" di Chrome DevTools, yang memungkinkan untuk memfilter berdasarkan pemilik IG (atau mungkin juga berdasarkan nama IG).	Kami mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem.
Chrome Headless	Dukungan PA API di Chrome Headless.	Ada beberapa komponen PA API yang terkait dengan Chrome, misalnya panggilan k-anon ke server Google, yang mungkin tidak berfungsi di Chrome Headless "lama". Kami yakin masalah ini dapat diatasi dengan Chrome Headless versi "baru" yang dirilis di Chrome 112.
Penggunaan API	Dalam kasus pelaporan kerugian dengan reportAdAuctionLoss, kita melihat "topLevelwinBid=0" dalam banyak kasus. Apa penafsiran dari hal ini?	Nilai topLevelWinBid berasal dari fungsi scoreAd() dalam komponen penjual tingkat teratas. Nilai ini berperan dalam menentukan hasil lelang tingkat teratas. Sesuai penjelasan ini, nilai topLevelWinBid nol atau angka negatif berapa pun menandakan bahwa iklan terkait tidak memenuhi syarat untuk memenangkan lelang. Mekanisme ini dapat diterapkan, misalnya, untuk memfilter iklan bertarget kelompok minat yang tidak melampaui kandidat yang ditargetkan secara kontekstual. Meskipun topLevelWinnerBid bernilai nol dapat menunjukkan bahwa lelang kontekstual telah menang, spesifikasi PA API mengonfirmasi bahwa faktor lain dapat berkontribusi pada hasil ini.
Pengujian A/B Mode	Klarifikasi tentang pemilihan traffic Mode B dan Mode A serta perintah pilihan tidak ikut.	Kriteria penyertaan untuk Mode A dan Mode B sama. Tujuannya adalah memiliki grup yang mewakili traffic Chrome normal selama mereka mendukung Privacy Sandbox API dan metode pelabelan, sehingga beberapa konfigurasi klien tidak kompatibel. Untuk tujuan eksperimen, penting untuk hanya membandingkan traffic yang diberi label dengan traffic berlabel lainnya. Pengguna di Mode B telah mengaktifkan fitur Perlindungan Pelacakan, sehingga mereka menerima notifikasi tentang fitur tersebut.
Peningkatan API	Dapatkah "lifetimeMs" disertakan sebagai properti langsung dalam panggilan joinAdInterestGroup atau mengelolanya sebagai argumen terpisah?	Kami mempertimbangkan dengan cermat masukan dari komunitas pengembangan web terkait fungsi "joinAdInterestGroup" dalam proposal PA API. Poin diskusi utama berfokus pada metode optimal untuk mengelola masa aktif IG. Kami mengevaluasi manfaat argumen terpisah untuk parameter "lifetimeMs", karena parameter tersebut mendorong fleksibilitas dan kemampuan adaptasi untuk potensi peningkatan di masa mendatang untuk spesifikasi. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Berpotensi meningkatkan rasio negatif palsu dalam framework PA API karena tumpang-tindih dengan ID browser yang memiliki entropi rendah.	Tim Chrome terlibat secara aktif dalam penyempurnaan framework PA API yang sedang berlangsung. Kami menghargai diskusi tentang potensi rasio negatif palsu yang timbul dari konflik ID browser. Kami mengevaluasi masukan ini dengan cermat dan akan berupaya untuk memastikan bahwa analisis yang diperbarui mencerminkan semua faktor yang relevan secara komprehensif. Komitmen kami adalah untuk menciptakan solusi yang dapat mencapai hasil privasi yang diinginkan sekaligus mempertahankan akurasi dan keandalan. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Apakah ID browser dengan entropi rendah diperlukan untuk mencegah klien berulang kali mengirim permintaan "Join" untuk objek yang sama dalam sistem k-anonymity?	Kami memahami dan mengapresiasi diskusi yang masih berlangsung mengenai penggunaan ID browser dalam penerapan sistem k-anonymity. Kami memahami kekhawatiran yang timbul tentang potensi implikasi privasi dari ID tersebut. Meskipun implementasi awal kami menggunakan ID entropi rendah sebagai mekanisme anti-penyalahgunaan, kami secara aktif mengeksplorasi teknik alternatif, seperti Token Penghitungan Anonim, yang memprioritaskan privasi pengguna sekaligus menjaga integritas sistem. Kami berkomitmen untuk menemukan solusi yang menyeimbangkan penggunaan data yang bertanggung jawab dengan perlindungan privasi yang kuat, dan kami menerima dialog berkelanjutan dengan komunitas riset. Kami mendiskusikan hal ini di sini dan menerima masukan tambahan.
Penggunaan API	Apakah AMP (Accelerated Mobile Pages) mendukung PA API.	AMP saat ini tidak mendukung PA API secara native. Kami menerima masukan tambahan dari ekosistem jika dukungan oleh AMP memiliki prioritas tinggi.
Peningkatan API	Pertimbangkan untuk menghapus jenis tersebut dari pemeriksaan k-anonymity.	Kami mempertimbangkan dengan cermat masukan terkait potensi pengoptimalan struktur permintaan k-anonymity. Kami memahami saran ini untuk menggabungkan parameter dan berpotensi menggabungkan jenis untuk menyederhanakan prosesnya. Tujuan kami adalah memastikan efisiensi dan kemudahan pemeliharaan, dan kami mengevaluasi semua opsi sambil terus mengembangkan solusi privasi kami. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan.
UI Chrome	Meminta mekanisme bagi pengguna yang tidak terlalu teknis agar dapat dengan mudah melihat dan mengelola IG tempat mereka bergabung, termasuk kemungkinan kontrol tingkat situs untuk memilih tidak ikut.	Kami menyadari pentingnya menyediakan alat yang mudah digunakan untuk memahami dan mengelola IG. Kami telah mempertimbangkan berbagai metode dengan cermat dan menemukan bahwa mengidentifikasi IG berdasarkan situs tempatnya bergabung menawarkan keseimbangan terbaik antara kejelasan dan perlindungan privasi. Saat ini, pengelolaan global IG terdapat dalam setelan Chrome. Kami terus mengeksplorasi cara untuk lebih meningkatkan pengalaman pengguna di area ini. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Keamanan API	Apakah PA API rentan terhadap kebocoran privasi melalui interaksi iklan materi iklan, bahkan dalam konteks Fenced Frames?	Kami menyadari potensi kebocoran informasi melalui interaksi iklan yang canggih. Kami terus menyelidiki interaksi antara Fenced Frames, PA API, dan potensi vektor serangan. Memitigasi risiko privasi adalah prioritas utama, dan kami berkomitmen untuk mengembangkan solusi andal yang menyeimbangkan inovasi dengan perlindungan pengguna. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Latensi	Apakah waktu tunggu default 50 md untuk logika bidding pembeli merupakan nilai yang realistis?	Kami memahami kekhawatiran yang timbul tentang potensi inkonsistensi antara spesifikasi dan waktu permintaan jaringan untuk logika bidding. Kami secara aktif meninjau spesifikasi tersebut untuk memastikan keakuratannya dan menyelidiki setelan waktu tunggu default yang optimal untuk menyeimbangkan performa dan kelayakan. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan.
Dokumentasi	Potensi kebocoran waktu dalam spesifikasi saat situs menyimpulkan apakah iklan gagal mencapai nilai minimum k-anonymity, dan potensi implikasi untuk pelacakan lintas situs.	Kami mengenali masalah yang dilaporkan terkait potensi kebocoran waktu. Kami telah mengonfirmasi perbedaan dalam spesifikasi dan mengambil langkah untuk memastikan bahwa status k-anonymity iklan ditentukan sebelum lelang untuk mencegah kebocoran tersebut. Kami menanggapi masalah ini dengan serius dan akan memperbarui spesifikasi untuk mencerminkan perubahan ini. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Cara menerapkan daftar yang tidak diizinkan SSP dalam PA API.	Kami menyadari perlunya mekanisme untuk mengelola pembatasan iklan oleh SSP. Sebaiknya pelajari solusi yang memprioritaskan evaluasi di perangkat dan memanfaatkan metadata iklan yang ada untuk melindungi privasi pengguna sekaligus memungkinkan fleksibilitas. Kami berkomitmen untuk bekerja sama dengan developer guna mengidentifikasi pendekatan yang optimal dalam PA API. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Dapatkah seseorang memerintahkan browsernya untuk berpura-pura melakukan PA API dengan cara yang tidak dapat dideteksi situs?	Kami memahami bahwa, dalam bentuknya saat ini, ketidakikutsertaan PA API dapat dideteksi oleh situs. Kami secara aktif berupaya membuat fitur seperti Bid Tambahan dan Penargetan Negatif, bersama dengan rendering Frame dengan Fence, untuk meningkatkan privasi dan berupaya menyediakan opsi pilihan tidak ikut yang tidak terdeteksi. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Pengujian A/B Mode	Traffic pusat data yang mengaku sebagai perlakuan 1.1.	Tim Chrome telah mengonfirmasi dengan tim GAM bahwa traffic ini sekarang difilter dari eksperimen. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Efisiensi dan keadilan penerapan interestGroupBuyers di PA API.	Kami mengakui diskusi yang sedang berlangsung tentang efisiensi dan keadilan kolom "interestGroupBuyers" dalam lelang API PA. Kami mengakui konsekuensi antara efisiensi, privasi, dan keadilan pasar. Meskipun penjual perlu mengelola hubungan bisnis dengan pembeli, kami sedang mempelajari cara untuk mengoptimalkan proses pencocokan. Hal ini dapat mencakup penyesuaian dinamis berdasarkan data real-time dan model hybrid. Kami tetap berkomitmen untuk menemukan solusi yang memprioritaskan privasi pengguna dan mendukung ekosistem periklanan yang kompetitif. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
UI Chrome	Potensi masalah memori dan kejelasan UI terkait IG di Chrome.	Kami memahami kekhawatiran yang timbul tentang menampilkan IG di DevTools. Meskipun tampilan saat ini mencerminkan semua peristiwa IG untuk pelacakan historis, kami mengakui manfaat dalam memberikan visibilitas yang lebih jelas tentang status IG yang disimpan saat ini. Kita akan mengeksplorasi pengoptimalan dan potensi peningkatan UI untuk meningkatkan insight developer. Terkait manajemen memori, implementasi IG dirancang untuk mencegah kebocoran memori, tetapi kami terus memantau dan mengoptimalkan penggunaan resource. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Dokumentasi	Pembuat postingan asli mengalami error saat mencoba menggunakan ukuran iklan yang diberi nama secara langsung dalam kolom "sizeGroup" pada fungsi "joinAdInterestGroup". Mereka ingin tahu apakah ini adalah perilaku yang dimaksudkan.	Kami memahami manfaat menyederhanakan konfigurasi iklan dalam fungsi "joinAdInterestGroup". Kami berupaya secara aktif untuk mengatasi keterbatasan ini dan berencana untuk mengaktifkan fungsi ini pada update mendatang. Peningkatan ini sejalan dengan komitmen kami untuk menyediakan alat yang fleksibel dan efisien untuk pengelolaan iklan kepada developer. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Label Pengujian yang difasilitasi Chrome	Meminta data langsung tentang Mode A vs B dan label yang tepat di sendReportTo agar kami dapat melacak eksperimen secara konsisten.	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan.
Dokumentasi	Apakah nama domain penjual disertakan dalam permintaan yang dibuat ke server tepercaya penjual untuk tujuan validasi?	Kami mengonfirmasi penghapusan awal parameter nama host dalam dokumentasi Protected Audience KV Server API. Kami ingin meyakinkan developer bahwa nama domain penjual disertakan secara otomatis dalam permintaan ke server tepercaya penjual. Fungsi ini sangat penting untuk proses validasi iklan yang andal. Kami telah memperbarui dokumentasi untuk mengatasi kelalaian ini dan akan terus memprioritaskan kejelasan dan transparansi untuk komunitas developer. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Metode yang dapat digunakan untuk menyertakan nama IG dalam panggilan pelacakan tayangan iklan untuk tujuan pelaporan.	Kami berkomitmen untuk menyeimbangkan kebutuhan akan mekanisme pelaporan yang andal dengan prinsip dasar privasi pengguna. Penyertaan nama IG dalam pelacakan tayangan iklan tunduk pada pengamanan k-anonymity yang dirancang untuk mencegah identifikasi individu. Kami akan terus mengeksplorasi solusi pelaporan inovatif dalam batasan privasi ini. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Fitur API	Meminta server tepercaya pembeli untuk menerima header HTTP Client Hints.	Kami melacak permintaan fitur ini di sini.
Penggunaan API	Apakah file delegasi harus memuat header "Access-Control-Allow-Origin" untuk dimuat, mengingat bahwa file tersebut menentukan perilaku keanggotaan IG untuk browser?	Kami berkomitmen untuk menyelaraskan dengan praktik terbaik keamanan web. Persyaratan header "Access-Control-Allow-Origin" untuk file delegasi memastikan konsistensi dengan prinsip CORS dan mencegah eksposur informasi sensitif yang tidak disengaja. Kami sedang mempelajari berbagai cara untuk mengoptimalkan proses ini sambil mempertahankan postur keamanan yang kuat. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Aktifkan server iklan untuk mempersonalisasi materi iklan dalam framework PA API.	Kami memahami peran server iklan dalam personalisasi materi iklan. Kami terus mempelajari solusi untuk mendukung server iklan dalam PA API, seperti model 'IG gabungan' tempat logika pemilihan materi iklan dan bidding dapat digabungkan. Tujuan kami adalah mencapai keseimbangan antara memungkinkan kemampuan materi iklan yang andal dan melindungi privasi pengguna. Kami menyambut baik kolaborasi dan masukan lebih lanjut tentang pengembangan API untuk mengakomodasi kebutuhan semua pemangku kepentingan di sini.
Kekhawatiran Tentang Privasi	Ketersediaan ID alternatif (misalnya RampID, ID5) dalam permintaan bid kontekstual dapat mengganggu sasaran privasi PA API dengan memfasilitasi pengumpulan data lintas situs.	Kami mengenali potensi ketegangan antara ID lintas situs dan tujuan privasi PA API. Meskipun penayang dapat memilih untuk membagikan ID tersebut, desain PA API pada dasarnya bertujuan untuk memisahkan pemilihan iklan dari kebutuhan akan pelacakan lintas situs. Kami berkomitmen untuk mengembangkan ekosistem periklanan yang berfokus pada privasi dan mendorong developer untuk memprioritaskan pendekatan PA API. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Menyimpan ke cache	Apakah ada cara untuk mencegah penggunaan ulang skrip bidding di beberapa lelang?	Kami mengonfirmasi perilaku caching yang diamati pada skrip bidding dalam framework PA API. Meskipun mekanisme caching HTTP standar didukung, potensi penggunaan ulang skrip di seluruh lelang ada karena perilaku penangguhan perangkat dan desain eksekutor bidding. Tim sedang menyelidiki solusi untuk memberi pembeli kontrol yang lebih besar atas cache skrip untuk mengelola strategi bidding secara efektif. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Memusatkan pelaporan aktivitas bidding di seluruh IG untuk DSP, sekaligus menghormati privasi pengguna.	Kami memprioritaskan privasi pengguna saat mendesain PA API. Meskipun pelaporan langsung untuk masing-masing peristiwa bidding tidak mungkin dilakukan karena risiko pelacakan lintas situs, kami menawarkan mekanisme seperti Penyimpanan Bersama dan Agregasi Pribadi. Hal ini memungkinkan DSP mendapatkan gabungan analisis tentang aktivitas bidding, dengan cara yang menjaga privasi pengguna.
Penggunaan API	Pengambilan dari sendReportTo() di reportResult() hanya terjadi 94% setiap waktu relatif untuk mendapatkan pengambilan yang terdaftar dengan forDebuggingOnly.reportAd AuctionWin().	Meski waktu keduanya tidak sama, kedua URL dapat diambil secara bersamaan. Dalam beberapa kasus, worklet penjual komponen telah dibuang dan perlu dimuat ulang untuk menjalankan fungsi reportResult(). Namun, waktu yang diperlukan untuk mengambil logika penskoran maupun waktu untuk memuat ulang worklet tidak memengaruhi waktu tunggu 50 md untuk reportResult(). Perhatikan bahwa Chrome akan menggunakan header penyimpanan dalam cache untuk menentukan perilaku pengambilannya jika worklet perlu dimuat ulang. Anda dapat mempelajari lebih lanjut fase lelang PA di sini.
K-anonimitas	Permintaan konfirmasi bahwa nama interestGroup tidak memengaruhi k-anonimitas penayangan iklan.	Agar materi iklan dianggap k-anonim, tuple URL pemilik IG, URL skrip bidding, URL materi iklan, dan ukuran iklan harus memenuhi nilai minimum yang ditentukan (k) selama jangka waktu sebelumnya (w). Status k-anonymity diperbarui secara berkala (p).
UI Chrome	Proposal untuk memberikan jenis "visibilitas internal" yang ditawarkan oleh banyak framework MVC, ORM, dll. Misalnya, mulai dengan logging sederhana peristiwa internal yang dipilih ke panel baru di bagian Dev Tools --> Application --> Application	Kami mendiskusikan proposal tersebut di sini dan menerima masukan tambahan.
UI Chrome	Penggabungan IG Dev Tools tidak menampilkan elemen terkait prioritas.	Kami telah mengatasi masalah ini di sini.
Peningkatan API	Sebaiknya izinkan server iklan materi iklan melacak peristiwanya sendiri. Apakah daftar domain pelacakan yang diizinkan dapat dikonfigurasi?	Kami telah membagikan proposal di sini dan menantikan masukan tambahan dari ekosistem.
Permintaan Fitur API	Dapatkah PA API diperluas untuk mendukung transaksi media non-RTB dan mengelola kasus penggunaan penting seperti penayangan iklan dan DCO?	Kami mendiskusikan masalah tersebut di sini dan menerima masukan tambahan.
Waktu Tunggu Lelang Penayang	Penayang memerlukan kontrol atas durasi lelang untuk mencegah tayangan yang hilang, terutama dalam penyiapan bidding header dengan iklan yang dipilih secara berurutan.	Kami memahami pentingnya memberikan kontrol terperinci kepada penayang atas waktu tunggu lelang iklan. Kami mempelajari secara aktif cara menerapkan mekanisme waktu tunggu lelang global, kemungkinan dalam objek "auctionConfig", sambil mempertimbangkan kasus ekstrem secara cermat. Fitur ini bertujuan untuk mengoptimalkan rasio pengisian tayangan bagi penayang, dan kami akan terus berkolaborasi dengan komunitas untuk menemukan solusi terbaik. Kami mendiskusikan masalah tersebut di sini dan menerima masukan tambahan.
Peningkatan API	Desain IG saat ini di PA API menghasilkan ukuran metadata yang besar karena renderURL yang panjang. Penguji menginginkan cara untuk mengompresi URL ini agar lebih efisien.	Kami menyadari pentingnya mengoptimalkan ukuran metadata IG, terutama untuk lelang iklan yang sensitif terhadap efisiensi. Menurut kami, solusi berbasis template untuk mengompresi renderURL menawarkan potensi yang signifikan. Kami akan mengevaluasi desain template yang diusulkan dan memastikan bahwa setiap solusi yang diterapkan mencakup mekanisme pencegahan penyalahgunaan yang tangguh untuk menjaga stabilitas browser. Bekerja sama dengan komunitas standar web untuk mengembangkan pendekatan yang optimal, dengan mempertimbangkan pertimbangan ini, tetap menjadi prioritas. Kami mendiskusikan masalah tersebut di sini dan menerima masukan tambahan.
Penggunaan API	Penguji yang menangani format iklan native ingin mengoptimalkan proses lelang Privacy Sandbox dengan mengambil beberapa hasil iklan dalam satu panggilan untuk mengurangi pemuatan jaringan dan meningkatkan kecepatan rendering iklan.	Kami menyadari masalah performa yang diajukan untuk rendering iklan native di Privacy Sandbox. Kami berkomitmen untuk menemukan keseimbangan antara efisiensi dan perlindungan privasi pengguna yang kuat. Meskipun menampilkan beberapa iklan dengan skor penuh akan membahayakan privasi, kami secara aktif mengeksplorasi cara untuk mengoptimalkan proses lelang. Kami berkomitmen untuk meningkatkan dukungan PA API untuk format iklan native dan menyelidiki mekanisme alternatif untuk meningkatkan efisiensi dalam batasan privasi yang kuat dari Privacy Sandbox. Kami mendiskusikan masalah tersebut di sini dan menerima masukan tambahan.
Penggunaan API	Fleksibilitas dalam cara menentukan skor dan pengurutan bid iklan dalam Privacy Sandbox, terutama untuk mewakili tingkat prioritas atau aturan marketplace pribadi.	Kami memahami perlunya kontrol terperinci atas penskoran dan pengurutan iklan dalam Privacy Sandbox, terutama dalam skenario bidding yang kompleks. Kami mengakui solusi yang diusulkan yang menggunakan tupel dan fungsi matematis untuk mencapai skor multi-dimensi tanpa mengorbankan privasi pengguna. Meskipun pendekatan ini dapat menambah kerumitan bagi developer, pendekatan tersebut menawarkan keekspresifan yang diperlukan. Kami berkomitmen untuk mempelajari cara menyederhanakan proses ini, kemungkinan melalui fungsi bantuan atau panduan, guna memastikan penggunaan fitur Privacy Sandbox yang optimal untuk logika lelang lanjutan. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
reportEvent()	Tambahkan peristiwa reservasi baru (mungkin beacon otomatis) yang diaktifkan oleh browser setelah frame dengan materi iklan diinisialisasi.	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan.
adCost	Mengizinkan perincian adCost.	Setiap nilai biaya adalah peluang untuk mengirimkan informasi dalam jumlah terbatas dari lelang. Mengizinkan seluruh daftar N dari biaya tersebut sudah cukup untuk mengirim seluruh ID pengguna, yang akan memungkinkan pelacakan lintas situs. Kami sedang membahas hal ini di sini dan menerima masukan tambahan.
resolveToConfig	Haruskah resolveToConfig diwarisi dari tingkat teratas dan diekspos di browserSignals?	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan.
Alat yang Lebih Baik	Apakah ada sesuatu yang mirip dengan chrome://topics-internals tetapi untuk PA API?	Tidak ada yang sama persis. Namun, ada alat developer yang lengkap untuk PA API.
Label	Dapatkah Chrome menggunakan label untuk mengidentifikasi 20% populasi k-anon?	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Dokumentasi	Apakah worklet lelang Privacy Sandbox akan menjadi jenis worklet standar?	Karena persyaratan privasi dan keamanan yang unik, worklet ini sangat berbeda dari jenis worklet browser standar, sehingga kami tidak mengantisipasi bahwa worklet ini akan segera menjadi jenis worklet standar dalam spesifikasi HTML. Kami berkomitmen untuk meningkatkan resource developer kami dengan penjelasan yang jelas tentang lingkungan implementasi dan eksekusi worklet lelang, sehingga informasi ini lebih mudah diakses oleh peserta Privacy Sandbox. Kami telah membahas hal ini lebih lanjut di sini.
Server Bring-Your-Own-Server (BYOS) Key-Value (KV)	Para pihak mungkin dapat mempelajari beberapa IG (dari pemilik yang sama) yang digabungkan oleh pengguna melalui kueri layanan KV dalam penyiapan Layanan KV BYOS.	Hal ini tidak akan mungkin lagi terjadi jika server KV berjalan di TEE dan kami dapat memastikan server tersebut dapat mematuhi model kepercayaan yang dipublikasikan.
userBiddingSignals	memperbarui bagian "userBiddingSignals" sekaligus mempertahankan bagian lainnya.	Tindakan ini sudah dapat dilakukan tanpa memerlukan perubahan pada API.
Penggunaan API	Menerapkan pembatasan frekuensi di beberapa IG dalam Privacy Sandbox, kemungkinan menggunakan server KV atau mengubah data "prevWinsMs".	Kami memahami keinginan untuk memiliki kemampuan pembatasan frekuensi lanjutan dalam Privacy Sandbox. Kami menyadari bahwa pembatasan berbagi data saat ini di IG dapat menimbulkan tantangan saat menerapkan strategi ini. Meskipun server KV menyediakan mekanisme potensial dengan perlindungan privasi yang sesuai, kami mendorong developer untuk mengeksplorasi solusi dalam satu model IG. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Penggunaan API	Penjual komponen (yang berpartisipasi dalam lelang bertingkat dalam Privacy Sandbox) memerlukan visibilitas terkait waktu tunggu lelang tingkat teratas untuk mengoptimalkan konfigurasi mereka sendiri dan menghindari penundaan yang tidak perlu.	Kami menyadari perlunya koordinasi waktu tunggu yang lebih baik antara penjual tingkat atas dan penjual komponen dalam Privacy Sandbox. Kami terus menyelidiki penambahan mekanisme waktu tunggu baru, termasuk potensi waktu tunggu seluruh lelang dan mempelajari cara untuk menerapkan waktu tunggu tingkat atas pada lelang komponen. Sasaran kami adalah meningkatkan efisiensi dan prediktabilitas semua peserta dalam proses lelang Privacy Sandbox. Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.

Layanan Protected Audience

Tema Masukan	Ringkasan	Respons Chrome
Trusted Execution Environment (TEE)	Lebih mahal untuk menjalankan TEE di cloud publik dibandingkan di pusat data teknologi iklan lokal?	Respons kami serupa dengan kuartal sebelumnya: Model keamanan TEE kami saat ini mendapatkan manfaat dari praktik implementasi cloud publik. Secara khusus, TEE berbasis perangkat keras saat ini tidak bertahan dari semua serangan fisik. Penyedia cloud publik kami yang sudah didukung, AWS dan GCP, merancang dan menerapkan mitigasi untuk risiko akses fisik, termasuk dari karyawan. Lihat detail lebih lanjut terkait dukungan lokal di bawah ini. Teknologi iklan telah memberi tahu kami bahwa menjalankan layanan cloud lebih mahal daripada pusat data teknologi iklan lokal. Meskipun kami tidak dalam posisi untuk mengevaluasi pernyataan tersebut, kami menerima masukan tambahan mengenai biaya dan terus mengevaluasi opsi untuk memperluas dukungan TEE kami.
TEE	Dukungan untuk TEE di lingkungan cloud non-publik	Respons kami serupa dengan kuartal sebelumnya: Meskipun kami terus mencari dukungan untuk opsi di luar solusi berbasis cloud publik, saat ini kami tidak memiliki rencana untuk mendukung TEE lokal. Pada tahap ini, mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung Google Cloud selain AWS) adalah yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan diperlukannya persyaratan tersebut dan kelayakan untuk mengingat batasan privasi dan keamanan.
Penyedia Cloud lainnya	Dukungan untuk penyedia cloud lainnya	Kami selalu menerima saran untuk penyedia cloud lainnya, tetapi saat ini kami berencana setidaknya mendukung GCP dan AWS saat 3PCD diterapkan. Lihat penjelasan ini untuk informasi selengkapnya.
API Layanan B&A	Ke mana arah Google untuk B&A Services API? Apakah akan diprioritaskan di atas atau di bawah Protected Audience browser Chrome di lelang perangkat?	Respons kami serupa dengan kuartal sebelumnya: Kami tetap berkomitmen pada desain bidding di perangkat Protected Audience saat ini. Layanan B&A telah diusulkan untuk mengeksplorasi kemungkinan solusi untuk mendukung sebagian kasus penggunaan di mana daya komputasi atau kecepatan jaringan perangkat mungkin terbatas.
Standardisasi	Layanan B&A belum melalui proses standardisasi.	Proposal B&A Services sedang berada di tengah-tengah satu fase proses standardisasi, dan kami menyambut baik interaksi tambahan untuk mendukung tujuan tersebut. Ini dimulai dengan proposal (berdasarkan proposal sebelumnya), dan sedang diinkubasi secara publik melalui diskusi terbuka yang ekstensif di W3C dan developer yang tertarik dapat mulai bereksperimen dengannya serta memberikan masukan. Ini adalah pola umum untuk pengembangan fitur web, seperti yang dijelaskan dalam postingan blog kami di sini.
Server KV	Mengekspos URL lengkap ke server KV pembeli untuk penargetan konten / kontekstual / situs.	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan dari ekosistem.
Dokumentasi	Dokumentasi untuk "Komponen Tepercaya/Diterapkan vs. opsional" di GitHub menyebabkan kebingungan bagi beberapa teknologi iklan yang memiliki kumpulan gambar dan infrastruktur deployment sendiri.	Kami ingin meningkatkan kualitas dokumentasi untuk "Komponen Tepercaya/Diterapkan vs. opsional", dan kami tertarik untuk mendengar pendapat dari ekosistem jika pekerjaan tersebut perlu diprioritaskan.
Peningkatan API	Kode Status HTTP panggilan server KV juga harus tersedia untuk fungsi scoreAd() sebagai parameter.	Kami mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem.
Dokumentasi	Berikan informasi selengkapnya tentang cara menangani beban kerja JS dan WASM secara tepat dengan eksekusi UDF.	Kami berupaya memberikan informasi ini dan menerima masukan tambahan di sini.
Dokumentasi	Minta untuk memperbarui nama repo.	Kami telah mengganti nama repositori menjadi "Protected-lelang-key-value-service". Ini sesuai dengan istilah untuk koleksi layanan yang mencakupnya, yang juga memiliki repositori lain seperti diskusi Layanan Audiens Dilindungi dan repositori dokumentasi Layanan Lelang Terlindungi.
Dokumentasi	Menghapus referensi ke Cloud debugger API di bidding_auction_services_gcp_guide.md.	Kami telah memperbarui dokumentasi dan menghapus referensi.
Penggunaan API	Latensi yang diperkenalkan oleh pencarian KV memerlukan waktu lebih dari 50 md. Perlu waktu hampir 100 md. Apakah Anda memiliki panduan tentang produk yang berfungsi dengan baik untuk penjual lain? Apakah Anda memiliki saran tentang cara mengukur waktu tunggu dan waktunya?	Panggilan server KV terjadi dalam konteks Runner Skrip, yaitu lingkungan khusus yang dilindungi di dalam browser Chrome. Hal ini dimaksudkan untuk menjaga informasi dalam runner skrip ini terlindungi dari akses non-API. Kami telah memberikan penjelasan mendetail di sini.
Penggunaan API	Apakah ada waktu tunggu bagi server KV untuk merespons dalam waktu tertentu?	Penjual dapat menentukan kolom "perBuyerCumulativeTimeouts" di konfigurasi lelang. Waktu tunggu ini mencakup waktu yang diperlukan untuk mengambil sinyal bidding tepercaya.
Latensi	Bagaimana cara tim Privacy Sandbox bekerja untuk mengatasi latensi?	Untuk strategi yang sedang kami pelajari guna menjaga latensi dalam batas yang dapat diterima, lihat di sini.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Pengoptimalan Kampanye Manual	ARA tidak mendukung pengoptimalan kampanye manual.	Kita telah membahas skenario ini dengan teknologi iklan dan menunjukkan cara menggunakan ARA untuk mendukung pengoptimalan kampanye manual. ARA dibuat sedemikian rupa agar memungkinkan penyesuaian dan fleksibilitas teknologi iklan untuk menyelesaikan berbagai kasus penggunaan teknologi iklan. Beberapa saran yang diberikan menggunakan berbagai konfigurasi tingkat peristiwa fleksibel yang berbeda dan, menggunakan laporan tingkat peristiwa dengan laporan ringkasan untuk mengurangi dampak derau dan untuk mencapai kebutuhan pengoptimalan manual dan otomatis. Kami terbuka terhadap masukan ekosistem tambahan terkait kemampuan penyesuaian dan fleksibilitas konfigurasi ARA.
Jenis Konversi	Google hanya mengizinkan delapan jenis konversi yang bersifat membatasi.	Kami telah menerapkan sebagian besar Pelaporan tingkat peristiwa fleksibel, yang memberi teknologi iklan fleksibilitas tambahan dalam hal jumlah periode pelaporan, jumlah laporan atribusi, dan bit data pemicu yang dapat mereka gunakan. Teknologi iklan dapat memilih konfigurasi yang memungkinkan pengukuran hingga 32 jenis konversi yang berbeda.
Batas Peristiwa Laporan Gabungan	Batas minimum numerik 20 peristiwa konversi per laporan agregat tidak dapat diterapkan untuk pengiklan kecil yang memiliki anggaran terbatas.	Tidak ada jumlah minimum peristiwa konversi yang diperlukan per laporan agregat. Selain itu, ada sejumlah keputusan desain yang dapat dibuat untuk mengoptimalkan laporan agregat untuk pengiklan kecil seperti mengubah struktur / dimensi utama yang dilacak, menguji berbagai level epsilon, menguji frekuensi pengelompokan yang lebih panjang, dan menguji berbagai alokasi anggaran kontribusi di antara sasaran pengukuran. Teknologi iklan yang lebih kecil juga dapat bereksperimen dengan menggabungkan laporan tingkat peristiwa untuk mengurangi dampak derau dari laporan tingkat peristiwa.
Data Real-time	Mengurangi data real-time DSP (misalnya klik, sesi, dan konversi) yang digunakan DSP untuk menyesuaikan strategi bidding dan mencapai efektivitas kampanye yang lebih baik bertentangan dengan komitmen untuk mempertahankan fungsi yang ada.	Meskipun dengan ARA, klik dan sesi tetap real time, dan konversi selalu terjadi bahkan dengan 3PC.
Bidang Belum Diisi	Persyaratan tidak ada di peluncuran peristiwa Fleksibel Penuh: i) kolom Currency, dan ii) kolom orderID / TransactionID.	Saat ini, kami tidak berencana untuk mendukung kolom Mata Uang atau ID Pesanan / ID Transaksi sebagai bagian dari tingkat peristiwa fleksibel penuh karena sudah ada cara untuk melakukannya dengan pelaporan tingkat peristiwa saat ini. Kami terbuka terhadap masukan tambahan terkait kolom ini, dan akan mempertimbangkan kembali jika ada kasus penggunaan lain yang memerlukan hal tersebut. Cara menggunakan desain ARA saat ini untuk mengukur informasi jenis ID pesanan dan mata uang: 1. Berdasarkan masukan tersebut, mata uang ditentukan berdasarkan geografis pengguna, yang dapat ditambahkan sebagai bagian dari source_event_id sebagai cara untuk menentukan mata uang yang digunakan. 2. Berdasarkan masukan tersebut, kolom ID pesanan diperlukan untuk memastikan konversi dan nilai tidak dihitung dua kali karena kesalahan, yang dapat dilakukan dengan menggunakan kunci penghapusan duplikat.
Anggaran Privasi	Anggaran Privasi ARA membatasi kemampuan untuk melakukan pengukuran di berbagai dimensi	ARA telah dirancang sedemikian rupa agar memungkinkan teknologi iklan menyesuaikan konfigurasi ARA mereka sendiri untuk mencakup berbagai skenario atribusi. Dengan teknologi iklan desain ARA saat ini, teknologi iklan harus memikirkan kompromi antara dimensi apa yang paling penting bagi mereka untuk diukur dan dampak derau pada data mereka. Penambahan derau ke data bergantung pada tingkat perincian dimensi yang diukur sangat penting untuk privasi. Kami terbuka terhadap masukan ekosistem tambahan terkait kemampuan pengukuran di berbagai dimensi, tetapi perlu memahami kasus penggunaan spesifik yang memerlukannya.
Perbarui Spesifikasi	Meskipun Google menyatakan telah beralih dari periode pelaporan peristiwa tetap ke fleksibel, hal ini tidak tercermin dalam Spesifikasi Teknis Google yang saat ini masih memiliki periode minimum satu jam.	Pelaporan tingkat peristiwa fleksibel saat ini memungkinkan teknologi iklan mengubah jumlah laporan atribusi per peristiwa sumber, bit data pemicu, dan jumlah/panjang periode pelaporan. ARA masih memiliki periode pelaporan minimum 1 jam untuk laporan tingkat peristiwa yang penting untuk menjaga privasi dan memitigasi jenis serangan rekonstruksi histori tertentu. Karena laporan ringkasan memberikan informasi secara agregat, teknologi iklan dapat memilih untuk segera menerima laporan agregat tanpa penundaan, jika diperlukan untuk kasus penggunaannya.
Desain API	Kekhawatiran bahwa pengurangan informasi dalam laporan konversi dan penambahan derau dapat berdampak lebih besar pada ekosistem dibandingkan dengan Google.	Google telah berkomitmen kepada CMA untuk merancang dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan mementingkan bisnis sendiri milik Google sendiri, serta mempertimbangkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan dari berbagai skala.
Koreksi Atribusi	ARA tidak mengizinkan penyedia teknologi mengontrol dan memverifikasi atribusi yang benar.	Ada banyak solusi yang tersedia dalam ARA yang memberikan kemampuan verifikasi: 1. Teknologi iklan dapat memverifikasi bahwa perilaku ARA sesuai dengan harapan mereka: – Kode sisi klien ARA bersifat open source. – Kode sisi server ARA juga merupakan open source, dan Koordinator memastikan bahwa hanya versi Layanan Agregasi yang diizinkan yang dapat mendekripsi dan memproses laporan gabungan. 2. Chrome telah menyediakan Library Simulasi untuk memverifikasi perilaku atribusi, tempat teknologi iklan dapat menguji cara ARA melakukan atribusi di lingkungan tiruan. 3. ARA mendukung sejumlah sinyal debug yang membantu memverifikasi apakah pemrosesan yang diharapkan tidak terjadi atau tidak, serta alasan pemrosesan yang diharapkan.
(Juga dilaporkan pada kuartal sebelumnya) Kebisingan	Masukan bahwa tingkat derau terlalu tinggi dan hal ini memengaruhi kegunaan pelaporan.	Kami telah berdiskusi dengan teknologi iklan dengan masukan yang sama ini dan dapat mengidentifikasi cara untuk menyesuaikan ARA agar lebih sesuai dengan kasus penggunaan mereka, bahkan dengan derau. Kami memiliki dokumentasi developer yang berisi sebagian besar keputusan desain dan penyesuaian yang telah kita diskusikan dengan teknologi iklan. ARA telah dirancang sedemikian rupa agar memungkinkan teknologi iklan menyesuaikan konfigurasi ARA mereka sendiri untuk mencakup berbagai skenario atribusi. Namun, teknologi iklan perlu memikirkan kompromi antara dimensi yang paling penting untuk diukur dan dampak derau pada data mereka. Kami terbuka terhadap masukan ekosistem tambahan terkait dampak derau dan dapat memberikan panduan tambahan terkait indikator ARA yang dapat digunakan untuk mengubah dampak derau.
Atribusi Lintas-Domain	Bagaimana cara melacak atribusi yang merupakan lintas domain?	Teknologi iklan dapat mengalihkan ke URL pelaporan yang berbeda untuk mengatasi kasus penggunaan ini. Kami terbuka terhadap masukan ekosistem tambahan mengenai aspek desain ARA ini.
Peningkatan API	Ubah faktor penskalaan yang digunakan saat mendaftarkan atribusi untuk Laporan Ringkasan ARA secara rutin.	Berdasarkan diskusi di GitHub, tampaknya menangani beberapa faktor penskalaan di Layanan Agregasi kemungkinan besar akan menghasilkan jumlah derau yang ditambahkan ke laporan ringkasan yang lebih tinggi dibandingkan dengan fungsi saat ini. Kami terbuka terhadap masukan tambahan mengenai perlunya faktor penskalaan sebagai bagian dari laporan agregat, tetapi kami ingin menjelaskan potensi kompromi dengan peningkatan derau. Kami juga mengevaluasi apakah fitur ARA lainnya di masa mendatang dapat membantu memecahkan kasus penggunaan ini juga.
Penggunaan API	Peluang untuk menyatukan cara peristiwa atribusi dibagikan kepada semua peserta yang bermanfaat bagi SSP, DSP, dll.	Kami berencana untuk menyinkronkan dengan teknologi iklan untuk lebih memahami masukan mereka dan keterbatasan apa pun yang mereka hadapi.
Menguji Volume Traffic	Apakah traffic pengujian untuk Mode B untuk semua Chrome stabil?	Penyertaan dalam grup eksperimen tidak terpengaruh oleh (terlepas dari) setelan Chrome.
Dokumentasi	Mendukung ARA untuk piksel.	Kami telah memublikasikan informasi tentang cara mendukung kasus penggunaan ini dan menantikan masukan tambahan dari ekosistem.
Penggunaan API	ARA mungkin tidak diatribusikan ke sumber yang benar untuk penjual pihak ketiga di platform e-commerce jika konversi tidak dilakukan dengan sentuhan terakhir.	Perusahaan dapat menggunakan filter untuk mencegah atribusi yang salah terjadi (karena tidak ada laporan konversi yang akan dibuat). Kami juga sedang mengerjakan proposal untuk pemfilteran pra-atribusi guna membantu kasus penggunaan ini.
Dukungan Browser	Apakah ARA akan didukung di browser yang berbeda?	Kami menyambut baik browser lain untuk mengadopsi Privacy Sandbox API dan terus mendedikasikan waktu untuk mendiskusikan pendekatan kami secara terbuka di W3C. Kami secara eksplisit telah menyatakan interoperabilitas sebagai tujuan untuk mengirimkan desain ARA dan ARA dimaksudkan agar tidak bergantung pada browser dengan nilai yang ditentukan vendor yang fleksibel untuk vendor dengan sikap privasi yang berbeda. Browser lain membuat pilihan mereka sendiri terkait apakah akan memberikan alternatif yang memungkinkan untuk mendukung ID lintas situs dan ekosistem konten. Kami yakin bahwa Microsoft Edge telah menunjukkan bahwa Microsoft Edge akan mendukung ARA.
Penggunaan API	Apa jenis sumber yang diharapkan untuk pendaftaran sumber ARA untuk registerAdBeacon/reportEvent (dan beacon otomatis navigation_start/commit)?	Bergantung pada apakah beacon ini otomatis atau manual: - dicadangkan.* (yaitu otomatis) untuk menjadi jenis sumber navigasi. - Peristiwa yang dipicu secara manual menjadi jenis sumber peristiwa.
Penggunaan API	Apakah batas maksimum 20 laporan gabungan per sumber berarti untuk setiap peristiwa sumber? Apakah batas tersebut bersifat global atau harian? Apakah ada rencana untuk meningkatkan batas tersebut?	Batas 20 laporan gabungan per sumber adalah batas global yang memungkinkan pembuatan 20 laporan gabungan untuk setiap sumber. Batasnya ditetapkan oleh browser dan tidak dapat dikonfigurasi. Tujuan batas ini adalah untuk menghindari penyalahgunaan perlindungan laporan atribusi yang sebenarnya dengan laporan null. Kami telah membahas hal ini lebih lanjut di sini.
Penggunaan API	Dukungan untuk pemasaran melalui email menggunakan ARA.	Saat ini tidak ada dukungan langsung untuk kasus penggunaan ini dalam ARA (jika Anda tidak mengontrol situs hosting email). Kami sedang membahas hal ini di sini dan menerima masukan tambahan.
Epsilon	Kapan nilai epsilon untuk Aggregate API akan ditentukan?	Nilai epsilon saat ini dapat dikonfigurasi oleh teknologi iklan hingga nilai minimum yang telah ditentukan sebelumnya dan ditetapkan oleh Privacy Sandbox (saat ini adalah 64). Sebaiknya uji berbagai nilai epsilon dan identifikasi titik belok untuk kasus penggunaan Anda sendiri dan berikan masukan. Kami akan memastikan untuk mengomunikasikan kepada teknologi iklan terlebih dahulu sebelum perubahan pada rentang nilai epsilon.
Peningkatan API	Mendukung kasus penggunaan saat pengiklan dapat memasukkan ID ke kolom trigger_data untuk mencocokkan dengan data CRM eksternal agar pengiklan dapat memverifikasi kualitas konversi.	Kami sedang mendiskusikan permintaan tersebut dan menerima masukan tambahan di sini.
Penggunaan API	Cara menangani URL alihan sebagai URL tujuan.	Teknologi iklan dapat melakukan salah satu hal berikut: 1. Masukkan URL tujuan akhir di kolom tujuan; 2. Kolom tujuan dapat berisi maksimal 3 URL, sehingga Anda dapat memasukkan beberapa URL ke kolom. Kedua opsi tersebut, Anda perlu mengetahui URL tujuan akhir. Kami telah membahas hal ini lebih lanjut di sini.

Layanan Agregasi

Tema Masukan	Ringkasan	Respons Chrome
Mekanisme Penemuan Utama	Meminta mekanisme penemuan kunci	Kami memiliki proposal untuk penemuan kunci dan menerima masukan dari ekosistem dalam proposal tersebut.
Penggunaan API	Roadmap untuk kemampuan observasi di Layanan Agregasi	Kami sedang meninjau sejumlah opsi untuk mendukung kemampuan observasi yang lebih tinggi dan menerima masukan dari ekosistem di sini.
Peningkatan API	Meminta agar dapat mengkueri ulang laporan.	Layanan Agregasi sedang mengerjakan proposal kueri ulang tempat teknologi iklan dapat memisahkan epsilon mereka untuk setiap laporan. Hal ini dapat menyebabkan lebih banyak derau per kueri, tetapi akan memungkinkan teknologi iklan mengkueri ulang dan menjaga privasi.
Peningkatan API	Ingin dapat mengaitkan beberapa origin ke ID AWS yang sama.	Layanan Agregasi kini akan memungkinkan beberapa situs untuk diaktivasi di akun cloud yang sama (GCP atau AWS). Hal ini akan memungkinkan teknologi iklan menggunakan enklave Layanan Agregasi yang sama untuk memproses laporan dari beberapa situs dan beberapa origin dari situs yang sama.
Penggunaan API	Ketika batch gabungan gagal, tidak yakin apakah anggaran habis atau tidak, dan apakah mereka dapat memproses ulang batch-nya. Jika layanan agregasi mengalami error anggaran untuk laporan duplikat, laporan lainnya akan hilang. Bagaimana cara meminimalkan kerugian ini?	Dalam skenario umum, jika seluruh tugas gagal, anggaran tidak akan habis. Dalam kasus kegagalan langka saat anggaran terpakai, teknologi iklan dapat meminta pemulihan anggaran. Jika teknologi iklan sering mengalami kegagalan tugas karena error kehabisan anggaran, mereka harus mengonfirmasi strategi pengelompokan mereka. Petunjuk mengenai cara mengelompokkan dengan benar serta menghindari error dan laporan duplikat dapat ditemukan di sini. Kami menerima masukan terkait pemulihan anggaran di sini.
Penggunaan API	Menggunakan Private Aggregation API dengan pemicu yang dijelaskan di sini akan menghasilkan laporan gabungan untuk setiap lelang. Apa saja kemampuan penskalaan Layanan Agregasi?	Layanan Agregasi itu sendiri tidak menetapkan batas maksimal pada jumlah kunci atau laporan dalam satu batch tetapi skala laporan 10^14 dan kunci 10^12 saat ini tidak didukung karena adanya memori yang akan diperlukan. Panduan ukuran kami menunjukkan rentang yang telah kami uji dan direkomendasikan untuk performa yang optimal dengan mempertimbangkan beban yang diharapkan dan jenis instance cloud vm yang didukung.
Pemrosesan Data	Jika data terenkripsi memiliki informasi pribadi, apa pengaturan hukum untuk penyediaan data terenkripsi ke Layanan Agregasi? Dapatkah Anda memberi tahu apakah koordinator sudah dijamin tidak akan mengakses data terenkripsi?	Layanan Agregasi tidak membagikan data pengguna / terenkripsi kepada Koordinator. Layanan Agregasi menggunakan koordinator untuk pengelolaan kunci dan akuntansi. Beberapa detail tentang koordinator dapat dilihat di sini. Untuk akuntansi, layanan Agregasi hanya membagikan ID bersama dan asal pelaporan kepada PBS untuk penggunaan anggaran. Setelah meluncurkan multi-situs, kami akan mengganti origin dengan situs. Perhatikan bahwa layanan Agregasi berjalan di TEE yang merupakan satu-satunya tempat laporan dari klien dapat didekripsi. Kode yang berjalan di TEE bersifat open source dan diaudit oleh pihak eksternal sebagaimana dijelaskan di sini.

Private Aggregation API

Tema Masukan	Ringkasan	Respons Chrome
Penggunaan API	Kemampuan penjual komponen untuk mengirim laporan ke beberapa server agregasi dalam TEE.	Status Private Aggregation API saat ini tidak mendukung fitur ini. Kami telah membahas masalah ini lebih lanjut di sini.
Dokumentasi	Berapa nilai epsilon yang digunakan dalam uji coba Google?	Untuk Private Aggregation API, nilai ε yang ditentukan dalam kueri layanan agregasi sesuai dengan anggaran kontribusi L1 2^16 yang diterapkan per 10 menit. Ada juga anggaran kontribusi L1 'backstop' sebesar 2^20 yang ditegakkan setiap 24 jam secara bergulir. Jadi pada dasarnya, parameter privasi adalah ε dalam basis 10 menit, dan 16ε dalam basis 24 jam (bukan 144ε). Layanan Agregasi saat ini mendukung rentang ε untuk pengujian (hingga 64) untuk memungkinkan eksperimen dengan berbagai strategi agregasi dan memberikan masukan terkait utilitas sistem dengan parameter privasi yang berbeda untuk Agregasi Pribadi dan API lainnya. Seiring waktu, kami berencana meninjau kembali nilai epsilon maksimum yang diizinkan sesuai dengan masukan dari penguji dan menambahkan fitur yang memungkinkan penggunaan anggaran privasi yang lebih efisien.

Batasi Pelacakan Terselubung

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tidak ada masukan yang diterima untuk kuartal ini.

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
ID Resolusi	Privacy Sandbox perlu lebih vokal untuk menekan bahwa ID resolusi yang sering kali dibuat berdasarkan IP tidak akan berkelanjutan bagi pengiklan.	Privacy Sandbox telah memperjelas bahwa kami bertujuan untuk mengurangi pelacakan lintas situs. Inisiatif publik kami, yang lebih dari sekadar cookie, dipublikasikan di privacysandbox.com dan GitHub. Kami berusaha mengurangi pelacakan lintas situs, termasuk yang didasarkan pada alamat IP. Namun, pada akhirnya bergantung pada masing-masing situs untuk memutuskan apakah akan mengaktifkan pelacakan lintas situs secara proaktif atau tidak. Di era peningkatan pengawasan terhadap kepatuhan terhadap peraturan, perusahaan sebaiknya memahami praktik yang diterapkan oleh penyedia layanan mereka.
Chromecast	Apakah Perlindungan IP akan memengaruhi Chromecast atau perangkat Chrome lainnya?	Saat ini, tidak ada rencana untuk menerapkan Perlindungan IP ke perangkat Chromecast.
Daftar Perlindungan IP	Apakah daftar pihak ketiga yang diidentifikasi berpotensi menggunakan alamat IP untuk pelacakan lintas situs di seluruh web akan dipublikasikan?	Daftar tersebut akan dipublikasikan setelah selesai, seperti yang dibahas di sini.

Mitigasi Pelacakan Kembali

Tema Masukan	Ringkasan	Respons Chrome
Pengecualian Single Sign On (SSO)	Bagaimana cara Mitigasi Pelacakan Kembali (BTM) memverifikasi kasus penggunaan SSO untuk pengecualian?	BTM akan dinonaktifkan oleh heuristik Chrome. Lihat di sini untuk mengetahui detailnya.
Uji Coba Penghentian Penggunaan	Apakah BTM diaktifkan untuk situs dalam uji coba penghentian penggunaan 3PC?	Tidak, BTM mematuhi pengecualian cookie yang dibuat oleh uji coba penghentian penggunaan, seperti yang dibahas di sini.

Anggaran Privasi

Seperti disebutkan dalam penjelasan GitHub dan situs developer, Anggaran Privasi tidak lagi dipertimbangkan secara aktif sebagai bagian dari proposal Privacy Sandbox.

Memperkuat batas privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tema Masukan	Ringkasan	Respons Chrome
Permintaan Fitur	CHIP dan / atau Partisi Penyimpanan secara otomatis diizinkan untuk diakses di seluruh RWS, tanpa memerlukan Storage Access API, maupun interaksi pengguna.	Kami mempertimbangkan manfaat dan kelayakan fitur yang dapat menjalankan fungsi ini. Salah satu pertimbangannya adalah potensi celah dalam interoperabilitas lintas browser, yang ditangani RWS dengan memanfaatkan Storage Access API. Saat ini, fungsi yang diminta ini tidak didukung di browser lain. Sebaiknya developer mengirimkan kasus penggunaan mereka terkait masalah ini untuk memfasilitasi diskusi di sini.
Penghapusan Set yang Tidak Mematuhi Kebijakan	Bagaimana proses untuk menghapus kumpulan yang tidak mematuhi kebijakan dari repositori?	Kami sedang menentukan prosesnya, dan kami akan membagikan info terbaru segera setelah tersedia.
Proses Penegakan Kebijakan	Terdapat kurangnya kejelasan mengenai peran subjektif Google dalam proses penegakan RWS.	Karena RWS adalah project yang sedang berlangsung dan kami terus menerima pengajuan baru, aspek proses dan kriteria kami masih diperkuat. Kami setuju bahwa penting bagi panduan pengiriman kami untuk menguraikan persyaratan pengiriman secara lengkap, dan kami akan menambahkan detail lebih lengkap pada panduan pengiriman kami ke depannya untuk menghindari ambiguitas dan kebingungan lebih lanjut. Tujuan kami adalah agar proses pengiriman dilakukan seteknis mungkin sehingga kami dapat menghilangkan keterlibatan manusia dan sepenuhnya mengandalkan pemeriksaan otomatis. PR seperti ini memerlukan lebih banyak interaksi manusia karena mencakup perilaku yang tidak kita antisipasi, tetapi memungkinkan kita mengidentifikasi lebih banyak area untuk otomatisasi dan cara memperbaiki pedoman untuk menghindari masalah ini ke depannya.
Membagikan Data	Minta fitur yang memungkinkan pemilik domain untuk menunjukkan bahwa mereka ingin pihak ketiga juga membagikan data RWS, dengan izin pengguna.	Fungsi yang diminta sudah tersedia melalui API seperti FedCM, dan Storage Access API yang memungkinkan akses ke identitas terautentikasi setelah pengguna menerima prompt izin. Kami menerima masukan dari ekosistem terkait kasus penggunaan tertentu yang mereka yakini tidak mungkin.
Metode Penyimpanan Lain	Apakah informasi yang disimpan di penyimpanan lokal atau penyimpanan sesi juga akan ditafsirkan sebagai 3PC?	Penyimpanan lokal, penyimpanan sesi, dan bentuk penyimpanan non-cookie lainnya jika digunakan dalam konteks pihak ketiga telah dipartisi di Chrome sejak versi 115. Lihat postingan blog ini untuk detail tambahan.
Batas Set Terkait	Apa yang terjadi pada organisasi yang mengirimkan lebih dari 5 domain meskipun hal ini "dibatasi pada 5 situs terkait"?	Kumpulan ini akan diterima melalui proses GitHub, tetapi browser (Chrome) hanya akan menerapkan aturan pemberian otomatis Storage Access API kami ke 5 domain pertama; dan mengabaikan domain lainnya, seperti yang dibahas di sini.
find_robots_txt	Pemeriksaan find_robots_txt tidak berfungsi dengan pengalihan.	Perbaikan telah dikirimkan untuk menyelesaikan masalah ini di sini.
Gestur Pengguna	Menghapus persyaratan gestur pengguna untuk accessStorage().	Persyaratan ini dibuat berdasarkan desain serupa yang diterapkan di semua browser utama untuk requestStorageAccess API. Kami mengundang masukan tambahan dan kasus penggunaan dalam masalah GitHub ini untuk membantu kami memprioritaskan permintaan ini, dan memungkinkan diskusi lintas browser.
Gestur Pengguna	Apakah gestur pengguna diperlukan untuk memberikan izin akses penyimpanan pihak ketiga setelah Chrome atau OS dimulai ulang?	Ya, tetapi kami menerima masukan tambahan dari ekosistem terkait apakah akan mengubah perilaku ini di sini.

API Frame dengan Fence

Tema Masukan	Ringkasan	Respons Chrome
adComponent	Kurangnya dokumentasi dan fleksibilitas menggunakan AdComponents dengan Frame dengan Fence.	Kami ingin membagikan lebih banyak dokumentasi terkait kasus penggunaan ini. Selain itu, komponen iklan didukung dalam Fenced Frames menggunakan getNestedConfigs() yang didokumentasikan dalam spesifikasi di sini.
(Juga dilaporkan pada kuartal sebelumnya) Merender komponen iklan	Meminta kode contoh tentang cara merender adComponents dalam Fenced Frame.	Kami sedang berupaya membagikan beberapa contoh kode di sini.
Verifikasi Iklan Pihak Ketiga	Peran verifikasi iklan pihak ketiga dalam konteks Frame dengan Fence memerlukan detail lebih lanjut, terutama terkait keamanan kontekstual/merek.	Saat ini, Pelaporan Iklan Fenced Frames memungkinkan DSP mengirim data tingkat peristiwa lelang dan tayangan ke pemverifikasi iklan pihak ketiga untuk penagihan dan pemeriksaan keamanan merek pasca-render.
Iklan yang Dapat Diperluas	Permintaan untuk mendukung iklan yang dapat diperluas.	Jika iklan perlu beralih di antara dua ukuran dengan rasio aspek yang sama, dan tidak ada perbedaan fungsional di antara keduanya (hanya ukuran), penyemat dapat mengubah ukuran Fenced Frame dengan ukuran iklan kedua dan browser menyesuaikan skala elemen Fenced Frame.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan untuk Inventaris Video & Native	Apakah Bingkai dengan Fence mendukung inventaris video & native?	Respons kami serupa dengan kuartal sebelumnya: PA API mendukung rendering video menggunakan mekanisme yang mengandalkan iframe. Namun, kami belum merancang solusi untuk rendering iklan native dan video yang kompatibel dengan Fenced Frames, dan ini adalah salah satu alasan kami memutuskan untuk membatalkan penerapan Fenced Frames ke 2026. Artinya, jika partner memutuskan untuk menerapkan Fenced Frames sekarang, dukungan untuk video dan native akan kurang untuk partner tersebut.
Dewan Penasihat	Meminta pembuatan dewan penasihat vendor iklan native untuk memastikan penerapan Fenced Frames mengikuti standar industri.	Frame dengan Fence tidak diperlukan untuk digunakan di PA API mulai tahun 2026. Tambahan waktu tersebut memungkinkan kami untuk terus bekerja sama dengan industri guna merancang dan mengimplementasikan dukungan untuk berbagai kasus penggunaan penting yang lebih luas. Kami telah menyatakan bahwa kami akan mengembangkan Fenced Frame sebelum persyaratan mereka untuk mempertahankan dukungan untuk iklan native dan video dengan PA API. Sesuai dengan komitmen kami, kami akan berinteraksi dengan dan memberi tahu CMA jika ada perubahan semacam itu. Kami juga akan terus merespons masukan dari ekosistem sebelum mewajibkan Bingkai dengan Fence. Model interaksi ekosistem kami di W3C dan organisasi standar iklan seperti IAB Tech Lab memungkinkan pakar industri dari segala jenis untuk memandu desain sebelum diperlukan.
(Juga dilaporkan di kuartal sebelumnya) Perbedaan Ukuran di Berbagai Platform	Melaporkan bahwa ukuran konten yang ditampilkan dalam Fenced Frame terlihat berbeda antara desktop dan smartphone.	Ini adalah masalah Chromium umum yang sedang kami selidiki. Kami menantikan masukan tambahan di sini.
Peningkatan API	Apakah persyaratan Frame dengan Fence diundur ke tahun 2025 sehingga iklan native kini didukung berdasarkan Privacy Sandbox?	Seperti yang kami catat dalam pengumuman publik terkait penerapan Fenced Frames paling cepat tahun 2026, kami telah mengetahui adanya "upaya signifikan untuk mengakomodasi" Fenced Frames secara luas. Tentu saja, salah satunya adalah Native, tetapi itu bukan satu-satunya faktor. Tujuannya adalah untuk menyediakan lebih banyak waktu guna memastikan kesiapan ekosistem untuk mendukung kasus penggunaan utama, termasuk, tetapi tidak terbatas pada, native.

Shared Storage API

Tema Masukan	Ringkasan	Respons Chrome
Performa	Waktu pengembalian Penyimpanan Bersama di luar worklet tampaknya bergantung pada aktivitas di worklet.	Kami sedang membahas hasil tes ini di sini.
Adopsi yang Lebih Lebar	Penyimpanan Bersama harus menjadi standar tingkat industri yang tersedia di seluruh browser.	Kami menyambut baik dan menghargai masukan ini. Chrome terus berpartisipasi secara aktif dalam fora W3C, termasuk WICG, untuk memperjuangkan proposal, mencari masukan, dan mendorong penggunaan.
Worklet Bidding	Apakah saya dapat membaca dari Penyimpanan Bersama dalam generateBid (yang sudah berjalan di worklet) untuk menerapkan keputusan iklan / logika bisnis (seperti Pembatasan Frekuensi) berdasarkan informasi lintas situs dan memilih subkumpulan iklan?	Tidak, Anda tidak dapat membaca dari penyimpanan bersama dalam worklet bidding.

CHIP

Tema Masukan	Ringkasan	Respons Chrome
Kapasitas Partisi	Memperjelas perilaku saat melebihi kapasitas partisi.	Saat kapasitas tercapai, cookie terlama akan dikeluarkan dari cookie yang terakhir diakses ke memori bebas hingga batasnya tidak lagi terlampaui. Developer melihat header Cookie yang diupdate dalam permintaan berikutnya.
Akses iFrame Pihak Ketiga	Konten iFrame pihak ketiga yang disematkan yang membuka tab/jendela baru ke situs pihak ketiga yang sama harus memiliki akses ke cookie terpartisi yang sama dengan pembuka.	Kami mendiskusikan kasus penggunaan ini dan menerima masukan tambahan dari ekosistem di sini.
Cookie Duplikat	Jika ada cookie yang dipartisi dan cookie tidak dipartisi dengan nama yang sama, nilai kunci mana yang memutuskan untuk dikirim oleh browser?	Jika memiliki dua cookie dengan nama yang sama (satu dipartisi, dan satu tidak), Anda akan mendapatkan kedua cookie tersebut – sayangnya, tidak ada cara untuk membedakannya. Spesifikasi RFC tersedia di sini, yang menjelaskan bahwa urutan pengiriman cookie tidak boleh diandalkan.
Permintaan Fitur	Ikut serta dalam cookie yang dipartisi origin.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem di sini.

FedCM

Tidak ada masukan yang diterima untuk kuartal ini.

Mencegah spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Webview	Apakah Token Status Pribadi (PST) tetap ada di beberapa Webview pada perangkat seluler (profil) yang sama?	Setiap aplikasi yang menggunakan webview akan memiliki penyimpanan lokal berbeda, yang berarti penerbit PST tidak dapat menerbitkan token di webview satu aplikasi, lalu di aplikasi terpisah, mengizinkan penukaran token. Hal ini juga berlaku untuk bentuk data lain yang disimpan secara lokal di webview, seperti cookie. PST belum sepenuhnya tersedia di WebView. Kami berharap dapat memberikan informasi terbaru tentang hal ini pada akhir Kuartal 2.
Jenis Token Baru	Proposal untuk jenis token baru.	Kami berterima kasih atas proposal ini dan melanjutkan eksplorasi aplikasi serta adaptasi PST, serta berharap dapat mempelajari proposal ini lebih lanjut dalam pertemuan Kelompok Komunitas Anti-Penipuan mendatang pada Q2 2024.
Identifikasi Pengguna	Bagaimana cara mencegah pengguna diidentifikasi berdasarkan PST tertentu yang dimiliki pengguna?	Saat ini, hal ini dimitigasi dengan membatasi upaya penukaran di situs untuk dua penerbit, terlepas dari apakah ada token yang tersedia dari penerbit tersebut atau tidak. Anda harus menghitung penerbit berdasarkan batasnya meskipun tidak ada token yang tersedia karena jika tidak, situs dapat melakukan iterasi ke semua penerbit hingga mencapai kecocokan positif.
Pendaftaran	Berapa lama pendaftaran diperlukan untuk PST?	Pendaftaran akan terus diwajibkan untuk waktu mendatang, seperti yang dijelaskan secara lebih mendetail di sini.
Dukungan untuk Browser Chromium lainnya	Apakah pendaftaran penerbit PST untuk browser berbasis Chromium lainnya akan didukung melalui repositori Pendaftaran Penerbit Chrome?	Chrome mengambil komitmen utama dan mendistribusikannya ke klien Chrome melalui mekanisme yang disebut Updater Komponen. Karena browser lain menambahkan dukungan yang lebih lengkap untuk API, browser tersebut harus menetapkan proses untuk mendapatkan komitmen kunci kepada klien, baik melalui metode gaya updater komponen atau metode lainnya. Hal ini dibahas secara lebih mendetail di sini.