Halaman ini diterjemahkan oleh Cloud Translation API.

Laporan Masukan - Kuartal 3 2023
bookmark_border Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Laporan kuartalan untuk K3 2023 yang 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) dari Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima 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

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
PatCG: Grup Komunitas Teknologi Iklan Pribadi
RP: Relying Party/Pihak yang Mengandalkan
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 atau Teknologi tertentu

Tema Masukan	Ringkasan	Respons Chrome
Kesiapan ekosistem	SSP menyoroti masalah terkait penayang yang belum siap dan tidak melakukan pekerjaan deployment yang diperlukan.	Privacy Sandbox memiliki jangkauan yang berfokus secara khusus untuk mengedukasi penayang, yang mencakup webinar dan pertemuan khusus dengan penayang dan SSP yang hadir untuk mendorong pekerjaan deployment.
Penghentian cookie pihak ketiga	Kekhawatiran terkait penghentian penggunaan cookie pihak ketiga (3PCD) meningkat pada Kuartal 4 2023 karena pemadaman teknologi industri.	Linimasa untuk Privacy Sandbox telah dibahas dengan CMA, dengan urutan yang mengarah ke kesiapan 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 pengujian menjadi sulit.	Respons yang diberikan oleh Google Ad Manager: Karena alasan yang dijelaskan dalam respons ini oleh Google Ad Manager, rencana Google Ad Manager untuk integrasi Protected Audience API-nya tidak mencakup dukungan untuk server iklan penayang Google tanpa kontrol atas lelang tingkat teratas.
Google Ad Manager	Google Ad Manager memiliki harga minimum rahasia yang hanya ditampilkan ke SSP AdX atau Bidding Terbuka.	Dokumentasi publik Google Ad Manager menyatakan bahwa pemenang lelang kontekstual diteruskan ke logika penskoran tingkat atas, 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 dari setiap lelang komponen, termasuk lelang komponen Ad Manager sendiri untuk bid grup minat dari 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 dengan produk iklan pihak ketiga.	Produk Google Ads sudah tunduk pada aturan yang sama seperti pihak ketiga.
Pengujian yang difasilitasi Chrome	Tambahkan label untuk browser yang tidak ada di A atau B.	Saat ini kami tidak mempertimbangkan untuk melakukannya, karena penyelidikan kami telah 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 API Privacy Sandbox?	Siapa pun dapat memanggil Privacy Sandbox API. Jika agensi atau orang lain ingin membuat teknologi langsung di API, mereka dapat melakukannya. 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, membuat integrasi sisi klien dengan API. Organisasi lain juga dapat melakukan hal yang sama.
Solusi Sisi Klien	Mengapa Google mengadopsi solusi sisi klien untuk Privacy Sandbox padahal seorang engineer sebelumnya telah menyatakan kekhawatiran tentang skalabilitas solusi tersebut pada tahun 2012?	Teknologi peningkat privasi (PET) sebagai bidang studi telah berkembang secara signifikan sejak tahun 2012 dan, dengan itu, aplikasi yang layak secara komersial. Inti dari Privacy Sandbox adalah kombinasi PET yang tidak akan mungkin dilakukan lebih dari satu dekade yang lalu. Selain itu, kemampuan komputasi pribadi telah meningkat, begitu pula ekspektasi konsumen terhadap browser dan ekspektasi peraturan terkait privasi.
Machine Learning	Apa rencana penggunaan Privacy Sandbox Google untuk tujuan pemelajaran mesin?	Saat ini, sebagian besar ekosistem teknologi iklan menggunakan machine learning dan kami tidak mengharapkan hal itu berubah. Privacy Sandbox tidak mencegah perusahaan teknologi iklan atau orang lain untuk terus menggunakan machine learning. Privacy Sandbox juga tidak mewajibkan perusahaan yang berintegrasi dengan API-nya menggunakan machine learning. Perusahaan akan terus membuat produk dan layanan dengan cara yang memenuhi kebutuhan pelanggan, baik yang mencakup machine learning maupun tidak. Setiap machine learning yang dibuat oleh integrator Privacy Sandbox akan jelas diketahui oleh mereka sehingga tidak akan disamarkan.
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)?	Privacy Sandbox API dibuat dalam platform open source yang mendukung Chrome. Bagian API yang dimaksudkan untuk berjalan di Trusted Execution Environments juga bersifat open source dan dapat diaudit. Siapa pun yang ingin memeriksa kode dapat melakukannya, termasuk MRC.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan Produksi	Apa proses yang diterapkan untuk Chrome guna mendukung masalah teknis dan eskalasi 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 lebih membangun dan menskalakan proses untuk menyelesaikan masalah teknis dan eskalasi yang memengaruhi kesehatan ekosistem. Chrome berkomitmen untuk memastikan resource untuk upaya ini. Lihat forum publik dan pribadi kami untuk mendapatkan masukan dan melakukan eskalasi.
Mode pengujian yang difasilitasi Chrome	Informasi selengkapnya tentang linimasa dan penerapan yang tepat untuk mode pengujian yang difasilitasi Chrome.	Kami telah membagikan postingan blog tentang mode pengujian dan sedang berupaya untuk segera membagikan informasi selengkapnya. Kami menerima saran untuk ukuran label mode pengujian.
Integrasi dengan standar industri lainnya	Apakah Privacy Sandbox API akan terhubung ke salah satu atau kedua TCF v2.* dan Mode Izin?	Kami tidak memiliki rencana untuk mengintegrasikan Privacy Sandbox API secara langsung dengan TCF v2 atau Mode Izin. Namun, perusahaan dan kelompok perdagangan industri dapat menyesuaikan produk dan framework mereka agar dapat 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 kapan dan cara menggunakan berbagai fungsi yang ditawarkan oleh elemen penyusun Privacy Sandbox kami.

Pendaftaran & Pengesahan

