Laporan Masukan - Kuartal 4 2022

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

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

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

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

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

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

Glosarium akronim

CHIP

Cookie yang Memiliki Status Dipartisi Independen

DSP

Platform Sisi Permintaan

FedCM

Pengelolaan Kredensial Federasi

FPS

Set Pihak Pertama

IAB

Interactive Advertising Bureau

IDP (IDP)

Penyedia Identitas

IETF

Internet Engineering Task Force

IP

Alamat Protokol Internet

openRTB

Bidding real-time

lewat batas waktu

Uji Coba Origin

PatCG

Grup Komunitas Teknologi Periklanan Pribadi

RP

Pesta Santai

SSP

Platform Sisi Suplai

TEE

Trusted Execution Environment

UA

String Agen Pengguna

UA-CH

Petunjuk Klien Agen Pengguna

W3C

Konsorsium World Wide Web

WIPB

Kebutaan IP yang Disengaja

Masukan umum, tidak ada API/Teknologi spesifik

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada K3) Kegunaan untuk berbagai jenis pemangku kepentingan	Kekhawatiran bahwa teknologi Privacy Sandbox mengutamakan developer yang lebih besar dan bahwa situs khusus (lebih kecil) berkontribusi lebih besar daripada situs generik (lebih besar)	Respons kami tidak berubah dari Q3: "Google telah berkomitmen pada CMA untuk merancang dan menerapkan proposal Privacy Sandbox melalui cara yang tidak mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, serta mempertimbangkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan, terlepas dari ukuran mereka. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini. Seiring dengan berlangsungnya pengujian Privacy Sandbox, salah satu pertanyaan utama yang akan kami nilai adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan spesifik dan dapat ditindaklanjuti yang dapat membantu kami meningkatkan kualitas desain teknis lebih lanjut. Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan pengujian kuantitatif, dan mendukung CMA dengan memublikasikan catatan tentang desain eksperimen guna memberikan lebih banyak informasi kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan."
(Juga dilaporkan pada K3) Permintaan dokumentasi	Permintaan lebih banyak resource yang menjelaskan cara mengelola pengujian, analisis, dan implementasi	Pembaruan K4: Kami menghargai bahwa developer menganggap materi kami saat ini bermanfaat, dan terus berkomitmen untuk menyediakan lebih banyak materi sehingga developer dapat memahami cara teknologi baru dapat berguna bagi mereka. Selama kuartal terakhir, kami menambahkan bagian "Berita & Update" ke privacysandbox.com dan memublikasikan ulasan lengkap tentang cara Privacy Sandbox membantu mendorong relevansi iklan di masa mendatang. Kami juga mengadakan sesi waktu konsultasi publik untuk developer untuk berbagi demo dan praktik terbaik, beserta sesi Tanya Jawab dengan pemimpin produk dan engineer untuk diskusi/pertanyaan langsung.
Data Web Inti	Bagaimana pengaruh latensi API Privacy Sandbox terhadap Data Web Inti?	Menjaga latensi seminimal mungkin adalah sasaran desain utama Privacy Sandbox API. Ekspektasi kami saat ini adalah latensi API akan berdampak minimal pada Data Web Inti situs, karena sebagian besar API dipanggil setelah rendering awal situs. Kami terus memantau dan melakukan peningkatan untuk mengurangi latensi lebih lanjut untuk setiap API, serta mendorong pengujian dan masukan yang berkelanjutan. Latensi dalam proses bidding real-time dibahas di bagian FLEDGE di bagian "Performa Lelang FLEDGE"
Interoperabilitas	Kekhawatiran mengenai interoperabilitas dengan solusi potensial lainnya	Tujuan Privacy Sandbox adalah untuk melindungi pengguna dari pelacakan lintas situs sekaligus mendukung kebutuhan ekosistem web. Kami berupaya mencapai hal ini dengan beralih dari teknologi browser lama yang memungkinkan pelacakan lintas situs semacam itu, seperti cookie pihak ketiga, dan menyediakan sebagai gantinya teknologi baru yang dibuat khusus untuk mendukung kasus penggunaan tertentu. Proposal Privacy Sandbox meningkatkan privasi dengan membatasi data yang keluar dari perangkat pengguna. Proposal ini tidak menempatkan batasan teknis pada kemampuan situs untuk berbagi atau memproses data setelah dikumpulkan dari browser. Oleh karena itu, teknologi tersebut tidak mencegah perusahaan mengadakan perjanjian "pengelolaan data" atau hubungan kontrak serupa lainnya. Demikian juga, mereka tidak membatasi kemampuan pengguna untuk setuju berbagi data mereka dengan cara lain. Agar lebih jelas, Google telah berkomitmen untuk menerapkan teknologi Privacy Sandbox dengan cara yang sama ke semua situs, termasuk produk dan layanan Google. Setelah Chrome mengakhiri dukungan untuk cookie pihak ketiga, komitmen ini juga memperjelas bahwa Google tidak akan menggunakan data pribadi lainnya, seperti histori penjelajahan Chrome yang disinkronkan milik pengguna, untuk melacak pengguna terkait penargetan atau pengukuran iklan digital.

Tampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Dampak pada peringkat penelusuran Google	Pertanyaan tentang apakah dukungan Topics API situs akan digunakan sebagai sinyal potensial untuk peringkat hasil Google Penelusuran	Beberapa situs mungkin memilih untuk tidak menggunakan Topics API. Tim Privacy Sandbox belum mengoordinasikan atau meminta dari organisasi Penelusuran agar mereka menggunakan peringkat halaman sebagai insentif bagi situs untuk mengadopsi Topics API. Google telah mengonfirmasi kepada CMA bahwa Google Penelusuran tidak akan menggunakan keputusan situs untuk memilih tidak ikut Topics API sebagai sinyal peringkat.
Pengklasifikasi topik	Tambahkan URL dan konten halaman selain nama host untuk menentukan Topik halaman web agar dapat meningkatkan kegunaan bagi berbagai pemangku kepentingan.	Histori penjelajahan pengguna saat ini diklasifikasikan menggunakan nama host situs. Chrome terus mengevaluasi opsi untuk mempertimbangkan metadata tingkat halaman (seperti semua atau beberapa komponen URL dan/atau konten halaman) dalam klasifikasi Topics. Setiap peningkatan utilitas harus dipertimbangkan untuk risiko privasi dan penyalahgunaan. Misalnya, secara khusus terkait dengan metadata, beberapa risikonya meliputi: - Situs yang mengubah metadata tingkat halaman sebagai metode untuk mengenkode berbagai makna (dan berpotensi sensitif) ke dalam topik; - Situs yang memodifikasi metadata tingkat halaman untuk memberikan pernyataan tidak benar tentang topiknya demi keuntungan finansial; - Situs yang mengubah metadata tingkat halaman secara dinamis sebagai metode pelacakan lintas situs
(Juga dilaporkan pada Kuartal 3) Dampak pada sinyal pihak pertama	Sinyal topik mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya.	Respons kami tidak berubah dari Q3: "Kami yakin periklanan menurut minat merupakan kasus penggunaan yang penting bagi web, dan Topics dirancang untuk mendukung kasus penggunaan tersebut. Seperti yang dijelaskan [dalam laporan K3 kami], pemangku kepentingan ekosistem lainnya telah menyampaikan kekhawatiran bahwa Topics mungkin tidak cukup berguna untuk memberikan nilai. Dalam semua kasus, peningkatan pada taksonomi adalah upaya berkelanjutan, dan kami berharap taksonomi akan berkembang dengan pengujian dan input ekosistem."
Memperbarui Taksonomi	Bagaimana daftar taksonomi akan diperbarui?	Kami secara aktif meminta masukan terkait taksonomi yang paling berguna bagi ekosistem. Taksonomi yang disertakan dalam proposal Topics API awal dirancang untuk memungkinkan pengujian fungsional. Chrome secara aktif mempertimbangkan beberapa pendekatan untuk memperbarui taksonomi. Misalnya, Chrome dapat menggunakan gagasan nilai komersial untuk setiap topik guna menentukan kategori yang akan disertakan dalam iterasi mendatang.
Performa pengklasifikasi regional topik	Pengklasifikasi topik berperforma buruk di domain regional	Penyempurnaan pada pengklasifikasi adalah upaya berkelanjutan. Berdasarkan masukan yang kami terima, satu kemungkinan yang sedang dipertimbangkan adalah memperluas daftar penggantian Topics, yang ditunjukkan oleh analisis kami akan memperluas cakupan global dan meningkatkan akurasi. Sebagai penjelasan, klasifikasi Topics API memiliki dua komponen yang relevan: (1) Daftar penggantian yang berisi 10 ribu situs teratas beserta topiknya, dan (2) model ML di perangkat yang mengklasifikasikan nama host ke dalam topik. Dengan memperluas daftar penggantian (1), kami dapat meningkatkan performa klasifikasi untuk wilayah tempat pengklasifikasi mungkin berperforma buruk.
Epoch satu minggu	Epoch satu minggu terlalu panjang bagi pengguna yang ingin membuat keputusan jangka pendek.	Kami terus berupaya menentukan durasi epoch yang sesuai dan kami mengharapkan masukan lebih lanjut terkait epoch yang lebih baik untuk ekosistem ini.
Pengambilan header HTTP	Masalah terkait pengambilan topik header HTTP tidak memadai	Pekerjaan sedang berlangsung untuk header dan fetch(). Kami juga memiliki informasi yang tersedia di sini. Kami juga telah menambahkan informasi skipObservation ke penjelasan.
Topics hanya bertujuan untuk membantu pengiklan, bukan pengguna	Topics/Privacy Sandbox tampaknya menjadi pendekatan yang berfokus pada industri. Manfaat bagi pengguna tidak sejelas manfaat bagi industri.	Kami yakin manfaat bagi pengguna adalah Topics mendukung iklan menurut minat yang membuat web tetap bebas dan terbuka. Kami juga yakin bahwa Topics meningkatkan privasi secara signifikan dibandingkan dengan cookie pihak ketiga. Menghapus cookie pihak ketiga tanpa alternatif yang memungkinkan dapat berdampak negatif terhadap penayang, dan dapat menyebabkan pendekatan yang lebih buruk yang kurang pribadi, tidak transparan, dan tidak dapat direset atau dikontrol oleh pengguna secara realistis. Banyak perusahaan secara aktif menguji Topics dan Sandbox API, dan kami berkomitmen untuk menyediakan alat untuk meningkatkan privasi dan mendukung web. Grup Arsitektur Teknis W3C baru-baru ini memublikasikan tampilan awalnya tentang Topics API, yang akan kami respons secara publik. Pada tahap ini, karena Google telah menerima pertanyaan dari ekosistem tentang apa yang mungkin diindikasikan oleh ulasan ini untuk pengembangan dan peluncuran Topics API, kami ingin menegaskan kembali rencana kami untuk menyediakannya di Chrome Stabil tahun ini. Meskipun Google menghargai masukan dari W3C Technical Architecture Group, namun menganggap penting untuk melanjutkan upaya pengembangan dan pengujian Topics melalui konsultasi dengan CMA dan ekosistem.
Kebocoran data	Kekhawatiran bahwa Topics dapat bocor ke situs lain tanpa izin	Desain Topics API membuatnya sangat kecil kemungkinannya bahwa data dari satu penayang (dan bahkan grup penayang yang lebih kecil) bisa dibocorkan dengan cara apa pun. Situs penayang juga memiliki kontrol penuh atas Topics API dan dapat melarang akses ke API ini melalui kebijakan izin.
Kurangnya pengiklan untuk pengujian	Penayang khawatir saat ini mereka tidak dapat menunjukkan nilai Topics kepada pengiklan.	Pada paruh kedua tahun 2023, kami berencana menyediakan semua API terkait iklan untuk pengujian integrasi dan memungkinkan analisis ekosistem nilai Topics untuk pengiklan. Pengujian dan publikasi hasil akan diawasi oleh CMA, yang akan meninjau data, analisis, dan metodologi. Ekosistem dianjurkan untuk memberikan masukan kepada Google dan CMA.
Topik dan FLEDGE	Permintaan informasi selengkapnya tentang cara menggunakan Topics dalam logika bidding FLEDGE	Anda dapat menggunakan Topics dalam logika bidding FLEDGE. Panduan integrasi juga sedang dibuat, dan akan menyertakan detail tambahan terkait penerapan.
Peringkat kustom untuk pemanggil topik	Izinkan peringkat disesuaikan oleh penelepon	Tantangan dalam peringkat atau nilai topik kustom untuk setiap teknologi iklan adalah bahwa hal ini dapat menjadi mekanisme yang dapat digunakan teknologi iklan untuk memengaruhi topik yang ditampilkan, sehingga menjadi vektor pelacakan sidik jari.
Daftar prioritas pemanggil topik	Izinkan pemanggil memberikan daftar prioritas peringkat untuk topik yang akan ditampilkan oleh Topics API berdasarkan kelayakan.	Saat ini kami membahas ide ini lebih lanjut dan menerima masukan tambahan.

FLEDGE

