Laporan Masukan - Kuartal 4 2023

Laporan kuartalan untuk Kuartal 4 2023 yang merangkum masukan ekosistem yang diterima tentang proposal Privacy Sandbox dan respons Chrome.

Sebagai bagian dari komitmennya terhadap CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan 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 mengagregasi jumlah masukan yang telah diterima tim Chrome seputar tema tertentu dan mengaturnya 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 tentang pertemuan pemangku kepentingan 1:1, email yang diterima oleh masing-masing engineer, milis API, dan formulir masukan publik dipertimbangkan. Google kemudian berkoordinasi antartim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif dari tema yang muncul dalam kaitannya 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 khusus untuk tujuan latihan pelaporan publik ini. Dengan mencerminkan fokus pengembangan dan pengujian saat ini, kami menerima pertanyaan dan masukan khususnya sehubungan dengan Topics, Protected Audience, dan Attribution Reporting API.

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

Glosarium akronim

Chip

Cookie yang Memiliki Status Terpartisi Independen

DSP

Platform Sisi Permintaan

FedCM

Pengelolaan Kredensial Federasi

FPS

Set Pihak Pertama

IAB

Interactive Advertising Bureau

IDP

Penyedia Identitas

IETF

Satu Tugas Internet Engineering

IP

Alamat Protokol Internet

openRTB

Bidding real-time

lewat batas waktu

Uji Coba Origin

PatCG

Grup Komunitas Teknologi Periklanan Pribadi

RP

Pesta Santai

SSP

Platform Sisi Suplai

TEE

Trusted Execution Environment

UA

String Agen Pengguna

UA-CH

Petunjuk Klien Agen Pengguna

W3C

Konsorsium World Wide Web

WIPB

Kebutaan IP yang Disengaja

Masukan umum, tidak ada API atau Teknologi tertentu

Tema Masukan	Ringkasan	Respons Chrome
Linimasa 3PCD	Bagikan informasi selengkapnya tentang rentang waktu 3PCD.	Untuk memfasilitasi pengujian, Chrome membatasi 3PC secara default bagi 1% pengguna, mulai 4 Januari 2024. Tunduk kepada masalah CMA yang tersisa, Chrome berencana untuk secara bertahap menghentikan dukungan untuk 3PC mulai Q3 2024 dan berlanjut hingga akhir tahun 2024.
Linimasa 3PCD	Dampak pengaturan waktu 3PCD pada Kuartal 4 2024 karena bertepatan dengan musim liburan dan dapat berdampak negatif bagi penayang.	Tidak ada waktu yang tepat untuk menghentikan penggunaan 3PC. Kami sudah memahami selama lebih dari setahun bahwa tujuan kami adalah menghentikan penggunaan 3PC pada paruh kedua tahun 2024. Komitmen kami kepada CMA, yang mencakup kemungkinan waktunya untuk Periode diam tidak berubah. Meskipun kami memahami kekhawatiran atas waktu Kuartal 4, perubahan jadwal membuat persiapan industri menjadi lebih sedikit, bukan lebih banyak.
Pengujian Chrome (mode a/b)	Apakah penyiapan pengujian untuk Mode A dan Mode B per instance atau per profil Chrome?	Kami telah memublikasikan klarifikasi dalam dokumentasi di sini bahwa browser Chrome dalam konteks ini merujuk pada klien Chrome: penginstalan Chrome di perangkat. Setiap direktori data pengguna individu merupakan klien yang berbeda.
Uji Coba Penghentian Penggunaan	Bagikan informasi selengkapnya tentang Uji Coba 3PCD.	Kami telah membagikan informasi selengkapnya tentang uji coba 3PCD di sini.
Uji Coba Penghentian Penggunaan	Tidak ada cukup waktu untuk menyediakan token Uji Coba Penghentian Penggunaan di semua situs sebelum Januari 2024.	Kami memahami bahwa ada jangka waktu yang singkat antara saat pendaftaran uji coba penghentian penggunaan dibuka dan saat periode pengujian yang difasilitasi Chrome mulai memblokir 1% cookie. Untuk mengatasi keterbatasan waktu ini, Chrome memberikan masa tenggang untuk origin yang berpartisipasi saat mereka berusaha men-deploy token uji coba penghentian penggunaan. Selama masa tenggang, yang akan berlangsung hingga 1 April 2024, origin yang terdaftar untuk uji coba penghentian penggunaan akan memiliki akses ke 3PC di Chrome meskipun mereka belum men-deploy tokennya. Tujuan masa tenggang ini adalah untuk mencegah masalah kompatibilitas web selama fase transisi. Origin yang berpartisipasi harus men-deploy token uji coba penghentian penggunaan sebelum akhir masa tenggang agar dapat terus memiliki akses ke 3PC setelah masa tenggang berakhir.
Pengujian Chrome (mode a/b)	Mode B terlalu kecil untuk mengukur penurunan performa dengan benar secara tepat.	Terdapat keseimbangan cermat yang harus dicapai antara persentase traffic dan risiko dampak terhadap pengguna dan fungsi di seluruh web.
Kontrol Pengujian	Hanya penayang terbesar dengan resource pengembangan signifikan yang dapat memahami performa selama pengujian dan meneruskannya ke CMA.	Kami sudah melihat penyedia layanan penayang berbagi insight secara publik dengan ekosistem yang lebih luas dan berharap hal ini terus berlanjut seiring peningkatan pengujian Privacy Sandbox. Kami juga memperkirakan perusahaan teknologi iklan yang menggunakan Privacy Sandbox API akan terus mengembangkan fitur yang diminta pelanggan mereka, seperti pelaporan berdasarkan label.
Data pihak ketiga	Kekhawatiran untuk perusahaan data pihak ketiga.	Ada berbagai jenis perusahaan data pihak ketiga. Beberapa mungkin melipatgandakan, beralih ke metode pelacakan lintas situs yang lebih buram. Perusahaan lain mungkin memanfaatkan teknologi yang meningkatkan privasi dan mengembangkan proposisi nilai baru dengan pelanggan mereka. Kami berharap lebih banyak orang yang memilih untuk melakukan yang terakhir dan melakukan perjalanan ke arah yang semakin menuntut pengguna dan badan. Perubahan akan melahirkan peluang untuk evolusi dan inovasi.
Google Ad Manager	Perlunya panduan Google Ad Manager selengkapnya tentang cara penayang dapat menguji Privacy Sandbox. Pelaporan tidak memadai bagi penayang untuk memahami dampaknya.	Respons yang diberikan Google Ad Manager: Google Ad Manager telah menjelaskan cara Google Ad Manager akan melakukan pengujian menggunakan label pengujian yang difasilitasi Chrome di pusat bantuan. Saat ini, Ad Manager menyediakan pelaporan terkait Topik dan Audiens yang Dilindungi kepada penayang. Mulai laporan Masukan ini, Ad Manager dapat melaporkan tayangan iklan yang ditayangkan melalui Protected Audience API dan dapat menunjukkan apakah data dari Topics API ada pada tayangan iklan tertentu atau tidak. Penayang yang tertarik dengan pelaporan yang lebih canggih seperti menyegmentasikan pelaporan berdasarkan label yang difasilitasi Chrome dapat melakukannya dengan membaca label langsung dari Chrome (menggunakan dokumentasi Chrome), dan meneruskannya sebagai nilai kunci dalam permintaan iklan ke Ad Manager, dan pelaporan nilai kunci untuk melaporkan label.
Insentif pengujian	Pengiklan khawatir akan adanya waktu yang cukup untuk menguji Privacy Sandbox, dan potensi perubahan penting pada API yang mungkin akan terjadi.	Kami mengerti bahwa beberapa orang menginginkan lebih banyak waktu, tetapi kami telah berulang kali mendengar dari industri berita bahwa mengalihkan rentang waktu kemungkinan besar akan mengakibatkan kesiapan ekosistem yang lebih sedikit, bukan lebih. Meskipun rentang waktu penghentian 3PCD tunduk pada penanganan masalah persaingan yang masih ada dari CMA, kami mendorong semua orang untuk bersiap menyambut 3PCD pada tahun 2024. Seperti teknologi lainnya, Privacy Sandbox API akan terus berkembang. Evolusi tersebut berasal dari kemajuan teknologi dan input ekosistem. Kami akan terus bertanggung jawab saat kami membuat perubahan dan menganggap perubahan teknologi tidak seharusnya menghambat penggunaan.
CTV	Tidak ada jalur untuk mendukung video linear atau CTV.	Kami berharap dapat mengeksplorasi kasus penggunaan CTV lebih lanjut, tetapi menurut kami API untuk perangkat CTV tidak akan menghalangi 3PCD di Chrome.
Server Iklan Pengiklan	Google tampaknya mengalihkan penargetan iklan ke DV360. Dukungan apa yang akan diberikan untuk server iklan pengiklan?	Respons yang diberikan oleh Chrome: PA API dirancang untuk server iklan pengiklan untuk menayangkan dan mengukur iklan yang ditampilkan kepada pengguna melalui penggunaan pelaporan iFrame / Frame dengan Fence dan Beacon. Selain itu, mereka akan bekerja sama dengan pihak upstream dan downstream untuk berintegrasi ke dalam alur penayangan, seperti yang mereka lakukan saat ini.
Pengelola Data Google Ads	"Pengelola Data Google Ads" yang baru-baru ini diumumkan dibuat berdasarkan Customer Match dan Konversi yang Disempurnakan, yang memungkinkan pengiklan membagikan data pelanggan pihak pertama mereka kepada Google untuk mempertahankan semua fungsi pemasaran yang dijalankan oleh 3PC. Bagaimana fitur baru ini selaras dengan komitmen Google terhadap CMA?	Respons yang diberikan Google Ads: Data Manager Google Ads hanya memfasilitasi upload data pihak pertama dari sistem penyimpanan data pengiklan (sistem cloud) untuk digunakan oleh pengiklan untuk Customer Match (CM) dan Konversi yang Disempurnakan (EC), sehingga mempermudah bisnis kecil hingga menengah dengan sumber daya teknis yang lebih sedikit. Pengelola Data Google Ads tidak mengaktifkan kemampuan baru apa pun untuk CM atau EC dalam hal alamat atau keterukuran iklan di Google O&O ATAU penayang pihak ketiga. Platform iklan Google memiliki akses yang sama ke kemampuan yang tersedia dalam teknologi Privacy Sandbox seperti perusahaan Teknologi Iklan lainnya.
Setelan Chrome	Halaman setelan internal Chrome akan memberikan informasi selengkapnya tentang ukuran cookie.	Fungsi yang diminta sudah tersedia di Chrome Developer Tools. Kami juga menerima masukan tambahan tentang alasan fitur ini harus diprioritaskan di halaman setelan.
Heuristik	Heuristik apa yang di-deploy Chrome untuk mempertahankan pengalaman pengguna yang penting selama 3PCD?	Lihat jawaban kami terhadap pertanyaan ini di GitHub.
Versi browser	Membedakan browser Chrome stabil dan yang tidak stabil?	Pencocokan kasar versi utama Chrome dengan siklus rilis Stabil akan berfungsi.
Kepatuhan	Dapatkah Chrome memberikan laporan terkait SOX?	Chrome tidak akan memberikan laporan terkait SOX. API Privacy Sandbox adalah salah satu dari banyak API web yang disediakan Chrome untuk situs yang dikunjungi pengguna. Seperti semua API web, pemanggil API tidak menyepakati perjanjian dengan Chrome untuk menggunakan Privacy Sandbox API; akses hanya bergantung pada apakah pemanggil API memenuhi persyaratan teknis dan pengguna telah mengaktifkan setelan yang sesuai. Jika demikian, pemanggil API saja akan menentukan cara menggunakan API, termasuk data yang akan disimpan, bid mana yang diajukan, pelaporan apa yang diminta, dll.
Kepatuhan	Memperluas FAQ Kepatuhan Privacy Sandbox untuk menjawab lebih banyak pertanyaan.	Kami menghargai masukan Anda dan berencana untuk mengembangkan FAQ lebih lanjut.
Pertanyaan terkait Chrome	Apakah penghentian penggunaan 3PC di Chrome memengaruhi ketersediaan 3PC di Android WebView (browser tersemat)?	Saat ini, kami tidak menyertakan WebView pada tahap peluncuran dan pengujian 3PCD atau Privacy Sandbox API ini, selain mengaktifkan Pengukuran Atribusi Lintas Aplikasi dan Web.
Pertanyaan terkait API	Bagaimana cara melacak klik dan tayangan produk bersponsor?	Kasus penggunaan ini dicakup oleh Attribution Reporting API.
Linimasa	Mengapa jadwal untuk 3PCD berubah?	Kami telah membahas alasannya di sini.
SSO ekstensi Chrome	Mengizinkan kasus penggunaan single sign-on antara situs dan ekstensi Chrome setelah 3PCD.	Kami mendiskusikan masalah ini dan menerima masukan untuk kasus penggunaan tambahan.
Penggunaan API	Dapatkah Google mengonfirmasi daftar partner yang digunakan untuk menguji API?	Detail penguji yang telah mengidentifikasi diri secara publik tersedia di GitHub untuk API berikut: - Topics API - Protected Audience API - Attribution Reporting API - Penyimpanan Bersama - CHIP
Inisiatif Utiq	Bagaimana pandangan Chrome terhadap inisiatif Utiq?	Kami sedang membahasnya di sini.
Pertanyaan terkait Chrome	Bagaimana cara mendeteksi pengguna yang melakukan penjelajahan tanpa perangkat 3PC?	Tidak ada setelan eksplisit untuk mendeteksi pemblokiran 3PC. Untuk pendekatan "deteksi fitur" umum, sebaiknya buat permintaan iframe / lintas situs dan mencoba menetapkan cookie serupa ke kasus penggunaan yang diperlukan akan menjadi solusi terdekat.
Pertanyaan terkait Chrome	Apakah menjelajah dalam mode samaran sama dengan menjalankan uji tanda (luncurkan Chrome menggunakan tanda command line --test-third-party-cookie-phaseout)?	Mode samaran berbeda dari flag. Tanda ini tidak hanya memblokir 3PC, tetapi juga memungkinkan partisi penyimpanan pihak ketiga dan FedCM.
Pertanyaan terkait Chrome	Detail selengkapnya tentang perkiraan dampak 3PCD untuk setiap wilayah/negara jika 1% terjadi.	Klien disertakan dalam 1% secara acak, secara global, meskipun mungkin ada variasi regional. Misalnya, mungkin ada perbedaan dalam distribusi perangkat dan versi Chrome.
Teknologi yang Meningkatkan Privasi Alternatif	Teknologi Peningkat Privasi Alternatif harus diizinkan untuk melakukan pelacakan lintas-domain yang menjaga privasi untuk mencegah monopoli data di Chrome & Android.	Developer memiliki peluang besar untuk membuat penawaran teknologi yang meningkatkan privasi selain elemen penyusun yang kami tawarkan serta elemen penyusun non-Privacy Sandbox.
Studi CookieGraph	Bagaimana perspektif Chrome terhadap metode CookieGraph seperti yang dijelaskan di makalah ini dalam framework Privacy Sandbox?	Kami sedang meninjau makalah ini dan menerima masukan tambahan.

