Laporan kuartalan untuk K4 2022 yang 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) 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, Fledge, dan Attribution Reporting API.
Masukan yang diterima setelah akhir periode pelaporan saat ini mungkin belum mendapatkan respons Chrome yang dipertimbangkan.
Glosarium akronim
- 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
- PatCG
- Grup Komunitas Teknologi Iklan Pribadi
- RP
- Relying Party/Pihak yang Mengandalkan
- 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/Teknologi tertentu
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada Kuartal 3) Kegunaan untuk berbagai jenis pemangku kepentingan |
Kekhawatiran bahwa teknologi Privacy Sandbox lebih mendukung developer yang lebih besar dan situs khusus (lebih kecil) berkontribusi lebih banyak daripada situs umum (lebih besar) | Respons kami tidak berubah dari Kuartal 3: "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, terlepas dari ukurannya. Kami terus bekerja sama dengan CMA untuk memastikan bahwa upaya kami mematuhi komitmen ini. Seiring pengujian Privacy Sandbox berlangsung, salah satu pertanyaan utama yang akan kami kaji adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan yang spesifik dan dapat ditindaklanjuti yang dapat membantu kami meningkatkan desain teknis lebih lanjut. Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA untuk memublikasikan catatan tentang desain eksperimen guna memberikan informasi lebih lanjut kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan." |
| (Juga dilaporkan pada Kuartal 3) Permintaan dokumentasi |
Permintaan referensi lainnya yang menjelaskan cara mengelola pengujian, analisis, dan implementasi | Info Terbaru Kuartal 4: Kami senang bahwa developer merasa materi kami saat ini bermanfaat, dan kami akan terus berkomitmen untuk menyediakan lebih banyak materi agar developer dapat memahami cara kerja teknologi baru tersebut. Selama kuartal terakhir, kami menambahkan bagian "Berita & Info Terbaru" ke privacysandbox.com dan memublikasikan ulasan lengkap tentang bagaimana Privacy Sandbox dapat membantu mendorong relevansi iklan di masa mendatang. Kami juga telah mengadakan sesi jam buka developer publik untuk membagikan praktik terbaik dan demo, serta sesi tanya jawab dengan pimpinan produk dan engineer untuk memungkinkan diskusi/pertanyaan secara live. |
| Data Web Inti | Bagaimana latensi Privacy Sandbox API memengaruhi Core Web Vitals? | Menjaga latensi seminimal mungkin adalah sasaran desain utama Privacy Sandbox API. Perkiraan kami saat ini adalah latensi API akan memiliki dampak minimal pada Data Web Inti situs, karena sebagian besar API dipanggil setelah rendering awal situs. Kami terus memantau dan melakukan peningkatan untuk mengurangi latensi lebih lanjut untuk setiap API, serta mendorong pengujian dan masukan yang berkelanjutan. Latensi dalam proses bidding real-time dibahas di bagian FLEDGE pada "Performa Lelang FLEDGE" |
| Interoperabilitas | Masalah terkait interoperabilitas dengan potensi solusi lainnya | Tujuan Privacy Sandbox adalah melindungi pengguna dari pelacakan lintas situs sekaligus mendukung kebutuhan ekosistem web. Kami berupaya mencapai hal ini dengan beralih dari teknologi browser lama yang memungkinkan pelacakan lintas situs tersebut, seperti cookie pihak ketiga, dan menyediakan teknologi baru yang dirancang khusus untuk mendukung kasus penggunaan tertentu. Proposal Privacy Sandbox meningkatkan privasi dengan membatasi data yang keluar dari perangkat pengguna. Proposal ini tidak menempatkan batasan teknis pada kemampuan situs untuk membagikan atau memproses data setelah dikumpulkan dari browser. Oleh karena itu, teknologi ini tidak mencegah perusahaan untuk menyepakati perjanjian "pengelolaan data" atau hubungan kontrak serupa lainnya. Demikian pula, kebijakan ini tidak membatasi kemampuan pengguna untuk memberikan izin untuk membagikan data mereka melalui cara lain. Untuk memperjelas, Google telah berkomitmen untuk menerapkan teknologi Privacy Sandbox dengan cara yang sama ke semua situs, termasuk produk dan layanan Google. Setelah Chrome menghentikan dukungan untuk cookie pihak ketiga, komitmen ini juga menjelaskan bahwa Google tidak akan menggunakan data pribadi lainnya, seperti histori penjelajahan Chrome pengguna yang disinkronkan, untuk melacak pengguna guna penargetan atau pengukuran iklan digital. |
Menampilkan Konten & Iklan yang Relevan
Topik
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Dampak pada peringkat penelusuran Google | Permintaan informasi tentang apakah dukungan Topics API situs akan digunakan sebagai sinyal potensial untuk peringkat hasil Google Penelusuran | Beberapa situs dapat memilih untuk tidak menggunakan Topics API. Tim Privacy Sandbox belum berkoordinasi atau meminta organisasi Penelusuran untuk menggunakan peringkat halaman sebagai insentif bagi situs untuk mengadopsi Topics API. Google telah mengonfirmasi kepada CMA bahwa Google Penelusuran tidak akan menggunakan keputusan situs untuk memilih tidak ikut Topics API sebagai sinyal peringkat. |
| Pengklasifikasi topik | Tambahkan URL dan konten halaman selain nama host untuk menentukan Topik halaman web guna meningkatkan utilitas bagi berbagai pemangku kepentingan. | Histori penjelajahan pengguna saat ini diklasifikasikan menggunakan nama host situs. Chrome terus mengevaluasi opsi untuk mempertimbangkan metadata tingkat halaman (seperti semua atau beberapa komponen URL halaman dan/atau konten) dalam klasifikasi Topik. Setiap peningkatan utilitas harus dipertimbangkan dengan risiko privasi dan penyalahgunaan. Misalnya, sehubungan dengan metadata secara khusus, beberapa risikonya mencakup: - Situs yang mengubah metadata tingkat halaman sebagai metode untuk mengenkode makna yang berbeda (dan berpotensi sensitif) ke dalam topik; - Situs yang mengubah metadata tingkat halaman untuk memalsukan topik mereka demi keuntungan finansial; - Situs yang mengubah metadata tingkat halaman secara dinamis sebagai metode pelacakan lintas situs |
| (Juga dilaporkan pada Kuartal 3) Dampak pada sinyal pihak pertama |
Sinyal topik mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. | Respons kami tidak berubah dari Pertanyaan 3: "Kami yakin bahwa periklanan berbasis minat adalah kasus penggunaan yang penting untuk web, dan Topics dirancang untuk mendukung kasus penggunaan tersebut. Seperti yang dijelaskan [dalam laporan K3 kami], pemangku kepentingan ekosistem lainnya telah menyatakan kekhawatiran bahwa Topics mungkin tidak cukup berguna untuk memberikan nilai. Dalam semua kasus, peningkatan pada taksonomi adalah upaya yang berkelanjutan, dan kami berharap taksonomi akan berkembang dengan pengujian dan input ekosistem." |
| Memperbarui Taksonomi | Bagaimana cara memperbarui daftar taksonomi? | Kami secara aktif mencari masukan tentang taksonomi yang akan paling berguna bagi ekosistem. Taksonomi yang disertakan dalam proposal Topics API awal dirancang untuk memungkinkan pengujian fungsional. Chrome secara aktif mempertimbangkan beberapa pendekatan untuk memperbarui taksonomi. Misalnya, Chrome dapat menggunakan konsep nilai komersial untuk setiap topik guna menentukan kategori yang akan disertakan dalam iterasi mendatang. |
| Performa pengklasifikasi regional topik | Pengklasifikasi topik berperforma buruk di domain regional | Peningkatan pada pengklasifikasi adalah upaya yang berkelanjutan. Berdasarkan masukan yang kami terima, salah satu kemungkinan yang sedang dipertimbangkan adalah memperluas daftar penggantian Topics, yang menurut analisis kami akan meningkatkan cakupan global dan meningkatkan akurasi. Untuk menjelaskannya, klasifikasi Topics API memiliki dua komponen yang relevan: (1) Daftar penggantian yang berisi 10.000 situs teratas dan topiknya, dan (2) model ML di perangkat yang mengklasifikasikan nama host ke dalam topik. Dengan memperluas daftar penggantian (1), kita dapat meningkatkan performa klasifikasi untuk wilayah yang mungkin memiliki performa buruk pada pengklasifikasi. |
| Epoch satu minggu | Epoch satu minggu terlalu lama bagi pengguna yang ingin membuat keputusan jangka pendek. | Kami secara aktif mempertimbangkan panjang epoch yang sesuai dan kami menerima masukan lebih lanjut tentang epoch yang lebih baik untuk ekosistem. |
| Pengambilan header HTTP | Kekhawatiran bahwa tidak ada cukup informasi terkait pengambilan header HTTP untuk topik | Kami sedang mengerjakan header dan fetch(). Kami juga memiliki informasi yang tersedia di sini. Kami juga telah menambahkan informasi skipObservation ke penjelasan. |
| Topik hanya bertujuan untuk membantu pengiklan, bukan pengguna | Topics/Privacy Sandbox tampaknya merupakan pendekatan yang berfokus pada industri. Manfaat bagi pengguna tidak sejelas manfaat bagi industri. | Kami yakin bahwa manfaat bagi pengguna adalah Topics mendukung iklan berbasis minat yang membuat web tetap bebas dan terbuka, dan kami juga yakin bahwa Topics secara signifikan meningkatkan privasi dibandingkan dengan cookie pihak ketiga. Menghapus cookie pihak ketiga tanpa alternatif yang dapat digunakan dapat berdampak negatif bagi penayang, dan dapat menyebabkan pendekatan yang lebih buruk yang kurang bersifat pribadi, tidak transparan, dan tidak dapat direset atau dikontrol secara realistis oleh pengguna. Banyak perusahaan yang secara aktif menguji Topics API dan Sandbox API, dan kami berkomitmen untuk menyediakan alat guna meningkatkan privasi dan mendukung web. Technical Architecture Group W3C baru-baru ini memublikasikan tanggapan awal mereka tentang Topics API, yang akan kami tanggapi secara publik. Pada tahap ini, karena Google telah menerima pertanyaan dari ekosistem tentang kemungkinan dampak peninjauan ini terhadap pengembangan dan peluncuran Topics API, kami ingin menegaskan kembali rencana kami untuk menyediakannya di Chrome Stabil tahun ini. Meskipun Google menghargai masukan dari W3C Technical Architecture Group, Google menganggap sangat penting untuk melanjutkan upaya pengembangan dan pengujian Topics dengan berkonsultasi dengan CMA dan ekosistem. |
| Kebocoran data | Kekhawatiran bahwa Topics dapat bocor ke situs lain tanpa izin | Desain Topics API membuat data dari satu penayang (dan bahkan grup penayang yang lebih kecil) tidak mungkin bocor dengan cara apa pun. Situs penayang juga memiliki kontrol penuh atas Topics API dan dapat melarang akses ke API ini melalui kebijakan izin. |
| Kurangnya pengiklan untuk pengujian | Penayang khawatir bahwa saat ini mereka tidak dapat menunjukkan nilai Topics kepada pengiklan. | Pada paruh kedua tahun 2023, kami berencana menyediakan semua API terkait iklan untuk pengujian integrasi dan memungkinkan analisis ekosistem tentang nilai Topics bagi pengiklan. Pengujian dan publikasi hasilnya akan diawasi oleh CMA, yang akan meninjau data, analisis, dan metodologi. Ekosistem ini didorong untuk memberikan masukan kepada Google dan CMA. |
| Topics dan FLEDGE | Minta informasi selengkapnya tentang cara menggunakan Topik dalam logika bidding FLEDGE | Anda dapat menggunakan Topik dalam logika bidding FLEDGE. Panduan integrasi juga sedang dalam proses, dan akan menyertakan detail tambahan tentang penerapan. |
| Peringkat kustom untuk pemanggil topik | Mengizinkan peringkat disesuaikan oleh pemanggil | Tantangan dengan peringkat atau nilai topik kustom untuk setiap teknologi iklan adalah hal ini dapat menjadi mekanisme yang dapat digunakan teknologi iklan untuk memengaruhi topik yang ditampilkan, sehingga menjadi vektor sidik jari. |
| Daftar prioritas penelepon topik | Mengizinkan pemanggil memberikan daftar prioritas topik yang diurutkan yang akan ditampilkan oleh Topics API berdasarkan kelayakan. | Saat ini kami sedang membahas ide ini lebih lanjut dan menerima masukan tambahan. |
FLEDGE
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Google Ad Manager | Kekhawatiran bahwa Google Ad Manager adalah pengambil keputusan akhir untuk lelang FLEDGE dan akan mendukung Tag Penayang Google dan Google Ad Manager. | FLEDGE memungkinkan setiap penayang memilih struktur lelang, termasuk pilihan penjual tingkat teratas dan komponen. Setiap pembeli dan penjual dalam lelang komponen mengetahui siapa penjual tingkat teratas, dan dapat memilih apakah akan mengajukan bid atau tidak. |
| Jumlah peserta yang menguji FLEDGE tidak cukup | Permintaan untuk mendorong lebih banyak perusahaan menguji FLEDGE, misalnya dengan meningkatkan fungsi API dan tidak mendorong alternatif yang mengganggu privasi seperti pelacakan sidik jari | Privacy Sandbox dilakukan secara bertahap, dalam kemitraan yang erat dengan panduan CMA dan ICO, dan pengujian FLEDGE fungsional telah menunjukkan stabilitas dan kemampuan yang diperlukan. Google terus mendorong ekosistem untuk menguji Sandbox API, baru-baru ini memublikasikan dokumentasi "Maksimalkan Relevansi Iklan" untuk menunjukkan bagaimana FLEDGE dan API lainnya dapat membantu mendukung kasus penggunaan penting bagi industri iklan setelah penghentian cookie pihak ketiga. Bagian lain dari Privacy Sandbox sudah mendukung mitigasi untuk mencakup pelacakan (lihat Mitigasi Pelacakan Pantulan, Perlindungan IP, dan UA-CH) dan akan terus ditingkatkan dari waktu ke waktu. Sasaran Google bukanlah menjadikan FLEDGE sebagai satu-satunya solusi penargetan yang layak, tetapi tetap berkomitmen untuk bekerja sama dengan industri dan regulator untuk mendorong teknologi iklan terbaik yang menjaga privasi di browser Chrome. |
| Kasus penggunaan machine learning | Panduan selengkapnya tentang cara kasus penggunaan machine learning untuk melatih algoritma bidding lelang akan didukung di FLEDGE dan Pelaporan Atribusi | Kami menyadari perlunya membantu penguji menemukan cara paling berguna untuk menerapkan teknologi Privacy Sandbox. Kami telah mulai memublikasikan panduan yang secara khusus terkait dengan penggunaan berbagai aspek Privacy Sandbox API sebagai input untuk machine learning. Artikel terbaru, Memaksimalkan Relevansi Iklan, membahas cara industri iklan dapat menggunakan sinyal ini untuk machine learning, dan kami berencana untuk terus memublikasikan panduan tersebut ke depannya. |
| Membuat Kueri Server Nilai Kunci (K/V) FLEDGE | Mengapa server K/V dapat dikueri secara publik? | Server K/V bertujuan untuk memberikan sinyal real-time ke lelang FLEDGE. Dengan demikian, server K/V harus dapat diakses dari tempat lelang FLEDGE tersebut dijalankan, yaitu di perangkat pengguna, sehingga server tersebut harus tersedia secara publik. Nilai yang disimpan di server K/V hanya dapat diambil oleh pihak yang sudah memiliki kuncinya. Jadi, jika teknologi iklan hanya memberikan kunci ke browser yang ada dalam Grup Minat, dan tidak menggunakan kunci yang dapat ditebak secara acak, hanya browser yang memerlukan Nilai untuk menjalankan lelangnya yang dapat mengambilnya. |
| Bagaimana cara melakukan penargetan tanggal/waktu? | Dukungan untuk objek tanggal dalam fungsi logika bidding. | Ada beberapa cara untuk melakukannya. Pembeli dapat meminta penjual untuk memberikan tanggal dan waktu saat ini, dan penjual harus dapat dengan mudah memberikan informasi ini kepada semua pembeli. Pembeli juga dapat memberikan tanggal dan waktu dalam respons nilai kunci real-time mereka. Terakhir, pembeli dapat memberikan tanggal dan waktu sebagai bagian dari respons kontekstual mereka dalam sinyal per pembeli, yang dapat diteruskan penjual ke skrip generateBid pembeli. |
| Preferensi pengguna | Kemampuan pengguna untuk memilih memblokir materi iklan menurut penayang saat ditayangkan melalui FLEDGE, atau solusi alternatif. | Pengguna dapat memilih untuk tidak menggunakan Ads API di Chrome. Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara pemilihannya. |
| Linimasa yang lebih jelas | Minta informasi selengkapnya tentang ketersediaan perlindungan privasi di FLEDGE, seperti mewajibkan Frame Pagar. | Kami berencana untuk memublikasikan linimasa yang lebih mendetail pada Kuartal 1. |
| Melaporkan kebingungan | Minta kejelasan lebih lanjut tentang cara kerja pelaporan FLEDGE dengan API lain seperti Fenced Frames dan Private Aggregation API. | Kami berencana memublikasikan penjelasan tentang interaksi antara Private Aggregation API, FLEDGE, dan Fenced Frames dalam beberapa minggu mendatang. |
| Bidding real-time dan FLEDGE | Panduan tentang cara FLEDGE berintegrasi dengan bidding real-time standar. | Dua hal utama yang mempersulit kemampuan teknologi iklan untuk melakukan bidding real-time adalah akses ke data tingkat peristiwa dan integrasi yang lebih mudah ke ARA. Kami berencana mengirimkan info terbaru dan penjelasan tentang kedua hal ini pada Kuartal 1. |
| Performa Lelang FLEDGE | Laporan dari penguji bahwa lelang FLEDGE memiliki latensi tinggi | Kami menghargai laporan dari penguji yang membagikan hasil dan kasus penggunaan mereka serta telah membagikan beberapa saran tentang cara meningkatkan performa FLEDGE. Secara paralel, kami telah menambahkan alat ke browser yang memungkinkan developer mendiagnosis dengan lebih baik penyebab leletnya lelang, dan telah secara sistematis mengatasi sumber utama latensi yang diamati. Peningkatan terbaru mencakup waktu tunggu untuk lelang lambat, teknik pemfilteran bidder cepat, cara untuk menggunakan kembali worklet FLEDGE agar tidak membayar biaya startup, dan pekerjaan yang sedang berlangsung untuk memungkinkan permintaan iklan kontekstual berjalan secara paralel dengan waktu startup FLEDGE dan pengambilan jaringan. Kami berharap pengoptimalan latensi akan terus berlanjut sebagai percakapan berkelanjutan antara developer Chrome dan penguji FLEDGE berdasarkan pengalaman mereka di dunia nyata saat menggunakan API. |
| Batas memori ukuran Grup Minat | Permintaan untuk menaikkan batas ukuran satu grup minat dari 50 kB. | Kami sedang mempertimbangkan permintaan tersebut dan mencari masukan tentang nilai batas yang sesuai. |
| Menggabungkan data yang ditayangkan FLEDGE dengan cookie pihak pertama | Apakah FLEDGE akan mendukung integrasi dengan data pihak pertama pengiklan? | FLEDGE dibuat untuk mendukung iklan menggunakan data pihak pertama yang sudah dimiliki pengiklan. Namun, FLEDGE tidak bermaksud mendukung pengiklan mempelajari perilaku penjelajahan seseorang di situs mana pun selain situs pengiklan itu sendiri. Mengaitkan perilaku penjelajahan di luar situs ke data pihak pertama bertentangan dengan tujuan Privacy Sandbox. Kami berencana untuk membagikan panduan integrasi dengan detail selengkapnya tentang cara FLEDGE akan mendukung integrasi dengan data pihak pertama dalam beberapa minggu mendatang. |
| Nilai k-anonymity | Bagaimana nilai "K" ke "k-anon" akan diputuskan dan apakah nilai tersebut akan dipublikasikan? | Nilai "K" masih dalam proses penyelesaian dan kami akan membagikan informasi selengkapnya seiring pengembangan rencana kami. Kami ingin mempelajari lebih lanjut bagaimana nilai k yang tidak diketahui dapat menghambat kesiapan FLEDGE dan cakupan pelatihan model ML. Kami juga menerima masukan tambahan tentang subjek ini. |
| Mendukung beberapa SSP | Bagaimana beberapa SSP akan didukung di FLEDGE? | FLEDGE mendukung lelang multi-penjual seperti yang disebutkan dalam proposal ini. |
| Visibilitas logika bidding | Kekhawatiran bahwa logika bidding DSP akan diekspos dalam JavaScript | Dengan logika bidding desain saat ini, JavaScript dapat diakses oleh orang lain, tetapi kami menerima lebih banyak masukan tentang mengapa hal ini dapat menjadi sumber masalah bagi DSP. |
| prebid.js | Apa linimasa dalam mendukung prebid.js di FLEDGE? | Hanya Prebid.js versi 7.14 dan yang lebih baru yang mendukung modul FLEDGE. Setiap penayang yang berminat untuk melakukan pengujian harus menambahkan modul FLEDGE dan mengupgrade instance Pra-bid mereka. |
| Fungsi yang ditentukan pengguna di FLEDGE | Bagaimana fungsi yang ditentukan pengguna (UDF) akan didukung di FLEDGE? Ini adalah fungsi yang dapat diprogram oleh pengguna akhir untuk memperluas fungsi API. | Penjelasan tersedia di sini. Fitur ini masih dalam pengembangan, jadi kami menerima masukan tambahan tentang kasus penggunaan. |
| Melonggarkan batasan asal yang sama pada resource Grup Minat | Permintaan untuk melonggarkan batasan origin yang sama pada resource Grup Minat untuk mengaktifkan kasus penggunaan teknologi iklan tertentu | Dalam penerapan FLEDGE saat ini, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl, dan trustedBiddingSignalsUrl harus memiliki origin yang sama dengan pemilik grup minat.Batasan ini ada untuk mencegah eksploitasi tertentu oleh penyerang, seperti yang dijelaskan di sini. |
| Kepemilikan interestGroup | Permintaan untuk membatasi apakah teknologi iklan dapat menggunakan joinInterestGroup untuk Grup Minat yang sama di seluruh situs | Fokus kami adalah pada cara audiens digunakan, bukan cara audiens dibuat. Kami membahas potensi pendekatan dan menerima masukan tambahan. |
| Masa Berlaku Kunci Server Nilai Kunci | Diskusi tentang penghapusan kunci server setelah masa berlaku grup minat yang sesuai berakhir | Kami sedang mempelajari cara menangani masa berlaku kunci dan mencari masukan. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Traffic Uji Coba Asal | Traffic Uji Coba Origin saat ini tidak cukup untuk melakukan pengujian utilitas. | Uji Coba Origin saat ini ditujukan bagi pelaku ekosistem untuk melakukan pengujian fungsional guna memastikan API berfungsi sebagaimana mestinya. Kami memahami bahwa jumlah traffic yang lebih besar akan diperlukan untuk melakukan pengujian utilitas setelah pengembangan berbagai Privacy Sandbox API lebih matang. Linimasa pengujian saat ini memperkirakan bahwa hal ini akan terjadi pada saat Ketersediaan Umum (yaitu saat teknologi untuk kasus penggunaan akan diluncurkan dan tersedia untuk 100% traffic Chrome) pada Kuartal 3 2023 (lihat linimasa terbaru kami di privacysandbox.com). Kami menerima masukan tambahan apa pun tentang pengujian kasus penggunaan yang memerlukan traffic tambahan. |
| Tumpang-tindih fungsi dari berbagai API pengukuran Privacy Sandbox | Kekhawatiran dalam memiliki beberapa pendekatan pengukuran yang tumpang-tindih melalui Privacy Sandbox akan meningkatkan kompleksitas, misalnya, Attribution Reporting API dan Private Aggregation API. | Kami sedang berupaya membuat dokumentasi yang lebih baik untuk mengklarifikasi berbagai kasus penggunaan API, dan menyambut masukan tambahan tentang bagian yang kurang penjelasan. Misalnya, Attribution Reporting API ditujukan secara khusus untuk mendukung pengukuran konversi, sedangkan Private Aggregation API dan Shared Storage adalah API tujuan umum yang ditujukan untuk mendukung berbagai kasus penggunaan pengukuran lintas situs yang lebih luas. |
| Mencoba lagi permintaan laporan yang gagal | Klarifikasi tentang berapa kali permintaan laporan dicoba jika gagal. | Kami telah memublikasikan panduan tentang hal ini. Singkatnya, laporan hanya dikirim saat browser berjalan/online. Setelah kegagalan pertama saat mengirim, laporan akan dicoba lagi setelah 5 menit. Setelah kegagalan kedua, laporan akan dicoba lagi setelah 15 menit. Setelah itu, laporan tidak akan dikirim. |
| Penundaan Pelaporan | Berapa perkiraan keterlambatan pelaporan? | Kami ingin mendapatkan lebih banyak masukan dari ekosistem terkait penundaan pelaporan yang mereka alami saat kami mengumpulkan data untuk menilai lebih lanjut penundaan ini secara paralel. |
| Pra-render halaman | Apakah atribusi ARA akan berfungsi di halaman pra-rendering? | Pendaftaran atribusi ditangguhkan di halaman pra-render hingga aktivasi (klik atau tampilan sebenarnya terjadi). Artinya, kami akan menunda ping permintaan `attributionsrc`. |
| Mengukur peningkatan konversi | Cara mengukur conversion lift dengan pengujian A/B di domain yang sama | Situs dapat mengukur peningkatan konversi dengan pengujian A/B di domain yang sama melalui pelaporan atribusi. Mereka dapat mengenkode parameter A/B sebagai kunci menggunakan API gabungan, lalu menerima laporan ringkasan untuk nilai konversi menurut bucket kunci tersebut. |
| (Juga dilaporkan di Kuartal 3) Konversi lintas-domain | Cara melacak konversi lintas-domain, seperti dengan 2 tujuan atau lebih | Info Terbaru Kuartal 4: Kami telah memublikasikan proposal untuk menghapus pembatasan tujuan halaman landing yang memungkinkan percakapan lintas-domain dilacak. Proposal ini telah diterapkan. |
| (Juga dilaporkan di Kuartal 3) Setelan masa berlaku di laporan konversi |
Permintaan untuk mendukung filter laporan / masa berlaku kurang dari 24 jam | Info Terbaru Kuartal 4: Kami telah membagikan permintaan pull ini yang akan memisahkan periode masa berlaku dan periode pelaporan untuk mengurangi konsekuensi penundaan pelaporan vs. masa berlaku konversi. Fitur ini kini diluncurkan di M110. |
| Penipuan dan Penyalahgunaan | Permintaan dari pengiklan dan pemasar agar dapat mengelompokkan dan menggabungkan data berdasarkan situs penayang tempat iklan mereka ditayangkan, yang juga akan memberikan lebih banyak insight tentang potensi praktik iklan yang menipu | Masukan ini sedang dibahas secara aktif di sini dan kami menerima masukan tambahan. |
| (Juga dilaporkan pada K3) Keterlambatan pelaporan tingkat peristiwa | Penundaan 2-30 hari dalam pelaporan tingkat peristiwa mungkin terlalu lama untuk kasus penggunaan tertentu. | Pelaporan tingkat peristiwa memiliki periode pelaporan default 2, 7, dan 30 hari. Hal ini dapat diubah menggunakan parameter "expiry". Teknologi iklan dapat mengonfigurasi masa berlaku, dengan minimum 1 hari, untuk mendapatkan laporan potensial dalam waktu kurang dari 2 hari. Kami membatasi perincian masa berlaku hingga 1 hari sebagai mekanisme perlindungan privasi, karena pelaporan yang lebih terperinci dapat menyebabkan serangan waktu. Selain itu, kami mengizinkan penetapan parameter "expiry" independen untuk laporan tingkat peristiwa dan gabungan. Lihat di sini. Selain itu, Google Ads tidak akan mendapatkan periode pelaporan khusus yang tidak didapatkan teknologi iklan lainnya melalui Attribution Reporting API. |
| Persyaratan asal pelaporan yang sama | Permintaan untuk menghapus persyaratan agar asal pendaftaran sumber sama dengan asal pendaftaran konversi | Kami mengusulkan penggunaan pengalihan HTTP untuk mendelegasikan pendaftaran guna menyelesaikan kasus penggunaan ini. Kami menerima masukan tambahan apa pun tentang panduan baru ini. |
| Tracking konversi | Perlu membedakan apakah konversi terjadi sebelum/setelah jam tertentu yang ditetapkan oleh pengiklan | Attribution Reporting API mendukung penetapan periode habis masa berlaku dan prioritas untuk atribusi sumber. Dengan menggunakan keduanya, secara teknis Anda dapat mengatribusikan konversi yang terjadi dalam periode X hari secara terpisah dari konversi yang terjadi setelah X. |
| Simulasi derau | Permintaan untuk dapat menyimulasikan volume konversi yang berbeda per bucket, guna memahami dampaknya terhadap pengiklan dengan lebih sedikit konversi | Kami ingin menambahkan cara untuk menyimulasikan hal ini di versi Noise Lab mendatang. Kami menerima masukan tambahan. |
| Pelaporan di perangkat seluler | Apakah laporan masih akan dikirim saat Chrome berjalan di latar belakang di perangkat seluler? | Saat ini, bahkan di perangkat seluler, laporan tidak akan dikirim saat Chrome berada di latar belakang. Hal ini kemungkinan akan berubah saat API terintegrasi dengan Privacy Sandbox Android. Lihat di sini. Perhatikan bahwa Privacy Sandbox Android bukan bagian dari Komitmen yang diterima oleh CMA. |
| Ketersediaan data | Kekhawatiran bahwa Google akan memiliki akses tambahan ke data melalui Privacy Sandbox API | Pertama, Google Ads tidak menerima akses preferensial apa pun ke data dari Attribution Reporting API atau Privacy Sandbox API lainnya. Masalah ini juga dibahas di bagian Masukan Umum pada "Interoperabilitas" yang menyertakan detail selengkapnya tentang Komitmen Google. Kedua, terkait perbedaan antara situs yang lebih besar dan lebih kecil, Google menyadari bahwa perlindungan privasi berbasis derau mungkin memiliki dampak yang lebih besar pada slice data yang lebih kecil. Namun, ada beberapa kemungkinan mitigasi: misalnya, metode seperti menggabungkan selama jangka waktu yang lebih lama akan menyelesaikan masalah ini. Meskipun demikian, masih belum jelas apakah kesimpulan berdasarkan potongan data yang sangat kecil (seperti satu atau dua pembelian) sama sekali bermakna bagi pengiklan. Selama uji coba origin, Google telah mendorong penguji untuk memanfaatkan kemampuan bereksperimen dengan berbagai parameter privasi dan derau sehingga mereka dapat memberikan masukan yang lebih spesifik tentang masalah ini. |
Membatasi Pelacakan Tersembunyi
Pengurangan Agen Pengguna
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Menunda Pengurangan Agen Pengguna hingga ekosistem web lebih siap | Tidak ada cukup waktu untuk beradaptasi dengan perubahan Pengurangan Agen Pengguna yang akan datang. | Kami membahas masukan ini dalam laporan lengkap di bagian "Kekhawatiran Pemangku Kepentingan" di bagian yang berjudul "Interaksi Google dengan CMA". |
| Menunda Pengurangan Agen Pengguna hingga ekosistem web lebih siap | Meminta penundaan peluncuran Pengurangan Agen Pengguna hingga Agen Pengguna Terstruktur (SUA) di-deploy | Tim Google Ads mengusulkan penambahan Agen Pengguna Terstruktur (lihat spesifikasi) ke OpenRTB pada Oktober 2021 dan diintegrasikan dalam update spesifikasi 2.6 yang dirilis pada April 2022. Kami memiliki beberapa bukti bahwa SUA di-deploy dan tersedia saat ini, seperti yang ditunjukkan oleh postingan blog Scientia Mobile yang menunjukkan cara menggunakan UA-CH dan WURFL API untuk membuat SUA. |
###
Petunjuk Klien Agen Pengguna
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Menguji UA-CH dengan teknik anti-pelacakan terselubung lainnya | Panduan tentang cara menguji semua Privacy Sandbox API dan teknik sidik jari yang diusulkan bersama dalam pendekatan holistik | Rencana pengujian kami dirancang untuk mencerminkan linimasa asinkron untuk mengembangkan beberapa langkah anti-pelacakan sidik jari, bukan Proposal Sandbox lainnya. Hal ini menjawab kenyataan bahwa beberapa tindakan anti-pelacakan sidik jari (yaitu Privacy Budget, IP Protection, dan Bounce Tracking Mitigations) akan dikembangkan sepenuhnya dan siap diluncurkan ke Ketersediaan Umum hanya setelah penghentian cookie pihak ketiga. Meskipun tindakan anti-pelacakan sidik jari tersebut tidak akan disertakan dalam pengujian kuantitatif, tindakan tersebut akan dikenai penilaian kualitatif berdasarkan fakta yang tersedia pada saat Standstill. |
| (Juga dilaporkan di K2) Performa |
Masalah terkait latensi untuk mendapatkan petunjuk melalui Critical-CH (pada pemuatan halaman pertama) | Lihat bagian UA-CH khusus di bawah |
| Masukan Tidak Mencukupi | Masukan dari ekosistem tentang perubahan UA-CH mungkin tidak memadai, sehingga menimbulkan kekhawatiran tentang kurangnya kesadaran dari ekosistem. | Kami telah secara proaktif membagikan rencana kami untuk memastikan peluncuran yang cermat yang meminimalkan gangguan. Rencana untuk Pengurangan Agen Pengguna dan UA-CH API dipresentasikan kepada W3C Anti-Fraud Community Group pada 18 Maret 2022 dan kepada Web Payments Working Group serta Web Payments Security Interest Group pada 20 Januari 2022. Tidak ada masalah signifikan yang diajukan selama atau setelah presentasi. Google telah secara proaktif menghubungi lebih dari 100 operator situs untuk mendapatkan masukan. Selain itu, Google juga telah menggunakan saluran Blink-Dev untuk menyampaikan peluncuran pengurangan agen pengguna secara publik berdasarkan masukan dari pemangku kepentingan ekosistem. |
| Waktu | Kekhawatiran yang muncul terkait waktu peluncuran dan kesiapan industri | Lihat bagian UA-CH khusus di bawah |
| Status Platform Chrome | Meminta agar halaman chromestatus untuk UA-CH diperbarui | Entri chromestatus diperbarui pada 19 Desember menjadi "Sinyal campuran". |
Perlindungan IP (sebelumnya bernama Gnatcatcher)
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Memilih Ikut Serta atau Tidak Ikut Serta | Apakah Privasi Alamat IP Diaktifkan atau Dinonaktifkan? | Tujuan kami adalah memberikan Perlindungan IP kepada semua pengguna. Dengan mempertimbangkan sasaran tersebut, saat ini kami sedang mengevaluasi opsi pilihan pengguna untuk Perlindungan IP. |
| Kasus penggunaan Alamat IP untuk data pihak pertama | Apakah alamat IP dapat digunakan untuk menggabungkan perjalanan pengguna di seluruh domain pihak pertama setelah Perlindungan IP? | Seperti yang dipublikasikan sebelumnya, Perlindungan IP pada awalnya akan berfokus pada pelacakan dalam konteks pihak ketiga, yang berarti domain pihak pertama tidak akan terpengaruh. |
| Kasus penggunaan Teknologi Iklan | Bagaimana cara perusahaan menyiapkan langkah anti-penipuan dengan Perlindungan IP? | Kami menyadari pentingnya alamat IP sebagai sinyal untuk upaya anti-penipuan di web saat ini. Sebagai bagian dari Komitmen kami kepada CMA (paragraf 20), kami telah menyatakan bahwa kami tidak akan menerapkan Perlindungan IP tanpa melakukan upaya yang wajar untuk mendukung kemampuan situs dalam melakukan upaya anti-spam dan anti-penipuan. Salah satu prioritas utama kami adalah memahami pengaruh Perlindungan IP terhadap kasus penggunaan dan kemampuan deteksi anti-penipuan, sehingga kami dapat lebih berinvestasi dalam teknologi perlindungan privasi yang membantu perusahaan menjaga keamanan web. Kami mendorong masukan dan masukan tentang proposal baru yang bertujuan untuk mendukung kebutuhan perusahaan keamanan dan anti-penipuan, meskipun sinyal berubah dari waktu ke waktu. |
| Penipuan dan Penyalahgunaan | Apakah perlindungan IP mencakup Perlindungan terhadap Denial of Service (DoS)? | Kami berkomitmen untuk meningkatkan privasi sekaligus menjaga keamanan web, dan melindungi dari serangan denial-of-service adalah kasus penggunaan anti-penyalahgunaan yang penting untuk dirancang. Kami berharap dapat meminimalkan dampak terhadap perlindungan DoS melalui desain Perlindungan IP itu sendiri dan melalui solusi anti-penyalahgunaan baru. Karena Perlindungan IP awalnya berfokus pada layanan tersemat pihak ketiga, beberapa pemangku kepentingan telah menunjukkan bahwa perlindungan ini akan memiliki dampak terbatas pada perlindungan DoS untuk situs pihak pertama. Namun, kami terus meminta masukan publik untuk menilai risiko terhadap kasus penggunaan DoS, terutama untuk layanan tersemat pihak ketiga. Secara paralel, kami sedang mempelajari mekanisme masukan penyalahgunaan dan pemblokiran klien yang akan memungkinkan situs atau layanan memblokir pengguna yang mengirimkan spam, tanpa mengidentifikasi pengguna tersebut. |
| Pemfilteran Konten | Pemfilteran konten dengan Perlindungan IP | Perusahaan yang berbeda memiliki kebutuhan yang berbeda terkait pemfilteran konten dan penyesuaian pengalaman pengguna. Saat ini, banyak kasus penggunaan tersebut tidak mengandalkan alamat IP sehingga tidak akan terpengaruh oleh Perlindungan IP. Misalnya, penerbit yang ingin menyesuaikan kontennya dan mendorong lebih banyak engagement dapat menggunakan cookie pihak pertama atau cookie partisi pihak ketiga (CHIP) untuk memahami minat pengguna dan interaksi sebelumnya dengan penerbit. Atau, partner teknologi iklan yang berfokus untuk menayangkan iklan yang tepat kepada pengguna yang tepat dapat menggabungkan FLEDGE dan Topics, misalnya, untuk memberikan hasil iklan yang serupa seperti yang mereka lakukan saat ini dengan cookie pihak ketiga atau teknologi pelacakan lintas situs lainnya. Kami juga sedang mempelajari cara membuat kemampuan baru yang menjaga privasi ke dalam Perlindungan IP, seperti geolokasi kasar, untuk lebih mendukung pemfilteran konten jika mekanisme yang ada mungkin tidak memadai. Kami menerima masukan tambahan tentang kasus penggunaan pemfilteran konten yang mungkin terpengaruh oleh Perlindungan IP. |
| (Juga dilaporkan pada Kuartal 3) Kasus penggunaan geolokasi |
Perlindungan IP dapat mencegah kasus penggunaan geolokasi yang sah berfungsi di masa mendatang, seperti personalisasi konten berdasarkan geolokasi. | Info Terbaru Kuartal 4: Kami sedang bekerja sama dengan pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami mencari masukan ekosistem tentang perincian Geolokasi IP di sini. |
Anggaran Privasi
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Dokumentasi yang lebih jelas | Contoh lainnya agar pemangku kepentingan dapat mengantisipasi bagaimana hal-hal dapat dibatasi setelah Privacy Budget diterapkan | Proposal Privacy Budget masih dalam diskusi aktif dan belum diterapkan oleh browser apa pun. Tanggal paling awal ketersediaan yang diskalakan menunjukkan tanggal paling awal saat Privacy Budget dapat diterapkan. Hal ini tidak akan terjadi sebelum penghapusan cookie pihak ketiga pada tahun 2024. Saat ini, kami tidak memiliki dokumentasi tambahan untuk disampaikan. Kami akan membagikan detail tambahan tentang proposal tersebut setelah lebih selesai. Sementara itu, kami menyambut baik pemangku kepentingan untuk memberikan masukan yang akan membantu dalam pengembangan proposal. |
Memperkuat batasan privasi lintas situs
Set Pihak Pertama
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada Kuartal 3) Batas domain | Meminta untuk memperluas jumlah domain terkait | Info Terbaru Kuartal 4: Kami telah merilis FPS untuk pengujian lokal, termasuk proses pengiriman set tiruan di GitHub dan tanda untuk menguji rSA dan rSAFor secara lokal. Kami juga telah menyelenggarakan dua pertemuan terbuka untuk developer di FPS guna terus menjawab pertanyaan seputar kasus penggunaan untuk subset terkait. Sebaiknya developer menguji fungsi FPS untuk memberikan masukan tentang pengaruh batas domain untuk subset terkait terhadap kegunaan FPS untuk kasus penggunaan mereka. Kami telah mengklarifikasi dalam panggilan WICG bahwa Chrome berkomitmen untuk memberikan solusi yang dapat digunakan yang juga mempertimbangkan minat privasi pengguna. Sehubungan dengan hal tersebut, kami menghargai masukan dari komunitas tentang kasus penggunaan tertentu yang mungkin terpengaruh oleh batas domain, sehingga tim dapat mempertimbangkan cara untuk mengatasi kasus penggunaan ini sekaligus terus melindungi privasi pengguna. |
| Meminta detail selengkapnya tentang langkah-langkah mitigasi penyalahgunaan | Apa yang terjadi jika domain ditambahkan ke set yang tidak diizinkan oleh pemiliknya? | Kami telah memublikasikan panduan pengiriman untuk Set Pihak Pertama di sini pada 2 Desember 2022. Seperti yang dijelaskan dalam panduan pengiriman, setiap manajemen perubahan yang ditetapkan akan mengikuti dan mematuhi proses validasi di GitHub, termasuk validasi kepemilikan, yang akan mengurangi risiko ini. |
| Mitigasi penyalahgunaan | Kekhawatiran bahwa pembentukan Set Pihak Pertama dapat dieksploitasi | Kami sedang mencari cara untuk memperluas pemeriksaan teknis untuk jenis subset dan secara aktif mencari masukan tambahan dari komunitas di sini. |
| Kasus penggunaan iklan | Pertanyaan tentang apakah Set Pihak Pertama harus digunakan untuk mendukung Penargetan iklan | Kami tidak mencoba mendukung kasus penggunaan penargetan Google Ads untuk Set Pihak Pertama, dan sebaiknya gunakan Ads API yang tersedia untuk kasus penggunaan tersebut. |
| (Juga dilaporkan pada Kuartal 3) Kebijakan | Kekhawatiran bahwa FPS tidak konsisten dengan Komitmen CMA terkait "Legislasi Perlindungan Data yang Berlaku", dengan alasan bahwa GDPR tidak memberlakukan batasan jumlah situs dalam satu set, sedangkan FPS memperkirakan batas 3 | Respons kami tidak berubah dari K3: "Google terus 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, penayang, dan pengiklan, serta dampak terhadap hasil privasi dan kepatuhan terhadap prinsip perlindungan data sebagaimana ditetapkan dalam Legislasi Perlindungan Data yang Berlaku. Kekhawatiran yang diungkapkan tidak mengungkapkan ketidakcocokan apa pun dengan GDPR. Kami terus bekerja sama dengan CMA untuk memastikan bahwa upaya kami mematuhi komitmen ini." |
| Proposal alternatif | Set Validasi GDPR | Selain masukan yang diberikan oleh ekosistem terkait proposal untuk mengadopsi "GDPR Validated Sets", Chrome memiliki kekhawatiran tentang batasan berikut dari proposal alternatif ini:
Sejak alternatif ini diajukan, Chrome telah memperbarui proposal Set Pihak Pertama dan memublikasikan pedoman pengiriman untuk membuat set baru. |
Fenced Frames API
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Pembatasan Frame Pagar selama OT | Apa batasan saat ini terkait Frame Pagar untuk periode Uji Coba Origin? | Kami sedang mengerjakan dokumentasi tentang pembatasan dan status penerapan, serta berencana untuk membagikannya selama Kuartal 1 2023. |
| Beberapa iklan dalam satu Frame Berpagar | Permintaan untuk menampilkan beberapa pengiklan dalam satu Bingkai Pagar dalam satu lelang | Saat ini, permintaan ini tidak sedang dikembangkan secara aktif, tetapi kami menerima masukan tambahan jika pelaku ekosistem menganggap fitur ini penting. |
| Paket Web | Apa saja persyaratan dan dukungan yang direncanakan untuk Web Bundle dengan Frame Pagar? | Saat ini kami belum memiliki informasi terbaru tentang apakah persyaratan ini akan berlaku di masa mendatang. Setiap perubahan akan diumumkan terlebih dahulu dan tidak akan diterapkan sebelum penghentian penggunaan cookie pihak ketiga. Lihat penjelasan ini untuk mengetahui status saat ini. |
Shared Storage API
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Penyimpanan Bersama untuk Teknologi Iklan | Ketidakpastian seputar penggunaan penyimpanan bersama untuk kasus penggunaan Teknologi Iklan | Shared Storage dan Private Aggregation API dapat digunakan untuk berbagai jenis tujuan pengukuran yang memerlukan pengukuran penyimpanan lintas situs. Beberapa contoh tercantum di sini. Kami memperkirakan bahwa DSP dan penyedia solusi Pengukuran akan menjadi integrator utama untuk kasus penggunaan iklan. |
CHIPs
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan di K3) Persyaratan partisi | Menambahkan persyaratan perilaku eksplisit untuk atribut "Dipartisi" pada cookie pihak pertama. | Pembaruan Kuartal 4: Setelah diskusi di GitHub dan panggilan PrivacyCG, perilaku yang telah kami sesuaikan adalah bahwa cookie yang Dipartisi yang ditetapkan pada cookie pihak pertama akan menggunakan kunci partisi (A,A) dengan "A" adalah situs tingkat teratas. Kami akan mendokumentasikan perilaku ini di penjelasan dan spesifikasi. |
| Pengelolaan Cookie | Apakah ada alat untuk mengelola/mengatur cookie pihak pertama atau pihak ketiga? | Chrome DevTools dan NetLog dapat digunakan untuk menguji situs dengan pemblokiran cookie pihak ketiga yang diaktifkan. Kedua alat ini melaporkan saat cookie diblokir karena konfigurasi pengguna. Kami menerima masukan tentang jenis situs audit tambahan yang ingin Anda lihat. |
FedCM
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| IdP memerlukan pengetahuan tentang RP untuk mengizinkan sesi | Masalah saat pengguna mencoba login ke IdP Feide dari dua RP yang berbeda | Kami sedang mendiskusikan solusi potensial untuk masalah ini. |
| Interoperabilitas | Kekhawatiran terkait dampak FedCM terhadap hubungan antara pengguna dan situs yang mereka gunakan untuk login menggunakan FedCM, serta "interoperabilitas" di antara situs | FedCM bertujuan untuk terus mendukung layanan identitas gabungan yang saat ini mengandalkan cookie pihak ketiga setelah cookie pihak ketiga dihapus dari Chrome. Kami memperkirakan bahwa FedCM hanya akan menjadi salah satu opsi yang tersedia untuk layanan tersebut; penyedia identitas (IdP) dan pihak tepercaya (RP) bebas menggunakan teknologi lain yang mungkin lebih sesuai dengan kebutuhan mereka. Tampaknya kekhawatiran terkait hubungan pengguna-RP dan "interoperabilitas" disebabkan oleh kesalahpahaman tentang proposal FedCM. FedCM menyerahkan keputusan kepada IdP untuk menentukan informasi apa yang akan dibagikan kepada RP, dan dalam bentuk apa, setelah pengguna memilih untuk login ke situs RP tersebut. FedCM tidak mewajibkan IdP untuk "membuat ID pseudonim unik untuk setiap [RP] yang digunakan pengguna untuk melakukan autentikasi". Sebaliknya, FedCM terbuka bagi setiap IdP untuk memilih apakah akan membagikan ID sebenarnya pengguna, versi per situs dari ID tersebut, atau beberapa versi lain dari informasi ini. (Spesifikasi FedCM mengidentifikasi korelasi lintas situs sebagai risiko privasi yang terkait dengan API dan membahas ID terarah (per situs) sebagai kemungkinan mitigasi. Namun, keputusan apakah akan menggunakan ID terarah diserahkan kepada IdP, bukan diberlakukan oleh browser.) FedCM juga sudah menyediakan pilihan pengguna terkait identitas. Misalnya, jika pengguna memiliki beberapa identitas dengan IdP yang sama (misalnya, profil kerja dan profil pribadi), FedCM menyediakan cara bagi pengguna untuk memilih identitas mana yang ingin digunakan untuk login ke situs RP. Selain itu, setiap RP memutuskan sendiri IdP mana yang akan didukung di situsnya. Salah satu aspek keputusan tersebut adalah mempertimbangkan mekanisme yang digunakan IdP, baik FedCM maupun teknologi lain. Sekali lagi, browser tidak menentukan pilihan ini untuk RP atau IdP. |
Memerangi spam dan penipuan
Private State Token API
| Feedback Theme | Ringkasan | Respons Chrome |
|---|---|---|
| Menangani Bot | Apa yang terjadi jika penerbit menemukan bahwa Token Status Pribadi telah diterbitkan ke bot? | Agar token yang diterbitkan untuk bot tidak tetap berada di ekosistem dalam waktu lama, penerbit harus memutar kunci yang mereka gunakan untuk menandatangani token secara berkala sehingga token lama yang diterbitkan berdasarkan logika penerbitan yang berpotensi rusak akan berakhir masa berlakunya dan situs menukarkan token yang lebih baru dengan logika penerbitan yang diperbarui. |
| Pengiriman formulir situs yang sama | Dapatkah Token Status Pribadi digunakan untuk pengiriman formulir di situs yang sama yang melibatkan navigasi halaman penuh (yaitu Content-Type: application/x-www-form-urlencoded) dan bukan permintaan dari API fetch/XMLHttpRequest? | Saat ini, fitur ini tidak didukung di Token Status Pribadi versi pertama. Kami menyambut masukan dari ekosistem jika ada permintaan yang kuat untuk kasus penggunaan ini. |
| Verifikasi sisi server | Pertanyaan tentang apakah Token Status Pribadi dapat diverifikasi sisi server | Token ditukarkan dengan penerbit, lalu penerbit membuat catatan penukaran yang dapat berisi token itu sendiri atau beberapa nilai yang ditandatangani yang berasal dari token, server dapat menggunakan catatan penukaran tersebut untuk memverifikasi keaslian token, dan kami berharap ekosistem penerbit yang berbeda akan memiliki standar yang berbeda untuk cara menafsirkan catatan penukaran mereka. |