Tema Masukan	Ringkasan	Respons Chrome
Google Ad Manager	Kekhawatiran bahwa Google Ad Manager adalah penentu akhir untuk lelang FLEDGE dan akan lebih memilih Tag Google Publisher dan Google Ad Manager.	FLEDGE memungkinkan setiap penayang memilih struktur lelang, termasuk pilihan penjual tingkat teratas dan komponen. Setiap pembeli dan penjual dalam lelang komponen mengetahui penjual tingkat teratas, dan dapat memilih apakah akan mengajukan bid atau tidak.
Jumlah peserta yang menguji FLEDGE tidak cukup	Permintaan untuk mendorong lebih banyak perusahaan agar menguji FLEDGE, misalnya dengan meningkatkan fungsi API dan mencegah alternatif yang mengganggu privasi seperti pelacakan sidik jari	Privacy Sandbox diproses secara bertahap, dalam kemitraan yang erat dengan panduan CMA dan ICO, dan pengujian FLEDGE fungsional telah menunjukkan stabilitas dan kemampuan yang diperlukan. Google terus mendorong ekosistem untuk menguji API Sandbox, baru-baru ini memublikasikan dokumentasi "Maksimalkan Relevansi Iklan" untuk menunjukkan bagaimana FLEDGE dan API lainnya dapat membantu mendukung kasus penggunaan penting bagi industri iklan setelah cookie pihak ketiga tidak digunakan lagi. Bagian lain dari Privacy Sandbox sudah mendukung mitigasi untuk mencakup pelacakan (lihat UA-CH, Perlindungan IP, dan Mitigasi Pelacakan Kembali) dan akan terus ditingkatkan kualitasnya seiring waktu. Tujuan Google bukan menjadikan FLEDGE sebagai satu-satunya solusi penargetan yang layak, tetapi tetap berkomitmen untuk bekerja sama dengan industri dan badan pengatur untuk mendorong teknologi iklan terbaik yang menjaga privasi di browser Chrome.
Kasus penggunaan machine learning	Panduan selengkapnya tentang cara kasus penggunaan machine learning untuk melatih algoritma bidding lelang akan didukung di FLEDGE dan Attribution Reporting	Kami menyadari perlunya membantu penguji menemukan cara yang paling berguna untuk menerapkan teknologi Privacy Sandbox. Kami telah mulai memublikasikan panduan yang secara khusus terkait dengan penggunaan berbagai aspek Privacy Sandbox API sebagai input untuk machine learning. Bagian terbaru, "Maksimalkan Relevansi Iklan", membahas bagaimana industri iklan dapat memanfaatkan sinyal ini untuk machine learning, dan kami berencana untuk terus memublikasikan panduan tersebut ke depannya.
Membuat kueri Server Nilai Kunci FLEDGE (K/V)	Mengapa server K/V dapat dikueri secara publik?	Server K/V bertujuan untuk menyediakan sinyal real-time ke lelang FLEDGE. Dengan demikian, server K/V harus dapat diakses dari tempat lelang FLEDGE tersebut dijalankan, yaitu di perangkat pengguna, sehingga harus tersedia untuk publik. Nilai yang tersimpan di server K/V hanya dapat diambil oleh pihak yang telah memiliki kuncinya — jadi jika teknologi iklan hanya memberikan kunci untuk browser yang termasuk dalam Grup Minat, dan tidak menggunakan kunci yang dapat ditebak secara acak, hanya browser yang memerlukan Nilai tersebut untuk menjalankan lelang yang dapat mengambilnya.
Bagaimana cara melakukan penargetan tanggal/waktu?	Dukungan untuk objek tanggal dalam fungsi logika bidding.	Ada beberapa cara untuk melakukannya. Pembeli dapat meminta penjual untuk memberikan tanggal dan waktu saat ini, dan penjual harus dapat memberikan informasi ini dengan mudah kepada semua pembeli. Pembeli juga dapat memberikan tanggal dan waktu dalam respons nilai kunci real time mereka. Terakhir, pembeli dapat memberikan tanggal dan waktu sebagai bagian dari respons kontekstual mereka dalam sinyal per pembeli, yang dapat diteruskan penjual ke skrip generateBid pembeli.
Preferensi pengguna	Kemampuan bagi pengguna untuk memilih memblokir materi iklan oleh pengiklan saat ditayangkan melalui FLEDGE, atau solusi alternatif.	Pengguna dapat memilih untuk tidak menggunakan Ads API di Chrome. Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara pemilihan materi iklan tersebut.
Rentang waktu yang lebih jelas	Minta informasi selengkapnya tentang ketersediaan perlindungan privasi di FLEDGE, seperti mewajibkan Frame dengan Fence.	Kami berencana untuk memublikasikan linimasa yang lebih mendetail pada Kuartal 1.
Kebingungan terkait pelaporan	Minta kejelasan lebih lanjut tentang cara kerja pelaporan FLEDGE dengan API lain, seperti Fenced Frames dan Private Aggregation API.	Kami berencana memublikasikan penjelasan tentang interaksi antara Private Aggregation API, FLEDGE, dan Fenced Frames dalam beberapa minggu mendatang.
Bidding real-time dan FLEDGE	Panduan cara FLEDGE terintegrasi dengan bidding real-time standar.	Dua hal utama yang mempersulit kemampuan teknologi iklan untuk melakukan bidding real-time adalah akses ke data tingkat peristiwa dan integrasi yang lebih mudah ke dalam ARA. Kami berencana mengirimkan info terbaru dan penjelasan tentang kedua hal tersebut di Kuartal 1.
Performa Lelang FLEDGE	Laporan dari penguji bahwa lelang FLEDGE memiliki latensi tinggi	Kami mengapresiasi laporan dari penguji yang membagikan hasil dan kasus penggunaannya. Kami juga memberikan beberapa saran mengenai cara meningkatkan performa FLEDGE. Secara paralel, kami telah menambahkan alat ke browser yang memungkinkan developer mendiagnosis dengan lebih baik faktor yang memperlambat lelang, dan secara sistematis mengatasi sumber utama latensi yang diamati. Peningkatan terbaru mencakup waktu tunggu untuk lelang lambat, teknik pemfilteran bidder cepat, cara untuk menggunakan kembali worklet FLEDGE agar tidak membayar biaya startup, dan pekerjaan berkelanjutan untuk memungkinkan permintaan iklan kontekstual berjalan secara paralel dengan waktu startup FLEDGE dan pengambilan jaringan. Kami berharap pengoptimalan latensi dapat terus berlanjut sebagai percakapan berkelanjutan antara developer Chrome dan penguji FLEDGE berdasarkan pengalaman nyata mereka menggunakan API.
Batas memori ukuran Grup Minat	Meminta penambahan batas ukuran satu grup minat dari 50 kB.	Kami secara aktif mempertimbangkan permintaan ini dan mencari masukan tentang nilai batas yang berfungsi.
Menggabungkan data yang ditayangkan FLEDGE dengan cookie pihak pertama	Apakah FLEDGE akan mendukung integrasi dengan data pihak pertama pengiklan?	FLEDGE dibuat untuk mendukung iklan menggunakan data pihak pertama yang sudah dimiliki pengiklan. Namun, FLEDGE tidak bermaksud mendukung pengiklan untuk mempelajari perilaku penjelajahan seseorang di situs mana pun selain situs milik pengiklan tersebut. Melampirkan perilaku penjelajahan di luar situs ke data pihak pertama bertentangan dengan tujuan Privacy Sandbox. Kami berencana membagikan panduan integrasi dengan detail selengkapnya tentang cara FLEDGE mendukung integrasi dengan data pihak pertama dalam beberapa minggu mendatang.
Nilai K-anonymity	Bagaimana nilai "K" menjadi "k-anon" akan ditentukan dan apakah nilai tersebut akan dipublikasikan?	Nilai "K" masih dalam tahap final dan kami akan membagikan lebih banyak informasi seiring dengan perkembangan rencana. Kami ingin mempelajari lebih lanjut bagaimana nilai k yang tidak diketahui dapat menghambat kesiapan FLEDGE dan mencakup pelatihan model ML. Kami juga mengharapkan masukan tambahan terkait topik ini.
Mendukung beberapa SSP	Bagaimana beberapa SSP akan didukung di FLEDGE?	FLEDGE mendukung lelang multi-penjual seperti disebutkan dalam proposal ini.
Visibilitas logika bidding	Masalah bahwa logika bidding DSP akan ditampilkan di JavaScript	Dengan logika bidding desain saat ini, JavaScript dapat diakses oleh orang lain, tetapi kami menerima masukan lainnya tentang mengapa hal ini dapat menjadi sumber kekhawatiran bagi DSP.
prebid.js	Bagaimana linimasa dalam mendukung prebid.js di FLEDGE?	Hanya Prebid.js versi 7.14 dan yang lebih baru yang mendukung modul FLEDGE. Setiap penayang yang tertarik dengan pengujian harus menambahkan modul FLEDGE dan mengupgrade instance Pra-bid mereka.
Fungsi yang ditetapkan pengguna di FLEDGE	Bagaimana fungsi buatan pengguna (UDF) akan didukung di FLEDGE? Ini adalah fungsi yang dapat diprogram oleh pengguna akhir untuk memperluas fungsi API.	Penjelasan tersedia di sini. Hal ini masih ditingkatkan, jadi kami menerima masukan tambahan tentang kasus penggunaan.
Melonggarkan batasan asal yang sama pada resource interest Group	Permintaan untuk melonggarkan batasan asal yang sama di resource grup Minat guna mengaktifkan kasus penggunaan teknologi iklan tertentu	Dalam penerapan FLEDGE saat ini, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl, dan trustedBiddingSignalsUrl harus memiliki asal yang sama dengan pemilik grup minat. Batasan dibuat untuk mencegah eksploitasi tertentu oleh penyerang, seperti yang dijelaskan di sini.
Kepemilikan grup minat	Permintaan untuk membatasi apakah teknologi iklan dapat menggunakan joinInterestGroup untuk Grup Minat yang sama di seluruh situs	Fokus kami adalah cara audiens digunakan, bukan cara audiens dibuat. Kami sedang membahas pendekatan potensial di sini dan menantikan masukan tambahan.
Akhir Masa Berlaku Kunci Server Nilai Kunci	Diskusi tentang menghapus kunci server setelah grup minat yang sesuai telah berakhir masa berlakunya	Kami sedang mempelajari cara untuk menangani akhir masa berlaku kunci dan mencari masukan di sini.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Traffic Uji Coba Origin	Traffic Uji Coba Origin Saat Ini tidak cukup untuk melakukan pengujian utilitas.	Uji Coba Origin saat ini ditujukan bagi pemain ekosistem untuk melakukan pengujian fungsional guna memastikan API berfungsi sebagaimana mestinya. Kami memahami bahwa sejumlah besar traffic akan diperlukan untuk melakukan pengujian utilitas setelah pengembangan berbagai Privacy Sandbox API lebih matang. Linimasa pengujian saat ini memperkirakan bahwa hal ini akan terjadi pada Ketersediaan Umum (yaitu saat teknologi untuk kasus penggunaan akan diluncurkan dan tersedia untuk 100% traffic Chrome) pada Kuartal 3 tahun 2023 (lihat linimasa terbaru kami di privacysandbox.com). Kami menerima masukan tambahan terkait pengujian kasus penggunaan yang memerlukan traffic tambahan.
Tumpang-tindih fungsi berbagai API pengukuran Privacy Sandbox	Kekhawatiran terkait adanya beberapa pendekatan pengukuran yang tumpang-tindih melalui Privacy Sandbox akan meningkatkan kompleksitas, misalnya, Attribution Reporting API dan Private Aggregation API.	Kami sedang mengerjakan dokumentasi yang lebih baik untuk mengklarifikasi berbagai kasus penggunaan API, dan menerima masukan tambahan tentang area mana yang kurang penjelasan. Misalnya, Attribution Reporting API secara khusus dimaksudkan untuk mendukung pengukuran konversi, sedangkan Private Aggregation API dan Shared Storage adalah API tujuan umum yang dimaksudkan untuk mendukung rentang kasus penggunaan pengukuran lintas situs yang lebih luas.
Coba lagi permintaan laporan yang gagal	Klarifikasi tentang berapa kali permintaan laporan dicoba jika gagal.	Kami telah memublikasikan panduan tentang hal ini. Singkatnya, laporan hanya dikirim saat browser berjalan/online. Setelah kegagalan pertama dikirim, laporan akan dicoba lagi setelah 5 menit. Setelah kegagalan kedua, laporan tersebut dicoba lagi setelah 15 menit. Setelah itu laporan tidak akan dikirim.
Penundaan Pelaporan	Berapa perkiraan penundaan pelaporan?	Kami ingin mendengar lebih banyak masukan dari ekosistem terkait keterlambatan pelaporan yang mereka alami selagi kami mengumpulkan data untuk menilai lebih lanjut penundaan ini secara paralel.
Halaman pra-rendering	Apakah atribusi ARA akan berfungsi pada halaman pra-rendering?	Pendaftaran atribusi ditangguhkan di halaman pra-rendering hingga aktivasi (klik atau tampilan aktual terjadi). Artinya, kami akan menunda ping permintaan `attributionsrc`.
Mengukur conversion lift	Cara mengukur conversion lift dengan pengujian A/B di domain yang sama	Situs dapat mengukur conversion lift dengan pengujian A/B di domain yang sama melalui pelaporan atribusi. Mereka dapat mengenkode parameter A/B sebagai kunci menggunakan API gabungan, lalu menerima laporan ringkasan untuk nilai konversi berdasarkan bucket kunci tersebut.
(Juga dilaporkan pada K3) Konversi lintas-domain	Cara melacak konversi yang merupakan lintas domain, seperti dengan 2 tujuan atau lebih	Pembaruan K4: Kami telah memublikasikan proposal untuk menghapus pembatasan tujuan halaman landing yang memungkinkan pelacakan percakapan lintas-domain. Proposal ini telah diterapkan.
(Juga dilaporkan di K3) Setelan habis masa berlaku di laporan konversi	Permintaan untuk mendukung filter / masa berlaku laporan habis selama kurang dari 24 jam	Pembaruan K4: Kami telah membagikan permintaan pull ini yang akan memisahkan periode masa berlaku dan pelaporan untuk mengurangi dampak dari penundaan pelaporan dan masa berlaku konversi. Fitur ini kini diluncurkan di M110.
Penipuan dan Penyalahgunaan	Permintaan dari pengiklan dan pemasar untuk dapat mengelompokkan dan menggabungkan data berdasarkan situs penayang tempat iklan mereka ditayangkan, yang juga akan memberikan lebih banyak insight tentang potensi praktik iklan penipuan	Masukan ini sedang dibahas secara aktif di sini dan kami mengharapkan masukan lainnya.
(Juga dilaporkan di K3) Penundaan pelaporan tingkat peristiwa	Penundaan 2–30 hari dalam pelaporan tingkat peristiwa mungkin terlalu lama untuk kasus penggunaan tertentu.	Pelaporan tingkat peristiwa memiliki periode pelaporan default 2, 7, dan 30 hari. Ini dapat diubah menggunakan parameter "expiry". Teknologi iklan dapat mengonfigurasi masa berlaku, dengan minimum 1 hari, untuk mendapatkan laporan potensial dalam waktu kurang dari 2 hari. Kami membatasi perincian masa berlaku hingga 1 hari sebagai mekanisme perlindungan privasi, karena pelaporan yang lebih mendetail dapat menyebabkan serangan waktu. Selain itu, kami mengizinkan penyetelan parameter "masa berakhir" independen untuk laporan tingkat peristiwa dan gabungan. Lihat di sini. Selain itu, Google Ads tidak akan mendapatkan periode pelaporan khusus yang tidak diperoleh teknologi iklan lain melalui Attribution Reporting API.
Persyaratan asal pelaporan yang sama	Permintaan untuk menghapus persyaratan untuk asal pendaftaran sumber agar sama dengan asal pendaftaran konversi	Kami mengusulkan menggunakan pengalihan HTTP untuk mendelegasikan pendaftaran guna mengatasi kasus penggunaan ini. Kami menerima masukan tambahan tentang panduan baru.
Tracking konversi	Perlu membedakan apakah konversi terjadi sebelum/setelah jam tertentu yang ditetapkan oleh pengiklan	Attribution Reporting API mendukung penetapan periode habis masa berlaku dan prioritas untuk atribusi sumber. Dengan menggunakan keduanya, secara teknis, konversi yang terjadi dalam periode X hari dapat diatribusikan secara terpisah dari konversi yang terjadi setelah X.
Simulasi kebisingan	Meminta untuk dapat menyimulasikan berbagai volume konversi per bucket, untuk memahami dampaknya terhadap pengiklan yang memiliki lebih sedikit konversi	Kami ingin menambahkan cara untuk menyimulasikan hal ini di versi Noise Lab mendatang. Kami siap menerima masukan tambahan.
Pelaporan di perangkat seluler	Apakah laporan akan tetap dikirim saat Chrome berjalan di latar belakang pada perangkat seluler?	Untuk saat ini, meskipun di perangkat seluler, laporan tidak akan dikirim jika Chrome berada di latar belakang. Hal ini mungkin akan berubah saat API terintegrasi dengan Privacy Sandbox Android. Lihat di sini. Perlu diperhatikan bahwa Privacy Sandbox Android bukan bagian dari Komitmen yang diterima oleh CMA.
Ketersediaan data	Kekhawatiran bahwa Google akan memiliki akses tambahan ke data melalui Privacy Sandbox API	Pertama, Google Ads tidak menerima akses preferensial ke data dari Attribution Reporting API atau Privacy Sandbox API lainnya. Masalah ini juga dibahas di bagian Masukan Umum pada "Interoperabilitas" yang mencakup detail selengkapnya tentang Komitmen Google. Kedua, berdasarkan perbedaan antara situs yang lebih besar dan lebih kecil, Google menyadari bahwa perlindungan privasi berbasis derau mungkin memiliki dampak yang lebih besar pada bagian data yang lebih kecil. Namun, ada beberapa kemungkinan mitigasi: misalnya, metode seperti melakukan agregasi dalam jangka waktu yang lebih lama akan menyelesaikan masalah ini. Dengan demikian, masih belum jelas apakah kesimpulan yang didasarkan pada potongan data yang sangat kecil (seperti satu atau dua pembelian) sama sekali bermanfaat bagi pengiklan. Selama uji coba origin, Google telah mendorong penguji untuk memanfaatkan kemampuan bereksperimen dengan berbagai parameter privasi dan derau sehingga mereka dapat memberikan masukan yang lebih spesifik mengenai masalah ini.