Pendaftaran & Pengesahan

Tema Masukan	Ringkasan	Respons Chrome
Pendaftaran dibatasi	Google telah memperkenalkan persyaratan penggunaan khusus untuk Privacy Sandbox API. Persyaratan ini efektif mencegah perusahaan yang berspesialisasi dalam membantu penayang mengenali pengunjung yang memberikan izin untuk menguji dan/atau mengintegrasikan fitur Privacy Sandbox dalam solusi identitas mereka. Persyaratan dan ketentuan secara tidak adil membatasi kemampuan mereka untuk beroperasi di dalam Privacy Sandbox.	Proses pendaftaran dan pengesahan tidak melibatkan persetujuan pada persyaratan penggunaan API. Pendaftaran dan pengesahan merupakan mekanisme yang dimaksudkan untuk meningkatkan transparansi terkait developer mana yang memanggil Privacy Sandbox API dan cara mereka menggunakan data yang diakses. Secara khusus, pengesahan tersebut merupakan pernyataan publik bahwa developer yang mengesahkan tidak menggunakan API untuk mengidentifikasi pengguna di berbagai situs atau aplikasi dan tidak mengakali perlindungan privasi API. Pengesahan ini tidak memerlukan pembuatan representasi tentang penggunaan data atau teknologi lain oleh developer.
Pendaftaran Privacy Sandbox	Bagaimana cara memperbarui kontak / alamat email untuk pengesahan?	Informasi pendaftaran dapat diperbarui menggunakan formulir pendaftaran. Detail lebih lanjut tersedia di sini.
Pendaftaran Privacy Sandbox	Bisakah Anda mengklarifikasi skenario pemotongan akses jika pengesahan tidak tersedia?	Privacy Sandbox akan memberikan waktu 3 minggu kepada kontak teknis untuk membuat kembali file pengesahan untuk situs yang terdaftar sebelum menolak akses perusahaan yang terdaftar ke (API pengukuran dan relevansi).
Pendaftaran Privacy Sandbox	Bagaimana cara menguji API di lingkungan lokal menggunakan endpoint non-produksi?	Kami telah menjawab pertanyaan ini di sini.

Tampilkan Konten & Iklan yang Relevan

Topik

Tema Masukan	Ringkasan	Respons Chrome
Kegunaan untuk berbagai jenis pemangku kepentingan	Penayang khawatir tentang dampak topik terhadap penjualan berbasis data. Situs yang lebih besar akan diberi Topik 'berita' umum, tidak ada data yang menautkannya ke penerbit tertentu. Sebagai imbalannya, penerbit spesialis akan memberikan data mereka untuk informasi terbatas.	Kami mengakui bahwa situs dengan domain minat yang lebih umum cenderung berkontribusi pada topik yang kurang terperinci daripada situs dengan domain minat yang lebih khusus. Namun, tidak semua situs khusus menyumbangkan topik yang berharga secara komersial. Selain itu, dinamika ini mencerminkan status quo, yaitu beberapa situs memberikan nilai lebih daripada situs lainnya dalam sistem relevansi iklan berbasis 3PC. Topics (dan Privacy Sandbox secara keseluruhan) memberi penayang kontrol yang lebih besar atas penggunaan informasi mereka oleh perusahaan teknologi iklan yang berpartner dengan mereka. Selain itu, informasi yang tersedia melalui Topics jauh lebih umum daripada sinyal yang ada.
Server Iklan Penayang	Server iklan penayang yang menggunakan server iklan khusus mungkin tidak dapat langsung mengamati Topics API.	Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Pengesahan	Memperluas persyaratan pengesahan untuk mengatasi konsekuensi yang tidak diinginkan yang diketahui dari transfer informasi lintas konteks.	Saat ini, pengesahan tidak dimaksudkan untuk mencakup kategori risiko yang luas, melainkan untuk mengatasi penyalahgunaan API.
Volume traffic Topik	Volume tayangan yang diterima saat ini tidak cukup untuk pengujian.	Chrome mengetahui masukan mengenai volume Topik yang tersedia di ekosistem terprogram. Kami sedang menyelidiki kemungkinan alasannya - baik di dalam browser maupun di antara penguji yang relevan. Jika dianggap perlu, Chrome akan menilai potensi perubahan desain API yang tersedia untuk meningkatkan tingkat cakupan dan memungkinkan pengujian pada skala yang memadai, sekaligus menjaga privasi pengguna.
Penggunaan API	Apakah ada pembatasan kapasitas Topics API?	Ada beberapa batasan kapasitas Topics untuk mencegah penyalahgunaan dan melindungi pengalaman pengguna di web. Anda dapat melihat detail selengkapnya di sini.
Taksonomi V2	Pedoman dari IAB untuk detail topik yang harus disertakan dalam protokol RTB terbuka?	Ya, pedoman dari IAB tentang cara menyertakan Topics dalam protokol Open RTB dapat ditemukan di sini.
Dampak pada sinyal pihak pertama	Taksonomi Topik Terperinci v2 yang digabungkan dengan proses untuk menampilkan nilai tertinggi dari segmentasi terperinci ini (topik teratas) akan mendistorsi pasar untuk data dalam iklan.	Respons kami tetap tidak berubah dari Q3: "Meskipun taksonomi Topics yang lebih terperinci dapat secara tidak langsung mengurangi daya tarik solusi lain, seperti solusi yang didasarkan pada data pihak pertama penayang atau solusi yang mengandalkan penawaran langsung, karena kami mengembangkan Topics API, sasaran utama kami adalah memastikan bahwa solusi ini mendukung kasus penggunaan iklan menurut minat setelah 3PCD seefektif mungkin, untuk semua pemangku kepentingan. Kami yakin bahwa manfaat yang lebih besar untuk Topics akan meningkatkan persaingan secara keseluruhan dan menguntungkan ekosistem secara keseluruhan."
Daftar penguji	Bagaimana penerapan Topics dan PA API di antara penayang Anda?	Kami tidak dapat membagikan informasi tersebut. Anda dapat melihat daftar penguji, yang memungkinkan penayang memilih untuk membagikan status pengujian mereka.
Pilihan topik	Izinkan pengguna memilih topik minat secara proaktif?	Kami tentu saja mempertimbangkan untuk memungkinkan pengguna menambahkan topik secara proaktif. Kami tidak berencana membahasnya dalam jangka pendek, tetapi kami terbuka untuk mempelajarinya lebih lanjut dalam jangka panjang.
Pilihan topik	Jika teknologi iklan memiliki kode di situs untuk mengamati topik, apakah mereka dapat mengetahui topik apa yang mungkin diamati?	Perusahaan teknologi iklan dapat menentukan topik yang terkait dengan situs. API tidak membagikan informasi ini secara real time karena dapat menimbulkan biaya latensi.
Taksonomi V2	Karena Topics dapat menampilkan hingga 3 Topics, apa perilaku yang diharapkan saat Taksonomi v2 diluncurkan?	API akan tetap menampilkan maksimal 3 Topik dan akan menyertakan versi taksonomi yang relevan untuk setiap Topik dalam respons.
(Juga dilaporkan pada kuartal sebelumnya) Pengamatan topik	Mengizinkan penerbit memberikan izin kepada Chrome untuk mengategorikan topik berdasarkan konten halaman (misalnya, head atau body).	Respons kami tetap tidak berubah sejak Kuartal 3: "Sebelumnya kami mempertimbangkan menawarkan fungsi untuk mengklasifikasikan situs ke dalam topik berdasarkan konten halaman, dan mengambil keputusan untuk tidak melanjutkan berdasarkan masalah privasi dan keamanan. Proposal ini dapat mengurangi beberapa kekhawatiran tersebut, tetapi tidak jelas sampai sejauh mana. Karena periode eksperimen CMA yang akan datang, perubahan ini tidak akan terjadi sebelum 3PCD. Kami menantikan masukan tambahan di sini."
Pilihan topik	Bagaimana domain diklasifikasikan dengan Topics mengingat bahwa domain tersebut bersifat umum?	Kami hanya menggunakan nama host untuk mengklasifikasikan situs ke dalam Topics. Situs yang diklasifikasikan secara luas tidak akan terpengaruh oleh perubahan ini. Hal ini karena informasi kontekstual situs akan selalu tersedia untuk lelang di situs mereka, yang akan memberikan informasi yang lebih spesifik untuk Topik yang luas.
Taksonomi V2	Menginginkan keselarasan topik yang lebih baik dengan standar lain (misalnya IAB).	Kami ingin mempelajari lebih lanjut alasan mereka mengharapkan keselarasan yang lebih dekat antara taksonomi IAB dan Topics. Langkah apa yang perlu mereka lakukan untuk mengadopsi Topics API, dan bagaimana taksonomi yang lebih berbeda memengaruhi langkah-langkah tersebut? Kami mempertimbangkan untuk merilis pemetaan antara taksonomi Topics dan taksonomi konten IAB. Akan sangat membantu untuk memahami apakah tindakan tersebut akan mengatasi tantangan yang dihadapi penayang.
Penyimpanan dan penggunaan data	Apakah Anda memiliki informasi lebih lanjut tentang bagaimana data disimpan dan di mana data ditransfer?	Informasi topik dibuat dan disimpan secara lokal, di perangkat pengguna. Berdasarkan permintaan, API akan menampilkan hingga 3 Topics ke pemanggil. Dalam tampilan Google, penelepon bertanggung jawab untuk mematuhi peraturan setempat saat menangani dan menyimpan informasi Topics. Selain itu, semua pemanggil harus menyatakan bahwa mereka tidak menggunakan Topics untuk mengidentifikasi ulang pengguna di seluruh situs. Lihat FAQ kepatuhan terkait privasi untuk detail lebih lanjut.
Taksonomi V2	Pengaruh Upgrade Taksonomi Topik dan status browser saat bertransisi dari v1 ke v2.	Topik yang disimpulkan dengan Taksonomi sebelumnya masih tersedia dan pada akhirnya dapat diambil oleh teknologi iklan hingga masa berlakunya habis (berusia 4 minggu).
Deskripsi API	Pengalaman pengguna Topics API menyesatkan.	Kami telah menyampaikan masukan ini kepada tim UX.
Pertanyaan terkait API	Bagaimana domain Yahoo diklasifikasikan dengan Topics mengingat domain tersebut bersifat umum?	Kami hanya menggunakan nama host untuk mengklasifikasikan situs ke dalam Topics. Penting untuk dipahami bahwa situs yang diklasifikasikan secara luas tidak akan dirugikan oleh hal ini.
Tingkat ketersediaan topik rendah	Penguji menerima Topics dalam jumlah rendah dari Google Ad Manager.	Google Ad Manager meluncurkan beberapa pengoptimalan untuk meningkatkan cakupan - pembeli seharusnya telah melihat peningkatan cakupan. Ada beberapa faktor yang diperkirakan yang dapat membatasi cakupan (misalnya preferensi pengguna, persyaratan pengamatan oleh pemanggil, dan kemungkinan latensi/waktu tunggu).

