Laporan kuartalan untuk K1 2024 yang merangkum masukan ekosistem yang diterima tentang proposal Privacy Sandbox dan respons Chrome.
Sebagai bagian dari komitmennya kepada CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox-nya (lihat paragraf 12 dan 17(c)(ii) dari Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang tersedia di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menerima masukan yang diperoleh dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.
Tema masukan diberi peringkat berdasarkan prevalensi per API. Hal ini dilakukan dengan mengambil agregasi jumlah masukan yang telah diterima tim Chrome terkait tema tertentu dan mengaturnya dalam urutan menurun berdasarkan jumlah. Tema masukan umum diidentifikasi dengan meninjau topik diskusi dari rapat publik (W3C, PatCG, IETF), masukan langsung, GitHub, dan pertanyaan umum yang muncul melalui tim internal Google dan formulir publik.
Lebih khusus lagi, risalah rapat untuk rapat badan standar web telah ditinjau dan, untuk masukan langsung, catatan Google tentang rapat pemangku kepentingan 1:1, email yang diterima oleh setiap engineer, milis API, dan formulir masukan publik dipertimbangkan. Google kemudian berkoordinasi antara tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi tema yang muncul secara relatif sehubungan dengan setiap API.
Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat untuk masalah yang diajukan oleh pemangku kepentingan, dan menentukan posisi secara khusus untuk tujuan latihan pelaporan publik ini. Mencerminkan fokus pengembangan dan pengujian saat ini, pertanyaan dan masukan diterima, terutama sehubungan dengan Topics, Protected Audience, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum mendapatkan respons Chrome yang dipertimbangkan.
Glosarium akronim
- ARA
- Attribution Reporting API
- CHIP
- Cookie yang Memiliki Status Partisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Federated Credential Management
- FPS
- Set Pihak Pertama
- IAB
- Interactive Advertising Bureau
- IDP
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Internet Protocol
- openRTB
- Bidding real-time
- OT
- Uji Coba Origin
- PAT API
- Protected Audience API (sebelumnya FLEDGE)
- PatCG
- Grup Komunitas Teknologi Iklan Pribadi
- RP
- Relying Party/Pihak yang Mengandalkan
- RWS
- Set Situs Terkait (sebelumnya Set Pihak Pertama)
- SSP
- Platform Sisi Pasokan
- TEE
- Trusted Execution Environment
- UA
- String Agen Pengguna
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Willful IP Blindness
Masukan umum, tidak ada API atau Teknologi tertentu
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Tata kelola | Minat dalam periode komentar publik untuk setiap pembaruan tata kelola pada Privacy Sandbox. | Kami terbuka untuk masukan yang wajar dari pemangku kepentingan terkait perkembangan signifikan apa pun terkait Privacy Sandbox, termasuk tata kelola Privacy Sandbox di masa mendatang. |
| Pengujian | Fase pengujian tambahan untuk 3PCD selain Pengujian yang difasilitasi Chrome 1% saat ini. | Kami tidak bermaksud menawarkan pengujian yang difasilitasi Chrome di luar 1% traffic Chrome saat ini yang diaktifkan sejak awal Januari. |
| Web ke Aplikasi | 3PCD di perangkat seluler tidak boleh terjadi sebelum interoperabilitas penuh antara web dan aplikasi tercapai. | Kami setuju bahwa sebaiknya interopabilitas aplikasi dan web didukung, dan telah meluncurkan pengukuran atribusi lintas aplikasi dan web serta sedang mempelajari solusi penargetan web ke aplikasi. Namun, kami tidak berencana menunda 3PCD di web seluler. Kami tidak memiliki sasaran cakupan 100% pada akhir 3PCD. Sebaliknya, kami memperkirakan kompatibilitas di Android untuk pengukuran lintas aplikasi dan web akan cukup tinggi pada 3PCD dan akan meningkat seiring waktu saat pengguna mengupdate ponsel mereka. |
| Peran Browser | Chrome tampaknya mengambil peran sebagai server iklan atau SSP. | Chrome tidak mengambil peran server iklan atau SSP. Dengan PA API, Chrome menyediakan penampung untuk server iklan, SSP, DSP, dan teknologi iklan lainnya untuk menghadirkan logika bidding dan penskoran mereka sendiri. |
| Panduan Kasus Penggunaan | Panduan yang lebih jelas tentang kasus penggunaan yang akan didukung oleh Privacy Sandbox API. | Pada awal project Privacy Sandbox, dokumentasi developer terutama berfokus untuk melibatkan developer dalam proses diskusi dan masukan untuk semua proposal. Artinya, konten umumnya disusun berdasarkan pemahaman tentang motivasi dan konsep di balik project, diikuti dengan detail pengembangan awal dan detail pengujian untuk setiap proposal. Hal ini efektif dalam membangun kolaborasi ekosistem yang sebenarnya dalam mengembangkan proposal, tetapi seiring dengan berkembangnya API hingga tersedia secara umum, ada audiens baru developer yang hadir terutama untuk mem-build API, bukan berkontribusi pada pengembangan dasarnya. Baru-baru ini kami memperbarui navigasi situs developer Privacy Sandbox agar berfokus pada kasus penggunaan, menggunakan kategorisasi yang serupa dengan IAB Tech Lab dalam laporan Privacy Sandbox Task Force terbarunya. Pendekatan berbasis kasus penggunaan untuk dokumentasi ini akan kami teruskan ke depannya. |
| Lingkungan Pengembangan Lokal | Bagaimana cara kami terus mengembangkan dan menguji frontend secara lokal di http://localhost jika cookie adalah SameSite=Secure dan backend di-fronting oleh CDN? | Kami membahas masalah ini di sini dan menerima masukan tambahan dari ekosistem. |
| Mitigasi 3PCD | Apakah ada cara terprogram untuk mengetahui 3PC diblokir atau saat heuristik aktif? | Di Chrome, deteksi fitur dan document.hasStorageAccess yang dipanggil di iframe memungkinkan developer mengetahui apakah origin di iframe memiliki akses ke 3PC. |
| Pengujian Video | Saat ini tidak dapat menguji iklan video di Privacy Sandbox. | Chrome memposting diskusi dan demonstrasi tentang beberapa kemungkinan cara video dapat dilakukan dengan PA API saat ini (lihat 242 dan 254 di repositori demo kami di GitHub). Perhatikan bahwa kode ini tidak dimaksudkan sebagai contoh kode yang akan diadopsi secara massal oleh teknologi iklan, tetapi sebagai bukti konsep dan demonstrasi teknik yang dapat mendukung rendering video VAST dengan PA API. Selama diskusi ini, juga menjadi jelas bahwa meskipun rendering video sudah dapat dilakukan saat ini, ada perubahan yang dapat dilakukan Chrome yang akan menyederhanakan penerapan dengan PA API. Misalnya, pembaruan pada penggantian makro (dibahas di sini) yang sudah kami rencanakan untuk ditangani berdasarkan masukan tentang kasus penggunaan keamanan merek verifikasi iklan pihak ketiga, juga akan menangani masukan dalam kasus penggunaan video, saat pembeli mencari makro penjual yang akan digunakan dalam rendering. Sebagian besar diskusi hingga saat ini berfokus pada rendering iklan video VAST. Rendering iklan Native dapat menggunakan pendekatan yang sama, dan dalam banyak hal lebih mudah. Iklan native saat ini tampaknya kurang mendapatkan perhatian dibandingkan video, tetapi ini hanya masalah prioritas industri teknologi iklan, bukan hambatan teknis untuk penerapan. |
| Pengukuran Non-iklan | 3PCD dapat memengaruhi solusi pengukuran audiens yang tidak terkait iklan. | API pengukuran tidak mewajibkan kasus penggunaan terkait iklan. Meskipun ARA lebih spesifik untuk perjalanan iklan standar, Agregasi Pribadi bersifat umum. Kedua elemen penyusun ini dapat digunakan untuk menangani berbagai aktivitas pengukuran. |
| Kreator Konten | Privacy Sandbox disusun untuk mendorong kreator konten membuat lebih banyak konten untuk YouTube dan lebih sedikit di situs mereka sendiri. | Inisiatif Privacy Sandbox berfokus untuk menjaga privasi aktivitas pengguna di internet yang terbuka dan bebas. Kami tahu bahwa penayang mengandalkan iklan untuk memproduksi konten dan menyediakannya seluas mungkin. Pengiklan membantu orang menemukan produk atau penawaran baru yang mungkin mereka inginkan. Fitur Privacy Sandbox memungkinkan berbagai situs, termasuk situs yang bekerja sama dengan kreator konten, untuk menampilkan iklan yang berguna kepada pengguna berdasarkan aktivitas mereka dengan berbagai pihak, tanpa mengungkapkan identitas pengguna kepada pihak tersebut. |
| Linimasa yang Lebih Jelas | Jadwal rilis yang lebih jelas dan mendetail untuk teknologi Privacy Sandbox. | Dokumentasi Privacy Sandbox API mencakup halaman status dan ketersediaan API. Halaman ini mencantumkan fitur mendatang dan linimasanya (misalnya, PA API, ARA). Anda dapat melihat status ini secara terpusat di sini. |
| Machine Learning | Teknologi iklan tidak dapat melatih model machine learning dengan benar hingga 3PCD melampaui 1%. | Memperluas 3PCD ke lebih banyak browser untuk pengujian tidak akan menjamin bahwa API akan melihat lebih banyak penggunaan, yang mungkin menjadi hal yang dicari teknologi iklan untuk melatih model machine learning lebih lanjut. Jika penggunaan ekosistem yang lebih luas bukan yang dicari teknologi iklan untuk melatih model machine learning lebih lanjut, maka tidak ada alasan untuk memperluas 3PCD karena teknologi iklan yang ingin melatih model pada lebih banyak traffic dapat melakukannya saat ini tanpa peningkatan 3PCD. Hal ini dapat dilakukan tanpa Chrome yang tampak bergerak maju di 3PCD sebelum akhir Standstill. |
| Kasus Penggunaan yang Tidak Didukung | Kasus penggunaan DSP layanan mandiri saat ini tidak dipertimbangkan. | Ada beberapa DSP layanan mandiri yang secara rutin memberikan masukan publik tentang API. Beberapa DSP tersebut yang memberikan masukan publik secara rutin juga mencantumkan diri mereka sebagai penguji. Selain itu, Chrome secara aktif terlibat dalam topik DSP layanan mandiri umum seperti video dan server iklan pihak ketiga. Panggilan PA API mingguan terbaru telah membahas topik ini. |
| Uji Coba Origin | Meminta OT untuk situs yang menginginkan peluncuran dan cakupan pengujian yang lebih agresif untuk 3PCD. | Chrome saat ini sedang mengembangkan OT pihak pertama, yang akan memungkinkan origin memilih ikut serta dalam perilaku penghentian bertahap 3PC. Origin tingkat teratas yang mendaftar untuk uji coba ini dan men-deploy token akan memiliki 3PC yang diblokir seolah-olah perangkat pengguna mengaktifkan perlindungan pelacakan. OT ini akan memberikan peluang berharga bagi situs untuk melakukan pengujian yang lebih luas terhadap alternatif jangka panjang untuk 3PC, sebelum penghentian 3PC yang dijadwalkan akan dilakukan setelah berkonsultasi dengan CMA. Kami masih berupaya untuk menyelesaikan linimasa peluncuran OT. |
| Laporan Lab Teknologi IAB | Masukan tentang Privacy Sandbox yang diterima dari Laporan IAB Tech Lab. | Kami merespons laporan IAB Tech Lab secara mendetail di sini. Kami juga mengakui bahwa "laporan tersebut menimbulkan pertanyaan seputar dokumentasi yang terfragmentasi, persyaratan komersial, audit pihak ketiga, akreditasi industri, skalabilitas, transparansi, dan tata kelola di masa mendatang, yang akan kami bahas dengan ekosistem dan memperbarui FAQ publik kami." Kami telah membahas dokumentasi yang terfragmentasi sebelumnya. Kami membahas persyaratan komersial di bagian "Jaminan Data" di sini dan beberapa produk Google Ads telah membagikan pendekatan mereka. Kami membahas audit pihak ketiga di bagian "Jaminan Integritas Algoritma" di sini. Sehubungan dengan akreditasi, kami berharap lembaga tersebut akan terus mengakreditasi produk, termasuk penggunaan teknologinya, bukan teknologi itu sendiri. Terkait skalabilitas, kami terus terbuka untuk data dari developer yang menunjukkan masalah. Terkait transparansi dan tata kelola, kami terus mengembangkannya secara terbuka di GitHub dan di forum seperti W3C sambil berinteraksi dengan CMA berdasarkan Komitmen. |
| Login dengan Google | Login dengan Google akan memungkinkan Google menggunakan data login lintas identifikasi yang bertentangan dengan Komitmen. | Login dengan Google tidak memungkinkan Google menggunakan data yang bertentangan dengan Komitmen. |
| Kompatibilitas | Apa rencana untuk dukungan Privacy Sandbox API dan kompatibilitas maju / mundur? | Setelah Chrome meluncurkan fitur untuk ketersediaan umum, kami berupaya mempertahankan dukungan untuk fitur tersebut. Tentu saja, mempertahankan kompatibilitas mundur tidak selalu dapat dilakukan, dan dalam kasus tersebut, kami memiliki proses yang jelas untuk penghentian dan penghapusan fitur yang ada, yang dijelaskan di sini. Kami berharap dapat terus menambahkan lebih banyak fitur ke Privacy Sandbox API dari waktu ke waktu, sebagai respons atas masukan ekosistem tentang kasus penggunaan yang akan mendapatkan manfaat dari dukungan yang lebih baik. Dalam kasus seperti itu, kami cenderung menyertakan semacam teknik Deteksi Fitur, sehingga teknologi iklan yang tertarik untuk bereksperimen dengan fitur baru dapat langsung bertanya kepada browser apakah fitur tersebut didukung. Hal ini lebih baik daripada meminta developer untuk memeriksa nomor versi Chrome tertentu, karena beberapa fitur mungkin tidak diluncurkan ke semua pengguna Chrome secara bersamaan. Misalnya, pekerjaan deteksi fitur kami untuk PA API dapat ditemukan di sini. |
| Implementasi Server | Daripada menggabungkan dengan implementasinya sendiri, Chrome harus menentukan perilaku yang harus dipenuhi oleh implementasi Server Sinyal Tepercaya, Server Agregasi, dan komponen non-browser lainnya yang diperlukan. Hal ini akan memungkinkan inovasi dalam batas privasi yang dapat diterima. | Kami menghargai dan menyambut keinginan untuk berinovasi oleh pihak eksternal. Untuk semua API dan layanan, kami ingin memberikan fleksibilitas teknologi iklan untuk menerapkan fungsinya. Misalnya, kami mengizinkan teknologi iklan menggunakan informasi bisnis rahasia dalam mendesain logika bidding untuk lelang. Selain itu, kami terus menerima masukan dari teknologi iklan dan, jika dibenarkan, memasukkannya ke dalam desain kami. Agar orang lain dapat menjalankan kode mereka sendiri di Trusted Execution Environment, Privacy Sandbox harus meninjau kode (dan perubahan apa pun) untuk mengonfirmasi bahwa kode tersebut memenuhi jaminan privasi. Hal ini akan memerlukan upaya yang signifikan dari tim Privacy Sandbox. Oleh karena itu, kami ingin memahami manfaat yang ingin dicapai pemangku kepentingan, yang saat ini belum terpenuhi oleh kami. |
| Heuristik | Apa rencana jangka panjang untuk heuristik? | Sejalan dengan yang telah ditunjukkan oleh browser lain, kami bermaksud untuk menghentikan heuristik ini pada akhirnya karena solusi alternatif menjadi digunakan secara luas, yang tunduk pada analisis kelayakan lebih lanjut. Kami telah membagikannya di sini. |
| Volume Pengujian | Volume traffic yang berbeda saat membandingkan dimensi yang berbeda. | Eksperimen 1% memiliki kriteria pengecualian yang menyebabkan perbedaan kelayakan untuk eksperimen, antara berbagai populasi klien Chrome. Misalnya, eksperimen mengecualikan pengguna Chrome Enterprise, sehingga diperkirakan pecahan traffic dengan label eksperimen akan lebih tinggi pada akhir pekan. Melihat persentase traffic yang berbeda di berbagai bagian data (seperti geografis, tanggal, dan platform) adalah hal yang wajar, dan hal ini sejalan dengan yang kita lihat di data Chrome. |
| Mengaktifkan Ulang 3PC secara Manual | Apakah situs dapat mengetahui jumlah pengguna (%) yang telah mengaktifkan kembali cookie secara manual setelah 3PCD diterapkan? | Pengguna akan dapat mengaktifkan kembali akses 3PC di tingkat situs melalui Pengabaian Pengguna jika mereka mengalami kerusakan. 3PC juga dapat diaktifkan kembali oleh tindakan lain seperti Storage Access API. Ada langkah-langkah teknis, seperti hasStorageAccess(), yang memungkinkan situs mendeteksi apakah 3PC diaktifkan atau dinonaktifkan. Namun, Chrome tidak akan memfasilitasi cara bagi situs untuk mengetahui alasan pengaktifan kembali. |
| Fitur Anti-Pelacakan | Berapa lama fitur UI Perlindungan dari Pelacakan Chrome akan tersedia? | UI Perlindungan Pelacakan di kolom URL diperkirakan akan tetap ada setelah 3PC tidak digunakan lagi. |
| (Juga dilaporkan pada kuartal sebelumnya) Dukungan lintas browser |
Vendor browser lain yang mengadopsi Privacy Sandbox API. | Vendor browser lainnya, seperti Apple, Mozilla, dan Microsoft, adalah peserta aktif dalam forum publik tempat prinsip privasi dan pendekatan berbasis browser dibahas. Kami merasa terdorong oleh diskusi kolaboratif di forum seperti pertemuan TPAC Tahunan W3C baru-baru ini dan forum PATCG W3C yang sedang berlangsung, tempat kami melihat tanda-tanda konvergensi. Misalnya, Microsoft Edge baru-baru ini mengumumkan rencananya yang "bertujuan untuk memaksimalkan kompatibilitas sintaksis" dengan PA API dan ARA sekaligus menawarkan fitur tambahan untuk developer. |
| Opsi penggantian untuk penyematan yang tidak kompatibel setelah 3PCD | Berikan hook API untuk mendeteksi apakah iframe / penyematan pihak ketiga mematuhi 3PCD atau tidak. | Kami sedang membahas permintaan tersebut di sini dan menerima masukan tambahan dari ekosistem. |
| Pengujian | Meminta flag tambahan di instance Chrome terkelola yang menonaktifkan perilaku yang disesuaikan untuk sementara. | Kami mempertimbangkan permintaan ini untuk instance Chrome terkelola dan menerima masukan tambahan dari ekosistem jika tanda tersebut akan berguna. |
Pendaftaran & Pengesahan
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Verifikasi Pengesahan | Bagaimana cara Google memastikan keaslian pengesahan? | Semua pendaftar diwajibkan untuk menyimpan file pengesahan saat menggunakan API. Google memvalidasi bahwa file sudah ada dan sintaksisnya sudah benar, tetapi Google tidak memvalidasi perilaku teknologi iklan sehubungan dengan bahasa pengesahan. |
| Proses Pendaftaran Private Aggregation API | Apakah ada cara untuk memeriksa status pendaftaran Private Aggregation API? | Semua peserta yang disetujui akan diberi tahu melalui email dari tim Dukungan pendaftaran setelah pendaftaran divalidasi. Jika ada pertanyaan selama proses pendaftaran, pendaftar dapat menghubungi tim dukungan (yang akan menghubunginya setelah mengirimkan formulir pendaftaran). Tim dukungan akan merespons dan menjawab pertanyaan serta memberikan panduan tambahan yang diperlukan. |
Menampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada kuartal sebelumnya) Linimasa dan Dokumentasi Pengklasifikasi |
Harus ada beberapa bentuk mekanisme untuk meninjau klasifikasi atau setidaknya transparansi tambahan tentang cara mode klasifikasi menentukan kategori. | Respons kami tidak berubah dari kuartal sebelumnya: "Kesalahan klasifikasi situs dapat membuat sinyal Topik sedikit kurang berguna sebagai sinyal secara keseluruhan, tetapi situs tertentu yang salah diklasifikasikan tidak lebih atau kurang dirugikan oleh hal ini dibandingkan situs lainnya. Hal ini karena informasi kontekstual situs akan selalu tersedia untuk lelang di situsnya, yang akan memberikan informasi yang sebanding dengan topik yang benar, bahkan jika terjadi kesalahan klasifikasi. Kami menerima masukan tentang subjek ini di sini." |
| Google Ad Manager | Google Ad Manager sudah disematkan di sebagian besar situs dan akan memiliki informasi yang jauh lebih luas tentang topik pengguna dibandingkan dengan pesaing yang hadir di lebih sedikit situs. | Persyaratan pengamatan ada untuk memastikan Topics API tidak menyebabkan data pengguna dibagikan kepada lebih banyak entitas daripada teknologi yang diganti oleh API (termasuk 3PC). Solusi industri lainnya seperti Pra-bid berfungsi dengan 10.000 situs dan memungkinkan peserta pasar memanggil Topics API melalui teknologi mereka. Selain itu, perlu diperhatikan bahwa batas hingga 5 topik teratas per minggu dapat memiliki efek penyetaraan, karena peserta pasar yang ada di banyak situs yang mungkin dapat mempelajari lebih dari 5 topik yang setara menggunakan 3 PC akan dibatasi hingga 5. |
| (Juga dilaporkan pada kuartal sebelumnya) Kegunaan untuk berbagai jenis pemangku kepentingan |
Kekhawatiran tentang nilai yang dihasilkan dan distribusi nilai tersebut untuk situs bergantung pada tingkat traffic atau seberapa khusus kontennya. | Kami menyadari bahwa situs khusus lebih cenderung berkontribusi pada topik yang lebih terperinci daripada domain minat umum. Namun, tidak semua situs khusus memberikan topik yang bernilai secara komersial. Selain itu, dinamika ini mencerminkan status quo dan sepenuhnya independen dari akhir dukungan untuk 3PC di Chrome. Selain itu, dalam lingkungan saat ini, beberapa situs memberikan lebih banyak nilai daripada situs lainnya dalam sistem relevansi iklan berbasis 3PC. Selain itu, topik di antara situs khusus dapat saling menguntungkan karena berbagai pengiklan dapat menjalankan kampanye di berbagai kumpulan topik dan logika bidding dapat mengamati nilai di berbagai topik. |
| Nama Host vs URL Lengkap | Apakah klasifikasi berdasarkan nama host situs cukup efektif dan apakah hal ini mengurangi risiko privasi dibandingkan dengan URL lengkap? | Kami mempertimbangkan penggunaan URL informasi atau judul halaman selain nama host, dan memutuskan bahwa potensi manfaatnya akan lebih kecil daripada risiko terhadap privasi dan keamanan pengguna. Contoh risiko privasi pengguna mencakup klasifikasi informasi sensitif yang disertakan dalam URL atau judul halaman ke dalam topik pengguna. |
| Topik sebagai Sinyal | Minta panduan tentang cara menggabungkan Topics dengan sinyal lain, dan sinyal lain yang dapat berguna. | Solusi teknologi iklan dapat memberikan hasil terbaik dengan menggabungkan semua alat yang tersedia, seperti machine learning dan sinyal yang menjaga privasi dari API yang menjaga privasi, bersama dengan data kontekstual, data materi iklan, dan data pihak pertama. Panduan lebih lanjut tentang hal ini tersedia di sini. |
Protected Audience API (sebelumnya FLEDGE)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Menguji Volume Traffic | Penguji melaporkan volume respons bid yang rendah untuk lelang PA API. | 1. Kepadatan bid berkorelasi dengan partisipasi ekosistem di PA API, yang kami perkirakan akan terus meningkat sepanjang tahun 2024 dan seterusnya. Pada akhirnya, pengiklan, agensi, dan penyedia teknologi merekalah yang menentukan cara mengalokasikan anggaran kampanye. Kami memperkirakan beberapa peserta ekosistem mungkin menunda investasi mereka dalam berbagai solusi "tanpa cookie" termasuk PA API hingga setelah 3PCD. Pada saat itu, kami memperkirakan mereka dapat meningkatkan alokasi anggaran kampanye mereka ke solusi tersebut. 2. Volume permintaan bid dalam lelang PA API dapat terpengaruh oleh (1) karena penayang dan penyedia teknologi iklan mereka dapat memutuskan untuk tidak memulai lelang PA API jika mereka merasa permintaannya rendah. Penerbit dapat menentukan prioritas pembaruan halaman dan partisipasi mereka. Kami memperkirakan penayang mungkin memerlukan waktu untuk menguji dan meningkatkan traffic secara bertahap karena alasan ini. Laporan ini juga menyertakan respons dari Google Ad Manager tentang kontrol penayangnya untuk partisipasi PA API. |
| (Juga dilaporkan pada kuartal sebelumnya) Penipuan / Penyalahgunaan |
Bagaimana ekosistem dapat mengurangi risiko dan menghentikan pihak tidak bertanggung jawab atau pembeli agar tidak memosisikan diri mereka sebagai audiens yang diinginkan? | Mekanisme pelaporan iklan PA API mempertahankan informasi yang digunakan untuk membedakan traffic manusia dari traffic bot saat ini. Selain itu, teknik berbasis domain saat ini untuk menyertakan atau mengecualikan domain dapat digunakan di PA API. Hal ini dijelaskan secara lebih mendetail dalam respons kami terhadap laporan IAB Tech Lab tentang Privacy Sandbox. |
| Batasan Asal yang Sama pada URL logika bidding dan pemilik IG | Dengan persyaratan origin yang sama, endpoint untuk pemilik IG akan dipaksa untuk melalui load balancer yang sama, yang dapat menyebabkan pengalihan ditolak. | Persyaratan origin yang sama untuk pemuatan skrip adalah perlindungan keamanan yang penting. Ada beberapa detail tentang solusi yang diusulkan di sini yang menyeimbangkan masukan ekosistem dan pertimbangan lainnya di sini. |
| Lelang Pribadi Multi-Slot | Ada banyak ruang untuk mengizinkan Lelang Pribadi Multi-Slot dalam batas privasi dengan menggunakan derau dan integrasi yang lebih ketat dengan praktik iklan saat ini. | Kami mempertimbangkan masukan ini dan mengevaluasi permintaan untuk lelang multi-tag dengan mempertimbangkan peningkatan kompleksitas dan risiko privasi yang terkait dengan fitur ini. Kami membahas masalah ini lebih lanjut selama panggilan Grup Komunitas Inkubator Web PA API (WICG) di sini. |
| Penjual Tingkat Teratas | Struktur PA API saat ini memberikan lebih banyak data dan pemahaman tentang nilai relatif tayangan kepada penjual tingkat teratas dibandingkan dengan penayang atau penjual komponen. | Dalam lelang multi-penjual, setiap penjual akan memiliki bid terbaik. Selain itu, kami telah mempelajari dari ekosistem bahwa penayang mungkin ingin mempertimbangkan permintaan yang dijual langsung di samping bid terbaik dari setiap penjual yang bekerja sama dengan mereka. Meninjau semua peluang monetisasi potensial ini diperlukan untuk menentukan iklan mana yang akan ditayangkan. Situasi ini, yang mengharuskan beberapa aktor melihat kumpulan opsi lengkap untuk memilih iklan yang akan ditayangkan, sudah ada sebelum PA API. PA API berupaya mendukung lelang multi-penjual dan keinginan penayang untuk mempertimbangkan bid terbaik setiap penjual di samping kampanye iklan yang dijual langsung, jika berlaku. Artinya, harus ada mekanisme untuk memilih di antara peluang monetisasi tersebut seperti yang ada saat ini. Kami tidak yakin bahwa browser harus memilih iklan mana yang akan ditayangkan. Dengan demikian, konsep penjual tingkat teratas diperlukan untuk memilih iklan pemenang dari banyak kemungkinan. Logika penjual tingkat teratas tersebut harus dapat mempertimbangkan bid terbaik dari setiap penjual yang dipilih penayang sebagai partner kerja sama. Selain itu, logika penjual tersebut dapat memilih untuk memberikan informasi tentang kampanye yang dijual langsung oleh penayang jika informasi tersebut tersedia. Semua informasi ini dapat dipertimbangkan dalam logika pemilihan iklan tingkat teratas. Artinya, logika tingkat atas melihat bid terbaik dari lelang PA API dan, jika berlaku, opsi iklan yang dijual langsung dari penayang untuk menentukan pemenang. Google Ad Manager menjelaskan penerapan PA API sebagai penjual tingkat atas dalam laporan ini dengan tema "Akses ke Informasi". |
| Pemisahan Iklan Kompetitif | Meminta pemisahan iklan kompetitif, seperti mencegah iklan dari merek yang bersaing muncul berdampingan. | Kami tidak mengetahui cara untuk memastikan pemisahan kompetitif dalam ekosistem periklanan digital terprogram, dengan bidding, dan multi-penjual saat ini. Namun, PA API memungkinkan penjual mengambil sinyal real-time tambahan berdasarkan kombinasi renderURL dan nama host (yang mewakili domain penayang) yang dapat digunakan selama scoreAd() saat menilai materi iklan. Hal ini dapat digunakan oleh penjual untuk mencegah iklan dari merek yang bersaing muncul berdampingan, dengan asumsi penayang ingin menerapkan aturan ini. |
| Informasi Terbatas | PA API mengurangi informasi yang tersedia untuk penayang seperti nilai iklan, nama pembeli komponen, nama pengiklan, URL halaman landing, ukuran materi iklan, waktu respons, dan rasio bid serta bid yang kalah. | Kami telah mengusulkan beberapa solusi potensial di sini dan menerima masukan tambahan dari ekosistem. |
| Pelaporan Tingkat Peristiwa | Penayang tidak dapat mendapatkan informasi yang memadai tentang iklan yang ditayangkan setelah penghentian PA API pelaporan tingkat peristiwa. | Kami menyadari berbagai kasus penggunaan pelaporan yang harus terus kami dukung saat pelaporan tingkat peristiwa dihentikan. Itulah sebabnya kami menargetkan tanggal penghentian pelaporan tingkat peristiwa tidak lebih awal dari tahun 2026. Selama waktu antara sekarang dan nanti, kami mengundang partisipasi aktif saat kami berinteraksi dengan ekosistem di jalur yang berkelanjutan ke depan, yang dapat mencakup ide-ide baru untuk mendapatkan informasi dengan cara yang menjaga privasi. |
| Beberapa SSP | Nilai tambah dari memiliki beberapa SSP akan terlalu rendah bagi penayang. | Kami tidak yakin bahwa hal ini benar dan akan menerima masukan tambahan dari ekosistem untuk memahami alasan pernyataan ini. |
| Aktivitas Seleksi | Aktivitas kurasi tidak dapat dilakukan dengan PA API. | Kami telah menerima masukan tentang kemampuan penjual untuk menggunakan PA API guna memberikan informasi audiens mereka kepada pembeli di seluruh web (alias ekstensi audiens). Kami yakin hal ini dapat dilakukan saat ini, menggunakan fungsi delegasi PA bersama dengan perjanjian bisnis. Pada saat yang sama, kami secara aktif mempertimbangkan apakah dan bagaimana kami dapat mengakomodasi jenis kasus penggunaan ini dengan lebih baik. |
| Pilihan Tidak Ikut Pembeli | Penonaktifan default pembeli kemungkinan akan menyebabkan hasil yang lebih rendah untuk lelang komponen. | Baik menentukan lelang PA penjual tunggal maupun multi-penjual, penjual harus mencantumkan pembeli secara eksplisit di kolom interestGroupBuyers dari AuctionConfig. Hal ini didasarkan pada masukan ekosistem bahwa penjual memiliki perjanjian kontrak dengan beberapa pembeli, tetapi tidak dengan pembeli lainnya, sehingga memerlukan kontrol eksplisit atas pembeli yang akan disertakan dalam lelang. Kami menyambut diskusi lebih lanjut di GitHub. |
| Adsize | Tidak dapat melakukan prafilter berdasarkan adsize dan adSlotSize. | Kami sedang berupaya menambahkan kemampuan ini, dan detail selengkapnya tersedia di sini. |
| Dukungan untuk penargetan IG negatif | API untuk mendukung penargetan IG negatif: menampilkan iklan hanya jika pengguna bukan anggota IG. | Masalah GitHub ini mengusulkan cara alternatif untuk menerapkan penargetan negatif, yaitu browser langsung memberi tahu server iklan aturan penargetan negatif yang harus berlaku untuk permintaan iklan tertentu. Meskipun ini tampak seperti pendekatan yang menarik, semua versi ide ini yang telah kami selidiki ternyata memungkinkan server mengidentifikasi pengguna secara unik. |
| Digital Services Act | Bagaimana cara penayang menggunakan Frame Pagar, tetapi juga mencegah rendering respons yang berisi informasi yang tunduk pada Digital Services Act? | Seperti halnya teknologi baru lainnya, setiap perusahaan bertanggung jawab untuk memastikan bahwa penggunaan Privacy Sandbox-nya mematuhi hukum; Google tidak dapat memberikan saran hukum kepada pihak lain. Untuk setiap API, kami telah memublikasikan dokumentasi teknis yang luas, yang akan memberikan dasar untuk membuat penilaian hukum yang diperlukan. Bingkai Pagar tidak diperlukan untuk digunakan di PA API sebelum tahun 2026, sehingga memberikan waktu tambahan bagi pemangku kepentingan untuk memastikan bahwa penggunaan teknologi ini oleh mereka mematuhi semua legislasi yang relevan. |
| Dokumentasi | Apakah updateAdInterestGroups() bersifat sementara? | Kami belum mengumumkan rencana apa pun untuk menghentikan penggunaan updateAdInterestGroup. Di masa mendatang, kami dapat menerapkan perlindungan privasi serupa seperti yang telah kami bicarakan secara publik untuk mekanisme update IG lainnya, misalnya menggunakan alamat IP juga proxy dan menambahkan beberapa penundaan sebelum update terjadi. |
| Dukungan kepemilikan logika dan metadata sisi beli untuk non-DSP | Meminta cara untuk bertindak sebagai proxy untuk DSP. | Kami mengetahui masukan ini dari segmen non-DSP dan sedang mempertimbangkan permintaan ini. Kami menerima masukan tambahan dari ekosistem. |
| Pelaporan | Permintaan untuk menambahkan fitur pengendali kustom untuk bucket / nilai sinyal dalam pelaporan Agregasi Pribadi. | Kami mengetahuinya dan permintaan fitur ini ada dalam antrean kami untuk penemuan lebih lanjut. Kami menerima masukan tambahan dari ekosistem di sini. |
| Dokumentasi | Apakah ada link yang dapat digunakan untuk melihat semua header respons yang perlu ditetapkan oleh pengiklan dan domain pemilik (yang didelegasikan)? | Kami berencana memperbarui dokumentasi untuk mengklarifikasi hal ini dan menerima masukan tambahan dari ekosistem. |
| Bidding Multi-menara | Minta penjelasan tentang alur kerja (pelatihan dan inferensi) melalui diagram arsitektur / blok tentang cara pendekatan multi-menara dibayangkan dalam konteks PA API. | Terima kasih atas masukannya. Kami memiliki beberapa presentasi tentang subjek yang akan kami gunakan untuk membuat dokumentasi tambahan. |
| Penargetan Negatif | Kemampuan Privacy Sandbox untuk melindungi audiens sensitif dan anak di bawah umur dari iklan yang tidak pantas, misalnya perjudian. | PA API tidak mempertimbangkan konten iklan yang ditampilkan. Hal ini berada dalam kontrol developer teknologi iklan yang menggunakan PA. Secara umum, penayang dan penyedia teknologi iklannya dapat memblokir materi iklan dalam lelang Protected Audience menggunakan informasi kontekstual dari halaman serta kumpulan aturan penayang. Hal ini mencerminkan pemahaman kami tentang pendekatan ekosistem terhadap tantangan ini saat ini. Bagi pembeli, fungsi penargetan IG negatif juga dapat berguna untuk beberapa kasus penggunaan kepatuhan. |
| Desain API | Google menolak dan ingin teknologi iklan menggunakan fungsi bidding Universal sehingga meningkatkan latensi, bukan biddingLogicURL yang berbeda di IG yang berbeda yang diizinkan. | Selama diskusi tentang latensi lelang, kami telah menyoroti bahwa menggunakan kembali skrip yang sama di semua IG pembeli akan membuat bidding pembeli tersebut berjalan lebih cepat. Hal ini dijelaskan secara lebih mendetail di sini, bersama dengan rekomendasi kami lainnya untuk meningkatkan latensi lelang PA API. |
| Pemasaran Berbasis Akun | PA API bukan API bersih untuk kasus penggunaan pemasaran berbasis akun. | Kami menerima masukan dari ekosistem tentang kasus penggunaan tertentu yang mereka yakini tidak mungkin dan akan mendorong peserta ekosistem untuk melanjutkan diskusi ini melalui repositori GitHub publik atau panggilan mingguan kami. |
| Pengujian A/B | Saat dikonfigurasi di GAM untuk penayang, PA API saat ini harus diaktifkan untuk semua inventaris atau tidak sama sekali. Hal ini membatasi kemampuan penayang untuk menjalankan pengujian A/B yang efektif. | Respons yang diberikan oleh Google Ad Manager: Kontrol PA API dalam Google Ad Manager (GAM) memengaruhi kemampuan GAM untuk menggunakan API, asalkan API tersebut tersedia untuk digunakan. Oleh karena itu, penayang dapat menjalankan pengujian A/B menggunakan fungsi kebijakan izin Chrome untuk menonaktifkan penggunaan API pada sebagian traffic yang akan digunakan sebagai grup kontrol untuk pengujian A/B. |
| Machine Learning | Penerbit memerlukan kontrol yang lebih besar atas penggunaan machine learning yang diusulkan GAM. | Respons yang diberikan oleh Google Ad Manager: Pada Januari 2024, kami meluncurkan kontrol yang menawarkan kemampuan kepada penayang untuk menonaktifkan throttler machine learning kami, dan mengaktifkan lelang PA API dengan penjual non-Google di semua traffic mereka. Detail selengkapnya tentang kontrol ini dapat ditemukan di pusat bantuan kami. |
| (Juga dilaporkan pada kuartal sebelumnya) Lelang tingkat teratas |
Kemampuan untuk menggunakan server iklan penayang Google tanpa juga memberi GAM kontrol atas lelang PA API tingkat teratas. | Respons yang diberikan oleh Google Ad Manager: Untuk alasan yang dijelaskan dalam laporan Kuartal 3 2023 Google, rencana GAM untuk integrasi PA API-nya tidak mencakup dukungan untuk penayang yang menggunakan GAM sebagai server iklan penayang mereka tanpa kontrol atas lelang tingkat teratas. |
| Akses ke Informasi | GAM memiliki akses ke informasi berharga dari pesaing, termasuk harga lelang kontekstual, sinyal yang diberikan oleh pembeli ke SSP untuk lelang PA API, dan parameter konfigurasi dari SSP. | Respons yang diberikan oleh Google Ad Manager: Kami telah mempertahankan fokus yang kuat pada keadilan lelang selama bertahun-tahun, termasuk janji kami bahwa tidak ada harga dari sumber iklan tanpa jaminan penayang, termasuk harga item baris tanpa jaminan, yang akan dibagikan kepada pembeli lain sebelum mereka mengajukan bid dalam lelang, yang kemudian kami tegaskan kembali dalam komitmen kami kepada French Competition Authority. Untuk lelang PA API, kami bermaksud menepati janji kami dan tidak membagikan bid peserta lelang kepada peserta lelang lainnya sebelum lelang selesai di lelang multi-penjual. Untuk memperjelas, kami tidak akan membagikan harga lelang kontekstual dengan lelang komponen apa pun, termasuk lelang kami sendiri, seperti yang dijelaskan dalam pembaruan ini. Selain itu, kami tidak menggunakan informasi tentang konfigurasi lelang komponen, termasuk sinyal yang diberikan oleh pembeli ke SSP, sebagai bagian dari lelang kami sendiri. Bahkan, kami akan menyambut perubahan pada PA API yang memungkinkan penjual komponen menentukan konfigurasi lelang komponen mereka dengan cara yang di-obfuscate dari penjual tingkat teratas. |
| Lelang Komponen | Sebagai lelang tingkat teratas, GAM akan mengontrol SSP mana yang menjalankan lelang komponen untuk setiap peluang iklan. | Respons yang diberikan oleh Google Ad Manager: Sebagai server iklan penayang, GAM menawarkan API ringan untuk SSP yang mungkin digunakan penayang untuk menentukan konfigurasi lelang komponennya melalui API Tag Penayang Google (GPT). Detail selengkapnya dapat ditemukan di sini. Jika SSP menyediakan konfigurasi lelang komponen melalui API ini, SSP tersebut akan disertakan dalam daftar lelang komponen untuk peluang iklan tersebut. GAM tidak memberlakukan batasan apa pun pada lelang komponen yang disertakan. Setiap SSP yang ingin menjalankan lelang komponen akan dapat melakukannya, asalkan penayang telah mengizinkan mereka untuk menjalankan kode yang diperlukan di halaman penayang. |
| Lelang Komponen | GAM dapat menerapkan nilai minimum tertentu dan tidak diungkapkan ke setiap bid pemenang lelang komponen. | Respons yang diberikan oleh Google Ad Manager: GAM telah mempertahankan fokus yang kuat pada keadilan lelang selama bertahun-tahun. Sebagai bagian dari upaya untuk mempertahankan lelang yang adil dan transparan, kami tidak mendukung harga minimum yang hanya berlaku untuk segmen permintaan tertentu. Hal ini merupakan prinsip yang konsisten dalam produk kami dan akan terus berlaku untuk lelang PA API. |
| Server Iklan Pihak Ketiga | Server iklan pihak ketiga tidak akan memiliki akses ke partisipasi Google dalam lelang tingkat yang lebih tinggi, sehingga membatasi kemampuannya untuk mendapatkan manfaat dari permintaan SSP Google dalam konteks PA API. | Respons yang diberikan oleh Google Ad Manager: Saat ini, GAM mendukung pengujian PA API dengan beberapa penjual di GAM melalui API yang dijelaskan di sini. Partisipasi GAM sebagai lelang komponen dalam lelang tingkat teratas lainnya saat ini tidak didukung. |
| (Juga dilaporkan pada kuartal sebelumnya) Performa Lelang PA API |
Laporan dari penguji bahwa lelang PA API memiliki latensi tinggi. | Kami telah mendengar kekhawatiran tentang latensi dan ini adalah salah satu alasan kami mengembangkan sejumlah fitur sebagai bagian dari PA API yang akan memungkinkan SSP menetapkan batas pada latensi DSP serta melakukan peningkatan yang dapat mengurangi latensi. Baru-baru ini kami memperbarui panduan praktik terbaik latensi yang menyertakan informasi selengkapnya tentang cara memanfaatkan fitur ini. Kami juga terus mengembangkan peningkatan latensi baru, beberapa di antaranya dapat dilihat di sini. |
| (Juga dilaporkan pada kuartal sebelumnya) Rendering Video |
Dukungan untuk rendering video menggunakan PA API dan Fenced Frames. | Pada bulan Januari, kami memublikasikan demo tentang cara kerja video in-stream dalam lelang PA, dengan detail tambahan tentang pendekatan alternatif. Kami juga melihat pemain ekosistem mulai mengusulkan cara kerja rendering video untuk partner yang berintegrasi dengan mereka, seperti usulan GAM tentang konstruksi renderURL yang kompatibel dengan video atau proses E2E lengkap. Selain itu, kami mendengarkan masukan ekosistem tentang perubahan yang dapat kami lakukan untuk meningkatkan adopsi, dan salah satu perubahan tersebut dijelaskan di GitHub. Kami tetap aktif berinteraksi dengan ekosistem untuk mengidentifikasi kendala lain terkait adopsi yang mungkin kami hadapi dan mengatasinya secara tepat waktu. |
| (Juga dilaporkan pada kuartal sebelumnya) Kebijakan Penanganan Data |
Apa kebijakan penanganan data untuk IGs / PA API? | Dalam desain PA API, semua data yang disimpan di IG, atau tentang orang-orang di IG tertentu, (i) tetap berada di perangkat atau (ii) diproses di Layanan Bidding dan Lelang (B&A) yang berjalan di dalam Trusted Execution Environment (TEE). Dalam kedua kasus tersebut, data tidak dapat dibaca oleh pihak lain, atau digunakan dengan cara apa pun selain untuk membuat bid dalam lelang. Beberapa peningkatan privasi yang sedang dieksplorasi Chrome memang melibatkan interaksi dengan server k-anonimitas yang dijalankan Google. Interaksi tersebut dirancang dengan cermat untuk menghindari pembagian informasi tentang pengguna, dan dijalankan di TEE untuk memastikan kesetaraan informasi di seluruh ekosistem iklan. Google telah berkomitmen kepada CMA untuk mendesain dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan memberikan preferensi sendiri pada bisnis Google, dan mempertimbangkan dampak terhadap persaingan dalam periklanan digital serta terhadap penayang dan pengiklan. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi kewajiban ini. |
| (Juga dilaporkan pada kuartal sebelumnya) Masa aktif IG |
Meminta untuk memperpanjang masa berlaku IG dari 30 menjadi 90 hari. | Perubahan tersebut memerlukan evaluasi yang cermat, dengan mempertimbangkan manfaat bagi industri dan dampaknya terhadap pengguna Chrome dan pemangku kepentingan lainnya. Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan di sini. |
| (Juga dilaporkan di kuartal sebelumnya) modelingSignals |
Minta kolom baru selain modelingSignals yang hanya dapat mengenkode informasi tampilan dan klik. | Kami telah merespons masukan ini dengan proposal tandingan di sini. Kami secara aktif berinteraksi dengan industri untuk memahami pandangan mereka tentang proposal kami, dan saat ini sedang mempertimbangkan manfaat bagi industri dibandingkan dengan dampaknya terhadap pengguna Chrome dan pemangku kepentingan lainnya. |
| Bit tambahan di reportWin() | Berikan bit tambahan di reportWin() dari batas saat ini 12 sebelum 3PCD. | Saat ini kami sedang mempelajari pendekatan untuk mendukung kasus penggunaan ini. Proses ini memerlukan waktu karena kami juga mencari pendekatan yang dapat membantu memastikan bahwa kami memiliki rencana privasi jangka panjang. |
| Desain Lelang | Meminta satu lelang yang menampilkan URL render dengan skor yang sesuai. | Membagikan beberapa renderURL, dan skornya masing-masing, dari satu lelang PA adalah sesuatu yang kami pertimbangkan, tetapi tidak diterapkan karena masalah privasi. Kami memahami keinginan untuk menghindari menampilkan iklan yang sama beberapa kali kepada pengguna di satu halaman dan menyambut diskusi lebih lanjut di GitHub. |
| reportWin | mencatat kolom arbitrer dalam fungsi reportWin(). | Hal ini sudah terjadi saat ini selama periode pengujian. Setelah Chrome menghentikan dukungan untuk 3PC, versi API forDebuggingOnly akan dimigrasikan untuk mengaktifkan proses debug dengan downsampling, yang ditentukan di sini. |
| Penjual Komponen | Memiliki mekanisme independen untuk menghitung tayangan iklan dan peristiwa lainnya, serta tidak harus bergantung sepenuhnya pada laporan teknologi iklan. | Permintaan fitur ini ada dalam antrean kami untuk penemuan lebih lanjut. Kami tidak akan mengatasi masalah ini selama periode pengujian yang difasilitasi Chrome. |
| Penagihan Biaya per klik | Mengimplementasikan penagihan biaya per klik di PA API. | Kami sedang mempertimbangkan permintaan ini di sini, dan saat ini kami menganggapnya sebagai permintaan saran tentang cara menerapkannya dengan platform API saat ini. |
| browserSignals | Menambahkan incomingBidInSellerCurrency ke spesifikasi browserSignals pelaporan untuk penjual. | Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan di sini. |
| Dukungan kepemilikan logika dan metadata sisi beli untuk non-DSP | Desain API saat ini dapat menyebabkan perubahan signifikan pada kampanye penargetan ulang tingkat produk, yang mengharuskan kampanye bermigrasi ke platform yang berfungsi sebagai DSP dan penyedia DCO. | Kami sedang membahas masalah ini dan menerima masukan tambahan di sini. |
| Dukungan kepemilikan logika dan metadata sisi beli untuk non-DSP | Berikan contoh jika DSP bukan pemilik IG. | Kami memahami bahwa non-bidder ingin menggunakan beberapa fungsi IG, tetapi tidak untuk fungsi lainnya. Kami secara aktif mengevaluasi opsi untuk mengatasi kasus penggunaan ini dan menerima masukan tambahan di sini. |
| Kontrol Waktu Tunggu | Penayang harus dapat menentukan jumlah IG yang dapat berpartisipasi dan waktu tunggu tingkat teratas / waktu tunggu global. | Kami memahami bahwa ada keinginan untuk meningkatkan kontrol waktu tunggu dan visibilitas antara penjual tingkat atas dan komponen, dan kami sedang mempertimbangkan permintaan ini. |
| Multi Ukuran Iklan | Dukungan PA API untuk kasus penggunaan Multi Ukuran Iklan. | Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem. |
| Dokumentasi | Apakah ada daftar atribut IG yang dikenai k-anon? | Kami telah menjawab pertanyaan ini di sini. |
| Proses Debug | Meningkatkan kemampuan proses debug untuk PA API. | Kami menyadari pentingnya alat proses debug yang andal bagi developer yang menggunakan PA API. Kami berkomitmen untuk meningkatkan pengalaman developer dengan mempelajari cara mengintegrasikan pengambilan file .well-known dengan alat developer dengan lebih baik. Sasaran kami adalah memberikan visibilitas dan kemampuan pemecahan masalah yang lebih baik dalam lingkungan pengembangan. Kami membahas masalah ini lebih lanjut di sini dan menerima masukan tambahan. |
| Label | Apakah semua pengguna dalam label perlakuan mode B mengaktifkan Privacy Sandbox API? | Penetapan grup eksperimen Chrome ditentukan secara acak dan tidak bergantung pada setelan Chrome yang dikonfigurasi pengguna. Meskipun API ini mungkin tersedia untuk pengguna dalam grup perlakuan tertentu (misalnya, treatment_1.*), fungsinya dapat diubah atau dinonaktifkan melalui setelan Chrome. Grup control_2 Mode B: Penyertaan dalam grup ini secara inheren menonaktifkan API pengukuran dan relevansi Privacy Sandbox, dan setelan ini tidak dapat diganti oleh pengguna dalam setelan Chrome. |
| Penggunaan API | Apakah panggilan ke reportWin() dan rendering iklan terjadi secara paralel atau satu per satu? | reportWin() dipanggil langsung setelah runAdAuction() selesai. Pada saat yang sama, proses rendering iklan dapat dimulai saat hasil lelang ditempatkan dalam iframe atau Frame Pagar. Setelah reportWin() selesai dieksekusi dan iklan mulai dirender, URL yang diberikan ke sendReportTo() akan diambil. |
| (Juga dilaporkan pada kuartal sebelumnya) Dukungan A/B Testing |
Meminta dukungan untuk pengujian A/B PA API. | Kami sedang membahas permintaan ini di sini dan menerima masukan tambahan. |
| Pembentukan Traffic | Proposal dari Google untuk mengelola pengambilan keputusan yang diperlukan melalui server KV tidak membantu, karena penjual tidak dapat berinteraksi dengan backend mereka, sehingga pembentukan traffic menjadi sulit. | Seperti yang dibahas dalam masalah GitHub, mengungkapkan apakah setiap DSP memiliki IG atau tidak dapat menimbulkan masalah sidik jari pengguna. Kami telah menyarankan alternatif lain dalam masalah ini dan terbuka untuk saran lebih lanjut. |
| Pembentukan Traffic | Mekanisme penyimpanan dalam cache menambahkan lapisan kompleksitas yang signifikan dan mencegah DSP mengetahui bentuk sebenarnya dari traffic yang akan di-bid. | Mekanisme penyimpanan dalam cache hanya ditawarkan sebagai saran. Teknologi Iklan dapat memilih untuk menggunakan saran yang sesuai dengan kasus penggunaannya dan kami menyambut diskusi tambahan di sini. |
| Label | Chrome harus membagikan label sebagai parameter dalam permintaan ke server tepercaya pembeli dan penjual. | Permintaan ini tampaknya wajar karena tampaknya selaras secara luas dengan sasaran penggunaan data IG yang bertanggung jawab. Namun, kami mempertimbangkan permintaan tersebut, yang tunduk pada peninjauan internal, dan akan memberikan info terbaru kepada publik terkait masalah ini seiring diskusi berlangsung. |
| Penggunaan API | Mengklarifikasi definisi eksplisit grup "control_1" dalam dokumen "Panduan CMA tambahan untuk pihak ketiga terkait pengujian". Secara khusus, ada kekhawatiran bahwa perubahan kata-kata mungkin disalahartikan sebagai mewajibkan pengecualian semua Privacy Sandbox API dari control_1. | Kami telah menyampaikan pandangan kami tentang hal ini di rangkaian pesan GitHub ini. Meskipun demikian, kami tidak dapat berbicara atas nama CMA dan sebaiknya Anda menyampaikan masalah apa pun terkait interpretasi panduan pengujian mereka langsung kepada CMA. |
| Penggunaan API | Apakah Chrome akan mengizinkan panggilan joinAdInterestGroup() di halaman kosong saat mengalihkan ke resource lain? | Jika pengguna mengunjungi beberapa situs, pemilik situs dapat mendelegasikan kemampuan untuk memanggil joinAdInterestGroup kepada pihak ketiga. Delegasi ini memungkinkan pihak ketiga membuat IG tanpa perlu menambahkan jenis pengalihan apa pun melalui halaman kosong. Kami menerima masukan tentang alasan spesifik untuk membuat IG di tengah pengalihan, bukan menggunakan mekanisme delegasi yang dimaksudkan. |
| Penggunaan API | Bursa harus dapat menulis IG ke halaman yang dimiliki oleh penayang yang bekerja sama dengan mereka, dan kemudian mereka dapat mendelegasikan izin untuk mengajukan bid pada IG tersebut kepada pembeli atau DSP tertentu. | Kami telah menerima masukan tersebut dan sedang mengevaluasi apakah permintaan tersebut dapat didukung. Kami menerima masukan tambahan dari ekosistem. |
| Penggunaan API | Tidak ada notifikasi kerugian proses debug jika tidak ada yang memenangkan lelang PA API. | Fungsi reportWin dan reportResult Chrome dirancang untuk pelaporan kemenangan tingkat peristiwa dalam sistem Privacy Auction (PA). Jika semua bid ditolak selama lelang PA, fungsi ini tidak akan dipanggil karena tidak ada pemenang yang ditentukan. Update terbaru pada Chrome dapat menjelaskan perbedaan saat URL yang diteruskan ke forDebuggingOnly.reportAdAuctionLoss() tidak muncul di panel Jaringan DevTools. Sebaiknya verifikasi fungsi ini menggunakan build saluran Canary atau Dev Chrome. |
| Penggunaan API | Dapatkah adCost yang ditampilkan dari generateBid bernilai negatif (sudah dibulatkan secara stokastik menjadi 2 byte)? | AdCost adalah biaya klik atau konversi pengiklan yang diteruskan dari generateBid() ke reportWin(). Nilai ini dapat berupa Null atau ganda. Nilai negatif akan diabaikan dan tidak diteruskan. Nilai akan dibulatkan secara stokastik saat diteruskan. |
| Peningkatan API | Dapatkah server Eksekusi Tepercaya dan Terenkripsi digunakan untuk menangani penargetan / kohor / atribusi dan lelang, bukan browser Chrome? | Sebaiknya pelajari komponen dan opsi berbasis TEE di PA API (misalnya server KV dan Layanan B&A) serta komponen berbasis TEE dari Attribution Reporting dan Private Aggregation (misalnya Aggregation Service) yang menjawab pertanyaan ini. |
| Peningkatan API | Dapatkah respons lelang Privacy Sandbox berupa respons bid (seperti bidding header) dan bukan respons iklan (seperti tag iklan)? | Jenis perubahan ini secara mendasar mengubah properti privasi PA API, sehingga bukan sesuatu yang kami pertimbangkan. |
| Kontrol Penayang | Dapatkah penayang memblokir materi iklan PA API di halaman mereka? | Chrome memiliki proposal untuk pemindaian materi iklan real-time yang belum tersedia untuk pengujian. Meskipun belum tersedia, kami mengamati bahwa sebagian besar SSP telah membuat solusi untuk mengaktifkannya. |
| Penggunaan API | Berapa batas ukuran perBuyerSignals? | Dalam bentuk klasiknya, perBuyerSignals tidak memiliki batasan ukuran bawaan dalam Chrome. Batasan utamanya adalah data tetap dapat diserialisasi JSON dan tidak menyebabkan konsumsi memori yang berlebihan. Namun, perlu diperhatikan bahwa perBuyerSignals yang sangat besar dan kompleks dapat berdampak negatif pada performa. Ada metode alternatif untuk meneruskan perBuyerSignals melalui directFromSellerSignalsHeaderAdSlot. Pendekatan ini mengirimkan perBuyerSignals dalam header, dengan batasan ukuran maksimum 10 kb untuk seluruh respons header. Selain itu, setiap server dapat menerapkan batasan ukuran header maksimumnya sendiri. |
| Dokumentasi | Dokumentasi tentang panggilan registerAdBeacon dari dalam generateBid perlu diubah. | Kami memperbarui dokumentasi ini pada 17 Februari. |
| Penggunaan API | Bagaimana cara reportEvent memilih URL beacon yang tepat dari beberapa opsi terdaftar? | Setiap lelang menghasilkan konfigurasi terpisah, yang pada akhirnya menghasilkan peta pelaporan terpisah. Setiap lelang (dan frame yang dihasilkannya) sepenuhnya terpisah satu sama lain, dan tidak berbagi data. Penjelasan "Pelaporan Iklan Frame Pagar" memberikan detail selengkapnya tentang topik ini. |
| UI Chrome | Menambahkan filter di tab "Aplikasi -> "Grup minat" DevTools Chrome, yang memungkinkan pemfilteran menurut pemilik IG (atau mungkin juga menurut nama IG). | Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem. |
| Chrome Headless | Dukungan PA API di Headless Chrome. | Ada beberapa komponen PA API yang terikat dengan Chrome, misalnya panggilan k-anon ke server Google, yang mungkin tidak berfungsi di Chrome Headless "lama". Kami yakin bahwa masalah ini dapat diatasi dengan Chrome Headless versi "baru" yang dirilis di Chrome 112. |
| Penggunaan API | Dalam kasus pelaporan kerugian dengan reportAdAuctionLoss, kami melihat "topLevelWinningBid=0" dalam banyak kasus. Apa interpretasi dari hal ini? | Nilai topLevelWinningBid berasal dari fungsi scoreAd() dalam komponen penjual tingkat atas. Nilai ini berperan dalam menentukan hasil lelang tingkat teratas. Seperti yang dijelaskan, nilai topLevelWinningBid nol atau angka negatif apa pun menunjukkan bahwa iklan yang sesuai tidak memenuhi syarat untuk memenangkan lelang. Mekanisme ini dapat digunakan, misalnya, untuk memfilter iklan yang ditargetkan ke grup minat yang tidak melampaui kandidat yang ditargetkan secara kontekstual. Meskipun topLevelWinningBid bernilai nol dapat menunjukkan bahwa lelang kontekstual telah menang, spesifikasi PA API mengakui bahwa faktor lain dapat berkontribusi pada hasil ini. |
| Mode Pengujian A/B | Klarifikasi tentang pemilihan traffic Mode B dan Mode A serta perintah untuk memilih tidak ikut. | Kriteria penyertaan untuk Mode A dan Mode B sama. Tujuannya adalah untuk memiliki grup yang mewakili traffic Chrome normal selama grup tersebut mendukung API Privacy Sandbox dan metode pemberian label, sehingga beberapa konfigurasi klien tidak kompatibel. Untuk tujuan eksperimen, sebaiknya hanya bandingkan traffic berlabel dengan traffic berlabel lainnya. Pengguna dalam Mode B mengaktifkan fitur Perlindungan Pelacakan sehingga mereka menerima notifikasi tentang fitur tersebut. |
| Peningkatan API | Dapatkah "lifetimeMs" disertakan sebagai properti langsung dalam panggilan joinAdInterestGroup atau mengelolanya sebagai argumen terpisah? | Kami mempertimbangkan dengan cermat masukan dari komunitas pengembangan web terkait fungsi "joinAdInterestGroup" dalam proposal PA API. Poin diskusi utama berfokus pada metode yang optimal untuk mengelola masa aktif IG. Kami mengevaluasi manfaat argumen terpisah untuk parameter "lifetimeMs", karena hal ini mendorong fleksibilitas dan kemampuan adaptasi untuk potensi peningkatan spesifikasi di masa mendatang. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Potensi peningkatan rasio negatif palsu dalam framework PA API karena konflik dengan ID browser entropi rendah. | Tim Chrome secara aktif terlibat dalam peningkatan kualitas framework PA API yang sedang berlangsung. Kami menghargai diskusi terkait potensi rasio negatif palsu yang timbul dari konflik ID browser. Kami mengevaluasi masukan ini dengan cermat dan akan berupaya memastikan bahwa analisis yang diperbarui secara komprehensif mencerminkan semua faktor yang relevan. Komitmen kami adalah untuk solusi yang mencapai hasil privasi yang diinginkan sekaligus mempertahankan akurasi dan keandalan. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Apakah ID browser entropi rendah diperlukan untuk mencegah klien berulang kali mengirimkan permintaan "Gabung" untuk objek yang sama dalam sistem k-anonimitas? | Kami memahami dan menghargai diskusi yang sedang berlangsung terkait penggunaan ID browser dalam penerapan sistem k-anonimitas. Kami memahami kekhawatiran yang muncul terkait potensi implikasi privasi dari ID tersebut. Meskipun implementasi awal kami menggunakan ID entropi rendah sebagai mekanisme anti-penyalahgunaan, kami secara aktif mempelajari teknik alternatif, seperti Token Penghitungan Anonim, yang memprioritaskan privasi pengguna sekaligus menjaga integritas sistem. Kami berkomitmen untuk menemukan solusi yang menyeimbangkan penggunaan data yang bertanggung jawab dengan perlindungan privasi yang andal, dan kami menyambut baik dialog berkelanjutan dengan komunitas riset. Kami membahasnya di sini dan menerima masukan tambahan. |
| Penggunaan API | Apakah AMP (Accelerated Mobile Pages) mendukung PA API. | AMP saat ini tidak mendukung PA API secara native. Kami menerima masukan tambahan dari ekosistem jika dukungan oleh AMP merupakan prioritas tinggi. |
| Peningkatan API | Pertimbangkan untuk menghapus jenis dari pemeriksaan k-anonymity. | Kami mempertimbangkan dengan cermat masukan tentang kemungkinan pengoptimalan struktur permintaan k-anonimitas. Kami memahami saran untuk menggabungkan parameter dan berpotensi menyatukan jenis untuk menyederhanakan proses. Tujuan kami adalah memastikan efisiensi dan pemeliharaan, dan kami mengevaluasi semua opsi saat terus mengembangkan solusi privasi kami. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| UI Chrome | Permintaan mekanisme bagi pengguna yang kurang teknis untuk melihat dan mengelola IG yang mereka ikuti dengan mudah, termasuk potensi kontrol tingkat situs untuk memilih tidak ikut. | Kami menyadari pentingnya menyediakan alat yang mudah digunakan untuk memahami dan mengelola IG. Kami telah mempertimbangkan berbagai metode dengan cermat dan mendapati bahwa mengidentifikasi IG berdasarkan situs tempat mereka bergabung menawarkan keseimbangan terbaik antara kejelasan dan perlindungan privasi. Saat ini, pengelolaan global IG berada dalam setelan Chrome. Kami terus mencari cara untuk meningkatkan pengalaman pengguna di area ini lebih lanjut. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Keamanan API | Apakah PA API rentan terhadap kebocoran privasi melalui interaksi iklan materi iklan, bahkan dalam konteks Frame Berpagar? | Kami menyadari potensi kebocoran informasi melalui interaksi iklan yang canggih. Kami secara aktif menyelidiki interaksi antara Frame Pagar, PA API, dan potensi vektor serangan. Mengurangi risiko privasi adalah prioritas utama, dan kami berkomitmen untuk mengembangkan solusi andal yang menyeimbangkan inovasi dengan perlindungan pengguna. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Latensi | Apakah waktu tunggu default 50 md untuk logika bidding pembeli merupakan nilai yang realistis? | Kami memahami kekhawatiran yang diajukan tentang potensi inkonsistensi antara spesifikasi dan waktu permintaan jaringan untuk logika bidding. Kami secara aktif meninjau spesifikasi untuk memastikan akurasinya dan menyelidiki setelan waktu tunggu default yang optimal untuk menyeimbangkan performa dan kelayakan. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Dokumentasi | Potensi kebocoran pengaturan waktu dalam spesifikasi yang memungkinkan situs menyimpulkan apakah iklan gagal memenuhi nilai minimum k-anonymity, dan potensi implikasinya terhadap pelacakan lintas situs. | Kami menyadari masalah yang diangkat terkait potensi kebocoran waktu. Kami telah mengonfirmasi adanya perbedaan dalam spesifikasi dan mengambil langkah-langkah untuk memastikan bahwa status k-anonimitas iklan ditentukan sebelum lelang untuk mencegah kebocoran tersebut. Kami menanggapi masalah ini dengan serius dan akan memperbarui spesifikasi untuk mencerminkan perubahan ini. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Cara menerapkan daftar yang tidak diizinkan SSP dalam PA API. | Kami menyadari perlunya mekanisme untuk mengelola batasan iklan oleh SSP. Sebaiknya pelajari solusi yang memprioritaskan evaluasi di perangkat dan memanfaatkan metadata iklan yang ada untuk melindungi privasi pengguna sekaligus memungkinkan fleksibilitas. Kami berkomitmen untuk bekerja sama dengan developer guna mengidentifikasi pendekatan yang optimal dalam PA API. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Dapatkah seseorang memberi tahu browsernya untuk berpura-pura melakukan PA API dengan cara yang tidak dapat dideteksi situs? | Kami memahami bahwa, dalam bentuknya saat ini, memilih tidak ikut PA API dapat dideteksi oleh situs. Kami secara aktif mengembangkan fitur seperti Bidding Tambahan dan Penargetan Negatif, beserta rendering Bingkai Pagar, untuk meningkatkan privasi dan berupaya menyediakan opsi tidak ikut yang tidak dapat dideteksi. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Mode Pengujian A/B | Traffic pusat data yang mengaku sebagai perlakuan 1.1. | Tim Chrome telah mengonfirmasi dengan tim GAM bahwa traffic ini kini difilter dari eksperimen. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Efisiensi dan keadilan implementasi interestGroupBuyers di PA API. | Kami memahami diskusi yang sedang berlangsung tentang efisiensi dan keadilan kolom "interestGroupBuyers" dalam lelang PA API. Kami memahami kompromi antara efisiensi, privasi, dan keadilan pasar. Meskipun penjual perlu mengelola hubungan bisnis dengan pembeli, kami sedang mempelajari cara mengoptimalkan proses pencocokan. Hal ini dapat mencakup penyesuaian dinamis berdasarkan data real-time dan model campuran. Kami tetap berkomitmen untuk menemukan solusi yang memprioritaskan privasi pengguna dan mendukung ekosistem iklan yang kompetitif. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| UI Chrome | Potensi masalah memori dan kejelasan UI terkait IG di Chrome. | Kami memahami kekhawatiran yang diajukan terkait tampilan IG di DevTools. Meskipun tampilan saat ini mencerminkan semua peristiwa IG untuk pelacakan historis, kami memahami nilainya dalam memberikan visibilitas yang lebih jelas tentang status IG yang tersimpan saat ini. Kami akan mempelajari pengoptimalan dan potensi peningkatan UI untuk meningkatkan insight developer. Terkait pengelolaan memori, penerapan IG dirancang untuk mencegah kebocoran memori, tetapi kami terus memantau dan mengoptimalkan penggunaan resource. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Dokumentasi | Poster asli mengalami error saat mencoba menggunakan ukuran iklan bernama langsung dalam kolom "sizeGroup" dari fungsi "joinAdInterestGroup". Mereka ingin tahu apakah ini adalah perilaku yang diinginkan. | Kami memahami nilai penyederhanaan konfigurasi iklan dalam fungsi "joinAdInterestGroup". Kami sedang berupaya secara aktif untuk mengatasi batasan ini dan berencana mengaktifkan fungsi ini di update mendatang. Peningkatan ini sejalan dengan komitmen kami untuk menyediakan alat yang fleksibel dan efisien bagi developer untuk pengelolaan iklan. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Label Pengujian yang difasilitasi Chrome | Minta untuk memiliki data langsung tentang Mode A vs B dan label yang tepat di sendReportTo sehingga kami dapat melacak eksperimen secara konsisten. | Kami sedang membahas permintaan ini di sini dan menerima masukan tambahan |
| Dokumentasi | Apakah nama domain penjual disertakan dalam permintaan yang dibuat ke server tepercaya penjual untuk tujuan validasi? | Kami menyadari bahwa parameter nama host awalnya dihilangkan dari dokumentasi Protected Audience KV Server API. Kami ingin meyakinkan developer bahwa nama domain penjual otomatis disertakan dalam permintaan ke server tepercaya penjual. Fungsi ini sangat penting untuk proses validasi iklan yang andal. Kami telah memperbarui dokumentasi untuk mengatasi kelalaian ini dan akan terus memprioritaskan kejelasan dan transparansi bagi komunitas developer. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Kemungkinan metode untuk menyertakan nama IG dalam panggilan pelacakan tayangan iklan untuk tujuan pelaporan. | Kami berkomitmen untuk menyeimbangkan kebutuhan akan mekanisme pelaporan yang andal dengan prinsip dasar privasi pengguna. Penyertaan nama IG dalam pelacakan tayangan iklan tunduk pada pengamanan k-anonimitas yang dirancang untuk mencegah identifikasi individu. Kami akan terus mempelajari solusi pelaporan yang inovatif dalam batasan privasi ini. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Fitur API | Minta server tepercaya pembeli untuk menerima header HTTP Client Hints. | Kami melacak permintaan fitur ini di sini. |
| Penggunaan API | Apakah file delegasi harus mewajibkan header "Access-Control-Allow-Origin" untuk dimuat, mengingat file tersebut menentukan perilaku keanggotaan IG untuk browser? | Kami berkomitmen untuk menyelaraskan dengan praktik terbaik keamanan web. Persyaratan header "Access-Control-Allow-Origin" untuk file delegasi memastikan konsistensi dengan prinsip CORS dan mencegah eksposur informasi sensitif yang tidak disengaja. Kami sedang mempelajari cara mengoptimalkan proses ini sekaligus mempertahankan postur keamanan yang kuat. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Mengaktifkan server iklan untuk mempersonalisasi materi iklan dalam framework PA API. | Kami menyadari peran server iklan dalam personalisasi materi iklan. Kami secara aktif mempelajari solusi untuk mendukung server iklan dalam PA API, seperti model 'IG gabungan' tempat logika pemilihan materi iklan dan bidding dapat digabungkan. Tujuan kami adalah mencapai keseimbangan antara mengaktifkan kemampuan materi iklan yang andal dan menjaga privasi pengguna. Kami menantikan kolaborasi dan masukan lebih lanjut terkait pengembangan API untuk mengakomodasi kebutuhan semua pemangku kepentingan di sini. |
| Masalah Privasi | Ketersediaan ID alternatif (mis., RampID, ID5) dalam permintaan bid kontekstual dapat merusak sasaran privasi PA API dengan memfasilitasi pengumpulan data lintas situs. | Kami menyadari potensi ketegangan antara ID lintas situs dan tujuan privasi PA API. Meskipun penayang dapat memilih untuk membagikan ID tersebut, desain PA API pada dasarnya bertujuan untuk memisahkan pemilihan iklan dari kebutuhan pelacakan lintas situs. Kami berkomitmen untuk mengembangkan ekosistem periklanan yang berfokus pada privasi dan mendorong developer untuk memprioritaskan pendekatan PA API. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Menyimpan ke cache | Apakah ada cara untuk mencegah penggunaan ulang skrip bidding di beberapa lelang? | Kami memahami perilaku penyimpanan dalam cache yang diamati dari skrip bidding dalam framework PA API. Meskipun mekanisme caching HTTP standar didukung, potensi penggunaan kembali skrip di seluruh lelang ada karena perilaku penangguhan perangkat dan desain eksekutor bidding. Tim sedang menyelidiki solusi untuk memberi pembeli kontrol yang lebih besar atas penyimpanan dalam cache skrip guna mengelola strategi bidding mereka secara efektif. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Memusatkan pelaporan aktivitas bidding di semua IG untuk DSP, sekaligus menghormati privasi pengguna. | Kami memprioritaskan privasi pengguna saat mendesain PA API. Meskipun pelaporan langsung untuk setiap peristiwa bidding tidak memungkinkan karena risiko pelacakan lintas situs, kami menawarkan mekanisme seperti Penyimpanan Bersama dan Agregasi Pribadi. Hal ini memungkinkan DSP mendapatkan insight gabungan tentang aktivitas bidding, dengan cara yang menjaga privasi pengguna. |
| Penggunaan API | Pengambilan dari sendReportTo() di reportResult() hanya terjadi 94% dari waktu yang relatif untuk mendapatkan pengambilan yang terdaftar dengan forDebuggingOnly.reportAdAuctionWin(). | Meskipun mungkin tidak memiliki pengaturan waktu yang sama, kedua URL tersebut dapat diambil secara bersamaan. Dalam beberapa kasus, worklet penjual komponen dihapus dan perlu dimuat ulang untuk menjalankan fungsi reportResult(). Namun, waktu yang diperlukan untuk mengambil logika penskoran atau waktu untuk memuat ulang worklet tidak memengaruhi waktu tunggu 50 md untuk reportResult(). Perhatikan bahwa Chrome akan menggunakan header penyimpanan dalam cache untuk menentukan perilaku pengambilannya jika worklet perlu dimuat ulang. Anda dapat mempelajari lebih lanjut fase lelang PA di sini. |
| K-anonymity | Meminta konfirmasi bahwa nama interestGroup tidak memengaruhi k-anonymity penayangan iklan. | Agar materi iklan dianggap k-anonim, tuple URL pemilik IG, URL skrip bidding, URL materi iklan, dan ukuran iklan harus memenuhi nilai minimum yang ditentukan (k) selama jangka waktu sebelumnya (w). Status k-anonymity diperbarui secara berkala (p). |
| UI Chrome | Proposal untuk menyediakan jenis "visibilitas internal" yang ditawarkan oleh banyak framework MVC, ORM, dll. Misalnya, mulai dengan logging sederhana peristiwa internal yang dipilih ke panel baru di bagian Dev Tools --> Application --> Application | Kami sedang membahas proposal ini di sini dan menerima masukan tambahan. |
| UI Chrome | Penggabungan IG Dev Tools tidak menampilkan elemen terkait prioritas. | Kami telah mengatasi masalah ini di sini. |
| Peningkatan API | Sebaiknya izinkan server iklan materi iklan untuk melacak peristiwanya sendiri. Dapatkah daftar domain pelacakan yang diizinkan dikonfigurasi? | Kami telah membagikan proposal di sini dan menerima masukan tambahan dari ekosistem. |
| Permintaan Fitur API | Dapatkah PA API diperluas untuk mendukung transaksi media non-RTB dan mempertahankan kasus penggunaan penting seperti penayangan iklan dan DCO? | Kami sedang membahas masalah ini di sini dan menerima masukan tambahan. |
| Waktu tunggu Lelang Penayang | Penayang memerlukan kontrol atas durasi lelang untuk mencegah hilangnya tayangan, terutama dalam penyiapan bidding header saat iklan dipilih secara berurutan. | Kami memahami pentingnya memberi penayang kontrol terperinci atas waktu tunggu lelang iklan. Kami secara aktif mempelajari cara menerapkan mekanisme waktu tunggu lelang global, yang mungkin berada dalam objek "auctionConfig", sambil mempertimbangkan kasus ekstrem dengan cermat. Fitur ini bertujuan untuk mengoptimalkan rasio pengisian tayangan iklan bagi penayang, dan kami akan terus berkolaborasi dengan komunitas untuk menemukan solusi terbaik. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan. |
| Peningkatan API | Desain IG saat ini di PA API menyebabkan ukuran metadata yang besar karena renderURL yang panjang. Penguji ingin menemukan cara untuk mengompresi URL ini agar lebih efisien. | Kami menyadari pentingnya mengoptimalkan ukuran metadata IG, terutama untuk lelang iklan yang sensitif terhadap efisiensi. Kami yakin solusi berbasis template untuk mengompresi renderURL menawarkan potensi yang signifikan. Kami akan mengevaluasi desain template yang diusulkan dengan cermat dan memastikan bahwa setiap solusi yang diterapkan menyertakan mekanisme pencegahan penyalahgunaan yang andal untuk mempertahankan stabilitas browser. Berkolaborasi dengan komunitas standar web untuk mengembangkan pendekatan yang optimal, dengan mempertimbangkan hal-hal ini, tetap menjadi prioritas. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Penguji yang menangani format iklan native ingin mengoptimalkan proses lelang Privacy Sandbox dengan mengambil beberapa hasil iklan dalam satu panggilan untuk mengurangi beban jaringan dan meningkatkan kecepatan rendering iklan. | Kami memahami masalah performa yang muncul untuk rendering iklan native di Privacy Sandbox. Kami berkomitmen untuk menemukan keseimbangan antara efisiensi dan perlindungan privasi pengguna yang kuat. Meskipun menampilkan beberapa iklan dengan skor penuh akan membahayakan privasi, kami secara aktif mencari cara untuk mengoptimalkan proses lelang. Kami berkomitmen untuk meningkatkan dukungan PA API untuk format iklan native dan menyelidiki mekanisme alternatif untuk meningkatkan efisiensi dalam batasan privasi yang kuat dari Privacy Sandbox. Kami sedang membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Fleksibilitas dalam cara skor dan pengurutan bid iklan dalam Privacy Sandbox, terutama untuk mewakili tingkat prioritas atau aturan marketplace pribadi. | Kami memahami perlunya kontrol terperinci atas penskoran dan pengurutan iklan dalam Privacy Sandbox, terutama dalam skenario bidding yang kompleks. Kami memahami solusi yang diusulkan menggunakan tuple dan fungsi matematika untuk mencapai penskoran multidimensi tanpa mengorbankan privasi pengguna. Meskipun pendekatan ini dapat menambah kompleksitas bagi developer, pendekatan ini menawarkan ekspresi yang diperlukan. Kami berkomitmen untuk mempelajari cara menyederhanakan proses ini, mungkin melalui fungsi atau panduan bantuan, untuk memastikan penggunaan fitur Privacy Sandbox yang optimal untuk logika lelang lanjutan. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| reportEvent() | Menambahkan peristiwa yang dicadangkan baru (mungkin beacon otomatis) yang diaktifkan oleh browser setelah frame dengan materi iklan diinisialisasi. | Kami sedang membahas permintaan ini di sini dan menerima masukan tambahan. |
| adCost | Mengizinkan pengelompokan adCost. | Setiap nilai biaya adalah peluang untuk mengirim informasi dalam jumlah terbatas dari lelang. Mengizinkan seluruh daftar N biaya tersebut akan cukup untuk mengirim seluruh ID pengguna, yang akan memungkinkan pelacakan lintas situs. Kami membahasnya di sini dan menerima masukan tambahan. |
| resolveToConfig | Apakah resolveToConfig harus diwarisi dari tingkat teratas dan ditampilkan di browserSignals? | Kami sedang membahas permintaan ini di sini dan menerima masukan tambahan. |
| Alat yang Lebih Baik | Apakah ada sesuatu yang mirip dengan chrome://topics-internals, tetapi untuk PA API? | Tidak ada yang sama persis. Namun, ada alat developer yang luas untuk PA API. |
| Label | Dapatkah Chrome menggunakan label untuk mengidentifikasi 20% populasi k-anon? | Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem. |
| Dokumentasi | Apakah worklet lelang Privacy Sandbox akan menjadi jenis worklet standar? | Karena persyaratan privasi dan keamanan yang unik, worklet ini berbeda secara signifikan dengan jenis worklet browser standar, sehingga kami tidak mengantisipasi bahwa worklet ini akan segera menjadi jenis worklet standar dalam spesifikasi HTML. Kami berkomitmen untuk meningkatkan kualitas referensi developer kami dengan penjelasan yang jelas tentang lingkungan implementasi dan eksekusi worklet lelang, sehingga informasi ini lebih mudah diakses oleh peserta Privacy Sandbox. Kami telah membahasnya lebih lanjut di sini. |
| Server Nilai Kunci (KV) Bring-Your-Own-Server (BYOS) | Pihak mungkin dapat mempelajari beberapa IG (dari pemilik yang sama) yang dihubungkan oleh pengguna melalui kueri layanan KV dalam penyiapan Layanan KV BYOS. | Hal ini tidak akan lagi dapat dilakukan saat server KV berjalan di TEE dan kami dapat memastikan server tersebut dapat mematuhi model kepercayaan yang dipublikasikan. |
| userBiddingSignals | memperbarui bagian "userBiddingSignals" sambil mempertahankan yang lain. | Hal ini sudah dapat dilakukan tanpa memerlukan perubahan pada API. |
| Penggunaan API | Menerapkan pembatasan frekuensi di beberapa IG dalam Privacy Sandbox, yang berpotensi menggunakan server KV atau data "prevWinsMs" yang dimodifikasi. | Kami memahami keinginan untuk kemampuan pembatasan frekuensi lanjutan dalam Privacy Sandbox. Kami menyadari bahwa pembatasan saat ini terkait berbagi data di seluruh IG dapat menimbulkan tantangan saat menerapkan strategi ini. Meskipun server KV menyediakan mekanisme potensial dengan pengamanan privasi yang sesuai, sebaiknya developer mempelajari solusi dalam satu model IG. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
| Penggunaan API | Penjual komponen (yang berpartisipasi dalam lelang bertingkat dalam Privacy Sandbox) memerlukan visibilitas ke waktu tunggu lelang tingkat teratas untuk mengoptimalkan konfigurasi mereka sendiri dan menghindari penundaan yang tidak perlu. | Kami menyadari perlunya peningkatan koordinasi waktu tunggu antara penjual tingkat atas dan penjual komponen dalam Privacy Sandbox. Kami sedang aktif menyelidiki penambahan mekanisme waktu tunggu baru, termasuk kemungkinan waktu tunggu lelang secara keseluruhan dan mempelajari cara menerapkan waktu tunggu tingkat atas ke lelang komponen. Tujuan kami adalah meningkatkan efisiensi dan prediktabilitas bagi semua peserta dalam proses lelang Privacy Sandbox. Kami membahas masalah ini di sini dan menerima masukan tambahan. |
Layanan Protected Audience
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Trusted Execution Environment (TEE) | Lebih mahal untuk menjalankan TEE di cloud publik dibandingkan dengan pusat data teknologi iklan lokal? | Respons kami serupa dengan kuartal sebelumnya: Model keamanan TEE kami saat ini mendapatkan manfaat dari praktik penerapan cloud publik. Secara khusus, TEE berbasis hardware saat ini tidak melindungi dari semua serangan fisik. Penyedia cloud publik yang didukung kami, AWS dan Google Cloud, telah mendesain dan menerapkan mitigasi untuk risiko akses fisik, termasuk dari karyawan. Lihat detail berikut terkait dukungan di lokasi. Teknologi iklan telah memberi tahu kami bahwa menjalankan layanan cloud lebih mahal daripada pusat data teknologi iklan di tempat. Meskipun kami tidak dapat mengevaluasi pernyataan tersebut, kami menerima masukan tambahan tentang biaya dan terus mengevaluasi opsi untuk memperluas dukungan TEE kami. |
| TEEs | Dukungan untuk TEE di lingkungan cloud non-publik | Respons kami serupa dengan kuartal sebelumnya: Meskipun kami terus mempelajari dukungan untuk opsi di luar solusi berbasis cloud publik, saat ini kami tidak memiliki rencana untuk mendukung TEE on-premise. Pada tahap ini, mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang ditimbulkan oleh deployment on-premise, kami yakin bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung Google Cloud selain AWS) adalah hal yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan persyaratan tersebut diperlukan dan dapat dilakukan mengingat batasan privasi dan keamanan. |
| Penyedia Cloud lainnya | Dukungan untuk penyedia cloud lainnya | Kami selalu terbuka untuk saran terkait penyedia cloud lainnya, tetapi kami berencana untuk setidaknya mendukung Google Cloud dan AWS saat 3PCD diterapkan. Lihat penjelasan ini untuk mengetahui informasi selengkapnya. |
| B&A Services API | Apa arahan Google untuk B&A Services API? Apakah Protected Audience browser Chrome akan diprioritaskan di atas atau di bawah Protected Audience browser Chrome di lelang perangkat? | Respons kami serupa dengan kuartal sebelumnya: Kami tetap berkomitmen pada desain bidding di perangkat Protected Audience saat ini. Layanan B&A telah diusulkan untuk mengeksplorasi kemungkinan solusi guna mendukung sebagian kasus penggunaan saat daya komputasi atau kecepatan jaringan perangkat mungkin terbatas. |
| Standardisasi | Layanan B&A belum melalui proses standardisasi. | Proposal Layanan B&A sedang berada di tengah-tengah salah satu fase proses standardisasi, dan kami menyambut interaksi tambahan untuk mendukung sasaran tersebut. Dimulai dengan proposal (berdasarkan proposal sebelumnya), proposal ini diinkubasi secara publik melalui diskusi terbuka yang ekstensif di W3C dan developer yang berminat dapat mulai bereksperimen dengan proposal ini dan memberikan masukan. Ini adalah pola umum untuk pengembangan fitur web, seperti yang dijelaskan misalnya dalam postingan blog kami di sini. |
| Server KV | Mengekspos URL lengkap ke server KV pembeli untuk penargetan konten / kontekstual / situs. | Kami membahas permintaan ini di sini dan menerima masukan tambahan dari ekosistem. |
| Dokumentasi | Dokumentasi untuk "Komponen tepercaya/yang diberlakukan vs. opsional" di GitHub menyebabkan kebingungan bagi beberapa teknologi iklan yang memiliki kumpulan image dan infrastruktur deployment mereka sendiri. | Kami ingin meningkatkan kualitas dokumentasi untuk "Komponen tepercaya/Diterapkan vs opsional", dan ingin mendengar pendapat dari ekosistem jika pekerjaan tersebut perlu diprioritaskan. |
| Peningkatan API | Kode Status HTTP dari panggilan server KV juga harus tersedia untuk fungsi scoreAd() sebagai parameter. | Kami sedang mengevaluasi permintaan ini dan menerima masukan tambahan dari ekosistem. |
| Dokumentasi | Berikan informasi selengkapnya tentang cara beban kerja JS dan WASM akan ditangani dengan tepat dengan eksekusi UDF. | Kami sedang mempertimbangkan untuk memberikan informasi ini dan menerima masukan tambahan di sini. |
| Dokumentasi | Meminta pembaruan nama repo. | Kami telah mengganti nama repositori menjadi "protected-auction-key-value-service". Hal ini sejalan dengan istilah untuk kumpulan layanan yang menjadi bagiannya, yang juga memiliki repositori lain seperti diskusi Protected Audience Services, dan repo dokumentasi Protected Auction Services. |
| Dokumentasi | Menghapus referensi ke Cloud debugger API di bidding_auction_services_gcp_guide.md. | Kami telah memperbarui dokumentasi dan menghapus referensi tersebut. |
| Penggunaan API | Latensi yang diperkenalkan oleh pencarian KV memerlukan waktu lebih dari 50 md. Prosesnya memerlukan waktu hampir 100 md. Apakah Anda memiliki panduan tentang hal yang berhasil dilakukan penjual lain? Apakah Anda memiliki saran tentang cara mengukur waktu tunggu dan pengaturan waktu? |
Panggilan server KV terjadi di dalam konteks Runner Skrip, yaitu lingkungan khusus yang dilindungi di dalam browser Chrome. Hal ini dimaksudkan untuk menjaga informasi dalam runner skrip ini agar terlindungi dari akses non-API. Kami telah memberikan penjelasan mendetail di sini. |
| Penggunaan API | Apakah ada waktu tunggu untuk server KV merespons dalam waktu tertentu? | Penjual dapat menentukan kolom "perBuyerCumulativeTimeouts" dalam konfigurasi lelang. Waktu tunggu ini mencakup waktu yang diperlukan untuk mengambil sinyal bidding tepercaya. |
| Latensi | Bagaimana tim Privacy Sandbox mengatasi latensi? | Untuk strategi yang kami pelajari agar latensi tetap dalam batas yang dapat diterima, lihat di sini. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pengoptimalan Kampanye Manual | ARA tidak mendukung pengoptimalan kampanye manual. | Kami telah membahas skenario ini dengan teknologi iklan dan menunjukkan cara ARA dapat digunakan untuk mendukung pengoptimalan kampanye manual. ARA telah dibuat dengan cara yang memungkinkan penyesuaian dan fleksibilitas teknologi iklan untuk menyelesaikan berbagai kasus penggunaan teknologi iklan. Beberapa saran yang diberikan mencakup penggunaan berbagai konfigurasi tingkat peristiwa yang fleksibel dan, menggunakan laporan tingkat peristiwa dengan laporan ringkasan untuk mengurangi dampak derau dan memenuhi kebutuhan pengoptimalan manual dan otomatis mereka. Kami terbuka untuk masukan ekosistem tambahan terkait kemampuan penyesuaian dan fleksibilitas konfigurasi ARA. |
| Jenis Konversi | Google hanya mengizinkan delapan jenis konversi yang membatasi. | Kami telah menerapkan sebagian besar Pelaporan tingkat peristiwa yang fleksibel, yang memberi teknologi iklan fleksibilitas tambahan dalam hal jumlah periode pelaporan, jumlah laporan atribusi, dan bit data pemicu yang dapat mereka gunakan. Teknologi iklan dapat memilih konfigurasi yang memungkinkan pengukuran hingga 32 jenis konversi yang berbeda. |
| Batas Peristiwa Laporan Gabungan | Jumlah minimum 20 peristiwa konversi per laporan gabungan tidak dapat digunakan untuk pengiklan yang lebih kecil dengan anggaran terbatas. | Tidak ada jumlah minimum peristiwa konversi yang diperlukan per laporan gabungan. Selain itu, ada sejumlah keputusan desain yang dapat dibuat untuk mengoptimalkan laporan gabungan bagi pengiklan yang lebih kecil, seperti mengubah struktur utama / dimensi yang dilacak, menguji berbagai tingkat epsilon, menguji frekuensi pengelompokan yang lebih lama, dan menguji berbagai alokasi anggaran kontribusi di antara sasaran pengukuran. Teknologi iklan yang lebih kecil juga dapat bereksperimen dengan menggabungkan laporan tingkat peristiwa dan laporan ringkasan sebagai cara untuk mengurangi dampak derau. |
| Data Real-Time | Menyembunyikan data real-time dari DSP (misalnya, klik, sesi, dan konversi) yang digunakan DSP untuk menyesuaikan strategi bidding dan mencapai efektivitas kampanye yang lebih baik, bertentangan dengan komitmen untuk mempertahankan fungsi yang ada. | Meskipun dengan ARA, klik dan sesi tetap real-time, dan konversi selalu terjadi setelahnya, bahkan dengan 3PC. |
| Bidang Belum Diisi | Persyaratan tidak terpenuhi dalam peluncuran peristiwa Fleksibel Lengkap: i) Kolom Mata Uang, dan ii) kolom orderID / TransactionID. | Saat ini, kami tidak berencana untuk mendukung kolom Mata Uang atau kolom ID Pesanan / ID Transaksi sebagai bagian dari tingkat peristiwa fleksibel penuh karena sudah ada cara untuk melakukannya dengan pelaporan tingkat peristiwa saat ini. Kami terbuka untuk masukan tambahan terkait kolom ini, dan akan mempertimbangkan kembali jika ada kasus penggunaan tambahan yang memerlukannya. Cara menggunakan desain ARA saat ini untuk mengukur informasi jenis mata uang dan ID pesanan: 1. Berdasarkan masukan tersebut, mata uang ditentukan oleh geo pengguna, yang dapat ditambahkan sebagai bagian dari source_event_id sebagai cara untuk menentukan mata uang yang digunakan. 2. Berdasarkan masukan tersebut, kolom ID pesanan diperlukan untuk memastikan konversi dan nilai tidak dihitung dua kali secara tidak sengaja, yang dapat dilakukan dengan menggunakan kunci penghapusan duplikat. |
| Anggaran Privasi | Anggaran Privasi ARA membatasi kemampuan untuk melakukan pengukuran di beberapa dimensi | ARA telah dirancang sedemikian rupa sehingga teknologi iklan dapat menyesuaikan konfigurasi ARA mereka sendiri untuk mencakup berbagai skenario atribusi. Dengan desain ARA saat ini, teknologi iklan harus mempertimbangkan kompromi antara dimensi yang paling penting untuk diukur dan dampak derau pada data mereka. Menambahkan derau ke data, bergantung pada tingkat perincian dimensi yang diukur, sangat penting untuk privasi. Kami terbuka untuk masukan ekosistem tambahan terkait kemampuan untuk mengukur di berbagai dimensi, tetapi kami perlu memahami kasus penggunaan spesifik yang memerlukan hal ini. |
| Memperbarui Spesifikasi | Meskipun Google telah menyatakan bahwa mereka telah beralih dari periode pelaporan peristiwa tetap ke fleksibel, hal ini belum tercermin dalam Spesifikasi Teknis Google yang saat ini masih memiliki periode minimum satu jam. | Pelaporan tingkat peristiwa yang fleksibel saat ini memungkinkan teknologi iklan mengubah jumlah laporan atribusi per peristiwa sumber, bit data pemicu, dan jumlah/durasi periode pelaporan. ARA masih memiliki periode pelaporan minimum 1 jam untuk laporan tingkat peristiwa yang penting untuk menjaga privasi dan mengurangi jenis serangan rekonstruksi histori tertentu. Karena laporan ringkasan memberikan informasi secara gabungan, teknologi iklan dapat memilih untuk menerima laporan gabungan dengan segera tanpa penundaan, jika diperlukan untuk kasus penggunaannya. |
| Desain API | Kekhawatiran bahwa mengurangi informasi dalam laporan konversi dan menambahkan derau dapat memengaruhi ekosistem lebih dari Google. | Google telah berkomitmen kepada CMA untuk mendesain dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan memberikan preferensi sendiri pada bisnis Google, dan mempertimbangkan dampak terhadap persaingan dalam periklanan digital serta terhadap penayang dan pengiklan dari semua ukuran. |
| Koreksi Atribusi | ARA tidak mengizinkan penyedia teknologi untuk mengontrol dan memverifikasi atribusi yang benar. | Ada banyak solusi yang tersedia dalam ARA yang menyediakan kemampuan verifikasi: 1. Teknologi iklan dapat memverifikasi bahwa perilaku ARA sesuai dengan ekspektasi mereka: – Kode sisi klien ARA bersifat open source. – Kode sisi server ARA juga bersifat open source, dan Koordinator memastikan bahwa hanya versi Layanan Agregasi yang diizinkan yang dapat mendekripsi dan memproses laporan agregat. 2. Chrome telah menyediakan Library Simulasi untuk teknologi iklan guna memverifikasi perilaku atribusi, tempat teknologi iklan dapat menguji cara ARA melakukan atribusi di lingkungan tiruan. 3. ARA mendukung sejumlah sinyal debug yang membantu memverifikasi apakah pemrosesan yang diharapkan mungkin tidak terjadi atau tidak dan alasannya. |
| (Juga dilaporkan pada kuartal sebelumnya) Derau |
Masukan bahwa tingkat derau terlalu tinggi dan memengaruhi kegunaan pelaporan. | Kami telah berbicara dengan teknologi iklan dengan masukan yang sama dan dapat mengidentifikasi cara ARA dapat disesuaikan agar lebih sesuai dengan kasus penggunaan mereka, bahkan dengan derau. Kami memiliki dokumentasi developer yang berisi sebagian besar keputusan desain dan penyesuaian yang kami bahas dengan teknologi iklan. ARA telah dirancang sedemikian rupa agar teknologi iklan dapat menyesuaikan konfigurasi ARA mereka sendiri untuk mencakup berbagai skenario atribusi. Namun, teknologi iklan harus mempertimbangkan kompromi antara dimensi yang paling penting untuk diukur dan dampak derau pada data mereka. Kami terbuka untuk masukan ekosistem tambahan terkait dampak derau dan dapat memberikan panduan tambahan tentang pengungkit ARA yang dapat digunakan untuk mengubah dampak derau. |
| Atribusi Lintas-Domain | Bagaimana cara melacak atribusi yang bersifat lintas-domain? | Teknologi iklan dapat mengalihkan ke URL pelaporan yang berbeda untuk mengatasi kasus penggunaan ini. Kami terbuka untuk masukan ekosistem tambahan terkait aspek desain ARA ini. |
| Peningkatan API | Ubah faktor penskalaan yang digunakan saat mendaftarkan atribusi untuk Laporan Ringkasan ARA secara rutin. | Berdasarkan diskusi di GitHub, tampaknya penanganan beberapa faktor penskalaan di Layanan Agregasi kemungkinan besar akan menghasilkan jumlah derau yang lebih tinggi yang ditambahkan ke laporan ringkasan dibandingkan dengan fungsi saat ini. Kami terbuka untuk masukan tambahan terkait kebutuhan faktor penskalaan sebagai bagian dari laporan agregat, tetapi ingin menyampaikan potensi kompromi dengan peningkatan derau. Kami juga mengevaluasi apakah fitur ARA lainnya di masa mendatang juga dapat membantu menyelesaikan kasus penggunaan ini. |
| Penggunaan API | Peluang untuk menyatukan cara peristiwa atribusi dibagikan kepada semua peserta yang bermanfaat bagi SSP, DSP, dll. | Kami berencana untuk menyinkronkan dengan teknologi iklan untuk lebih memahami masukan mereka dan batasan yang mereka hadapi. |
| Menguji Volume Traffic | Apakah traffic pengujian untuk Mode B untuk semua Chrome stabil? | Penyertaan dalam grup eksperimen tidak terpengaruh oleh (terlepas dari) setelan Chrome. |
| Dokumentasi | Mendukung ARA untuk piksel. | Kami telah memublikasikan informasi tentang cara mendukung kasus penggunaan ini dan menerima masukan tambahan dari ekosistem. |
| Penggunaan API | ARA mungkin tidak diatribusikan ke sumber yang benar untuk penjual pihak ketiga di platform e-commerce jika konversi tidak dilakukan oleh kontak terakhir. | Perusahaan dapat menggunakan filter untuk mencegah terjadinya atribusi yang salah (karena tidak ada laporan konversi yang akan dibuat). Kami juga sedang mengerjakan proposal untuk pemfilteran pra-atribusi guna membantu kasus penggunaan ini. |
| Dukungan Browser | Apakah ARA akan didukung di browser lain? | Kami menyambut baik browser lain untuk mengadopsi API Privacy Sandbox dan terus meluangkan waktu untuk mendiskusikan pendekatan kami secara terbuka di W3C. Kami telah menyatakan secara eksplisit interoperabilitas sebagai sasaran untuk merilis ARA dan desain ARA dimaksudkan agar tidak bergantung pada browser dengan nilai yang ditentukan vendor yang fleksibel untuk vendor dengan posisi privasi yang berbeda. Browser lain membuat pilihan mereka sendiri tentang apakah akan memberikan alternatif yang layak untuk ID lintas situs yang dapat mendukung ekosistem digital konten dan layanan. Kami senang karena Microsoft Edge telah menunjukkan bahwa browser tersebut akan mendukung ARA. |
| Penggunaan API | Apa jenis sumber yang diharapkan untuk pendaftaran sumber ARA untuk registerAdBeacon/reportEvent (dan beacon otomatis navigation_start/commit)? | Bergantung pada apakah beacon ini otomatis atau manual:
- dicadangkan.* (yaitu otomatis) harus berupa jenis sumber navigasi. - Peristiwa yang dipicu secara manual harus berupa jenis sumber peristiwa. |
| Penggunaan API | Apakah batas maksimum 20 laporan gabungan per sumber berarti untuk setiap peristiwa sumber? Apakah batasnya bersifat global atau harian? Apakah ada rencana untuk meningkatkan batasnya? | Batas 20 laporan gabungan per sumber adalah batas global yang memungkinkan pembuatan 20 laporan gabungan untuk setiap sumber. Batas ini ditetapkan oleh browser dan tidak dapat dikonfigurasi. Tujuan batas ini adalah untuk menghindari penyalahgunaan perlindungan laporan atribusi sebenarnya dengan laporan null. Kami telah membahasnya lebih lanjut di sini. |
| Penggunaan API | Dukungan untuk pemasaran melalui email menggunakan ARA. | Saat ini tidak ada dukungan langsung untuk kasus penggunaan ini dalam ARA (jika Anda tidak mengontrol situs hosting email). Kami membahasnya di sini dan menerima masukan tambahan. |
| Epsilon | Kapan nilai epsilon untuk Aggregate API akan ditentukan? | Nilai epsilon saat ini dapat dikonfigurasi oleh teknologi iklan hingga nilai minimum yang telah ditentukan oleh Privacy Sandbox (saat ini 64). Sebaiknya uji berbagai nilai epsilon dan identifikasi titik belok untuk kasus penggunaan Anda sendiri dan berikan masukan. Kami akan memastikan untuk berkomunikasi dengan teknologi iklan terlebih dahulu sebelum melakukan perubahan pada rentang nilai epsilon. |
| Peningkatan API | Mendukung kasus penggunaan saat pengiklan dapat menyisipkan ID ke kolom trigger_data untuk dicocokkan dengan data CRM eksternal agar pengiklan dapat memverifikasi kualitas konversi. | Kami sedang mendiskusikan permintaan tersebut dan menerima masukan tambahan di sini. |
| Penggunaan API | Cara menangani URL alihan sebagai URL tujuan. | Teknologi iklan dapat melakukan salah satu hal berikut: 1. Masukkan URL tujuan akhir di kolom tujuan; 2. Kolom Tujuan memungkinkan Anda memasukkan maksimal 3 URL sehingga Anda dapat memasukkan beberapa URL ke dalam kolom. Kedua opsi tersebut memerlukan URL tujuan akhir. Kami telah membahasnya lebih lanjut di sini. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Mekanisme Penemuan Kunci | Meminta mekanisme penemuan kunci | Kami memiliki proposal untuk penemuan kunci dan menyambut masukan dari ekosistem terkait proposal tersebut. |
| Penggunaan API | Roadmap untuk visibilitas di Layanan Agregasi | Kami sedang meninjau opsi untuk mendukung lebih banyak visibilitas dan menerima masukan dari ekosistem di sini. |
| Peningkatan API | Meminta agar dapat membuat kueri ulang laporan. | Layanan Agregasi sedang mengerjakan proposal permintaan ulang tempat teknologi iklan dapat membagi epsilon untuk setiap laporan. Hal ini dapat menyebabkan lebih banyak derau per kueri, tetapi akan memungkinkan teknologi iklan membuat kueri ulang dan menjaga privasi. |
| Peningkatan API | Ingin dapat mengaitkan beberapa origin ke ID AWS yang sama. | Layanan Agregasi kini akan memungkinkan beberapa situs diaktifkan di akun cloud yang sama (Google Cloud atau AWS). Hal ini akan memungkinkan teknologi iklan menggunakan enclave Layanan Agregasi yang sama untuk memproses laporan dari beberapa situs dan beberapa origin dari situs yang sama. |
| Penggunaan API | Jika batch agregat gagal, tidak yakin apakah anggaran sudah terpakai atau belum dan apakah mereka dapat memproses ulang batch. Jika layanan agregasi mengalami error anggaran untuk laporan duplikat, laporan lainnya yang tersisa akan hilang. Bagaimana cara meminimalkan kerugian ini? | Dalam skenario umum, jika seluruh tugas gagal, anggaran tidak akan digunakan. Jika terjadi kegagalan yang jarang terjadi dan anggaran habis, teknologi iklan dapat meminta pemulihan anggaran. Jika teknologi iklan sering mengalami kegagalan tugas dengan error anggaran habis, mereka harus mengonfirmasi strategi pengelompokan. Petunjuk tentang cara membuat batch dengan benar dan menghindari laporan duplikat serta error dapat ditemukan di sini. Kami menerima masukan tentang pemulihan anggaran di sini. |
| Penggunaan API | Menggunakan Private Aggregation API dengan pemicu yang dijelaskan di sini akan menghasilkan laporan gabungan untuk setiap lelang. Apa kemampuan penskalaan Layanan Agregasi? | Layanan Agregasi itu sendiri tidak menetapkan batas atas jumlah kunci atau laporan dalam batch, tetapi skala 10^14 laporan dan 10^12 kunci saat ini tidak didukung karena memori yang diperlukan. Panduan ukuran kami menunjukkan rentang yang telah kami uji dan rekomendasikan untuk performa yang optimal dengan beban yang diharapkan dan jenis instance VM cloud yang didukung. |
| Pemrosesan Data | Jika data terenkripsi memiliki informasi pribadi, apa pengaturan hukum untuk menyediakan data terenkripsi ke Layanan Agregasi? Dapatkah Anda memberi tahu apakah koordinator dijamin tidak akan mengakses data terenkripsi? |
Layanan Agregasi tidak membagikan data terenkripsi / pengguna kepada Koordinator. Layanan Agregasi menggunakan koordinator untuk pengelolaan dan pencatatan kunci. Beberapa detail tentang koordinator dapat ditemukan di sini. Untuk akuntansi, layanan Agregasi hanya membagikan ID bersama dan asal pelaporan dengan PBS untuk penggunaan anggaran. Setelah meluncurkan multi-situs, kita akan mengganti origin dengan situs. Perhatikan bahwa layanan Agregasi berjalan di TEE yang merupakan satu-satunya tempat laporan dari klien dapat didekripsi. Kode yang berjalan di TEE bersifat open source dan diaudit oleh pihak eksternal seperti yang diuraikan di sini. |
Private Aggregation API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penggunaan API | Kemampuan penjual komponen untuk mengirim laporan ke beberapa server agregasi dalam TEE. | Status Private Aggregation API saat ini tidak mendukung fitur ini. Kami telah membahas masalah ini lebih lanjut di sini. |
| Dokumentasi | Berapa nilai epsilon yang digunakan dalam uji coba Google? | Untuk Private Aggregation API, nilai ε yang ditentukan dalam kueri layanan agregasi sesuai dengan anggaran kontribusi L1 sebesar 2^16 yang diterapkan secara rolling selama 10 menit. Ada juga anggaran kontribusi L1 'backstop' sebesar 2^20 yang diterapkan secara rolling selama 24 jam. Jadi, pada dasarnya, parameter privasi adalah ε berdasarkan periode 10 menit bergulir, dan 16ε berdasarkan periode 24 jam bergulir (bukan 144ε). Layanan agregasi saat ini mendukung rentang ε untuk pengujian (hingga 64) guna memungkinkan eksperimen dengan berbagai strategi agregasi dan memberikan masukan tentang utilitas sistem dengan parameter privasi yang berbeda untuk Agregasi Pribadi dan API lainnya. Kami berencana untuk meninjau kembali nilai epsilon maksimum yang diizinkan dari waktu ke waktu seiring kami mendapatkan masukan dari penguji dan menambahkan fitur yang memungkinkan penggunaan anggaran privasi yang lebih efisien. |
Membatasi Pelacakan Tersembunyi
Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna
Tidak ada masukan yang diterima kuartal ini.
Perlindungan IP (sebelumnya bernama Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| ID Resolusi | Privacy Sandbox perlu lebih vokal untuk menekankan bahwa ID resolusi yang sering kali dibuat di IP tidak berkelanjutan bagi pengiklan. | Privacy Sandbox telah menjelaskan bahwa kami bertujuan untuk mengurangi pelacakan lintas situs. Inisiatif publik kami, yang melampaui cookie, dipublikasikan di privacysandbox.com dan GitHub. Kami berupaya mengurangi pelacakan lintas situs, termasuk pelacakan yang didasarkan pada alamat IP. Namun, pada akhirnya setiap situs dapat memutuskan apakah akan mengaktifkan pelacakan lintas situs secara proaktif atau tidak. Di era peningkatan pemeriksaan terhadap kepatuhan peraturan, setiap perusahaan harus memahami praktik yang diterapkan oleh penyedia layanan mereka. |
| Chromecast | Apakah Perlindungan IP akan memengaruhi Chromecast atau perangkat Chrome lainnya? | Saat ini tidak ada rencana untuk menerapkan Perlindungan IP ke perangkat Chromecast. |
| Daftar Perlindungan IP | Apakah daftar pihak ketiga yang diidentifikasi sebagai berpotensi menggunakan alamat IP untuk pelacakan lintas situs di seluruh web akan dipublikasikan? | Daftar ini akan dipublikasikan setelah selesai, seperti yang dibahas di sini. |
Mitigasi Pelacakan Kembali
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pengecualian Single Sign-On (SSO) | Bagaimana cara Mitigasi Pelacakan Pantulan (BTM) memverifikasi kasus penggunaan SSO untuk pengecualian? | BTM akan dinonaktifkan oleh heuristik Chrome. Lihat penjelasan untuk mengetahui detailnya. |
| Uji Coba Penghentian | Apakah BTM diaktifkan untuk situs dalam uji coba penghentian penggunaan 3PC? | Tidak, BTM mematuhi pengecualian cookie yang dibuat oleh uji coba penghentian penggunaan, seperti yang dibahas di sini. |
Anggaran Privasi
Seperti yang disebutkan dalam penjelasan GitHub dan situs developer, Privacy Budget tidak lagi dipertimbangkan secara aktif sebagai bagian dari proposal Privacy Sandbox.
Memperkuat batasan privasi lintas situs
Set Situs Terkait (sebelumnya Set Pihak Pertama)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Permintaan Fitur | CHIP dan / atau Partisi Penyimpanan secara otomatis diizinkan untuk diakses di seluruh RWS, tanpa memerlukan Storage Access API, atau interaksi pengguna. | Kami sedang mempertimbangkan manfaat dan kelayakan fitur yang dapat menjalankan fungsi ini. Salah satu pertimbangannya adalah potensi kesenjangan dalam interoperabilitas lintas browser, yang diatasi oleh RWS dengan memanfaatkan Storage Access API. Saat ini tidak ada fungsi yang setara dengan fungsi yang diminta ini yang didukung di browser lain. Sebaiknya developer mengirimkan kasus penggunaan mereka terkait masalah ini untuk memfasilitasi diskusi di sini. |
| Penghapusan Set yang Tidak Mematuhi Kebijakan | Bagaimana proses untuk menghapus set yang menjadi tidak mematuhi dari repositori? | Kami sedang berupaya menentukan proses untuk hal ini, dan akan membagikan info terbaru sesegera mungkin setelah tersedia. |
| Proses Penegakan Kebijakan | Peran subjektif Google dalam proses penegakan RWS tidak jelas. | Karena RWS adalah project yang sedang berlangsung dan kami terus menerima kiriman baru, aspek proses dan kriteria kami masih dalam proses penyempurnaan. Kami setuju bahwa pedoman pengiriman kami harus menjelaskan persyaratan pengiriman secara menyeluruh, dan kami akan menambahkan detail yang lebih lengkap ke pedoman pengiriman kami ke depannya untuk menghindari ambiguitas dan kebingungan lebih lanjut. Kami ingin proses pengiriman dilakukan se-teknis mungkin sehingga kami dapat menghentikan keterlibatan manusia dan sepenuhnya mengandalkan pemeriksaan otomatis. PR seperti ini memerlukan lebih banyak interaksi manusia karena mencakup perilaku yang tidak kami antisipasi, tetapi PR ini memungkinkan kami mengidentifikasi lebih banyak area untuk otomatisasi dan cara memperbaiki pedoman kami untuk menghindari masalah ini di masa mendatang. |
| Membagikan Data | Meminta fitur yang memungkinkan pemilik domain menunjukkan bahwa mereka ingin pihak ketiga juga membagikan data RWS, dengan izin pengguna. | Fungsi yang diminta sudah tersedia melalui API seperti FedCM, dan Storage Access API yang memungkinkan akses ke identitas terautentikasi setelah pengguna menerima permintaan izin. Kami menerima masukan dari ekosistem tentang kasus penggunaan tertentu yang mereka yakini tidak mungkin. |
| Metode Penyimpanan Lainnya | Apakah informasi yang disimpan di penyimpanan lokal atau penyimpanan sesi juga akan ditafsirkan sebagai 3PC? | Penyimpanan lokal, penyimpanan sesi, dan bentuk penyimpanan non-cookie lainnya saat digunakan dalam konteks pihak ketiga telah dipartisi di Chrome sejak versi 115. Lihat postingan blog ini untuk detail selengkapnya. |
| Batas Set Terkait | Apa yang terjadi pada organisasi yang mengirimkan lebih dari 5 domain meskipun "dibatasi hingga 5 situs terkait"? | Set ini akan diterima melalui proses GitHub, tetapi browser (Chrome) hanya akan menerapkan aturan pemberian otomatis Storage Access API kami ke 5 domain pertama; dan mengabaikan domain lainnya, seperti yang dibahas di sini. |
| find_robots_txt | Pemeriksaan find_robots_txt tidak berfungsi dengan pengalihan. | Perbaikan telah dikirim untuk menyelesaikan masalah ini di sini. |
| Gestur Pengguna | Menghapus persyaratan gestur pengguna untuk accessStorage(). | Persyaratan ini dibuat berdasarkan desain serupa yang diterapkan di semua browser utama untuk requestStorageAccess API. Kami mengundang masukan dan kasus penggunaan tambahan di masalah GitHub ini untuk membantu kami memprioritaskan permintaan ini, dan memungkinkan diskusi lintas browser. |
| Gestur Pengguna | Apakah gestur pengguna diperlukan untuk memberikan izin akses penyimpanan pihak ketiga setelah Chrome atau OS dimulai ulang? | Ya, tetapi kami menerima masukan tambahan dari ekosistem tentang apakah perilaku ini akan diubah di sini. |
Fenced Frames API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| adComponent | Kurangnya dokumentasi dan fleksibilitas saat menggunakan AdComponents dengan Frame Pagar. | Kami ingin membagikan dokumentasi selengkapnya terkait kasus penggunaan ini. Selain itu, komponen iklan didukung di Bingkai Pagar menggunakan getNestedConfigs() yang didokumentasikan dalam spesifikasi di sini. |
| (Juga dilaporkan pada kuartal sebelumnya) Merender adComponent |
Minta kode contoh tentang cara merender adComponents di Fenced Frame. | Kami sedang berupaya membagikan beberapa contoh kode di sini. |
| Verifikasi Iklan Pihak Ketiga | Peran verifikasi iklan pihak ketiga dalam konteks Frame Berpagar memerlukan detail lebih lanjut, terutama terkait keamanan merek/kontekstual. | Saat ini, Pelaporan Iklan Bingkai Pagar memungkinkan DSP mengirim data tingkat peristiwa tayangan dan lelang ke verifikasi iklan pihak ketiga untuk pemeriksaan keamanan merek pasca-render dan penagihan. |
| Iklan yang Dapat Diperluas | Meminta dukungan untuk iklan yang dapat diperluas. | Jika iklan perlu beralih antara dua ukuran dengan rasio aspek yang sama, dan tidak ada perbedaan fungsional di antara keduanya (hanya ukuran), penyempan dapat mengubah ukuran Bingkai Pagar dengan ukuran iklan kedua dan browser akan menskalakan elemen Bingkai Pagar sesuai kebutuhan. |
| (Juga dilaporkan pada kuartal sebelumnya) Dukungan untuk Inventaris Video & Native |
Apakah Bingkai Pagar mendukung inventaris video & native? | Respons kami serupa dengan kuartal sebelumnya: PA API mendukung rendering video menggunakan mekanisme yang mengandalkan iframe. Namun, kami belum mendesain solusi untuk rendering iklan video dan native yang kompatibel dengan Bingkai Pagar, dan ini adalah salah satu alasan kami memutuskan untuk menunda penerapan Bingkai Pagar hingga tahun 2026. Artinya, jika partner memutuskan untuk menerapkan Bingkai Pagar sekarang, dukungan untuk video dan native akan berkurang untuk partner tersebut. |
| Dewan Penasihat | Meminta pembentukan dewan penasihat vendor iklan native untuk memastikan penerapan Frame Pagar mengikuti standar industri. | Bingkai Pagar tidak diperlukan untuk digunakan di PA API sebelum tahun 2026. Waktu tambahan ini memungkinkan kami untuk terus bekerja sama dengan industri guna mendesain dan menerapkan dukungan untuk berbagai kasus penggunaan penting yang lebih luas. Kami sebelumnya menyatakan bahwa kami akan mengembangkan Frame Pagar sebelum persyaratannya untuk mempertahankan dukungan untuk iklan video dan native dengan PA API. Sesuai dengan komitmen kami, kami akan berkomunikasi dan memberi tahu CMA tentang perubahan tersebut, dan kami akan terus menerima masukan dari ekosistem sebelum mewajibkan Frame Pagar. Model interaksi ekosistem kami di W3C dan organisasi standar iklan seperti IAB Tech Lab memungkinkan berbagai pakar industri untuk memandu desain sebelum diperlukan. |
| (Juga dilaporkan pada kuartal sebelumnya) Perbedaan Ukuran di Seluruh Platform |
Melaporkan bahwa ukuran konten yang ditampilkan di Bingkai Pagar terlihat berbeda antara desktop dan smartphone. | Ini adalah masalah Chromium umum yang sedang kami selidiki. Kami menerima masukan tambahan di sini. |
| Peningkatan API | Apakah persyaratan Frame Pagar diundur hingga 2025 sehingga iklan native kini didukung di Privacy Sandbox? | Seperti yang kami sampaikan dalam pengumuman publik untuk penegakan Frame Pagar paling lambat tahun 2026, kami telah mengetahui "upaya signifikan untuk mengakomodasi" Frame Pagar secara luas. Tentu saja, salah satunya adalah Native, tetapi bukan satu-satunya faktor. Tujuannya adalah untuk memberikan lebih banyak waktu guna memastikan kesiapan ekosistem untuk mendukung kasus penggunaan utama, termasuk, tetapi tidak terbatas pada, native. |
Shared Storage API
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Performa | Waktu pengembalian Penyimpanan Bersama di luar worklet tampaknya bergantung pada aktivitas dalam worklet. | Kami membahas hasil pengujian ini di sini. |
| Penggunaan yang Lebih Luas | Penyimpanan Bersama harus menjadi standar di seluruh industri yang tersedia di seluruh browser. | Kami menerima dan menghargai masukan ini. Chrome terus berpartisipasi secara aktif dalam forum W3C, termasuk WICG, untuk mendukung proposal, mencari masukan, dan mendorong adopsi. |
| Worklet Bidding | Apakah Anda dapat membaca dari Penyimpanan Bersama dalam generateBid (yang sudah berjalan di worklet) untuk menerapkan logika bisnis / keputusan iklan (seperti Pembatasan Frekuensi) berdasarkan informasi lintas situs dan memilih sebagian iklan? | Tidak, Anda tidak dapat membaca dari penyimpanan bersama dalam worklet bidding. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Kapasitas Partisi | Mengklarifikasi perilaku saat melebihi kapasitas partisi. | Jika kapasitas tercapai, cookie tertua akan dikeluarkan dari cookie yang paling jarang diakses untuk mengosongkan memori hingga batas tidak lagi terlampaui. Developer akan melihat header Cookie yang diperbarui dalam permintaan berikutnya. |
| Akses iFrame Pihak Ketiga | Konten iFrame pihak ketiga tersemat yang membuka tab/jendela baru ke situs pihak ketiga yang sama harus memiliki akses ke cookie yang dipartisi sama seperti pembuka. | Kami sedang membahas kasus penggunaan ini dan menerima masukan tambahan dari ekosistem di sini. |
| Cookie Duplikat | Jika ada cookie yang dipartisi dan cookie yang tidak dipartisi dengan nama yang sama, nilai kunci mana yang akan dikirim browser? | Jika memiliki dua cookie dengan nama yang sama (satu dipartisi, dan satu tidak), Anda akan mendapatkan kedua cookie tersebut. Sayangnya, tidak ada cara untuk membedakan keduanya. Spesifikasi RFC tentang hal ini tersedia di sini, yang menjelaskan bahwa urutan pengiriman cookie tidak boleh diandalkan. |
| Permintaan Fitur | Ikut serta dalam cookie yang dipartisi asal. | Kami sedang mempertimbangkan permintaan ini dan menerima masukan tambahan dari ekosistem di sini. |
FedCM
Tidak ada masukan yang diterima kuartal ini.
Memerangi spam dan penipuan
Private State Token API (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Webview | Apakah Token Status Pribadi (PST) dipertahankan di beberapa Webview di perangkat seluler (profil) yang sama? | Setiap aplikasi yang menggunakan webview akan memiliki penyimpanan lokal yang berbeda, yang berarti penerbit PST tidak dapat menerbitkan token di webview satu aplikasi, lalu di aplikasi terpisah, mengizinkan penukaran token. Hal ini juga berlaku untuk bentuk data lain yang disimpan secara lokal di webview, seperti cookie. PST belum sepenuhnya tersedia di WebView. Kami berharap dapat memberikan kabar terbaru terkait hal ini paling lambat akhir Kuartal 2. |
| Jenis Token Baru | Proposal untuk jenis token baru. | Kami berterima kasih atas proposal ini dan eksplorasi berkelanjutan terhadap aplikasi dan adaptasi PST, serta berharap dapat mempelajari proposal ini lebih lanjut dalam pertemuan Grup Komunitas Anti-Penipuan mendatang pada K2 2024. |
| Identifikasi Pengguna | Bagaimana cara mencegah pengguna diidentifikasi berdasarkan PST tertentu yang dimiliki pengguna? | Hal ini saat ini dimitigasi dengan membatasi upaya penukaran di situs menjadi dua penerbit, terlepas dari apakah ada token yang tersedia dari penerbit tersebut. Anda harus menghitung penerbit berdasarkan batas meskipun tidak ada token yang tersedia karena jika tidak, situs dapat melakukan iterasi melalui semua penerbit hingga menemukan kecocokan positif. |
| Pendaftaran | Berapa lama pendaftaran akan diperlukan untuk PST? | Pendaftaran akan terus diperlukan untuk waktu yang akan datang, seperti yang dijelaskan secara lebih mendetail di sini. |
| Dukungan untuk Browser Chromium lainnya | Apakah pendaftaran penerbit PST untuk browser berbasis Chromium lainnya akan didukung melalui repositori Pendaftaran Penerbit Chrome? | Chrome mengambil komitmen kunci dan mendistribusikannya ke klien Chrome melalui mekanisme yang disebut Updater Komponen. Saat browser lain menambahkan dukungan yang lebih lengkap untuk API, browser tersebut harus membuat proses untuk mendapatkan komitmen kunci ke klien, baik melalui metode gaya updater komponen atau metode lainnya. Hal ini dibahas secara lebih mendetail di sini. |