Batasi Pelacakan Terselubung

Pengurangan Agen Pengguna

Tema Masukan	Ringkasan	Respons Chrome
Tunda Pengurangan Agen Pengguna hingga ekosistem web lebih siap	Tidak ada cukup waktu untuk beradaptasi dengan perubahan Pengurangan Agen Pengguna yang akan datang.	Kami menangani masukan ini dalam laporan lengkap di bagian "Kekhawatiran Pemangku Kepentingan" di bagian berjudul "Interaksi Google dengan CMA".
Tunda Pengurangan Agen Pengguna hingga ekosistem web lebih siap	Permintaan untuk menunda peluncuran Pengurangan Agen Pengguna hingga Agen Pengguna Terstruktur (SUA) di-deploy	Tim Google Ads mengusulkan Penambahan Agen Pengguna Terstruktur (lihat spesifikasi) ke OpenRTB pada Oktober 2021 dan disertakan dalam update spesifikasi 2.6 yang dirilis pada April 2022. Kami memiliki beberapa bukti bahwa SUA telah di-deploy dan tersedia saat ini, seperti yang ditunjukkan oleh postingan blog Scientia Mobile yang menunjukkan cara menggunakan UA-CH dan WURFL API untuk membuat SUA.

###

Petunjuk Klien Agen Pengguna

