Laporan Masukan - Kuartal 1 2023

Laporan kuartalan untuk K1 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, FLEDGE, dan Attribution Reporting API.

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

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/Teknologi tertentu

Tema Masukan Ringkasan Respons Chrome
Pengujian dan uji coba Relevansi pengujian untuk menginformasikan penilaian CMA jika Privacy Sandbox API tidak selesai pada saat pengujian dimulai Pengembangan Privacy Sandbox API terus berjalan. Fitur ini sudah tersedia di Uji Coba Origin untuk pengujian dan akan umumnya tersedia untuk 100% traffic pada musim panas ini.

Selain itu, kami telah mengklarifikasi linimasa untuk fitur tertentu (seperti pelaporan tingkat peristiwa FLEDGE, rendering FLEDGE dengan iframe) yang tidak akan terpengaruh sebelum tahun 2026.

Kami mendorong ekosistem untuk menguji API dan memberikan masukan ke CMA berdasarkan hal yang diharapkan penguji untuk diandalkan setelah cookie pihak ketiga tidak digunakan lagi. Hal ini dapat berkontribusi pada penilaian mereka terhadap kemungkinan dampak penghentian penggunaan cookie pihak ketiga.
Kontrol pengguna Panduan yang jelas untuk ekosistem tentang implikasi kontrol pengguna dari API Privacy Sandbox Kami tidak dapat memberikan saran hukum tentang kontrol pengguna yang dapat digunakan ekosistem. Pada saat yang sama, Chrome bereksperimen dengan menampilkan kontrol pengguna Privacy Sandbox ("Privasi Iklan yang Ditingkatkan") yang telah diperbarui kepada sebagian kecil pengguna, sebagai bagian dari upaya berkelanjutan kami untuk meningkatkan teknologi Privacy Sandbox. Pembaruan ini mencakup bahasa dan tata letak yang lebih jelas dan lebih bermanfaat. Setelah Chrome mengevaluasi peningkatan ini dan memutuskan apakah akan memperluasnya ke populasi yang lebih besar, Chrome dapat membagikan lebih banyak informasi ke ekosistem.
Kebocoran data Risiko kebocoran data pihak pertama ke Google dan pihak lain jika browser disusupi Penjelasan FLEDGE kami menunjukkan bahwa data satu teknologi iklan hanya dibagikan ke teknologi iklan yang sama (baik dengan worklet atau server tepercaya) atau jika dibagikan secara eksplisit oleh teknologi iklan tersebut (seperti pembeli menampilkan URL iklan yang ingin ditampilkan kepada penjual). Satu-satunya pengecualian adalah bahwa pemeriksaan k-anonimitas harus dilakukan oleh server terpusat global, yang merupakan area yang terus kami dedikasikan untuk resource yang signifikan. Lihat penjelasan K-anonimitas untuk mengetahui pandangan mendetail tentang privasi.

Selain itu, kami siap memberikan detail selengkapnya tentang cara kerja perlindungan teknologi iklan yang digunakan dalam desain server k-anonymity.
Forum tambahan untuk diskusi Meminta forum tambahan ke W3C bagi pelaku ekosistem non-teknis untuk membagikan masukan Formulir masukan Privacy Sandbox sesuai untuk komentar umum dan spesifik, teknis dan non-teknis.
Improving Web Advertising Business Group adalah forum untuk diskusi melalui panggilan mingguan dan repo GitHub.
Halaman Masukan Privacy Sandbox menjelaskan mekanisme lain untuk memberikan masukan dan terlibat dalam diskusi. Chrome juga terus mengadakan acara seperti Waktu Konsultasi publik untuk memfasilitasi pertanyaan dan berbagi konten. Selain itu, Chrome telah menyelenggarakan atau menghadiri lebih dari sepuluh acara industri pada kuartal lalu.
Klarifikasi linimasa Klarifikasi tentang tanggal pasti untuk Ketersediaan Umum pada Kuartal 3 tahun 2023 Sesuai dengan linimasa yang dipublikasikan di PrivacySandbox.com, Ketersediaan Umum ditargetkan untuk mulai diluncurkan dengan rilis Chrome versi 115.
reCAPTCHA Dampak Sandbox API untuk kasus penggunaan deteksi spam reCATPCHA Kami mendapatkan masukan dari reCAPTCHA secara berkala untuk memastikan proposal Privacy Sandbox tidak memengaruhi keamanan web atau penipuan secara signifikan. Mereka sedang mengembangkan rencana mereka sendiri untuk bersiap dan menyesuaikan diri dengan penghentian penggunaan cookie pihak ketiga, jadi pertanyaan ini sebaiknya dijawab oleh mereka.
Ekstensi Chrome Apakah teknologi Privacy Sandbox seperti langkah Anti Pelacakan Rahasia (ACT) akan berlaku untuk ekstensi Chrome? Kami belum membuat pengumuman apa pun tentang apakah ACT dapat berlaku untuk ekstensi Chrome. Namun, jika teknologi mengumpulkan informasi tentang pengguna secara diam-diam, hal ini tidak akan sesuai dengan prinsip privasi kami.

Menampilkan Konten dan Iklan yang Relevan

Topik

Tema Masukan Ringkasan Respons Chrome
TAG Design Review TAG merilis Tinjauan Desain Awal Topik. Kami tetap berkomitmen pada Topics dan telah membagikan info terbaru tentang komitmen kami di halaman info terbaru dan dalam edisi ini. Kami merespons, poin demi poin, peninjauan TAG dan membagikan visi tingkat tinggi kami di sini. Topics API akan tetap menjadi bagian dari kumpulan API yang harus diuji ekosistem iklan selama tahun 2023 — dan kami berharap masukan pengujian yang kami dengar dan pengalaman pengimplementasi yang kami peroleh akan menjadi kontribusi yang berharga dalam upaya mendatang untuk menerapkan standar lintas browser di ruang ini. Kami berharap dapat terus berinteraksi dengan ekosistem tentang cara mempermudah kemungkinan transisi dengan Topics API yang dapat menjadi standar yang disepakati dengan kompatibilitas lintas browser.
Pendekatan untuk Topik Dukungan untuk pendekatan terbuka yang dimiliki Chrome dalam mengembangkan Topics API Kami menghargai sentimen tersebut dan berharap dapat terus bekerja sama dengan grup industri untuk mengembangkan Topics API yang memberikan nilai kepada ekosistem secara keseluruhan.
(Juga dilaporkan pada K3 2022)
Taksonomi topik tidak cukup terperinci		 Taksonomi topik luas tidak mencakup topik yang lebih terperinci, termasuk khusus wilayah. Pembaruan Kuartal 1:

Peningkatan pada taksonomi adalah upaya yang sedang berlangsung, dan pada Kuartal 2, kami akan mengumumkan taksonomi yang diperbarui untuk Topics API. Untuk membuat taksonomi baru ini, kami bekerja sama dengan perusahaan dari seluruh ekosistem.
Kami secara aktif mencari masukan tentang taksonomi yang akan paling berguna bagi ekosistem. Dalam mengevaluasi apakah akan memperluas jumlah topik atau menyertakan topik yang lebih terperinci, ada beberapa pertimbangan, termasuk 1) potensi implikasi privasi (lebih banyak topik dapat menimbulkan risiko pelacakan sidik jari) dan 2) kemampuan untuk mengambil topik yang diamati sebelumnya (seperti dengan lebih banyak topik, mungkin ada lebih sedikit peluang bahwa teknologi iklan telah melihat topik yang dipilih sebelumnya).
(Juga dilaporkan pada Kuartal 4 2022)
Dampak pada sinyal pihak pertama		 Sinyal Topics mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. Kami yakin bahwa iklan berbasis minat adalah kasus penggunaan yang penting untuk web, dan Topics dirancang untuk mendukung kasus penggunaan tersebut. Kami mengerti bahwa beberapa penayang besar khawatir bahwa Topics akan memengaruhi strategi data pihak pertama mereka secara negatif. Kami menantikan pengujian ekosistem, yang akan memberikan insight tentang dampak Topik terhadap penayang.
Kasus penggunaan Topik yang tidak terkait Iklan Penggunaan Topics untuk tujuan selain menampilkan iklan berdasarkan minat Topics dirancang untuk mengatasi kasus penggunaan iklan berbasis minat, yang kami yakini merupakan kasus penggunaan yang penting untuk web yang bebas dan terbuka. Saat ini kami mencari masukan tentang kasus penggunaan lain dan sedang mengevaluasinya.
Status keikutsertaan default Dampak legislasi regional untuk izin default Topics Kami tidak berwenang untuk mengomentari pendapat hukum.
(Juga dilaporkan pada Kuartal 3 2022)
Situs yang salah dikategorikan		 Penargetan iklan saat topik salah dikategorikan untuk situs tertentu Info Terbaru Kuartal 1:
Pada Kuartal 2, kami akan mengumumkan pengklasifikasi yang diperbarui untuk Topics API dan berharap dapat berinteraksi dengan ekosistem di dalamnya.
Sebagai respons terhadap masukan saat ini, situs diklasifikasikan melalui kombinasi daftar penggantian yang diseleksi manusia, yang berisi situs paling populer, dan model ML di perangkat. Chrome terus mengevaluasi opsi bagi situs untuk berkontribusi pada Klasifikasi topik. Setiap peningkatan utilitas harus dipertimbangkan dengan risiko privasi dan penyalahgunaan. Misalnya, beberapa risikonya mencakup: situs yang menggunakan pemberian label mandiri sebagai metode untuk mengenkode berbagai makna (dan berpotensi sensitif) ke dalam topik; situs yang memutarbalikkan topik mereka untuk mendapatkan keuntungan finansial; situs yang menyerang topik untuk mengurangi kegunaannya bagi orang lain (misalnya, mengirim spam ke topik pengguna dengan derau yang tidak berarti). Publik dapat memeriksa komponen ini, dengan alat yang tersedia melalui chrome://topics-internals atau colab ini. Melalui pengujian, kami berharap klasifikasi akan meningkat seiring waktu, dan kami menyambut masukan tentang contoh situs yang mungkin salah dikategorikan.
Pengklasifikasi Topik Permintaan untuk menampilkan informasi tambahan yang menunjukkan alasan saat "Tidak ada Topik" ditampilkan kepada pemanggil untuk tujuan proses debug Kami memahami dan menghargai bahwa alat proses debug bermanfaat bagi developer, saat mereka berupaya mengintegrasikan Topics API ke dalam sistem mereka. Namun, dengan mengekspos informasi tambahan (seperti alasan tidak ada Topics yang ditampilkan), kami mungkin tidak sengaja membagikan informasi yang memungkinkan pihak lain menemukan detail tambahan (misalnya, jika pengguna berada dalam mode Samaran, telah menonaktifkan API, dan sebagainya) di luar yang dimaksudkan, yang membahayakan privasi pengguna. Meskipun saat ini kami tidak berencana untuk menyediakan alat proses debug tambahan, kami terbuka untuk menerima masukan tentang alat mana yang akan berguna.
Pengambilan Informasi Pribadi (PIR) Meminta Topics API untuk menggunakan Pengambilan Informasi Pribadi Sebelumnya, kami telah menyelidiki penggunaan PIR dan telah membagikan kompromi di sini.
Aliran bid Apakah Topik akan direpresentasikan secara berbeda dari Audiens yang Ditentukan Penjual dalam aliran bid? Topics API adalah proposal Privacy Sandbox yang dikembangkan oleh Chrome, yang berbeda dengan proposal Audiens yang Ditetapkan Penjual IAB Tech Lab. Kami berharap keduanya akan ditampilkan secara berbeda dalam bidstream. Pelajari cara Topics akan diwakili dalam permintaan bid OpenRTB.

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan Ringkasan Respons Chrome
Ketersediaan fitur FLEDGE Klarifikasi tentang linimasa pengujian dan penerapan untuk fitur FLEDGE seperti penerapan Frame Berpagar, K-Anonymity, dan sebagainya. Kami memiliki status bersama tentang berbagai fitur FLEDGE cakupan dan kapan fitur tersebut akan didukung. Kami menerima masukan tambahan terkait pengumuman ini seiring upaya kami untuk terus mengembangkan FLEDGE.
Pembatasan rendering produk Permintaan untuk melonggarkan pembatasan Iklan yang Terdiri dari Beberapa Bagian untuk Frame Pagar FLEDGE Seperti yang kami umumkan pada bulan Februari, penggunaan Frame Pagar akan tetap bersifat opsional hingga setidaknya tahun 2026, dan perilaku iframe akan didukung oleh urn-iframe. Kami menyambut baik diskusi lebih lanjut tentang topik ini.
Masalah skalabilitas Performa FLEDGE seiring meningkatnya skala penggunaan Kami secara aktif menindaklanjuti masukan dan memahami lebih banyak konteks sehingga kami dapat mengusulkan solusi yang bisa ditindaklanjuti. Langkah pertama adalah memisahkan masukan menjadi dua kategori, yang telah kami lakukan:
  1. Pemfilteran berbasis SSP untuk mengoptimalkan beban kueri per detik (QPS) pada a) SSP itu sendiri dan b) DSP.
  2. Logika DailyUpdate grup minat untuk mengoptimalkan beban QPS di DSP.
