Laporan Masukan - K2 dan K3 2024

Laporan kuartalan untuk Kuartal 2 dan 3 tahun 2024 yang merangkum masukan ekosistem yang diterima terkait proposal Privacy Sandbox dan respons Chrome.

Sebagai bagian dari komitmennya terhadap CMA, Google telah setuju untuk memberikan laporan secara publik per kuartal tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox (lihat paragraf 12 dan 17(c)(ii) dalam Komitmen). Pada 22 Juli 2024, Google mengumumkan bahwa mereka tidak akan menghentikan penggunaan cookie pihak ketiga (3PC) di Chrome, dan sebagai gantinya mengusulkan untuk memperkenalkan pendekatan yang diperbarui untuk meningkatkan pilihan pengguna. Oleh karena itu, dengan persetujuan CMA, Google tidak mengirimkan laporan publik Q2 2024 kepada CMA agar Google dan CMA memiliki waktu yang cukup untuk mempertimbangkan implikasi pengumuman Google tersebut.

Laporan ringkasan masukan Privacy Sandbox ini dihasilkan dengan menggabungkan masukan yang diterima oleh Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang tersedia di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menerima masukan yang diperoleh dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.

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

Lebih khusus lagi, risalah rapat untuk rapat badan standar web telah ditinjau dan, untuk masukan langsung, catatan Google tentang rapat pemangku kepentingan 1:1, email yang diterima oleh setiap engineer, milis API, dan formulir masukan publik dipertimbangkan. Google kemudian berkoordinasi antara tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi tema yang muncul secara relatif sehubungan dengan setiap API.

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

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

Glosarium akronim

ARA

Attribution Reporting API

CHIP

Cookie yang Memiliki Status Partisi Independen

DSP

Platform Sisi Permintaan

FedCM

Federated Credential Management

FPS

Set Pihak Pertama

IAB

Interactive Advertising Bureau

IDP

Penyedia Identitas

IETF

Internet Engineering Task Force

IP

Alamat Internet Protocol

openRTB

Bidding real-time

OT

Uji Coba Origin

API PAT

Protected Audience API (sebelumnya FLEDGE)

PatCG

Grup Komunitas Teknologi Iklan Pribadi

RP

Pesta Santai

RWS

Set Situs Terkait (sebelumnya Set Pihak Pertama)

SSP

Platform Sisi Pasokan

TEE

Trusted Execution Environment

UA

String Agen Pengguna

UA-CH

User-Agent Client Hints

W3C

World Wide Web Consortium

WIPB

Willful IP Blindness

Masukan umum, tidak ada API/Teknologi tertentu

Tema Masukan	Ringkasan	Respons Chrome
Penghentian cookie pihak ketiga (3PCD)	Apa rencana Google untuk 3PCD dan apakah efek jangka panjangnya terhadap industri periklanan digital telah dinilai?	Kami mengusulkan pendekatan yang diperbarui yang mengakomodasi pilihan pengguna. Seperti yang diuraikan di sini, alih-alih menghentikan penggunaan 3PC, kami akan memperkenalkan pengalaman baru di Chrome yang memungkinkan pengguna membuat pilihan tepat yang berlaku di seluruh penjelajahan web mereka, dan mereka dapat menyesuaikan pilihan tersebut kapan saja. Kami sedang mendiskusikan jalur baru ini dengan badan pengatur, dan akan melibatkan industri sebelum meluncurkannya.
Pilihan Pengguna	Pengumuman pilihan pengguna telah memengaruhi minat ekosistem dalam mengadopsi solusi Privacy Sandbox. Ada masukan beragam terkait pengumuman pilihan pengguna, termasuk permintaan untuk fitur seperti kemampuan pemantauan.	Dengan pendekatan terbaru yang meningkatkan pilihan pengguna, tetap penting bagi developer untuk memiliki alternatif yang meningkatkan privasi untuk ID lintas situs. Meskipun kami belum memiliki detail untuk dibagikan tentang tampilan pengalaman baru ini, kami memperkirakan akan ada peningkatan traffic tanpa cookie yang signifikan di Chrome. Artinya, Privacy Sandbox API tetap penting bagi bisnis. Kami akan terus berinvestasi pada teknologi Privacy Sandbox untuk lebih meningkatkan privasi dan utilitas.
UI Pilihan Pengguna	Pertanyaan tentang linimasa untuk fitur pilihan tidak ikut/izin, jenis opsi pengguna yang dipertimbangkan, dan pengaruh UI terhadap lingkungan pengujian otomatis.	Saat ini, kami tidak memiliki pembaruan linimasa untuk dibagikan. Setelah memutuskan untuk tidak melanjutkan 3PCD, kami ingin memberikan pembaruan ke ekosistem sesegera mungkin. Kami akan segera membagikan info terbaru tentang jadwal untuk pilihan pengguna.
Pengujian Chrome	Meminta ketersediaan berkelanjutan Label Pengujian yang difasilitasi Chrome untuk mengukur adopsi pasar dan dampak ekonomi 3PCD pasca-Semester 1 2024.	Kami memahami bahwa penguji ingin terus menggunakan grup browser berlabel untuk pengujian dan koordinasi bahkan saat pengujian yang difasilitasi Chrome 1H 2024 telah berakhir. Kami sedang mengevaluasi langkah berikutnya untuk label sehubungan dengan pengumuman pilihan pengguna. Sementara itu, tim Chrome telah memublikasikan niat untuk memperluas dukungan bagi grup browser berlabel melalui Chrome Milestone 132, yang berlangsung hingga Januari 2025.
Privacy Sandbox di Android	Privacy Sandbox di Android dan Privacy Sandbox di Chrome saling terkait, dan kami tidak dapat menilai Privacy Sandbox dengan benar tanpa Android. Perjalanan pelanggan yang khas, yang melibatkan aspek lintas perangkat dan multi-sentuh, sangat penting bagi Privacy Sandbox di Chrome dan Privacy Sandbox di Android.	Perhatikan bahwa Privacy Sandbox di Android tidak termasuk dalam cakupan Komitmen Google kepada CMA. Jika masukan ini khusus untuk linimasa dan peluncuran Android, tidak ada update yang dapat kami sampaikan saat ini selain yang terus kami kembangkan di Android, yang kami anggap sebagai alur kerja independen untuk meningkatkan privasi. Seperti yang telah kami sampaikan sebelumnya, ketersediaan Privacy Sandbox API di Android juga akan ditentukan oleh frekuensi pengguna mengupdate perangkat mereka, yang tidak berada dalam kendali Google.
Traffic Mode B dibatasi	Traffic Lelang Iklan yang tersedia dari Mode B lebih rendah dari yang diharapkan.	Ada beberapa alasan volume lelang untuk Protected Audience API (PA API) bisa lebih rendah dari yang diharapkan, misalnya: - Perusahaan yang kami ketahui siapa yang mengintegrasikan PA API hanya menyertakan format banner. - Platform sisi jual mungkin tidak selalu memulai lelang. - Browser mungkin tidak memiliki Grup Minat (IG). - Mungkin tidak ada bid. Namun, kami tidak mengetahui siapa pun yang mencoba menguji PA API dan tidak menerima traffic.
Visibilitas pemadaman	Visibilitas ke pemadaman dan masalah yang memengaruhi Privacy Sandbox API.	Ada halaman status publik untuk Privacy Sandbox API yang memiliki layanan di luar browser. Tim Chrome menempatkan prioritas tertinggi pada keandalan platform kami dan semua API penting yang digunakan oleh situs dan layanan utama di seluruh web, termasuk teknologi Privacy Sandbox. Sejauh ini hanya ada satu pemadaman layanan. Hal ini terkait dengan konfigurasi sementara untuk pengujian pada 1%. Konfigurasi eksperimental yang terlibat dalam pemadaman ini tidak akan diperlukan lagi dalam waktu dekat, sehingga kami yakin masalah ini tidak akan terjadi setelah API diaktifkan dengan cara normal di Chrome.
Studi Grafik Cookie	Apa perspektif Chrome tentang metode CookieGraph seperti yang dijelaskan dalam makalah ini dalam framework Privacy Sandbox?	Makalah ini mengangkat beberapa poin menarik seputar deteksi dan prevalensi cookie pihak pertama (pihak 1) yang ditetapkan oleh domain yang berbeda dengan domain yang dikunjungi pengguna. Seperti yang ditunjukkan makalah, {i>cookie<i} ini sangat berguna untuk mengumpulkan analitik dan informasi tentang bagaimana pengguna berinteraksi dengan situs web. Data ini penting bagi developer untuk memberikan pengalaman penjelajahan yang lebih baik kepada pengguna. Argumen utama makalah ini salah karena menganggap cookie pihak pertama sebagai vektor pelacakan lintas situs. Namun, hal ini hanya berlaku berdasarkan asumsi yang sangat agresif yang diuraikan dalam makalah: Pengguna bersedia membagikan PII mereka ke situs. Perangkat memiliki sidik jari yang stabil yang dapat digunakan untuk melacak pengguna di berbagai situs. Perhatikan bahwa ini adalah vektor re-identifikasi yang dapat dieksploitasi tanpa menggunakan cookie pihak pertama (misalnya, melalui berbagi data sisi server), dan perlu ditangani secara terpisah dari upaya kami saat ini yang berfokus pada mekanisme pelacakan berbasis status seperti 3PC. Terakhir, kami ingin menunjukkan bahwa makalah tersebut menyamakan cookie analisis dan iklan dengan cookie pelacakan dan cookie yang benar-benar diperlukan sebagai cookie non-pelacakan yang mungkin tidak selalu demikian. Memang, analisis pihak pertama, atau layanan vendor yang dipartisi ke situs seperti widget pencari toko, widget chat, atau cookie load balancer sering kali terbatas hanya pada satu domain, dan sebaliknya, beberapa cookie yang sangat diperlukan mungkin merupakan pelacakan lintas situs untuk tujuan anti-penipuan.
Perubahan UX	Perubahan UX di Chrome 112 yang menempatkan kontrol cookie pihak pertama di bagian 'data situs di perangkat' pada setelan Chrome dapat mempersulit pengguna memblokir semua cookie.	Perubahan ini dilakukan sebagai bagian dari upaya untuk memisahkan dan meningkatkan kontrol untuk 3PC (atau penyimpanan yang tidak dipartisi) dari semua jenis data situs lainnya. Kontrol 3PC ditingkatkan di bawah panel Privasi & Keamanan; sementara kontrol untuk cookie pihak pertama dan semua jenis data situs lainnya - yang biasanya diandalkan oleh fungsi situs penting - digabungkan dalam "Data situs di perangkat". Kami akan terus memantau masukan tentang topik ini, tetapi kami yakin bahwa pemisahan yang saat ini dilakukan telah mencapai keseimbangan yang baik antara visibilitas kontrol privasi yang signifikan, dan menjaga pengalaman penjelajahan yang fungsional.
Penagihan dan Pembayaran	Penagihan dan pembayaran tidak diuji sepenuhnya karena penguji lebih berfokus pada pengujian area lain dari Privacy Sandbox API.	Kapan dan developer serta perusahaan mana yang memilih untuk diuji adalah pilihan mereka. API ini secara umum tersedia untuk pengujian dan sudah aktif sejak September 2023.
Pengujian	Tidak semua traffic eksperimental yang diterima DSP dari SSP diberi label. Beberapa DSP telah mengirimkan bahwa pangsa tayangan iklan eksperimental yang tidak berlabel mungkin berbeda di seluruh grup perlakuan dan kontrol.	Chrome tidak dapat mengontrol apakah perusahaan meneruskan label dalam permintaan bid. Kami menyediakan metode untuk mendapatkan label dari browser. Kemudian, ekosistem dapat meneruskan label ke partner jika partner mereka tidak dapat membaca label tersebut secara langsung.
3PCD di Android WebView	Minta panduan tentang cara mengaktifkan tanda "Test Third Party Cookie Phaseout" di Android WebView untuk menguji penghentian penggunaan.	3PC diblokir secara default di Android WebView.
Privasi Diferensial untuk mengurangi risiko dalam Pelatihan Model	Mengapa Privasi Diferensial digunakan dalam Pelatihan Model?	Privasi Diferensial, yang dikombinasikan dengan Trusted Execution Environment (TEE), sangat penting dalam pelatihan model untuk mencegah kebocoran data dan mengamankan informasi sensitif dari ancaman. Pendekatan ini memastikan bobot model tidak dapat mengungkapkan data pengguna individual.