Tema Masukan	Ringkasan	Respons Chrome
Uji UA-CH dengan teknik pelacakan anti-rahasia lainnya	Panduan cara menguji semua API Privacy Sandbox dan teknik pelacakan sidik jari diusulkan bersama dalam pendekatan holistik	Rencana pengujian kami dirancang untuk mencerminkan linimasa asinkron dalam pengembangan beberapa tindakan anti-sidik jari, dibandingkan dengan Proposal Sandbox lainnya. Kebijakan ini menangani kenyataan bahwa beberapa tindakan anti-sidik jari (yaitu Anggaran Privasi, Perlindungan IP, dan Mitigasi Pelacakan Kembali) akan sepenuhnya dikembangkan dan siap untuk diluncurkan ke Ketersediaan Umum hanya setelah cookie pihak ketiga tidak digunakan lagi. Meskipun langkah anti-sidik jari tersebut tidak akan disertakan dalam uji kuantitatif, tindakan tersebut akan menjalani penilaian kualitatif berdasarkan fakta yang tersedia pada saat Standstill.
(Juga dilaporkan di Kuartal 2) Performa	Kekhawatiran tentang latensi untuk mendapatkan petunjuk melalui CH Penting (pada pemuatan halaman pertama)	Lihat bagian UA-CH khusus di bawah
Masukan Tidak Memadai	Masukan dari ekosistem terkait perubahan UA-CH mungkin tidak cukup, sehingga menyebabkan kekhawatiran tentang kurangnya kesadaran dari ekosistem.	Kami telah membagikan rencana secara proaktif untuk memastikan peluncuran yang cermat yang meminimalkan gangguan. Rencana untuk User-Agent Reduction dan UA-CH API telah disampaikan kepada W3C Anti-Fraud Community Group pada 18 Maret 2022 serta ke Web Payments Working Group dan Web Payments Security interest Group pada 20 Januari 2022. Tidak ada kekhawatiran signifikan yang diangkat selama atau setelah presentasi. Google secara proaktif berinteraksi dengan lebih dari 100 operator situs untuk mendapatkan masukan. Selain itu, Google juga telah menggunakan saluran Blink-Dev untuk menyampaikan peluncuran pengurangan agen pengguna secara publik berdasarkan masukan dari pemangku kepentingan ekosistem.
Waktu	Kekhawatiran yang muncul terkait waktu peluncuran dan kesiapan industri	Lihat bagian UA-CH khusus di bawah
Status Platform Chrome	Meminta agar halaman chromestatus untuk UA-CH diperbarui	Entri chromestatus telah diperbarui pada 19 Desember menjadi "Sinyal campuran".

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
Memilih ikut atau Tidak ikut serta	Apakah Privasi Alamat IP Ikut Serta atau Tidak Ikut Serta?	Tujuan kami adalah memberikan Perlindungan IP kepada semua pengguna. Dengan mempertimbangkan sasaran tersebut, saat ini kami mengevaluasi opsi pilihan pengguna untuk Perlindungan IP.
Kasus penggunaan Alamat IP untuk data pihak pertama	Apakah mungkin menggunakan alamat IP untuk menggabungkan perjalanan pengguna di seluruh domain pihak pertama setelah Perlindungan IP?	Seperti yang telah dipublikasikan sebelumnya, Perlindungan KI pada awalnya akan berfokus pada pelacakan dalam konteks pihak ketiga, yang berarti domain pihak pertama tidak akan terpengaruh.
Kasus penggunaan Teknologi Iklan	Bagaimana perusahaan dapat menyiapkan tindakan antipenipuan dengan Perlindungan Kekayaan Intelektual?	Kami mengakui pentingnya alamat IP sebagai sinyal untuk upaya antipenipuan di web saat ini. Sebagai bagian dari Komitmen kami terhadap CMA (paragraf 20), kami telah menyatakan bahwa kami tidak akan menerapkan Perlindungan KI tanpa melakukan upaya yang wajar untuk mendukung kemampuan situs dalam melakukan upaya anti-spam dan anti-penipuan. Salah satu prioritas utama kami adalah memahami pengaruh Perlindungan KI terhadap kasus penggunaan dan kemampuan deteksi antipenipuan, sehingga kami dapat berinvestasi lebih lanjut dalam teknologi yang menjaga privasi yang membantu perusahaan menjaga keamanan web. Kami mendorong masukan dan input untuk proposal baru yang bertujuan mendukung kebutuhan perusahaan keamanan dan antipenipuan, meskipun sinyal berubah dari waktu ke waktu.
Penipuan dan Penyalahgunaan	Apakah perlindungan IP menyertakan Perlindungan Denial of Service (DoS)?	Kami berkomitmen untuk meningkatkan privasi sekaligus menjaga keamanan web, dan perlindungan dari serangan denial-of-service merupakan kasus penggunaan anti-penyalahgunaan yang penting. Kami berharap dapat meminimalkan dampak terhadap perlindungan DoS melalui desain Perlindungan IP itu sendiri dan melalui solusi anti-penyalahgunaan yang baru. Karena Perlindungan IP awalnya berfokus pada layanan sematan pihak ketiga, beberapa pemangku kepentingan telah menunjukkan bahwa perlindungan tersebut akan berdampak terbatas pada perlindungan DoS untuk situs pihak pertama. Namun, kami terus meminta masukan publik untuk menilai risiko terhadap kasus penggunaan DoS, terutama untuk layanan sematan pihak ketiga. Sejalan dengan itu, kami juga mempelajari masukan penyalahgunaan dan mekanisme pemblokiran klien yang memungkinkan situs atau layanan memblokir pengguna yang berisi spam, tanpa mengidentifikasi pengguna.
Penyaringan Konten	Pemfilteran konten dengan Perlindungan IP	Perusahaan yang berbeda memiliki kebutuhan yang berbeda dalam hal memfilter konten dan menyesuaikan pengalaman pengguna. Banyak kasus penggunaan tersebut saat ini tidak mengandalkan alamat IP dan, oleh karena itu, tidak akan terpengaruh oleh Perlindungan IP. Misalnya, penayang yang ingin menyesuaikan kontennya dan mendorong lebih banyak engagement mungkin menggunakan cookie pihak pertama atau cookie pihak ketiga yang dipartisi (CHIP) untuk memahami minat pengguna dan interaksi sebelumnya dengan penayang. Atau, partner teknologi iklan yang berfokus pada penayangan iklan yang tepat kepada pengguna yang tepat dapat menggabungkan FLEDGE dan Topics, misalnya, untuk memberikan hasil iklan yang serupa seperti yang mereka lakukan saat ini dengan cookie pihak ketiga atau teknologi pelacakan lintas situs lainnya. Kami juga sedang mempelajari pengembangan kemampuan baru yang menjaga privasi ke dalam Perlindungan Kekayaan Intelektual, seperti geolokasi sementara, untuk lebih mendukung pemfilteran konten jika mekanisme yang ada mungkin tidak mencukupi. Kami menerima masukan tambahan terkait kasus penggunaan pemfilteran konten yang mungkin terpengaruh oleh Perlindungan IP.
(Juga dilaporkan pada K3) Kasus penggunaan geolokasi	Perlindungan KI dapat mencegah kasus penggunaan geolokasi yang sah agar tidak berfungsi di masa mendatang, seperti personalisasi konten berdasarkan geolokasi.	Pembaruan Q4: Kami bekerja sama dengan pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami mencari masukan ekosistem tentang perincian Geolokasi IP di sini.