(Juga dilaporkan pada Kuartal 3 2022)
Visibilitas logika bidding		 Kekhawatiran bahwa logika bidding DSP akan diekspos dalam JavaScript Info Terbaru Kuartal 1:

Kami telah membagikan proposal yang akan membatasi kemampuan penyerang untuk meminta data dari server dengan cara eksplorasi (penjelajahan paksa) dan kami menyambut baik para pelaku ekosistem untuk membagikan masukan atau dukungan mereka untuk proposal tersebut.
Kesulitan pengujian Kemampuan DSP yang lebih kecil untuk menguji FLEDGE dengan benar, dan mengurangi risiko pengiklan hanya tertarik untuk melakukan pengujian dengan DSP yang lebih besar Kami berkomitmen untuk bekerja sama dengan DSP yang lebih kecil dan sangat mendorong pengujian yang diperluas di antara DSP dan pengiklan dari semua ukuran saat FLEDGE beralih ke ketersediaan umum. Kami ingin mengetahui cara kami dapat membantu mereka menguji FLEDGE dengan pihak lain di ekosistem, dan menyambut ide serta upaya industri untuk memotivasi pengiklan agar melakukan pengujian dengan DSP yang lebih kecil.
Pemasaran ulang dinamis Apakah Pemasaran ulang dinamis masih dapat dilakukan dengan FLEDGE setelah penghentian penggunaan cookie pihak ketiga? Kami sedang mempertimbangkan respons atas pertanyaan ini dan menyambut baik pemain ekosistem untuk membagikan insight tambahan tentang cara mereka menggunakan Pemasaran ulang dinamis.
Penipuan/Penyalahgunaan Bagaimana ekosistem dapat mengurangi risiko dan menghentikan pihak tidak bertanggung jawab atau pembeli agar tidak memposisikan diri sebagai audiens yang diinginkan? Kami berharap dapat berinteraksi lebih lanjut dengan pelaku ekosistem terkait penipuan dan penyalahgunaan, serta menerima lebih banyak masukan di bidang ini.
Preferensi pengguna Proses untuk menyimpan preferensi pengguna dan menggunakannya dalam pemilihan iklan Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara materi iklan tersebut dipilih.
Proposal Pengujian Kuantitatif Agar Pengujian Kuantitatif adil, apakah pengujian harus dilakukan pada traffic tanpa cookie pihak ketiga atau dengan SSP yang hanya menggunakan FLEDGE? Bagaimana cara menghindari pencampuran sinyal dari cookie pihak ketiga? Kami menghargai masukan ini dan bekerja sama dengan CMA untuk mendesain eksperimen yang akan memberikan gambaran yang andal tentang dampak penghentian penggunaan cookie pihak ketiga dan pengenalan proposal Privacy Sandbox pada ekosistem. Sebaiknya masukan tambahan tentang proposal Pengujian Kuantitatif CMA dibagikan langsung kepada CMA.
Dokumentasi yang lebih jelas Meminta dokumentasi yang lebih jelas tentang konfigurasi lelang Kami berharap dapat membagikan postingan blog dengan ringkasan tambahan tentang Pelaporan Lelang FLEDGE dalam beberapa minggu mendatang.
Paralelisasi Apakah Layanan Bidding dan Lelang (B&A) akan mendukung Paralelisasi? Teknologi iklan yang menggunakan server Bidding / Lelang dapat memulai beberapa server yang dapat menayangkan hasil secara paralel.
Mitigasi penyalahgunaan Apakah server k-anonimitas FLEDGE yang menggunakan Token Status Pribadi akan cukup untuk memastikan privasi pengguna? Motivasi untuk k-anonymity kurang berfokus pada microtargeting dan lebih pada memiliki beberapa cadangan selama fase sementara saat FLEDGE memungkinkan pelaporan tingkat peristiwa. Kami telah membagikan lebih banyak pemikiran dan menyambut masukan tambahan.
Konflik Modul ES Meminta untuk menghapus generateBid sebagai fungsi global karena bertentangan dengan modul ES Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan.
Lelang komponen Permintaan agar penayang memiliki kontrol lebih besar atas desain lelang Bidding dan rencana lelang untuk mendukung lelang komponen, sama seperti Chrome di perangkat.
Linimasa B&A Kejelasan tentang linimasa untuk teknologi iklan yang tertarik untuk menguji Server B&A Kami baru saja memperbarui Penjelasan B&A dan memperbarui bagian Linimasa untuk menyertakan definisi yang jelas tentang linimasa untuk berbagai fase pengujian Chrome-B&A, setelah menyesuaikan dengan CMA.
Skema kontrol waktu tunggu Meningkatkan skema kontrol waktu tunggu yang saat ini tersedia untuk FLEDGE Ini adalah proposal yang menarik. Kami akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangannya.
Bidstream materi iklan Kemampuan untuk meninjau dan memfilter bid pemenang, berdasarkan materi iklan Ini adalah proposal yang menarik. Kami akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangannya.
reportWin Proposal untuk memberikan informasi tambahan tentang bid dengan skor tertinggi dari pemilik grup minat yang berbeda selain pemenang dalam fungsi reportWin Ini adalah proposal yang menarik. Kami akan mempertimbangkan untuk menambahkan sinyal tambahan dalam pelaporan gabungan dan menyambut masukan tambahan di sini.
Jenis peristiwa Menstandarkan jenis peristiwa di seluruh API pengukuran saat terintegrasi dengan FLEDGE Ini adalah proposal yang menarik. Kami akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangannya. Hal ini akan memerlukan koordinasi dengan upaya kami yang lebih luas di bidang ini, karena akan memengaruhi API Privacy Sandbox lainnya di luar FLEDGE. Kami menerima masukan tambahan di sini.
Solusi jangka panjang untuk pelaporan tingkat peristiwa Minat untuk mempertahankan data tertentu seperti highestScoringOtherBid tersedia bahkan setelah cookie pihak ketiga tidak digunakan lagi Seperti yang kami sampaikan dalam postingan blog Februari, pelaporan kemenangan lelang tingkat peristiwa akan didukung hingga "setidaknya 2026". Saat ini kami tidak memiliki detail lebih lanjut untuk dibagikan, tetapi kami menerima masukan tambahan tentang pentingnya memastikan data tertentu tetap tersedia setelah penghentian cookie pihak ketiga.
Batas grup minat Berapa batas jumlah grup minat yang dapat ditambahkan browser tunggal ke origin? Chrome mengizinkan hingga 1.000 grup minat per pemilik, dan hingga 1.000 pemilik grup minat. Ini dimaksudkan sebagai pembatasan, bukan untuk dicapai dalam operasi reguler.
Sinyal tingkat peristiwa Dukungan untuk proposal agar memiliki sinyal tingkat peristiwa untuk generateBid dan reportWin, yang dapat digunakan dalam pelatihan machine learning Kami telah menyampaikan keputusan kami untuk sinyal yang dirancang browser dan sinyal yang ditentukan teknologi iklan di sini dan menerima masukan tambahan.
Skrip bidding Sertakan ID pengguna di URL ke skrip bidding. Hal ini tidak akan mungkin karena FLEDGE memiliki persyaratan tambahan bahwa tuple pemilik grup minat, URL skrip bidding, dan materi iklan yang dirender harus bersifat k-anonim agar iklan dapat ditampilkan.
Penerapan K-anon Apakah k-anonymity diterapkan pada pasangan (componentAd, size)? Ya, akan dihapus. Lihat turtledove/issues/312.
Persyaratan Layanan Bidding dan Lelang Bagaimana Layanan B&A mendukung peserta yang berintegrasi dengan FLEDGE di perangkat dan lainnya dengan layanan B&A? Kami masih menyelesaikan desainnya dan menerima masukan tambahan di sini.
Atribusi pascatayang Apakah Atribusi pasca-penayangan akan didukung? Saat ini kami tidak memiliki definisi standar visibilitas dan mengandalkan materi iklan itu sendiri untuk menandai peristiwa penayangan. Lihat turtledove/issues/452.
Penargetan mirip Dapatkah Privacy Sandbox mendukung "penargetan mirip"? Kami membahas kasus penggunaan di sini dan menyambut input tambahan.
API pemantauan real-time Proposal untuk pendekatan pemantauan FLEDGE real-time Kami sedang membahas proposal tersebut dan menyambut masukan tambahan di sini.
Pelaporan FLEDGE reportWin dan reportResult harus dibuat dalam urutan acak untuk mencegah pelaporan berlebih atau kurang. reportResult() harus dieksekusi terlebih dahulu oleh penjual sebelum reportWin() oleh pembeli sehingga sinyal penjual dari reportResult() dapat disertakan dalam reportWin(). Lihat penjelasan untuk mengetahui informasi selengkapnya.
Server Nilai Kunci (K/V) kustom Apakah server K/V kustom akan didukung di masa mendatang? Kami membahas pertanyaan tersebut di sini dan menerima masukan tambahan apa pun.
Lelang tingkat teratas Apakah seseorang harus menjadi server iklan untuk menjalankan mekanisme lelang tingkat teratas? FLEDGE API tidak menentukan pihak mana yang harus memanggilnya; tidak ada persyaratan dalam hal tersebut dalam desain FLEDGE. Siapa saja dapat menjalankan lelang FLEDGE (termasuk lelang multi-penjual). Seperti yang disebutkan dalam laporan K4 2022, FLEDGE memungkinkan setiap penayang memilih struktur lelang, termasuk pilihan penjual komponen dan tingkat teratas.
Cakupan API Apakah FLEDGE bermaksud untuk menggunakan data pihak pertama? Kami akan memublikasikan konten pada Kuartal 2 2023 yang menjelaskan bahwa data pihak pertama memang dapat digunakan dengan FLEDGE untuk 1) digunakan sebagai logika untuk menentukan keanggotaan grup minat dan 2) dimasukkan sebagai sinyal bidding pengguna untuk digunakan dalam pembuatan logika bidding berikutnya.
Grup minat lintas-domain Kemungkinan membuat grup minat lintas-domain Informasi apa pun yang tersedia pada saat menambahkan browser ke grup minat dapat digunakan untuk menginformasikan audiens tersebut. Saat cookie pihak ketiga dihentikan secara bertahap, ketersediaan data lintas situs untuk menginformasikan pembuatan grup minat akan dibatasi.
Logika bidding sisi klien Mentransfer logika bidding sisi server yang ada ke sisi klien Kami ingin mempelajari lebih lanjut area yang menantang atau saat ini kurang dalam proses transfer, dan menyambut masukan tambahan atau insight.
Nilai server K/V Apakah nilai server K/V harus berupa string? Nilai harus berupa string, tetapi dapat menyimpan objek dalam JSON atau buffer protokol dan melakukan serialisasi ke dalam string.
Daftar yang tidak diberi akses pengiklan Sinyal mana yang sesuai untuk memberikan daftar blokir pengiklan kepada pembeli? Tempat yang sesuai adalah di auctionSignals atau di perBuyerSignals.
Unit bidding Dukungan untuk berbagai unit bidding seperti CPI dan CPM Kami ingin mempelajari lebih lanjut alasan hal ini diperlukan mengingat desain saat ini dan ingin mendengar masukan tambahan.
Logika lelang Apakah browser atau server Iklan yang menentukan pemenang lelang? Semua pemilihan pemenang dijalankan di dalam sandbox, dan semua keputusan dibuat oleh kode penjual. Browser hanya menyediakan lingkungan pribadi yang tertutup tempat kode pembeli dan penjual berjalan.
Permissions-Policy Apakah Kebijakan Izin FLEDGE saat ini akan terus diterapkan setelah Uji Coba Origin berakhir? Untuk Uji Coba Origin, daftar yang diizinkan default saat ini untuk kedua fitur tersebut bersifat sementara dan akan diubah. Kami ingin mengetahui berapa lama teknologi iklan perlu bersiap untuk perubahan ini sebelum kami mulai menerapkan perubahan tersebut.
Batasan ukuran sinyal Permintaan Sinyal Bidding Tepercaya digabungkan di beberapa grup minat dengan trustedBiddingSignalsUrl yang sama; batas ukuran 2 MB adalah batasan. Batasan ini ada untuk pemanggil di perangkat guna mencegah resource yang berlebihan di perangkat. Pemanggil dari Server B&A akan memiliki batasan yang lebih longgar.
Sinyal pelaporan Tambahkan sinyal tambahan, error skrip, untuk memungkinkan pengambilan jumlah error sisi klien per pemilik grup minat dan per computeBid atau reportWin / reportResult. Kami mempertimbangkan potensi masalah privasi terkait proposal ini dan menyambut pemain ekosistem untuk membagikan insight tambahan tentang mengapa hal ini diperlukan.
Ukuran jendela K-Anon Meningkatkan ukuran periode K-Anon dari batas 7 hari saat ini. Hal ini sedang dipertimbangkan dan saat ini kami menunggu (dan menerima) masukan tambahan dari ekosistem.
Performa perangkat Bagaimana FLEDGE menangani performa perangkat jika pengguna berada dalam sejumlah besar grup minat? FLEDGE menawarkan beberapa opsi waktu tunggu, prioritas, dan batas di seluruh SSP dan DSP yang memberi teknologi iklan kontrol terperinci dalam situasi saat performa perangkat mungkin menjadi salah satu alasan untuk membatasi partisipasi lelang saat perangkat berada dalam sejumlah besar grup minat.
Pengujian Layanan B&A Meminta pemain ekosistem untuk menggunakan server mereka sendiri selama fase pengujian agar lebih banyak log yang tersedia untuk proses debug B&A memungkinkan pengguna meluncurkan dan menskalakan server dari penyedia cloud yang disetujui. Untuk menjaga privasi pengguna, kami mewajibkan eksekusi dilakukan dalam trusted execution environment (TEE). Kami akan segera merilis penjelasan tentang proses debug B&A TEE dan sedang mengembangkan fitur untuk mendukungnya. Kami mencari masukan tambahan tentang topik ini.
Persyaratan peraturan Apakah FLEDGE akan bekerja sama dengan penyedia cloud di berbagai negara untuk mendukung kepatuhan terhadap persyaratan peraturan setempat? Kami selalu terbuka untuk saran terkait penyedia cloud lainnya, tetapi saat ini kami berencana setidaknya untuk mendukung GCP dan AWS saat penghentian cookie pihak ketiga diterapkan. Lihat penjelasan ini untuk mengetahui informasi selengkapnya.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan Ringkasan Respons Chrome
Analisis data dampak derau Panduan cara melakukan analisis data tentang dampak Derau Kami telah membagikan dokumentasi tambahan terkait derau dan terkait derau serta keputusan desain yang dapat digunakan untuk mengubah dampak derau pada data teknologi iklan.