Protected Audience API (sebelumnya FLEDGE)

Tema Masukan	Ringkasan	Respons Chrome
Diferensiasi	Kurangnya kejelasan tentang bagaimana SSP menghadirkan diferensiasi pada lelang baru.	Kami telah mendengar beberapa rencana strategis yang memiliki Protected Audience dan/atau Privacy Sandbox API lainnya. Gambaran yang lebih besar, pengurangan ID lintas situs yang ada di mana-mana sering dilihat oleh sisi jual ekosistem sebagai langkah positif tidak hanya terkait privasi, tetapi juga secara komersial. Bisnis, kecil dan besar, yang menerima perubahan ini cenderung akan menemukan peluang.
Rendering iklan	Chrome sebagai satu-satunya jalur untuk merender iklan menghambat inovasi. Rendering Protected Audience mengurangi kelangsungan standar saat ini terkait iklan native.	Rendering iklan di browser selalu menggunakan teknologi browser untuk dirender. Hal itu tidak berubah. Mungkin masalah ini khusus untuk rencana mewajibkan penggunaan Fenced Frames bersama Protected Audience pada masa mendatang. Sebagian alasan mengapa rencana tersebut "di masa depan" adalah karena kami ingin teknologi Fenced Frames mendukung inovasi dan diferensiasi ekosistem dalam hal rendering iklan. Ada waktu bagi developer dan perusahaan yang tertarik untuk mempertimbangkan arah pembuatan Fenced Frames yang mencakup bagaimana pendekatan iklan native dapat didukung.
Input	Concern Protected Audience API (PA API) ditayangkan sebagai kurang lebih selesai pada saat banyak teknologi iklan mulai menjelajahi Privacy Sandbox API.	API ini akan terus berkembang berdasarkan informasi yang kami pelajari dari penggunaan serta ide-ide baru yang berasal dari dalam dan luar Chrome. API pengukuran dan relevansi yang tersedia secara umum saat ini sudah stabil, tetapi bukan berarti pengembangan telah berhenti dan kami menerima masukan tambahan.
Desain lelang	Desain Protected Audience menempatkan semua logika pemilihan iklan dan pembuatan audiens di platform sisi beli, sehingga menghilangkan kemampuan SSP untuk menawarkan pembuatan audiens dan logika pemilihan iklan untuk kampanye yang dijalankan di platformnya.	Protected Audience tidak bergantung pada siapa yang membuat audiens dan siapa yang mengajukan bid pada audiens. SSP dapat membuat Grup Minat (IG) yang disediakan untuk bidding. SSP juga dapat menyediakan logika bidding, yang tampaknya selaras dengan arah yang diarahkan langsung oleh banyak SSP ke agensi. Meskipun selalu ada ruang untuk kasus penggunaan tambahan, dasar-dasar Protected Audience cukup fleksibel untuk mendukung berbagai pendekatan terhadap pembuatan dan aktivasi audiens. Karakteristik privasi dari fondasi tersebut juga berarti bahwa data mentah tingkat pengguna tidak dibagikan antar-situs.
Desain lelang	Apakah lelang Protected Audience bertentangan dengan upaya Pengoptimalan Jalur Pasokan (SPO) ekosistem untuk mengurangi total jumlah perantara antara pengiklan dan penayang dan/atau duplikasi peluang iklan tertentu?	Tidak. Iklan pemenang di Protected Audience akan melewati maksimal dua entitas penjual (mis. SSP dan server iklan penayang) dan minimal tidak sama sekali—jika pembeli membuat integrasi langsung dengan penayang. Duplikasi permintaan yang sama melalui beberapa perantara tetap menjadi pilihan penayang. Protected Audience tidak akan memengaruhi hal ini. Lelang Protected Audience terjadi di luar sistem real-time server ke server saat ini agar tidak membocorkan data pengguna lintas situs. Sebagian orang mungkin mengatakan bahwa hal ini menduplikasi permintaan iklan. Ada beberapa kompromi yang diperlukan untuk mencapai privasi yang dapat dibuktikan secara teknis. Namun, dalam jangka panjang mungkin ekosistem memutuskan untuk menggunakan Protected Audience tanpa lelang sisi server tradisional. Pilihan ini dapat menghasilkan jalur pasokan yang lebih optimal.
Desain lelang	Protected Audience beralih ke model yang SSP jarang berada dalam lelang 'terakhir' yang dijalankan di halaman, tetapi dipaksa masuk ke model ini oleh desain API.	Kami tidak setuju. Penerapan pengguna awal yang kami lihat sebenarnya memungkinkan SSP yang berpartisipasi dalam lelang komponen dapat mengalahkan output lelang kontekstual, yang terjadi sebelum lelang Protected Audience berjalan. Output lelang komponen SSP di Protected Audience dianggap terakhir, setelah lelang kontekstual penuh dijalankan.
Desain lelang	Lelang kontekstual mungkin hanya relevan untuk memberikan sinyal data tentang peluang lelang untuk menginformasikan lelang Protected Audience.	Kami memperkirakan lelang kontekstual akan tetap relevan karena berbagai alasan seperti transaksi, kampanye bertarget audiens non-pihak pertama, dan banyak skenario kontekstual. Hal ini juga berguna jika tidak ada IG atau bid dalam Protected Audience gagal mencapai harga minimum atau mematuhi aturan kualitas iklan.
Pembentukan lalu lintas	DSP beroperasi pada QPS tetap. Mematuhi lelang Protected Audience akan mengurangi utilitas infrastruktur lama.	Seperti yang kami pahami, hal yang berubah terkait kueri per detik adalah banyak SSP menggunakan ID lintas situs sebagai fitur untuk menentukan apakah akan mengirim permintaan kepada DSP atau tidak. Hal ini akan tetap berlaku terlepas dari apakah penayang ingin menjalankan lelang Protected Audience atau tidak. Kami mempelajari pembentukan traffic dengan banyak SSP dan menemukan solusi, termasuk caching dan pemfilteran berbasis kontekstual. Seiring waktu, kami berharap developer dapat memanfaatkan Agregasi Pribadi untuk lebih membantu memahami preferensi bidding DSP dan untuk memfilter yang sesuai. Pada akhirnya, beberapa infrastruktur lama yang dibuat berdasarkan ID lintas situs tidak akan berguna lagi.
Sinyal yang tersedia	Kurangnya kejelasan tentang berbagai sinyal yang tersedia saat lelang terjadi dan bagaimana pengurutan dengan lelang kontekstual merugikan hal tersebut.	Secara umum, bagi bidder, informasi dapat diberikan saat IG dibuat, dari lelang kontekstual dan dari pencarian nilai kunci real-time. Untuk pencetak skor, informasi dapat diberikan saat lelang dikonfigurasi, termasuk informasi kontekstual tentang halaman dan lelang kontekstual, serta dari pencarian nilai kunci real-time di renderUrls iklan.
(Dilaporkan dalam kuartal sebelumnya) Rendering Video	Dukungan untuk rendering video menggunakan Protected Audience dan Fenced Frames.	Respons kami tidak berubah dibandingkan kuartal sebelumnya: "Protected Audience API mendukung rendering video menggunakan mekanisme yang mengandalkan iframe. Namun, kami belum mendesain solusi yang kompatibel dengan Fenced Frames, dan ini adalah salah satu alasan kami memutuskan untuk mendorong penerapan Fenced Frames hingga 2026. Artinya, jika partner memutuskan untuk menerapkan Fenced Frames sekarang, dukungan untuk video akan kurang untuk partner tersebut."
Rendering Video	Dukungan PA API untuk video di iframe terbatas untuk video HTML5, dan tidak mendukung standar VAST yang banyak digunakan.	Anda dapat menerapkan iklan berbasis VAST menggunakan mekanisme rendering iframe yang tersedia di Protected Audience saat ini. Google mengakui bahwa diperlukan rekayasa baru dari pihak pembeli, penjual, dan platform iklan penayang, dan kami akan terus berupaya memudahkan transisi dari cara kerja VAST di masa lalu.
(Dilaporkan dalam kuartal sebelumnya) Lelang Tingkat Teratas	Kemampuan untuk menggunakan server iklan penayang Google tanpa memberikan kontrol kepada Google Ad Manager atas lelang PA API tingkat teratas.	Respons kami tidak berubah dari kuartal sebelumnya: "Respons diberikan oleh Google Ad Manager: Rencana Google Ad Manager untuk Protected Audience API tidak menyertakan dukungan server iklan penayang Google tanpa kontrol lelang Protected Audience tingkat atas, karena alasan berikut. Agar dapat menayangkan iklan kepada pelanggan dengan baik di pasar penayangan iklan penayang, server iklan penayang Google perlu mempertahankan kontrol atas lelang Protected Audience tingkat teratas. Sebagai server iklan penayang, peran kami adalah memberikan perkiraan kepada penayang agar mereka dapat menegosiasikan kampanye yang dijual langsung tanpa memesan berlebih, serta mengatur kecepatan dan menayangkan reservasi langsung mereka secara optimal. Untuk melakukannya, Anda harus menjalankan lelang akhir untuk membandingkan semua permintaan langsung dan tidak langsung yang memenuhi syarat. Perkiraan dan kecepatan adalah fungsi inti yang diharapkan penayang dari server iklan. Tanpa perkiraan yang akurat, penayang dapat pada akhirnya menjual inventaris mereka secara berlebihan, sehingga membahayakan reputasi bisnis mereka. Kecepatan juga penting, karena tidak dapat memenuhi kontrak reservasi dengan pengiklan juga berisiko merusak hubungan langsung penayang-pengiklan, yang dapat mengakibatkan dampak yang signifikan bagi bisnis penayang. Singkatnya, kami tidak melihat aktivitas server iklan penayang dalam menjalankan lelang Protected Audience tingkat teratas sebagai hal yang berbeda dari aktivitas lain server iklan penayang."
(Dilaporkan pada kuartal sebelumnya) directFrom SellerSignals	directFromSellerSignals memungkinkan Google Ad Manager mencegah penayang melihat harga lelang kontekstualnya.	Respons kami tidak berubah dari kuartal sebelumnya: "Respons Chrome: Informasi yang diteruskan ke runAdLelang() tidak diketahui berasal dari penjual, kecuali jika penjual memanggil runAdAuction() dari iframe-nya sendiri. Dalam lelang multi-penjual, tidak mungkin semua penjual membuat frame yang memanggil runAdLelang(). directFromSellerSignals mengatasi masalah ini dengan memuat konten dari paket subresource yang dimuat dari asal penjual. Hal ini memastikan keaslian dan integritas informasi yang diteruskan ke lelang dari konfigurasi lelang penjual tidak dapat dimanipulasi. Jika ingin menggunakan Protected Audience API untuk memahami informasi apa pun yang diteruskan oleh penyedia teknologi mereka ke lelang Protected Audience, penayang dapat meminta fungsi ini kepada penyedia teknologi tersebut. Respons yang diberikan oleh Google Ad Manager: Kami telah lama terus berfokus pada keadilan lelang, termasuk janji kami bahwa tidak ada harga dari sumber iklan tanpa jaminan milik penayang, termasuk harga item baris tanpa jaminan, yang akan dibagikan kepada pembeli lain sebelum mereka mengajukan bid dalam lelang, yang kemudian kami tegaskan kembali dalam komitmen kami terhadap Otoritas Persaingan Prancis. Untuk lelang Protected Audience, kami ingin memenuhi janji kami dengan memanfaatkan directFromSellerSignals, dan tidak membagikan bid dari peserta lelang mana pun kepada peserta lelang lain sebelum lelang selesai di lelang multi-penjual. Untuk lebih jelasnya, kami tidak akan membagikan harga lelang kontekstual ke lelang komponen kami sendiri, seperti yang dijelaskan dalam pembaruan ini."
(Dilaporkan pada kuartal sebelumnya) Nilai K-anonymity	Bagaimana nilai "K" menjadi "k-anon" akan ditentukan dan kapan nilai tersebut akan dipublikasikan?	Kami memublikasikan nilai K-anonymity pada Desember 2023. Setelah proses 3PCD dimulai, kita akan menaikkan ambang batas k-anonymity ke nilai akhir 50 (k=50) dan mengatur periode pembaruan menjadi 1 jam (p=1). Nilai K-anonymity 50 dinilai memberikan keseimbangan optimal antara utilitas dan privasi. Nilai ini cukup untuk menggagalkan serangan bot dasar dan menjaga privasi diferensial, sekaligus cukup rendah sehingga API tetap berguna untuk kasus penggunaan yang dimaksudkan.
(Dilaporkan dalam kuartal sebelumnya) forDebuggingOnly	Potensi penyalahgunaan forDebuggingOnly.reportAdAuctionWin disalahgunakan jika tetap setelah 3PCD.	Kami telah membagikan proposal kami tentang cara untuk terus mendukung kasus penggunaan proses debug dalam jangka panjang di sini. Kami menantikan masukan tambahan terkait proposal ini.
(Dilaporkan dalam kuartal sebelumnya) Kebijakan asal yang sama	Minta untuk melonggarkan kebijakan asal yang sama untuk mengizinkan subdomain.	Permintaan ini sedang dipertimbangkan dan kami telah membahasnya di sini.
(Dilaporkan dalam kuartal sebelumnya) Ukuran Komponen Iklan	Tingkatkan jumlah komponen iklan dari 20 menjadi 40.	Kami telah membahas permintaan ini selama panggilan WICG 4 Oktober dan dalam masalah GitHub ini serta berencana untuk mengatasinya pada akhir Kuartal 1 2024.
(Dilaporkan pada kuartal sebelumnya) Masa Berlaku Kunci Server Nilai Kunci	Diskusi tentang penghapusan kunci server setelah IG yang terkait kedaluwarsa.	Pengelolaan TTL lebih baik dilakukan di luar TEE untuk mengurangi kompleksitas, meskipun kami menerima masukan tambahan di sini.
Pemicu MinatGroup	Dapatkah satu IG memicu beberapa generateBids dalam satu lelang (komponen)?	Setiap kali browser memanggil fungsi generateBid() dari sebuah IG, IG tersebut diperbolehkan untuk menampilkan nilai bid. Ada kemungkinan bahwa, misalnya, dalam lelang multi-penjual, IG dipanggil beberapa kali, setiap kali di salah satu lelang komponen. Tidak ada yang perlu dilakukan secara eksplisit oleh pemilik IG untuk mengaktifkan/mendukung perilaku ini.
Pertanyaan terkait kepatuhan	Apa cakupan izin yang dikumpulkan melalui browser Chrome pengguna?	Lihat "Bagaimana cara Privacy Sandbox menangani kepatuhan terkait privasi di Chrome?" di FAQ kepatuhan terkait privasi untuk mengetahui detailnya.
Lelang multi-tag	Bagaimana cara mengakomodasi lelang multi-tag?	Kami mengevaluasi permintaan ini dan menerima masukan tambahan di sini.
Ketersediaan Perlindungan IP	Apa dampaknya pada linimasa fitur Protected Audience seperti penerapan Frame Pagar dan penghapusan atau penghapusan Pelaporan Tingkat Peristiwa jika Perlindungan Kekayaan Intelektual belum siap hingga tanggal yang diumumkan?	Seperti yang disebutkan di sini, kami yakin linimasa Protected Audience harus ditautkan dengan linimasa rilis fitur perlindungan privasi lainnya.
modelingSignals	Minta kolom baru selain pemodelanSignals yang hanya dapat mengenkode informasi tampilan dan klik.	Kami memahami manfaat utilitas yang diberikan oleh hal ini dan kami sedang mengevaluasi permintaan tersebut serta menerima masukan tambahan di sini.
IG negatif	Apakah saya bisa mengizinkan IG normal untuk menentukan nama IG negatif?	Saat ini, hal ini tidak dapat dilakukan seperti yang dijelaskan di penjelasan, tetapi kami menerima masukan dari ekosistem tambahan terkait alasan mengapa hal ini diperlukan.
Penggunaan API	Membuat laporan gabungan di tingkat generateBid() yang lulus	Agregasi Pribadi dapat dipanggil di dalam generateBid.
Makro	Rutekan sinyal dari perBuyerSignals melalui makro di IFrame ke pihak ketiga.	Kami mendiskusikan kasus penggunaan ini di sini dan menerima masukan tambahan.
Penggunaan API	Jika pengambilan Sinyal Penskoran Tepercaya menampilkan error, apakah scoreAd() tetap akan dipanggil?	ScoreAd() harus tetap berjalan jika panggilan pengambilan tidak berhasil.
Penggunaan API	Menulis metadata.shard_num dalam file riegeli untuk file delta/snapshot.	Sekarang kami menambahkan dukungan untuk shard_num guna berhenti memblokir. Riegeli tidak diadopsi sebaik Avro, misalnya, tetapi tidak ditinggalkan. Karena TEE memiliki lebih banyak batasan dan overhead, kami melakukan kompromi untuk memprioritaskan performa daripada pengalaman pengguna. Kami mempertimbangkan untuk menyediakan layanan gRPC untuk membuat file dari permintaan. Kami juga dapat mengevaluasi dampak performa format lain seperti Avro.
Pengujian API	Bagaimana PA API dan Measurement API akan mendukung pengujian inkrementalitas?	Privacy Sandbox tidak memiliki cara untuk mengukur inkrementalitas dengan pra-lelang kontrafaktual. Anda dapat menggunakan Penyimpanan Bersama dan Agregasi Pribadi, tetapi kontrafaktual hanya akan dilakukan setelah lelang.
Penggunaan API	Apakah menggunakan biddingWasmHelperURL untuk update harian memengaruhi nilai minimum k-anonymity?	Karena k-anonymity tidak lagi dipertimbangkan untuk update IG, biddingWasmHelperURL dapat diperbarui tanpa memengaruhi nilai minimum.
Penggunaan API	Apakah kami dapat menerima notifikasi error untuk PA API?	Kami menyambut baik masukan ekosistem tentang notifikasi error seperti apa yang mereka perlukan untuk memecahkan masalah PA API.
Ukuran iklan	Ukuran iklan tidak terlihat dalam lelang maupun pelaporan.	Kami sedang mengatasi masalah terkait permintaan pull ini.
Penggunaan API	Apakah endpoint IG update dipanggil untuk IG jika tidak berpartisipasi dalam lelang ini?	Ya. UpdateURL dipanggil untuk semua IG dari pemilik tertentu, meskipun mereka tidak mengajukan bid di lelang tersebut. Satu-satunya persyaratan adalah: - pemilik harus disertakan dalam lelang tertentu (yaitu, disertakan sebagai pembeli dalam auctionConfig) - interestGroup pemilik tertentu tidak boleh diperbarui dalam 24 jam terakhir.
Pra-bid di PA API	Versi Prebid.js mana yang akan diperlukan untuk fase pengujian?	Menurut dokumentasi teknis kami, versinya harus >= 8.9.0.
Aktivasi data pihak pertama di PA API	Bagaimana mereka dapat mengaktifkan data pihak pertama mereka sendiri untuk definisi dan penggunaan IG?	Anda dapat menggunakan "Delegasi Izin" dan "grup minat negatif" untuk tugas ini.
PA API dan pemberian tag sisi server	Bagaimana cara kerja PA API dengan pemberian tag sisi server?	Tag dasar pada browser pengguna harus mengalihkan panggilan API ke tag lainnya di sisi server, yang akan memungkinkannya untuk mendaftarkan panggilan.
Pengujian Chrome (mode a/b)	Apakah ekspektasi bahwa SSP juga akan meneruskan label ini dalam permintaan bid RTB, dan jika demikian, bagaimana caranya?	Ya, ekspektasinya adalah label akan diteruskan dari SSP ke DSP. Entitas dianjurkan untuk mengakses label dan membagikan nilai yang tidak dimodifikasi kepada partner melalui Ekstensi perangkat ini.
Penyimpanan dan penggunaan data	Apakah Anda memiliki informasi lebih lanjut tentang bagaimana data disimpan dan di mana data ditransfer?	Kami tidak akan memberikan panduan hukum, melainkan lebih ke pendekatan/pemikiran umum kami seputar penyimpanan data, retensi, dan masalah privasi lainnya. Lihat FAQ kepatuhan terkait privasi di sini yang mungkin berguna bagi Anda.
Keamanan API	Kekhawatiran tentang kode berbahaya sisi klien yang memanipulasi nilai hasil dari fungsi generateBid().	Kami telah membahas masalah tersebut di sini dan beberapa masukan telah dimasukkan ke dalam proposal Agregasi Pribadi.
Tujuan khusus	Saat menggunakan panggilan reportEvent tujuan kustom, apakah Anda mengetahui jika asal pelaporan kustom (bukan kepada pembeli atau penjual) yang telah didaftarkan sebelumnya sebagai bagian dari IG di allowedReportingOrigins harus dinyatakan oleh DSP di reportWin menggunakan registerAdBeacon?	Tidak, peristiwa ini tidak perlu didaftarkan lagi di reportWin dan dapat langsung digunakan di reportEvent seperti yang didokumentasikan di sini.
Pembatasan API	Ukuran IG selama pembuatan dan update.	Ukuran update telah diperbarui menjadi 1 MB, yang cocok dengan batas 1 MB baru (dari 50 KB) untuk pembuatan IG.
Pembatasan K-anon	K-anon untuk iklan yang berisi berbagai ukuran.	Kami memublikasikan nilai K-anonymity pada Desember 2023 yang menyatakan bahwa K-anonymity akan mulai memeriksa ukuran iklan "sekitar 2025". Tidak ada cara untuk mengecualikan ukuran karena ini dapat berupa vektor pelacakan lintas situs, seperti yang dijelaskan dalam panggilan WICG 11 Oktober.
Keamanan API	Dapatkah pemain berbahaya memalsukan "nama host" halaman?	API mendukung subkunci yang ditetapkan ke nama host penayang. Karena browser menyetel kunci, sepertinya sulit untuk mengakali mekanisme ini.
Penggunaan API	Fungsi ForDebuggingOnly tidak boleh direkomendasikan untuk penggunaan produksi.	Kami akan menegaskan kembali pada ekosistem bahwa fungsi forDebuggingOnly tidak cocok sama sekali untuk memecahkan masalah setelah penggunaan 3PCD.
Memerlukan lebih banyak alat proses debug	ForDebuggingOnly tidak cukup untuk memahami masalah yang mungkin terjadi sebelum scoreAd().	Kami mengumpulkan lebih banyak masukan mengenai celah ini dan menerima masukan tambahan di sini.
Grup Tidak Ikut Minat Permanen	Permintaan untuk mengizinkan pengguna memilih tidak ikut membuat IG khusus secara permanen.	Strategi kami adalah mencegah pengguna memilih tidak ikut di level IG karena semantiknya tidak dapat dipahami pengguna sebagaimana mestinya.
Meningkatkan kualitas dokumentasi	Gunakan kapitalisasi yang sama untuk parameter renderUrls di spesifikasi dan penjelasan.	Kami menghargai masukan Anda dan akan menindaklanjuti pembaruan dokumentasi.
Dukungan transaksi Protected Audience	Minta opsi tambahan untuk Dukungan Transaksi Protected Audience.	Tim Chrome saat ini sedang mengevaluasi apa yang dapat kami lakukan untuk mendukung hal ini dengan 3PCD.
Makro	Dukungan makro diperlukan untuk menjaga ukuran IG di bawah ukuran IG maks.	Pembaruan terbaru untuk pesan penjelasan mengatasi sebagian permintaan ini.
ReportLoss API tingkat peristiwa	Permintaan untuk ReportLoss API tingkat peristiwa.	Meskipun laporan kerugian tingkat peristiwa menimbulkan risiko privasi yang parah, kami yakin sasaran dasar permintaan ini dapat dipenuhi dengan modifikasi yang sesuai pada Private Aggregation API. Kami menantikan masukan tambahan di sini.
Penggunaan API	Bagaimana perilaku metode forDebuggingOnly jika tidak ada skor bid > 0?	Jika skor <= 0, maka itu adalah kerugian otomatis. Jadi, reportAdLelangloss akan dipanggil.
Standardisasi	Tidak ada keselarasan antara pengguna nilai input/output fungsi PA API generateBid().	Kami merekomendasikan semua partner untuk melaporkan masalah ini (atau yang serupa) ke IAB Tech Lab. Grup ini secara khusus menangani standar industri untuk API seperti Protected Audience.
Keamanan API	Data apa dari IG kami yang dapat dilihat Google?	K-anonymity mengandalkan perlindungan privasi yang kuat untuk menghindari kebocoran data sensitif pengguna ke pihak mana pun, termasuk Google. Google juga mengembangkan implementasi pihak ketiga (Cepat) dari lapisan ini untuk meminimalkan risiko ini.
Pengujian Chrome (mode a/b)	Apakah pengguna yang dibatasi "k-anon" dapat dikecualikan dari pengujian?	Kami menampilkan status k-anonymity dalam pelaporan, seperti yang dijelaskan di sini.
Keamanan Brand	Dukung kasus penggunaan Keamanan Merek saat iklan tidak ditayangkan bergantung pada daftar situs atau kata kunci yang diblokir.	Kasus penggunaan keamanan merek tersebut seharusnya sudah dapat dilakukan dengan PA API. Agar kampanye iklan menargetkan beberapa kumpulan domain secara negatif, mereka dapat menyimpan daftar domain yang tidak diizinkan di IG itu sendiri, mungkin menggunakan filter Mekar jika mencantumkan setiap domain akan menghabiskan terlalu banyak ruang. Atau, pengguna dapat memperoleh keputusan izinkan atau tolak dari server Nilai Kunci, menggunakan UDF yang mencari jawaban berdasarkan kombinasi kunci yang mengidentifikasi kampanye iklan dan nama domain yang disertakan dalam permintaan Nilai Kunci. Protected Audience API juga memungkinkan SSP dan DSP meneruskan informasi apa pun tentang konteks halaman ke lelang. Hal ini dapat mencakup, misalnya, daftar topik atau kata kunci sensitif di halaman. Logika bidding DSP dapat membandingkan informasi ini dengan informasi yang tersimpan tentang tempat iklan tidak boleh ditampilkan, dan memilih untuk tidak mengajukan bid jika perlu. Kami menerima masukan dari ekosistem ini terkait kasus penggunaan tertentu yang mereka yakini tidak mungkin.
Delegasi izin	Bagaimana cara kerja delegasi izin?	Kami telah membagikan dokumentasi tentang delegasi izin di sini.
Permintaan Serempak	Gunakan permintaan POST untuk beberapa URL API PA agar dapat mendukung Permintaan Batch.	Kami menyambut baik proposal tersebut dan menantikan masukan tambahan di sini.
Tingkatkan API	Kolom yang mungkin tidak boleh digunakan (seperti X-fledge-bidding-signals-format-version).	Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Tingkatkan API	Permintaan untuk meneruskan izin GDPR ke Vendor pengukuran & penayangan iklan pihak ketiga.	Fungsi ini didukung menggunakan API pengganti makro yang tidak digunakan lagiReplaceInURN, seperti yang dijelaskan di sini.
Pengoptimalan Materi Iklan Dinamis	Bagaimana cara Protected Audience mendukung pengoptimalan materi iklan dinamis?	Kita membahas kasus penggunaan ini dan membagikan kemungkinan solusi di sini.
Tingkatkan API	Permintaan agar URL penayangan iklan pihak ketiga dapat memperoleh konteks IG terutama nama IG yang sesuai dengan IG yang memenangkan lelang.	Permintaan tersebut dapat meningkatkan risiko pelacakan bagi pengguna. Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Keamanan API	Kekhawatiran bahwa ukuran "blob IG" akan membocorkan informasi tentang IG yang dipilih.	Seperti disebutkan di bagian pertimbangan privasi dari penjelasan Chrome B&A API, ukuran blob tidak bergantung pada input apa pun ke navigator.getInterestGroupAdTargetingData(). Ukuran blob hanya memaketkan semua IG di perangkat. Hal ini memastikan bahwa ukuran blob relatif konsisten pada halaman dan membatasi kemampuan untuk membocorkan informasi lintas situs. Kami merancang seperti ini untuk alasan ini.
Pengujian Chrome (mode a/b)	Apa pendapat SSP lain tentang melewatkan pemuatan pertama sehubungan dengan setelan cookie dan Pengujian yang difasilitasi Chrome?	Kami belum pernah mendengar kekhawatiran yang signifikan (meskipun pihak lain telah mengakui situasi ini), tetapi kami menerima masukan terkait ekosistem jika ini adalah masalah yang signifikan.
Dukungan A/B Testing	Minta dukungan untuk pengujian A/B PA API.	Kami membahas permintaan ini dalam pertemuan WICG bulan November dan menerima masukan tambahan di sini.
Ukuran iklan	Siapa yang memilih ukuran untuk lelang Protected Audience?	Pertanyaan ini dijawab dalam FAQ ini.
Tingkatkan API	Permintaan untuk mengonfigurasi layanan nilai kunci agar menyetujui jalur /bidding-signals/v1/getvalues.	Kami telah menambahkan awalan jalur dukungan dalam permintaan pull ini.
Penggunaan API	Bagaimana penayang dapat membuat IG dengan kode mereka jika seharusnya berada di basis pengiklan, sehingga pengiklan dapat mengajukan bid pada IG tersebut?	Jawaban harus berasal dari beberapa partner teknologi iklan, yaitu DSP atau SSP yang ingin berpartisipasi dalam lelang Protected Audience dan menyediakan cara bagi audiens tersebut untuk berasal dari sumber luar. Kami telah membahas hal ini lebih lanjut dalam masalah GitHub ini.
Tingkatkan API	Meminta kemungkinan untuk menautkan IG Negatif ke iklan di "Grup Minat Positif".	Kami sedang mempertimbangkan permintaan ini dan membagikan kemungkinan proposal tentang cara mendukungnya di sini.
Jumlah Shard	Permintaan dukungan untuk meneruskan "dukungan shard_num" dalam metadata.	Setelah masukan ini, kami telah menambahkan dukungan untuk shard_num.
Penggunaan API	Permintaan estimasi overhead kunci di server K/V.	Kami telah menyampaikan pendapat dan menerima masukan tambahan di sini.
K-anonimitas	Permintaan klarifikasi dan peningkatan perincian penghitung K-Anonymity.	Kami telah memberikan klarifikasi tentang perincian penghitung Anonimitas K di sini.
Proses debug	Permintaan untuk meningkatkan kemampuan proses debug PA API setelah perubahan terbaru yang diusulkan ke forDebuggingOnly.	Kami sedang mendiskusikan permintaan tersebut di sini dan menerima masukan tambahan di sini.
Ukuran iklan	Meminta ukuran Slot Iklan sebagai sinyal BTS tambahan.	Kami telah membagikan proposal untuk mendukung permintaan ini dan menerima masukan tambahan di sini.
Keamanan API	Apakah mungkin untuk membatasi penggunaan "runAdLelang()" berdasarkan origin?	Kami telah membagikan jawaban mendetail di sini.
Masa aktif IG	Permintaan untuk memperpanjang masa pakai IG dari 30 menjadi 90 hari.	Kami mempertimbangkan permintaan tersebut dan menerima masukan tambahan di sini.
Penggunaan API	Apakah saya dapat menjalankan lelang Protected Audience secara paralel dengan Bidding Header dan panggilan server iklan penayang?	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.
Proses debug	Meminta dukungan yang lebih baik untuk ekstensi proses debug Chrome PA API yang berkomunikasi dengan DevTools.	Kami sangat mendukung untuk menyediakan lebih banyak alat proses debug dan menerima saran lainnya di sini.
Penggunaan API	Notifikasi kerugian tidak terpicu jika tidak ada bid dari penjual komponen yang membuatnya menjadi penjual teratas.	Kami telah menjelaskan alasan di balik hal ini di sini.
Tingkatkan API	Permintaan untuk mendukung TextEncoder dalam worklet bidding Protected Audience.	Kami mempertimbangkan permintaan ini dan menerima masukan tambahan di sini.
Penggunaan API	Panggilan jaringan dan logika yang berjalan di klien dapat memblokir thread utama dan menyebabkan tantangan eksekusi JS yang dapat memengaruhi SEO.	Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Penggunaan API	Apakah DSP dapat menggunakan funnel bidding sisi server saat ini untuk mengevaluasi dan mengirim kandidat iklan sebagai bagian dari perBuyerSignal untuk digunakan dalam lelang di perangkat?	Kami mendiskusikan pertanyaan ini dan menerima masukan tambahan di sini.
Memperluas data peluang bid	Permintaan untuk memperluas data peluang bid yang diteruskan oleh browser ke SSP dengan daftar domain asal unik dari IG aktif di browser.	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.
ORTB	Meminta dua hook baru untuk adaptasi AuctionConfig dan generateBid di ORTB.	Kami sedang meninjau masalah ini dan menerima masukan tambahan di sini.
Kemenangan Sebelumnya	Permintaan untuk IG yang mendefinisikan prevWinsTransformer, yang mengambil pencapaian IG sebelumnya dan menghasilkan hal yang dapat diserialisasi.	Kami sedang meninjau masalah ini dan menerima masukan tambahan di sini.
Jenis Konten	Strategi untuk evolusi jenis konten, misalnya JSON menjadi sesuatu seperti CBOR.	Kami sedang meninjau masalah ini dan menerima masukan tambahan di sini.
Pra-bid di Protected Audience API	Minta contoh halaman penayang yang menggunakan pra-bid agar dapat menjalankan alur menyeluruh untuk lelang Protected Audience.	Kami mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem terkait mengapa hal ini harus diprioritaskan. Kami juga telah melihat peserta ekosistem yang memproduksi contoh halaman penayang yang tersedia bagi pengguna lain di ekosistem untuk melakukan demo.

