Halaman ini diterjemahkan oleh Cloud Translation API.

Laporan Masukan - Kuartal 1 2022

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

Sebagai bagian dari komitmennya terhadap Otoritas Persaingan dan Pasar, Google telah setuju untuk memberikan laporan tiga bulanan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox (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 dan teknologi.

Masukan yang diterima baru-baru ini mungkin belum dipertimbangkan untuk respons Chrome.

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

Tema umum dari semua sumber masukan

Tema umum di saluran diskusi dan masukan kami adalah pertanyaan tentang waktu, tingkat traffic, dan ketersediaan pengujian. Secara khusus, penguji secara konsisten menginginkan konfirmasi tentang kapan API akan tersedia untuk pengujian dan apakah pengujian akan tersedia secara global.

Untuk menjawab masukan ini, Chrome telah berkomunikasi secara luas, dan Chrome akan memposting FAQ yang mengonfirmasi hal yang sama, bahwa pengujian akan tersedia secara global. Selain itu, Chrome akan terus memperbarui jadwal publik melalui konsultasi dengan CMA secara berkala.

Menampilkan konten dan iklan yang relevan

API / Teknologi	Tema Masukan (Diurutkan berdasarkan Prevalensi)	Ringkasan Pertanyaan dan Kekhawatiran	Respons Chrome
Topik	Kegunaan topik yang terperinci	Terdapat kekhawatiran bahwa taksonomi topik yang terperinci mungkin tidak cukup berguna untuk periklanan menurut minat.	Kegunaan API akan dieksplorasi melalui pengujian. Chrome mengharapkan taksonomi berkembang berdasarkan hasil pengujian.
Topik	Taksonomi	Pemangku kepentingan industri ingin memiliki suara dalam memengaruhi taksonomi.	Chrome tetap menerima masukan pada taksonomi. Chrome sangat tertarik dengan masukan tentang model tata kelola untuk memodifikasi taksonomi, dan diskusi tentang cara lembaga industri lain dapat memainkan peran yang lebih aktif dalam mengembangkan dan memelihara taksonomi dalam jangka panjang.
Topik	Kegunaan untuk berbagai jenis situs	Terdapat kekhawatiran tentang manfaat situs bergantung pada tingkat traffic atau seberapa khusus konten situs tersebut.	Kegunaan API akan dieksplorasi melalui pengujian. Chrome mengharapkan taksonomi dan parameter lainnya berkembang berdasarkan hasil pengujian. Evolusi taksonomi atau parameter mungkin tidak memerlukan perubahan inkompatibilitas mundur. Selain itu, Chrome mengharapkan masukan untuk terus memengaruhi evolusi Topics API setelah cookie pihak ketiga tidak digunakan lagi.
Topik	Metodologi klasifikasi situs	Meminta situs agar dapat menentukan atau memengaruhi klasifikasi Topik mereka.	Chrome sedang mempelajari permintaan ini, tetapi pernah mendengar kekhawatiran (dari komunitas browser web dan dari DSP) tentang potensi risiko situs dapat "mengakali sistem" untuk menargetkan pengguna dengan cara yang mengganggu privasi atau mengurangi relevansi iklan. Chrome meminta masukan dan mempertimbangkan potensi perubahan.
Topik	Sinyal berisik	Mengirimkan topik acak dengan frekuensi 5% dari waktu tersebut dapat menghasilkan terlalu banyak derau / sinyal palsu.	Derau adalah metode penting untuk melindungi privasi pengguna, dan tingkat derau versus kegunaan topik akan dieksplorasi melalui pengujian.
Topik	Pemberian izin pihak ketiga yang dikontrol situs	Meminta agar situs dapat memilih teknologi iklan yang dapat memanggil Topics API dari situs mereka.	Kemampuan yang diminta ini sudah didukung melalui kebijakan izin 'topik penjelajahan' seperti yang disebutkan dalam penjelasan.
Topik	Efek Topics API pada performa halaman	Kekhawatiran seputar penundaan waktu ke iklan pertama karena bergantung pada Topics API	Chrome membahas kemungkinan dukungan untuk Topics di Header Permintaan HTTP guna meningkatkan performa. Kami mengandalkan pengujian untuk melihat apakah perubahan tersebut diperlukan.
Topik	Privasi / Kebijakan	Pertanyaan seputar tujuan pemfilteran respons menurut penelepon jika beberapa pihak ketiga akan membagikan topik mereka kepada siapa pun yang menelepon	Berdasarkan masukan dari banyak orang dalam ekosistem, Chrome memilih desain ini untuk membatasi akses ke informasi bagi mereka yang tidak memiliki akses ke informasi tersebut. Tentu saja, penayang dan pihak ketiga yang menerima Topics dapat memutuskan sendiri informasi apa yang akan dibagikan dengan pihak di situs mereka. Jika mereka melakukan jenis berbagi ini, Chrome sangat mendorong mereka untuk bersikap transparan kepada pengguna terkait fitur berbagi tersebut, dan menawarkan kontrol kepada mereka.
Topik	Dokumentasi	Minat terhadap dokumentasi yang mencakup detail model pengklasifikasi dan taksonomi yang digunakan oleh Chrome seperti yang Anda lakukan untuk FLoC, seperti seberapa sering pengklasifikasi dan taksonomi akan berubah	Chrome sudah menyediakan taksonomi yang digunakan sebagai bagian dari Uji Coba Origin, dan model pengklasifikasi yang mengategorikan situs ke dalam Topics akan disediakan dalam code base Chrome sebagai bagian dari kode open source. Sebagai bagian dari Uji Coba Origin, Chrome berhak membuat perubahan pada saat masukan diterima dan pembelajaran dikumpulkan terkait seberapa baik performanya.
FLEDGE	Pembatasan frekuensi	Berkeinginan untuk dapat mengontrol frekuensi per pengguna dalam kampanye atau dalam grup iklan.	FLEDGE akan mendukung pembatasan frekuensi untuk lelang di perangkat. Ada masalah terbuka ketika hal ini dibahas agar FLEDGE juga mendukung kampanye kontekstual/branding. Penyimpanan bersama, API dalam pengembangan lainnya, dan pembatasan khusus situs juga dapat digunakan untuk kontrol pembatasan frekuensi tambahan.
FLEDGE	Dampak FLEDGE terhadap performa	Terdapat kekhawatiran tentang potensi dampak bidder yang sarat komputasi dalam lelang FLEDGE	Chrome sedang berdiskusi aktif dengan developer tentang potensi dampaknya terhadap performa situs. Chrome menyambut baik kesempatan untuk mempelajari lebih lanjut selama pengujian.
FLEDGE	Menguji FLEDGE dengan fitur lain	Waktu dan bagaimana pengujian dengan fitur lainnya (server k-anonymity, server nilai kunci, dll.) akan dilakukan.	Chrome sengaja meluncurkan fitur secara bertahap untuk uji coba origin awal kami guna mempermudah pengujian. Chrome menyadari bahwa memberikan kejelasan tentang linimasa untuk fitur lain merupakan hal yang penting dan akan mengklarifikasi jika memungkinkan.
FLEDGE	Koordinasi pengujian	Cara mengoordinasikan pengujian di beberapa teknologi iklan.	Chrome sedang menyelidiki pemberian dukungan tambahan untuk membantu mengoordinasikan eksperimen agar teknologi iklan yang berbeda melakukan eksperimen terhadap pengguna yang sama. Hal ini juga menjadi fokus utama dari penjangkauan kemitraan Chrome; badan perdagangan industri juga telah menyatakan minatnya untuk memainkan peran.
FLEDGE	Batas grup minat	Apakah akan ada batasan jumlah grup minat yang dapat ditambahkan pengguna atau yang dapat disertakan dalam lelang?	Chrome bersedia menyaring batas ini untuk alasan performa halaman web atau pengalaman pengguna selama periode pengujian berdasarkan masukan dan dampak latensi yang diukur. Terdapat diskusi berkelanjutan di antara penguji tentang cara tambahan agar pembeli dan penjual dapat menyesuaikan penggunaan resource.
FLEDGE	Kemampuan Lintas API	Bagaimana cara kerja pelaporan atribusi dengan FLEDGE?	Detail lengkapnya masih belum ditentukan, dan Chrome memperkirakan akan mendapatkan pembaruan tentang hal ini pada Kuartal 2. Chrome berharap dapat terus menyediakan pelaporan tingkat peristiwa untuk hasil lelang (kemenangan dan kekalahan) selama uji coba origin.

Mengukur iklan digital

API / Teknologi	Tema Masukan (Diurutkan berdasarkan Prevalensi)	Ringkasan Pertanyaan dan Kekhawatiran	Respons Chrome
Attribution Reporting (dan API lainnya)	Menguji traffic	Kekhawatiran apakah akan ada cukup traffic untuk pengujian	Chrome memulai uji coba origin pada traffic yang sangat rendah untuk memastikan bahwa tidak ada bug atau masalah serius pada kontrol pengguna. Penguji awal memainkan peran penting dalam memastikan bahwa API berfungsi sebagaimana mestinya dari sudut pandang teknis, sehingga membantu meningkatkan traffic yang lebih besar dengan lebih cepat. Setelah yakin bahwa API berfungsi seperti yang diharapkan, Chrome akan meningkatkan uji coba origin untuk mendukung pengujian utilitas.
Pelaporan Atribusi	Ergonomi untuk mendaftarkan acara	Pertanyaan tentang formulir pendaftaran yang didukung untuk acara.	Chrome telah memublikasikan respons di github untuk mengklarifikasi bentuk pendaftaran yang didukung saat ini. Chrome sedang mengumpulkan masukan dari ekosistem terkait desain saat ini untuk melihat apakah perubahan yang diusulkan cukup mengatasi masalah ini atau memerlukan update lebih lanjut.
Pelaporan Atribusi	Pembuatan derau	Menginginkan detail selengkapnya tentang cara derau dihasilkan untuk laporan gabungan.	Chrome telah memublikasikan respons di GitHub untuk memberikan detail selengkapnya tentang cara sistematis derau dihasilkan. Chrome berencana menyediakan library untuk menyimulasikan derau dan menguji dengan berbagai parameter selama OT. Chrome juga berencana memberikan dokumentasi dan panduan developer tambahan untuk mode pelaporan gabungan.
Pelaporan Atribusi	Data yang kurang akurat untuk situs kecil	Kekhawatiran bahwa situs atau kampanye yang lebih kecil akan menerima data yang kurang akurat.	Chrome menyadari bahwa perlindungan privasi berbasis derau memiliki dampak yang lebih besar pada bagian data yang lebih kecil. Namun, mungkin saja metode seperti agregasi data dalam jangka waktu yang lebih lama akan menyelesaikan masalah ini. Namun, tidak jelas apakah kesimpulan yang didasarkan pada potongan data yang sangat kecil (seperti satu atau dua pembelian) bermanfaat bagi pengiklan. Selama uji coba origin, Chrome mendorong penguji untuk memanfaatkan kemampuan bereksperimen dengan berbagai parameter privasi dan derau sehingga mereka dapat memberikan masukan yang lebih spesifik tentang masalah ini.
Pelaporan Atribusi	Dampak jeda konversi terhadap utilitas	Pastikan jeda konversi akan mengganggu penyiapan dan verifikasi kampanye atau pengoptimalan kampanye.	Chrome telah menerima beberapa masukan yang bertentangan tentang dampak jeda pelaporan konversi. Namun, mengingat Attribution Reporting API menerapkan penundaan acak dalam pelaporan untuk melindungi privasi pengguna, Chrome memperkirakan kasus penggunaan atau masalah tertentu akan menjadi lebih jelas selama periode pengujian, dan dapat ditangani dengan dukungan proses debug tambahan atau panduan developer.
Pelaporan Atribusi	Periode atribusi yang lebih panjang	Meminta perpanjangan periode atribusi 30 hari	Chrome telah memublikasikan respons yang meminta lebih banyak masukan tentang durasi periode atribusi, dengan mempertimbangkan minimalisasi data dan utilitas.
Pelaporan Atribusi	Tayangan iklan tidak terlihat	Pertanyaan tentang apakah tayangan tidak terlihat dihitung untuk laporan konversi lihat-tayang.	Chrome telah memublikasikan respons di GitHub untuk lebih memperjelas tayangan yang terlihat.

Membatasi pelacakan tersembunyi

API / Teknologi	Tema Masukan (Diurutkan berdasarkan Prevalensi)	Ringkasan Pertanyaan dan Kekhawatiran	Respons Chrome
Pengurangan Agen Pengguna	Performa	Ada masalah tentang latensi untuk mendapatkan petunjuk melalui CH Penting (pada pemuatan halaman pertama).	Chrome sedang menyelidiki cara untuk meningkatkan performa.
Pengurangan Agen Pengguna / Petunjuk Klien Agen Pengguna	Masalah Anti-Penipuan / Anti-Penyalahgunaan	Memiliki sebanyak mungkin informasi adalah hal penting saat melakukan proses debug untuk jenis serangan tertentu, termasuk Denial of Service. Kehilangan beberapa info dari string UA dapat menimbulkan tantangan.	Chrome sedang berdiskusi dan mengevaluasi cara untuk menjaga privasi sekaligus memberikan informasi memadai yang akan berguna untuk proses debug.
Pengurangan Agen Pengguna	Kebingungan seputar penyiapan OT	Peserta Uji Coba Multi-Origin merekomendasikan peningkatan kualitas dokumentasi dengan contoh cara mendaftar ke Uji Coba Origin.	Uji Coba Origin UA yang Dikurangi akan berakhir, tetapi Chrome bermaksud meningkatkan petunjuk untuk Uji Coba Penghentian Penggunaan (termasuk membuat contoh demo lebih terlihat).
Pengurangan Agen Pengguna	Kekhawatiran tentang nilai petunjuk spesifik	Pertanyaan tentang apakah Sec-CH-UA-Model sama dengan <deviceModel> di string Agen Pengguna.	Sec-CH-UA-Model sama dengan <deviceModel> di string Agen Pengguna. Chrome akan mencoba menjelaskannya dalam dokumentasi mendatang.
Pengurangan Agen Pengguna	Masalah terkait pendaftaran dalam Uji Coba Penghentian Layanan	Pertanyaan terkait cara mendaftarkan domain dalam jumlah besar ke dalam Uji Coba Penghentian Penggunaan	Chrome telah mempertimbangkan pendekatan terpusat saat merancang Uji Coba Penghentian Penggunaan, tetapi Chrome yakin bahwa Uji Coba Origin yang ada adalah opsi terbaik karena memberikan semua kontrol kepada developer (karena mereka dapat memilih untuk mengirim header atau tidak).
Petunjuk Klien Agen Pengguna	Kekhawatiran seputar sifat preskriptif UA-CH	Ada kekhawatiran bahwa UA-CH terlalu preskriptif jika dibandingkan dengan fleksibilitas yang ditawarkan header Agen Pengguna, seperti yang ditetapkan oleh rfc7231.	Chrome melihat sifat preskriptif header UA-CH sebagai peningkatan penting atas fleksibilitas string UA, baik dari sudut pandang interoperabilitas lintas browser dan perlindungan privasi pengguna (dengan mencegah penambahan arbitrer ID entropi tinggi). Namun, masalah ini tetap terbuka jika orang lain juga memiliki kekhawatiran yang sama dan ingin memberikan masukan.
Petunjuk Klien Agen Pengguna	Kekhawatiran bahwa API digunakan untuk memblokir browser tertentu	Perlu diketahui bahwa situs menggunakan API untuk mencari "Google Chrome" atau "Microsoft Edge" dan memblokir semua browser lainnya.	Konsep daftar merek dirancang untuk menangani kasus ini - browser dapat mengirim "Google Chrome" selain mereknya sendiri.
Petunjuk Klien Agen Pengguna	Meminta metode untuk menghitung semua petunjuk yang didukung	Tertarik memiliki cara terprogram untuk mengetahui semua petunjuk yang didukung untuk browser.	Chrome sedang mengevaluasi permintaan fitur.
Pengurangan Agen Pengguna / Petunjuk Klien Agen Pengguna	Masalah Anti-Penipuan / Anti-Penyalahgunaan	Petunjuk klien tidak tersedia saat pemuatan pertama untuk HTTP1	Salah satu Client Hints Reliability API (Accept_CH) hanya tersedia melalui HTTP2 dan HTTP3. Untuk server yang masih disalurkan melalui HTTP1, server tersebut harus hanya mengandalkan Critical-CH.
Pengurangan Agen Pengguna	Dampak pada Chrome untuk Android	Pertanyaan tentang bagaimana hal ini berdampak pada Chrome di Android secara khusus.	Pengurangan UA serta UA-CH akan diluncurkan di Chrome di Android, selain di Desktop. Untuk Chrome di Android, perubahan hanya akan berlangsung pada "Tahap 6", yang saat ini dijadwalkan untuk Chrome 110.
Penangkap Asap (WIPB)	Penggunaan dan metode yang tidak sesuai	Kejelasan mengenai metode yang tidak sesuai dan metode yang tidak sesuai.	Chrome akan memperbarui penjelasan dengan detail selengkapnya.
Gnatcatcher + Pengurangan Agen Pengguna	Mengurangi sinyal antipenipuan	Dampak antipenipuan secara bersamaan mengurangi akses IP dan UA.	Ketentuan kebijakan antipenipuan Kebutaan IP yang Disengaja (untuk mengizinkan penggunaan IP untuk kasus penggunaan antipenipuan) akan menyelesaikan masalah pertahanan seputar proxy IP.
Pelacakan Navigasi	Kekhawatiran tentang kerusakan di masa mendatang	Pengiklan khawatir dengan potensi kerusakan; penyedia identitas juga telah menunjukkan minat pada rencana Chrome.	Chrome tidak akan membuat perubahan yang dapat menyebabkan gangguan, dan masih mempelajari kasus penggunaannya.
Cookie SameSite	Interoperabilitas dengan browser lain	Pertanyaan seputar rencana Chrome untuk memperbaiki crbug.com/1221316, karena ini merupakan area tempat implementasi Chrome berbeda dari browser lain.	Chrome menemukan bug dalam metrik, dan mendapatkan metrik baru sebagai hasilnya. Chrome mengumpulkan data untuk lebih memahami dampak perbaikan bug.
Partisi Penyimpanan	Kekhawatiran terkait partisi saluran pesan	Pertanyaan seputar apakah saluran pesan atau tidak (yaitu, SharedWorker & BroadcastChannel) harus dipartisi.	Chrome mengevaluasi masukan, tetapi Chrome yakin bahwa partisi saluran pesan bersama dengan penyimpanan diperlukan untuk mencegah pelacakan tersembunyi.

Memperkuat batas privasi lintas situs

API / Teknologi	Tema Masukan (Diurutkan berdasarkan Prevalensi)	Ringkasan Pertanyaan dan Kekhawatiran	Respons Chrome
Set Pihak Pertama	Persyaratan kebijakan privasi umum	Anda tidak dapat menjaga kebijakan privasi yang sama di semua produk dan wilayah hukum yang perlu menjadi bagian dari kumpulan yang sama.	Chrome masih menentukan persyaratan kebijakan kami; dan akan memperhatikan masukan ini.
Set Pihak Pertama	Independent Enforcement Entity (IEE) kemungkinan akan menerima sejumlah besar tantangan validitas FPS	Ringkasan tantangan yang dapat diperkirakan untuk menentukan validitas FPS: kebijakan privasi atau teks tidak sesuai dengan seluruh anggota kumpulan, kejelasan tentang cara mendefinisikan keanggotaan kumpulan yang jelas oleh pengguna, tantangan waktu dan bandwidth, serta keahlian khusus seputar struktur perusahaan.	Chrome masih menentukan persyaratan kebijakan kami; dan akan memperhatikan masukan ini.
Set Pihak Pertama	Proses untuk mempertahankan daftar FPS browser	Kekhawatiran tentang hambatan memasuki situs web di negara selain barat, versi daftar FPS yang tidak konsisten di seluruh browser karena perbedaan dalam ritme pembaruan, dan kemampuan browser yang lebih kecil/baru untuk menggunakan daftar.	Chrome masih menentukan persyaratan kebijakan, proses persetujuan, dan hak penggunaan untuk daftar tersebut; dan akan mengingat masukan ini. Chrome juga akan melihat pembelajaran dari daftar statis lain yang digunakan di platform web, seperti Daftar Akhiran Publik
Set Pihak Pertama	Desain pernyataan dinamis per situs	Desain dinamis (bukan daftar statis) mungkin lebih rentan terhadap pernyataan palsu tentang kepemilikan umum, dan latensi/kegagalan pemuatan halaman.	Chrome saat ini menerapkan pendekatan daftar statis; dan akan mempertimbangkan masukan ini jika pendekatan pernyataan bertanda tangan dievaluasi ulang di masa mendatang.
Set Pihak Pertama	Potensi kasus penggunaan untuk Set Pihak Pertama (jika versi daftar FPS yang tepercaya dan setara dapat dibuat)	Dialog single sign-on dan data yang dapat disesuaikan, kemungkinan untuk pelaporan transparansi yang lebih baik kepada pengguna.	Chrome akan mempertimbangkan masukan ini saat mempertimbangkan langkah selanjutnya untuk Set Pihak Pertama
CHIP	Kompatibilitas browser	Minat dalam memahami cara browser lain menangani atribut cookie yang dipartisi	Chrome terus bekerja dalam grup standar publik seperti W3C untuk mengidentifikasi desain dan implementasi yang dapat berfungsi di seluruh browser.
CHIP	Persyaratan desain	Perhatikan bahwa mungkin tidak mungkin untuk menyertakan awalan nama __Host-	Chrome telah menghapus persyaratan penamaan untuk Uji Coba Origin; dan akan mempertimbangkan apakah akan membuatnya permanen pada akhir periode pengujian.
CHIP	Penggunaan CHIPS untuk kasus penggunaan iklan	Pertanyaan tentang apakah CHIPS dapat digunakan untuk kasus penggunaan iklan.	CHIPS memungkinkan pihak ketiga membuat cookie sisi klien yang dipartisi ke situs level teratas (atau Set Pihak Pertamanya). Jika kasus penggunaan memerlukan status yang dipartisi, dan bukan status lintas situs; maka CHIPS dapat digunakan untuk kasus penggunaan tersebut.
CHIP	Integrasi CHIPS dengan FPS	Kekhawatiran bahwa pengujian dengan CHIPS mungkin tidak dapat dilakukan bersama dengan proposal Privacy Sandbox lainnya, seperti Set Pihak Pertama	Chrome secara aktif mengeksplorasi cara memfasilitasi lingkungan pengujian yang memungkinkan pengujian tersebut terjadi. Chrome juga telah memublikasikan petunjuk pengujian lokal untuk FPS dan CHIPS; yang dapat digunakan untuk sementara.
FedCM	Eksprestivitas	Perlu diperhatikan bahwa karena browser merender bagian dari alur identitas gabungan, sulit untuk menangkap semua nuansa yang ingin ditampilkan IDP kepada pengguna mereka	Chrome menyadari konsekuensinya dan akan terus bekerja sama dengan ekosistem untuk mencakup sebanyak mungkin aspek yang dapat dilakukan dan membuatnya seekspresi mungkin. Beberapa ide yang dijelajahi Chrome mencakup penyesuaian branding (misalnya logo, warna) dan penyesuaian string (misalnya, "akses artikel ini", bukan "login dengan").
FedCM	Keterlibatan browser	Kekhawatiran bahwa browser lebih terlibat dalam alur penggabungan identitas daripada sebelumnya, sehingga lebih eksplisit mengetahui situs mana yang digunakan pengguna (juga dengan IDP yang mana).	Chrome mengetahui bahwa browser kini memainkan peran yang lebih aktif, tetapi tingkat keterlibatan ekstra ini diperlukan agar browser dapat membedakan dan mencegah pelacakan lintas situs sambil tetap mendukung penggabungan.
FedCM	Penerapan dan Interoperabilitas	Kekhawatiran bahwa browser lain tidak akan mengadopsi atau menerapkan FedCM.	Chrome juga bekerja sama dengan vendor browser lainnya untuk menemukan solusi umum federasi di FedID Community Group.
FedCM	Berbagai tantangan API	Kekhawatiran bahwa FedCM masih dalam tahap awal / belum matang dan akan memerlukan waktu lama untuk menawarkan semua fitur yang dibutuhkan ekosistemnya.	Chrome akan mempelajari hal ini lebih lanjut sebagai bagian dari pengujian ekosistem.
FedCM	Kebijakan Perusahaan & Kontrol Pengguna	Perhatikan apakah akan ada kontrol (mis. kebijakan perusahaan dan/atau setelan pengguna) yang memungkinkan perusahaan mempertahankan deployment identitas gabungan mereka tanpa perubahan apa pun. Ada banyak deployment lokal identitas gabungan yang sangat sulit di-deploy ulang / diubah, sehingga ada banyak resistensi terhadap API browser baru yang memerlukan IDP untuk di-deploy ulang.	Chrome sedang mempelajari kontrol untuk admin perusahaan dan pengguna yang diyakini dapat mengatasi masalah ini. Chrome menerima masukan dari perusahaan tentang kasus penggunaan tertentu yang ingin mereka pertanggungjawabkan.

Memerangi spam dan penipuan

API / Teknologi	Tema Masukan (Diurutkan berdasarkan Prevalensi per API)	Ringkasan Pertanyaan dan Kekhawatiran	Respons Chrome
API Token Kepercayaan	Batas penukaran	Masalah sekitar 2 per halaman terlalu ketat, terutama untuk skenario ketika satu halaman mungkin disematkan di halaman yang sama beberapa kali atau memiliki domain penerbit kedua dalam organisasi mereka. Seseorang kemungkinan akan mencapai batas tanpa mempertimbangkan peserta pasar lainnya.	Chrome bersedia sedikit memperluas batas penukaran per halaman jika akan meningkatkan adopsi, tetapi harus menjaganya tetap relatif rendah agar dapat memasukkan entropi yang berlebihan. Selain itu, menyimpan data penukaran dalam cache dapat mengurangi kebutuhan satu penerbit untuk menukarkan beberapa token untuk satu pengguna dalam waktu singkat.
API Token Kepercayaan	Latensi	Biasanya harus merespons permintaan bid dalam waktu 10 md atau kurang, sehingga penukaran token pada pemuatan halaman pertama membuat hampir tidak mungkin disertakan dalam pengambilan keputusan Traffic Tidak Valid pra-bid	Chrome mencoba memahami pengaruh latensi terhadap kasus penggunaan pra-bid melalui pengujian.
API Token Kepercayaan	Adopsi OpenRTB	Untuk kasus penggunaan pra-bid, penting untuk meneruskan informasi token yang ditukarkan ke SSP dan DSP untuk digunakan dalam pengambilan keputusan iklan	Chrome bersedia berkolaborasi dengan IAB untuk membantu memastikan sinyal antipenipuan/anti-penyalahgunaan yang berguna dapat disebarkan melalui openRTB, meskipun sinyal tersebut memiliki standar untuk menambahkan kolom default baru.
API Token Kepercayaan	Privasi	Pertanyaan tentang kelayakan jangka panjang dari segala bentuk propagasi data lintas situs, meskipun dengan jumlah entropi yang rendah (~2,5 bit)	Dengan adanya perlindungan pengguna yang kuat untuk menghindari identifikasi pengguna unik, Chrome yakin ada alasan yang bagus untuk penerimaan ekosistem. Chrome bekerja sama dengan para pemangku kepentingan utama untuk memastikan kelayakan jangka panjang.
Sinyal Pengesahan Platform	Mengukur Minat pada ide/proposal baru	Dukungan yang kuat untuk berbagai sinyal yang layak (dan tidak layak), seperti menyampaikan sinyal integritas perangkat yang dapat disediakan oleh platform	Chrome berencana untuk membawa ide ini ke grup komunitas antipenipuan W3C sebagai ide baru untuk masukan.
Server Tepercaya untuk Antipenipuan	Mengukur Minat pada ide/proposal baru	Konsep menarik, tetapi kemungkinan memerlukan penyelidikan lebih lanjut dalam kasus penggunaan yang berlaku	Bergantung pada tingkat minat, Chrome dapat melakukan pemunculan ide lebih lanjut tentang konsep ini, dan menjadikannya penjelasan untuk masukan ekosistem di masa mendatang.