Panduan yang lebih mendetail juga tersedia.
Pelaporan null Kejelasan tentang penerapan laporan null Saat ini kami sedang mengerjakan proposal untuk menerapkan laporan null dan akan segera membagikan detail selengkapnya. Dengan menerapkan laporan null, kami dapat mengurangi keterlambatan laporan tanpa mengorbankan privasi.
Tingkat kebisingan Menyesuaikan tingkat derau berdasarkan panjang periode atribusi Kami menyambut baik proposal ini dan sedang mempertimbangkan untuk menambahkannya ke spesifikasi. Kami menerima masukan tambahan di sini.
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/konteks tentang pengguna dibatasi. Kami menyambut baik pemain ekosistem untuk mengirim masukan tentang apakah parameterisasi saat ini untuk pelaporan tingkat peristiwa sudah sesuai.
Pemicu pelaporan tingkat peristiwa Mengizinkan prioritas dalam kunci penghapusan duplikat Kami sedang mencari solusi untuk masalah ini dan menerima masukan tambahan.
Dukungan proses debug Kejelasan tentang proses debug setelah penghentian penggunaan cookie pihak ketiga Kami ingin mendukung proses debug setelah penghentian cookie pihak ketiga dan sedang mempertimbangkan berbagai opsi. Kami mencari masukan dan ide tambahan.
Alternatif konversi klik-tayang Meminta panduan lebih lanjut tentang alternatif untuk konversi klik-tayangan Sebaiknya ekosistem menggunakan Attribution Reporting API sebagai sistem pengukuran pribadi yang andal untuk kasus penggunaan pengukuran konversi yang berlaku. Ada alternatif lain dan penyedia teknologi iklan harus memutuskan solusi yang sesuai berdasarkan kebutuhan privasi dan utilitas yang diinginkan.
Kasus penggunaan penagihan Kejelasan tentang sejauh mana Pelaporan Atribusi akan mendukung kasus penggunaan penagihan berbasis konversi Kami sedang berupaya memposting secara publik untuk mengklarifikasi cakupan Attribution Reporting API untuk penagihan. Attribution Reporting API awalnya tidak dicakup dengan cara yang secara langsung mendukung penagihan CPA; API ini mendukung penagihan CPC dan CPM, yang merupakan struktur penagihan yang digunakan sebagian besar teknologi iklan.
Hal ini mungkin akan kami dukung di masa mendatang jika ada masukan ekosistem tambahan.
Dukungan kasus penggunaan Dokumentasi kasus penggunaan untuk Measurement API Kami sedang berupaya mengklarifikasi dokumentasi untuk semua platform pelaporan Privacy Sandbox.
Mutu klik Permintaan untuk menambahkan sinyal guna membedakan klik yang disengaja dan tidak disengaja pada iklan Kami sedang mendiskusikan permintaan tersebut dan menerima masukan tambahan.
Solusi pengukuran Dukungan untuk solusi pengukuran di beberapa DSP Attribution Reporting API dapat digunakan oleh penyedia pengukuran untuk menghapus duplikat di antara beberapa DSP. Selain itu, kami mengusulkan dukungan untuk daftar URL di attributionsrc, yang akan mempermudah DSP untuk mendukung permintaan Attribution Reporting API penyedia pengukuran. Kami menerima masukan tambahan apa pun tentang proposal di atas.
Pelaporan tingkat peristiwa Permintaan untuk memiliki jumlah hari sebelum laporan dikirim langsung tersedia Permintaan ini sudah dapat dihitung oleh teknologi iklan menggunakan informasi yang tersedia saat ini. Kami belum mendengar masukan ekosistem lain terkait permintaan ini, tetapi kami menerima masukan tentang hal tersebut.
source_registration_time Menambahkan source_registration_time di Pelaporan Atribusi tingkat peristiwa. Kami mempertimbangkan permintaan ini dan menerima masukan tambahan tentang apakah pemain ekosistem menganggap fitur ini berguna.
Mode Samaran Apakah solusi pengukuran akan tersedia saat pengguna berada dalam mode Samaran? Tidak, solusi pengukuran tidak akan tersedia saat pengguna berada dalam mode Samaran. Cookie pihak ketiga dinonaktifkan secara default dalam mode Samaran.
Ruang bersih data Apakah Measurement API akan kompatibel dengan ruang bersih? Ruang bersih data standar adalah lingkungan tempat setiap data ID dari berbagai sumber diupload ke database untuk menjalankan analisis berdasarkan penggabungan data pokok tersebut. Dua framework pengukuran untuk Privacy Sandbox API adalah laporan tingkat peristiwa dan laporan ringkasan. Laporan tingkat peristiwa memang berisi ID peristiwa yang disediakan teknologi iklan yang dapat digunakan di cleanroom data, tetapi informasi sisi konversi yang terkait akan terbatas dan berisi derau. Laporan gabungan terenkripsi tidak dapat digunakan langsung di ruang bersih, tetapi hasil ringkasan yang disediakan oleh Layanan Agregasi dapat digunakan sebagai input untuk analisis yang Anda lakukan atau sebagai informasi tambahan.