Layanan Lelang Terlindungi

Tema Masukan	Ringkasan	Respons Chrome
Trusted Execution Environment (TEE)	Lebih mahal untuk menjalankan Lingkungan Eksekusi Tepercaya di cloud publik dibandingkan di pusat data teknologi iklan lokal?	Model keamanan TEE kami saat ini memanfaatkan praktik implementasi cloud publik. Secara khusus, TEE berbasis perangkat keras saat ini tidak bertahan dari semua serangan fisik. Penyedia cloud publik kami yang sudah didukung, AWS dan GCP, merancang dan menerapkan mitigasi untuk risiko akses fisik, termasuk dari karyawan. Lihat detail selengkapnya di bawah mengenai dukungan lokal. Teknologi iklan telah memberi tahu kami bahwa menjalankan layanan cloud lebih mahal daripada pusat data teknologi iklan lokal. Meskipun kami tidak dalam posisi untuk mengevaluasi pernyataan tersebut, kami menerima masukan tambahan mengenai biaya dan terus mengevaluasi opsi untuk memperluas dukungan TEE kami.
(Dilaporkan dalam kuartal sebelumnya) TEE lokal	Apa saja persyaratan yang harus dipenuhi agar seseorang dapat menjadi penyedia TEE?	Respons kami serupa dengan kuartal sebelumnya: "Meskipun kami terus mempelajari dukungan untuk opsi di luar solusi berbasis cloud publik, termasuk mempertimbangkan deployment mana yang dapat diterima dari sudut pandang keamanan, saat ini kami tidak memiliki rencana untuk mendukung TEE lokal. Pada tahap ini, mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud adalah yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang mengapa persyaratan tersebut diperlukan dan layak mengingat batasan privasi dan keamanan."
Batas Server Kunci/Nilai	Batas kunci per lelang per server	Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Pembatasan K-anon	Konfirmasi bahwa K-anonymity tidak akan diterapkan di masa mendatang pada kunci K/V.	Saat ini kami tidak memiliki rencana untuk menerapkan k-anon pada kunci permintaan server K/V karena kami berencana untuk memindahkan server K/V ke TEE di masa mendatang.
Membuat layanan K/V	Apakah Google memiliki artefak siap pakai yang tersedia untuk layanan K/V?	Saat ini kami tidak memiliki artefak siap pakai untuk server Kunci/Nilai Protected Audience, meskipun kami dapat mempertimbangkan untuk menyediakannya jika mendengar permintaan yang tinggi dari ekosistem.
Dukungan EgId di B&A	Meminta dukungan kolom experimentGroupId dalam kode Bidding & Lelang dan meminta layanan KeyValue dari BuyerFrontEnd	B&A saat ini tidak memiliki dukungan untuk experimentGroupId, tetapi ingin meluncurkannya pada Beta 2 (saat ini dijadwalkan untuk Februari 2024). Kami telah membagikan informasi tambahan di sini.
Penggunaan API	Penggabungan permintaan di HTTP dapat membantu melindungi jaringan dari penyerang di jalur, tetapi operator TEE akan mempelajari ukuran.	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.
Meningkatkan kualitas dokumentasi	Spesifikasi tidak jelas bagaimana server k-v akan ditangani.	Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Penggunaan API	Apa tujuan dari "Ad-Auction-Result" dan adAuctionHeaders?	Kami mendiskusikan masalah ini di sini dan menerima masukan tambahan.
Meningkatkan kualitas dokumentasi	Tidak jelas apakah desain v2 telah disebarkan ke FLEDGE.md.	FLEDGE.md membahas cara Chrome mengirim permintaan ke BYOS-KV. Desain protokol v2 terbatas untuk TEE-KV saja dan saat ini tidak didukung oleh Chrome.