Pendaftaran &Pengesahan

Tema Masukan	Ringkasan	Respons Chrome
Pendaftaran	Permintaan klarifikasi tentang cara kerja pendaftaran pengesahan antara asal yang terdaftar dan asal teknologi iklan dengan subdomain www.	Teknologi iklan hanya perlu melakukan aktivasi di https://example.com. Saat mereka menempatkan pengesahan di https://example.com/.well-known/privacy-sandbox-attestations.json, https://www.example.com akan tercakup karena merupakan subdomain.
Spesifikasi API	Saran untuk menambahkan skema JSON untuk file pengesahan ke repositori.	Kami sedang mengevaluasi saran ini dan menerima masukan tambahan di sini.

Tampilkan Konten &Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Pembobotan Topik	Hal terpenting yang harus dipahami dalam Topics adalah kelangkaan sinyal tertentu. Desain saat ini harus berkembang untuk memungkinkan penambahan nilai bobot di samping setiap topik yang diamati. Bobotnya adalah bobot relatif topik tertentu untuk browser dibandingkan dengan semua browser yang menggunakan topik tersebut.	Kita ingin lebih memahami mengapa kelangkaan sinyal adalah sinyal yang paling penting. Kami menerima masukan tambahan dari ekosistem tentang kegunaan kasus penggunaan ini di sini.
Keandalan Topik	Google perlu memberikan jaminan yang lebih kuat seputar keandalan Topics dari waktu ke waktu.	Perubahan pada API kami akan terus dilakukan berdasarkan masukan ekosistem dan akan dibahas secara publik sebelum perubahan tersebut dilakukan. Proposal kami untuk struktur tata kelola yang direvisi akan memberikan jaminan tambahan.
Pengklasifikasi	Situs penayang sering kali salah diklasifikasikan atau diberi Topik yang terlalu umum untuk tujuan yang bermakna.	Seperti yang dijelaskan dalam penjelasan tentang Klasifikasi topik, situs diklasifikasikan melalui kombinasi daftar penggantian yang diseleksi manusia, yang berisi situs paling populer, dan model machine learning di perangkat. Chrome terus mengevaluasi opsi bagi situs untuk berkontribusi pada Klasifikasi topik. Setiap peningkatan utilitas harus dipertimbangkan dengan risiko privasi dan penyalahgunaan. Misalnya, beberapa risikonya mencakup: - situs yang menggunakan pemberian label mandiri sebagai metode untuk mengenkode berbagai makna (dan berpotensi sensitif) ke dalam topik; dan - situs yang menyerang topik untuk mengurangi kegunaannya bagi orang lain (misalnya, mengirim spam ke topik pengguna dengan derau yang tidak berarti). Publik dapat memeriksa komponen ini, dengan alat yang tersedia melalui chrome://topics-internals atau colab ini. Melalui pengujian, kami berharap klasifikasi akan meningkat dari waktu ke waktu, dan kami menerima masukan tentang contoh situs yang mungkin salah dikategorikan.
Pertanyaan API	Kekhawatiran bahwa Topics API memberikan manfaat yang persisten dan anti-kompetitif kepada SSP yang memonetisasi konten buruk.	Seperti halnya 3PC, browser tidak peduli kepada siapa Topics ditampilkan, selama entitas tersebut terdaftar dan diautentikasi.
(Juga dilaporkan pada kuartal sebelumnya) Kegunaan untuk berbagai jenis pemangku kepentingan	Karena pengklasifikasi Topik saat ini hanya menggunakan nama host halaman untuk menentukan topik yang sesuai, situs besar dengan konten beragam berkontribusi pada topik umum, sedangkan situs kecil berkontribusi pada topik khusus dengan nilai iklan yang lebih tinggi.	Respons kami serupa dengan kuartal sebelumnya: Seperti 3PC, ada perbedaan nilai informasi yang dikontribusikan oleh situs yang berbeda. Kontribusi nilai situs minat khusus tidak konsisten: tidak semua situs minat khusus memiliki konteks yang bernilai secara komersial, sehingga memberikan kontribusi nilai yang lebih sedikit. Berikut adalah situs yang akan mendapatkan manfaat dari Topics API. Kami telah mempertimbangkan kemungkinan klasifikasi tingkat halaman daripada tingkat situs, tetapi ada sejumlah masalah privasi dan keamanan yang signifikan terkait klasifikasi tersebut.
Pengklasifikasi	Situs yang lebih kecil sering kali diberi klasifikasi yang tidak akurat atau tidak diberi klasifikasi sehingga tidak dapat berpartisipasi dalam pertukaran nilai.	Mengenai dugaan bahaya, situs tertentu yang berpotensi salah diklasifikasikan tidak lebih dirugikan oleh hal ini dibandingkan situs lain, mengingat bahwa informasi kontekstual situs akan selalu tersedia untuk lelang di situs mereka, yang akan memberikan informasi yang sebanding dengan topik yang benar, bahkan dalam kasus kesalahan klasifikasi. Topik biasanya digunakan untuk mengumpulkan informasi iklan yang mungkin bermanfaat dari situs eksternal, bukan situs mereka sendiri.
Versi Taksonomi	Bagaimana cara mengakses versi taksonomi untuk memastikan kompatibilitas mundur?	Versi taksonomi adalah bagian dari header permintaan yang dikirim dengan permintaan pengambilan yang mengaktifkan topik. Misalnya, jika headernya adalah "(1 2);v=chrome.1:2:5, ();p=P000000000", versinya adalah chrome.1:1:2. Dengan chrome.1 adalah versi konfigurasi, 2 adalah versi taksonomi, dan 5 adalah versi model. Hal ini dijelaskan dalam spesifikasi dan juga telah ditambahkan ke penjelasan.
Data Topik	Meminta klarifikasi tentang cara data Topik diperbarui.	Pembaruan taksonomi tidak ditentukan. Dengan begitu, vendor browser memiliki fleksibilitas dalam implementasi. Dengan demikian, berikut adalah heuristik update taksonomi Chrome dari V1 ke V2: - Satu hierarki taksonomi dipertahankan untuk topik dari V1 dan V2. - ID topik yang sama mewakili makna yang sama. - Hierarkinya hanya akan tumbuh – menambahkan topik atau koneksi baru, tanpa pernah menyusut. - Namun, beberapa topik atau link dapat "tidak aktif" dalam versi, yang dapat memberikan kesan penghapusan atau penyusunan ulang. Contoh: - "Truk Bak Terbuka" kini memiliki "Truk, Van, & SUV" sebagai induk perantara. - "Studi Bahasa Asing" kini memiliki "Pendidikan" sebagai orang tua kedua, dan "Referensi" induk aslinya menjadi tidak aktif. Dampak topik "tidak aktif": Topik ini tidak akan digunakan untuk klasifikasi baru. Namun, topik tersebut masih dipertimbangkan saat menerapkan pemblokiran pengguna: jika pengguna memblokir topik di V1, turunannya akan tetap diblokir di V2 (meskipun topik turunan muncul di bawah induk yang berbeda di V2).
Pengklasifikasi	Ingin memahami penyebab dan opsi perbaikan yang tersedia terkait klasifikasi yang salah.	Pertama, kami ingin menunjukkan bahwa penentuan topik situs oleh Chrome hanya digunakan sebagai masukan bagi algoritme Topiknya untuk menentukan minat pengguna untuk tujuan periklanan. Ini tidak dikembangkan untuk tujuan klasifikasi lain yang lebih umum. Kami tertarik dengan akurasi keseluruhan model klasifikasi kami, dan mencoba meningkatkan presisi/perolehannya jika memungkinkan, tetapi pada tingkat global, bukan pada tingkat klasifikasi situs individual. Hal ini karena kesalahan klasifikasi, jika terjadi, tidak membahayakan situs yang salah diklasifikasikan, melainkan mengurangi kualitas sinyal Topics saat memilih iklan di situs lain. Saat memilih iklan di situs yang salah diklasifikasikan, topik sebenarnya dari situs tersebut sudah diketahui oleh situs tersebut, dan dapat digunakan sebagai input untuk kueri iklan. Kami menerima masukan tambahan di sini.
Pengujian API	Apakah Topics dan secara umum Privacy Sandbox API dapat diuji dengan Chromium?	Topics API tidak dikirimkan dengan Chromium, tetapi dikirimkan dengan Chrome.
Topics Caller	Permintaan untuk meningkatkan nilai tambah Topics yang memanfaatkan layanan TEE untuk teknologi iklan guna mendukung biaya analisis lanjutan dengan cara yang mematuhi privasi.	Kami telah merespons masukan serupa di sini. Kami mempertimbangkan frekuensi terbalik, dan pada akhirnya setelah membuat model frekuensi terbalik, kami mendapati bahwa frekuensi terbalik tidak berkorelasi dengan baik dengan nilai topik sesuai dengan nilai yang diberikan oleh pembeli dan penjual. Kami menantikan masukan tambahan di sini.
Spesifikasi API	Dapatkah setelan kelompok minat browser memblokir Topics API?	Kami telah merespons masukan ini di sini. Topics API adalah evolusi dari FLoC, dan mematuhi kebijakan izin FLoC. Seperti yang dijelaskan dalam penjelasan: "Catatan: Permissions-Policy: interest-cohort=() lama dari FLoC juga akan melarang penghitungan topik."
Peringkat Topik	Saat mendapatkan '5 topik teratas', apakah kita akan menghitung frekuensi kunjungan situs berdasarkan setiap pemanggil yang memenuhi syarat, atau selalu menghitung berdasarkan seluruh histori kunjungan browser? Selain itu, apakah topik diberi peringkat lebih lanjut untuk setiap pemanggil secara terpisah?	Hal ini didasarkan pada frekuensi subkumpulan histori penjelajahan. Entri histori penjelajahan (halaman) hanya memenuhi syarat untuk berpartisipasi jika halaman memiliki setidaknya satu pemanggil Topics. Detail selengkapnya tentang penyimpanan histori topik tersedia di sini. Seperti yang dijelaskan dalam pengumuman kami tentang peningkatan pada Topics API, peringkat bergantung pada frekuensi, dan juga pada tingkat prioritas biner (lihat di sini dan di sini untuk detail selengkapnya). Namun, hal ini tidak bergantung pada frekuensi pemanggil. Perhatikan bahwa hal ini tidak berarti semua pemanggil dapat mendapatkan semua 5 topik teratas di epoch berikutnya. Seperti yang dijelaskan dalam penjelasan "Hanya penelepon yang mengamati pengguna yang mengunjungi situs tentang topik yang dimaksud dalam tiga minggu terakhir yang dapat menerima topik". Browser perlu melacak pemanggil mana yang mengamati 5 topik teratas (sesuai dengan 5 topik teratas dengan domain pemanggil di spesifikasi). Kami menerima masukan tambahan tentang masalah ini di sini.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Biaya	Lebih mahal untuk menjalankan TEE di cloud publik dibandingkan dengan pusat data teknologi iklan lokal?	Model keamanan TEE kami saat ini mendapatkan manfaat dari praktik implementasi cloud publik (lihat detail selengkapnya dalam penjelasan persyaratan TEE cloud publik). Misalnya, TEE berbasis hardware saat ini tidak dapat melindungi dari semua serangan fisik. Penyedia cloud publik kami yang didukung, AWS dan GCP, merancang dan menerapkan mitigasi untuk risiko akses fisik, termasuk dari karyawan. Meskipun beberapa teknologi iklan telah memberi tahu kami bahwa menjalankan layanan cloud lebih mahal daripada pusat data teknologi iklan di infrastruktur lokal, teknologi iklan lainnya berjalan di cloud publik, baik untuk biaya maupun manfaat lainnya. Kami terus mengevaluasi opsi untuk memperluas dukungan TEE, termasuk di luar cloud publik. Sebagai bagian dari upaya tersebut, kami sedang meneliti pusat data on-premise, dan berinteraksi dengan ekosistem untuk mempelajari potensi solusi dalam menawarkan dukungan tersebut. Pada tahap riset saat ini, kami tidak dapat menjamin bahwa hal ini akan menghasilkan solusi yang dapat diterapkan untuk ekosistem.
PA API & Google Ad Manager (GAM)	GAM tidak dapat mencapai hasil pasar yang adil. GAM gagal menayangkan iklan secara tepat waktu, melaporkan jumlah iklan yang ditayangkan menggunakan PA API, dan tidak menawarkan konfigurasi terkait metode yang akan dipilih untuk menayangkan iklan, misalnya dengan menonaktifkan PA API untuk slot tertentu.	Respons Google Ad Manager: GAM telah dan terus berupaya mengoptimalkan latensi saat menayangkan iklan melalui PA API sehingga peningkatan pendapatan penayang dari permintaan PA API lebih besar daripada biaya yang dikeluarkan karena latensi lelang PA API tambahan. Pengujian awal kami menunjukkan bahwa penayang memperoleh manfaat pendapatan bersih dari PA API untuk traffic tanpa 3PC, yang menunjukkan bahwa peningkatan permintaan dari PA API lebih besar daripada biaya yang timbul karena latensi. Detail selengkapnya tentang pendekatan kami dapat ditemukan di FAQ kami. Selain itu, GAM menyediakan pelaporan iklan yang ditayangkan melalui PA API kepada penayang. Hal ini mencakup iklan yang ditayangkan saat GAM adalah penjual komponen, dan iklan yang ditayangkan melalui penjual komponen lain saat GAM adalah penjual tingkat teratas. Detail selengkapnya tentang pelaporan dapat ditemukan di Pusat Bantuan kami. Terakhir, GAM memungkinkan penayang mengaktifkan atau menonaktifkan penggunaan PA API pada traffic mereka melalui kontrol dalam UI (lihat Pusat Bantuan kami untuk mengetahui detailnya). Kami terbuka untuk mempertimbangkan masukan tentang kontrol lebih lanjut yang mungkin diinginkan penayang dan akan memprioritaskan permintaan fitur apa pun sesuai dengan proses prioritas fitur standar kami.
PA API & GAM/AdX	Tampaknya Google telah mengambil posisi bahwa mereka tidak akan membeli tayangan PA API yang keputusan penjualan akhirnya tidak dibuat oleh GAM, sama seperti AdWords yang hanya membeli dari rumah. Hal ini tampaknya murni merupakan penyalahgunaan posisi pasar, karena GAM/AdX dapat mengirimkan konfigurasi lelang komponen ke penjual tingkat teratas alternatif seperti bursa lainnya.	Respons Pengelola Platform Google Ads: Itu bukan posisi Google. Platform sisi beli Google (Google Ads dan DV360) memang membeli tayangan dari bursa non-Google. Hal ini berlaku untuk tayangan PA API dan tayangan non-PA API.
Respons Pasar	Kekhawatiran Mozilla: Protected Audience Google Melindungi Pengiklan (dan Google) Lebih Daripada Melindungi Anda.	Kami menghargai penilaian Mozilla dan akan terus menanggapi masukan Mozilla di forum standar publik. Tema penilaian mereka adalah penerapan PA API saat ini belum menerapkan semua perlindungan yang direncanakan. Pendekatan go-to-market kami dengan PA API telah berupaya untuk mencapai keseimbangan yang tepat antara mendorong adopsi dan menerapkan perlindungan privasi sesegera mungkin. Sebagai bagian dari hal ini, kami telah menetapkan roadmap untuk menerapkan pembatasan privasi dari waktu ke waktu, guna memfasilitasi integrasi dengan API dengan lebih baik serta memberi kami waktu untuk mengumpulkan lebih banyak masukan yang dapat kami sertakan dalam perlindungan di masa mendatang (misalnya, fitur VAST di Bingkai Pagar). Kami juga menyambut baik komunikasi terbaru Mozilla tentang pendekatannya sendiri terhadap privasi dan iklan digital: "Internet yang bebas dan terbuka tidak boleh mengorbankan privasi" dan "Meningkatkan kualitas iklan online melalui produk dan infrastruktur".
(Juga dilaporkan di kuartal sebelumnya) Hasil Lelang	Meminta lelang tunggal untuk menampilkan beberapa URL render dengan skor yang sesuai, sehingga mempermudah iklan native untuk menghapus duplikat dan menghindari masalah UX dan latensi.	Respons kami serupa dengan kuartal sebelumnya: Membagikan beberapa renderURL, dan skornya masing-masing, dari satu lelang PA API adalah sesuatu yang kami pertimbangkan, tetapi tidak kami terapkan karena masalah privasi. Kami memahami keinginan untuk menghindari penayangan iklan yang sama beberapa kali kepada pengguna di satu halaman dan sedang mengevaluasi permintaan ini. Kami menantikan masukan tambahan dari ekosistem di sini tentang dukungan tambahan yang diperlukan di PA API untuk mendukung kasus penggunaan Iklan Native secara optimal.
Performa	Masalah terkait latensi yang memengaruhi PA API.	Kami telah mendengar kekhawatiran tentang latensi dan ini merupakan bagian dari alasan kami mengembangkan sejumlah fitur sebagai bagian dari PA API yang akan memungkinkan SSP untuk menetapkan batas latensi DSP serta melakukan peningkatan yang dapat mengurangi latensi. Baru-baru ini, kami memperbarui panduan praktik terbaik latensi yang menyertakan informasi lebih lanjut tentang cara memanfaatkan fitur ini. Kami juga terus mengembangkan peningkatan latensi baru, beberapa di antaranya dapat dilihat di sini.
Penjual tingkat teratas	Google seharusnya memungkinkan penayang memilih penjual lelang PA API tingkat teratas alternatif.	PA API tidak bergantung pada siapa yang memulai lelang baik dalam desain penjual tunggal maupun multi-penjual. Setiap perusahaan memiliki pilihan sendiri tentang apakah dan bagaimana mendukung lelang PA API.
(Juga dilaporkan pada kuartal sebelumnya) Penargetan Negatif	Meminta solusi untuk kasus penggunaan saat pengiklan tidak ingin menampilkan iklan kepada audiens tertentu.	Kami mendukung penargetan IG negatif melalui bid tambahan (kontekstual), yang memenuhi kebutuhan saat pengiklan tidak ingin menampilkan iklan kepada audiens tertentu. Detailnya dapat ditemukan di penjelasan ini dan masalah GitHub ini. Kami juga sedang mempelajari solusi untuk mendukung penargetan IG negatif untuk bid PA API, dan menerima masukan tambahan di sini.
(Juga dilaporkan pada kuartal sebelumnya) Iklan Native	Meminta dukungan Frame Pagar untuk Iklan Native.	Kami mempertimbangkan untuk mendukung kasus penggunaan ini dan sedang mendiskusikan kemungkinan solusi dan solusi di sini.
WebView	Mencari klarifikasi tentang skenario saat IG bergabung di Chrome tidak tersedia untuk Lelang yang dijalankan di WebView.	Kami ingin mendukung kasus penggunaan ini setelah infrastruktur privasi yang memadai tersedia. Untuk saat ini, kami tidak memiliki pengumuman lebih lanjut, tetapi kami menerima masukan tambahan di sini.
IG Negatif	Permintaan untuk memproses updateURL guna mendukung IG negatif melalui fitur header yang baru.	Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan di sini.
Pemfilteran Keberagaman	Meminta panduan tentang cara menerapkan pemfilteran keberagaman saat menjalankan iklan native di PA API dengan multi-penjual dan multi-lelang.	Kami sedang membahas permintaan ini di sini dan menerima masukan tambahan.
(Juga dilaporkan pada kuartal sebelumnya) Filter Pemblokiran	Meminta panduan tentang cara menerapkan aturan 'pemblokiran penayang' (filter) saat menjalankan iklan native di PA API dengan multi-penjual.	Kami telah membagikan panduan di sini dan menantikan masukan tambahan.
Pembatasan	Permintaan untuk mengizinkan pembatasan di tingkat domain, bukan di tingkat subdomain.	Pembatasan di tingkat subdomain atau origin mengikuti model keamanan dasar web, sehingga desain default kami adalah pembatasan tersebut. Kami telah membahasnya secara lebih mendetail di sini dan di sini.
Bidding Tepercaya	Permintaan agen pengguna dan petunjuk klien terkait dalam permintaan sinyal bidding tepercaya.	Kami memantau permintaan fitur ini dan menerima masukan tambahan di sini.
(Juga dilaporkan pada kuartal sebelumnya) Beberapa IG	Gunakan beberapa IG dalam bid yang sama.	Hal ini tidak didukung di PA API saat ini, karena akan mengakibatkan perubahan pada model privasi yang mendasarinya. Kami menerima diskusi tambahan di sini.
(Juga dilaporkan di kuartal sebelumnya) Performa	Memindahkan lebih banyak logika ke klien dapat mengganggu performa halaman dan UX, yang berpotensi mengganggu skor SEO situs.	Kami sedang membahas masalah ini dan menerima masukan tambahan di sini.
Dinamika Lelang	PA API mengurangi informasi tentang dinamika lelang (misalnya, siapa yang berpartisipasi, siapa yang memenangkan setiap komponen yang dilelang, dll.) yang mengurangi ketertelusurannya dan mempersulit untuk mengetahui apakah kesepakatan tetap berlaku.	Kami mengusulkan solusi untuk pelacakan transaksi di sini. Kami berencana untuk mengubah beberapa kolom yang ada dan membuat beberapa kolom baru dalam objek IG untuk menyimpan DealID dan SeatID, serta mengizinkan kolom tersebut di-propagate dari generateBid ke scoreAd atau egress melalui pelaporan tingkat peristiwa. Hal ini akan memberikan dukungan yang memadai untuk kasus penggunaan transaksi. Kami menerima masukan tentang metadata lain yang dianggap penting oleh teknologi iklan untuk dinamika lelang dan untuk terus memiliki pelacakan ini bagi penayang. Sebaiknya teknologi iklan memberikan contoh spesifik metadata yang mereka maksud dan dari pihak mana ke pihak mana metadata tersebut harus mengalir.
GAM	Khawatir tentang persyaratan untuk menggunakan GAM sebagai server iklan penayang agar dapat mengakses permintaan AdX.	Respons yang diberikan oleh Google Ad Manager: GAM tidak mewajibkan penayang menggunakan fungsi server iklannya untuk mengakses fungsi bursanya.
(Juga dilaporkan di kuartal sebelumnya) Lelang Komponen	Pemenang lelang komponen PA API akan terlihat oleh GAM, yang meningkatkan kekhawatiran tentang ketidaksetaraan akses ke informasi.	Respons kami tetap tidak berubah dari kuartal sebelumnya: Respons yang diberikan oleh Google Ad Manager: "Kami telah mempertahankan fokus yang kuat pada keadilan lelang selama bertahun-tahun, termasuk janji kami bahwa tidak ada harga dari sumber iklan tanpa jaminan penayang, termasuk harga item baris tanpa jaminan, yang akan dibagikan kepada pembeli lain sebelum mereka mengajukan bid dalam lelang, yang kemudian kami tegaskan kembali dalam komitmen kami kepada French Competition Authority. Untuk lelang PA API, kami bermaksud menepati janji kami dan tidak membagikan bid peserta lelang kepada peserta lelang lainnya sebelum lelang selesai di lelang multi-penjual. Untuk memperjelas, kami tidak akan membagikan harga lelang kontekstual dengan lelang komponen apa pun, termasuk lelang kami sendiri, seperti yang dijelaskan dalam pembaruan ini. Selain itu, kami tidak menggunakan informasi tentang konfigurasi lelang komponen, termasuk sinyal yang diberikan oleh pembeli ke SSP, sebagai bagian dari lelang kami sendiri. Bahkan, kami akan menyambut perubahan pada PA API yang memungkinkan penjual komponen menentukan konfigurasi lelang komponen mereka dengan cara yang di-obfuscate dari penjual tingkat teratas."
GAM	Apakah GAM akan meminta pembagian keuntungan untuk menjalankan/melaporkan lelang tingkat teratas jika GAM belum berpartisipasi dalam pembuatan lelang komponen IG atau PA API?	Respons yang diberikan oleh Google Ad Manager: Saat penayang memilih untuk menggunakan GAM sebagai server iklan mereka, GAM akan menjalankan lelang tingkat teratas dan mengenakan biaya penayangan iklan untuk fungsi server iklannya (biaya penayangan iklan yang sama dengan yang berlaku di luar lelang PA API). Namun, jika iklan pemenang berasal dari penjual komponen non-GAM - yang berarti GAM belum berpartisipasi dalam pembuatan lelang komponen IG atau PA API - GAM tidak menangani penagihan dan tidak mengenakan biaya media persen.
Klik	Apakah pendaftaran peristiwa klik tunduk pada privasi diferensial yang sama?	Fitur ini saat ini tidak direncanakan untuk tunduk pada pembatasan "k-anon", karena "jumlah klik" hanya akan tersedia sebagai browserSignal di dalam fungsi generateBid(); fitur ini tidak tersedia sebagai atribut baru dalam pelaporan tingkat peristiwa.
Performa	Biaya traffic keluar yang tinggi karena respons tanpa syarat terhadap permintaan bid kontekstual.	Kami tidak dapat langsung memberikan informasi tentang DSP mana yang memiliki IG karena alasan privasi. Namun, kami sedang mempelajari solusi alternatif yang dapat memberikan insight sekaligus menjaga privasi.
Iklan Native & Outstream	Meminta info terbaru tentang perspektif Chrome terkait iklan native & outstream.	Posisi Chrome bergantung pada kasus penggunaan yang dimaksud. Di Video, posisi Chrome adalah mendorong ekosistem untuk bertemu dalam solusi Video in-stream yang tepat menggunakan API kami. Sejauh ini, satu-satunya proposal konkret yang kami ketahui adalah proposal GAM. Di Native, kami secara aktif mengumpulkan masukan di sini dan berencana untuk segera melibatkan teknologi iklan dengan lebih banyak langkah penemuan.
Pemantauan Real-Time (RTM)	Traffic yang diberi label tidak mengirim laporan RTM.	Kami menyadari kesenjangan ini dan berupaya untuk memberikan solusi. Kami akan membagikan info terbaru jika tersedia di sini.
Dukungan Ekstensi Audiens	Permintaan update tentang dukungan untuk ekstensi audiens/audiens yang diseleksi penjual di PA API.	Kami sedang berupaya untuk memberikan solusi untuk kasus penggunaan ini. Kami mengumpulkan masukan dari ekosistem tentang hal yang harus kami bangun dan dukung. Kami akan membagikan info terbaru jika tersedia dan kami menerima masukan tambahan di sini.
Proses Debug	Di alat developer Chrome, tidak ada panel untuk memantau performa mendetail PA API. Misalnya, performa keseluruhan mungkin terpengaruh oleh jumlah IG atau jumlah pembeli.	Meskipun masukan spesifik ini berkaitan dengan kemampuan UI Alat Developer Chrome untuk membantu pemantauan, pada 7 Oktober kami memperkenalkan kemampuan bagi teknologi iklan untuk mengonfigurasi peristiwa kustom yang dapat digunakan sebagai dasar untuk pemantauan dan pemberitahuan. Detail selengkapnya tersedia di sini dan kami harap pembaruan ini dapat mengatasi sebagian besar masukan ini. Kami siap menerima masukan lebih lanjut tentang fitur ini, baik terkait titik data yang didukung maupun pengalaman developer dalam diskusi GitHub yang sesuai di sini.
Sinyal	Kekhawatiran terkait apakah DSP dapat memastikan perBuyerSignals dikirim ke SSP terlepas dari hasil lelang kontekstual atau tidak.	Lelang kontekstual diasumsikan hanya memiliki satu bid pemenang dari satu DSP, atau lebih tepatnya satu bid yang akan dicoba dikalahkan dengan lelang PA API berikutnya. Untuk alur PA API, SSP memutuskan untuk mengundang setiap dan semua DSP yang ingin mereka lihat apakah mereka memiliki permintaan (dalam bentuk IG di perangkat) untuk dikirimkan. DSP yang kalah dalam lelang kontekstual dapat "diundang kembali" untuk berpartisipasi dalam lelang PA API. Dalam "undangan ulang" ini, jika memutuskan untuk menerima, DSP akan meneruskan ke SSP sinyal apa pun yang ingin dipertimbangkan oleh Verifikator Iklan, jika ada, untuk kampanye tersebut. Dengan kata lain, dalam lelang PA API, selalu ada cara bagi DSP untuk mengirimkan perBuyerSignals ke SSP, terlepas dari apa yang terjadi dalam lelang kontekstual.
Sinyal	Permintaan untuk menambahkan prevClicks ke objek browserSignals yang diteruskan ke generatedBid().	Permintaan ini dapat diatasi dengan proposal kami untuk mendukung sinyal klik. Kami mengumumkan fitur ini di postingan blog terbaru kami dan penjelasan terkait. Kami menerima masukan tambahan tentang proposal ini di sini.
(Juga dilaporkan pada kuartal sebelumnya) Sinyal Pemodelan	Meminta untuk meningkatkan jumlah bit sinyal pemodelan dari 12 bit menjadi 30 bit.	Kami telah merespons masukan ini dengan proposal tandingan di sini. Kami secara aktif berinteraksi dengan industri untuk memahami pandangan mereka tentang proposal kami, dan saat ini sedang mempertimbangkan manfaat bagi industri dibandingkan dampaknya terhadap pengguna Chrome dan pemangku kepentingan lainnya.
Dokumentasi	Minta panduan tentang cara menggunakan Server Kunci/Nilai (K/V) dan TEE.	Panduan tentang penggunaan TEE dalam konteks K/V tersedia di detail desain model kepercayaan layanan K/V di sini.
Masa aktif IG negatif	Meminta perpanjangan masa pakai IG negatif menjadi 365 hari.	IG negatif digunakan untuk mencegah iklan ditampilkan, tetapi pihak tidak bertanggung jawab masih dapat menggunakannya untuk mengungkapkan informasi tentang pengguna, sehingga menimbulkan risiko re-identifikasi (misalnya, salah satu cara pihak tidak bertanggung jawab untuk menyerang adalah dengan menempatkan bid tinggi yang berisi IG negatif berulang kali untuk mengetahui apakah pengguna telah atau belum mengunjungi situs tertentu). Jika kita mempertahankan TTL selama 365 hari, pihak tidak bertanggung jawab akan memiliki lebih banyak data terkait IG negatif, yang mengakibatkan risiko privasi yang jauh lebih besar. Oleh karena itu, kami tidak dapat mendukung permintaan ini untuk melindungi privasi pengguna.
Spesifikasi API	Apa yang dapat disisipkan sebagai nilai yang akan diteruskan sebagai bagian dari perBuyerSignals? Dapatkah hal ini ditentukan secara sewenang-wenang oleh penjual?	perBuyerSignals adalah tempat bagi penjual untuk memberikan informasi apa pun yang ingin mereka sediakan kepada pembeli di dalam lelang. Ekosistem dapat memutuskan apa yang ingin dimasukkan ke sana, tetapi kami menerima diskusi tambahan di sini.
Penggantian Makro Ukuran Iklan	Mencari panduan terkait penggantian makro ukuran iklan yang tidak berfungsi.	Kami akan segera membagikan detail selengkapnya secara publik.
Penggantian Makro SSP Pasca-Bid: Spoofing URL Level Teratas	Mekanisme apa yang dapat diperkenalkan Chrome untuk memungkinkan vendor verifikasi memverifikasi URL tingkat teratas dalam framework Privacy Sandbox? Apakah ada titik data atau sinyal alternatif yang dapat digunakan dalam Frame Pagar untuk memastikan akurasi URL tingkat teratas yang disediakan SSP?	Saat ini kami sedang membahas masukan tambahan yang disambut baik ini di sini.
Permintaan Fitur	Permintaan untuk memberikan UACH entropi rendah pada pengambilan updateURL dan pada postback Pelaporan Real-Time.	Permintaan ini sedang dibahas di sini, dan kami menerima masukan tambahan di sini dan di sini.
Permintaan Fitur	Meminta agar desain proses debug yang diizinkan server tepercaya diaktifkan saat klien tertentu telah dipicu untuk mengirim laporan tingkat peristiwa forDebuggingOnly yang didownsample melalui forDebuggingOnly.reportAdAuctionWin() dan forDebuggingOnly.reportAdAuctionLoss().	Ini adalah permintaan aktif yang saat ini kami lacak dan akan memberikan pembaruan pada ekosistem jika tersedia. Kami menerima masukan tambahan di sini.
Penggunaan API	Minta panduan tentang cara menghitung jangkauan pengguna unik dan jangkauan tayangan.	Kami sedang membahas proposal untuk membahas cara membaca IG dari dalam worklet penyimpanan bersama, yang kemudian dapat Anda gunakan untuk mengirim laporan gabungan pribadi. Detail selengkapnya tersedia di sini dan kami mengharapkan masukan tentang proposal dan kegunaannya bagi ekosistem.
Penggunaan API	Kurangnya kejelasan tentang apa yang harus diuji penayang, API mana yang penting, API mana yang harus diaktifkan, dan apa yang akan datang.	Kami sedang berupaya untuk lebih mendukung penayang dan peran mereka dalam ekosistem.
Penggunaan API	Apakah pemroses peristiwa dapat ditambahkan ke peristiwa Worklet Lelang Iklan?	Hal ini tidak dapat dilakukan melalui peristiwa normal, tetapi peristiwa Chrome Devtools Protocol akan menangani kasus penggunaan ini sebagian. Perhatikan bahwa peristiwa reguler kemungkinan akan memengaruhi properti isolasi/privasi, tetapi detailnya tersedia di sini.
K-Anonymity	Meminta klarifikasi tentang persyaratan rendering iklan (misalnya, setidaknya 50 orang akan melihat iklan, jika iklan diizinkan untuk ditampilkan).	Dokumentasi developer memberikan ringkasan ekspektasi kami untuk pengembangan di masa mendatang. Secara khusus, dokumen ini menjelaskan bahwa nilai minimum k-anonymity awal adalah k=10 orang. Milis blink-dev memberikan info terbaru tentang hal-hal yang terjadi secara live di Chrome. Seperti yang dijelaskan dalam thread milis k-anonymity, saat ini kami menerapkan persyaratan k-anonymity secara eksperimental pada sekitar 1% traffic stabil Chrome, dan tidak pernah menerapkannya pada slice yang diberi label secara eksplisit ("Mode A" dan "Mode B").
Percikan	Dapatkah chaffing K/V TEE dihapus atau dikurangi untuk sementara dari harus memanggil semua shard N, menjadi jumlah tertentu yang menyeimbangkan perlindungan privasi dengan utilitas (yaitu, K/V performa/biaya)?	Jenis permintaan ini hanya ditangani untuk instance non-produksi tempat chaffing dapat dikontrol. Untuk instance produksi, chaffing masih diperlukan. Kami dapat mengevaluasi situasi setelah menerima masukan dari penggunaan non-produksi.
Percikan	Permintaan untuk menambahkan flag guna menonaktifkan chaffing dari biner K/V debug/non-prod.	Flag ini disediakan dengan rilis 1.0.0.
Bug API	API berhenti berfungsi setelah mengupgrade ke Chrome 126, meskipun API diaktifkan di setelan.	Masalah ini ditemukan terkait dengan tanda Chrome "enable-fenced-frames", yang diaktifkan oleh pengguna untuk tujuan pengembangan. Mereset tanda ini ke default akan menyelesaikan masalah.
Pelaporan	Permintaan untuk membuat keikutsertaan reporting API real-time tidak bergantung pada penjual untuk pembeli.	Permintaan ini dipertimbangkan di sini. Solusi RTM baru-baru ini dirilis dan kami menerima masukan, terutama dari teknologi iklan yang telah diaktifkan untuk fitur ini.
Pelaporan	Meminta pelaporan pihak ketiga; meskipun DSP dan SSP menerima notifikasi tayangan dari Chrome, penyedia teknis lapisan menengah secara default tidak menerima notifikasi tayangan iklan.	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.