Layanan Agregasi

Tema Masukan Ringkasan Respons Chrome
(Juga dilaporkan pada K4 2022)
Penundaan pelaporan		 Berapa perkiraan keterlambatan pelaporan? Info Terbaru Kuartal 1 2023:

Sesuai masukan partner, kami telah membagikan proposal untuk mengurangi keterlambatan dan meminimalkan dampak keterlambatan.

Kedua proposal tersebut telah didukung oleh teknologi iklan selama panggilan WICG.
Aturan tidak ada duplikat Bagaimana cara menangani "laporan agregat yang tertunda" jika laporan agregat, yang memiliki ID bersama yang sama, sudah diproses? Kami telah membagikan proposal tentang penambahan penundaan laporan tambahan ke info bersama laporan agregat dan definisi ID bersama untuk Layanan Agregasi untuk mengatasi sebagian dampak hilangnya penundaan pada API gabungan. Kami menerima masukan apa pun tentang proposal tersebut.
Pemrosesan data Permintaan untuk mengaktifkan dukungan bagi beberapa penerusan data sekaligus menghormati privasi diferensial, menggunakan Anggaran Privasi Kami sedang membahas kemungkinan penggunaan cara yang lebih fleksibel untuk menggunakan Privacy Budget guna mengaktifkan kasus penggunaan ini dan menerima masukan tambahan.
(Juga dilaporkan pada Kuartal 2 2022) Ergonomi kueri Mengaktifkan kueri agregat kunci. Info Terbaru Kuartal 1 2023:

Permintaan fitur masih dipertimbangkan, tetapi saat ini kami tidak memiliki proposal untuk dibagikan.
Batasan Uji Coba Origin Mengklarifikasi cakupan Layanan Agregasi seperti "aturan tidak ada duplikat" yang saat ini tidak diterapkan dalam uji coba origin. Kami sedang mempertimbangkan untuk memperbarui dokumentasi guna memperjelas apa yang akan tersedia dalam uji coba origin vs. dalam GA.

Private Aggregation API

Tema Masukan Ringkasan Respons Chrome
Anggaran Kontribusi Agregasi Pribadi Anggaran kontribusi L1 terlalu ketat. Setiap panggilan ke Private Aggregation API disebut kontribusi. Untuk melindungi privasi pengguna, jumlah kontribusi yang dapat dikumpulkan dari individu dibatasi.
Saat Anda menjumlahkan semua nilai agregat di semua kunci agregasi, jumlah tersebut harus kurang dari anggaran kontribusi.

Berdasarkan desain saat ini, kami menetapkan batas kontribusi untuk asal pelaporan tertentu selama ~24 jam terakhir (sebagai periode bergulir). Ini adalah anggaran kontribusi L1 yang disebutkan dalam masukan. Sebaiknya developer menskalakan nilai yang mereka kontribusikan berdasarkan volume yang diharapkan (yaitu, tidak hanya menggunakan nilai 1). Jadi, sebaiknya gunakan nilai yang lebih kecil untuk peristiwa yang lebih umum agar tidak menghabiskan anggaran.

Saat ini kami mencari beberapa masukan tentang anggaran kontribusi Private Aggregation API pada batas numerik dan cakupan. Kami mempertimbangkan untuk memindahkan cakupan dari per origin ke per situs dan memindahkan batas yang ada ke periode sepuluh menit dengan batas harian yang lebih besar.

Membatasi Pelacakan Tersembunyi

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tema Masukan Ringkasan Respons Chrome
Adopsi UA-R Dari 10.000 situs teratas di Inggris Raya, hanya 1% situs yang menggunakan iklan terprogram yang mengirimkan petunjuk klien HTTP. DSP yang belum dimigrasikan dapat memengaruhi kemampuan anti-penipuan. Setelah menjalankan analisis pada set data yang sama, kami mendapati bahwa jika Anda memperhitungkan penggunaan UA-CH menggunakan tag <meta> HTML, dan API JavaScript, jumlah situs yang menggunakan UA-CH secara signifikan lebih tinggi daripada angka 1% yang diberikan dalam masukan. Berdasarkan hal ini, dan fakta lainnya termasuk masukan ekosistem, kami merasa yakin untuk melanjutkan peluncuran bertahap Fase 6 Pengurangan UA, sesuai dengan linimasa yang dipublikasikan, sambil terus memberi tahu CMA. Kami mencatat bahwa situs telah memiliki waktu tunggu hampir dua tahun untuk mempersiapkan transisi dan uji coba penghentian masih tersedia untuk situs yang merasa belum siap.
Petunjuk untuk faktor bentuk tambahan Permintaan untuk UA-CH agar menyediakan faktor bentuk tambahan seperti TV, VR Kami menyambut baik proposal ini dan sedang mempertimbangkan untuk memasukkannya ke dalam desain. Kami menerima masukan tambahan.
Pengujian otomatis Permintaan untuk menyelesaikan bug UA-CH di Chrome headless sebelum UAR Fase 6 dikirim Bug yang dimaksud telah diperbaiki.
Dukungan UA-CH di iOS Situs yang mengandalkan info UA terperinci untuk kasus penggunaan iklan akan mencantumkan bahwa Chrome di iOS tidak didukung. Untuk browser iOS non-Safari (termasuk Chrome di iOS), project WebKit harus menambahkan dukungan untuk UA-CH sebelum dapat diaktifkan (karena mengontrol stack jaringan).

Perlindungan IP (sebelumnya bernama Gnatcatcher)

Tema Masukan Ringkasan Respons Chrome
(Juga dilaporkan pada Kuartal 4) Kasus penggunaan geolokasi Perlindungan IP dapat mencegah kasus penggunaan geolokasi yang sah berfungsi di masa mendatang, seperti personalisasi konten berdasarkan geolokasi. Respons kami tidak berubah sejak Kuartal 4 2022:

"Kami bekerja sama dengan pemangku kepentingan untuk memastikan Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami mencari masukan ekosistem tentang tingkat perincian Geolokasi IP."
Kepatuhan terhadap peraturan Jika suatu wilayah memiliki populasi kurang dari 1 juta, nilai minimum saat ini sebesar 1 juta untuk perlindungan IP akan mencegah situs menggunakan alamat IP untuk kepatuhan peraturan. Kami bekerja sama dengan pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami mencari masukan ekosistem terkait kepatuhan peraturan terkait Perlindungan IP.
Mitigasi penyalahgunaan Pihak dapat mengakali Perlindungan IP dengan membagikan alamat IP yang tidak disamarkan kepada orang lain. Kami menyadari risiko bahwa proposal Perlindungan IP saat ini mungkin secara teknis tidak mencegah pihak membagikan alamat IP yang tidak disamarkan kepada orang lain. Kami sedang berupaya untuk melakukan mitigasi yang akan menghindari risiko penyalahgunaan ini.