Anggaran Privasi

Tema Masukan	Ringkasan	Respons Chrome
Dokumentasi yang lebih jelas	Lebih banyak contoh sehingga pemangku kepentingan dapat mengantisipasi bagaimana segala sesuatunya dapat dibatasi setelah Anggaran Privasi diterapkan	Proposal Anggaran Privasi masih dibahas secara aktif dan belum diterapkan oleh browser apa pun. Tanggal paling awal ketersediaan yang diskalakan menunjukkan tanggal paling awal saat Anggaran Privasi dapat diterapkan. Hal ini tidak akan terjadi sebelum penghapusan cookie pihak ketiga pada tahun 2024. Saat ini, kami tidak memiliki dokumentasi tambahan untuk dibagikan. Kami akan membagikan detail tambahan terkait proposal tersebut saat sudah selesai difinalisasi. Sementara itu, kami mengharapkan para pemangku kepentingan memberikan masukan yang akan membantu pengembangan proposal.

Memperkuat batas privasi lintas situs

Set Pihak Pertama

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan di K3) Batas domain	Permintaan untuk menambah jumlah domain terkait	Update Q4: Kami telah merilis FPS untuk pengujian lokal, termasuk proses pengiriman set tiruan di GitHub dan tanda untuk menguji rSA dan rSAFor secara lokal. Kami juga telah menyelenggarakan dua rapat terbuka bagi developer di FPS untuk terus menjawab pertanyaan seputar kasus penggunaan untuk subset terkait. Kami mendorong developer untuk menguji fungsi FPS untuk memberikan masukan tentang bagaimana batas domain untuk subset terkait akan memengaruhi kegunaan FPS untuk kasus penggunaan mereka. Kami telah mengklarifikasi dalam panggilan WICG bahwa Chrome berkomitmen untuk memberikan solusi yang dapat digunakan, yang juga mempertimbangkan kepentingan privasi pengguna. Untuk itu, kami mengapresiasi masukan dari komunitas tentang kasus penggunaan tertentu yang mungkin terpengaruh oleh batas domain, sehingga tim dapat mempertimbangkan cara untuk mengatasi kasus penggunaan ini sambil terus melindungi privasi pengguna.
Meminta detail selengkapnya tentang langkah-langkah mitigasi penyalahgunaan	Apa yang terjadi jika sebuah domain ditambahkan ke kumpulan yang tidak mereka izinkan?	Kami telah memublikasikan panduan pengiriman untuk Set Pihak Pertama di sini pada 2 Desember 2022. Seperti yang dijelaskan dalam panduan pengiriman, setiap set pengelolaan perubahan akan mengikuti dan mematuhi proses validasi di GitHub, termasuk validasi kepemilikan, yang akan mengurangi risiko ini.
Mitigasi penyalahgunaan	Kekhawatiran bahwa formasi Set Pihak Pertama dapat dieksploitasi	Kami sedang mencari cara untuk memperluas pemeriksaan teknis untuk jenis subkumpulan dan secara aktif mencari masukan tambahan dari komunitas di sini.
Kasus penggunaan iklan	Pertanyaan tentang apakah Set Pihak Pertama harus digunakan untuk mendukung Penargetan iklan	Kami tidak mencoba mendukung kasus penggunaan penargetan Google Ads untuk Set Pihak Pertama, dan sebaiknya gunakan Ads API yang tersedia untuk kasus penggunaan tersebut.
(Juga dilaporkan dalam Kuartal 3)	Kekhawatiran bahwa FPS tidak konsisten dengan Komitmen CMA mengenai "Legislasi Perlindungan Data yang Berlaku", atas dasar bahwa GDPR tidak memberlakukan batasan jumlah situs dalam satu set sementara FPS mensyaratkan batas 3	Respons kami tidak berubah dari Q3: "Google terus berkomitmen pada CMA untuk merancang dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mengganggu persaingan dengan memprioritaskan bisnis Google sendiri, dan untuk mempertimbangkan dampak terhadap persaingan dalam periklanan digital, penayang, dan pengiklan serta dampak pada hasil privasi dan kepatuhan terhadap prinsip-prinsip perlindungan data sebagaimana ditetapkan dalam Legislasi Perlindungan Data yang Berlaku. Kekhawatiran yang diungkapkan tidak mengungkapkan ketidakcocokan apa pun dengan GDPR. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini."
Proposal alternatif	Set yang Divalidasi GDPR	Selain masukan yang diberikan oleh ekosistem terkait proposal untuk mengadopsi "Set yang Divalidasi GDPR", Chrome memiliki masalah terkait batasan berikut pada proposal alternatif ini: "Set yang Divalidasi GDPR" mengklaim "selaraskan dengan" GDPR (meskipun tidak benar-benar jelas apa yang dimaksud dengan hal tersebut). Sebaliknya, komitmen Google mengharuskan Google mempertimbangkan "dampak terhadap hasil privasi" secara lebih umum. Dalam keputusannya yang menyetujui komitmen tersebut, CMA menunjukkan bahwa hal ini berbeda dengan kewajiban Google untuk mempertimbangkan "kepatuhan terhadap prinsip perlindungan data sebagaimana ditetapkan dalam Legislasi Perlindungan Data yang Berlaku", yang, sebagaimana dijelaskan oleh CMA, mencerminkan fakta bahwa Google terikat oleh Legislasi Perlindungan Data yang Berlaku, baik seperti yang berlaku pada komitmen maupun secara lebih umum. Kami memiliki masalah privasi tentang proposal untuk mengizinkan domain muncul dalam beberapa rangkaian. Set Pihak Pertama dimaksudkan untuk mendukung kasus penggunaan tertentu yang saat ini bergantung pada cookie pihak ketiga tanpa mengaktifkan pelacakan lintas situs yang luas. Mengizinkan domain untuk bergabung dengan beberapa kumpulan akan menghapus perlindungan privasi utama yang disertakan dalam proposal Set Pihak Pertama, tanpa memperkenalkan batasan lain yang berarti. Set yang Divalidasi GDPR juga mengusulkan untuk "menentukan Set sebagai grup pengontrol dan pemroses data yang memiliki kebijakan penggunaan umum". Hal ini mirip dengan persyaratan dalam proposal Set Pihak Pertama asli kami bahwa semua pihak dalam set harus memiliki kebijakan privasi umum. Sejak saat itu, kami menghapus persyaratan tersebut berdasarkan masukan kuat dari ekosistem yang menimbulkan kekhawatiran tentang persyaratan berbasis kebijakan privasi. Misalnya, kami mendengar dari penayang situs bahwa mempertahankan kebijakan privasi umum tidak mungkin dilakukan karena variasi produk dan geografis, di antara tantangan lain yang diajukan oleh anggota komunitas W3C (1, 2, 3). Kami yakin bahwa tantangan yang sama akan berlaku untuk proposal ini. Sejak alternatif ini dimunculkan, Chrome telah memperbarui proposal Set Pihak Pertama dan memublikasikan panduan pengiriman untuk membuat kumpulan baru.