Layanan Protected Auction

Tema Masukan	Ringkasan	Respons Chrome
TEEs	Persyaratan Google untuk orientasi manual berdasarkan standar teknis merupakan batasan yang kuat pada pilihan vendor cloud. Standar teknis yang diterapkan dapat diikuti tanpa mengunjungi Bureau of Cloud Providers seperti yang tampaknya diinginkan Google. Keterlambatan penyedia alternatif pada tahun 2025 (paling awal) tidak dapat diterima karena akan menimbulkan efek jaringan yang mendorong pemberian tip ke solusi Google.	Layanan Agregasi adalah satu-satunya layanan yang diperlukan untuk berjalan di layanan TEE guna menangani beberapa kasus penggunaan teknologi iklan. Layanan Agregasi mendukung Amazon Web Services (AWS) dan Google Cloud Platform (GCP). Berdasarkan masukan dari teknologi iklan, kami yakin dukungan tersebut sudah memadai pada tahap ini. Pada penyedia cloud tambahan - Google memublikasikan kriteria mendetail untuk TEE di Penyedia Cloud Publik. Hal ini bertujuan untuk memastikan bahwa solusi TEE memenuhi tujuan privasi dan keamanan Privacy Sandbox. Secara khusus, server TEE Privacy Sandbox memproses data pengguna lintas situs yang tidak dienkripsi (misalnya, data dari situs penayang dan pengiklan untuk Layanan Agregasi). API ini harus aman untuk memenuhi sasaran privasi pengguna API. Lingkungan yang aman juga diperlukan untuk memastikan API terus melindungi informasi bisnis rahasia perusahaan (misalnya, mencegah peserta lelang PA API lainnya mengakses data bisnis eksklusif pembeli). Sejauh yang kami ketahui, saat ini tidak ada teknologi TEE yang sepenuhnya melindungi data pengguna dari operator yang berpotensi menjadi lawan. Oleh karena itu, kami menyertakan beberapa persyaratan untuk memvalidasi kepercayaan penyedia cloud. Kami tidak yakin apa yang dimaksud dengan "Bureau of Cloud Providers", dan hal ini bukan bagian dari persyaratan. Kami menerima masukan apa pun tentang persyaratan ini. Kami juga terus mengevaluasi dukungan untuk penyedia baru, termasuk berdasarkan permintaan untuk dikirimkan menggunakan proses yang ditentukan dalam penjelasan. Sejauh ini, kami hanya menerima permintaan untuk mendukung Azure, yang sedang kami evaluasi.
B&A	Sulit untuk menilai kompleksitas teknis dan kelayakan layanan B&A karena desainnya terus berkembang.	Untuk mengatasi masalah ini, kami telah menyediakan penjelasan mendetail di GitHub yang menjelaskan desain B&A, linimasa ketersediaan yang dipublikasikan, dan roadmap fitur yang mendukung PA API. Kami mendukung teknologi iklan yang ingin men-deploy B&A dan mengumpulkan masukan dari ekosistem di GitHub.
B&A	Mencari panduan dan cara yang lebih baik untuk menghitung biaya penggunaan TEE untuk B&A agar dapat mulai menggunakannya atau bermigrasi untuk menggunakannya dari perangkat.	Baru-baru ini kami memublikasikan Panduan Pengukuran Instance Server K/V, yang mencakup alat untuk mengukur biaya secara lebih akurat.
Server K/V	Pengverifikasi iklan meminta agar dapat menggunakan URL halaman lengkap ke server K/V untuk melakukan verifikasi iklan.	Saat ini kami sedang mengevaluasi kemungkinan menyediakan URL halaman lengkap ke server K/V yang berjalan di TEE untuk tujuan verifikasi iklan. URL halaman penuh tidak akan tersedia di K/V BYOS.
Keamanan Lelang	Mencari fitur keamanan lelang untuk memastikan pelaku kejahatan tidak mengakses data sensitif atau bertindak sebagai peniru identitas - fitur mana yang melindungi lelang dari serangan replay dan bagaimana pengamanan keamanan dapat diterapkan?	Model keamanan B&A saat ini dapat melindungi integritas lelang. B&A berjalan di TEE yang melindungi kerahasiaan sinyal dan kode teknologi iklan dari pihak yang berniat jahat. Dalam arsitektur B&A, payload permintaan B&A terenkripsi (ciphertext permintaan) mengalir dari klien melalui server iklan tidak tepercaya ke layanan SellerFrontEnd (SFE, dijalankan oleh SSP di TEE). Ciphertext permintaan berisi ID pembuatan berbasis stempel waktu. SFE akan memeriksa stempel waktu permintaan dan menolak permintaan yang diputar ulang yang tidak dalam +/- n detik dari waktu server. Selain itu, B&A dapat menampilkan payload respons ukuran tetap yang ditambahkan untuk komunikasi server ke server. Solusi ini dapat membantu mengurangi serangan replay melalui sistem saat pelaku berbahaya mencoba memutar ulang payload permintaan yang sama untuk mempelajari kontennya lebih lanjut. B&A sedang dalam proses mendokumentasikan dan memperbarui model keamanan dalam penjelasan.
Sinyal melalui Server K/V	Permintaan untuk menyertakan perBuyerSignals yang dikirim melalui layanan K/V sebagai bagian dari permintaan sinyal bidding tepercaya dari Chrome.	Kami sedang mengevaluasi kelayakan untuk menyertakan informasi dari perBuyerSignals, yang ditransfer ke server K/V yang berjalan di TEE, termasuk URL halaman lengkap.
Server K/V	Meminta linimasa penerapan yang lebih bertahap untuk batasan privasi di K/V dan B&A.	Kami memahami keinginan Anda untuk pendekatan yang lebih bertahap dalam mengadopsi TKV dan menghargai permintaan spesifik Anda terkait K/V dan B&A. Namun, setelah melakukan evaluasi yang cermat, kami memutuskan untuk tidak melonggarkan perlindungan privasi di API ini untuk saat ini. Kami yakin bahwa langkah-langkah ini, seperti chaffing, sangat penting untuk menjaga privasi pengguna dan mempertahankan kepercayaan pada Privacy Sandbox.
Server K/V	Mencari panduan tentang cara menskalakan penyimpanan K/V melalui konfigurasi yang kompatibel.	Panduan Ukuran Instance Server K/V yang baru-baru ini dipublikasikan dapat membantu mengatasi masalah ini. Alat ini akan memberikan QPS (disebut sebagai "RPS" dalam penjelasan) pada setiap kombinasi parameter.
Server K/V	Tambahkan Informasi Penjual pada permintaan Server K/V.	Kami sedang membahasnya dan menerima masukan tambahan di sini.
Layanan K/V + B&A	Meminta klarifikasi linimasa rilis atau roadmap untuk K/V dan B&A.	Untuk K/V dan B&A, kami memiliki tahapan dan linimasa: Untuk Server K/V bersama dengan lelang PA API di perangkat (vs B&A), linimasa publik tersedia di sini. Terkait cara "Ketersediaan Umum" ditentukan untuk K/V, lihat bagian Roadmap yang menentukan kumpulan fitur untuk Beta dan GA. Untuk B&A, lihat linimasa publik di sini dan roadmap di sini. Kami mendefinisikan Pengujian Skala sebagai "pengujian skala produksi yang stabil sepenuhnya" -- lihat di sini untuk kumpulan fitur tertentu pada tahap ini. B&A juga memiliki tahap Alfa dan Beta, sehingga Pengujian Skala akan menyertakan superset fitur dari tahap sebelumnya. Untuk K/V dan B&A, beri tahu kami jika definisi tahap ini membantu memberikan kejelasan mengenai waktu yang tersedia. Jika masih ada kekurangan, harap beri tahu kami. Kami akan dengan senang hati membuat informasi ini lebih spesifik untuk membantu perencanaan.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Respons Pasar	Persyaratan bagi sistem atribusi pesaing untuk hanya menggunakan pelaporan tingkat peristiwa dan pelaporan ringkasan/agregat dalam batas yang ketat adalah pembatasan persaingan yang sewenang-wenang. Tindakan ini mencegah atribusi dan penargetan ulang khusus perangkat secara real time di tingkat peristiwa, meskipun pengamanan telah diterapkan untuk memastikan kepatuhan perlindungan data (mis. de-identifikasi).	Desain yang disebutkan didasarkan pada sasaran privasi API - misalnya, melindungi informasi lintas situs yang diteruskan dari satu situs ke situs lain. Misalnya, ARA mendukung atribusi tingkat peristiwa melalui laporan peristiwa. Laporan peristiwa tertunda minimal satu jam, yang diperlukan untuk mempersulit atribusi laporan tingkat peristiwa dengan identitas pengguna di situs pengiklan, menggunakan serangan saluran sisi waktu, seperti yang didokumentasikan di sini. Selain itu, ada cara lain untuk melakukan atribusi, selain ARA, seperti mengumpulkan informasi secara langsung dari pengguna yang dengan sengaja memberikan data identitas. Kami menerima masukan tentang kasus penggunaan yang tidak dapat dicapai dengan batas privasi Privacy Sandbox API saat ini.
Berbagai Permukaan	Minta konfirmasi apakah ARA dan Shared Storage API mendukung kasus penggunaan multi-platform atau tidak dan buktinya.	Saat ini, ARA dan Penyimpanan Bersama tidak mendukung atribusi multi-platform (lintas perangkat). Atribusi lintas aplikasi dan web di perangkat yang sama (melalui ARA) didukung.
(Juga dilaporkan pada kuartal sebelumnya) Lintas Perangkat	Apakah ARA mendukung konversi lintas-perangkat?	Respons kami serupa dengan kuartal sebelumnya: Lintas perangkat menghadirkan tantangan privasi baru di atas 3PC dan juga menambah tantangan distribusi teknologi mengingat berbagai perangkat dan platform yang mungkin digunakan pengguna. Kami sedang mempelajari kemungkinan solusinya, tetapi kami berfokus pada kasus penggunaan penting yang saat ini didukung oleh ARA dan saat ini tidak memiliki jadwal untuk dukungan lintas perangkat.
Penskalaan	Kekhawatiran tentang apakah Attribution Report API (ARA) saat ini dikonfigurasi dan dapat diluncurkan serta diskalakan dengan andal untuk melayani semua pengguna Chrome.	ARA saat ini tersedia untuk semua pengguna Chrome dan berjalan seperti yang diharapkan. Selain itu, kami terus menguji dan memantau keandalan dan skalabilitasnya karena jumlah perusahaan teknologi iklan yang menguji ARA terus meningkat. Kami menerima masukan ekosistem tambahan terkait hal ini di sini.
(Juga dilaporkan di kuartal sebelumnya) Penghapusan duplikat	Kekhawatiran tentang cara ARA mengusulkan untuk membatasi mekanisme atribusi di perangkat sehingga penayang tidak dapat menjalankan logika pasca-atribusi secara efektif untuk laporan ringkasan, termasuk menghapus duplikat beberapa konversi jenis yang sama untuk klik iklan yang sama.	Respons kami tetap tidak berubah dari kuartal sebelumnya: Pembersihan duplikat di seluruh perangkat dan pipeline pengukuran adalah tantangan umum dan saat ini yang juga dihadapi teknologi iklan saat ini dengan 3PC. Dengan ARA, teknologi iklan dapat memutuskan kapan harus mendaftarkan konversi tertentu dan menambahkan metadata tertentu untuk menunjukkan pipeline pengukuran yang telah mereka gunakan untuk melacak konversi (yaitu bagian dari kunci agregasi), yang dapat dibandingkan dengan pipeline pengukuran lainnya. Kami menerima masukan ekosistem tambahan terkait hal ini di sini.
Pelacakan Konversi	Meminta kemampuan untuk beroperasi dengan konversi dari beberapa domain.	Kami sedang membahas permintaan ini di sini dan menerima masukan ekosistem tambahan.
Pelaporan	Browser menunggu setidaknya dua hari, tetapi hingga 30 hari, untuk mengirim konversi. Hal ini dapat menimbulkan kekhawatiran mengingat sebagian besar pengiklan pemangku kepentingan adalah pengiklan berbasis performa, yang bekerja hampir secara real-time.	Setelan default untuk laporan tingkat peristiwa memiliki periode pelaporan default berikut: 2 hari, 7 hari, dan 30 hari. Dengan pelaporan tingkat peristiwa yang fleksibel, teknologi iklan dapat mengubah jumlah dan durasi periode pelaporan dari nilai default. Periode pelaporan dapat diubah menjadi minimal 1 jam, yang dapat membantu kasus penggunaan pengiklan terkait performa. Kami menerima masukan ekosistem tambahan terkait hal ini di sini.
Atribusi Online ke Offline	Apakah akan ada opsi penerapan untuk iklan online ke offline di ARA, atau apakah ada saran lain untuk mengukur atribusi offline ke online?	Saat ini tidak ada rencana untuk mendukung kasus penggunaan pengukuran online ke offline di ARA. Ada tantangan privasi dan keamanan signifikan yang perlu dipertimbangkan untuk jenis dukungan ini. Kami siap menerima masukan ekosistem tambahan terkait kasus penggunaan untuk dukungan ini di sini.
Pelaporan Debug	Bagaimana cara menyimpan dan/atau mengambil ID iklan sedemikian rupa sehingga dapat diakses untuk pendaftaran Chrome (sumber/pemicu) untuk atribusi aplikasi ke web?	Untuk mengaktifkan laporan debug, teknologi iklan harus membuktikan kepada kami bahwa teknologi tersebut sudah dapat bergabung dengan pengguna di seluruh aplikasi dan web, dan hal ini dilakukan untuk memastikan tidak ada informasi baru yang diungkapkan oleh laporan debug. Teknologi iklan dapat membuktikan penggabungan dengan memberikan kunci join yang unik per pengguna. Kunci join ini dapat berupa ID Iklan atau kunci join pihak pertama. Jika teknologi iklan menggunakan ID Iklan, Chrome tidak mendukung secara native akses ke ID Iklan dari browser dan API mengharapkan setiap teknologi iklan memiliki metodenya sendiri untuk meneruskan ID Iklan selama pendaftaran web.
Perincian Bucket	Apakah saya dapat menggunakan strategi bucket yang berbeda per pengiklan?	Sebaiknya lakukan eksperimen dengan berbagai pendekatan penskalaan anggaran kontribusi untuk menemukan pendekatan yang paling sesuai dengan kasus penggunaan Anda. ARA dibuat dengan tujuan agar fleksibel dan dapat disesuaikan untuk memenuhi berbagai kasus penggunaan teknologi iklan. Oleh karena itu, sebaiknya bereksperimen dengan berbagai strategi pengelompokan per pengiklan atau per kategori. Menggunakan strategi pengelompokan yang berbeda dapat berguna jika pengiklan memiliki perbedaan nilai pengukuran yang ingin mereka lacak dan volume nilai pengukuran.
Dokumentasi	Meminta dokumentasi tambahan untuk menerapkan aplikasi<>web untuk ARA.	Kami telah merilis dokumentasi tentang Aplikasi<>Web untuk ARA di sini.
Performa	Jumlah permintaan terkait ARA berpotensi menjadi beban berat pada server penayang dibandingkan dengan jumlah permintaan keepalive yang diperlukan untuk mendukung situs tersebut. Mengelompokkan peristiwa sumber dalam satu permintaan dapat membantu mengurangi beban pada server. Salah satu ide potensial adalah mengizinkan array objek yang dienkode JSON	Pengelompokan peristiwa sumber berdasarkan logika tertentu dapat dilakukan hingga batas tertentu menggunakan logika JavaScript yang dikombinasikan dengan API. Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem di sini.
Permintaan Fitur	Saran untuk proposal solusi karena tidak ada dukungan integrasi server ke server.	Saat ini kami tidak berencana untuk menerapkan dukungan integrasi server ke server di ARA. Ada banyak tantangan privasi yang perlu dipertimbangkan lebih lanjut untuk memungkinkan integrasi server ke server yang mendukung. Kami menerima masukan dari ekosistem terkait kasus penggunaan tambahan untuk dukungan server ke server di sini.
Dokumentasi	Minta panduan "mulai cepat" yang menjelaskan bagian-bagian penting ARA/cara menyiapkan dan menjalankannya dengan beberapa kasus penggunaan sederhana.	Panduan memulai cepat untuk ARA tersedia di sini. Kami berupaya meningkatkan dokumentasi ini lebih lanjut tahun ini, dan menerima masukan tambahan tentang kasus penggunaan atau skenario tertentu yang memerlukan dokumentasi tambahan di sini.
Penggunaan API	Meminta rekomendasi tentang penskalaan kontribusi untuk banyak nilai kecil.	Sebaiknya lakukan eksperimen dengan berbagai pendekatan penskalaan anggaran kontribusi untuk menemukan pendekatan yang paling sesuai dengan kasus penggunaan Anda. Untuk skenario banyak nilai kecil, sebaiknya bereksperimen dengan berbagai nilai epsilon untuk mengidentifikasi titik belok tempat derau dari epsilon dapat diterima untuk kasus penggunaan Anda. Detail selengkapnya tersedia dalam makalah riset kami tentang Pengoptimalan laporan ringkasan di ARA.
Tingkat Peristiwa Fleksibel	Kapan Tingkat Peristiwa Fleksibel (beberapa spesifikasi pemicu) akan diterapkan?	Saat ini Tingkat Peristiwa Fleksibel mendukung penyesuaian aspek konfigurasi pendaftaran berikut: jumlah laporan yang dapat dibuat per sumber, jumlah dan panjang periode pelaporan, serta kardinalitas data pemicu. Saat ini kami sedang mengumpulkan masukan ekosistem tambahan terkait peningkatan tingkat peristiwa fleksibel tambahan, tetapi tidak berencana untuk menerapkannya saat ini. Kami menerima masukan tambahan tentang kasus penggunaan yang mungkin memanfaatkan beberapa peningkatan tingkat peristiwa fleksibel yang tercantum di sini.
Pemrosesan Bucket	Permintaan untuk mempertimbangkan pembatasan kontribusi gabungan untuk bucket serta ekstensi dan kompatibilitas mundur di masa mendatang.	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.
Epsilon	Apa yang terjadi pada rentang epsilon setelah ARA berubah menjadi ketersediaan umum?	ARA mencapai ketersediaan umum di Chrome pada Kuartal 3 2023. Saat ini, tidak ada rencana untuk mengubah periode nilai epsilon. Proposal kami untuk struktur tata kelola yang direvisi akan memberikan jaminan tambahan ketika ada perubahan yang dipertimbangkan.
Pelaporan	Laporan Trigger-unknown-error tidak berisi atribut sumber dalam isi laporan.	Seperti yang ditetapkan dalam spesifikasi, tidak ada persyaratan untuk kolom lain yang ada dalam isi laporan untuk trigger-unknown-error. Kami menyadari bahwa tabel yang menjelaskan kolom dalam isi laporan berpotensi menyesatkan, karena kolom terkait sumber mungkin ada atau tidak ada, bergantung pada penyebab utama error. Misalnya, error internal dapat terjadi sebelum logika pencocokan sumber terjadi, yang berarti tidak ada data sumber yang tersedia untuk mengisi laporan debug. Dokumentasi kini telah diperbarui untuk mengklarifikasi hal ini.
Penggunaan API	Saat bekerja dengan dua sasaran pengukuran, {i>COUNT<i} dan nilai, apakah indikasi untuk membagi anggaran kontribusi dan epsilon?	Saat menggunakan dua sasaran pengukuran, sebaiknya bagi anggaran kontribusi di antara keduanya.
Pelaporan	Apakah ARA mendukung atribusi multi-sentuh atau laporan bantuan (alias pelaporan kontribusi)?	ARA saat ini tidak mendukung pelaporan atribusi multi-sentuh atau bantuan. Saat ini kami tidak berencana untuk menerapkannya. Kami menerima masukan tambahan tentang kasus penggunaan dan prioritasnya di sini.
Bug API	Untuk ARA, dokumentasi menyatakan bahwa XOR digunakan untuk menggabungkan bagian kunci agregasi sumber dan pemicu, tetapi dalam praktiknya, OR digunakan. Perbedaan ini menyebabkan kebingungan dan potensi error dalam penerapan.	Dokumentasi telah diperbarui untuk menunjukkan bahwa ini adalah error.