Tema Masukan	Ringkasan	Respons Chrome
Batasan	Proses pendaftaran berarti Google dapat memutuskan perusahaan mana dalam ekosistem yang diizinkan untuk menggunakan API Privacy Sandbox.	Proses Pendaftaran dan Pengesahan pada dasarnya memerlukan verifikasi entitas (misalnya, entitas memiliki nomor DUNs, 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 gratis yang dipercepat dengan Dun & Bradstreet untuk mendapatkannya. Tujuannya adalah untuk meningkatkan perlindungan privasi API (dengan langkah-langkah yang baru saja disebutkan) dan juga untuk menambahkan lapisan transparansi ke Privacy Sandbox API, sehingga pihak yang berkepentingan dapat lebih memahami siapa yang menggunakan API mana dan pengesahan apa yang mereka buat. Kami terbuka untuk mendapatkan masukan lebih lanjut dari industri terkait masalah ini, yang telah digunakan untuk membentuk prosesnya.
Overhead pendaftaran ulang	Masa berlaku file pengesahan berakhir setiap 12 bulan dan mengharuskan situs untuk mendaftar ulang.	Kami telah mendengar masukan dari ekosistem dan mengubah pendekatan kami sesuai dengan masukan tersebut. Artinya, file tidak akan lagi berakhir masa berlakunya setelah 12 bulan atau periode waktu yang ditetapkan. Kami memperbarui panduan developer pendaftaran kami dengan konteks tambahan.
File pengesahan	Bagaimana cara file pengesahan digunakan?	Semua perusahaan yang memanggil API relevansi dan pengukuran akan diwajibkan menjelang batas waktu penerapan untuk mengupload file pengesahan di situs mereka dan menyimpannya untuk dilihat publik selama Anda ingin terus memanggil API. Situs dapat menerima sekitar satu permintaan per jam dari Privacy Sandbox, dan entitas potensial lainnya juga dapat membuat kueri. Hal ini akan dilakukan melalui mekanisme sistem pendaftaran sendiri untuk membuat kueri server entitas terdaftar dan memastikan file pengesahan valid. Pengesahan akan disertakan dalam Laporan Transparansi dan dapat dilihat oleh masyarakat umum. Kami berharap perusahaan bertindak sesuai dengan pernyataan pengesahan mereka, seperti halnya seluruh ekosistem dan lembaga pengatur yang relevan.
Pendaftaran	Apakah pendaftaran per situs atau per origin?	Pendaftaran dilakukan di tingkat situs.

Menampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Performa	Masalah performa terkait dampak rasio keikutsertaan Topics di Wilayah Ekonomi Eropa.	Sebaiknya pemangku kepentingan yang bersangkutan menghubungi Otoritas Perlindungan Data yang relevan terkait masalah ini. Mereka berada dalam posisi terbaik untuk menangani kekhawatiran tersebut dan memengaruhi apakah penerapan teknologi peningkatan privasi diberi insentif oleh hukum atau diperlakukan seperti pelacakan, yang memerlukan pendekatan yang sama untuk izin. Hal terakhir ini dapat menyebabkan API seperti yang ada di Privacy Sandbox tidak sering tersedia.
Pendaftaran	Apakah bidder downstream perlu mendaftar ke 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 didaftarkan untuk penggunaan API lainnya. Daftar peserta Privacy Sandbox akan disediakan secara terprogram sebagai bagian dari upaya transparansi program, yang akan memungkinkan pemanggil yang tertarik dengan Topics API untuk memeriksa apakah penerima yang menerima topik darinya telah terdaftar, jika pemanggil ingin melakukannya.
Pemfilteran topik	Minta untuk menerapkan pemfilteran pemanggil lain ke topik yang mereka ambil di halaman, agar hanya membagikan hal yang memenuhi syarat untuk diambil oleh pembeli.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem.
Pengecualian situs	Mengecualikan situs agar tidak berkontribusi pada Topik pengguna.	Topik tidak dipanggil secara default. Perlu diperhatikan bahwa tidak ada konten halaman yang diperhitungkan saat topik dipilih, dan semua topik diseleksi untuk memastikan topik tersebut tidak sensitif. Situs juga dapat membatasi situsnya agar tidak disertakan dalam penghitungan topik melalui header kebijakan izin berikut: `Permissions-Policy: browsing-topics=()`
Pengamatan topik	Mengizinkan penayang memberikan izin agar Chrome dapat mengklasifikasikan topik berdasarkan konten halaman (misalnya, judul atau isi).	Sebelumnya, kami mempertimbangkan untuk menawarkan fungsi untuk mengklasifikasikan situs ke dalam topik berdasarkan konten halaman, dan memutuskan untuk tidak melanjutkannya berdasarkan masalah privasi dan keamanan. Proposal ini dapat memitigasi beberapa kekhawatiran tersebut, tetapi tidak jelas sejauh mana. Karena periode eksperimen CMA mendatang, kami tidak memperkirakan perubahan ini akan terjadi sebelum 3PCD. Kami menerima masukan tambahan di sini.
Pengamatan topik	Memberikan kebijakan izin yang lebih terperinci untuk penayang.	Dengan menyediakan kebijakan izin yang lebih terperinci untuk penayang, situs penayang dapat berdampak negatif pada utilitas Topics API untuk ekosistem secara keseluruhan, tanpa berdampak negatif pada utilitas Topics API untuk situs itu sendiri. Lihat masalah GitHub Memperbarui kebijakan izin untuk mendukung izin terpisah untuk mengambil dan mengamati untuk diskusi yang lebih mendetail tentang topik ini.
Topik Medis dan Kesehatan	Mengapa taksonomi Topik tidak mencakup topik dalam kategori Medis atau Kesehatan?	Kategori medis dan kesehatan dianggap sebagai topik sensitif sehingga dikecualikan dari taksonomi Topik.
Pengambilan topik	Cara yang lebih cepat bagi DSP untuk mendapatkan Topics tanpa mengambil menggunakan header.	Metode header memiliki performa yang lebih baik dan lebih murah daripada membuat iframe lintas origin dan melakukan panggilan `document.browsingTopics()` darinya. (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 perspektif keamanan, hal ini tidak mungkin. Setiap dokumen dan lingkungan eksekusinya dikaitkan dengan satu origin, yaitu origin dokumen. Sub-resource pihak ketiga yang dimuat dan dieksekusi dalam lingkungan yang sama 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>`. Hal ini harus bersih dari perspektif keamanan, dan tidak menambahkan latensi tambahan. Kami terbuka untuk menerima masukan dari pihak yang berminat.
Awareness	Meningkatkan kesadaran publik tentang Topics API dan cara API akan digunakan.	Kami telah menghubungi 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 pandangan dari pemangku kepentingan. Sementara itu, kami menyarankan pemangku kepentingan yang ingin mengetahui lebih lanjut tentang Topics API untuk memahami dokumentasi di panduan developer Chrome.
Notifikasi	Notifikasi untuk memberi tahu pengguna saat Topik mereka diamati oleh situs.	Kami menangani 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 Topik karena cara browser menghitungnya.	Hanya teknologi iklan yang mengamati pengguna 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 membatasi ketersediaan informasi tentang pengguna hanya kepada pihak yang sudah dapat mengamati informasi dasar yang sama (saat ini melalui cookie pihak ketiga).
Permintaan XHR	Kapan penyertaan Topics dalam permintaan `XMLHttpRequest` (XHR) tidak digunakan lagi?	Seperti yang diumumkan Chrome pada Agustus 2023, Chrome mulai menghentikan dukungan untuk XHR saat bertransisi dari Uji Coba Origin ke Ketersediaan Umum. Seiring dengan peningkatan Topics, dukungan XHR hanya disertakan untuk pengguna yang fitur OT-nya diaktifkan dan sepenuhnya tidak digunakan lagi saat setiap grup eksperimen OT digabungkan. Jika Anda menggunakan Topics dengan XHR, situs Anda tidak akan rusak. Topik hanya tidak akan ditambahkan ke header permintaan XHR Anda. Sebaiknya transisikan ke `fetch` untuk permintaan Anda, gunakan atribut iframe, atau gunakan JavaScript API untuk mengambil topik. Pengambilan didukung oleh semua browser modern, tetapi tidak untuk Internet Explorer atau Opera Mini.
Proses pembaruan taksonomi dan pengklasifikasi	Informasi selengkapnya tentang taksonomi Topics dan siklus rilis pengklasifikasi serta cara perusahaan dapat mempersiapkan update tersebut.	Respons kami tetap sama seperti pada K2: Seperti yang disampaikan dalam postingan blog terbaru, kami memperkirakan taksonomi akan berkembang seiring waktu, dan tata kelola taksonomi pada akhirnya akan 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	Jenis inventaris penayang apa yang akan didukung oleh pengujian Protected Audience dan Topics?	Protected Audience maupun Topics pada dasarnya tidak membatasi dalam hal jenis inventaris yang dapat digunakan.
Waktu peningkatan	Menyarankan tidak ada waktu pengoptimalan untuk taksonomi baru agar mencapai 100%.	Setelah permintaan masukan ini dari ekosistem dan diskusi selama rapat PATCG, kami telah mengumumkan rencana kami untuk peluncuran taksonomi baru.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan	Ringkasan	Respons Chrome
Lelang Level Atas	Kemampuan untuk menggunakan server iklan penayang Google tanpa juga memberikan kontrol lelang Protected Audience API level teratas kepada Google Ad Manager.	Respons yang diberikan oleh Google Ad Manager: Rencana Google Ad Manager untuk Protected Audience API tidak mencakup dukungan untuk server iklan penayang Google tanpa kontrol lelang Protected Audience tingkat teratas, karena alasan berikut. Untuk menayangkan iklan kepada pelanggan kami di pasar penayangan iklan penayang dengan benar, server iklan penayang Google harus mempertahankan kontrol atas lelang Protected Audience tingkat teratas. Sebagai server iklan penayang, peran kami adalah memberikan perkiraan kepada penayang agar mereka dapat menegosiasikan kampanye yang dijual langsung tanpa kelebihan pemesanan, serta mengatur kecepatan dan mengirimkan pemesanan langsung secara optimal. Untuk melakukannya, Anda harus menjalankan lelang akhir untuk membandingkan semua permintaan langsung dan tidak langsung yang memenuhi syarat. Peramalan dan kecepatan adalah fungsi inti yang diharapkan penayang dari server iklan. Tanpa perkiraan yang akurat, penayang mungkin akhirnya menjual berlebih inventaris mereka, yang membahayakan reputasi bisnis mereka. Kecepatan juga penting, karena tidak dapat memenuhi kontrak reservasi dengan pengiklan juga berisiko merusak hubungan langsung penayang-pengiklan, yang dapat mengakibatkan dampak signifikan pada bisnis penayang. Singkatnya, kami tidak menganggap aktivitas server iklan penayang yang menjalankan lelang Protected Audience tingkat teratas berbeda dengan aktivitas lainnya dari 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-nya sendiri. Dalam lelang multi-penjual, semua penjual tidak dapat membuat frame yang memanggil `runAdAuction()`. `directFromSellerSignals` memecahkan masalah ini dengan memuat konten dari paket subresource yang dimuat dari asal penjual. Hal ini memastikan bahwa 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 penyedia teknologi mereka ke lelang Protected Audience, mereka dapat meminta fungsi ini kepada penyedia teknologi tersebut. 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 kepada Otoritas Persaingan Prancis. Untuk lelang Protected Audience, kami bermaksud menepati janji kami dengan memanfaatkan `directFromSellerSignals`, dan tidak membagikan bid peserta lelang dengan peserta lelang lainnya sebelum lelang selesai di lelang multi-penjual. Untuk memperjelas, kami juga tidak akan membagikan harga lelang kontekstual dengan lelang komponen kami sendiri, seperti yang dijelaskan dalam pembaruan Memperjelas lebih lanjut dinamika lelang tingkat teratas.
Eksposur Informasi	Logika bisnis sensitif dan detail kontrak dapat diekspos oleh browser.	Orang yang menggunakan browser web dapat melihat semua yang terjadi di browser. Saat lelang iklan terjadi di dalam browser, orang yang browser-nya digunakan dapat menyaksikan lelang tersebut berlangsung, termasuk melihat jumlah bid yang dipilih oleh berbagai pihak. Karena browser adalah agen pengguna, kami tidak yakin apakah hal ini dapat atau tidak diinginkan untuk diubah. Namun, hanya orang yang menggunakan browser yang dapat melihat operasi ini. Lelang di perangkat yang dijalankan menggunakan Protected Audience API tidak dapat diamati oleh server mana pun, termasuk server Google.
`PerBuyerExperiment GroupId`	Rentang nilai saat ini `PerBuyerExperiment GroupId` dapat memungkinkan pembeli melakukan korelasi data kontekstual dengan permintaan server tepercaya.	Menggunakan Protected Audience API dengan cara ini tidak konsisten dengan pengesahan wajib Privacy Sandbox bahwa pengguna API tidak akan mencoba menghindari perlindungan Privacy Sandbox. Di masa mendatang, persyaratan agar server nilai kunci berjalan di trusted execution environment (TEE) akan memberikan perlindungan teknis terhadap serangan ini.
Kebijakan origin yang sama	Melonggarkan kebijakan origin yang sama untuk mengizinkan subdomain.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem.
Pembuatan versi API	Minta pembuatan versi dan catatan rilis untuk perubahan pada Protected Audience API.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem.
Lelang Multi-SSP	Mengizinkan sinyal lelang tingkat teratas untuk melakukan penggabungan JSON dengan sinyal komponen `auctionSignals`.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem.
Batas bid	Meningkatkan batas jumlah komponen iklan yang masuk ke bid dari 20 menjadi 40.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem tentang alasan hal ini akan berguna.
(Juga dilaporkan pada kuartal sebelumnya) Performa Lelang Protected Audience	Laporan dari penguji bahwa lelang Protected Audience memiliki latensi yang tinggi.	Terkait pertanyaan latensi, Protected Audience API secara umum mengikuti paradigma standar yang ada untuk membuat kontrol yang memungkinkan penjual memutuskan jumlah waktu dan resource yang dapat digunakan bidder, dan membuat alat yang memungkinkan pembeli memutuskan cara terbaik untuk menggunakan resource yang tersedia bagi mereka. Kontrol dan alat ini umumnya tersedia saat ini, tetapi manfaat lengkapnya hanya akan terwujud setelah diadopsi oleh pembeli dan penjual. Selain itu, Chrome terus mengerjakan berbagai peningkatan infrastruktur untuk kecepatan lelang (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Kami mengundang masukan tentang kedua bagian upaya terkait latensi ini: alat baru yang akan berguna bagi pembeli dan penjual, serta laporan 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 desain mereka untuk menangani hal ini: Memindahkan beberapa tugas ke server Kunci/Nilai DSP. SSP membuat beberapa sinyal kontekstual dan memberikannya ke DSP. SSP menyimpan sinyal kontekstual dalam cache untuk DSP.
Kontrol Grup Minat Penayang	Dukungan untuk penayang yang ingin mendelegasikan penggunaan grup minat yang dibuat penayang.	Kami telah berdiskusi dengan banyak pihak terkait permintaan tersebut. Kami yakin bahwa semua kasus penggunaan tersebut yang terlibat dalam "mendelegasikan" grup minat yang dibuat penayang dapat diakomodasi sekarang, dan lebih lanjut, kami harus membuat dukungan tambahan agar beberapa kasus penggunaan berjalan lebih lancar di masa mendatang.
(Juga dilaporkan pada Kuartal 2) Trusted Execution Environment	Dukungan untuk Trusted Execution Environment (TEE) di lingkungan cloud non-publik.	Respons kami serupa dengan kuartal sebelumnya: Meskipun kami terus mempelajari dukungan untuk opsi di luar solusi berbasis cloud publik, saat ini kami tidak memiliki rencana untuk mendukung TEE on-premise. Pada tahap ini, mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang ditimbulkan oleh deployment on-premise, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung Google Cloud selain AWS) adalah yang paling berguna bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan persyaratan tersebut diperlukan dan dapat dilakukan 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 di header permintaan ke layanan iklan penjual yang tidak tepercaya dalam kasus Bidding dan Lelang serta lelang Protected Audience di perangkat. Lihat Penerusan metadata untuk mengetahui informasi selengkapnya. Dalam jangka panjang, kami berencana untuk melakukan proxy pada teknologi iklan dan traffic pelacak 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 akan ditetapkan atau apakah dimaksudkan untuk fleksibel (atau dinamis)?	TTL biasanya bersifat statis. Saat ini, TTL untuk publik adalah 8 hari, dan rotasi terjadi setiap 7 hari; TTL juga sama untuk kunci pribadi dalam kasus Layanan Agregasi. Untuk layanan Bidding dan Lelang, kunci pribadi dan publik diambil setiap N jam di jalur non-permintaan dan di-cache dalam memori, sehingga tidak ada penundaan lebih dari N jam antara rotasi kunci dan server mengambil kunci ini. Buffer 1 hari antara rotasi kunci dan masa berlaku 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. Perhatikan bahwa kunci publik di-cache di klien, saat ini selama 24 jam, lagi-lagi untuk memastikan bahwa jika terjadi pemadaman koordinator, layanan masih dapat beroperasi.
Pembentukan Traffic	Dukungan Traffic Shaping untuk Layanan Bidding dan Lelang.	Pembeli dapat menunjukkan, berdasarkan data pihak pertama Penayang atau data kontekstual, permintaan untuk lelang Protected Audience. Penjual juga dapat melakukan penentuan serupa di server iklan penjual atau server Ad Exchange. Model dapat dilatih dengan data pihak pertama dan laporan gabungan 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 percaya bahwa ini dapat menjadi cara yang efektif untuk membentuk traffic.
Lelang Komponen	auctionSignals tingkat teratas apa yang dibagikan kepada penjual Komponen?	Pembeli dalam lelang komponen hanya menerima sinyal dari penjual komponen. Kami akan segera membagikan dokumentasi tentang urutan keseluruhan lelang gabungan dengan bidding header dan lelang Protected Audience.
Rendering Video	Dukungan untuk rendering video menggunakan Protected Audience dan Frame Pagar.	Protected Audience API mendukung rendering video menggunakan mekanisme yang mengandalkan iframe. Namun, kami belum mendesain solusi yang kompatibel dengan Frame Pagar, dan ini adalah salah satu alasan kami memutuskan untuk menunda penerapan Frame Pagar hingga tahun 2026. Artinya, jika partner memutuskan untuk menerapkan Bingkai Pagar 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 juga 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 memblokir berdasarkan 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 asal yang sama untuk URL sumber skrip bidding dan lelang	Melonggarkan persyaratan bahwa semua kolom yang menentukan URL untuk memuat skrip atau JSON harus memiliki origin yang sama dengan pemilik.	Saat ini kami sedang mempertimbangkan permintaan ini dan menyambut masukan tambahan dari ekosistem.
`forDebuggingOnly`	Potensi `forDebuggingOnly .reportAdAuctionWin` disalahgunakan jika tetap ada setelah 3PCD.	Selama beberapa tahun terakhir, kami telah menerima masukan dari ekosistem terkait kesenjangan fungsi di Protected Audience setelah cookie pihak ketiga tidak digunakan lagi, dan kami sedang berupaya merumuskan rencana untuk mendukungnya setelah 3PCD tanpa mengorbankan tujuan 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.	Hal ini tidak didukung di Protected Audience API saat ini, karena akan menghasilkan perubahan pada model privasi yang mendasarinya. Kami menerima 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 di Android.
(Dilaporkan pada K2 2023) Data terkait klik	Menambahkan data terkait klik ke browserSignals.	Kami terus mengevaluasi permintaan fitur ini dan menerima masukan tambahan tentang alasan fitur ini harus diprioritaskan.
Penyedia Trusted Execution Environment	Apakah ada perbedaan mendasar dalam penawaran Trusted Execution Environment dari berbagai penyedia cloud?	Kami tidak mengetahui perbedaan besar apa pun, tetapi sebaiknya ekosistem meninjau panduan deployment publik untuk melihat solusi mana yang paling sesuai dengan kebutuhan mereka. Google Cloud. AWS.
(Dilaporkan pada kuartal sebelumnya ) Dukungan untuk penargetan Grup Minat negatif	API untuk mendukung penargetan grup minat negatif: hanya menampilkan iklan jika pengguna tidak termasuk dalam grup minat.	Kami sedang mempertimbangkan untuk menerapkan fitur ini dan membahas permintaan tersebut.
Pelanggaran Konten	Mendukung fitur yang memungkinkan pengguna melaporkan iklan buruk yang ditayangkan oleh Protected Audience API di Bingkai Pagar.	Kami yakin bahwa mekanisme Pelaporan Iklan Bingkai Pagar yang ada menawarkan opsi yang baik bagi teknologi iklan yang menginginkan alur pelaporan "Iklan Buruk" buatan pengguna. Hal ini akan memungkinkan pelaporan iklan yang tidak baik dengan cara yang pada dasarnya tidak berubah dari standar industri saat ini. Kami menerima permintaan fitur tambahan jika masih ada kekurangan, termasuk selama waktu setelah penghapusan cookie pihak ketiga, tetapi sebelum rendering Frame Pagar menjadi umum.
Pelaporan Private Aggregation API	Bagaimana cara menghitung waktu yang dihabiskan pengguna di grup minat tersebut?	Di Chrome M116+, Anda seharusnya dapat menggunakan keaktualan seperti yang ditentukan pull/639.
Server K-Anonymity	Informasi selengkapnya tentang server K-Anonymity.	Kami membagikan informasi selengkapnya tentang server K-Anonymity di sini dan menyambut masukan tambahan.
URL Materi Iklan Dinamis	Dukungan untuk URL materi iklan tanpa deklarasi awal sekaligus masih menghormati k-anonimitas.	Kami sedang mendiskusikan permintaan fitur ini dan menerima masukan tambahan tentang alasan fitur ini harus diprioritaskan.
Persyaratan k-anonymity	Apakah persyaratan k-anonymity pada update Grup Minat akan diperkenalkan kembali?	Kami tidak mengantisipasi perubahan pada posisi yang dinyatakan dalam postingan GitHub ini. Seperti yang diumumkan dalam postingan tersebut, kami memutuskan untuk menghapus persyaratan k-anonimitas pada pembaruan grup minat Protected Audience, yang tidak memiliki dampak signifikan pada perlindungan privasi API secara keseluruhan, dan kami berencana untuk mempertimbangkan potensi perlindungan lain yang lebih langsung (seperti privasi alamat IP atau server update tepercaya) pada kemudian hari saat teknologi terkait lebih dikembangkan, di-deploy, dan diadopsi.
Pengujian Beta Layanan Bidding & Lelang	Kapan pengujian Layanan Bidding & Lelang Beta akan dimulai?	Seperti yang dinyatakan dalam Linimasa dan roadmap, fase pertama pengujian Layanan Bidding dan Lelang dimulai pada November 2023.
Roadblocking	Permintaan untuk mendukung Koordinasi materi iklan untuk Jaringan Iklan (SSP dan DSP berada di perusahaan atau properti yang sama).	Kami menghargai masukan untuk kasus penggunaan ini dan ingin memahami apakah lebih banyak teknologi iklan yang tertarik untuk mendukung hal ini. Kami menerima masukan tambahan.
Iklan Native	Dukungan Frame Pagar untuk Iklan Native.	Kami mempertimbangkan untuk mendukung kasus penggunaan tersebut dan sedang membahas kemungkinan solusi dan solusi.
K-anonymity	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 sedang mengevaluasi permintaan fitur ini dan menerima pengiriman masalah GitHub tambahan tentang alasan fitur ini harus diprioritaskan.
Perincian pelaporan	Berapa perincian pelaporan pelaporan iklan Bingkai Pagar dengan Iklan yang Terdiri dari Beberapa Bagian?	Desain saat ini tidak memungkinkan 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 bingkai berpagar komponen iklan, yang menghasilkan navigasi tingkat atas.
Lelang iklan	Dapatkah SSP yang berpartisipasi dalam lelang komponen memicu lelang komponen lain itu sendiri?	`componentSeller` juga tidak boleh menyertakan `componentAuctions`. Lelang multi-penjual hanya memiliki dua tingkat: 1. Lelang komponen secara paralel. 2. Lelang tingkat atas (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 mendiskusikan permintaan ini dan menerima masukan tambahan tentang alasan permintaan ini harus diprioritaskan.
`generateBid()`	Kemampuan untuk memperbarui `userBiddingSignals` interestGroup melalui `updateURL`.	Kami sedang mempertimbangkan proposal ini dan menyambut masukan tambahan serta diskusi.
Jenis Inventaris Penayang	Jenis inventaris penayang apa yang akan didukung oleh pengujian Protected Audience dan TOPICS?	Protected Audience maupun Topics pada dasarnya tidak membatasi 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 diproses tersebut ke fungsi bidding di perangkat.
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 batasan jumlah sinyal per pembeli, tetapi mengirim terlalu banyak data 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	Sertakan Blob Grup Minat dalam header HTTP.	Kami sedang mempertimbangkan permintaan ini dan menerima masukan lebih lanjut tentang 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 keluar akan terlihat di Tab Jaringan Chrome Developer Tools.	Kami sedang berupaya mengaktifkan fungsi ini di tab jaringan dan menyambut masukan tambahan tentang alasan fungsi ini harus diprioritaskan.
Trusted Execution Environment	Kapan detail tentang metrik yang memengaruhi privasi (dan tingkatnya) akan ditambahkan ke penjelasan tentang pemantauan Trusted Execution Environment?	Kami sedang dalam proses memperbarui penjelasan dengan informasi ini. Penjelasan yang diperbarui akan tersedia pada November 2023.
`directFrom SellerSignals`	Mengapa `directFrom SellerSignals` tidak dikemas sebagai paket web?	Kami telah membagikan alasan keputusan ini di sini.
Delegasi tayangan	Apakah ada cara yang efektif untuk melakukan delegasi tayangan jika hasil grup minat yang dipilih adalah tindakan penargetan lain?	Beberapa lelang bertingkat tidak kompatibel dengan sasaran privasi kami karena dua alasan. Pertama, saat pemenang lelang dirender di dalam Bingkai Pagar, sasaran privasi kami untuk Protected Audience mencakup rendering materi iklan yang dihasilkan tanpa mengetahui konteksnya: URL halaman di sekitar atau cookie pihak pertama merupakan pelanggaran privasi. Dalam lingkungan tersebut, lelang bertingkat tidak dapat dilakukan. Kedua, model Protected Audience menyatakan bahwa pemenang setiap lelang harus didasarkan pada data dari satu situs tambahan saja. Lelang bertingkat akan menjadi cara untuk menggabungkannya, sehingga memungkinkan pemilihan iklan berdasarkan profil banyak situs.
Kriteria Data dalam Penyimpanan	Jelaskan lebih lanjut kriteria Data dalam Penyimpanan di model kepercayaan layanan Key/Value.	Data di Layanan Nilai Kunci dimuat ke dalam memori dan ditayangkan dari tempat tersebut, bukan melakukan cache read-through.
Sinyal Data Pembeli	Apakah ada batas ukuran yang ditentukan untuk sinyal `buyer_data` yang diterima dari DSP?	Saat ini tidak ada batasan yang diberlakukan browser 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 di atas 3PC dan juga menambahkan tantangan distribusi teknologi mengingat berbagai perangkat dan platform yang mungkin digunakan pengguna. Kami sedang mempelajari potensi solusi, tetapi kami berfokus pada kasus penggunaan penting yang saat ini didukung oleh Pelaporan Atribusi dan tidak memiliki rencana untuk memperkenalkan 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 berbeda untuk memastikan bahwa jumlah informasi lintas situs dan lintas konteks tentang pengguna dibatasi. Kami menyambut baik pemain ekosistem untuk mengirim masukan tentang apakah parametrisasi saat ini untuk pelaporan tingkat peristiwa sudah memadai.
Funnel konversi	Melaporkan beberapa domain yang digunakan dalam konversi.	Kasus penggunaan ini dimungkinkan karena penambahan beberapa tujuan. Kami menerima masukan tambahan.
Dukungan domain yang sama di negara yang berbeda	Apakah Pelaporan Atribusi berfungsi dengan situs yang memiliki Domain yang sama, tetapi beberapa TLD negara?	Masalah ini telah dibahas dan diselesaikan dengan pemangku kepentingan yang mengajukan pertanyaan. Jika teknologi iklan perlu menggunakan beberapa TLD negara, teknologi iklan tersebut harus memiliki beberapa pendaftaran, dengan satu pendaftaran untuk setiap TLD negara.
Protected Audience dan Pelaporan Atribusi	Dapatkah teknologi iklan mengakses konversi lihat-tayang untuk lelang Protected Audience serta konversi klik-tayang untuk Pelaporan Atribusi?	Ya, Privacy Sandbox harus mendukung VTC dan CTC dalam Protected Audience.
Penundaan laporan gabungan	Mengurangi penundaan laporan agregat lebih lanjut.	Kami telah mendengar masukan terbaru terkait hal ini dan telah membagikan ide di sini. Kami menerima masukan tambahan dari ekosistem.
Penundaan laporan gabungan	Mengurangi keterlambatan dengan memperkenalkan mediasi server.	Kami sedang mempertimbangkan proposal ini dan menyambut masukan tambahan .
Penundaan laporan tingkat peristiwa	Mengurangi keterlambatan laporan tingkat peristiwa.	Proposal tingkat peristiwa fleksibel penuh, yang dijelaskan dalam Konfigurasi tingkat peristiwa yang fleksibel, dapat mengurangi keterlambatan 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 berbagai asal pelaporan untuk satu asal penayang.	Hal ini telah didiskusikan dengan pemangku kepentingan yang mengangkat masalah tersebut dan potensi solusi menggunakan 1 asal pelaporan per situs pelaporan sumber sedang diuji sebelum mencoba potensi solusi lain yang melibatkan pengalihan. Kami juga menerima masukan ekosistem tambahan terkait batas ini.
Pelaporan masalah	Bagaimana cara melaporkan error atau masalah terkait Attribution Reporting API ke Chrome?	Saat ini, sebaiknya teknologi iklan melaporkan error Attribution Reporting API yang mungkin mereka alami sebagai Masalah di GitHub. Jika mereka mengalami masalah terkait Chrome, sebaiknya buat bug Chromium. Link cara dan tempat melaporkan masalah dapat ditemukan di Berinteraksi dan memberikan masukan.
Deduplikasi	Bagaimana cara menghapus duplikat konversi di berbagai pipeline dan perangkat?	Penghapusan duplikat di seluruh perangkat dan pipeline pengukuran adalah tantangan yang diketahui dan saat ini juga dihadapi teknologi iklan dengan 3PC. Dengan Attribution Reporting API, teknologi iklan dapat memutuskan kapan harus mendaftarkan konversi tertentu dan menambahkan metadata tertentu untuk menunjukkan pipeline pengukuran yang telah mereka gunakan untuk melacak konversi (dengan kata lain, bagian dari kunci agregasi), yang dapat dibandingkan dengan pipeline pengukuran lainnya. Kami terbuka untuk masukan ekosistem tambahan terkait hal ini.
Penghapusan Duplikat dan Prioritas	Minta prioritas terlebih dahulu sebelum penghapusan duplikat.	Kami sedang mempertimbangkan permintaan ini dan menyambut masukan tambahan.
Anti-penipuan	Risiko pengguna berbahaya yang memodifikasi data tingkat peristiwa.	Verifikasi laporan tidak berfungsi untuk pelaporan tingkat peristiwa karena alasan yang dijelaskan dalam Mengapa hal ini tidak mendukung laporan tingkat peristiwa?.
Jenis konversi	Bagaimana cara membedakan antara penayangan melalui dan navigasi dalam Pelaporan Atribusi?	Kami 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 mereka.	Tim kami sedang mempelajari cara mengatasi hal ini dengan cara yang menjaga privasi.
Pendaftaran situs	Beberapa teknologi iklan telah meminta dukungan untuk memproses beberapa asal di akun yang sama untuk kasus penggunaan seperti memisahkan data menurut Geo, 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 origin ke pendaftaran situs untuk Layanan Agregasi dan menerima masukan dari ekosistem.
Rencana Rilis & Penghentian	Jadwal rilis dan depresiasi untuk fitur dan patch Layanan Agregasi yang dipublikasikan. Tujuan rencana ini adalah untuk memberi teknologi iklan visibilitas terhadap kebijakan rilis kami agar mereka dapat bersiap untuk rilis dan penghentian mendatang, serta memastikan mereka menjalankan versi layanan yang stabil dan aman.	Baru-baru ini kami memublikasikan proposal untuk rencana rilis dan penghentian Layanan Agregasi dan menerima masukan tambahan.
Koordinator	Apa yang terjadi jika koordinator tidak dapat mengakses layanan agregasi?	Kedua koordinator harus tersedia sepenuhnya agar sistem dapat berfungsi dengan benar. Ketidaktersediaan singkat diakomodasi dengan percobaan ulang di library klien kami; ketidaktersediaan salah satu dari dua koordinator yang lebih lama akan menyebabkan tugas agregasi gagal. Tugas dapat dijalankan ulang jika anggaran untuk privasi belum digunakan. Jika kegagalan layanan menyebabkan penggunaan anggaran tanpa laporan ringkasan yang ditulis ke penyimpanan teknologi iklan, saat ini sebaiknya teknologi iklan tersebut menggunakan laporan debug untuk mengambil hasil menggunakan alat pengujian lokal. Kami juga sedang mengembangkan fitur untuk memungkinkan pemulihan anggaran jika terjadi kegagalan sehingga teknologi iklan dapat menjalankan ulang tugasnya.

Private Aggregation API

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

Membatasi Pelacakan Tersembunyi

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 dengan entropi tinggi di luar 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 menerima masukan dari ekosistem.

Perlindungan IP (sebelumnya bernama 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 secara aktif bekerja untuk mengidentifikasi traffic pihak ketiga mana yang akan memenuhi syarat dan mana yang tidak. Kami menerima 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, yang akan membatasi jumlah traffic yang memerlukan pemfilteran. Selain itu, kami berencana memberi pengguna opsi untuk menggunakan atau tidak menggunakan Perlindungan IP, dan untuk Chrome yang dikontrol perusahaan, akan ada kebijakan perusahaan untuk menonaktifkan Perlindungan IP. Terakhir, kami sedang mempelajari kontrol apa (jika ada) yang akan diberikan kepada operator jaringan untuk menonaktifkan Perlindungan IP. Kami menerima masukan tentang topik ini.
Kontrol akses	Perlindungan IP dapat memengaruhi layanan web yang menggunakan alamat IP untuk kontrol akses.	Kami memahami pentingnya kasus penggunaan anti-penipuan dan kemungkinan dampaknya terhadap kasus penggunaan tersebut. Kami mencari masukan ekosistem tentang cara kami dapat lebih mendukung kasus penggunaan anti-penipuan yang biasanya mengandalkan alamat IP.
Komunikasi antara proxy 2-Hop	Cara memastikan tidak ada informasi di antara proxy.	Kami sedang dalam proses mendesain interaksi proxy. Sasaran kami adalah meminimalkan peluang berbagi informasi tersebut melalui cara bisnis, proses, dan teknis.
Autentikasi Non-Google	Dukungan untuk Autentikasi Non-Google.	Kami berencana untuk memublikasikan detail selengkapnya tentang autentikasi akun di masa mendatang, meskipun kami telah membagikan beberapa pertimbangan awal.
Klasifikasi pelacak	Bagaimana Perlindungan IP akan menentukan apa yang dimaksud dengan pelacak dan variannya?	Kami memahami pentingnya pertanyaan ini dan secara aktif bekerja untuk mengidentifikasi traffic pihak ketiga mana yang akan memenuhi syarat dan mana yang tidak. Kami menerima masukan tentang topik ini.
Analytics	Perlindungan IP dapat memengaruhi akurasi layanan analisis.	Kami ingin lebih memahami dampak Perlindungan IP dan menerima masukan dan contoh tambahan dari ekosistem.
Proxy	Jika pengguna menggunakan proxy atau telah menentukan proxy secara manual, bagaimana Mask IP akan berfungsi dalam hal ini?	Kami ingin memahami dampak yang mungkin ditimbulkan oleh Perlindungan IP pada proxy lain. Saat ini, kami tidak memiliki rencana untuk membagikannya. Kami menyambut 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. Fitur ini tidak akan berbayar.
Server proxy	Apakah server proxy yang sama akan digunakan selama sesi pengguna?	Koneksi HTTP/S akan menggunakan satu pasangan proxy dan akan menampilkan satu alamat IP yang disamarkan ke origin. Selain itu, tidak ada batasan keras pada koneksi HTTP/S yang berbeda yang harus menggunakan server yang sama.
Dukungan platform	Di platform mana Perlindungan IP akan didukung?	Perlindungan IP awalnya akan tersedia di Chrome untuk Android dan Desktop. Kami terus mengevaluasi cara memperluas perlindungan ke platform lain.
Memilih Tidak Ikut	Apakah pengguna dapat menonaktifkan Perlindungan IP?	Kami berencana untuk memberikan pilihan kepada pengguna apakah mereka ingin menggunakan Perlindungan IP atau tidak.
Anonimisasi	Jenis permintaan apa yang akan dianonimkan dalam Perlindungan IP?	Permintaan HTTP/S dan DNS ke domain pihak ketiga yang memenuhi syarat akan dianonimkan melalui proxy privasi. Kami akan memberikan detail tambahan dalam penjelasan mendatang tentang cara kami menentukan domain mana yang akan disertakan. Traffic lainnya (misalnya, permintaan DNS lainnya atau traffic HTTP/S lainnya) tidak terpengaruh.
Visibilitas Data	Alamat jaringan dapat diakses selama hop pertama dalam 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 proxy + port) dan IP tujuan. Untuk respons yang kembali dari origin, 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 membagikannya, 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 seperti yang ditentukan oleh spesifikasi html. Ini pada dasarnya adalah klik, penekanan tombol, ketukan layar sentuh, dll. Pernyataan webauth yang berhasil. Ini adalah kasus saat pengguna mengetuk kunci keamanan atau menggunakan kunci sandi sebagai bentuk autentikasi Interaksi ini dikaitkan dengan situs tingkat atas di halaman tempat interaksi tersebut terjadi. Misalnya, jika pengguna mengklik iframe tersemat, interaksi akan dikaitkan dengan situs tingkat teratas, bukan situs tersemat. Interaksi disimpan dalam database yang berisi etld+1 tanpa skema dan waktu interaksi. Interaksi melindungi domain terkait dari penghapusan status mitigasi pelacakan pantulan selama 45 hari.
Pengecualian yang Diizinkan	Dapatkah domain dikecualikan?	Kami sedang mempertimbangkan permintaan ini dan kami menerima masukan tambahan dari ekosistem.

Anggaran Privasi

Tidak ada masukan yang diterima kuartal ini.

Memperkuat batasan privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tema Masukan	Ringkasan	Respons Chrome
Pendekatan Terpusat	Kekhawatiran terkait pendekatan repositori terpusat untuk mengelola Set Situs Terkait.	Repositori publik yang mudah diakses adalah kunci desain RWS karena menyediakan akuntabilitas untuk pengiriman. Fungsi cookie pihak ketiga pada akhirnya disediakan oleh penggunaan Storage Access API atau rSAFor API, dengan keanggotaan RWS yang memberikan akses yang diberikan secara otomatis (bukan melalui perintah dengan Storage Access API). Kami yakin bahwa pendekatan seperti proses pengiriman RWS adalah 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 utama 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 di kuartal sebelumnya) Batas Domain	Meminta untuk memperluas jumlah domain terkait	Seperti yang diumumkan dalam postingan blog pada 31 Agustus, kami telah menaikkan batas domain terkait menjadi lima domain setelah menerima masukan dari ekosistem. Kami telah memutuskan untuk meningkatkan batas domain terkait menjadi lima domain (ditambah satu domain utama) yang paling cocok dengan implementasi yang paling sebanding yang ditawarkan oleh browser utama lainnya.
Cookie Pihak Ketiga	Apakah Set Situs Terkait hanya akan berfungsi jika cookie pihak ketiga 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 non-pemilik mengubah set?	Sesuai dengan panduan pengiriman, siapa saja dapat mengirimkan PR di GitHub untuk mengedit file `first_party_sets.JSON`. Namun, jika PR disetujui (lulus validasi teknis, dan sebagainya), PR tersebut akan digabungkan secara manual dalam batch ke daftar FPS kanonis sekali per minggu (Selasa pukul 12.00 Waktu Timur) oleh Google. Jika pelaku kejahatan mencoba mengubah set yang bukan miliknya, hal ini seharusnya tidak menjadi masalah karena mereka tidak akan dapat mengubah file `.well-known` sehingga validasi akan gagal.
Pembajakan domain	Pembajakan domain dapat mengekspos data domain terkait kepada pihak yang tidak berizin.	Hal ini tidak dapat dilakukan, seperti yang dibahas dalam masalah GitHub Protected Audience ini.

Fenced Frames API

Tema Masukan	Ringkasan	Respons Chrome
Pelanggaran Konten	Izinkan pengguna melaporkan iklan yang mencurigakan.	Pelaporan iklan yang mencurigakan tidak dicegah oleh Bingkai Pagar. Pengguna masih dapat berinteraksi dengan iklan dan melaporkan iklan yang mencurigakan ke teknologi iklan dengan cara biasa.
Interaksi dengan situs di sekitar	Mengizinkan interaksi dengan situs di sekitarnya atau situs tingkat atas.	Kami ingin memahami alasan permintaan ini diperlukan dan menyambut masukan tambahan dari ekosistem.
Iklan Native	Dukungan Frame Pagar untuk Iklan Native.	Kami mempertimbangkan untuk mendukung kasus penggunaan tersebut dan sedang membahas kemungkinan solusi dan solusi.

Shared Storage API

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

CHIPs