API Fenced Frames

Tema Masukan	Ringkasan	Respons Chrome
Pembatasan Frame dengan Fence selama OT	Apa saja batasan saat ini terkait Frame dengan Fence untuk periode Uji Coba Origin?	Kami sedang menyusun dokumentasi tentang pembatasan dan status penerapan serta berencana untuk membagikannya selama Kuartal 1 2023.
Beberapa iklan dalam satu Frame Berpagar	Meminta untuk menampilkan beberapa pengiklan dalam satu Frame Berpagar dalam satu lelang	Saat ini, permintaan ini belum dikembangkan secara aktif, tetapi kami menerima masukan tambahan jika pemain ekosistem menganggap fitur ini penting.
Paket Web	Apa saja rencana persyaratan dan dukungan untuk Paket Web dengan Frame dengan Fence?	Saat ini, kami tidak memiliki informasi tentang apakah fitur ini akan menjadi persyaratan di masa mendatang atau tidak. Setiap perubahan akan diumumkan di awal dan tidak akan diterapkan sebelum penghentian cookie pihak ketiga. Lihat penjelasan ini untuk mengetahui status saat ini.

API Penyimpanan Bersama

Tema Masukan	Ringkasan	Respons Chrome
Penyimpanan Bersama untuk Teknologi Iklan	Ketidakpastian seputar penggunaan penyimpanan bersama untuk kasus penggunaan Teknologi Iklan	Shared Storage dan Private Aggregation API dapat digunakan untuk berbagai jenis tujuan pengukuran yang memerlukan pengukuran penyimpanan lintas situs. Beberapa contoh tercantum di sini. Kami memperkirakan penyedia solusi DSP dan Pengukuran akan menjadi integrator utama untuk kasus penggunaan iklan.