Layanan Agregasi

Tema Masukan	Ringkasan	Respons Chrome
Tugas Agregasi	Permintaan untuk mengizinkan beberapa awalan dalam tugas agregasi.	Kami sedang menyelidiki masukan ini dan telah memposting proposal di sini. Kami menerima masukan tentang proposal ini di sini.
Permintaan Fitur	Permintaan untuk mengubah skrip terraform sehingga jika service_account_token_creator_list tidak ditetapkan (atau kosong), modifikasi kebijakan IAM akun akan dilewati.	Kami sedang menyelidiki masalah ini di sini dan menantikan masukan ekosistem tambahan.
Penggunaan API	Klarifikasi diperlukan terkait rencana Terraform yang selalu menampilkan perubahan.	Masalah ini telah diperbaiki dalam rilis AgS 2.8.
Penggunaan API	Mencari rekomendasi untuk menyiapkan setelan per pengiklan untuk frekuensi agregasi dengan pemfilteran kontribusi yang fleksibel.	Pengelompokan menurut pengiklan saat ini dapat dilakukan dengan ARA. Pemfilteran kontribusi yang fleksibel dapat digunakan untuk kasus yang lebih lanjut, yaitu saat teknologi iklan ingin mengelompokkan kontribusi laporan lebih lanjut berdasarkan frekuensi yang berbeda. Teknologi iklan dapat mempelajari lebih lanjut pengelompokan di sini dan menggunakan ID pemfilteran dengan ARA di sini. Kami juga sedang menyiapkan dokumentasi lainnya untuk memfilter ID.
Permintaan Fitur	Meminta dukungan untuk `log_sum_exp` di Layanan Agregasi (AgS).	Kami telah menghubungi pemangku kepentingan ini untuk mengetahui detail selengkapnya tentang kasus penggunaan. Kami akan memberikan kabar terbaru setelah kami memiliki detail selengkapnya.
Permintaan Fitur	Minta agar dapat melihat lebih banyak log/insight/metrik lainnya setiap kali ada masalah di AgS dan potensi masalah di AgS yang di-deploy.	Kami telah memublikasikan pembaruan pada dokumentasi kami untuk menyertakan lebih banyak error, mitigasi, dan deskripsi di sini. Kami menerima masukan tambahan tentang error/metrik/log, dll. yang tidak didokumentasikan atau tersedia dan detail yang akan berguna di sini.
Pengujian API	Berapa nilai akhir epsilon setelah periode pengujian?	Saat ini, tidak ada rencana untuk mengubah periode nilai epsilon. Sebaiknya penguji bereksperimen dengan parameter yang berbeda dan memberikan masukan.
Pelaporan	Laporan sedang dibuat, tetapi juga masih mendapatkan PRIVACY_BUDGET_AUTHORIZATION_ERROR dalam kode pengembalian.	Kami telah memberikan panduan tentang cara menentukan asal pelaporan dan laporan gabungan yang benar untuk menghindari error ini. Kami menerima masukan tambahan tentang masalah ini, terutama jika ada error berulang.
Penemuan Kunci	Apa rencana untuk proposal penemuan kunci?	Kami belum memiliki linimasa untuk peluncuran proposal penemuan kunci, tetapi kami meminta masukan dari ekosistem tentang proposal tersebut di sini.
Penyesuaian	Mencari opsi penyesuaian yang tersedia untuk Layanan Agregasi.	Penyesuaian Layanan Agregasi tidak dapat dilakukan dalam TEE, tetapi dapat dilakukan untuk beberapa komponen di luar TEE. Hal ini disebabkan oleh standar privasi dan keamanan yang perlu kami pertahankan dalam TEE. Kami sedang berupaya memperbarui dokumentasi untuk membantu teknologi iklan memahami arsitektur dan komponen yang dapat disesuaikan. Kami tidak dapat mendukung penyesuaian tertentu sehingga sebaiknya teknologi iklan menggunakan konfigurasi standar kami jika memungkinkan.
Instance Spot vs. On-Demand	Apakah sistem telah diuji menggunakan instance spot versus instance on-demand? Apakah ada kekurangan khusus dalam menggunakan instance spot, selain potensi ketidaktersediaan sementara?	Kami belum memprioritaskan pengujian di instance spot karena kami merekomendasikan teknologi iklan untuk menggunakan instance on-demand. Kelemahan instance spot adalah tugas akan terganggu selama penggunaan anggaran. Jika anggaran telah habis dan tugas terganggu sebelum teknologi iklan menerima laporan ringkasan, teknologi iklan tidak akan dapat mencoba kembali tugas tersebut, tetapi harus meminta pemulihan anggaran. Pemulihan anggaran hanya direkomendasikan untuk kegagalan besar guna menjaga privasi. Sebaiknya teknologi iklan mengonfigurasi penskalaan otomatis untuk membantu meminimalkan biaya. Memilih 0 untuk penskalaan otomatis berarti tidak akan ada instance yang berjalan hingga tugas diminta (perhatikan bahwa hal ini dapat meningkatkan latensi karena instance akan diaktifkan pada saat permintaan).
Error & Solusi Umum	Klarifikasi diperlukan terkait tugas Layanan Agregasi yang menampilkan "Service Error"	Masalah ini telah diselesaikan di sini. Kami juga telah memperbarui beberapa pesan error agar lebih deskriptif. Misalnya, kami mulai menampilkan error izin/autentikasi yang lebih spesifik di AWS daripada sebelumnya saat error ini muncul sebagai error internal. Kami telah memperbarui dokumentasi tentang kode error dan langkah-langkah mitigasi di sini dan menerima masukan tambahan tentang error yang tidak didokumentasikan atau tersedia serta detail apa yang akan berguna di sini.