Seiring dengan iterasi proposal, kami mendorong lebih banyak masukan dan diskusi. Secara khusus, kami ingin mengetahui kasus penggunaan saat pihak yakin bahwa mereka perlu membagikan alamat IP yang tidak disamarkan kepada pihak lain.
Pemblokiran jaringan Pihak dapat mengakali pemblokiran jaringan dengan menggunakan Proxy Perlindungan IP. Entitas yang melakukan pemblokiran harus menonaktifkan Perlindungan IP untuk skenario ini. Kami telah merespons masalah tersebut dan menerima masukan tambahan.
Daftar blokir alamat IP yang terpengaruh oleh proposal Perlindungan IP Banyak perusahaan teknologi iklan menggunakan daftar blokir dasar alamat IP, seperti daftar IP datacenter TAG, untuk mencegah bidding pada inventaris iklan yang sangat mungkin menipu (atau setidaknya tidak dapat dimonetisasi). Jika teknologi iklan juga merupakan pelacak dan dapat tunduk pada proposal Perlindungan IP, perusahaan tersebut dapat kehilangan kemampuan untuk melakukan pemeriksaan dasar terhadap iklan sebelum membeli inventaris iklan. Kami mendorong masukan lebih lanjut dan diskusi tentang Proposal Perlindungan IP terkait potensi masalah dan solusi. Salah satu opsi adalah menerapkan daftar serupa ke Perlindungan IP, sehingga kami tidak melakukan proxy klien yang berasal dari alamat IP yang sebelumnya ditandai.

Memperkuat batasan privasi lintas situs

Set Pihak Pertama

Tema Masukan Ringkasan Respons Chrome
(Juga dilaporkan pada Kuartal 4) Batas domain Meminta untuk memperluas jumlah domain terkait Respons kami tidak berubah sejak Kuartal 4 2022:

"Kami telah menjelaskan dalam panggilan WICG bahwa Chrome berkomitmen untuk menyediakan solusi yang dapat digunakan yang juga mempertimbangkan minat privasi pengguna. Sehubungan dengan hal tersebut, kami menghargai masukan dari komunitas terkait kasus penggunaan tertentu yang mungkin dipengaruhi oleh batas domain, sehingga tim dapat mempertimbangkan cara untuk menangani kasus penggunaan ini sekaligus terus melindungi privasi pengguna."
Pengiriman FPS alternatif Proposal untuk cara alternatif guna mengirimkan daftar global untuk FPS Saat ini, kami sedang bersiap untuk mengirimkan Set pihak pertama (FPS) di Chrome, dan telah menyiapkan repositori GitHub terpusat untuk menerima pengiriman set. Karena kami berharap bahwa FPS akan mengisi kesenjangan dengan solusi platform web yang ada sebagai persiapan untuk penghentian penggunaan cookie pihak ketiga, kami berharap dapat mempelajari cara FPS dimanfaatkan oleh penulis situs. Seiring daftar set bertambah seiring waktu, dan ekosistem beradaptasi dengan dunia pasca-cookie pihak ketiga, kita juga dapat mengembangkan proses hingga tahap kita dapat mempertimbangkan skema terdesentralisasi alternatif seperti yang diusulkan. Dengan proses saat ini, kami berharap dapat menerapkan masa aktif yang ditetapkan, yang akan memungkinkan kami mengembangkan proses penerimaan seiring waktu. Kita dapat meninjau kembali ide ini setelah proses pengiriman selesai.
Moderasi repo Menerapkan moderasi komunitas pada repo Pengiriman FPS untuk mencegah penyalahgunaan. Pelaku kejahatan dapat dengan mudah membebani proses yang menggunakan origin burner untuk mengusulkan set, dan volume permintaan yang luar biasa mungkin memengaruhi operasi untuk proposal set yang asli. Kami mencoba membuat pemeriksaan seobjektif mungkin dengan mengandalkan pemeriksaan validasi teknis. Menurut kami, ini adalah pendekatan yang paling skalabel untuk proses pengiriman. Sesuai dengan sasaran ini, kami juga akan berupaya memastikan prosesnya tahan terhadap kiriman spam / burner.
Subkumpulan terkait Apakah FPS dapat mendukung kasus penggunaan alur Vendor/SaaS pihak ketiga melalui Subkumpulan terkait? Alur vendor / SaaS pihak ketiga bukan kasus penggunaan yang saat ini dipertimbangkan dalam cakupan untuk Set Pihak Pertama. Kami menerima masukan tambahan tentang cara cookie lintas situs digunakan untuk kasus penggunaan ini.
Integrasi FPS + CHIPS Meminta integrasi FPS + CHIPS untuk mendukung kasus penggunaan seperti pengujian A/B Kami sedang membahas kasus penggunaan ini dan juga mempertimbangkan untuk membahasnya lebih lanjut dalam panggilan WICG dan menerima masukan tambahan di sini.
GDPR Proposal untuk subset FPS baru yang akan dimodelkan berdasarkan konsep GDPR Kami telah membahas proposal ini secara internal dan mempertimbangkannya dengan masukan lain yang diterima serta sasaran privasi kami. Kami telah memberikan jawaban yang menjelaskan alasan kami tidak akan melanjutkan proposal ini saat ini.
Memori Perubahan yang diharapkan pada ukuran memori browser saat daftar FPS disertakan Ada preseden bagi browser untuk menyimpan jenis daftar ini dengan dampak memori minimal, seperti Daftar Perlindungan Pelacakan Disconnect. Meskipun daftar Set Pihak Pertama akan disalin ke setiap klien Chrome secara lokal, kami akan terus memantau ukuran file dan yakin bahwa kami dapat mengoptimalkan jejak memori.

Fenced Frames API

Tema Masukan Ringkasan Respons Chrome
Batasan Frame Pagar Kejelasan terkait batasan yang diberlakukan oleh Bingkai Pagar Pada bulan Maret, kami memperbarui penjelasan tentang Frame Berpagar yang memberikan informasi tentang kemampuannya dan kami menerima masukan tambahan.
Memperluas informasi akses Permintaan untuk memperluas akses ke informasi di sekitar frame tetangga Kami ingin lebih memahami mengapa hal ini merupakan persyaratan dari ekosistem, dan kami menerima masukan tambahan.
Frame dengan Pagar dan iframe Pertanyaan terkait paritas fitur antara Bingkai Pagar dan iframe Semua laporan dan API Privacy Sandbox yang tersedia akan tersedia untuk iframe dan FencedFrames dengan cara yang sama.
Mengubah Ukuran Frame dengan Pagar Membatasi perubahan ukuran frame akan memengaruhi kasus penggunaan tertentu. Kami ingin mempelajari lebih lanjut jenis kasus penggunaan yang dipengaruhi oleh pembatasan ini dan akan menerima masukan tambahan.