CHIP

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan di K3) Persyaratan yang dipartisi	Menambahkan persyaratan perilaku eksplisit untuk atribut "Terpartisi" pada cookie pihak pertama.	Update Q4: Setelah diskusi pada panggilan GitHub dan PrivacyCG, perilaku yang telah kami selaraskan adalah bahwa Cookie yang dipartisi yang ditetapkan pada cookie pihak pertama akan menggunakan kunci partisi (A,A) dengan "A" adalah situs tingkat atas. Kami akan mendokumentasikan perilaku ini di penjelasan dan spesifikasi.
Pengelolaan Cookie	Apakah ada alat untuk mengelola/mengatur cookie pihak pertama atau pihak ketiga?	Chrome DevTools dan NetLog dapat digunakan untuk menguji situs yang mengaktifkan pemblokiran cookie pihak ketiga. Kedua alat tersebut melaporkan saat cookie diblokir karena konfigurasi pengguna. Kami menerima umpan balik tentang jenis situs web audit tambahan apa yang ingin dilihat.

FedCM

Tema Masukan	Ringkasan	Respons Chrome
IdP memerlukan pengetahuan tentang RP untuk mengizinkan sesi	Masalah saat pengguna mencoba login ke IdP Feide dari dua RP yang berbeda	Kita sedang membahas kemungkinan solusi untuk masalah ini di sini.
Interoperabilitas	Kekhawatiran mengenai dampak FedCM terhadap hubungan antara pengguna dan situs tempat mereka login menggunakan FedCM, dan "interoperabilitas" antar-situs	FedCM bertujuan untuk terus mendukung layanan identitas gabungan yang saat ini mengandalkan cookie pihak ketiga setelah cookie pihak ketiga dihapus dari Chrome. Kami harap FedCM hanya akan menjadi salah satu opsi yang tersedia untuk layanan semacam itu; penyedia identitas (IdP) dan pihak tepercaya (RP) bebas menggunakan teknologi lain yang mungkin lebih sesuai dengan kebutuhan mereka. Sepertinya masalah terkait hubungan RP pengguna dan "interoperabilitas" disebabkan oleh kesalahpahaman tentang proposal FedCM. FedCM menyerahkannya ke IdP untuk menentukan informasi yang akan dibagikan kepada RP, dan format apa, setelah pengguna memilih untuk login ke situs RP tersebut. FedCM tidak mewajibkan IdP untuk "membuat ID pseudonim unik untuk setiap [RP] yang digunakan pengguna untuk melakukan autentikasi". Sebaliknya, FedCM terbuka bagi setiap IdP untuk memilih apakah akan membagikan ID pengguna yang sebenarnya, versi ID per situs, atau versi lain dari informasi ini. (Spesifikasi FedCM mengidentifikasi korelasi lintas situs sebagai risiko privasi yang terkait dengan API dan membahas ID yang diarahkan (per situs) sebagai kemungkinan mitigasi. Namun, keputusan untuk menggunakan ID yang diarahkan ada di IdP, tidak diberlakukan oleh browser.) FedCM juga sudah memberikan pilihan kepada pengguna sehubungan dengan identitas. Contohnya, jika pengguna memiliki beberapa identitas dengan IdP yang sama (misalnya, profil kerja dan profil pribadi), FedCM memberikan cara bagi pengguna untuk memilih identitas mana yang ingin mereka gunakan untuk login ke situs RP. Selain itu, setiap RP memutuskan sendiri IdP mana yang akan didukung di situsnya. Salah satu aspek dari keputusan tersebut adalah mempertimbangkan mekanisme yang diandalkan IdP, baik FedCM maupun teknologi lain. Sekali lagi, browser tidak menentukan pilihan ini untuk RP atau IdP.

Memerangi spam dan penipuan

API Token Status Pribadi

Tema Masukan	Ringkasan	Respons Chrome
Menangani Bot	Apa yang terjadi jika penerbit menemukan bahwa Token Status Pribadi telah dikeluarkan untuk bot?	Agar token yang dikeluarkan ke bot tidak tersisa dalam ekosistem dalam waktu yang lama, penerbit harus merotasi kunci yang mereka gunakan untuk menandatangani token secara rutin sehingga token lama yang dikeluarkan berdasarkan logika penerbitan yang berpotensi rusak akan habis masa berlakunya dan situs akan menukarkan token yang lebih baru dengan logika penerbitan yang diperbarui.
Pengiriman formulir situs yang sama	Dapatkah Token Status Pribadi digunakan untuk pengiriman formulir situs yang sama yang melibatkan navigasi halaman penuh (yaitu Content-Type: application/x-www-form-url mirip) dan bukan permintaan dari fetch/XMLHttpRequest API?	Saat ini, ini tidak didukung di versi pertama Private State Tokens. Kami menerima masukan dari ekosistem jika ada permintaan yang tinggi untuk kasus penggunaan ini.
Verifikasi sisi server	Pertanyaan tentang apakah Token Status Pribadi dapat diverifikasi di sisi server	Token ditukarkan terhadap penerbit, lalu penerbit membuat data penukaran yang dapat berisi token itu sendiri atau beberapa nilai yang ditandatangani yang berasal dari token tersebut, server dapat menggunakan data penukaran tersebut untuk memverifikasi keaslian token, dan kami berharap ekosistem penerbit yang berbeda akan memiliki standar berbeda terkait cara menafsirkan data penukarannya.