Private Aggregation API

Tema Masukan	Ringkasan	Respons Chrome
Desain Kunci	Meminta panduan desain utama Agregasi Pribadi	Meskipun kami tidak memiliki panduan khusus Agregasi Pribadi, framework pengujian beban Layanan Agregasi dan Panduan pengelolaan kunci lanjutan dapat digunakan sebagai resource.
Anggaran Kontribusi	Pada tingkat apa anggaran kontribusi dihitung dan dibatasi?	Anggaran kontribusi adalah 2^16 dalam periode 10 menit bergulir dan 2^20 dalam periode 24 jam bergulir.

Membatasi Pelacakan Tersembunyi

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tidak ada masukan yang diterima kuartal ini.

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
Khusus perangkat Android	Apa rencana untuk meluncurkan Perlindungan IP ke Android?	Meskipun kami sedang mempelajari cara menghadirkan fitur anti-pelacakan tersembunyi ke Android, termasuk Perlindungan IP, kami belum memiliki rencana formal untuk disampaikan saat ini.
Penggunaan API	Pertanyaan tentang apakah ada atau akan ada pengecualian anti-penipuan untuk Perlindungan IP?	Kami berusaha mencapai keseimbangan antara melindungi pengguna agar tidak dilacak di seluruh web berdasarkan alamat IP mereka sekaligus meminimalkan gangguan pada pengoperasian normal server, termasuk penggunaan alamat IP untuk anti-penyalahgunaan. Meskipun saat ini kami tidak dapat memberikan detail selengkapnya, kami berharap dapat memberikannya dalam waktu dekat dan menantikan untuk melanjutkan diskusi.
Identifikasi Pelaku Tidak Bertanggung Jawab	Kekhawatiran terkait efektivitas langkah-langkah keamanan tradisional terhadap alamat IP berbahaya.	Perlindungan IP tidak akan mem-proxy permintaan pihak pertama, sehingga kami memperkirakan sebagian besar Sistem Deteksi Intrusi tidak akan terpengaruh. Kami berencana untuk memberikan detail tambahan di masa mendatang yang membahas masalah anti-penipuan dan kerusakan situs bagi pengguna mode Samaran.
Penyamaran Alamat IP	Jika situs penayang berita (pihak pertama) menggunakan domain yang sama dengan situs iklan (pihak ketiga), apakah alamat IP akan disamarkan untuk keduanya? Jika tidak, bagaimana cara membedakan keduanya?	Perlindungan IP saat ini mengusulkan pendekatan berbasis daftar untuk mengidentifikasi traffic pihak ketiga mana yang melewati proxy. Namun, meskipun ada dalam daftar tersebut, origin tidak akan di-proxy jika diakses dalam konteks pihak pertama. Kami sedang menyelesaikan detail terkait domain pihak ketiga tertentu yang akan diprioritaskan pada awalnya dan cara kami menentukan konteks pihak pertama dan pihak ketiga secara akurat untuk Perlindungan IP.
Penyamaran Alamat IP	Kekhawatiran tentang perlindungan IP dan dampaknya terhadap sistem anti-penipuan.	Pihak pertama tidak terpengaruh oleh paket Perlindungan IP kami, sehingga situs seperti forum harus memiliki akses ke alamat IP untuk penyelesaian sengketa. Kami berencana untuk memberikan detail tambahan di masa mendatang untuk menangani masalah penipuan iklan.
Penyamaran Alamat IP	Apakah IP disamarkan di header untuk domain yang terpengaruh?	Pengguna akan ditetapkan ke area geografis berdasarkan alamat IP pra-proxy yang mewakili lokasi mereka saat ini. Anda dapat menemukan detail selengkapnya di sini.