Mengukur Iklan Digital

Attribution Reporting (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Pengukuran lintas-lingkungan	Bagaimana rencana Chrome untuk mendukung pengukuran lintas-lingkungan dalam fase sementara saat 3PC telah dihapus dari perangkat seluler Chrome, tetapi Privacy Sandbox untuk Android belum tersedia?	Di sisi Android, kami sedang berupaya memperluas cakupan PSB/ARA - Attribution Reporting API (ARA) tersedia di Android 13 dan 14, dan kami berencana untuk mulai memperluasnya ke Android 11 dan 12 dalam tahun ini, meskipun hal tersebut dapat berubah sewaktu-waktu. Kami tidak akan dapat memperluas ke Android 10 atau yang lebih lama, tetapi kami memperkirakan persentase perangkat Android yang masih menggunakan Android 10 atau lebih rendah pada 3PCD dan secara alami menurun dari waktu ke waktu seiring pengguna melakukan upgrade. Kami menantikan masukan tambahan dari ekosistem terkait permintaan ini.
Pemfilteran	Memfilter "konversi" dari pemindaian materi iklan.	Kami telah menghubungi pemangku kepentingan ini untuk lebih memahami permintaan mereka, dan menerima masukan tambahan dari ekosistem mengenai masalah ini.
Server Iklan Pihak Ketiga	Bagaimana cara kerja PA API dan ARA dengan tag Server Iklan Pihak Ketiga?	Serupa dengan cara kerja piksel dengan tag tayangan dan klik saat ini, server iklan dapat menetapkan sendiri pendaftaran sumber dan pemicu untuk ARA (termasuk dari lelang Protected Audience), atau server iklan dapat menyiapkan pengalihan untuk meneruskan dan menerima pendaftaran sumber dan pemicu untuk ARA.
DCM	Dukungan attributionsrc oleh DCM dan server iklan pihak ketiga lainnya.	Ini adalah masalah terkait DCM dan telah ditangani oleh tim DCM di masalah GitHub ini.
Kunci Agregasi Hierarkis	Apakah perlu membagi semua anggaran kontribusi ke dalam semua kunci hierarki ini?	Kami telah membahas dan memberikan jawaban kepada pemangku kepentingan ini. Saat menggunakan struktur kunci hierarkis, teknologi iklan harus mempertimbangkan bahwa anggaran kontribusi dibagi di semua output utama untuk tayangan.
Menggunakan Sub-Domain yang berbeda	Membuat pelaporan atribusi berfungsi dengan sumber dan pemicu yang terdaftar di subdomain yang berbeda tetapi menggunakan eTLD+1 yang sama?	Kami telah mendiskusikan pertanyaan ini dengan pemangku kepentingan dan mengusulkan solusi berikut. Mereka dapat mengubah penyiapan URL agar memiliki asal pelaporan yang sama pada sumber dan pemicu, atau mengalihkan dari URL mereka saat ini ke URL umum sebelum melakukan pendaftaran. Kami terbuka terhadap masukan ekosistem tambahan jika solusi yang diusulkan tidak berhasil untuk kasus penggunaan mereka.
(Juga dilaporkan pada kuartal sebelumnya) Dukungan Produksi	Tingkat layanan apa yang tersedia untuk mendukung partner menggunakan ARA?	Respons kami tidak berubah dibandingkan kuartal sebelumnya: "Google menyediakan berbagai saluran untuk memungkinkan teknologi iklan melaporkan masalah teknis dan memungkinkan eskalasi apa pun yang diperlukan untuk menyelesaikan masalah tersebut. Selain itu, Chrome berharap dapat membuat dan menskalakan proses lebih lanjut untuk menyelesaikan masalah teknis dan eskalasi yang memengaruhi kondisi ekosistem. Chrome berkomitmen untuk memastikan resource untuk upaya ini. Lihat postingan developer kami untuk informasi selengkapnya di forum publik dan pribadi untuk masukan dan eskalasi."
(Juga dilaporkan pada kuartal sebelumnya) Linimasa	Apakah Google akan menyiapkan "Tingkat Peristiwa Fleksibel Penuh Fase 2" pada awal pengujian Kuantitatif CMA?	Tingkat Peristiwa Fleksibel Penuh Fase 2 diperkirakan akan tersedia di Chrome pada K1 2024. Anda dapat melacak statusnya di sini.
(Juga dilaporkan pada kuartal sebelumnya) Funnel konversi	Laporkan beberapa domain yang digunakan dalam konversi.	Kasus penggunaan ini dapat terjadi karena penambahan beberapa tujuan. Kami menantikan masukan tambahan.
Melaporkan label pengujian	Apakah kemampuan pelaporan akan memungkinkan penguji melaporkan grup mana yang merupakan bagian dari pengguna (browser Chrome) (Mode A/B)?	Kami sedang berupaya memublikasikan panduan pengujian untuk mendapatkan label pengujian Chrome di ARA.
Dokumentasi	Dokumentasi untuk Attribution-Reporting-Register-Source menyatakan bahwa tanggal habis masa berlaku akan dibulatkan ke hari terdekat, bagaimana cara pembulatannya?	Dibulatkan ke hari terdekat berarti 1,5 hari akan dibulatkan menjadi 2 hari.
Menggunakan Sub-Domain yang berbeda	Minta untuk menerima laporan Attribution Reporting API di subdomain yang berbeda sebagai pendaftaran sumber dan pemicu.	Hal ini tidak mungkin. Pengalihan HTTP dapat diterapkan tetapi hal ini tidak disiapkan. Kami menantikan masukan tambahan dari ekosistem tentang mengapa permintaan ini berguna.
Penundaan pelaporan tingkat peristiwa	Atribusi dan periode pelaporan 7 hari, tetapi karena keterlambatan pelaporan tingkat peristiwa, mungkin perlu waktu lebih dari 8 hari hingga semua laporan diterima.	Kami menerima masukan tersebut dan menerima masukan tambahan dari ekosistem terkait apakah keterlambatan dalam pelaporan tingkat peristiwa ini merupakan masalah atau bukan, terutama dengan peralihan dari periode pelaporan peristiwa tetap ke fleksibel.
Pemicu konversi	Pemicu konversi yang terjadi antara akhir event_report_window pertama (1 jam) dan waktu habis masa berlaku (1Hari) tidak akan menghasilkan laporan.	Kami telah memperkenalkan konfigurasi tingkat peristiwa fleksibel yang beralih dari periode pelaporan peristiwa tetap ke periode fleksibel.
Kebisingan	Apakah laporan level peristiwa menghasilkan konversi palsu seperti yang dijelaskan di penjelasan GitHub?	Ya, derau diterapkan ke laporan tingkat peristiwa dan mewakili semua kemungkinan status output, termasuk trigger_data yang berbeda, tidak melaporkan apa pun sama sekali saat pemicu benar-benar terjadi, atau berpotensi melaporkan beberapa laporan palsu untuk peristiwa tersebut. % derau bersifat open source dan dapat dibuat fleksibel melalui konfigurasi tingkat peristiwa yang fleksibel.
Pemfilteran	Menggunakan pemfilteran dengan Attribution Reporting API akan tetap menghabiskan anggaran kontribusi meskipun tidak mencatat kunci agregasi.	Ini berfungsi sebagaimana mestinya karena aggregatable_trigger_data hanya mendukung pemfilteran pada bagian kunci pemicu itu sendiri, bukan pada nilai / kunci. Filter tingkat atas dapat mendukung pemfilteran kunci itu sendiri, tetapi hal ini dibagikan berdasarkan peristiwa + agregat sehingga tidak berlaku di sini. Kami menerima masukan tambahan dari ekosistem di sini jika pemfilteran kunci diperlukan.
Batas Penyimpanan	Permintaan untuk menetapkan batas penyimpanan yang juga mempertimbangkan asal pelaporan.	Peningkatan batas dari 1024 menjadi 4.096 akan berlaku mulai M120 dan kami mengharapkan masukan tambahan dari ekosistem di sini.
Atribusi Langsung	Bagaimana cara mendapatkan metrik untuk situasi saat pengguna mengunjungi pengiklan secara langsung tanpa melalui penayang, karena proses pelaporan atribusi standar tidak mencakup skenario ini?	ARA hanya dirancang untuk memulihkan informasi lintas situs (yaitu gabungan informasi di seluruh situs penayang/pengiklan). Jika tidak memerlukan informasi lintas situs, ARA tidak akan membantu Anda. Kami sedang mendiskusikan masalah ini dan menerima masukan tambahan di sini.
Waktu Laporan	Mendapatkan waktu schedule_report_time dari timeserver, bukan menggunakan waktu mesin lokal.	Saat ini kami tidak memiliki rencana untuk menggunakan server waktu, dan kami belum mendengar banyak permintaan dari Teknologi Iklan. Kami ingin mendengar masukan tambahan dari ekosistem tentang apakah ini akan menjadi fitur yang berguna.

Layanan Agregasi

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Solusi lokal	Dapatkah Layanan Agregasi di-deploy di pusat data lokal?	Selagi kami mempelajari opsi yang berpotensi mendukung di luar solusi berbasis cloud, saat ini mendukung TEE lokal tidak memungkinkan karena adanya batasan keamanan lokal yang memerlukan evaluasi yang memakan waktu untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung GCP selain AWS) akan sangat bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan di sini tentang alasan diperlukannya persyaratan tersebut.
Kantong	Jika enklave tidak aktif atau tiba-tiba menerima error, bagaimana penanganannya oleh Aggregation Service API?	Kami akan menggunakan percobaan ulang jika enklave gagal saat memulai dan penskalaan otomatis untuk memunculkan instance baru jika sebuah instance dianggap tidak responsif. Adtech juga dapat menyelidiki kegagalan menggunakan log. Untuk men-debug kegagalan enklave di AWS, teknologi iklan dapat memeriksa status instance EC2 dengan login ke AWS Console Manager. Teknologi iklan juga dapat login ke instance host Nitro Enclave dan memeriksa status enklave dengan alat nitro-cli. Jika ada error/kegagalan, mereka dapat menggunakan antarmuka command line AWS untuk melihat log dan menyelidiki lebih lanjut. Untuk men-debug kegagalan enklave di GCP, adtech dapat memeriksa status instance mereka melalui Cloud Console. Mereka juga dapat memeriksa error menggunakan list-errors-command.
Menggunakan Sub-Domain yang berbeda	Meminta untuk mendaftarkan beberapa (sub)domain untuk menggunakan beberapa instance Layanan Agregasi, baik di lingkungan pengembangan maupun produksi.	Pendaftaran situs telah diluncurkan sehingga teknologi iklan dapat mendaftarkan beberapa subdomain dari situs yang sama pada satu akun AWS atau project GCP. Mereka juga dapat mendaftarkan domain yang sama di beberapa akun AWS atau project GCP. Kami menerima masukan dari ekosistem.
Anggaran Privasi	Bagaimana cara men-debug masalah terkait kehabisan anggaran privasi dengan lebih baik?	Saat ini kami sedang mencari solusi untuk memberikan detail selengkapnya tentang anggaran yang habis dan juga meningkatkan dokumentasi kami guna menguraikan strategi yang dapat digunakan teknologi iklan untuk meminimalkan kemunculan error ini. Kami akan memperbarui halaman GitHub Layanan Agregasi setelah memiliki proposal.
Nilai Epsilon	Permintaan untuk meningkatkan nilai epsilon.	Nilai epsilon Layanan Agregasi akan disimpan dalam rentang hingga 64, untuk memfasilitasi eksperimen dan masukan pada parameter yang berbeda selama 3PCD. Kami akan memberikan pemberitahuan awal ke ekosistem sebelum nilai rentang epsilon diperbarui.
Biner	Publikasikan kumpulan biner yang lebih lengkap untuk rilis Layanan Agregasi.	Kami sedang meninjau permintaan ini dan menerima masukan tambahan.
Penggunaan API	Berbagi data dengan Koordinator, dengan mempertimbangkan Persyaratan Layanan Koordinator.	Kami meminta klarifikasi tentang masalah ini dan menerima masukan tambahan.

