Laporan Masukan - Kuartal 3 2023

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

Sebagai bagian dari komitmennya kepada CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox-nya (lihat paragraf 12 dan 17(c)(ii) 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 mengambil agregasi jumlah masukan yang telah diterima tim Chrome seputar tema tertentu dan mengaturnya dalam urutan kuantitas 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 terkait pertemuan pemangku kepentingan 1:1, email yang diterima oleh masing-masing engineer, milis API, dan formulir masukan publik juga dipertimbangkan. Google kemudian berkoordinasi dengan tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif dari tema yang muncul sehubungan dengan setiap API.

Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat terhadap 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

CHIP

Cookie yang Memiliki Status Dipartisi Independen

DSP

Platform Sisi Permintaan

FedCM

Pengelolaan Kredensial Federasi

FPS

Set Pihak Pertama

IAB

Interactive Advertising Bureau

IDP (IDP)

Penyedia Identitas

IETF

Internet Engineering Task Force

IP

Alamat Protokol Internet

openRTB

Bidding real-time

lewat batas waktu

Uji Coba Origin

PatCG

Grup Komunitas Teknologi Periklanan Pribadi

RP

Pesta Santai

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 khusus

Tema Masukan	Ringkasan	Respons Chrome
Kesiapan ekosistem	SSP menyoroti kekhawatiran terkait ketidaksiapan penayang dan tidak melakukan pekerjaan deployment yang diperlukan.	Privacy Sandbox memiliki jangkauan yang secara khusus berfokus pada edukasi penayang, yang mencakup webinar dan rapat khusus dengan penayang dan SSP yang hadir untuk mendorong pekerjaan deployment.
Penghentian cookie pihak ketiga	Kekhawatiran terhadap penghentian penggunaan cookie pihak ketiga (3PCD) meningkat pada Kuartal 4 2023 karena pemadaman teknologi industri.	Linimasa untuk Privacy Sandbox telah dibahas dengan CMA, dengan pengurutan yang menghasilkan kesiapan untuk paruh kedua tahun 2024. Privacy Sandbox akan memublikasikan informasi yang lebih mendetail tentang urutan peningkatan 3PCD. Berdasarkan Komitmen, 3PCD tunduk pada masalah persaingan CMA yang sedang ditangani.
Google Ad Manager	Google Ad Manager menolak untuk mengekspos platform API sehingga mempersulit pengujian.	Respons yang diberikan oleh Google Ad Manager: Karena alasan yang dijelaskan dalam respons Google Ad Manager ini, rencana Google Ad Manager untuk integrasi Protected Audience API-nya tidak menyertakan dukungan server iklan penayang Google tanpa kontrol lelang tingkat atas.
Google Ad Manager	Google Ad Manager memiliki harga minimum rahasia yang hanya ditampilkan pada AdX atau SSP Bidding Terbuka.	Dokumentasi publik Google Ad Manager mengatakan bahwa pemenang lelang kontekstual akan diteruskan ke logika penskoran tingkat teratas dan bukan ke lelang komponen apa pun, termasuk AdX atau Bidding Terbuka. Selain itu, dokumentasi tersebut menjelaskan logika penskoran tingkat teratas: "Ad Manager akan membandingkan bid pemenang di setiap lelang komponen, termasuk lelang komponen Ad Manager sendiri untuk bid grup minat pembelinya, serta iklan kontekstual terbaik (yang dipilih melalui alokasi dinamis), dan akan menayangkan iklan dengan bid tertinggi".
Google Ad Manager	Produk Google Ads harus tunduk pada aturan yang sama seperti produk iklan pihak ketiga.	Produk Google Ads telah tunduk pada aturan yang sama seperti pihak ketiga.
Pengujian yang difasilitasi Chrome	Tambahkan label untuk browser yang tidak berada di A atau B.	Kami tidak mempertimbangkan melakukannya untuk saat ini, karena penyelidikan kami menemukan bahwa menambahkan label non-eksperimen dapat mempersulit masalah privasi seputar traffic dalam mode samaran.
Agensi iklan	Dapatkah agensi atau perusahaan tanpa JavaScript di situs menggunakan Privacy Sandbox API?	Siapa pun dapat memanggil API Privacy Sandbox. Agensi atau pihak lain dapat membuat teknologi langsung di API. API sisi klien memerlukan integrasi dengan klien, seperti halnya cookie. Banyak API, seperti cookie, juga memiliki antarmuka header HTTP. Kita telah melihat satu framework industri iklan, Prebid, membangun integrasi sisi klien dengan API. Organisasi lain juga dapat melakukan hal yang sama.
Solusi Sisi Klien	Mengapa Google menggunakan solusi sisi klien untuk Privacy Sandbox padahal seorang engineer sebelumnya telah menyatakan kekhawatirannya terhadap skalabilitas solusi tersebut pada tahun 2012?	Teknologi peningkatan privasi (PET) sebagai bidang studi telah berkembang secara signifikan sejak tahun 2012 dan, dengan itu, menjadi aplikasi yang layak secara komersial. Inti dari Privacy Sandbox adalah kombinasi PET yang tidak mungkin berjalan lebih dari satu dekade yang lalu. Selain itu, daya komputasi pribadi telah meningkat, begitu juga dengan ekspektasi konsumen akan browser dan ekspektasi peraturan terkait privasi.
Machine Learning	Bagaimana rencana penggunaan Privacy Sandbox Google untuk tujuan machine learning?	Sebagian besar ekosistem teknologi iklan menggunakan machine learning saat ini dan kami tidak berharap hal tersebut akan berubah. Privacy Sandbox tidak mencegah perusahaan teknologi iklan atau siapa pun untuk terus menggunakan machine learning. Privacy Sandbox juga tidak mengharuskan perusahaan yang berintegrasi dengan API-nya menggunakan machine learning. Karena itu, wajar saja jika perusahaan akan terus membuat produk dan layanannya dengan cara yang memenuhi kebutuhan pelanggannya, baik yang mencakup machine learning maupun tidak. Setiap machine learning yang dibuat oleh integrator Privacy Sandbox akan jelas oleh mereka sehingga tidak akan terhalang oleh mereka.
Verifikasi data	Bagaimana perusahaan dapat memverifikasi bahwa data yang mereka terima dari penggunaan Privacy Sandbox akurat dan apakah Google bersedia ditinjau melalui entitas seperti Media Ratings Council (MRC)?	API Privacy Sandbox dibuat dalam platform open source yang mendukung Chrome. Bagian dari API yang dimaksudkan untuk dijalankan di Trusted Execution Environment juga bersifat open source dan dapat diaudit. Siapa saja yang ingin memeriksa kode dapat, termasuk MRC.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan Produksi	Apa proses yang diterapkan bagi Chrome untuk mendukung masalah dan eskalasi teknis Privacy Sandbox yang memengaruhi ekosistem?	Google menyediakan berbagai saluran untuk memungkinkan teknologi iklan melaporkan masalah teknis dan memungkinkan eskalasi yang diperlukan untuk menyelesaikan masalah tersebut. Selain itu, Chrome berharap dapat mem-build dan menskalakan proses lebih lanjut untuk menyelesaikan masalah teknis dan eskalasi yang memengaruhi kesehatan ekosistem. Chrome berkomitmen untuk memastikan resource untuk upaya ini. Lihat postingan developer kami untuk mengetahui informasi selengkapnya tentang forum publik dan pribadi untuk masukan dan eskalasi.
Mode pengujian yang difasilitasi Chrome	Informasi selengkapnya tentang linimasa dan implementasi yang tepat untuk mode pengujian yang difasilitasi Chrome.	Kami telah membagikan postingan blog tentang mode pengujian dan berupaya untuk segera membagikan informasi selengkapnya. Kami akan menyambut ukuran label mode pengujian yang seharusnya.
Integrasi dengan standar industri lainnya	Apakah Privacy Sandbox API akan terhubung ke salah satu atau kedua TCF v2.* dan Mode Izin?	Kami tidak berencana untuk mengintegrasikan Privacy Sandbox API secara langsung dengan TCF v2 atau Mode Izin. Namun, perusahaan dan grup perdagangan industri dapat menyesuaikan produk dan framework mereka agar berfungsi bersama dengan Privacy Sandbox API. Misalnya, dengan framework seperti TCF, setiap peserta harus menentukan pendekatan kepatuhannya sendiri berdasarkan sinyal TCF yang diterima dan kebijakan TCF terkait. Kami berharap perusahaan dapat menentukan waktu dan cara menggunakan berbagai fungsi yang ditawarkan elemen penyusun Privacy Sandbox kami.

Pendaftaran & Pengesahan

Tema Masukan	Ringkasan	Respons Chrome
Batasan	Dengan proses pendaftaran, Google dapat menentukan perusahaan mana di ekosistem yang diizinkan untuk menggunakan API Privacy Sandbox.	Proses Pendaftaran dan Pengesahan pada dasarnya memerlukan verifikasi entitas (misalnya, entitas memiliki nomor DUN, dapat memberikan link ke kebijakan privasi, dan sebagainya) dan menjadikan pengesahan publik sebagai persyaratan untuk memanggil API. Entitas yang berhasil memenuhi persyaratan pendaftaran akan divalidasi. Untuk perusahaan yang tidak memiliki DUN, kami menyediakan proses yang cepat dan bebas biaya dengan Dun & Bradstreet untuk mendapatkan DUN. Tujuannya adalah untuk meningkatkan perlindungan privasi API (dengan langkah-langkah yang baru saja disebutkan) dan juga untuk menambahkan lapisan transparansi ke API Privacy Sandbox, sehingga pihak yang berminat dapat lebih memahami siapa yang menggunakan API mana dan pengesahan apa yang mereka buat. Kami menerima masukan industri lebih lanjut tentang masalah ini, yang telah digunakan untuk membentuk proses ini.
Biaya pendaftaran ulang	Masa berlaku file pengesahan akan berakhir setiap 12 bulan dan mengharuskan situs untuk mendaftar ulang.	Kami telah mendengar masukan dari ekosistem dan mengubah pendekatan kami sesuai dengan itu. Artinya, masa berlaku file tidak akan lagi berakhir setelah 12 bulan atau jangka waktu tertentu. Kami memperbarui panduan developer pendaftaran kami dengan konteks tambahan.
File pengesahan	Bagaimana cara penggunaan file pengesahan?	Semua perusahaan yang memanggil API pengukuran dan relevansi akan diwajibkan hingga batas waktu penerapan untuk mengupload file pengesahan di situs mereka dan menyimpannya agar dapat dilihat publik selama Anda bermaksud untuk terus memanggil API tersebut. Situs dapat menunggu sekitar satu permintaan per jam dari Privacy Sandbox, dan calon entity lainnya juga dapat membuat kueri. Hal ini akan dilakukan melalui mekanisme sistem pendaftaran sendiri untuk mengkueri server entity terdaftar dan memastikan file pengesahan valid. Pengesahan akan disertakan dalam Laporan Transparansi dan dapat dilihat oleh masyara umum. Kami mengharapkan perusahaan bertindak sesuai dengan pengesahan yang mereka nyatakan, begitu juga dengan seluruh ekosistem dan badan pengatur terkait.
Pendaftaran	Apakah pendaftaran per situs atau per origin?	Pendaftaran dilakukan di tingkat situs.

Tampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Performa	Masalah performa pada dampak rasio keikutsertaan Topics di Wilayah Ekonomi Eropa.	Kami menyarankan kepada pemangku kepentingan yang bersangkutan untuk menghubungi Otoritas Perlindungan Data Anda yang relevan mengenai masalah ini. Langkah ini paling tepat untuk mengatasi kekhawatiran tersebut dan memengaruhi apakah penerapan teknologi yang meningkatkan privasi diberi insentif oleh hukum atau diperlakukan seperti pelacakan, yang memerlukan pendekatan yang sama untuk memberikan izin. Hal ini dapat menyebabkan API seperti yang ada di Privacy Sandbox tidak sering tersedia.
Pendaftaran	Apakah bidder downstream perlu mendaftar di Topics API untuk menggunakan sinyal Topics dari SSP upstream?	Penerima downstream topik di luar pemanggil Topics API awal tidak perlu didaftarkan, meskipun banyak yang kemungkinan akan terdaftar untuk penggunaan API lainnya. Daftar pendaftar Privacy Sandbox akan diberikan secara terprogram sebagai bagian dari upaya transparansi program, yang akan memungkinkan pemanggil Topics API yang berminat untuk memeriksa apakah penerima yang mereka kirimi topik telah terdaftar, jika pemanggil menginginkannya.
Pemfilteran topik	Minta untuk menerapkan pemfilteran pemanggil lain ke topik yang mereka ambil di halaman, untuk membagikan hanya item yang memenuhi syarat untuk diambil oleh pembeli.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Pengecualian situs	Mengecualikan situs agar tidak berkontribusi ke Topics pengguna.	Topik tidak dipanggil secara default. Penting untuk diperhatikan bahwa tidak ada konten halaman yang dipertimbangkan saat topik dipilih, dan semua topik diseleksi untuk memastikan tidak sensitif. Situs juga dapat membatasi situsnya agar tidak disertakan dalam penghitungan topik melalui header kebijakan izin berikut: Permissions-Policy: browsing-topics=()
Observasi topik	Izinkan penerbit memberikan izin kepada Chrome untuk mengklasifikasikan topik berdasarkan konten halaman (misalnya, head atau body).	Sebelumnya kami mempertimbangkan penawaran fungsi untuk mengklasifikasikan situs ke dalam topik berdasarkan konten halaman, dan membuat keputusan untuk tidak melanjutkan berdasarkan masalah privasi dan keamanan. Proposal ini dapat mengurangi beberapa kekhawatiran tersebut, tetapi cakupannya tidak jelas. Karena periode eksperimen CMA mendatang, perubahan ini tidak akan terjadi sebelum 3PCD. Kami menantikan masukan tambahan di sini.
Observasi topik	Menyediakan kebijakan izin yang lebih mendetail untuk penerbit.	Memberikan kebijakan izin yang lebih mendetail bagi penayang akan memungkinkan situs penayang memberikan dampak negatif pada utilitas Topics API bagi ekosistem secara keseluruhan, tanpa berpengaruh negatif terhadap utilitas Topics API untuk situs itu sendiri. Lihat Memperbarui kebijakan izin untuk mendukung izin terpisah untuk mengambil dan mengamati masalah GitHub guna mengetahui diskusi topik yang lebih mendetail.
Topik Medis dan Kesehatan	Mengapa taksonomi Topics tidak mencakup topik dalam kategori medis atau Kesehatan?	Kategori medis dan kesehatan dianggap sebagai topik sensitif, sehingga dikecualikan dari taksonomi Topics.
Pengambilan topik	Cara lebih cepat bagi DSP untuk mendapatkan Topics tanpa mengambil menggunakan header.	Metode header berperforma lebih baik dan lebih murah daripada membuat iframe lintas origin dan membuat panggilan document.browsingTopics() dari iframe. (iframe lintas origin harus digunakan untuk panggilan, karena konteks tingkat teratas untuk mengamati topik harus cocok dengan konteks tempat topik diakses.) Hal ini dibahas secara mendetail di sini.
Pengambilan topik	Permintaan untuk mendukung penerusan Topics melalui header pada permintaan tag skrip lintas origin.	Dari segi keamanan, hal ini tidak mungkin. Setiap dokumen dan lingkungan eksekusinya dikaitkan dengan satu asal, yaitu asal dokumen. Subresource pihak ketiga yang dimuat dan dieksekusi dalam lingkungan yang sama tersebut dianggap dimiliki oleh asal dokumen. Hal ini untuk mencegah kebocoran data tanpa izin dari satu origin ke origin lainnya. Alternatifnya adalah memberikan atribut browsingTopics pada tag <script>. Dari perspektif keamanan, proses ini harus bersih, dan tidak menambahkan latensi tambahan. Kami menerima masukan dari pihak yang berminat.
Awareness	Meningkatkan awareness publik terhadap Topics API dan cara API akan digunakan.	Kami telah berinteraksi dengan pemangku kepentingan yang memberikan masukan ini dan masalah ini telah diselesaikan di GitHub. Ke depannya, kami akan terus mendukung pemahaman ekosistem tentang API dan kami menantikan pendapat dari para pemangku kepentingan. Sementara itu, sebaiknya para pemangku kepentingan yang ingin mengetahui lebih lanjut tentang Topics API untuk membiasakan diri dengan dokumentasi dalam panduan developer Chrome.
Notifikasi	Notifikasi untuk memberi tahu pengguna saat Topik mereka diamati oleh situs.	Kami telah menanggapi masukan ini di GitHub. Pengguna dapat mempelajari lebih lanjut kontrol Topik di pusat bantuan Chrome.
Machine Learning	Bagaimana ML dapat digunakan untuk menyimpulkan Topik pengguna?	Kami sedang membahas masalah ini dan menerima masukan tambahan.
Kegunaan untuk berbagai jenis pemangku kepentingan	Perusahaan teknologi iklan yang lebih kecil mungkin tidak dapat mengamati Topics karena cara browser menghitungnya.	Hanya teknologi iklan yang mengamati pengguna yang mengunjungi halaman tentang topik yang dimaksud dalam tiga minggu terakhir yang akan menerima topik. Jika teknologi iklan tidak memanggil API dalam tiga minggu sebelumnya untuk pengguna tersebut di situs tentang topik tersebut, nilai yang ditampilkan akan kosong. Fitur ini berarti bahwa teknologi iklan yang layanannya digunakan oleh lebih banyak pemilik situs, sehingga memiliki lebih banyak peluang untuk mengamati kunjungan situs oleh pengguna tertentu, dapat menerima lebih banyak topik daripada teknologi iklan lainnya. Fitur ini penting untuk perlindungan privasi API karena fitur ini membatasi ketersediaan informasi tentang pengguna hanya bagi pihak yang sudah dapat mengamati informasi dasar yang sama (saat ini melalui cookie pihak ketiga).
Permintaan XHR	Kapan penyertaan Topics dalam permintaan XMLHttpRequest (XHR) akan tidak digunakan lagi?	Seperti yang diumumkan Chrome pada Agustus 2023, Chrome mulai menghentikan dukungan untuk XHR saat beralih dari Uji Coba Origin ke Ketersediaan Umum. Seiring berlanjutnya peningkatan Topics, dukungan XHR hanya disertakan untuk pengguna yang fitur OT-nya diaktifkan dan sepenuhnya tidak digunakan lagi saat masing-masing grup eksperimen OT digabungkan. Jika Anda menggunakan Topics dengan XHR, situs Anda tidak akan terganggu. Topik tidak akan ditambahkan ke header permintaan XHR Anda. Sebaiknya Anda beralih ke fetch untuk permintaan Anda, menggunakan atribut iframe, atau menggunakan JavaScript API untuk mengambil topik. Fetch didukung oleh semua browser modern, tetapi tidak oleh Internet Explorer atau Opera Mini.
Proses pembaruan taksonomi dan pengklasifikasi	Informasi selengkapnya tentang ritme rilis pengklasifikasi dan taksonomi Topics dan cara perusahaan dapat mempersiapkan diri untuk pembaruan tersebut.	Respons kami tetap tidak berubah dari Kuartal 2: Seperti yang dibagikan di postingan blog terbaru, kami memperkirakan taksonomi akan berkembang dari waktu ke waktu, dan agar tata kelola taksonomi pada akhirnya bertransisi ke pihak eksternal yang mewakili pemangku kepentingan dari seluruh industri. Kami juga membagikan rencana peningkatan di grup pengumuman topik.
Penyalahgunaan	Potensi serangan melalui rantai pengalihan.	Kami mempertimbangkan masalah ini dan menerima masukan tambahan.
Jenis Inventaris Penayang	Apa jenis inventaris penayang yang akan didukung pengujian Protected Audience dan Topics?	Protected Audience atau Topics tidak memiliki batasan inheren dalam hal jenis inventaris yang dapat digunakan.
Waktu peningkatan	Sarankan tidak ada waktu peningkatan untuk taksonomi baru agar mencapai 100%.	Menindaklanjuti permintaan masukan ini dari ekosistem dan diskusi selama pertemuan PATCG, kami telah mengumumkan rencana peluncuran taksonomi baru.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan	Ringkasan	Respons Chrome
Lelang Tingkat Teratas	Kemampuan untuk menggunakan server iklan penayang Google tanpa memberikan kontrol kepada Google Ad Manager atas lelang Protected Audience API tingkat atas.	Respons yang diberikan oleh Google Ad Manager: Rencana Google Ad Manager untuk Protected Audience API tidak menyertakan dukungan server iklan penayang Google tanpa kontrol lelang Protected Audience tingkat teratas, karena alasan berikut. Agar dapat menayangkan iklan kepada pelanggan dengan baik di pasar penayangan iklan penayang, server iklan penayang Google harus mempertahankan kontrol atas lelang Protected Audience tingkat teratas. Sebagai server iklan penayang, peran kami adalah memberikan perkiraan penayang agar mereka dapat menegosiasikan kampanye yang dijual langsung tanpa memesan berlebih, serta mengatur dan menayangkan reservasi langsung mereka secara optimal. Untuk melakukannya, Anda harus menjalankan lelang akhir untuk membandingkan semua permintaan langsung dan tidak langsung yang memenuhi syarat. Perkiraan dan kecepatan adalah fungsi inti yang diharapkan penayang dari server iklan. Tanpa perkiraan yang akurat, penayang dapat pada akhirnya menjual inventaris mereka secara berlebihan, yang membahayakan reputasi bisnis mereka. Kecepatan juga sangat penting, karena tidak dapat memenuhi kontrak reservasi dengan pengiklan juga berisiko merusak hubungan langsung pengiklan penayang, yang dapat mengakibatkan dampak yang signifikan bagi bisnis penayang. Singkatnya, kami tidak melihat aktivitas server iklan penayang dalam menjalankan lelang Protected Audience tingkat teratas sebagai hal yang berbeda dengan aktivitas lainnya server iklan penayang.
directFrom SellerSignals	directFrom SellerSignals memungkinkan Google Ad Manager mencegah penayang melihat harga lelang kontekstualnya.	Respons Chrome: Informasi yang diteruskan ke runAdAuction() tidak diketahui berasal dari penjual, kecuali jika penjual memanggil runAdAuction() dari iframe miliknya. Dalam lelang multi-penjual, semua penjual tidak akan dapat membuat frame yang memanggil runAdAuction(). directFromSellerSignals menyelesaikan masalah ini dengan memuat konten dari paket subresource yang dimuat dari origin penjual. Hal ini memastikan keaslian dan integritas informasi yang diteruskan ke lelang dari konfigurasi lelang penjual tidak dapat dimanipulasi. Jika penayang ingin menggunakan Protected Audience API untuk memahami informasi apa pun yang diteruskan oleh penyedia teknologi mereka ke lelang Protected Audience, penayang dapat meminta fungsi ini kepada penyedia teknologi tersebut. 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 tanpa jaminan milik penayang, termasuk harga item baris tanpa jaminan, akan dibagikan kepada pembeli lain sebelum mereka mengajukan bid dalam lelang, yang kemudian kami tegaskan kembali dalam komitmen kami kepada Otoritas Kompetisi Prancis. Untuk lelang Protected Audience, kami bermaksud untuk memenuhi janji kami dengan memanfaatkan directFromSellerSignals, dan tidak membagikan bid peserta lelang apa pun dengan peserta lelang lainnya sebelum penyelesaian lelang di lelang multi-penjual. Untuk lebih jelasnya, kami tidak akan membagikan harga lelang kontekstual dengan lelang komponen kami sendiri, seperti yang dijelaskan dalam pembaruan Menjelaskan dinamika lelang tingkat atas lebih lanjut.
Eksposur Informasi	Logika bisnis dan detail kontrak yang sensitif dapat diekspos oleh browser.	Orang yang menggunakan {i>browser<i} web dapat melihat segala sesuatu yang terjadi di dalam {i>browser<i}. Saat lelang iklan terjadi di dalam browser, memang benar bahwa orang yang browsernya dapat melihat lelang tersebut terjadi, termasuk melihat berapa banyak pihak yang berbeda memilih untuk mengajukan bid. Karena browser adalah agen pengguna, menurut kami tidak mungkin atau diperlukan untuk mencoba mengubahnya. Namun, hanya orang yang menggunakan browser yang memiliki visibilitas ke operasi ini. Lelang di perangkat yang dijalankan menggunakan Protected Audience API tidak dapat diamati oleh server mana pun, termasuk milik Google.
PerBuyerExperiment GroupId	Rentang nilai PerBuyerExperiment GroupId saat ini dapat memungkinkan pembeli menghubungkan data kontekstual dengan permintaan server tepercaya.	Penggunaan Protected Audience API dengan cara ini tidak konsisten dengan pengesahan wajib Privacy Sandbox bahwa pengguna API tidak akan mencoba mengakali perlindungan Privacy Sandbox. Di masa mendatang, persyaratan yang dijalankan oleh server nilai kunci di trusted execution environment (TEE) akan memberikan perlindungan teknis terhadap serangan ini.
Kebijakan asal yang sama	Melonggarkan kebijakan origin yang sama untuk mengizinkan subdomain.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Pembuatan versi API	Permintaan pembuatan versi dan catatan rilis untuk perubahan pada Protected Audience API.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Lelang Multi-SSP	Izinkan sinyal lelang tingkat teratas untuk melakukan penggabungan JSON dengan sinyal komponen auctionSignals.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem.
Batas bid	Tingkatkan batas jumlah komponen iklan yang memasukkan bid dari 20 menjadi 40.	Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan dari ekosistem yang membahas mengapa hal ini akan berguna.
(Juga dilaporkan di kuartal sebelumnya) Performa Lelang Protected Audience	Membuat laporan dari penguji bahwa lelang Protected Audience memiliki latensi tinggi.	Terkait pertanyaan tentang latensi, Protected Audience API umumnya mengikuti paradigma standar pembuatan kontrol yang ada, yang memungkinkan penjual memutuskan jumlah waktu dan resource yang dapat digunakan bidder, dan membuat alat yang memungkinkan pembeli memutuskan cara terbaik menggunakan resource yang tersedia bagi mereka. Kontrol dan alat ini umumnya tersedia saat ini, tetapi manfaat penuhnya hanya akan terlihat setelah diadopsi oleh pembeli dan penjual. Selain itu, Chrome terus mengerjakan berbagai peningkatan infrastruktur pada kecepatan lelang (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Kami mengundang masukan terkait kedua tahap dari upaya latensi ini: alat baru yang dapat berguna bagi pembeli dan penjual, serta laporan tentang bottleneck yang diamati yang harus diselidiki oleh engineer Chrome.
Pemfilteran sisi beli	Menambahkan dukungan untuk pemfilteran sisi beli berdasarkan grup minat.	Kami telah menyarankan beberapa cara agar SSP dan DSP dapat mengubah desainnya untuk menangani hal ini: Memindahkan beberapa tugas ke server Kunci/Nilai DSP. SSP membuat beberapa sinyal kontekstual dan memberikannya ke DSP. SSP meng-cache sinyal kontekstual untuk DSP.
Kontrol Grup Minat Penayang	Dukungan untuk penerbit yang ingin mendelegasikan penggunaan grup minat yang dibuat penayang.	Kami telah berdiskusi dengan banyak pihak mengenai permintaan ini. Kami percaya bahwa semua kasus penggunaan yang terlibat dalam "delegasi" grup minat buatan penayang dapat diakomodasi sekarang, dan selanjutnya kami harus membuat dukungan tambahan untuk membuat beberapa kasus penggunaan berjalan lebih lancar di masa mendatang.
(Juga dilaporkan di Kuartal 2) Trusted Execution Environment	Dukungan untuk Trusted Execution Environments (TEE) di lingkungan cloud non-publik.	Respons kami serupa dengan kuartal sebelumnya: Sementara kami terus mengeksplorasi 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 yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung Google Cloud selain AWS) adalah yang paling bermanfaat bagi ekosistem. Namun, kami tetap menerima masukan tambahan tentang mengapa persyaratan tersebut diperlukan dan memungkinkan mengingat batasan privasi dan keamanan.
Trusted Execution Environment	Komponen di jalur penayangan TEE, seperti load balancer, dapat mengamati semua traffic dan memiliki informasi alamat IP setiap permintaan.	Saat ini, alamat IP diteruskan sebagai metadata dalam header permintaan ke layanan iklan penjual tidak tepercaya dalam kasus Bidding dan Lelang serta lelang Protected Audience di perangkat. Baca Penerusan metadata untuk mengetahui informasi selengkapnya. Dalam jangka panjang, kami berencana untuk melakukan proxy teknologi iklan dan melacak traffic melalui Proxy IP, yang akan mencegah komponen mengamati semua traffic di jalur penayangan.
Time-to-Live (TTL)	Apakah time to live (TTL) sebelum layanan harus meminta kunci baru ditetapkan atau apakah time to live (TTL) harus bersifat fleksibel (atau dinamis)?	TTL umumnya statis. Saat ini, TTL untuk publik adalah 8 hari, dan rotasi terjadi setiap 7 hari; TTL juga sama untuk kunci pribadi seperti Layanan Agregasi. Dalam kasus layanan Bidding dan Lelang, kunci pribadi dan publik diambil setiap N jam di jalur non-permintaan dan di-cache dalam memori, sehingga tidak ada lebih dari penundaan N jam antara kunci yang berputar dan server mengambil kunci ini. Buffering 1 hari antara rotasi kunci dan masa berakhir adalah untuk memastikan bahwa meskipun pembuatan kunci gagal, layanan dapat terus beroperasi. Kami mempertimbangkan untuk memperpanjang TTL agar lebih tahan terhadap pemadaman. Jika terjadi kebocoran kunci, kami berencana untuk memaksa pembuatan kunci secara manual dan membatalkan kunci lebih cepat. Perlu diperhatikan bahwa kunci publik akan di-cache pada klien, saat ini selama 24 jam, sekali lagi untuk memastikan bahwa jika terjadi pemadaman koordinator, layanan masih dapat beroperasi.
Pembentukan Lalu Lintas	Dukungan Pembentukan Traffic untuk Layanan Bidding dan Lelang.	Pembeli dapat menunjukkan permintaan untuk lelang Protected Audience berdasarkan data pihak pertama Penayang atau data kontekstual. Penjual juga dapat melakukan penentuan serupa di server iklan penjual atau server Ad Exchange. Model ini dapat dilatih dengan data pihak pertama dan laporan gabungan apa pun dari lelang Protected Audience. Penjual dapat menggunakan informasi ini untuk menghindari pengiriman permintaan ke server Bidding dan Lelang saat tidak ada permintaan untuk lelang Protected Audience. Kami yakin ini bisa menjadi cara yang efektif untuk meningkatkan traffic.
Lelang Komponen	AuctionSignals tingkat atas mana yang dibagikan dengan penjual Komponen?	Pembeli dalam lelang komponen hanya menerima sinyal dari penjual komponen. Kami ingin membagikan dokumentasi tentang keseluruhan urutan lelang gabungan dengan bidding header dan lelang Protected Audience segera.
Rendering Video	Dukungan untuk rendering video menggunakan Protected Audience dan Fence Frame.	Protected Audience API mendukung rendering video menggunakan mekanisme yang mengandalkan iframe. Namun, kami belum mendesain solusi yang kompatibel dengan Frame dengan Fence, dan ini adalah salah satu alasan kami memutuskan untuk menolak penerapan Frame dengan Fence ke tahun 2026. Artinya, jika partner memutuskan untuk menerapkan Frame dengan Fence sekarang, dukungan untuk video akan kurang bagi partner tersebut.
Pembatasan frekuensi	(Juga dilaporkan pada kuartal sebelumnya) Kontrol frekuensi per pengguna dalam kampanye dan grup iklan.	Respons kami tidak berubah dari laporan sebelumnya: Protected Audience akan mendukung pembatasan frekuensi untuk lelang di perangkat serta kampanye kontekstual dan branding. Penyimpanan bersama dan batas khusus situs juga dapat digunakan untuk kontrol pembatasan frekuensi tambahan.
Preferensi Iklan	Apakah Protected Audience menyediakan cara untuk memilih tidak ikut atau membatalkan daftar yang tidak diizinkan oleh situs pengiklan atau cara untuk keluar dari semua grup minat dari pemilik yang sama?	Ada beberapa cara bagi pengguna untuk memblokir akses ke Protected Audience API dan fitur Privacy Sandbox lainnya.
Kebijakan origin yang sama untuk URL sumber skrip bidding dan lelang	Longgarkan persyaratan bahwa semua kolom yang menentukan URL untuk memuat skrip atau JSON harus berasal dari pemiliknya yang sama.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem ini.
forDebuggingOnly	forDebuggingOnly .reportAdAuctionWin berpotensi disalahgunakan jika tetap setelah 3PCD.	Selama beberapa tahun terakhir, kami telah menerima masukan dari ekosistem terkait kesenjangan fungsi dalam Protected Audience setelah cookie pihak ketiga tidak digunakan lagi, dan kami sedang berupaya menyusun rencana untuk mendukung mereka setelah 3PCD tanpa mengorbankan sasaran Privacy Sandbox. Kami menerima saran dan masukan tambahan tentang fungsi yang hilang yang ingin dilihat oleh ekosistem.
Beberapa Grup Minat	Menggunakan beberapa grup minat dalam bid yang sama.	Saat ini, tindakan ini tidak didukung di Protected Audience API karena akan mengakibatkan perubahan pada model privasi yang mendasarinya. Kami menyambut diskusi tambahan di sini.
Lelang di perangkat	Apakah Chrome di Android akan mendukung lelang Protected Audience di perangkat?	Ya, lelang di perangkat akan didukung di Chrome pada Android.
(Dilaporkan pada Kuartal 2 2023) Data terkait klik	Menambahkan data terkait klik ke browserSignals.	Kami terus mengevaluasi permintaan fitur ini dan menerima masukan tambahan tentang alasan mengapa hal ini harus diprioritaskan.
Penyedia Trusted Execution Environment	Apakah ada perbedaan materi pada penawaran Trusted Execution Environment dari berbagai penyedia cloud?	Kami tidak mengetahui adanya perbedaan utama, tetapi sebaiknya Anda meninjau ekosistem panduan deployment publik untuk melihat solusi yang paling sesuai dengan kebutuhan mereka. Google Cloud. AWS.
(Dilaporkan dalam kuartal sebelumnya) Dukungan untuk penargetan Grup Minat negatif	API untuk mendukung penargetan grup minat negatif: menampilkan iklan hanya jika pengguna bukan anggota grup minat.	Kami sedang mempertimbangkan untuk menerapkan fitur ini dan sedang membahas permintaan tersebut.
Pelanggaran Konten	Mendukung fitur yang memungkinkan pengguna melaporkan iklan tidak baik yang ditayangkan oleh Protected Audience API dalam Frame dengan Fence.	Kami yakin bahwa mekanisme Pelaporan Iklan dengan Fenced Frame yang ada menawarkan opsi yang tepat bagi teknologi iklan yang menginginkan alur pelaporan "Iklan yang Tidak Valid" buatan pengguna. Hal ini akan memungkinkan pelaporan iklan yang tidak baik dengan cara yang sama sekali tidak berubah dari standar industri saat ini. Kami menerima permintaan fitur tambahan jika ada celah yang masih ada, termasuk selama waktu setelah penghapusan cookie pihak ketiga, tetapi sebelum rendering Fenced Frame meluas.
Pelaporan Private Aggregation API	Bagaimana cara menghitung waktu yang dihabiskan pengguna dalam grup minat tersebut?	Di Chrome M116+, Anda dapat menggunakan keterkinian seperti yang didefinisikan pull/639.
Server K-Anonimitas	Informasi selengkapnya tentang server K-Anonymity.	Kami telah membagikan informasi selengkapnya tentang server K-Anonymity di sini dan menerima masukan tambahan.
URL Materi Iklan Dinamis	Dukungan untuk URL materi iklan tanpa deklarasi awal dengan tetap menghormati k-anonymity.	Kami sedang membahas permintaan fitur ini dan menantikan masukan tambahan tentang alasan hal ini harus diprioritaskan.
Persyaratan K-anonymity	Apakah persyaratan k-anonymity pada pembaruan grup Minat akan diperkenalkan kembali?	Kami tidak mengantisipasi perubahan pada posisi yang disebutkan dalam postingan GitHub ini. Seperti yang diumumkan dalam postingan tersebut, kami memutuskan untuk menghapus persyaratan k-anonymity pada update grup minat Protected Audience, yang tidak memiliki dampak signifikan terhadap perlindungan privasi API secara keseluruhan, dan kami berencana untuk mempertimbangkan potensi perlindungan lain yang lebih langsung (seperti privasi alamat IP atau server update tepercaya) di nanti ketika teknologi terkait lebih dikembangkan, di-deploy, dan diadopsi.
Pengujian Beta Layanan Bidding & Lelang	Kapan pengujian Beta Layanan Bidding & Lelang akan dimulai?	Sebagaimana dinyatakan dalam Linimasa dan roadmap, fase pertama pengujian Layanan Bidding dan Lelang dimulai pada November 2023.
Pemblokiran jalan	Permintaan untuk mendukung koordinasi Materi Iklan untuk Jaringan Iklan (SSP dan DSP berada di perusahaan atau properti yang sama).	Kami menghargai masukan Anda untuk kasus penggunaan ini dan kami ingin memahami apakah lebih banyak teknologi iklan tertarik untuk melihat dukungan ini. Kami menantikan masukan tambahan.
Iklan Native	Dukungan Frame Fence untuk Iklan Native.	Kami mempertimbangkan untuk mendukung kasus penggunaan tersebut dan sedang mendiskusikan kemungkinan solusi dan solusi.
K-anonimitas	Bagaimana cara memaksimalkan iklan grup minat yang memenuhi nilai minimum k-anon?	Kami telah membagikan beberapa panduan taktis tentang topik ini.
Dukungan POST	Dukungan untuk mengirim data lelang melalui permintaan POST.	Kami mengevaluasi permintaan fitur ini dan menerima pengiriman masalah GitHub tambahan tentang alasan hal ini harus diprioritaskan.
Perincian pelaporan	Apa tingkat perincian pelaporan pelaporan iklan Frame Berpagar dengan Iklan yang Terdiri dari Beberapa Bagian?	Desain saat ini tidak mengizinkan pengambilan ID atau posisi produk karena hal ini dapat membahayakan privasi pengguna. Hanya reserved.top_navigation yang dapat dipanggil, yang akan dikirim saat ada aktivasi pengguna (seperti klik) pada frame dengan fence komponen iklan, yang menghasilkan navigasi tingkat atas.
Lelang iklan	Dapatkah SSP yang berpartisipasi dalam lelang komponen memicu lelang komponen lain sendiri?	componentSeller tidak boleh menyertakan componentAuctions. Lelang multi-penjual hanya memiliki dua tingkat: 1. Komponen lelang secara paralel. 2 Lelang tingkat teratas (tempat iklan pemenang dari setiap componentAuction bersaing).
Ketersediaan Layanan Bidding & Lelang	Apakah Bidding & Lelang akan tersedia selama fase pengujian yang difasilitasi Chrome?	Server Bidding dan Lelang tidak akan tersedia selama fase pengujian yang difasilitasi Chrome.
Sinyal bidding	Mengizinkan browser meminta dan menghapus sinyal bidding.	Kami sedang membahas permintaan ini dan menerima masukan tambahan tentang alasan hal ini harus diprioritaskan.
generateBid()	Kemampuan untuk memperbarui userBiddingSignals interestGroup melalui updateURL.	Kami sedang mempertimbangkan proposal ini dan menerima masukan tambahan dan diskusi.
Jenis Inventaris Penayang	Apa saja jenis inventaris penayang yang akan didukung oleh pengujian Protected Audience dan TOPICS?	Protected Audience atau Topics tidak memiliki batasan inheren dalam hal jenis inventaris yang dapat digunakan.
Integrasi Server ke Server	Apakah integrasi langsung antara SSP dan DSP diperlukan untuk Protected Audience?	Integrasi langsung antara SSP dan DSP tidak diperlukan jika DSP tidak perlu memproses sinyal kontekstual di servernya sendiri untuk meneruskan informasi yang telah diproses tersebut ke fungsi bidding di perangkatnya.
Kolom bid_currency di B&A	Dukungan untuk kolom bid_currency di Layanan Bidding dan Lelang.	B&A belum mendukung bid_currency, meskipun kami berencana untuk mendukungnya pada akhir Januari 2024. Lihat linimasa di sini.
perBuyerSignals	Apakah ada batas ukuran untuk perBuyerSignals?	Tidak ada batas jumlah sinyal per pembeli, tetapi pengiriman data yang terlalu banyak dapat berdampak buruk pada performa browser.
Kasus penggunaan lintas situs	Dapatkah kami menggunakan grup minat Protected Audience API di beberapa situs?	Protected Audience tidak dirancang untuk kasus penggunaan tersebut, seperti yang dijelaskan dalam turtledove/issues/282.
Permintaan HTTP Grup Minat	Menyertakan Blob Grup Minat di header HTTP.	Kami mempertimbangkan permintaan ini dan menerima masukan lainnya terkait permintaan ini.
Kontrol kualitas iklan	Hilangnya kontrol kualitas iklan yang terkait dengan informasi lintas situs.	Kami mempertimbangkan masukan ini dan menerima masukan tambahan.
Chrome DevTools	Permintaan jaringan Protected Audience yang keluar harus terlihat di Tab Jaringan Chrome Developer Tools.	Kami sedang berupaya mengaktifkan fungsi ini di tab jaringan dan menerima masukan tambahan tentang alasan hal ini harus diprioritaskan.
Trusted Execution Environment	Kapan detail tentang metrik mana yang berdampak pada privasi (dan tingkatnya) akan ditambahkan ke penjelasan tentang pemantauan Lingkungan Eksekusi Tepercaya?	Kami sedang dalam proses memperbarui penjelasan dengan informasi ini. Penjelasan yang diperbarui akan tersedia paling lambat November 2023.
directFrom SellerSignals	Mengapa directFrom SellerSignals tidak dikemas sebagai paket web?	Kami membagikan alasan keputusan ini di sini.
Delegasi tayangan	Apakah ada cara yang layak untuk melakukan pendelegasian tayangan jika hasil grup minat yang dipilih hanyalah tindakan penargetan lain?	Beberapa lelang bertingkat tidak kompatibel dengan sasaran privasi kami karena dua alasan. Pertama, saat pemenang lelang merender ke dalam Fenced Frame, sasaran privasi kami untuk Protected Audience mencakup rendering materi iklan yang dihasilkan tanpa mengetahui konteksnya: URL halaman atau cookie pihak pertama di sekitar merupakan pelanggaran privasi. Dalam lingkungan tersebut, lelang bertingkat tidak memungkinkan. Kedua, model Protected Audience mengatakan bahwa setiap pemenang lelang harus didasarkan pada data hanya dari satu situs tambahan. Lelang bertingkat akan menjadi cara untuk menggabungkan hal tersebut, sehingga memungkinkan pemilihan iklan berdasarkan profil banyak situs.
Kriteria Data dalam Istirahat	Menjelaskan lebih lanjut kriteria Data dalam Istirahat dalam model kepercayaan layanan Kunci/Nilai.	Data di Key Value Service dimuat ke dalam memori dan disajikan dari sana, bukan melakukan cache baca-tayang.
Sinyal Data Pembeli	Apakah ada batas ukuran yang ditentukan untuk sinyal buyer_data yang diterima dari DSP?	Saat ini, browser tidak memberlakukan batas untuk sinyal buyer_data yang diterima dari DSP.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Lintas-perangkat	Merencanakan dukungan lintas perangkat untuk Attribution Reporting API.	Lintas perangkat menghadirkan tantangan privasi baru selain 3PC dan juga menambahkan tantangan distribusi teknologi mengingat berbagai perangkat dan platform yang mungkin digunakan pengguna. Kami sedang mempelajari berbagai kemungkinan solusi, tetapi berfokus pada kasus penggunaan penting yang saat ini didukung oleh Attribution Reporting dan tidak berencana memberikan dukungan lintas perangkat sebelum penghapusan cookie pihak ketiga.
(Juga dilaporkan pada kuartal sebelumnya) Ukuran Data Pemicu	Mengapa ukuran data pemicu dibatasi hingga 3 bit?	Ukurannya dibatasi hingga 3 bit dan 8 nilai yang berbeda untuk memastikan jumlah informasi lintas situs dan lintas konteks tentang pengguna dibatasi. Kami mempersilakan pemain ekosistem untuk mengirimkan masukan terkait apakah parametrisasi saat ini untuk pelaporan tingkat peristiwa sudah memadai.
Funnel konversi	Laporkan beberapa domain yang digunakan dalam konversi.	Kasus penggunaan ini dapat terjadi karena penambahan beberapa tujuan. Kami menerima masukan tambahan.
Dukungan untuk domain yang sama di negara yang berbeda	Apakah Attribution Reporting berfungsi dengan situs yang memiliki Domain yang sama, tetapi beberapa TLD negara?	Masalah ini telah didiskusikan dan diselesaikan dengan pemangku kepentingan yang mengajukan pertanyaan ini. Jika teknologi iklan perlu menggunakan beberapa TLD negara, teknologi iklan harus memiliki beberapa pendaftaran, dengan satu untuk setiap TLD negara.
Protected Audience dan Attribution Reporting	Dapatkah teknologi iklan mengakses konversi lihat-tayang untuk lelang Audiens yang Dilindungi serta konversi klik-tayang untuk Attribution Reporting?	Ya, Privacy Sandbox harus mendukung VTC dan CTC dalam Protected Audience.
Keterlambatan laporan agregat	Mengurangi lebih lanjut penundaan laporan gabungan.	Kami telah mendengar masukan terbaru terkait hal ini dan telah membagikan ide di sini. Kami menerima masukan tambahan dari ekosistem ini.
Keterlambatan laporan agregat	Mengurangi penundaan dengan memperkenalkan mediasi server.	Kami sedang mempertimbangkan proposal ini dan menerima masukan tambahan .
Keterlambatan laporan tingkat peristiwa	Kurangi penundaan laporan tingkat peristiwa.	Proposal tingkat peristiwa fleksibel penuh, yang dijelaskan dalam Konfigurasi tingkat peristiwa fleksibel, dapat mengurangi penundaan pelaporan tingkat peristiwa hingga 1 jam dengan kompromi derau.
Asal pelaporan sumber per sumber	Pembatasan asal pelaporan sumber maksimum per situs pelaporan sumber mencegah teknologi iklan mendaftarkan sumber dari asal pelaporan yang berbeda untuk satu asal penayang.	Hal ini telah didiskusikan dengan pemangku kepentingan yang mengangkat masalah ini dan solusi potensial penggunaan 1 asal pelaporan per situs pelaporan sumber akan diuji sebelum mencoba solusi potensial lain yang melibatkan pengalihan. Kami juga terbuka untuk menerima masukan ekosistem tambahan terkait batasan ini.
Pelaporan masalah	Bagaimana cara melaporkan error atau masalah terkait Attribution Reporting API ke Chrome?	Saat ini, kami merekomendasikan teknologi iklan untuk melaporkan error Attribution Reporting API apa pun yang mungkin dihadapi sebagai Masalah di GitHub. Jika mereka mengalami masalah terkait Chrome, sebaiknya buat bug Chromium. Link tentang cara dan tempat untuk melaporkan masalah dapat ditemukan di Berinteraksi dan membagikan masukan.
Penghapusan Duplikat	Bagaimana cara menghapus duplikat konversi di berbagai pipeline dan perangkat?	Menduplikasi di seluruh perangkat dan pipeline pengukuran merupakan tantangan umum dan saat ini yang juga dihadapi teknologi iklan saat ini dengan 3PC. Dengan Attribution Reporting API, teknologi iklan dapat memutuskan kapan harus mendaftarkan konversi tertentu dan menambahkan metadata tertentu untuk menunjukkan pipeline pengukuran mana yang telah mereka gunakan untuk melacak konversi (dengan kata lain, bagian dari kunci agregasi), yang dapat dibandingkan dengan pipeline pengukuran lainnya. Kami terbuka untuk menerima masukan ekosistem tambahan terkait hal ini.
Penghapusan duplikat dan Prioritas	Minta agar memiliki prioritas terlebih dahulu sebelum penghapusan duplikat.	Kami mempertimbangkan permintaan ini dan menerima masukan tambahan.
Antipenipuan	Risiko pengguna berbahaya merusak data tingkat peristiwa.	Verifikasi laporan tidak berfungsi untuk pelaporan tingkat peristiwa untuk alasan yang dijelaskan dalam Mengapa ini tidak mendukung laporan tingkat peristiwa?.
Jenis konversi	Bagaimana cara membedakan antara lihat-tayang dan navigasi di Attribution Reporting?	Kita memiliki opsi pemfilteran bawaan berikut: source_type. Detail tambahan tersedia di sini.

Layanan Agregasi

Tema Masukan	Ringkasan	Respons Chrome
Pemulihan anggaran	Beberapa teknologi iklan telah meminta kemampuan untuk memproses ulang laporan jika terjadi kegagalan, error, atau penghapusan laporan.	Tim sedang mencari cara untuk mengatasi hal ini dengan cara yang menjaga privasi.
Pendaftaran situs	Beberapa teknologi iklan telah meminta dukungan untuk memproses beberapa asal dalam akun yang sama untuk kasus penggunaan seperti memisahkan data menurut Geografis, pengiklan. Perilaku ini juga diharapkan oleh teknologi iklan mengingat pendaftaran API klien kini berbasis situs (dan bukan berbasis asal). Migrasi dari asal ke pendaftaran situs menyederhanakan proses orientasi teknologi iklan melalui konsistensi dengan proses pendaftaran klien.	Kami akan segera meluncurkan migrasi dari pendaftaran asal ke pendaftaran situs untuk Layanan Agregasi dan menerima masukan dari ekosistem.
Paket Rilis & Penghentian Penggunaan	Jadwal rilis dan depresiasi untuk fitur dan patch Layanan Agregasi yang dipublikasikan. Tujuan rencana ini adalah untuk memberi teknologi iklan visibilitas ke dalam kebijakan rilis kami agar mereka dapat mempersiapkan rilis dan penghentian penggunaan mendatang, serta memastikan teknologi iklan menjalankan versi layanan yang stabil dan aman.	Baru-baru ini kami memublikasikan proposal untuk rencana rilis dan penghentian penggunaan Layanan Agregasi dan menerima masukan tambahan.
Koordinator	Apa yang terjadi jika koordinator berhenti menggunakan layanan agregasi?	Kedua koordinator harus tersedia sepenuhnya agar sistem dapat berfungsi dengan benar. Ketidaktersediaan yang singkat diakomodasi dengan percobaan ulang di library klien kami; jika salah satu dari kedua koordinator tidak tersedia, tugas agregasi akan gagal. Tugas dapat dijalankan kembali jika anggaran untuk privasi belum dipakai. Jika kegagalan layanan menyebabkan penggunaan anggaran tanpa laporan ringkasan yang ditulis ke penyimpanan teknologi iklan, sebaiknya gunakan laporan debug untuk mengambil hasil menggunakan alat pengujian lokal. Kami juga sedang membuat fitur untuk memungkinkan pemulihan anggaran jika terjadi kegagalan, sehingga teknologi iklan dapat menjalankan kembali tugasnya.

API Agregasi Pribadi

Tema Masukan	Ringkasan	Respons Chrome
URL Blob	Permintaan untuk mendukung Url Blob di Penyimpanan Bersama.	Dukungan untuk URL Blob telah ditambahkan di Chrome M116.

Batasi Pelacakan Terselubung

Pengurangan Agen Pengguna dan Petunjuk Klien Agen Pengguna

Tema Masukan	Ringkasan	Respons Chrome
JavaScript API	Ketersediaan User Agent Client Hints JavaScript API.	Tidak ada rencana untuk menghapus fungsi ini karena ini adalah solusi inti kami bagi partner yang ingin secara aktif mengakses data entropi tinggi selain dari yang tersedia secara default di UA yang dibekukan dan dikurangi.
Informasi Perangkat dan Faktor Bentuk	Kemampuan situs untuk memahami input, output, dan informasi lain yang dapat didukung perangkat yang mengunjungi situs.	Kami telah menambahkan dukungan untuk permintaan ini setelah masukan dari ekosistem.

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
Traffic Pihak Ketiga yang Memenuhi Syarat	Apa yang dimaksud dengan "traffic pihak ketiga yang memenuhi syarat" dalam penjelasan?	Kami memahami pentingnya pertanyaan ini dan berupaya secara aktif untuk mengidentifikasi traffic pihak ketiga mana yang memenuhi syarat dan mana yang tidak. Kami menantikan masukan tentang topik ini.
Audit Traffic Jaringan	Dukungan bagi perusahaan untuk melakukan audit traffic jaringan untuk jaringan mereka.	Hanya traffic pihak ketiga yang disematkan di situs pihak pertama yang akan terpengaruh, sehingga akan membatasi jumlah traffic yang memerlukan pemfilteran. Selain itu, kami berencana memberi pengguna opsi untuk menggunakan Perlindungan IP atau tidak, dan untuk Chrome yang dikontrol perusahaan, akan ada kebijakan perusahaan untuk menonaktifkan Perlindungan IP. Terakhir, kita sedang mempelajari kontrol apa (jika ada) yang akan diberikan kepada operator jaringan untuk menonaktifkan Perlindungan IP. Kami menantikan masukan tentang topik ini.
Kontrol akses	Perlindungan IP dapat memengaruhi layanan web yang menggunakan alamat IP untuk kontrol akses.	Kami memahami pentingnya kasus penggunaan antipenipuan dan kemungkinan dampaknya terhadap kasus penggunaan tersebut. Kami mencari masukan ekosistem tentang bagaimana kami dapat mendukung kasus penggunaan antipenipuan dengan lebih baik yang biasanya mengandalkan alamat IP.
Komunikasi antara {i>proxy<i} 2-Hop	Cara memastikan tidak ada informasi di antara proxy.	Kita sedang dalam proses merancang interaksi {i>proxy<i}. Tujuan kami adalah meminimalkan peluang pembagian informasi tersebut melalui sarana bisnis, proses, dan teknis.
Autentikasi Non-Google	Dukungan untuk Autentikasi Non-Google.	Kami berencana untuk memublikasikan lebih banyak detail tentang autentikasi akun di masa mendatang, meskipun kami telah memberikan beberapa pertimbangan awal.
Klasifikasi pelacak	Bagaimana Perlindungan IP menentukan apa yang dimaksud dengan pelacak dan variannya?	Kami memahami pentingnya pertanyaan ini dan berupaya secara aktif untuk mengidentifikasi traffic pihak ketiga mana yang memenuhi syarat dan mana yang tidak. Kami menantikan masukan tentang topik ini.
Analytics	Perlindungan KI dapat memengaruhi akurasi layanan analisis.	Kami ingin memahami dampak Perlindungan Kekayaan Intelektual lebih lanjut dan menerima masukan serta contoh tambahan dari ekosistem.
Proxy	Jika pengguna menggunakan proxy atau telah menentukan proxy secara manual, bagaimana cara kerja IP Mask dalam kasus ini?	Kami ingin memahami dampak yang mungkin diakibatkan oleh Perlindungan IP terhadap proxy lainnya. Saat ini belum ada rencana yang dapat kami sampaikan. Kami menerima masukan tentang topik ini.
Penawaran premium	Apakah Perlindungan IP akan menjadi fitur berbayar?	Perlindungan IP akan tersedia untuk pengguna Chrome sebagai bagian dari pengalaman browser inti. Video tersebut tidak akan menjadi fitur berbayar.
{i>Proxy<i}	Apakah server proxy yang sama akan digunakan selama sesi pengguna?	Koneksi HTTP/S akan menggunakan sepasang proxy dan akan memberikan satu alamat IP yang disamarkan ke asalnya. Selain itu, tidak ada batasan yang sulit pada koneksi HTTP/S yang berbeda yang harus menggunakan server yang sama.
Dukungan platform	Di platform manakah Perlindungan IP akan didukung?	Perlindungan IP pada awalnya akan tersedia di Chrome untuk Android dan Desktop. Kami terus mengevaluasi cara memperluas perlindungan ke platform lain.
Nonaktifkan	Apakah pengguna dapat menonaktifkan Perlindungan IP?	Kami berencana memberi pengguna pilihan untuk menggunakan Perlindungan IP atau tidak.
Anonimisasi	Jenis permintaan apa yang akan dianonimkan berdasarkan Perlindungan IP?	Permintaan HTTP/S dan DNS ke domain pihak ketiga yang memenuhi syarat dianonimkan melalui proxy privasi. Kami akan memberikan detail tambahan dalam penjelasan mendatang tentang cara kami menentukan domain yang akan disertakan. Traffic lainnya (misalnya, permintaan DNS lainnya atau traffic HTTP/S lainnya) tidak akan terpengaruh.
Visibilitas Data	Alamat jaringan dapat diakses selama hop pertama di Perlindungan IP.	Dalam model proxy dua hop, hop pertama (dikontrol oleh Google) hanya melihat IP klien sumber dan permintaan untuk terhubung ke hop kedua, sedangkan hop kedua (dikontrol oleh CDN eksternal) hanya melihat tuple pada hop pertama (IP + port proxy) dan IP tujuan. Untuk respons kembali dari asal, hop kedua dapat meneruskan respons ke proxy+port hop pertama yang terkait dengan permintaan dan tidak perlu mempelajari apa pun tentang IP klien asli (dan hop pertama hanya menampilkan respons ke klien, tanpa mempelajari apa pun tentang IP tujuan). Dengan cara ini, hop pertama hanya mempelajari IP klien dan hop kedua, sedangkan hop kedua hanya mempelajari IP tujuan.
WebView	Apakah Perlindungan IP akan tersedia untuk Android WebView di masa mendatang?	Saat ini kami tidak memiliki rencana untuk dibagikan, tetapi visi kami adalah memberikan perlindungan ini seluas mungkin.

Mitigasi Pelacakan Kembali

Tema Masukan	Ringkasan	Respons Chrome
Pelacakan Interaksi	Bagaimana interaksi pengguna dilacak?	Mitigasi pelacakan kembali melacak dua jenis interaksi pengguna: Aktivasi pengguna sebagaimana ditetapkan oleh spesifikasi html. Pada dasarnya, ini adalah klik, penekanan tombol, ketukan layar sentuh, dll. Pernyataan webauth berhasil. Ini adalah kasus saat pengguna mengetuk kunci keamanan atau menggunakan kunci sandi sebagai bentuk autentikasi Interaksi ini dikaitkan dengan situs tingkat teratas di halaman tempat interaksi tersebut terjadi. Misalnya, jika pengguna mengklik dalam iframe tersemat, interaksi dikaitkan dengan situs tingkat teratas, bukan situs tersemat. Interaksi disimpan di database yang berisi skema etld+1 dan waktu interaksi. Interaksi melindungi domain terkait dari penghapusan status mitigasi pelacakan pantulan selama 45 hari.
Pengecualian yang Diizinkan	Apakah domain dapat dikecualikan?	Kami mempertimbangkan permintaan ini dan kami menerima masukan tambahan dari ekosistem.

Anggaran Privasi

Tidak ada masukan yang diterima untuk kuartal ini.

Memperkuat batas privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tema Masukan	Ringkasan	Respons Chrome
Pendekatan Terpusat	Memperhatikan pendekatan repositori terpusat untuk mengelola Set Situs Terkait.	Repositori publik yang mudah diakses adalah kunci untuk desain RWS karena memberikan akuntabilitas atas pengiriman. Fungsi cookie pihak ketiga pada akhirnya disediakan oleh penggunaan Storage Access API atau rSAFor API, dengan keanggotaan RWS yang menyediakan akses yang diberikan secara otomatis (bukan melalui perintah dengan Storage Access API). Kami percaya bahwa pendekatan seperti proses pengiriman RWS merupakan persyaratan yang sesuai untuk akses cookie pihak ketiga yang diberikan secara otomatis.
Mengganti nama file JSON	Dengan perubahan nama API, apakah nama file JSON yang dihosting perlu diubah?	Ya, panduan pengiriman telah diubah, dan domain primer harus menayangkan file JSON di /.well-known/related-website-set.json. Set yang ada dalam daftar RWS tidak perlu diubah, tetapi jika ada modifikasi yang dikirimkan ke set yang ada, file JSON harus diubah.
(Juga dilaporkan pada kuartal sebelumnya) Batas Domain	Permintaan untuk menambah jumlah domain terkait	Seperti yang diumumkan di postingan blog pada 31 Agustus, kami telah menaikkan batas domain terkait menjadi lima domain setelah menerima masukan dari ekosistem tersebut. Kami memutuskan untuk meningkatkan batas domain terkait menjadi lima domain (ditambah satu domain primer) yang paling cocok dengan penerapan paling sebanding yang ditawarkan oleh browser besar lainnya.
Cookie Pihak Ketiga	Apakah Set Situs Terkait hanya akan berfungsi dengan cookie pihak ketiga yang dinonaktifkan?	Set Situs Terkait akan berfungsi meskipun pengguna belum memblokir cookie pihak ketiga; tetapi tidak akan ada efek yang dapat diamati karena cookie yang relevan tersedia tanpa memerlukan Set Situs Terkait dan Storage Access API.
Pengeditan yang sah	Bagaimana cara repositori Set Situs Terkait mencegah pengguna non-pemilik mengubah kumpulan?	Sesuai panduan pengiriman, siapa pun dapat mengirimkan PR di GitHub untuk mengedit file first_party_sets.JSON. Namun, jika PR disetujui (lulus validasi teknis, dan sebagainya), PR akan digabungkan secara manual dalam beberapa batch ke daftar FPS kanonis sekali per minggu (Selasa pukul 12.00 Waktu Timur) oleh Google. Jika pihak tidak bertanggung jawab mencoba mengubah kumpulan yang bukan milik mereka, hal tersebut seharusnya tidak menjadi masalah karena dia tidak akan dapat mengubah file .well-known sehingga validasi akan gagal.
Pembajakan domain	Pembajakan domain dapat mengekspos data domain terkait kepada pihak yang tidak sah.	Hal ini tidak mungkin, seperti yang telah dibahas dalam masalah GitHub Protected Audience ini.

API Fenced Frames

Tema Masukan	Ringkasan	Respons Chrome
Pelanggaran Konten	Izinkan pengguna melaporkan iklan yang mencurigakan.	Pelaporan iklan yang mencurigakan tidak dicegah oleh Fenced Frames. Pengguna masih dapat berinteraksi dengan iklan dan melaporkan iklan yang mencurigakan ke teknologi iklan seperti biasa.
Interaksi dengan situs di sekitarnya	Izinkan interaksi dengan {i>website<i} tingkat atas atau di sekitarnya.	Kami ingin memahami mengapa permintaan ini diperlukan dan menerima masukan tambahan dari ekosistem.
Iklan Native	Dukungan Frame Fence untuk Iklan Native.	Kami mempertimbangkan untuk mendukung kasus penggunaan tersebut dan sedang mendiskusikan kemungkinan solusi dan solusi.

API Penyimpanan Bersama

Tema Masukan	Ringkasan	Respons Chrome
Lintas-domain	Mengizinkan komunikasi di seluruh domain untuk penyimpanan lokal.	Kasus penggunaan ini saat ini tidak sejalan dengan gerbang output yang menjaga privasi dari Penyimpanan Bersama, tetapi kami menerima konteks tambahan selagi kami mengembangkan proposal untuk penyimpanan tanpa partisi.
URL Blob	Permintaan untuk mendukung Url Blob di Penyimpanan Bersama.	Dukungan untuk URL Blob telah ditambahkan di Chrome M116.

CHIP

Tidak ada masukan yang diterima untuk kuartal ini.

FedCM

Tema Masukan	Ringkasan	Respons Chrome
Cookie pihak ketiga	Apakah FedCM saat ini dinonaktifkan jika pengguna mengaktifkan "Blokir cookie pihak ketiga" di setelan Chrome"?	Ya, FedCM saat ini dinonaktifkan. Untuk pengujian, sebaiknya Anda juga mengaktifkan chrome://flags/#fedcm- without-third-party-cookies. Kami ingin mendukung FedCM tanpa cookie pihak ketiga di masa mendatang.

Memerangi spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Akhir masa berlaku token	Setelah Google Chrome di-uninstal, apakah Token akan hilang atau disimpan di cache?	Token akan hilang jika pengguna meng-uninstal Google Chrome.
Informasi Token	Bagaimana penerbit dapat menjaga informasi yang diterbitkan dalam Token Status Pribadi tetap pribadi?	Informasi selalu dirahasiakan dalam token dan tidak dapat dienkripsi oleh pihak eksternal yang tidak memiliki kunci.
Error dalam demo	Terjadi error saat mencoba menjalankan demo Token Status Pribadi.	Kami telah memperbarui demo dan kini seharusnya sudah berfungsi dengan benar.