Mitigasi Pelacakan Kembali

Tema Masukan	Ringkasan	Respons Chrome
Spesifikasi API	Diperlukan klarifikasi tentang perilaku penanganan Chrome terhadap navigasi yang diperluas saat tab ditutup.	Kami telah menyelesaikan masalah ini di sini dan memperbarui spesifikasinya.
Pelacakan Navigasi	Diskusi tentang pendekatan mitigasi pelacakan yang melibatkan kumpulan link terbatas untuk mengurangi entropi dalam permintaan lintas situs.	Kami terus membahas topik ini dengan vendor browser lain di sini, dan menerima masukan tambahan serta proposal spesifik apa pun tentang masalah ini dari ekosistem.

Anggaran Privasi

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

Memperkuat batasan privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Batas Domain Set Situs Terkait (RWS)	Meminta untuk meningkatkan batas Domain terkait dalam RWS	Respons kami serupa dengan kuartal sebelumnya: Saat ini, kami tidak berencana untuk menaikkan batas numerik. Batas ini ditetapkan berdasarkan pertimbangan privasi pengguna, masukan dari pemangku kepentingan ekosistem di W3C, dan pertimbangan penerapan yang sebanding di browser lain. Untuk mengetahui informasi tambahan, lihat postingan blog kami (1, 2). Sebaiknya periksa kasus penggunaan yang memerlukan akses cookie lintas situs di luar batas numerik, dan pertimbangkan untuk memanfaatkan panduan kami untuk kasus penggunaan identitas, penyematan yang diautentikasi, dan kasus penggunaan iklan. Jika sesi pengguna terkait dengan tindakan login, sebaiknya gunakan Federated Credential Management (FedCM) API untuk mempertahankan fungsi. Kami menerima masukan tentang kasus penggunaan lain yang mungkin diperlukan di sini.
Penanganan cookie lintas situs	Cookie lintas situs yang ditetapkan oleh subdomain tidak diteruskan dalam permintaan berikutnya dari domain utama. Masalah ini tetap terjadi meskipun dengan konfigurasi CORS dan kredensial yang tepat.	Kami memberikan panduan di sini terkait penggunaan requestStorageAccessFor API yang benar yang perlu menentukan origin lengkap (yaitu menyertakan subdomain) agar cookie lintas situs dapat dikirim pada permintaan pengambilan berikutnya.
Pilihan Pengguna	Permintaan informasi lebih lanjut mengenai requestStorageAccessFor yang digunakan oleh RWS setelah peluncuran pilihan pengguna, khususnya bagaimana gestur pengguna yang implisit atau eksplisit, yang saat ini memungkinkan akses ke 3PC, akan berfungsi di sistem baru.	Kami memperkirakan bahwa perilaku RWS dalam mode pilihan pengguna, (yaitu, terlepas dari apakah pengguna telah memilih untuk mempertahankan atau membatasi 3PC mereka) akan konsisten dengan perilaku yang ada/dikirimkan di Chrome dengan 3PC diizinkan vs. 3PC diblokir dengan RWS diaktifkan ("Izinkan situs terkait melihat aktivitas Anda di grup"). Sebaiknya panggil hasStorageAccess terlebih dahulu untuk memeriksa apakah sematan sudah memiliki akses ke cookie lintas situs yang tidak dipartisi sebelum memanggil requestStorageAccess. Metode hasStorageAccess akan menampilkan nilai benar jika pengguna memilih untuk mengizinkan 3PC. requestStorageAccessFor saat ini tidak memerlukan gestur pengguna jika 3PC diizinkan. Kami telah membuka masalah GitHub baru untuk membahas dan menentukan perilaku yang tepat dalam kasus ini, dan menerima masukan tambahan dari ekosistem.
Penggunaan API	Kekhawatiran tentang kurangnya kejelasan terkait penggunaan RWS untuk tujuan "komersial", sehingga menghambat penerapan RWS. Pemangku kepentingan menunjukkan minat untuk mengelompokkan publikasi untuk iklan yang ditargetkan.	Tujuan penggunaan RWS adalah untuk mendukung fungsi situs inti dan perjalanan pengguna inti. Sebaiknya gunakan API iklan yang dibuat khusus untuk kasus penggunaan yang terkait dengan iklan yang ditargetkan.
Penggunaan API	Laporan masalah dengan requestStorageAccess yang dapat menetapkan data localStorage, tetapi tidak dapat menetapkan cookie.	Masalah ini disebabkan oleh kesalahan ketik pada atribut SameSite. Pastikan ejaan sudah benar dan tetapkan secara eksplisit ke Tidak ada untuk 3PC.
Spesifikasi API	Perbedaan skema JSON di seluruh repositori, seperti kesalahan penempatan kolom "contact" dan saran untuk peningkatan, termasuk penggunaan kata kunci "oneOf" untuk memastikan konsistensi.	Kami sedang menyelidiki masukan ini dan akan melakukan perbaikan pada skema ini dalam waktu dekat. Kami menerima masukan tambahan di sini.
Akses pihak ketiga (3P) ke RWS	Dengan izin pengguna tertentu, izinkan stopkontak untuk menunjukkan domain pihak ketiga yang juga akan memiliki akses tersebut ke data RWS API.	Mengizinkan pihak ketiga menggabungkan data mereka sendiri yang tidak dipartisi dengan data situs RWS akan melemahkan perlindungan pelacakan lintas situs Privacy Sandbox. Namun, kami mempertimbangkan potensi untuk memungkinkan pihak ketiga mempertahankan data yang dipartisi ke RWS dan mencari masukan tentang desain untuk solusi tersebut di sini.