API Agregasi Pribadi

Tema Masukan	Ringkasan	Respons Chrome
Proses debug	Mengaktifkan opsi tambahan untuk proses debug selama pengujian Mode B.	Seperti yang telah disampaikan dalam masalah GitHub ini, kami akan terus mengizinkan mode debug di Mode B. Kelayakan ini akan berubah di M121 Beta sebesar 50% dari traffic Mode B mulai 31/1. Kami akan memberikan pemberitahuan sebelum mengaktifkan Stabil.

Batasi Pelacakan Terselubung

Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna

Tema Masukan	Ringkasan	Respons Chrome
ChromeOS	Mendukung Petunjuk Klien Agen Pengguna untuk bit Chrome OS.	Kami telah membagikan respons terhadap permintaan ini di sini.

Perlindungan IP (sebelumnya Gnatcatcher)

Tema Masukan	Ringkasan	Respons Chrome
Penyalahgunaan	Google mungkin dapat melihat data penjelajahan pengguna melalui Perlindungan IP.	Perlindungan IP meneruskan traffic melalui dua proxy (satu dijalankan oleh Google, satu oleh perusahaan lain). Tindakan ini memastikan bahwa Google tidak dapat melihat data penjelajahan. Semua traffic dienkripsi antara Chrome dan proxy, sehingga proxy Google tidak memiliki informasi tentang situs yang sedang dijelajahi. Selain itu, sistem menggunakan token autentikasi buta untuk meminimalkan akses ke ID pengguna di proxy. Yang akan dilihat oleh semua proxy Google adalah klien yang tidak dikenal pada IP tertentu menggunakan sistem proxy. Informasi tentang situs yang dikunjungi atau iklan dimuat tidak tersedia.
Dukungan Mode Headless	Bagaimana bot yang menggunakan plugin dan mode headless akan dikelola?	Mengurangi penyalahgunaan Perlindungan Kekayaan Intelektual merupakan prioritas utama tim. Kami telah mempertimbangkan skenario ini dengan cermat (di antara banyak potensi ancaman lainnya) dan sedang mengupayakan opsi yang akan membantu mengurangi kemungkinan keberhasilan penyalahgunaan atau penipuan. Meskipun saat ini kami tidak dapat memberikan detail lebih lanjut, kami berharap dapat menyediakannya dalam waktu dekat dan berharap dapat melanjutkan diskusi ini.
Proxy yang ada	Bagaimana cara kerja Perlindungan IP dengan setelan proxy yang ada di Chrome?	Konfigurasi proxy yang ada akan tetap didukung. Pengguna akan dapat mengonfigurasi proxy kustom mereka sendiri seperti sebelumnya.
Pelaporan Penyalahgunaan	Bagaimana pelaporan penyalahgunaan akan ditangani?	Kami akan memberitahukan detail selengkapnya dalam waktu dekat, tetapi kami berencana untuk memiliki mekanisme bagi organisasi dan pengguna untuk membagikan laporan dan bukti penyalahgunaan.
Peraturan	Bagaimana Perlindungan Kekayaan Intelektual akan mematuhi hukum dan peraturan setempat?	Google berkomitmen untuk mematuhi hukum dan peraturan setempat, dan mengakali pemblokiran tingkat negara seperti itu mungkin tidak diizinkan. Fitur ini tidak dimaksudkan untuk pengelakan.
Membatasi kemampuan	Apakah Perlindungan IP akan memblokir respons cyber kami?	Kami berusaha untuk mencapai keseimbangan antara melindungi pengguna agar tidak dilacak di seluruh web berdasarkan alamat IP mereka sekaligus meminimalkan gangguan terhadap operasi normal server, termasuk penggunaan alamat IP untuk anti-penyalahgunaan. Meskipun saat ini kami tidak dapat memberikan detail lebih lanjut, kami berharap dapat menyediakannya dalam waktu dekat dan berharap dapat melanjutkan diskusi ini.
Linimasa	Jika kebijakan ini akan diberlakukan sebelum akhir tahun 2024, hampir tidak mungkin untuk bersiap menghadapinya.	Chrome pada awalnya akan meluncurkan Perlindungan IP sebagai setelan keikutsertaan untuk pengguna di wilayah tertentu, memahami bahwa hal ini dapat menjadi perubahan signifikan terkait cara beberapa perusahaan mengandalkan alamat IP, dan berupaya meminimalkan gangguan seiring dengan penyesuaian ekosistem. Perlindungan IP akan ditransisikan ke default paling cepat tahun 2025.
Penggunaan API	Apakah pengguna akan diberi pilihan untuk mengaktifkan/menonaktifkan Perlindungan IP saat pertama kali membuka Chrome?	Kami berencana memberikan pilihan kepada pengguna apakah mereka ingin menggunakan Perlindungan IP atau tidak. Mekanisme penyajian opsi ini kepada pengguna masih dalam pengembangan.
Penggunaan API	Berapa banyak data yang dicatat dan berapa lama data tersebut disimpan?	Kami akan membagikan detail lebih lanjut di masa mendatang, tetapi kami berencana mencatat jumlah data yang minimal.
Masukan negatif	Pengguna dapat menggunakan VPN jika mereka lebih suka menggunakannya. Tidak perlu API PS.	Tujuan Perlindungan IP adalah mencegah penggunaan alamat IP untuk tujuan pelacakan lintas situs, IP ini tidak dimaksudkan sebagai layanan VPN.
Keamanan API	Bagaimana cara mencegah pihak pertama mengakses alamat IP dan meneruskan info melalui parameter header?	Pada awalnya, kami akan berfokus pada pihak ketiga karena kami melihatnya memiliki dampak terbesar. Kami akan terus memantau ekosistem untuk menentukan apakah kami perlu mengembangkan pendekatan kami untuk mencegah pengelakan berskala besar.
Penggunaan API	Konfirmasi diperlukan jika pemahaman tentang penggunaan API sudah benar.	Perlindungan IP menggunakan pendekatan berbasis daftar untuk mengidentifikasi traffic pihak ketiga mana yang melewati proxy. Origin yang ada dalam daftar, tetapi diakses dalam konteks pihak pertama tidak akan di-proxy-kan melalui layanan ini untuk koneksi tersebut. Misalnya, jika perusahaan analisis tercantum di daftar domain dan pengguna membuka langsung situs, situs tersebut akan tetap dapat mengamati alamat IP pengguna, bukan alamat IP melalui proxy. Namun, jika domain dalam daftar tersebut membuat permintaan jaringan dalam konteks pihak ketiga, koneksi akan di-proxy-kan dan alamat IP asli pengguna tidak akan terlihat oleh situs. Sasaran akhir kami adalah mencegah pelacakan lintas situs terhadap pengguna di seluruh web. Kami sedang mempertimbangkan beberapa detail sebelum membagikan informasi lebih lanjut tentang domain pihak ketiga yang akan menjadi fokus utama kami di awal.
VPN	Kekhawatiran bahwa proposal Google mungkin tidak menguntungkan bagi penyedia VPN lainnya.	Tujuan Perlindungan IP adalah mencegah penggunaan alamat IP untuk tujuan pelacakan lintas situs, IP ini tidak dimaksudkan sebagai layanan VPN.
Linimasa	Apa yang dimaksud dengan linimasa Perlindungan IP?	Perlindungan IP akan diikutsertakan pada awalnya. Hal ini akan membantu memastikan adanya kontrol pengguna atas keputusan privasi dan Google dapat memantau perilaku pada volume yang lebih rendah. Perlindungan IP akan diluncurkan secara bertahap dan akan beralih ke default paling cepat tahun 2025. Seperti semua proposal terkait privasi yang kami buat, kami ingin memastikan bahwa kami mempelajari semua hal yang kami lakukan dan menyadari bahwa mungkin ada pertimbangan regional yang perlu dievaluasi. Kami menggunakan pendekatan berbasis daftar dan hanya domain dalam daftar dalam konteks pihak ketiga yang akan terpengaruh. Kami sadar bahwa proposal ini dapat menyebabkan gangguan yang tidak diinginkan untuk kasus penggunaan yang sah, sehingga kami hanya berfokus pada skrip dan domain yang dianggap melacak pengguna.
Membatasi kemampuan	Alamat IP pengguna tidak dapat lagi dicari di WHOIS.	Posisi kami adalah bahwa alamat IP adalah ID stabil yang penggunaannya dapat memiliki implikasi privasi bagi pengguna, termasuk penggunaan metadata yang terkait dengannya seperti ASN. Dengan Perlindungan IP, kami mencoba mencapai keseimbangan yang tepat antara privasi dan mendukung pengalaman pengguna yang bermanfaat di web, misalnya dengan pendekatan kami terhadap geolokasi IP. Jika metadata ini tidak cukup untuk kasus penggunaan Anda, kami terbuka untuk membahasnya lebih lanjut.
Perujuk HTTP	Apakah Perujuk HTTP asli akan dipertahankan?	Tidak ada rencana untuk mengubah header Perujuk sebagai bagian dari Perlindungan IP, seperti yang dibahas di sini.
Open source	Apakah kode sumber Perlindungan IP akan menjadi open source?	Mayoritas software di sini adalah open source sebagai bagian dari project Chromium dan Envoy Proxy, tetapi beberapa komponen merupakan open source, seperti yang dijelaskan di sini.

