Laporan triwulanan untuk Kuartal 2 2023 merangkum masukan ekosistem yang diterima terkait proposal Privacy Sandbox dan respons Chrome.
Sebagai bagian dari komitmennya kepada CMA, Google telah setuju untuk secara publik memberikan laporan kuartalan tentang proses interaksi pemangku kepentingan untuk proposal Privacy Sandbox-nya (lihat paragraf 12 dan 17(c)(ii) Komitmen). Laporan ringkasan masukan Privacy Sandbox ini dibuat dengan menggabungkan masukan yang diterima oleh Chrome dari berbagai sumber seperti yang tercantum dalam ringkasan masukan, termasuk, tetapi tidak terbatas pada: Masalah GitHub, formulir masukan yang disediakan di privacysandbox.com, pertemuan dengan pemangku kepentingan industri, dan forum standar web. Chrome menyambut masukan yang diterima dari ekosistem dan secara aktif mencari cara untuk mengintegrasikan pembelajaran ke dalam keputusan desain.
Tema masukan diberi peringkat menurut prevalensi per API. Hal ini dilakukan dengan mengambil agregasi jumlah masukan yang telah diterima tim Chrome seputar tema tertentu dan mengaturnya dalam urutan kuantitas dalam urutan menurun. Tema masukan umum diidentifikasi dengan meninjau topik diskusi dari rapat publik (W3C, PatCG, IETF), masukan langsung, GitHub, dan pertanyaan umum yang muncul melalui tim internal Google dan formulir publik.
Lebih khusus lagi, menit rapat untuk rapat badan standar web ditinjau dan, untuk masukan langsung, catatan Google terkait pertemuan pemangku kepentingan 1:1, email yang diterima oleh masing-masing engineer, milis API, dan formulir masukan publik juga dipertimbangkan. Google kemudian berkoordinasi dengan tim yang terlibat dalam berbagai aktivitas penjangkauan ini untuk menentukan prevalensi relatif dari tema yang muncul sehubungan dengan setiap API.
Penjelasan respons Chrome terhadap masukan dikembangkan dari FAQ yang dipublikasikan, respons aktual yang dibuat terhadap masalah yang diajukan oleh pemangku kepentingan, dan menentukan posisi khusus untuk tujuan latihan pelaporan publik ini. Dengan mencerminkan fokus pengembangan dan pengujian saat ini, kami menerima pertanyaan dan masukan khususnya sehubungan dengan Topics, Protected Audience, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum memiliki respons Chrome yang dipertimbangkan.
Glosarium akronim
- CHIP
- Cookie yang Memiliki Status Dipartisi Independen
- DSP
- Platform Sisi Permintaan
- FedCM
- Pengelolaan Kredensial Federasi
- FPS
- Set Pihak Pertama
- IAB
- Interactive Advertising Bureau
- IDP (IDP)
- Penyedia Identitas
- IETF
- Internet Engineering Task Force
- IP
- Alamat Protokol Internet
- openRTB
- Bidding real-time
- lewat batas waktu
- Uji Coba Origin
- PatCG
- Grup Komunitas Teknologi Periklanan Pribadi
- RP
- Pesta Santai
- SSP
- Platform Sisi Suplai
- TEE
- Trusted Execution Environment
- UA
- String Agen Pengguna
- UA-CH
- Petunjuk Klien Agen Pengguna
- W3C
- Konsorsium World Wide Web
- WIPB
- Kebutaan IP yang Disengaja
Masukan umum, tidak ada API/Teknologi spesifik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Tata Kelola Data & Kepatuhan terhadap Peraturan | Panduan ekosistem tentang penggunaan Privacy Sandbox sesuai dengan persyaratan peraturan. | Seperti teknologi baru lainnya, setiap perusahaan bertanggung jawab untuk memastikan bahwa penggunaan Privacy Sandbox mematuhi hukum. Google tidak dapat memberikan nasihat hukum kepada orang lain. Namun, kami menyadari bahwa ini adalah area minat utama untuk ekosistem. Untuk setiap API, kami telah memublikasikan dokumentasi teknis lengkap, yang akan menjadi dasar untuk melakukan penilaian hukum yang diperlukan, dan kami sedang berupaya menyediakan materi tambahan untuk mendukung upaya perusahaan dalam mematuhi persyaratan peraturan. |
| Proposal Pengujian Kuantitatif CMA | Informasi selengkapnya tentang proposal pengujian kuantitatif CMA | Kami bekerja sama dengan CMA untuk merancang eksperimen yang akan memberikan gambaran tentang dampak penghentian penggunaan cookie pihak ketiga dan pengenalan proposal Privacy Sandbox pada ekosistem. Pada bulan April, CMA memublikasikan panduan tingkat tinggi tentang hal yang akan terjadi selama periode Pengujian dan Uji Coba, diikuti dengan panduan mendetail pada bulan Juni. Sebaiknya sampaikan pertanyaan atau masukan terkait proposal Pengujian Kuantitatif CMA langsung kepada CMA. |
| Mode pengujian yang difasilitasi Chrome | Informasi dan klarifikasi selengkapnya tentang jadwal pengujian | Kami memublikasikan postingan blog pada 18 Mei yang membagikan informasi selengkapnya tentang dua mode pengujian yang difasilitasi Chrome. Detail ini belum final, dan kami akan memublikasikan panduan penerapan lebih lanjut seiring progres kami pada Kuartal 3 2023. |
| Penyimpanan yang Dipartisi | Apakah penyimpanan yang dipartisi akan digunakan selama pengujian yang difasilitasi Chrome? | Partisi penyimpanan akan dikirimkan ke semua pengguna sebelum eksperimen penghentian penggunaan cookie pihak ketiga. Oleh karena itu, ini akan diaktifkan untuk semua grup eksperimen. Sites akan memiliki opsi mengaktifkan uji coba penghentian penggunaan untuk mendapatkan kembali penyimpanan yang tidak dipartisi selama jangka waktu ini. |
| Dukungan produksi | Apa proses yang diterapkan bagi Chrome untuk mendukung masalah teknis dan eskalasi Privacy Sandbox yang memengaruhi ekosistem? | Google menyediakan berbagai saluran untuk mengizinkan teknologi iklan melaporkan masalah dan memungkinkan eskalasi apa pun yang diperlukan. Lihat postingan developer kami untuk mengetahui informasi selengkapnya tentang forum publik dan pribadi untuk mendapatkan masukan dan eskalasi. |
| Rentang Waktu Pendaftaran | Jangka waktu pendaftaran saat ini terlalu singkat | Kami masih mengevaluasi batas waktu penegakan kebijakan dan kami ingin mengetahui dari ekosistem tentang rentang waktu yang lebih sesuai. |
| Nomor D-U-N-S | Informasi selengkapnya tentang persyaratan nomor D-U-N-S untuk Pendaftaran dan Pengesahan | Peserta dapat menemukan persyaratan untuk mendapatkan Nomor D-U-N-S di situs Dun and Bradstreet. Persyaratannya bervariasi tergantung pada pasar, jadi peserta harus memastikan untuk memeriksa {i>website<i} untuk pasar tertentu yang mereka minati. Namun, secara umum, peserta harus memberikan informasi dasar tentang bisnis mereka, seperti nama bisnis, alamat, dan informasi kontak pemilik atau pengelola bisnis. Peserta mungkin juga akan diminta untuk memberikan informasi keuangan, seperti pendapatan tahunan bisnis. Setelah permohonan selesai, D&B akan meninjaunya dan menerbitkan Nomor D-U-N-S jika permohonan disetujui. |
| Bertransisi dari Uji Coba Origin ke Ketersediaan Umum | Apakah transisi dari Uji Coba Origin ke Ketersediaan Umum akan memengaruhi penguji Uji Coba Origin saat ini? | Mulai bulan Juli, penguji akan dapat mengakses API pengukuran dan relevansi pada ketersediaan umum. Hal ini akan memberikan tumpang-tindih antara ketersediaan uji coba origin dan ketersediaan umum. |
| Studi AdExchanger | Informasi lebih lanjut tentang metodologi survei | Survei meminta responden untuk memperkirakan rasio sinkronisasi dan pendapatan untuk bisnis mereka. Metodologi responden untuk menjawab pertanyaan individual sepenuhnya bergantung pada mereka. |
| Nilai-nilai parameter | Bagaimana cara menentukan nilai parameter seperti tingkat derau, nilai minimum anonimitas, dan anggaran privasi? | Penjelasan GitHub ini menetapkan prinsip yang lebih umum di balik Privacy Sandbox API. Banyak nilai yang masih dalam proses finalisasi dan kami mengharapkan masukan tentang subjek ini. |
Tampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Preservasi Privasi | Penelitian yang mengevaluasi Topics API tentang perlindungan privasi | Kami terlibat secara aktif dengan komunitas riset, menyajikan riset kami tentang properti privasi Topics API dalam makalah, laporan, dan presentasi workshop. Kami senang melihat lebih banyak anggota eksternal komunitas riset berinteraksi dengan area ini. Topics API melindungi pengguna dari pelacakan umum di web dengan membuatnya terlalu sulit untuk melacak pengguna dalam skala besar. Makalah ini menunjukkan bahwa kita berhasil melakukannya dengan Topics API. Opsi ini lebih pribadi daripada cookie pihak ketiga dan melindungi pengguna sekaligus mendukung situs yang suka mereka kunjungi. |
| Taksonomi topik tidak cukup terperinci | Taksonomi topik yang luas tidak mencakup topik yang lebih terperinci, termasuk topik yang spesifik per wilayah. | Sebagai respons atas masukan sebelumnya dari ekosistem, kami memublikasikan postingan blog pada 15 Juni yang menjelaskan taksonomi baru yang diperbarui yang menggabungkan banyak peningkatan setelah masukan dari ekosistem. Sebagai bagian dari upaya kami terkait taksonomi yang direvisi, kami telah bekerja sama dengan beberapa perusahaan di seluruh ekosistem, seperti Raptive (sebelumnya CafeMedia) dan Criteo. Taksonomi yang diperbarui menghapus kategori yang kami dengar kurang berguna, demi kategori yang lebih cocok dengan minat pengiklan, sambil mempertahankan komitmen kami untuk mengecualikan topik yang berpotensi sensitif. Kami mendorong ekosistem untuk meninjau taksonomi terbaru dan memberikan masukan terkait perubahan tersebut. |
| Proses pembaruan taksonomi dan pengklasifikasi | Informasi selengkapnya tentang ritme rilis taksonomi dan pengklasifikasi Topics serta langkah-langkah yang dapat dilakukan perusahaan untuk menghadapi perubahan tersebut. | Seperti yang dijelaskan dalam postingan blog baru-baru ini, kami memperkirakan taksonomi akan berkembang dari waktu ke waktu, dan agar tata kelola taksonomi pada akhirnya beralih ke pihak eksternal yang mewakili pemangku kepentingan dari seluruh industri. Kami juga membagikan rencana peningkatan di grup topics-announce. |
| Dampak pada sinyal pihak pertama | Peningkatan jumlah Topics dalam update Taksonomi baru-baru ini mungkin sangat bermanfaat dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. | Dalam laporan Q1 tahun 2023, CMA berkomentar bahwa "Kami memahami bahwa Google telah mendiskusikan taksonomi baru yang diusulkan dengan beberapa peserta pasar di seluruh supply chain teknologi iklan. Meskipun beberapa penayang besar telah menyatakan bahwa utilitas topik yang lebih besar akan meningkatkan tekanan persaingan pada solusi berbasis data pihak pertama mereka, pandangan awal kami adalah bahwa utilitas yang lebih besar lebih baik untuk persaingan secara keseluruhan – khususnya kemampuan penayang yang lebih kecil untuk terus memonetisasi inventaris mereka setelah cookie pihak ketiga tidak lagi digunakan". Pandangan kami selaras dengan komentar yang dibuat oleh CMA ini. |
| Kegunaan untuk berbagai jenis pemangku kepentingan | Teknologi iklan yang bertindak sebagai SSP dan DSP mungkin memiliki keunggulan yang signifikan dibandingkan pemain ekosistem lainnya. | Respons kami tidak berubah dari kuartal sebelumnya: "Google telah berkomitmen pada CMA untuk merancang dan menerapkan proposal Privacy Sandbox melalui cara yang tidak mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, serta mempertimbangkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan, terlepas dari ukuran mereka. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini. Seiring berjalannya pengujian Privacy Sandbox, salah satu pertanyaan utama yang akan kami nilai adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. {i>Feedback<i} sangat penting dalam hal ini, terutama masukan yang spesifik dan dapat ditindaklanjuti yang dapat membantu kami untuk lebih meningkatkan desain teknis. Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA untuk memublikasikan catatan tentang desain eksperimen guna memberikan lebih banyak informasi kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan." |
| Topik Turunan | Kriteria pemilihan Topik adalah frekuensi kunjungan browser, apakah fragmentasi segmentasi akan mengarah ke topik turunan yang tidak pernah naik ke atas? | Chrome saat ini mengevaluasi metodologi peringkat lainnya, dan mengeksplorasi sinyal lain yang dapat meningkatkan peringkat. Kami akan mengomunikasikan rencana kami yang direvisi kepada ekosistem pada waktu yang tepat. |
| Sensitivitas | Tujuan Topics API seharusnya adalah untuk memastikan bahwa informasi pengguna yang diperoleh atau berasal dari Topics API harus kurang sensitif secara pribadi daripada yang dapat diperoleh menggunakan metode pelacakan saat ini. | Kami yakin Topics API secara signifikan lebih bersifat pribadi dibandingkan teknologi saat ini, secara signifikan membatasi identifikasi ulang pengguna, dan dirancang untuk mengecualikan topik sensitif. Kami memahami bahwa topik dapat dikorelasikan atau digabungkan dengan data pihak pertama untuk membuat kategori sensitif, tetapi kami yakin Topics API merupakan langkah maju untuk privasi pengguna dan kami berkomitmen untuk terus meningkatkan API. |
| Struktur Taksonomi | Menambahkan ID, Pembuatan Versi, dan struktur metadata lainnya ke Taksonomi Topics | Saat ini, dalam respons API, kami menyertakan ID taksonomi. Seiring dengan langkah kami menuju tata kelola jangka panjang, sebaiknya tinjau objek Topics dan sertakan metadata tambahan pada pembuatan versi jika diperlukan. |
| Kontrol penayang | Penayang harus menentukan topik yang tepat untuk situs mereka. | Kesalahan klasifikasi situs dapat membuat sinyal Topics sedikit kurang berguna sebagai sinyal secara keseluruhan, tetapi situs tertentu yang salah diklasifikasikan tidak lebih dan tidak kalah terkena dampak dari 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, meskipun terjadi kesalahan klasifikasi. Kami menerima masukan tentang topik ini di sini. Mengizinkan penayang untuk mengontrol klasifikasi mereka memiliki risiko tersendiri. Situs mungkin salah mengklasifikasikan situs mereka, mengurangi utilitas untuk semua, atau mengenkode arti sensitif dalam topik yang kurang umum, sehingga membahayakan privasi pengguna. |
| Ekstensi Chrome | Izinkan Ekstensi Chrome mengelola dan memfilter Topik, mirip dengan ekstensi Pengelolaan Cookie saat ini | Hal ini seharusnya sudah memungkinkan, seperti yang telah dibahas di GitHub, tetapi kami mengharapkan masukan tambahan dari ekosistem. |
| Transisi ke Ketersediaan Umum | Apakah akan ada dampak pada Topics API saat melakukan transisi dari Uji Coba Origin ke Ketersediaan Umum? | Tidak akan ada data yang hilang untuk pengguna yang melakukan transisi dari Uji Coba Origin ke Ketersediaan Umum. |
| Privasi | Nama Host dapat berisi informasi pribadi yang mungkin diungkapkan oleh Topics API | Kami memiliki sejumlah mitigasi untuk memastikan privasi, seperti yang diuraikan di sini. |
| Penipuan dan Penyalahgunaan | Cara mencegah manipulasi Topics oleh kunjungan penipuan | Mitigasi diuraikan di sini. |
| Pengklasifikasi topik | Apakah situs dapat meminta untuk mengubah klasifikasi Topiknya? | Kami ingin mendengar pendapat dari ekosistem tentang topik ini dan menerima masukan di sini. |
| Situs penyedia topik | Tetapkan situs tertentu yang menghosting konten untuk banyak Topics sebagai "Situs Penyedia Topik Khusus" dan latih pengklasifikasi berdasarkan tag yang diberikan di halaman web. | Kami membahas proposal tersebut di sini, dan menantikan masukan tambahan. |
Protected Audience API (sebelumnya FLEDGE)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pembentukan Lalu Lintas | Dampak performa pemfilteran berbasis SSP untuk mengoptimalkan pemuatan kueri per detik (QPS) | Kami telah menghabiskan banyak waktu untuk memikirkan pembentukan traffic dan rekomendasinya adalah agar SSP memanfaatkan cache. |
| Menguji volume | Menguji Protected Audience karena SSP dan DSP kesulitan untuk mendapatkan volume traffic yang besar. | Kami terus berinteraksi dengan partner SSP dan DSP untuk mengadopsi dan menguji Protected Audience. Ketersediaan Umum telah dimulai dan kami yakin bahwa persentase traffic yang mengaktifkan PA akan membuatnya lebih disukai partner untuk diuji. |
| Kompleksitas | Penerapan solusi Protected Audience memerlukan upaya dan biaya yang signifikan. | Kami memahami bahwa teknologi baru sulit untuk diadopsi, termasuk Privacy Sandbox. Tim Privacy Sandbox bekerja sama dengan berbagai pemangku kepentingan untuk mengedukasi dan mendukung upaya mereka, serta terus mengevaluasi percepatan lainnya untuk mendukung adopsi ekosistem. |
| Trusted Execution Environment | Dukungan untuk Trusted Execution Environments (TEE) di lingkungan cloud non-publik | Selagi kami mengeksplorasi opsi-opsi yang berpotensi mendukung di luar solusi berbasis cloud, saat ini kami tidak dapat mendukung TEE lokal mengingat batasan keamanan lokal yang akan memerlukan evaluasi yang memakan waktu untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung GCP selain AWS) adalah hal yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan diperlukannya persyaratan tersebut. |
| Struktur Biaya | Proposal Layanan Bidding & Lelang akan meningkatkan biaya dan kompleksitas untuk Teknologi Iklan dibandingkan dengan model sisi klien. | Saat ini kami sedang mengembangkan panduan untuk memperkirakan biaya mendukung alur kerja bidding dan lelang di server Bidding & Lelang, yang akan berkorelasi dengan penggunaan teknologi iklan, yang memenuhi salah satu sasaran desain kami. |
| Linimasa K-Anon | Kapan batasan k-anonymity yang direncanakan akan diterapkan pada `renderUrl` ? | Kami sedang mengerjakan penjelasan untuk rentang waktu penegakan yang akan segera kami rilis. |
| Pembatasan runAdLelang | Dapatkah Chrome membatasi runAdAuction agar hanya dapat dipanggil dari halaman teratas? |
Meskipun desain kami sepenuhnya mendukung runAdAuction agar dapat dipanggil dari halaman teratas, kami yakin akan lebih berbahaya bagi penayang untuk membatasinya agar hanya dapat dipanggil dari domain teratas.Kami telah secara khusus mendengar dari ekosistem bahwa Privacy Sandbox perlu meminimalkan beban pada penayang dan pengiklan. Masukan tersebut sejalan dengan prinsip umum pengembangan web bahwa pemilik situs dapat menggunakan alat pihak ketiga dalam menjalankan situs mereka. Tujuan Privacy Sandbox adalah untuk mendorong ekosistem yang sehat tanpa perlu menentukan cara kerja penayang dan teknologi iklan. Dengan memungkinkan penayang memilih cara dan siapa yang memanggil runAdAuction di situs mereka, kami yakin kami menawarkan fleksibilitas kepada penayang untuk menemukan jalur terbaik bagi persyaratan mereka. |
| Dukungan implementasi | Dapatkah Chrome membuat atau berkontribusi pada penerapan open source dari lelang multipenjual? | Privacy Sandbox bertujuan untuk mengembangkan teknologi yang menjaga privasi yang tidak mengandalkan cookie pihak ketiga atau ID lintas situs lainnya. Kami ingin mendorong ekosistem yang sehat tanpa perlu menentukan cara kerja teknologi iklan. Kami telah memublikasikan panduan tentang cara kerja API di repositori GitHub dan terbuka untuk mengeksplorasi solusi dengan industri ini. Kami tidak berencana membuat implementasi tertentu karena tugas utama kami adalah membangun teknologi platform, bukan menentukan strategi untuk menggunakan teknologi tersebut. Teknologi kami akan membantu perusahaan teknologi iklan memberikan layanan terbaik kepada pelanggan mereka dengan pagar pengaman privasi yang tepat bagi konsumen. |
| Lelang multi-penjual | Apakah Chrome akan memaksa berbagi pemenang "kontekstual" dengan lelang komponen? | Protected Audience API dirancang untuk menawarkan kemampuan bagi pihak yang memulai lelang multi-penjual untuk meneruskan informasi ke lelang komponen (catatan: hanya sebelum memulai lelang). Meskipun demikian, kami tidak melihat cara bagi browser untuk membedakan apakah informasi tertentu dapat unggul secara kontekstual atau tidak, sehingga kami tidak dapat menerapkan pemblokiran atau mewajibkan informasi tertentu. |
| Preferensi pengguna untuk pelacakan izin | Adtech menanyakan kepada PA cara menerapkan pelacakan izin pengguna dengan benar | Respons kami mencakup apa yang kami katakan pada Kuartal 1: "Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara materi iklan dipilih." Kami membahas sejumlah skenario terkait masalah ini selama Rapat Protected Audience WICG Mei dan kami menerima masukan dan diskusi tambahan tentang masalah ini. |
| Audiens Kustom | Apakah kasus penggunaan SSP yang terkait dengan pembuatan Audiens Kustom akan didukung oleh Protected Audience API? | Protected Audience API memungkinkan SSP dan penyedia teknologi iklan lainnya memiliki dan mengelola Audiens Kustom. Panduan lebih lanjut tentang cara SSP dapat berintegrasi dengan PA API sedang dikembangkan dan akan tersedia untuk SSP serta penyedia teknologi iklan lainnya guna mendukung upaya integrasi mereka. |
| Format | Apakah video didukung oleh Protected Audience API? | Iklan video ditayangkan dengan salah satu dari dua cara: sebagai XML VAST atau HTML (iklan outstream yang pada akhirnya dapat memuat XML VAST ke pemutar video). Pembeli dapat menampilkan salah satu format melalui renderURL. Spesifikasi VAST baru-baru ini diperbarui untuk mendukung Attribution Reporting API. Situs yang menayangkan iklan video harus melakukan persiapan untuk cara penayangan iklan melalui Protected Audience API. Hal ini berarti memastikan tag penempatan dapat meneruskan URL dari iframe Protected Audience ke pemutar video. Untuk Frame dengan Fence, kami akan berupaya memenuhi kebutuhan video sebelum persyaratan untuk menggunakan Frame dengan Fence, yaitu paling cepat tahun 2026. |
| Kecepatan | Bagaimana cara kerja kasus penggunaan Kecepatan dengan Protected Audience API? | Kami menghargai masukan tersebut. Kami ingin melihat lebih banyak contoh permintaan ini dengan detail selengkapnya berasal dari lebih banyak partner SSP karena hal ini sebagian besar merupakan masalah DSP hingga saat ini. |
| Frekuensi update | Frekuensi panggilan dari dailyUpdate (hingga 1 per grup minat per hari) mungkin tidak cukup untuk kasus penggunaan tertentu, seperti memperbarui informasi produk. |
Kami menghargai masukan tersebut. Ada solusi lain yang tersedia untuk memungkinkan teknologi iklan menggunakan sinyal yang diperbarui dalam berbagai ritme seperti pencarian K/V. |
| Kontrol Kualitas Iklan | Bagaimana cara penayang menerapkan kendali mutu iklan? | Saat ini, Protected Audience API menawarkan fungsi bagi penayang untuk memberi tahu SSP tentang kontrol tertentu yang dapat mereka tetapkan sebagai bagian dari konfigurasi lelang, pra-bidding (yaitu daftar yang ditolak berdasarkan label yang terkait dengan iklan). Kami menerima masukan tentang fungsi tambahan yang mungkin diperlukan ekosistem. |
| Proses debug | Kapan fungsi forDebuggingOnly akan dihapus? |
Kami berencana menghentikan forDebuggingOnly karena peristiwa kerugian akibat penghentian cookie pihak ketiga. Kami berencana untuk segera menghentikan forDebuggingOnly atas acara yang menang di tahun 2026. |
| Grup Minat Lintas Perangkat | Proposal untuk mengaktifkan grup minat lintas perangkat bagi agen pengguna yang diautentikasi | Kami mengevaluasi proposal ini, tetapi kekhususan tinggi penargetan lintas-perangkat menimbulkan masalah privasi yang signifikan, seperti yang dibahas dalam Masalah GitHub ini. |
| (Juga dilaporkan di K1) Pemasaran Ulang Dinamis | Apakah Pemasaran ulang dinamis masih dapat dilakukan dengan Protected Audience API setelah cookie pihak ketiga tidak digunakan lagi? | Kami yakin kasus penggunaan ini dapat dilakukan menggunakan Protected Audience, seperti yang dijelaskan di sini. |
| Data terkait klik | Tambahkan data terkait klik ke browserSignals. |
Saat ini kami meminta klarifikasi tentang kapan klik terjadi untuk memberikan posisi awal. |
| (Juga dilaporkan pada Kuartal 4 2022) Fungsi yang ditentukan pengguna di Protected Audience | Bagaimana fungsi yang ditentukan pengguna (UDF) akan didukung di Protected Audience API? Ini adalah fungsi yang dapat diprogram oleh pengguna akhir untuk memperluas fungsi API. | Teknologi iklan yang mengangkat masalah ini juga menyebutkan bahwa mereka masih mengevaluasi apa yang dapat dilakukan dengan UDF sehingga belum ada masukan yang dapat ditindaklanjuti di sini, belum ada reaksi hingga setidaknya Ketersediaan Umum. |
| Mata uang | Jumlah mata uang tidak boleh dinyatakan menggunakan floating point. | Kami telah membahas masalah ini secara mendetail di sini. |
| Kemampuan pemilihan iklan non-DSP | Apa peran Server Iklan dalam lelang Protect Audience API? | Kami mengetahui permintaan untuk Server Iklan untuk terus menawarkan layanan pemilihan iklan pasca-bid / pengoptimalan materi iklan dinamis. Saat ini, kami sedang menilai analisis kesenjangan mendetail yang ada antara Protected Audience API saat ini dan permintaan tersebut. |
| GenerateBid | Dukungan untuk proposal Google Ads untuk menampilkan lebih dari satu iklan kandidat per grup minat iklan dari generateBid dan membuat kandidat tersebut mendapatkan skor di `scoreAd`. |
Hal ini sedang dievaluasi. Kami menantikan masukan tambahan di sini. |
| Pesanan Lelang | Apakah Lelang Protected Audience API harus menjadi lelang terakhir yang dijalankan agar dapat mengambil input dari hasil semua lelang lainnya? | Tidak ada persyaratan teknis agar Protected Audience API dapat berjalan terakhir. |
| Navigasi yang tidak dimulai oleh pengguna | Mengekspos navigasi yang tidak dimulai pengguna | Kami meninjau permintaan ini dan membahasnya di sini serta menerima masukan tambahan. |
| Menyimpan ke cache | SSP tidak boleh membuat perBuyerSignals DSP tertentu dari cache jika status pengguna berubah. | Kami memahami bahwa penyimpanan dalam cache tidak berfungsi untuk setiap kasus penggunaan sinyal perBuyer dan kami sedang mengevaluasi opsi lebih lanjut. Kami menantikan masukan tambahan dari ekosistem terkait apakah cache berfungsi untuk kasus penggunaan mereka atau tidak. |
| Attribution Reporting dan Protected Audience | Bagaimana cara Attribution Reporting API dan Protected Audience API bekerja sama? | Integrasi saat ini tersedia untuk Protected Audience API untuk kedua mode Attribution Reporting API (laporan tingkat peristiwa dan ringkasan). Kami telah memberikan informasi selengkapnya tentang peningkatan integrasi Protected Audience API dan Attribution Reporting pada 1 Juni. Anda dapat membacanya di sini. |
| Endpoint Server | Akankah endpoint server menjadi Server Agregasi Tepercaya dalam desain akhir? | Endpoint server adalah endpoint yang dikelola teknologi iklan dan terpisah dari Server Agregasi Tepercaya yang digunakan untuk memproses laporan yang dikumpulkan dan diubah. Saat ini kami tidak memiliki perubahan apa pun yang direncanakan untuk endpoint pelaporan. Desain saat ini bertujuan untuk memastikan bahwa laporan gabungan itu sendiri (dengan payload terenkripsi) tidak membocorkan data lintas situs, sehingga endpoint tepercaya tidak diperlukan. Detail lainnya adalah bahwa teknologi iklan yang berbeda kemungkinan akan memiliki strategi pengelompokan yang diinginkan berbeda. Kami menantikan masukan tambahan di sini. |
| WebIDL | Spesifikasi Protected Audience API saat ini tidak kompatibel dengan spesifikasi WebIDL. | Kami mengevaluasi masukan ini dan membahas masalahnya di sini. |
| Pengelolaan Izin | Bagaimana penerusan sinyal izin ditangani di Protected Audience API? | Informasi kontekstual tidak berada dalam cakupan Protected Audience API. Kami sedang membahas masalah ini dan menantikan masukan tambahan. |
| Pemasaran Berbasis Akun | Apakah kasus penggunaan pemasaran berbasis akun dapat dilakukan? | Protected Audience API mendukung berbagai kasus penggunaan pemasaran berbasis audiens. Kami terus memahami bagaimana Protected Audience API dapat mendukung kasus penggunaan khusus ini secara optimal, dan menerima masukan tambahan tentang masalah ini dari ekosistem. |
| Lelang komponen | Apa yang dinilai peserta lelang komponen? | Lelang komponen tidak menilai Grup Minat secara langsung, melainkan menilai iklan dan bid yang dikirimkan DSP dari fungsi generateBid. Fungsi generateBid() berjalan per grup minat, dan DSP menampilkan hal berikut saat menjalankan generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Kontribusi Eksternal | Permintaan untuk mendukung kontribusi eksternal pada code base GitHub Server Kunci/Nilai. | Kami ingin memperbarui proses kami yang relevan untuk mendukung kontribusi eksternal ke kode GitHub. |
| Ukuran Grup Minat | Berapa jumlah kunci maksimum yang didukung yang dapat didukung oleh IG? | Batas saat ini adalah 50 kb untuk ukuran satu IG dan kunci dihitung sebagai bagian dari itu. Kami menyambut baik diskusi lebih lanjut tentang batas ukuran. |
| Pengelompokan | Bagaimana cara mengurangi jumlah panggilan server K/V? | Anda dapat menggunakan Header Cache-Control HTTP untuk mengurangi jumlah panggilan K/V. Misalnya, iklan dapat di-cache di seluruh lelang komponen, dan juga di seluruh slot iklan pada satu halaman. |
| Kontrol versi | Dukungan untuk beberapa versi kode teknologi iklan | Layanan Bidding dan Lelang akan mendukung beberapa versi kode teknologi iklan. Dalam Bidding and Auction API, permintaan SelectAd dapat menentukan versi kode yang digunakan untuk permintaan lelang (yaitu untuk bidding / lelang dan juga pelaporan). |
| Penyimpanan Bersama | Mendukung penulisan ke Penyimpanan Bersama di Layanan Bidding dan Lelang. | Saat ini, Layanan Bidding dan Lelang tidak mendukung Penyimpanan Bersama, tetapi kami menerima masukan tambahan tentang mengapa kasus penggunaan tersebut penting bagi ekosistem. |
| Web ke aplikasi | Mendukung berbagi grup minat dari web ke aplikasi. | Web ke aplikasi saat ini tidak tercakup dalam deployment Protected Audience API di Chrome dan Android, tetapi kami ingin mendengar pendapat dari ekosistem tentang pentingnya kasus penggunaan ini. |
| Anonimitas K | Cara menangani penggantian K-Anonymity | Kami sedang membahas masalah ini dan menantikan masukan tambahan. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Konfigurasi Laporan Tingkat Peristiwa VTC Alternatif | Masukan tentang konfigurasi laporan tingkat peristiwa VTC alternatif | Kami menerima beberapa masukan bahwa konfigurasi tingkat peristiwa saat ini tidak optimal dan kami meminta masukan terkait konfigurasi global yang optimal. Kami terbuka untuk menerima masukan tambahan terkait hal ini dan merasa bahwa penjelasan tingkat peristiwa yang fleksibel kami juga akan membantu mengatasi hal ini. |
| Konfigurasi tingkat peristiwa fleksibel | Apa status fitur konfigurasi tingkat peristiwa fleksibel? | Kami telah membagikan dokumentasi tentang konfigurasi tingkat peristiwa yang fleksibel. Fitur ini masih dalam tahap proposal dan kami menantikan masukan lainnya tentang apakah fitur tersebut akan bermanfaat bagi ekosistem. |
| Konfigurasi tingkat peristiwa fleksibel | Bagaimana laporan yang bertentangan dari pihak yang berbeda dapat direkonsiliasi? | Sebagian besar skenario pelaporan ditangani melalui penggunaan laporan gabungan, sedangkan proposal konfigurasi tingkat peristiwa yang fleksibel dikhususkan untuk fleksibilitas tambahan bagi laporan tingkat peristiwa, yang paling sering digunakan untuk kasus penggunaan pengoptimalan. Kami menyambut baik jika ada komentar/masukan terkait ekosistem lainnya terkait skenario ini. |
| Pendaftaran sumber | Bagaimana jika pendaftaran sumber terjadi setelah pendaftaran pemicu? | Saat ini, jika pendaftaran sumber terjadi setelah pendaftaran pemicu, sumber dan pemicu tidak akan dapat diatribusikan satu sama lain. Tampaknya ini merupakan skenario {i>edge case<i}. Kami menerima masukan tambahan terkait masalah ini dan akan berupaya mengatasinya jika ini merupakan skenario yang tampaknya dihadapi oleh banyak teknologi iklan. |
| Bekerja dengan beberapa Agensi Iklan | Bagaimana cara DSP menggunakan Attribution Reporting API jika pengiklan bekerja sama dengan beberapa agensi iklan? | API mendukung pengalihan sehingga dapat digunakan bahkan saat pengiklan bekerja sama dengan beberapa agensi iklan. Selain itu, ada beberapa batasan terkait pengalihan untuk memastikan bahwa API meningkatkan privasi. Kami juga telah mengidentifikasi kemungkinan solusinya menggunakan Shared Storage API untuk skenario tertentu yang dibuat oleh teknologi iklan. Kami menerima masukan tambahan mengenai skenario ini dan akan terus melakukan iterasi berdasarkan masukan tersebut. |
| Batas Tujuan | Kasus penggunaan iklan yang dimuat ulang secara otomatis dapat terpengaruh karena adanya batas tujuan iklan. | Kita telah membahas masalah ini dalam rapat WICG 1 Mei dan mencari masukan tentang batasan yang wajar. Kami telah menambahkan penjelasan Pelaporan Atribusi dengan laporan tingkat peristiwa yang menyatakan bahwa browser dapat membatasi jumlah eTLD+1 `destination` yang diwakili oleh situs sumber. (Lihat permintaan pull). |
| Attribution Reporting dan Protected Audience | Bagaimana cara Attribution Reporting API dan Protected Audience API bekerja sama? | Integrasi saat ini tersedia untuk Protected Audience API untuk kedua mode Attribution Reporting API (laporan tingkat peristiwa dan ringkasan). Kami telah memberikan informasi selengkapnya tentang peningkatan integrasi Protected Audience API dan Attribution Reporting pada 1 Juni. Anda dapat membacanya di sini. |
| Konfigurasi tingkat peristiwa fleksibel | Bagikan praktik terbaik untuk simulasi derau setelah parameternya dapat dikonfigurasi. | Kami telah membagikan kode di GitHub yang dapat digunakan siapa saja untuk menilai perolehan informasi dan dampak derau untuk konfigurasi tingkat peristiwa fleksibel apa pun yang ingin mereka uji. Kami ingin mendengar pendapat dari siapa saja yang memilih untuk menguji kode dan ingin memberikan masukan. |
| Pengukuran Atribusi Lintas Aplikasi dan Web | Kapan pengukuran atribusi lintas aplikasi dan web akan tersedia? | Kami mengumumkan pada 9 Mei eksperimen untuk Pengukuran Atribusi Lintas Aplikasi dan Web melalui Attribution Reporting API. Meskipun Ketersediaan Umum direncanakan untuk API pengukuran dan relevansi di Chrome 115, Pengukuran Atribusi Lintas Aplikasi dan Web saat ini tidak direncanakan untuk mencapai ketersediaan umum dengan Chrome 115. |
| Hapus duplikat konversi | Bagaimana solusi pengukuran independen dapat direkonsiliasi berdasarkan ARA? | Seperti praktik standar saat ini, pengiklan akan bekerja sama dengan penyedia pengukuran independen pihak ketiga untuk menghapus duplikat pelaporan konversi. Kami telah menawarkan referensi tentang cara menghapus duplikat konversi untuk pelaporan tingkat peristiwa. |
| Kehilangan data selama pembaruan database Attribution Reporting | Apakah akan ada data yang hilang saat Chrome memperbarui Database Attribution Reporting seperti yang diumumkan? | Mulai Chrome Stabil 115, kami akan mulai mengaktifkan Relevansi dan Measurement API untuk sebagian pengguna Chrome secara default. Ketersediaan umum ini akan ditingkatkan seiring kami memantau potensi masalah. Tujuannya adalah mencapai ketersediaan 100% selama jangka waktu beberapa minggu, paling lambat Q3 2023. Hal ini akan bertepatan dengan akhir uji coba asal Relevansi dan Pengukuran. Mulai bulan Juli, penguji akan dapat mendaftar untuk mendapatkan akses ke API ini pada saat ketersediaan umum. Hal ini akan memberikan tumpang-tindih antara ketersediaan uji coba origin dan ketersediaan umum melalui pendaftaran. Token uji coba origin Anda akan berlaku hingga 19 September, tetapi sebaiknya Anda mendaftar ke API sebelum habis masa berlakunya agar dapat bertransisi dengan lancar keluar dari uji coba origin tanpa mengganggu pengujian yang sedang berlangsung. Seperti yang disebutkan dalam pengumuman ini, data yang terdaftar dari versi lama (M113 dan versi sebelumnya) tidak akan dimigrasikan setelah update, sehingga mungkin akan terjadi kehilangan data. Kehilangan data ini tidak akan muncul di pelaporan debug, dan kita akan mencoba menghindari kehilangan data dari 114 ke 115. |
| Penagihan | Menggunakan Attribution Reporting untuk penagihan biaya per konversi | Seperti yang dinyatakan dalam artikel ini, Attribution Reporting API mungkin tidak sesuai untuk kebutuhan penagihan biaya per konversi karena derau yang ditambahkan ke laporan ringkasan dan tingkat peristiwa. Kami mendorong para pemain ekosistem untuk memberikan masukan tentang dampaknya pada berbagai model penagihan oleh Attribution Reporting API di GitHub. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Perubahan penundaan laporan gabungan | Reaksi positif terhadap proposal untuk mengubah penundaan Laporan gabungan dari [10-60 menit] menjadi [0-10 menit] setelah masukan dari ekosistem | Kami senang melihat reaksi positif terhadap perubahan yang diusulkan, dan mendorong ekosistem untuk terus memberikan masukan terkait proposal kami. |
| Solusi di lokasi | Dapatkah Layanan Agregasi di-deploy di pusat data lokal? | Selagi kami mengeksplorasi opsi-opsi yang berpotensi mendukung di luar solusi berbasis cloud, saat ini kami tidak dapat mendukung TEE lokal mengingat batasan keamanan lokal yang akan memerlukan evaluasi yang memakan waktu untuk Privacy Sandbox. Mengingat persyaratan keamanan Privacy Sandbox dan tantangan signifikan yang dihadirkan oleh deployment lokal, kami percaya bahwa terus memperluas dan meningkatkan deployment berbasis cloud (misalnya, mendukung GCP selain AWS) adalah hal yang paling bermanfaat bagi ekosistem. Namun, kami menerima masukan tambahan tentang alasan diperlukannya persyaratan tersebut. |
| Memproses ulang laporan untuk jangka waktu yang berbeda | Kemampuan untuk memproses ulang laporan untuk jangka waktu yang berbeda | Kami telah mendengar permintaan serupa untuk dapat membagi batch untuk rentang tanggal yang berbeda. Salah satu proposalnya adalah mengizinkan kemampuan untuk memperpanjang ID bersama dengan label yang ditentukan oleh teknologi iklan, sehingga laporan dapat dibagi ke dalam batch yang berbeda. Kami sedang dalam proses awal mengevaluasi proses ini dan akan terus memperbarui ekosistem saat proposal ini berkembang. |
| Implikasi Privasi dari Trusted Execution Environment | Sentimen positif terhadap implikasi privasi Trusted Execution Environments | Kami senang mendengar reaksi positif dari ekosistem terkait proposal kami, dan kami menerima masukan tambahan seiring upaya kami untuk terus melakukan iterasi dan pengembangan. |
| Persyaratan Layanan | Kapan batas waktu untuk menyetujui persyaratan layanan Layanan Agregasi? | Meskipun kami belum menentukan batas waktu untuk menyetujui persyaratan dan ketentuan, kami akan mendorong perusahaan ekosistem untuk menyetujui persyaratan dan ketentuan sesegera mungkin untuk mencegah keterlambatan dalam pendaftaran. Sebaiknya perusahaan menghubungi kami jika ada pertanyaan. |
| Penemuan Utama | Fitur penemuan utama akan memungkinkan penguji untuk mengkueri laporan gabungan tanpa memerlukan daftar eksplisit kemungkinan kombinasi kunci guna memproses laporan ringkasan untuk atribusi lintas jaringan guna meningkatkan performa dan akurasi. | Kami sedang mempelajari berbagai kemungkinan solusi dan solusi, serta menerima masukan tambahan dari ekosistem ini. |
API Agregasi Pribadi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Asal Pelaporan | Bagaimana cara asal pelaporan ditentukan? | Asal pelaporan selalu merupakan asal skrip dari pemanggil Agregasi Pribadi. |
| Ruang kunci 128 bit | Kejelasan pada pembatasan ruang kunci 128-bit | Kami akan membuat batasan spasi kunci ini lebih jelas dan mengatasi inkonsistensi di seluruh halaman. Sebaiknya gunakan strategi hashing agar tetap berada dalam keyspace ini. |
| Kontribusi maksimum per laporan | Batas saat ini sebanyak 20 kontribusi per laporan terlalu rendah. | Daripada meningkatkan jumlah maksimum kontribusi, kami siap mempertimbangkan pembagian laporan, bukan memotongnya pada batas yang ditentukan. Kami akan melibatkan ekosistem saat proposal ini berkembang. |
| Pelaporan jangkauan | Meminta pelaporan lintas platform/lintas perangkat jangkauan. Jangkauan adalah metrik dasar dalam iklan brand. Pengiklan mengandalkan perkiraan lintas platform/lintas perangkat untuk pelaporan Jangkauan dan Frekuensi guna menganalisis kampanye dan mengalokasikan pembelanjaan. Model jangkauan menggunakan cookie pihak ketiga sebagai sinyal untuk mengukur iklan yang ditampilkan di lingkungan pihak ketiga, sehingga teknologi iklan telah meminta solusi alternatif setelah cookie pihak ketiga tidak digunakan lagi. |
Tim Privacy Sandbox sedang mempelajari berbagai fitur untuk mendukung metodologi jangkauan lintas-domain setelah penghentian penggunaan cookie pihak ketiga. Kami menantikan masukan tambahan dari ekosistem. |
Batasi Pelacakan Terselubung
Petunjuk Klien Agen Pengguna/Pengurangan Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada Kuartal 1 2023) Petunjuk untuk faktor bentuk tambahan | Meminta Petunjuk Klien Agen Pengguna (UA-CH) untuk memberikan faktor bentuk tambahan seperti TV, VR | Kami masih menyusun beberapa keputusan desain penting (apakah akan memberikan nilai tunggal seperti "TV", atau daftar kemampuan faktor bentuk), tetapi tetap tertarik untuk membuat prototipe ide ini. |
| Anggaran Privasi | Pembatasan Anggaran Privasi dapat menyebabkan permintaan UA-CH menjadi nondeterministik jika terlalu banyak permintaan yang dikirim. | Kami tidak memiliki pembaruan terkini terkait proposal Anggaran Privasi saat ini, tetapi kami telah berkomitmen untuk tidak membatasi permintaan petunjuk klien UA sebelum cookie pihak ketiga tidak digunakan lagi. |
| Kompatibilitas Situs | Situs menggunakan merek UA-CH untuk membatasi browser tertentu agar tidak mengakses situs. | Ada kasus penggunaan yang valid untuk memiliki daftar merek, dan salah satunya adalah kompatibilitas. UA dapat memiliki beberapa brand untuk mengatasi masalah ini. |
Perlindungan IP (sebelumnya Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penipuan & Penyalahgunaan | Bagaimana perusahaan dapat menyiapkan tindakan antipenipuan dengan Perlindungan Kekayaan Intelektual? | Kami memahami pentingnya kasus penggunaan antipenipuan dan kemungkinan dampaknya terhadap kasus penggunaan tersebut. Kami berencana untuk memublikasikan detail selengkapnya terkait dukungan antipenipuan pada musim panas ini. Kami mencari masukan ekosistem tentang bagaimana kami dapat mendukung kasus penggunaan antipenipuan dengan lebih baik. |
| GeoIP | Informasi selengkapnya tentang linimasa pengujian dan deployment untuk GeoIP | Chrome baru-baru ini memublikasikan informasi baru yang menjelaskan rencana GeoIP kami. Kami berencana untuk memublikasikan informasi lebih lanjut tentang jadwal deployment pada Kuartal 3. Pada awalnya, kami akan meluncurkan Perlindungan IP sebagai fitur keikutsertaan pengguna pada sebagian kecil traffic. Alasannya adalah karena kami menyadari bahwa proposal ini mungkin melibatkan beberapa perubahan signifikan bagi perusahaan, dan kami ingin memberikan waktu kepada ekosistem untuk menyesuaikan dan memberikan masukan sebelum fitur ini diluncurkan secara lebih luas. |
| Autentikasi akun | Bagaimana cara otentikasi akun dengan server {i>proxy<i} bekerja sebenarnya? | Kami berencana untuk memublikasikan lebih banyak detail tentang autentikasi akun nanti pada musim panas ini, meskipun kami telah menyampaikan beberapa pertimbangan awal. |
Mitigasi Pelacakan Kembali
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Panduan Pengujian | Informasi tentang cara menguji mitigasi Pelacakan Pantulan | Kami memublikasikan postingan blog pada bulan Mei yang berisi informasi lebih lanjut tentang cara menguji Mitigasi Pelacakan Kembali. |
| Dokumentasi | Kejelasan dalam Proposal Pelacakan Pantulan | Proposal saat ini masih dalam proses pengerjaan dan Chrome terus memperbarui proposal untuk memberikan kejelasan dan informasi kepada ekosistem. Kami sedang berupaya memberikan detail lebih lanjut dan menerima masukan tambahan jika ada. |
| Penghapusan cookie | Apakah Mitigasi Pelacakan Kembali akan menghapus semua cookie di domain? | Mitigasi pelacakan kembali (BTM) akan menghapus semua penyimpanan dan semua cache, seperti yang dijelaskan di sini. |
| Mengakali Mitigasi Pelacakan Kembali | Klasifikasi pelacak pantulan dapat diabaikan dengan melakukan pengalihan dengan pop-up atau tab baru. | Spesifikasi Mitigasi Pelacakan Kembali masih dalam proses. Sejauh ini kami berfokus pada pengalihan tab yang sama, tetapi kami berencana untuk menangani alur pop-up di masa mendatang. Kami menantikan masukan tambahan di sini. |
Anggaran Privasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Penargetan Kedekatan | Anggaran Privasi dapat memengaruhi kasus penggunaan penargetan jarak. | Kami telah menerima masukan terkait masalah ini dan ingin mengetahui lebih lanjut dampak potensial dari ekosistem ini. |
Memperkuat batas privasi lintas situs
Set Pihak Pertama
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada kuartal sebelumnya) Batas Domain | Permintaan untuk menambah jumlah domain terkait | Chrome sedang mengevaluasi batas numerik yang sesuai untuk subset Terkait yang akan menyeimbangkan privasi dan utilitas untuk kasus penggunaan yang telah diidentifikasi. Sejak awal paling awal, Chrome menyampaikan bahwa jumlah persis untuk subset Terkait belum final. |
| Kasus Penggunaan yang Disematkan | Dukungan untuk kasus penggunaan Tersemat yang memerlukan Set Pihak Pertama, CHIP, dan penyimpanan bersama | Chrome telah menerima masukan terkait kasus penggunaan ini, dan tim sedang menyelidiki serta menerima masukan tambahan. |
| Pengelolaan Repositori | Informasi tentang kebijakan untuk menghapus Set Pihak Pertama dari repositori GitHub jika ada perbedaan atau kelalaian | Chrome telah menerima masukan tentang kasus penggunaan ini. Tim kami sedang menyelidikinya dan menerima masukan tambahan. |
| Edukasi Pengguna | Chrome akan meningkatkan awareness dan pemahaman pengguna tentang Set Pihak Pertama untuk mendorong penggunaan. | Chrome berkomitmen untuk mengedukasi pengguna tentang Set Pihak Pertama, dan telah memublikasikan artikel Pusat Bantuan (ditautkan dari UI Chrome) untuk penerapan ini. Chrome juga berinvestasi untuk terus mempelajari cara terbaik mengedukasi pengguna dalam konteks yang sesuai. |
| Posting 3PCD | Cookie pihak ketiga akan terus ada dalam Set Pihak Pertama setelah cookie pihak ketiga tidak lagi digunakan. | Meskipun requestStorageAccess dan requestStorageAccessFor memang membuat cookie pihak ketiga tersedia lagi untuk kasus penggunaan tertentu yang ditentukan dengan jelas, cookie tersebut sekarang memerlukan pemanggilan aktif oleh situs, bukan tersedia secara default, seperti dengan status cookie pihak ketiga saat ini (di Chrome).Meskipun pemanggilan dalam satu rangkaian tidak memerlukan persetujuan pengguna, pengguna dapat mencegahnya dengan memilih tidak ikut serta dalam perilaku ini di Setelan. Informasi lebih lanjut tersedia untuk pengguna di artikel Pusat Bantuan (ditautkan dari UI Chrome). Kami berencana untuk memperluas panduan developer yang ada seiring peningkatan FPS hingga 100%. |
| Pengiriman Set Pihak Pertama | Ganti nama .well-known/first-party-set yang diperlukan untuk menyertakan ekstensi .json. |
Kami telah melakukan perubahan ini untuk memastikan paket hosting web tertentu didukung. |
| Pendaftaran IANA | first_party_sets.JSON harus terdaftar di IANA |
Kami sedang mempertimbangkan proposal ini dan menantikan masukan tambahan di sini. |
API Fenced Frames
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Pemblokiran Iklan | Frame dengan Fence dapat memudahkan pemblokir iklan untuk memblokir iklan. | Ekstensi dapat berinteraksi dengan frame dengan fence mirip dengan cara berinteraksi dengan iframe. URL sebenarnya yang akan dibuka bingkai dengan fence juga akan terlihat oleh ekstensi, sehingga ekstensi dapat menerapkan aturan pencocokan URL apa pun untuk pemblokiran seperti yang dilakukan di iframe. Hanya memblokir semua frame dengan fence tanpa syarat dapat merusak kasus penggunaan non-iklan untuk frame dengan fence. |
API Penyimpanan Bersama
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Adopsi yang lebih luas | Penyimpanan Bersama harus menjadi standar tingkat industri yang tersedia di seluruh browser. | Kami menerima dan mengonfirmasi masukan ini. Chrome terus berpartisipasi secara aktif dalam W3C untuk memperjuangkan proposal, mencari masukan, dan mendorong penggunaan. |
| Gerbang Output | Gerbang output Penyimpanan Bersama terlalu terbatas. | Kami mempertimbangkan masukan ini dan menantikan masukan ekosistem tambahan tentang alasan output gate terlalu terbatas. |
| Kepatuhan terhadap Peraturan | Bagaimana Penyimpanan Bersama akan menangani kepatuhan terhadap peraturan seperti kebijakan retensi data? | Penyimpanan Bersama memberikan fleksibilitas untuk menerapkan dan menyesuaikan logika guna mengontrol masa berlaku dan berakhirnya masa berlaku data yang disimpan. Teknologi iklan dapat memperbarui atau menghapus data Penyimpanan Bersama berdasarkan stempel waktu penulisan. |
| Pengujian A/B | Bagaimana cara melakukan pengujian A/B untuk Shared Storage dan Protected Audience API? | Kami sedang berupaya untuk memublikasikan panduan tambahan mengenai masalah ini dan berharap dapat membagikan detail selengkapnya di masa mendatang. |
| Batas Penyimpanan Bersama | Apa yang akan terjadi setelah batas Penyimpanan Bersama tercapai? | Jika batas ini tercapai, input lebih lanjut tidak akan disimpan. |
| Beberapa akses pada pemuatan halaman yang sama | Apa yang terjadi ketika Penyimpanan Bersama diakses beberapa kali pada pemuatan halaman yang sama? | Cara terbaik untuk menangani hal ini adalah melalui fungsi window.sharedStorage.append(key, value). Daripada memperbarui nilai untuk setiap iklan, yang dapat menyebabkan konflik jika ada beberapa iklan. Fungsi {i>add<i} hanya akan menambahkan nilai baru ke akhir nilai yang sudah ada sebelumnya. |
| Fungsi iframe | Apakah Penyimpanan Bersama akan mendukung fungsi iframe tertentu setelah cookie tidak lagi berfungsi setelah cookie pihak ketiga tidak digunakan lagi? | Setelah cookie pihak ketiga tidak digunakan lagi, penyimpanan lokal di iframe akan dipartisi oleh situs tingkat atas, tetapi iframe itu sendiri tidak akan diblokir. Data dalam penyimpanan lokal iframe tidak dapat direplikasi di beberapa situs tingkat atas, tetapi penyimpanan lokal masih dapat digunakan dalam iframe. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Batas partisi | 10 KiB per situs yang dipartisi masih cukup besar, dan kami ingin menurunkannya. | Firefox telah menunjukkan posisi positif pada CHIPS. Untuk dukungan Webkit, sebaiknya developer memberikan masukan kepada Apple secara langsung mengenai masalah GitHub ini. Hal ini terkait kasus penggunaan cookie berpartisi lebih disukai daripada penyimpanan berpartisi. |
| Sematan terautentikasi | CHIP dapat memengaruhi alur login SSO saat ini karena partisi yang berbeda memengaruhi penyematan yang diautentikasi. | Kami ingin memanfaatkan Storage Access API (dengan perintah pengguna) untuk mendukung kasus penggunaan sematan yang diautentikasi, dan baru-baru ini mengirim intent-to-prototype. |
| Kebijakan Seumur Hidup | Apakah potensi kebijakan sepanjang waktu akan diterapkan ke cookie pihak pertama? | Saat ini kami tidak berencana untuk menerapkan batas sepanjang waktu pada cookie pihak pertama. |
FedCM
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Dukungan Otorisasi OAuth | Selaraskan pemberian otorisasi cakupan Oauth non-profil | Kami secara aktif mencari masukan dari komunitas Web Identity melalui CG FedID W3C mengenai cara terbaik untuk mendukung otorisasi di luar autentikasi dasar setelah cookie pihak ketiga tidak digunakan lagi. |
| Dukungan untuk SAML | Sesuaikan persyaratan untuk dukungan SAML | Tim ini secara aktif mencari masukan dari komunitas riset dan edukasi tentang kebutuhan dukungan SAML (selain dukungan OpenID-connect) setelah cookie pihak ketiga tidak digunakan lagi. |
Memerangi spam dan penipuan
Private State Token API (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Menjelajahi sinyal baru | Beberapa partner telah menyatakan sentimen positif terhadap eksplorasi sinyal integritas perangkat atau kepercayaan pengguna yang difasilitasi browser. Secara umum, mereka juga berhati-hati tentang apakah sinyal baru yang dibuat untuk tujuan tertentu sudah memadai untuk mempertahankan tingkat deteksi penipuan saat ini. | Kami sangat antusias untuk mempelajari proposal baru bersama dalam komunitas antipenipuan dan keamanan web, serta memahami dan menyampaikan kekhawatiran mereka. Itulah sebabnya "memerangi spam dan penipuan" telah menjadi alur kerja inti Privacy Sandbox dan alasan kami terus memprioritaskan investasi dalam menjaga keamanan web seiring kami meningkatkan privasi pengguna. |
| Masukan positif terkait PST | Beberapa partner telah menyatakan minatnya dalam menguji atau menggunakan PST untuk berbagai kasus penggunaan antipenipuan atau keamanan web. | Kami sangat senang mendengar dukungan dan minat untuk mempelajari lebih lanjut solusi baru yang memanfaatkan PST. Kami memiliki resource dan kode contoh yang tersedia melalui situs developer Chrome, dan kami menantikan masukan lebih lanjut. |
| Penipuan dan Penyalahgunaan | Panduan untuk Pencegahan / Deteksi Penipuan Iklan dalam pengukuran setelah penghentian penggunaan cookie pihak ketiga saat ID tidak lagi tersedia. | Kami telah memperkenalkan alat seperti private state token, yang membantu memulihkan beberapa sinyal yang hilang oleh cookie pihak ketiga untuk tujuan antipenipuan, tetapi dengan kontrol privasi baru. Kami secara aktif berinvestasi dalam proposal antipenipuan dan anti-penyalahgunaan baru untuk mempertahankan kemampuan dengan perubahan Privacy Sandbox lainnya. |
| Rasio informasi penerbit ke asal | Tarif informasi dari penerbit hingga asal cukup tinggi untuk mengidentifikasi pengguna unik. | Kami telah memperbarui spesifikasi agar lebih jelas tentang data pengguna apa yang dapat disampaikan menggunakan Token Status Pribadi. Sesuai desainnya, hingga enam kunci publik dapat digunakan pada satu waktu, yang bisa mewakili sebuah "status" untuk pengguna tertentu. Kumpulan kunci ini hanya dapat diperbarui setiap 60 hari (kecuali dalam kasus yang jarang terjadi saat rotasi kunci darurat diperlukan), yang memperlambat potensi untuk menggabungkan data pengguna tambahan dari waktu ke waktu. Dengan setiap API web baru, ada keseimbangan antara utilitas yang disediakan dan informasi bersih pengguna baru yang disediakannya. Kami memperkirakan bahwa PST mencapai jumlah yang sesuai dalam melindungi privasi pengguna sekaligus memungkinkan kasus penggunaan antipenipuan utama yang terpengaruh oleh penghentian cookie pihak ketiga. |
| Integrasi Pengambilan | Integrasi fetch rumit dan tidak diperlukan. |
Ada kelebihan dan kekurangan dalam menggunakan fetch, dan kami ingin terus melakukan standardisasi lebih lanjut dalam ekosistem web, tetapi menurut kami masih terlalu dini untuk melakukan perubahan ini sampai kami memiliki gambaran yang lebih jelas tentang seperti apa standar tersebut nantinya. Jika dan saat standar muncul, kami juga berkomitmen untuk mengalihkan developer web ke standar tersebut secara bertanggung jawab. |
| Lokasi Penyimpanan | Konfigurasi kunci Token Status Pribadi harus disimpan di lokasi yang sama dengan PrivacyPass Protocol. | Saat menguji selama Uji Coba Origin, developer menyatakan bahwa mereka lebih memilih fleksibilitas untuk menyimpan kunci di URL umum, bukan di direktori .well-known. Format komitmen utama di PrivacyPass tidak terlalu cocok untuk versi yang kumpulan key-nya dimaksudkan untuk memungkinkan nilai "metadata publik" implisit. Jika varian PrivacyPass akhirnya distandarkan dengan metadata publik (baik sebagai POPRF, RSA blinding parsial, atau keyset), kami mungkin akan beralih ke versi PST mendatang untuk mendukung hal tersebut. |
| Implementasi header API | Pertanyaan terkait penerapan header API | Seiring dengan semakin terstandardisasinya API dan semakin matangnya ekosistem API ini, semoga kita dapat mendukung versi non-header standar API ini dan berpotensi menghentikan penggunaan versi header jika penggunaannya cukup rendah atau tersedia alat/dukungan developer yang cukup untuk cara-cara standar yang menghubungkan permintaan penerbitan/penukaran dengan data lain. Kami membahas masalahnya di sini. |
| Pendaftaran | Apakah membuat penerbit mendaftar ke vendor browser itu praktis? | Kami telah memperbarui spesifikasi untuk menjelaskan proses pendaftaran penerbit untuk Token Status Pribadi. Meskipun menggunakan prosesnya sendiri, proses ini mirip dengan paket pendaftaran untuk tugas Privacy Sandbox lainnya, saat kami meminta penerbit membuat pernyataan publik tentang cara mereka ingin menggunakan PST dan mengonfirmasi batasan teknis yang melindungi privasi pengguna. |