Fenced Frames API

Tema Masukan	Ringkasan	Respons Chrome
Pertanyaan API	Kekhawatiran tentang bagaimana Frame Berpagar tanpa akses jaringan dapat melanggar keamanan merek dan perlindungan penipuan bagi pengiklan.	Kami melacak masalah ini dalam konteks rencana kami untuk menerapkan Bingkai Pagar. Kami akan mulai mencari solusi yang kompatibel dengan penerapan Fenced Frames dan akan menyampaikannya segera setelah ada proposal yang cukup material.
Pertanyaan API	Apakah Fenced Frames API masih dijadwalkan untuk tahun 2026?	Seperti yang dinyatakan dalam pengumuman publik kami, Fenced Frames akan diwajibkan mulai tahun 2026.
Bug API	Jika reportEvent() berhasil mengirim data klik dari subframe lintas origin, setReportEventDataForAutomaticBeacons() tidak akan menimpa data frame atas.	Kami sedang membahas masalah ini dan menerima masukan tambahan di sini.

Shared Storage API

Tema Masukan	Ringkasan	Respons Chrome
Iklan Aplikasi	Tidak ada yang setara dengan Shared Storage API di Privacy Sandbox di Android.	Kami mengevaluasi solusi di Android berdasarkan kebutuhan kasus penggunaan dan batasan platform. Saat ini, kami belum memiliki rencana untuk disampaikan, tetapi kami menerima masukan tambahan dari ekosistem terkait masalah ini.
Penggunaan API	Kebingungan terkait kebutuhan worklet JavaScript tambahan untuk penerapan Shared Storage API.	Kami sedang menyelidiki masukan ini dan mencari kemungkinan untuk memperbarui dokumentasi kami guna menjelaskan perlunya skrip worklet tambahan untuk Share Storage API.
Ketidakandalan	Shared Storage API dapat berubah secara signifikan atau dihapus berdasarkan kritik privasi, sehingga menjadikannya sebagai dasar yang tidak dapat diandalkan untuk membangun aplikasi.	Kami tidak berencana untuk mengubah atau menghentikan infrastruktur Penyimpanan Bersama secara signifikan. Perubahan utama yang telah diumumkan adalah pada gate output Select URL, tempat frame berpagar akan diperlukan dan pelaporan tingkat peristiwa tidak akan digunakan lagi. Namun, perubahan ini tidak akan berlaku hingga setidaknya tahun 2026.