Mitigasi Pelacakan Kembali

Tema Masukan	Ringkasan	Respons Chrome
Penghapusan penyimpanan	Apakah Mitigasi Pelacakan Kembali (BTM) menghapus penyimpanan Bersama dan Attribution Reporting?	Kami tidak bermaksud agar BTM menghapus penyimpanan Privacy Sandbox API (ARA, PA API, Shared Storage, Private Aggregation, Topics). BTM hanya boleh menghapus jenis penyimpanan yang memiliki risiko privasi jika diakses dalam konteks pihak ketiga. Perbaikan bug sedang berlangsung.
Penggunaan API	Versi Chrome mana yang akan diaktifkan BTM? Apakah pelacakan pengalihan/pantulan setelah 10 detik akan dianggap sebagai Pelacakan kembali oleh BTM atau tidak?	Pada M116, BTM diluncurkan ke 100% pengguna dengan 3PC yang diblokir. Saat ini, pengalihan setelah 10 detik tidak dianggap sebagai pantulan.
Kasus penggunaan login	Menyinkronkan/mempertahankan status login secara otomatis di beberapa domain, tanpa dihukum karena perilaku seperti pelacakan?	Kami mendiskusikan permintaan ini di sini dan menerima masukan tambahan dari ekosistem.
Perjalanan pengguna	Saat ini BTM menghasilkan perjalanan pengguna yang rumit.	Kami sedang mendiskusikan masalah ini dan menyampaikan pendapat kami tentang hal ini di sini.
API Akses Penyimpanan	BTM di Chromium akan menerima hibah 3PC dari Storage Access API (SAA).	Kami telah membahas masalah ini dengan peserta ekosistem di TPAC 2023 dan menerima masukan tambahan di sini.
Dampak pada pelaporan iklan	Mitigasi Pelacakan Kembali dapat menyebabkan perusahaan kecil di ekosistem ini mengandalkan API Privacy Sandbox lainnya seperti ARA untuk menjalankan kasus penggunaan iklan.	Mitigasi pelacakan kembali dimaksudkan untuk mencegah pengelakan 3PCD. ARA adalah salah satu dari banyak solusi pengukuran alternatif yang akan tersedia bagi perusahaan setelah 3PCD, tetapi tidak ada perusahaan yang diwajibkan untuk menggunakannya.