Shared Storage API

Tema Masukan Ringkasan Respons Chrome
Worklet pihak ketiga Dapatkah pihak ketiga menulis ke Penyimpanan Bersama, yang dipartisi menurut origin? Atau memanggil worklet lain untuk pengukuran pihak ketiga? Asal konteks penjelajahan tempat kode dijalankan menentukan penyimpanan bersama tempat data tersebut ditulis. Saat kode pihak ketiga ditambahkan ke halaman, kode pihak ketiga dapat disematkan sebagai iframe dengan konteks penjelajahan sendiri, yang memungkinkan kode pihak ketiga menulis ke origin-nya sendiri. Kode pihak ketiga juga dapat disematkan sebagai skrip, bukan iframe, yang tidak mengganti konteks penjelajahan, dan pihak ketiga dapat menulis ke penyimpanan bersama penyematan. Perhatikan bahwa hanya pemilik penyimpanan bersama tersebut yang dapat membaca dari penyimpanan bersama tersebut.
Deduplikasi Penghapusan duplikat tidak akan dapat dilakukan untuk interaksi di luar ekosistem Chrome. Penyimpanan Bersama dimaksudkan untuk memberikan output jangkauan unik berbasis browser Chrome dalam Chrome. Kami tertarik untuk bekerja sama dengan teknologi iklan untuk memahami cara output ini dapat digunakan sebagai bagian dari model jangkauan yang lebih luas. Kami memahami bahwa output itu sendiri mungkin hanya mempertimbangkan sebagian interaksi dan tertarik untuk bekerja sama dengan teknologi iklan untuk mempelajari metodologi pemodelan tambahan yang dapat ditambahkan di atasnya.
Periode lihat balik konversi Meminta periode lihat balik untuk rasio konversi guna melihat perubahan konversi dari waktu ke waktu Hal ini dapat diterapkan dengan memproses berbagai jalur konversi di sisi klien menggunakan Shared Storage, yang memberikan fleksibilitas tambahan untuk analisis lanjutan melalui penyimpanan browser yang aman dan tidak dipartisi.
Periode habis masa berlaku item Meminta perpanjangan periode habis masa berlaku hingga 90 hari Kebijakan retensi data diperbarui pada November 2022, dan menyatakan bahwa setiap kunci akan dihapus setelah tiga puluh hari sejak penulisan terakhir. Kami menerima masukan tambahan untuk memahami apakah kebijakan baru akan berfungsi untuk ekosistem.
Rotasi materi iklan Kasus penggunaan rotasi materi iklan tidak mencerminkan tindakan sebenarnya setelah lelang. Kami ingin mendengar dari lebih banyak perusahaan teknologi iklan sisi beli tentang apakah dokumentasi rotasi materi iklan akurat atau tidak.

CHIPs

Tidak ada masukan yang diterima kuartal ini.

FedCM

Tema Masukan Ringkasan Respons Chrome
Endpoint pernyataan identitas Izinkan permintaan arbitrer secara eksplisit ke endpoint pernyataan identitas. Kami telah berkolaborasi dengan Mozilla dalam permintaan pull ini untuk membatasi kemampuan situs dalam membuat permintaan kredensial lintas origin secara diam-diam tanpa menyebabkan gangguan bagi pengguna dan akan terus meninjau serta menangani masukan lainnya.
Mengisi otomatis identitas Dapatkah FedCM digunakan untuk mengisi otomatis formulir login dengan penyedia identitas dari daftar FedCM? Masalah untuk kasus penggunaan ini adalah kasus ini dapat menyebabkan kebocoran informasi saat situs yang belum berinteraksi dengan pengguna dapat mengkueri IDP terakhir yang digunakan oleh pengguna. Kami sedang membahas masalah ini dan menerima masukan tambahan.
Pemilihan akun kontekstual Proposal untuk menambahkan sinyal kontekstual di UI pemilihan akun Kami sedang mempertimbangkan proposal ini dan menyambut baik diskusi tambahan.

Memerangi spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan Ringkasan Respons Chrome
Survei pengumpulan kemampuan Pada awal K1, kami selesai mengumpulkan hasil survei tentang kemampuan yang diperlukan untuk berbagai kasus penggunaan anti-penipuan, dan membagikannya secara publik (notulen, hasil) Kami berencana untuk menyertakan masukan ini saat mengembangkan proposal dan prototype baru untuk API yang dirancang khusus dan menjaga privasi untuk kemampuan anti-penipuan. Kami berharap dapat memprioritaskan pengembangan jika ada kebutuhan yang memadai dan ada teknologi yang sudah ada yang dapat kami kembangkan untuk memperkenalkan kemampuan ke web, sekaligus menjaga privasi pengguna. Misalnya, integritas perangkat dan booting memiliki peringkat tinggi dan banyak platform memiliki API yang ada yang membagikan penilaian integritas perangkat dengan aman, sehingga merupakan kandidat yang baik untuk melakukan eksplorasi dalam grup komunitas.
Masukan terkait Intent untuk Mengirim PST Sebagai bagian dari niat untuk mengirimkan, kami menerima kekhawatiran dalam melanjutkan karena kami menggunakan Privacy Pass versi lama. Kami juga menerima masukan bahwa spesifikasinya tidak jelas di bagian tertentu, dan harus ditingkatkan untuk memfasilitasi kompatibilitas browser. Kami berencana untuk menerapkan banyak perubahan spesifikasi yang disarankan sebelum dikirim ke GA, serta beberapa perubahan API. Masukan tersebut diterima tepat pada akhir Kuartal 1, jadi kami akan menindaklanjuti masalah GitHub dengan detail spesifik dan pembaruan pada rencana peluncuran kami (sedang berlangsung, sejak publikasi laporan masukan ini).

Untuk perubahan yang lebih besar pada API, kami terbuka untuk mempertimbangkannya, tetapi kami merasa cara terbaik untuk melanjutkan adalah dengan meluncurkannya ke ketersediaan umum dan mendapatkan masukan langsung dari lebih banyak developer. Kami berharap dapat melanjutkan diskusi ini dan mengejar standardisasi browser. Jika dan saat standar baru muncul, kami akan mempertimbangkan untuk mengadopsi dan mengembangkan rencana untuk bertransisi dengan cermat ke standar tersebut.