CHIP

Tema Masukan	Ringkasan	Respons Chrome
Cookie yang Dipartisi	Chrome tidak membedakan kunci partisi berdasarkan ancestor frame, tidak seperti Firefox, sehingga menyebabkan inkonsistensi.	Chrome menggunakan "ancestor chain bit" untuk menyelesaikan masalah keamanan dan perbedaan perilaku Firefox. Kami telah menjelaskan hal ini secara lebih mendetail di sini.
Cookie yang Dipartisi	Iframe tersemat dengan tingkat akses penyimpanan yang berbeda berbagi dan menimpa cookie yang dipartisi sama, sehingga menyebabkan inkonsistensi dalam status autentikasi.	Untuk konfigurasi khusus ini, rekomendasi kami adalah menggunakan cookie yang tidak dipartisi dengan pemanggilan Storage Access API. Kami telah membahasnya secara lebih mendetail di sini.
Cookie yang Dipartisi	Apakah cookie jar yang dipartisi akan dihapus saat 3PC dinonaktifkan? Apakah ada cara untuk menguji perilaku ini?	Saat ini, kami belum berencana untuk membagikan informasi apa pun. Namun, developer dapat menguji fungsi ini dengan menghapus cookie yang dipartisi secara manual melalui panel Aplikasi>Cookie Chrome DevTools.

FedCM

Tema Masukan	Ringkasan	Respons Chrome
Cakupan Pendaftaran Penyedia Identitas (IdP) & Pemilih Organisasi	Pertanyaan tentang memperluas pendaftaran IdP dari kebijakan origin yang sama saat ini ke kebijakan situs yang sama. Perubahan ini akan memungkinkan pengelolaan identitas yang lebih luas dan lebih fleksibel, seperti memungkinkan halaman sambutan universitas mendaftarkan beberapa penyedia identitas berbasis subdomain tanpa memerlukan pendaftaran khusus asal yang terpisah. Masukan tentang cara meningkatkan kemampuan proses debug, menangani klien yang disetujui untuk mediasi senyap, mengklarifikasi perilaku cookie, mengizinkan penyesuaian kata-kata pop-up, dan mengatasi masalah waktu tunggu habis.	Kami menerima masukan ini dan sedang mempertimbangkan cara penyertaan pemilih organisasi ke dalam FedCM. Kami menerima masukan tambahan dari ekosistem di sini sambil terus meningkatkan pendekatan ini.
Cookie IdP	Diskusi tentang dampak penerapan cookie sesi berumur pendek sebagai bagian dari proposal Kredensial Sesi yang Terikat Perangkat (DBSC). Muncul kekhawatiran tentang pengalaman pengguna di FedCM, tempat cookie IdP yang sudah tidak berlaku memerlukan modal yang terlihat pengguna untuk diperpanjang.	DBSC yang diusulkan harus memungkinkan perpanjangan cookie tanpa interaksi pengguna, sehingga memastikan pengalaman pengguna yang berkelanjutan. Kami telah membahas masalah ini secara lebih mendetail di sini.
Spesifikasi API	Pertanyaan tentang kesesuaian penggunaan "NetworkError" dalam spesifikasi FedCM API saat ukuran array "providers" tidak sama dengan 1.	Kami setuju bahwa "TypeError" akan lebih sesuai untuk situasi ini karena mencerminkan error coding, bukan masalah jaringan. Kami akan mempertimbangkan perubahan ini dan mempelajari kemungkinan penghapusan pembatasan ini dalam update mendatang seiring kami terus mengembangkan dukungan multi-IdP. Kami menantikan masukan tambahan di sini.

Mencegah spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Uji Coba Penghentian Penggunaan & Mode B	Kekhawatiran tentang uji coba penghentian, pengujian Mode B, potensi penghentian Token Status Pribadi (PST), dan kemungkinan API baru yang lebih cocok untuk kasus penggunaan anti-penipuan mereka.	Uji coba penghentian penggunaan dan pengujian Mode B tidak berubah. Kami akan menyampaikan informasi terbaru apa pun melalui blog dev. Kami tidak berencana untuk menghentikan PST. Kami sedang membahas pengembangan dan update fitur yang sedang berlangsung di GitHub. Kami belum mengumumkan API baru, tetapi kami menerima masukan tentang cara PST dapat menangani kasus penggunaan anti-penipuan dengan lebih baik.
Masukan API	Minta kemampuan untuk mencabut token guna mengatasi kasus penggunaan anti-penipuan.	Meskipun penerbit dapat mencabut semua token dengan mengubah kunci yang mereka gunakan, pencabutan token individual tidak mungkin dilakukan dengan API karena akan mengharuskan penerbit untuk mengaitkan penerbitan dan penukaran token yang melanggar model privasi PST guna mencegah pelacakan di antara kedua peristiwa tersebut.