Anggaran Privasi

Tidak ada masukan yang diberikan untuk kuartal ini.

Memperkuat batas privasi lintas situs

Set Situs Terkait (sebelumnya Set Pihak Pertama)

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Batas domain Set Situs Terkait (RWS)	Permintaan untuk memperluas jumlah domain terkait.	Saat ini, kami tidak bermaksud meningkatkan batas numerik. Batas ini ditetapkan berdasarkan pertimbangan privasi pengguna, masukan dari pemangku kepentingan ekosistem di W3C, dan pertimbangan implementasi yang sebanding di browser lain. Untuk mengetahui informasi tambahan, lihat postingan blog kami (1, 2). Sebaiknya periksa kasus penggunaan yang memerlukan akses cookie lintas situs di luar batas numerik, dan pertimbangkan untuk memanfaatkan panduan kami untuk kasus penggunaan identitas, sematan yang diautentikasi, dan kasus penggunaan iklan.
Cakupan akses cookie	Kekhawatiran bahwa semua domain di RWS akan memberikan akses untuk membaca dan menulis semua cookie dari semua domain.	Keanggotaan dalam RWS tidak mengakibatkan anggota dapat mengakses cookie satu sama lain. Sebagai gantinya, hal ini akan memungkinkan anggota mengakses cookie mereka sendiri saat disematkan di situs RWS yang sama (setelah pemanggilan Storage Access API).
(Juga dilaporkan pada kuartal sebelumnya) Integrasi RWS + CHIPS	Meminta integrasi RWS + CHIPS untuk mendukung kasus penggunaan seperti pengujian A/B	Kami akan terus meminta kasus penggunaan dan permintaan untuk fitur ini di sini. Untuk saat ini, kami mempertimbangkan kebutuhan akan fitur ini terhadap risiko interoperabilitas lintas browser.
Penggunaan API	Bagaimana jika pengguna menghapus situs secara manual dari setelan Chrome secara lokal?	Saat ini kami tidak memiliki cara bagi pengguna untuk menghapus situs secara manual dari grup. Sebagai gantinya, pengguna dapat memilih untuk menonaktifkan fitur "situs terkait" menggunakan tombol di bawah "Blokir cookie pihak ketiga"; atau "Blokir semua cookie pihak ketiga" di panel setelan Perlindungan Pelacakan yang baru.
Komunikasi Lintas-Domain	Apakah RWS akan mengizinkan komunikasi lintas domain?	Saat ini kami sedang menjalankan Uji Coba Origin untuk memperluas akses ke beberapa jenis penyimpanan yang tidak dipartisi (termasuk localStorage dan Broadcast Channel) melalui Storage Access API yang akan mengaktifkan komunikasi ini. Kemampuan ini tersedia dalam semua konfigurasi Storage Access API yang didukung, di RWS yang sama, dan juga di seluruh situs non-RWS. Terdapat informasi tambahan untuk Postingan blog ini.
requestStorageAccessFor	Dapatkah document.requestStorageAccessFor(origin) menampilkan promise yang di-resolve dengan cookie lintas situs origin?	Hal ini tidak mungkin. Karena pemanggilan terjadi dari origin tingkat atas (yang berbeda dari origin yang diteruskan sebagai argumen), tindakan tersebut akan melanggar Kebijakan Asal yang Sama.

API Frame dengan Fence

Tema Masukan	Ringkasan	Respons Chrome
(Juga dilaporkan pada kuartal sebelumnya) Iklan Native	Dukungan Frame Fence untuk Iklan Native.	Kami sebelumnya menyampaikan bahwa beberapa teknologi Privacy Sandbox akan diperlukan pada masa mendatang untuk lebih memperkuat perlindungan privasi. Misalnya, untuk Protected Audience, kami akan mewajibkan penggunaan Bingkai dengan Fence untuk rendering iklan, dan beralih dari pelaporan tingkat peristiwa, paling lambat tahun 2026. Kami telah memberikan tanggal "paling cepat" untuk setiap persyaratan mendatang ini, sehingga industri memiliki kejelasan tentang evolusi API yang dimaksudkan. Tambahan waktu tersebut memungkinkan kami untuk terus bekerja sama dengan industri guna merancang dan mengimplementasikan dukungan untuk berbagai kasus penggunaan penting yang lebih luas. Misalnya, kami akan mengembangkan Frame dengan Fenced sebelum persyaratannya pada tahun 2026 atau yang lebih baru guna mempertahankan dukungan untuk iklan native dan video dengan Protected Audience API. Sesuai dengan Komitmen kami, CMA akan dimintai masukan terkait perubahan tersebut, dan kami akan terus menerima masukan dari ekosistem sebelum menerapkan persyaratan "paling cepat" tersebut.
Perbedaan ukuran di berbagai platform	Melaporkan bahwa ukuran konten yang ditampilkan dalam Fenced Frame terlihat berbeda antara desktop dan smartphone.	Kami sedang memeriksa masalah tersebut dan menerima masukan tambahan di sini.
Merender komponen iklan	Memberikan kode contoh tentang cara merender adComponents dalam Fenced Frame?	Kami akan mencari dokumentasi tentang cara menggunakan navigator.adLelangComponents(numComponents) di dalam Fenced Frame untuk menampilkan iklan yang terdiri dari beberapa bagian.
Tingkatkan API	Memberikan lebih banyak sinyal ke FencedFrames (meningkatkan keamanan merek).	Kami menyambut baik proposal tersebut dan menantikan masukan tambahan di sini.

API Penyimpanan Bersama

Tema Masukan	Ringkasan	Respons Chrome
Kasus penggunaan anti-penyalahgunaan / anti-penipuan	Potensi penggunaan Shared Storage untuk mendeteksi penipuan atau anomali.	Kita telah membahas kemungkinan tersebut di sini dan menantikan masukan tambahan.
Pembatasan Frekuensi	Menyediakan cara untuk pembatasan frekuensi lintas situs di luar PA API.	Kami menghargai masukan bahwa pembatasan frekuensi lintas situs di luar PA API adalah kasus penggunaan yang berharga. Saat ini, Privacy Sandbox tetap berfokus pada kumpulan API saat ini untuk 3PCD. Namun, kami menerima masukan tambahan dari ekosistem terkait kasus penggunaan ini di sini.

CHIP

Tema Masukan	Ringkasan	Respons Chrome
Pop-up/Pengalihan	Bagaimana CHIP akan mendukung kasus penggunaan autentikasi tersemat yang melibatkan pop-up dan pengalihan?	Baru-baru ini kami membagikan beberapa panduan untuk memeriksa dampak penghentian penggunaan 3PC terhadap alur kerja login Anda dan kami menerima masukan tambahan di sini.
Batas partisi	Kurangi batas keseluruhan per situs per partisi hingga 1 KiB.	Kami mempertimbangkan permintaan ini dan menerima masukan tambahan di sini. Kami akan terus memantau masukan seiring kami terus meluncurkan 3PCD dan developer mengadopsi CHIP serta memberikan masukan.
Migrasi cookie	Proses yang direkomendasikan untuk memigrasikan aplikasi web guna mengeluarkan cookie ketika dipartisi. Tindakan ini tidak merusak cookie/sesi yang sedang berlangsung?	Kami mengusulkan skema potensial untuk migrasi dalam respons kami di sini; tetapi developer dapat merumuskan solusi alternatif yang lebih cocok untuk konfigurasi mereka.
Penggunaan API	Apakah akses ke penyimpanan terpartisi dinonaktifkan saat pengguna tidak memilih ikut serta dalam setelan API Privasi Iklan?	Penyimpanan yang dipartisi dan cookie terpartisi (CHIP) diaktifkan meskipun pengguna tidak memilih ikut serta dalam setelan API Privasi Iklan; karena mereka tidak mengaktifkan transfer informasi lintas situs. Sebagai prinsip umum, transfer informasi lintas situs akan tunduk pada batasan, pemeriksaan, atau keikutsertaan pengguna; tetapi saat ini hal ini tidak berlaku untuk CHIPS.
Penggunaan API	Apa alasan untuk memblokir cookie yang tidak dipartisi, dan bukan karena browser hanya "diam-diam" mempartisi cookie tersebut?	Hal ini tidak dapat dilakukan dalam jangka pendek dan menengah, seperti yang dijelaskan di sini.

FedCM

Tema Masukan	Ringkasan	Respons Chrome
Penggunaan API	Tidak dapat menyajikan 'file terkenal' di eTLD+1 dalam lingkungan pengembangan.	Kami telah mengupdate Chrome Canary untuk melewati pengambilan yang terkenal seperti yang dibahas di sini.
Penggunaan API	Apakah ada persyaratan interaksi pengguna tertentu yang ditentukan untuk meminta izin login pihak ketiga atau menggunakan FedCM?	Tidak ada persyaratan interaksi pengguna yang spesifik, seperti yang dibahas di sini.
Keamanan API	Apakah ada rencana untuk memiliki alur yang memungkinkan klien memulai FedCM, namun pada dasarnya Token ditransfer dari IdP ke sistem backend RP?	Kami sedang mendiskusikannya dan menantikan masukan tambahan di sini.
Keikutsertaan	Izinkan IDP untuk ikut serta menerima client ID RP, sehingga pengguna dapat memutuskan apakah mereka memercayai IDP tersebut atau tidak.	Kami sedang mendiskusikan permintaan ini dan menerima masukan tambahan di sini.
Penggunaan API	Minta dokumentasi selengkapnya tentang FedCM.	Kami menerima masukan ini dan akan terus meningkatkan dokumentasi seiring kami terus mengembangkan API ini.

Mencegah spam dan penipuan

Private State Token API (dan API lainnya)

Tema Masukan	Ringkasan	Respons Chrome
Dokumentasi	Minta panduan developer mendetail tentang Token Status Pribadi untuk membantu pengujian.	Kami telah memublikasikan panduan developer untuk Token Status Pribadi pada Q4 2023.
Verifikasi Usia/Gender	Sulit melakukan verifikasi "usia & gender" pada audiens setelah 3PCD.	Token Status Pribadi saat ini tidak dirancang untuk verifikasi usia dan gender. Kami ingin memahami kasus penggunaan dengan lebih baik, dan bagaimana hal ini dicapai hari ini, serta menerima masukan tambahan.