Laporan triwulanan untuk Kuartal 1 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, FLEDGE, 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 |
|---|---|---|
| Pengujian dan uji coba | Relevansi pengujian untuk memberikan penilaian CMA jika API Privacy Sandbox tidak selesai pada saat pengujian dimulai | Pengembangan API Privacy Sandbox berjalan dengan cepat.
Library ini sudah tersedia di Uji Coba Origin untuk pengujian dan akan
tersedia secara umum untuk 100% traffic musim panas ini. Selain itu, kami telah mengklarifikasi linimasa untuk fitur tertentu (seperti pelaporan tingkat peristiwa FLEDGE, rendering FLEDGE dengan iframe) yang tidak akan terpengaruh lebih awal dari tahun 2026. Kami mendorong ekosistem untuk menguji API dan memberikan masukan kepada CMA berdasarkan ekspektasi penguji setelah cookie pihak ketiga tidak digunakan lagi. Hal ini dapat berkontribusi pada penilaian mereka terhadap kemungkinan dampak penghentian penggunaan cookie pihak ketiga. |
| Kontrol pengguna | Panduan yang jelas untuk ekosistem terkait implikasi kontrol pengguna dari Privacy Sandbox API | Kami tidak dapat memberikan nasihat hukum tentang hal apa saja yang dapat digunakan oleh ekosistem kontrol pengguna. Pada saat yang sama, Chrome sedang bereksperimen dengan menampilkan kontrol pengguna Privacy Sandbox ("Privasi Iklan yang Ditingkatkan") kepada sebagian kecil pengguna, sebagai bagian dari upaya berkelanjutan kami untuk meningkatkan teknologi Privacy Sandbox. Pembaruan ini mencakup bahasa dan tata letak yang lebih jelas dan lebih membantu. Setelah Chrome mengevaluasi penyempurnaan ini dan memutuskan apakah akan memperluasnya ke populasi yang lebih besar, mereka dapat membagikan lebih banyak informasi dengan ekosistem. |
| Kebocoran data | Risiko kebocoran data pihak pertama ke Google dan pihak lainnya jika browser disusupi | Penjelasan
FLEDGE kami memperjelas bahwa satu data teknologi iklan hanya dibagikan
dengan teknologi iklan yang sama (baik dengan worklet atau server
terpercaya) atau jika dibagikan secara eksplisit oleh teknologi iklan tersebut (seperti pembeli
menunjukkan URL iklan yang ingin ditampilkan kepada penjual). Satu-satunya pengecualian
adalah pemeriksaan k-anonymity harus dilakukan oleh server
terpusat global, yang merupakan area yang terus kami alokasikan resource
yang signifikan. Baca penjelasan
K-anonymity untuk mendapatkan pemahaman mendetail mengenai pandangan kami tentang
privasi. Selain itu, kami bersedia untuk memberikan detail selengkapnya tentang cara kerja perlindungan teknologi iklan yang digunakan dalam desain server k-anonymity. |
| Forum tambahan untuk diskusi | Meminta forum tambahan ke W3C bagi pemain ekosistem non-teknis untuk memberikan masukan | Formulir masukan
Privacy Sandbox sesuai untuk komentar umum dan spesifik, teknis dan non-teknis. Meningkatkan Grup Bisnis Iklan Web adalah forum untuk berdiskusi melalui panggilan mingguan dan repositori GitHub. Halaman Masukan Privacy Sandbox di developer.chrome.com menjelaskan mekanisme lain untuk memberikan masukan dan berinteraksi dalam diskusi. Chrome juga terus mengadakan acara seperti Waktu Konsultasi publik untuk memfasilitasi pertanyaan dan berbagi konten. Selain itu, Chrome telah menyelenggarakan atau menghadiri lebih dari selusin acara industri dalam kuartal terakhir ini. |
| Klarifikasi linimasa | Klarifikasi tentang tanggal pasti ketersediaan Umum pada Kuartal 3 2023 | Berdasarkan linimasa yang dipublikasikan di PrivacySandbox.com, Ketersediaan Umum ditargetkan untuk memulai peluncuran dengan rilis Chrome versi 115. |
| reCAPTCHA | Dampak Sandbox API untuk kasus penggunaan deteksi spam reCATPCHA | Kami mendapatkan masukan dari reCAPTCHA secara berkala untuk memastikan proposal Privacy Sandbox tidak memengaruhi keamanan atau penipuan web secara signifikan. Mereka mengembangkan rencana sendiri untuk mempersiapkan dan menyesuaikan penghentian cookie pihak ketiga, sehingga pertanyaan ini paling tepat dijawab oleh mereka. |
| Ekstensi Chrome | Apakah teknologi Privacy Sandbox seperti tindakan Anti Covert Tracking (ACT) akan berlaku untuk ekstensi Chrome? | Kami belum membuat pengumuman apa pun tentang apakah ACT dapat berlaku untuk ekstensi Chrome. Namun, jika teknologi secara diam-diam mengumpulkan informasi tentang pengguna, ini tidak akan sejalan dengan prinsip privasi kami. |
Tampilkan Konten dan Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Tinjauan Desain TAG | TAG merilis Ulasan Desain Awal Topics. | Kami tetap berkomitmen pada Topics dan menyampaikan informasi terbaru tentang komitmen kami terhadap Topics di halaman info terbaru dan dalam masalah ini. Kami merespons ulasan TAG secara menyeluruh dan menyampaikan visi yang lebih tinggi di sini. Topics API akan tetap menjadi bagian dari kumpulan API yang harus diuji oleh ekosistem iklan selama tahun 2023 — dan kami berharap masukan pengujian yang kami dapatkan serta pengalaman pengimplementasi yang kami dapatkan akan berkontribusi berharga dalam upaya mendatang terhadap standar lintas browser yang bekerja di ruang ini. Kami berharap dapat terus berkomunikasi dengan ekosistem untuk memudahkan transisi dengan Topics API yang dapat menjadi standar yang disepakati dengan kompatibilitas lintas browser. |
| Pendekatan terhadap Topik | Dukungan untuk pendekatan terbuka yang dimiliki Chrome untuk mengembangkan Topics API | Kami menghargai sentimen ini dan berharap dapat terus bekerja sama dengan grup industri untuk mengembangkan Topics API yang memberikan nilai bagi ekosistem secara keseluruhan. |
| (Juga dilaporkan pada Kuartal 3 2022) Taksonomi topik tidak cukup terperinci |
Taksonomi topik yang luas tidak mencakup topik yang lebih terperinci, termasuk yang spesifik per wilayah. | Pembaruan Kuartal 1: Peningkatan taksonomi adalah upaya berkelanjutan, dan pada Kuartal 2 kami akan mengumumkan taksonomi yang diperbarui untuk Topics API. Untuk menyusun taksonomi baru ini, kami bekerja sama dengan perusahaan dari seluruh ekosistem. Kami secara aktif mencari masukan terkait taksonomi yang paling berguna untuk ekosistem. Saat mengevaluasi apakah akan memperluas jumlah topik atau menyertakan topik yang lebih terperinci, ada beberapa pertimbangan termasuk 1) potensi implikasi privasi (lebih banyak topik dapat menimbulkan risiko pelacakan sidik jari) dan 2) kemampuan untuk mengambil topik yang diamati sebelumnya (seperti dengan lebih banyak topik, mungkin ada lebih sedikit peluang bahwa teknologi iklan telah melihat topik yang dipilih di masa lalu). |
| (Juga dilaporkan pada Kuartal 4 2022) Dampak pada sinyal pihak pertama |
Sinyal topik dapat sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. | Kami percaya bahwa periklanan menurut minat adalah kasus penggunaan yang penting bagi web, dan Topics dirancang untuk mendukung kasus penggunaan tersebut. Kami memahami bahwa beberapa penayang besar khawatir jika Topics akan berdampak negatif pada strategi data pihak pertama mereka. Kami menantikan pengujian ekosistem, yang akan memberikan insight tentang dampak Topics terhadap penerbit. |
| Kasus penggunaan Topik yang Tidak terkait Iklan | Penggunaan Topics untuk tujuan selain menampilkan iklan menurut minat | Topics didesain untuk menangani kasus penggunaan periklanan menurut minat, yang kami yakini merupakan kasus penggunaan penting untuk web yang gratis dan terbuka. Saat ini kami sedang mencari masukan untuk kasus penggunaan lainnya dan melakukan evaluasi. |
| Status keikutsertaan default | Dampak legislasi regional untuk default izin Topics | Kami tidak berhak mengomentari opini hukum. |
| (Juga dilaporkan pada Kuartal 3 2022) Situs yang salah dikategorikan |
Penargetan iklan saat topik salah dikategorikan untuk situs tertentu | Pembaruan Kuartal 1: Pada Kuartal 2, kami akan mengumumkan pengklasifikasi yang diperbarui untuk Topics API dan berharap dapat berinteraksi dengan ekosistem di dalamnya. Sebagai respons terhadap masukan saat ini, situs diklasifikasikan melalui kombinasi daftar penggantian yang diseleksi oleh manusia, yang berisi situs paling populer, dan model ML di perangkat. Chrome terus mengevaluasi opsi bagi situs untuk berkontribusi pada klasifikasi Topik. Setiap peningkatan utilitas harus dipertimbangkan untuk risiko privasi dan penyalahgunaan. Misalnya, beberapa risikonya meliputi: situs yang menggunakan pelabelan mandiri sebagai metode untuk mengenkode arti yang berbeda (dan berpotensi sensitif) ke dalam topik; situs yang membuat pernyataan tidak benar tentang topik mereka demi keuntungan finansial; situs yang menyerang topik untuk menuduh kegunaannya bagi orang lain (misalnya, mengirim spam ke topik pengguna dengan kata-kata yang tidak bermakna). Publik dapat memeriksa komponen tersebut, dengan alat yang tersedia melalui chrome://topics-internals atau colab ini. Melalui pengujian, kami berharap klasifikasi dapat meningkat seiring waktu, dan kami menerima masukan tentang contoh situs yang mungkin salah dikategorikan. |
| Pengklasifikasi Topik | Permintaan untuk menampilkan informasi tambahan yang menampilkan alasan "Tidak Ada Topik" ditampilkan ke pemanggil untuk tujuan proses debug | Kami memahami dan menghargai bahwa alat proses debug sangat membantu developer, karena mereka bekerja untuk mengintegrasikan Topics API ke dalam sistem mereka. Namun, dengan mengekspos informasi tambahan (seperti alasan mengapa tidak ada Topics yang ditampilkan), kami mungkin secara tidak sengaja membagikan informasi yang memungkinkan pihak menemukan detail tambahan (misalnya, jika pengguna berada dalam mode samaran, telah menonaktifkan API, dan sebagainya) di luar yang dimaksudkan, sehingga membahayakan privasi pengguna. Meskipun saat ini kami tidak berencana menyediakan alat proses debug tambahan, kami terbuka untuk menerima masukan tentang alat yang akan berguna. |
| Pengambilan Informasi Pribadi (PIR) | Permintaan untuk Topics API untuk mengadopsi Pengambilan Informasi Pribadi | Sebelumnya kami telah menyelidiki menggunakan PIR dan telah membagikan konsekuensinya di sini. |
| Aliran bid | Apakah Topik akan direpresentasikan secara berbeda dari Audiens yang Ditetapkan Penjual dalam kumpulan bid? | Topics API adalah proposal Privacy Sandbox yang dikembangkan oleh Chrome, yang berbeda dengan proposal Audiens yang Ditetapkan Penjual IAB Tech Lab. Kami memperkirakan keduanya akan direpresentasikan secara berbeda dalam bidstream. Pelajari cara Topics diwakili dalam permintaan bid OpenRTB. |
Protected Audience API (sebelumnya FLEDGE)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Ketersediaan fitur FLEDGE | Klarifikasi terkait linimasa pengujian dan penerapan fitur FLEDGE seperti penerapan Fenced Frame, K-Anonymity, dan sebagainya. | Kami telah membagikan postingan blog tentang berbagai cakupan fitur FLEDGE dan kapan fitur tersebut akan didukung. Kami menantikan masukan tambahan terkait pengumuman ini selagi kami terus mengembangkan FLEDGE. |
| Batasan rendering produk | Permintaan untuk melonggarkan Iklan yang Terdiri dari Beberapa Bagian yang dibatasi untuk Frame dengan Fence FLEDGE | Seperti yang kami umumkan pada bulan Februari, penggunaan Fenced Frames akan tetap bersifat opsional hingga setidaknya tahun 2026, dan perilaku iframe akan didukung oleh urn-iframe. Kami menerima diskusi lebih lanjut tentang topik ini. |
| Masalah skalabilitas | Performa FLEDGE sebagai skala penggunaan | Kami secara aktif menindaklanjuti masukan dan memahami konteks yang lebih lengkap sehingga kami dapat mengusulkan solusi yang dapat ditindaklanjuti. Langkah pertama adalah memisahkan masukan menjadi dua kategori, yaitu:
|
| (Juga dilaporkan pada K3 2022) Visibilitas logika bidding |
Masalah bahwa logika bidding DSP akan ditampilkan di JavaScript | Update K1: Kami telah membagikan proposal yang akan membatasi kemampuan musuh untuk meminta data dari server dengan cara eksploratif (penjelajahan paksa) dan kami menyambut pemain ekosistem untuk memberikan masukan atau dukungan mereka terkait proposal ini. |
| Kesulitan pengujian | Kemampuan DSP yang lebih kecil untuk menguji FLEDGE dengan benar, dan mengurangi risiko bahwa pengiklan hanya tertarik untuk melakukan pengujian dengan DSP yang lebih besar | Kami berkomitmen untuk bekerja sama dengan DSP yang lebih kecil dan sangat mendorong pengujian yang diperluas di antara DSP dan pengiklan dari semua ukuran seiring FLEDGE beralih ke ketersediaan umum. Kami ingin mengetahui bagaimana kami dapat membantu mereka sebaik mungkin dalam menguji FLEDGE dengan orang lain di ekosistem, serta menyambut ide dan upaya industri untuk memotivasi pengiklan agar melakukan pengujian dengan DSP yang lebih kecil. |
| Pemasaran ulang dinamis | Apakah Pemasaran ulang dinamis masih dapat dilakukan dengan FLEDGE setelah penghentian cookie pihak ketiga? | Kami sedang mempertimbangkan jawaban atas pertanyaan ini dan mengajak para pemain ekosistem untuk membagikan insight tambahan tentang cara mereka ingin menggunakan Pemasaran ulang dinamis. |
| Penipuan/Penyalahgunaan | Bagaimana ekosistem dapat mengurangi risiko dan menghentikan pihak yang tidak bertanggung jawab atau pembeli agar tidak memposisikan diri mereka sebagai audiens yang diinginkan? | Kami berharap dapat berinteraksi lebih lanjut dengan para pemain ekosistem terkait penipuan dan penyalahgunaan, serta menerima lebih banyak masukan dalam area ini. |
| Preferensi pengguna | Proses untuk menyimpan preferensi pengguna dan penggunaan dalam pemilihan iklan | Untuk iklan tertentu, teknologi iklan yang relevan adalah pihak yang paling tepat untuk menawarkan kontrol atas materi iklan yang ditampilkan atau cara pemilihan. |
| Proposal Pengujian Kuantitatif | Agar Pengujian Kuantitatif adil, apakah pengujian harus dilakukan pada traffic tanpa cookie pihak ketiga atau dengan SSP yang hanya menggunakan FLEDGE? Bagaimana pencampuran sinyal dari cookie pihak ketiga dapat dihindari? | Kami menghargai masukan ini dan bekerja sama dengan CMA untuk mendesain eksperimen yang akan memberikan gambaran tepercaya tentang dampak penghentian cookie pihak ketiga dan pengenalan proposal Privacy Sandbox pada ekosistem. Sebaiknya sampaikan masukan tambahan tentang proposal Pengujian Kuantitatif CMA langsung kepada CMA. |
| Dokumentasi yang lebih jelas | Meminta dokumentasi yang lebih jelas tentang konfigurasi lelang | Kami ingin membagikan postingan blog yang berisi ringkasan tambahan tentang FLEDGE Lelang Reporting dalam beberapa minggu mendatang. |
| Paralelisasi | Apakah Layanan Bidding dan Lelang (B&A) akan mendukung Paralelisasi? | Teknologi iklan yang menggunakan server Bidding / Lelang dapat memulai beberapa server yang dapat menayangkan hasil secara paralel. |
| Mitigasi penyalahgunaan | Apakah server k-anonymity FLEDGE yang menggunakan Token Status Pribadi akan cukup untuk memastikan privasi pengguna? | Motivasi untuk k-anonymity tidak terlalu difokuskan pada penargetan mikro, tetapi lebih pada memiliki beberapa backstop selama fase sementara saat FLEDGE memungkinkan pelaporan tingkat peristiwa. Kami telah menyampaikan lebih banyak pendapat dan menerima masukan tambahan. |
| Konflik Modul ES | Permintaan untuk menghapus generateBid sebagai fungsi global karena bertentangan dengan
modul ES |
Kami membahas permintaan ini dan menantikan masukan tambahan. |
| Lelang komponen | Meminta penayang untuk memiliki kontrol lebih besar atas desain lelang | Rencana bidding dan lelang untuk mendukung lelang komponen, sama seperti Chrome di perangkat. |
| Jadwal B&A | Kejelasan linimasa untuk teknologi iklan yang tertarik untuk menguji Server B&A | Kami baru saja memperbarui B&A Explainer dan memperbarui bagian Linimasa untuk menyertakan definisi yang jelas tentang linimasa untuk berbagai fase pengujian Chrome-B&A, setelah menyelaraskan dengan CMA. |
| Skema kontrol waktu tunggu | Meningkatkan skema kontrol waktu tunggu yang saat ini tersedia untuk FLEDGE | Ini adalah proposal yang menarik. Kita akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangan kita. |
| Aliran bid materi iklan | Kemampuan untuk meninjau dan memfilter bid pemenang, berdasarkan materi iklan | Ini adalah proposal yang menarik. Kita akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangan kita. |
reportWin |
Proposal untuk memberikan informasi tambahan tentang bid dengan skor tertinggi
dari pemilik grup minat yang berbeda selain pemenang dalam
fungsi reportWin |
Ini adalah proposal yang menarik. Kami akan mempertimbangkan untuk menambahkan sinyal tambahan dalam pelaporan gabungan dan menerima masukan tambahan di sini. |
| Jenis peristiwa | Menstandarkan jenis peristiwa di seluruh API pengukuran saat terintegrasi dengan FLEDGE | Ini adalah proposal yang menarik. Kita akan menambahkannya ke antrean proposal untuk dipelajari, dan melaporkan perkembangan kita. Diperlukan koordinasi dengan upaya kami yang lebih luas dalam bidang ini, karena akan memengaruhi Privacy Sandbox API lainnya di luar FLEDGE. Kami menantikan masukan tambahan di sini. |
| Solusi jangka panjang untuk pelaporan tingkat peristiwa | Minat untuk mempertahankan ketersediaan data tertentu seperti highestScoringOtherBid meskipun cookie pihak ketiga tidak lagi digunakan |
Seperti yang telah kami sampaikan dalam postingan blog Februari, pelaporan kemenangan lelang tingkat peristiwa akan didukung hingga "setidaknya tahun 2026". Kami tidak dapat membagikan detail lebih lanjut saat ini, tetapi kami mengharapkan masukan tambahan tentang perlunya menjaga ketersediaan data tertentu setelah cookie pihak ketiga tidak digunakan lagi. |
| Batas grup minat | Berapa batas jumlah grup minat yang dapat ditambahi satu browser oleh origin? | Chrome mengizinkan hingga 1.000 grup minat per pemilik, dan hingga 1.000 pemilik grup minat. Hal ini dimaksudkan sebagai pagar pembatas, bukan untuk ditabrak dalam operasi biasa. |
| Sinyal tingkat peristiwa | Dukungan untuk proposal memiliki sinyal tingkat peristiwa untuk generateBid
dan reportWin, yang dapat digunakan dalam pelatihan machine learning |
Kami telah menyampaikan keputusan kami untuk sinyal yang didesain browser dan sinyal yang ditentukan teknologi iklan di sini serta menerima masukan tambahan. |
| Skrip bidding | Sertakan ID pengguna di URL ke skrip bidding. | Hal ini tidak mungkin dilakukan karena FLEDGE memiliki persyaratan tambahan bahwa tuple pemilik grup minat, URL skrip bidding, dan materi iklan yang dirender harus bersifat k-anonim agar iklan dapat ditampilkan. |
| Penegakan K-anon | Apakah k-anonymity diterapkan pada pasangan (componentAd, size)? | Ya. Lihat turtledove/issues/312. |
| Persyaratan Layanan Bidding dan Lelang | Bagaimana Layanan B&A mendukung peserta berintegrasi dengan FLEDGE di perangkat dan lainnya dengan layanan B&A? | Kami masih menyelesaikan desain dan menerima masukan tambahan di sini. |
| Atribusi pasca-penayangan | Apakah Atribusi pasca-penayangan akan didukung? | Saat ini, kami tidak memiliki definisi standar visibilitas dan mengandalkan materi iklan itu sendiri untuk menandai peristiwa penayangan. Lihat turtledove/issues/452. |
| Penargetan mirip | Dapatkah Privacy Sandbox mendukung "penargetan yang mirip"? | Kita membahas kasus penggunaan di sini dan menerima input tambahan. |
| API pemantauan real-time | Proposal untuk pendekatan pemantauan FLEDGE real-time | Kami sedang mendiskusikan proposal ini dan menerima masukan tambahan di sini. |
| Pelaporan FLEDGE | reportWin dan reportResult harus dibuat dalam urutan acak untuk mencegah pelaporan yang berlebihan atau kurang. |
reportResult() harus dijalankan terlebih dahulu oleh penjual sebelum
reportWin() oleh pembeli agar sinyal penjual dari reportResult()
dapat disertakan dalam reportWin(). Baca penjelasan untuk mengetahui informasi selengkapnya. |
| Server Nilai Kunci Kustom (K/V) | Apakah server K/V kustom akan didukung di masa mendatang? | Kami membahas pertanyaan tersebut di sini dan menerima masukan tambahan apa pun. |
| Lelang tingkat teratas | Apakah kampanye harus menjadi server iklan untuk menjalankan mekanisme lelang tingkat atas? | FLEDGE API tidak menentukan pihak mana yang harus memanggilnya; dalam hal ini, tidak ada persyaratan dalam desain FLEDGE. Siapa pun dapat menjalankan lelang FLEDGE (termasuk lelang multi-penjual). Seperti yang disebutkan dalam laporan Kuartal 4 2022, FLEDGE memungkinkan setiap penayang memilih struktur lelang, termasuk pilihan penjual tingkat atas dan komponen. |
| Cakupan API | Apakah FLEDGE bermaksud menggunakan data pihak pertama? | Kami akan memublikasikan konten pada Q2 2023 yang mengklarifikasi bahwa data pihak pertama benar-benar dapat digunakan dengan FLEDGE untuk 1) digunakan sebagai logika untuk menentukan keanggotaan grup minat dan 2) untuk dijadikan feed sebagai sinyal bidding pengguna untuk digunakan dalam pembuatan logika bidding berikutnya. |
| Grup minat lintas-domain | Kemungkinan membuat grup minat lintas-domain | Informasi apa pun yang tersedia saat menambahkan browser ke grup minat dapat digunakan untuk menginformasikan audiens tersebut. Saat cookie pihak ketiga dihapus, ketersediaan data lintas situs untuk menginformasikan pembuatan grup minat akan dibatasi. |
| Logika bidding sisi klien | Mem-porting logika bidding sisi server yang ada ke sisi klien | Kami tertarik untuk mempelajari lebih lanjut area mana yang menantang atau saat ini kurang dalam proses transfer, dan menerima masukan atau insight tambahan. |
| Nilai server K/V | Apakah nilai server K/V harus berupa string jenis? | Nilai harus berupa string, tetapi dapat menyimpan objek di JSON atau buffering protokol dan melakukan serialisasi ke dalam string. |
| Daftar pengiklan yang tidak diizinkan | Sinyal apa yang sesuai untuk memberikan pembeli daftar pengiklan yang tidak diizinkan? | Tempat yang sesuai adalah di auctionSignals atau di
perBuyerSignals. |
| Unit bidding | Dukungan untuk berbagai unit bidding seperti CPI dan CPM | Kami ingin mempelajari lebih lanjut alasan diperlukannya solusi ini mengingat desain saat ini dan ingin mendengar masukan tambahan. |
| Logika lelang | Apakah browser atau server Iklan menentukan pemenang lelang? | Semua pilihan pemenang dijalankan di dalam sandbox, dan semua keputusan dibuat oleh kode penjual. Browser hanya menyediakan lingkungan pribadi yang tertutup, tempat kode pembeli dan penjual dijalankan. |
| Kebijakan-Izin | Apakah Kebijakan Izin FLEDGE saat ini akan terus diterapkan setelah Uji Coba Origin berakhir? | Untuk Uji Coba Origin, daftar yang diizinkan default saat ini dari kedua fitur tersebut bersifat sementara dan akan diubah. Kami ingin mengetahui berapa lama teknologi iklan perlu mempersiapkan perubahan sebelum mulai menerapkannya. |
| Batasan ukuran sinyal | Permintaan Sinyal Bidding Tepercaya digabungkan di beberapa
grup minat dengan trustedBiddingSignalsUrl yang sama; batas ukuran 2 MB
menjadi batasannya. |
Batasan ini ada untuk pemanggil di perangkat guna mencegah resource yang berlebihan pada perangkat. Pemanggil dari Server B&A akan memiliki batasan yang lebih longgar. |
| Sinyal pelaporan | Tambahkan sinyal tambahan, error skrip, untuk memungkinkan pengambilan jumlah error sisi klien per pemilik grup minat dan per computeBid atau reportWin / reportResult. |
Kami mempertimbangkan potensi masalah privasi dalam proposal ini dan menerima para pemain ekosistem untuk memberikan insight tambahan tentang alasan hal ini diperlukan. |
| Ukuran jendela K-Anon | Tingkatkan ukuran jendela K-Anon dari batas 7 hari saat ini. | Hal ini sedang dipertimbangkan dan kami saat ini sedang menunggu (dan menyambut) input tambahan dari ekosistem. |
| Performa perangkat | Bagaimana cara FLEDGE menangani performa perangkat jika pengguna berada dalam sejumlah besar grup minat? | FLEDGE menawarkan beberapa opsi waktu tunggu, prioritas, dan batas di seluruh SSP dan DSP yang memberi teknologi iklan kontrol terperinci dalam situasi ketika performa perangkat mungkin menjadi salah satu alasan untuk membatasi partisipasi lelang saat perangkat berada dalam sejumlah besar grup minat. |
| Pengujian Layanan B&A | Minta pemain ekosistem untuk menggunakan server mereka sendiri selama fase pengujian agar lebih banyak log tersedia untuk proses debug | B&A memungkinkan pengguna meluncurkan dan menskalakan server dari penyedia cloud yang disetujui. Untuk menjaga privasi pengguna, kami menerapkan eksekusi yang harus dilakukan dalam trusted execution environment (TEE). Kami akan segera merilis penjelasan tentang proses debug B&A TEE dan mengembangkan fitur untuk mendukungnya. Kami meminta masukan tambahan terkait topik tersebut. |
| Persyaratan peraturan | Apakah FLEDGE akan bekerja sama dengan penyedia cloud di berbagai negara untuk mendukung kepatuhan terhadap persyaratan peraturan setempat? | Kami selalu menerima saran untuk penyedia cloud lainnya, tetapi saat ini kami berencana setidaknya untuk mendukung GCP dan AWS saat penghentian penggunaan cookie pihak ketiga diterapkan. Baca penjelasan ini untuk mengetahui informasi selengkapnya. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Analisis data dampak derau | Panduan cara melakukan analisis data tentang dampak Noise | Kami telah membagikan dokumentasi
tambahan terkait keputusan derau dan desain yang dapat
digunakan untuk mengubah dampak derau pada data teknologi iklan. Panduan yang lebih mendetail juga tersedia. |
| Pelaporan null | Kejelasan penerapan laporan null | Saat ini, kami sedang mengerjakan proposal untuk menerapkan laporan null dan kami akan segera membagikan detail selengkapnya. Menerapkan laporan null akan memungkinkan kami mengurangi penundaan laporan tanpa mengorbankan privasi. |
| Level kebisingan | Menyesuaikan level derau berdasarkan durasi periode atribusi | Kami menyambut baik proposal ini dan ingin menambahkannya ke spesifikasi. Kami menantikan masukan tambahan di sini. |
| Ukuran data pemicu | Mengapa ukuran data pemicu dibatasi hingga 3 bit? | Ukurannya dibatasi hingga 3 bit dan 8 nilai yang berbeda untuk memastikan jumlah informasi lintas situs/konteks tentang pengguna dibatasi. Kami mempersilakan pemain ekosistem untuk mengirimkan masukan tentang apakah parameterisasi saat ini untuk pelaporan tingkat peristiwa dapat diterima. |
| Pemicu pelaporan tingkat peristiwa | Mengizinkan penentuan prioritas dalam kunci penghapusan duplikat | Kami sedang mencari solusi untuk masalah ini dan menantikan masukan tambahan. |
| Dukungan proses debug | Kejelasan proses debug setelah cookie pihak ketiga tidak digunakan lagi | Kami ingin mendukung proses debug setelah cookie pihak ketiga tidak digunakan lagi dan sedang mempertimbangkan opsi. Kami memerlukan masukan dan ide tambahan. |
| Alternatif konversi klik tayang | Meminta panduan lebih lanjut tentang alternatif untuk konversi klik-tayang | Kami mendorong ekosistem untuk menggunakan Attribution Reporting API sebagai sistem pengukuran pribadi yang andal untuk kasus penggunaan pengukuran konversi yang berlaku. Alternatif lain ada dan penyedia teknologi iklan harus menentukan solusi yang tepat berdasarkan kebutuhan privasi dan utilitas yang diinginkan. |
| Kasus penggunaan penagihan | Kejelasan tentang sejauh mana Attribution Reporting akan mendukung kasus penggunaan penagihan berbasis konversi | Kami sedang berupaya memposting secara publik untuk memperjelas cakupan
Attribution Reporting API untuk penagihan. Attribution Reporting API
pada awalnya tidak dicakupkan dengan cara yang mendukung penagihan CPA secara langsung, tetapi
mendukung penagihan CPC dan CPM, yang merupakan struktur penagihan
yang digunakan sebagian besar teknologi iklan. Ini adalah fitur yang mungkin kami dukung pada masa mendatang jika ada masukan ekosistem tambahan. |
| Dukungan kasus penggunaan | Dokumentasi kasus penggunaan untuk API pengukuran | Kami sedang berupaya memperjelas dokumentasi untuk semua platform pelaporan Privacy Sandbox. |
| Mutu klik | Permintaan untuk menambahkan sinyal guna membedakan klik yang disengaja dan tidak disengaja pada iklan | Kami membahas permintaan ini dan menantikan masukan tambahan. |
| Solusi pengukuran | Dukungan untuk solusi pengukuran di berbagai DSP | Attribution Reporting API dapat digunakan oleh penyedia pengukuran untuk
menghapus duplikat di antara beberapa DSP. Selain itu, kami mengusulkan
dukungan untuk daftar URL di attributionsrc,
yang akan mempermudah DSP dalam mendukung permintaan
Attribution Reporting API penyedia pengukuran. Kami menantikan masukan
tambahan terkait proposal di atas. |
| Pelaporan tingkat peristiwa | Meminta jumlah hari sebelum laporan dikirim tersedia secara langsung | Permintaan ini sudah dapat dihitung oleh teknologi iklan menggunakan informasi yang saat ini tersedia. Kami belum mendengar masukan ekosistem lainnya terkait permintaan ini, tetapi kami akan menerima masukan terkait permintaan ini. |
source_registration_time |
Tambahkan source_registration_time di Attribution Reporting tingkat peristiwa. |
Kami mempertimbangkan permintaan ini dan menantikan masukan tambahan tentang apakah ekosistem ini menurut para pemain game yang berguna untuk dimiliki. |
| Mode Samaran | Apakah solusi pengukuran akan tersedia saat pengguna berada dalam mode Samaran? | Tidak, solusi pengukuran tidak akan tersedia saat pengguna berada dalam mode Samaran. Cookie pihak ketiga dinonaktifkan secara default dalam mode Samaran. |
| Ruang bersih data | Apakah Measurement API kompatibel dengan ruang bersih? | Ruang bersih data standar adalah lingkungan tempat data ID individu dari sumber yang berbeda diupload ke database untuk menjalankan analisis berdasarkan penggabungan data pokok tersebut. Dua framework pengukuran untuk Privacy Sandbox API adalah laporan tingkat peristiwa dan laporan ringkasan. Laporan tingkat peristiwa berisi ID peristiwa yang disediakan teknologi iklan yang dapat digunakan di ruang pembersihan data, tetapi informasi sisi konversi yang terkait akan terbatas dan berisik. Laporan agregat yang dienkripsi tidak dapat digunakan langsung di ruang bersih, tetapi hasil ringkasan yang disediakan oleh Layanan Agregasi dapat digunakan sebagai input untuk analisis yang Anda lakukan atau sebagai informasi tambahan. |
Layanan Agregasi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan pada K4 2022) Keterlambatan pelaporan |
Berapa perkiraan penundaan pelaporan? | Update Kuartal 1 2023: Setelah menerima masukan dari partner, kami telah membagikan proposal untuk mengurangi penundaan dan mengurangi dampak penundaan. Kedua proposal telah didukung oleh teknologi iklan selama panggilan WICG. |
| Tidak ada aturan duplikat | Bagaimana cara menangani "laporan agregat tertunda" jika laporan agregat, yang memiliki ID bersama yang sama, sudah diproses? | Kami telah membagikan proposal tentang cara menambahkan penundaan laporan tambahan ke info bersama laporan agregat dan definisi ID bersama untuk Layanan Agregasi untuk mengatasi sebagian dampak kehilangan penundaan pada API agregat. Kami menerima masukan apa pun tentang proposal. |
| Pemrosesan data | Permintaan untuk mengaktifkan dukungan beberapa penerusan data sekaligus menghormati privasi diferensial, menggunakan Anggaran Privasi | Kami sedang membahas kemungkinan menggunakan cara yang lebih fleksibel dalam menggunakan Anggaran Privasi untuk memungkinkan kasus penggunaan ini dan menerima masukan tambahan. |
| (Juga dilaporkan pada K2 2022) Ergonomi kueri | Aktifkan kueri gabungan kunci. | Update K1 2023: Permintaan fitur masih dipertimbangkan, tetapi kami tidak memiliki proposal untuk saat ini. |
| Batasan Uji Coba Origin | Mengklarifikasi cakupan Layanan Agregasi seperti "aturan jangan duplikasi" yang saat ini tidak diterapkan dalam uji coba origin. | Kami ingin memperbarui dokumentasi kami untuk mengklarifikasi apa saja yang akan tersedia dalam uji coba origin vs di GA. |
API Agregasi Pribadi
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Anggaran Kontribusi Agregasi Pribadi | Anggaran kontribusi L1 terlalu ketat. | Setiap panggilan ke Private Aggregation API disebut kontribusi. Untuk melindungi privasi pengguna, jumlah kontribusi yang dapat dikumpulkan dari individu dibatasi. Saat Anda menjumlahkan semua nilai agregasi di semua kunci agregasi, jumlahnya harus lebih kecil dari anggaran kontribusi. Dalam desain saat ini, kami menetapkan batas kontribusi untuk asal pelaporan tertentu selama ~24 jam terakhir (sebagai periode berputar). Itu adalah anggaran kontribusi L1 yang disebutkan dalam masukan. Sebaiknya developer menskalakan nilai yang mereka kontribusikan berdasarkan volume yang diharapkan (yaitu, tidak hanya menggunakan nilai 1). Jadi, sebaiknya gunakan nilai yang lebih kecil untuk peristiwa yang lebih umum agar anggaran tidak habis. Saat ini, kami meminta masukan tentang anggaran kontribusi Private Aggregation API tentang batas numerik dan cakupan. Kami mempertimbangkan untuk memindahkan cakupan dari per origin ke per situs dan memindahkan batas yang ada ke jendela sepuluh menit dengan batas harian yang lebih besar. |
Batasi Pelacakan Terselubung
Pengurangan Agen Pengguna/Petunjuk Klien Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Adopsi UA-R | Dari 10.000 situs teratas di Inggris Raya, hanya 1% situs yang menggunakan iklan terprogram mengirimkan petunjuk klien HTTP. DSP yang belum migrasi mungkin memiliki dampak terhadap kemampuan antipenipuan. | Setelah menjalankan analisis pada set data yang sama, kami menemukan bahwa jika Anda memperhitungkan penggunaan UA-CH melalui tag <meta> HTML dan JavaScript API, jumlah situs yang menggunakan UA-CH jauh lebih tinggi daripada angka 1% yang diberikan dalam masukan. Berdasarkan hal ini, dan fakta lainnya termasuk masukan ekosistem, kami merasa yakin untuk melanjutkan peluncuran bertahap Pengurangan UA Fase 6, sesuai dengan linimasa yang dipublikasikan, sambil terus memberikan informasi terbaru kepada CMA. Kami mendapati bahwa situs telah memiliki masa tunggu hampir dua tahun untuk mempersiapkan transisi dan uji coba penghentian penggunaan masih tersedia untuk situs yang dirasa belum siap. |
| Petunjuk untuk faktor bentuk tambahan | Meminta UA-CH untuk menyediakan faktor bentuk tambahan seperti TV, VR | Kami menyambut baik proposal ini dan ingin memasukkannya ke dalam desain. Kami menerima masukan tambahan. |
| Pengujian otomatis | Permintaan untuk mengatasi bug UA-CH di Chrome headless sebelum UAR Tahap 6 dikirim | Bug yang dimaksud telah diperbaiki. |
| Dukungan UA-CH di iOS | Situs yang mengandalkan info UA yang terperinci untuk kasus penggunaan iklan mencatat bahwa Chrome di iOS tidak didukung. | Untuk browser iOS non-Safari (termasuk Chrome di iOS), project WebKit perlu menambahkan dukungan untuk UA-CH sebelum dapat diaktifkan (karena project tersebut mengontrol stack jaringan). |
Perlindungan IP (sebelumnya Gnatcatcher)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan di K4) Kasus penggunaan Geolokasi | Perlindungan IP dapat mencegah kasus penggunaan geolokasi yang sah agar tidak berfungsi pada masa mendatang, seperti personalisasi konten berdasarkan geolokasi. | Respons kami tidak berubah sejak Q4 2022: "Kami bekerja sama dengan pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami mengharapkan masukan ekosistem tentang perincian Geolokasi IP". |
| Kepatuhan terhadap peraturan | Jika suatu wilayah memiliki populasi di bawah 1 juta, batas saat ini sebesar 1 juta untuk perlindungan IP akan mencegah situs menggunakan alamat IP untuk mematuhi peraturan. | Kami bekerja sama dengan para pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan yang sah untuk alamat IP. Kami meminta masukan ekosistem tentang kepatuhan terhadap peraturan tentang Perlindungan Kekayaan Intelektual. |
| Mitigasi penyalahgunaan | Pihak dapat mengakali Perlindungan IP dengan membagikan alamat IP yang tidak disamarkan kepada pihak lain. | Kami menyadari risiko bahwa proposal Perlindungan KI saat ini mungkin secara teknis tidak mencegah pihak berbagi alamat IP tanpa bersembunyi dengan orang lain. Kami sedang berupaya melakukan mitigasi yang akan menghindari
risiko penyalahgunaan ini. Saat kami melakukan iterasi pada proposal, kami mendorong lebih banyak masukan dan diskusi. Secara khusus, kami ingin mengetahui kasus penggunaan apa pun yang diyakini oleh pihak lain bahwa mereka perlu membagikan alamat IP yang tidak bersembunyi kepada pihak lain. |
| Pemblokiran jaringan | Pihak dapat mengakali pemblokiran jaringan dengan menggunakan Proxy Perlindungan IP. | Untuk skenario ini, entitas yang melakukan pemblokiran harus menonaktifkan Perlindungan IP. Kami telah merespons masalah dan menantikan masukan tambahan. |
| Daftar pemblokiran alamat IP yang terpengaruh oleh proposal Perlindungan IP | Banyak perusahaan teknologi iklan menggunakan daftar blokir dasar alamat IP, seperti daftar IP pusat data TAG, untuk mencegah bidding pada inventaris iklan yang kemungkinan besar merupakan penipuan (atau setidaknya tidak dapat dimonetisasi). Jika teknologi iklan juga merupakan pelacak dan dapat tunduk pada proposal Perlindungan IP, perusahaan tersebut dapat kehilangan kemampuan untuk melakukan pemeriksaan dasar terhadap iklan sebelum membeli inventaris iklan. | Kami mendorong lebih banyak masukan dan diskusi tentang Proposal Perlindungan Kekayaan Intelektual tentang potensi masalah dan solusinya. Salah satu opsinya adalah menerapkan daftar yang serupa ke Perlindungan IP, sehingga kami tidak mem-proxy klien yang berasal dari alamat IP yang ditandai sebelumnya. |
Memperkuat batas privasi lintas situs
Set Pihak Pertama
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| (Juga dilaporkan dalam K4) Batas domain | Permintaan untuk menambah jumlah domain terkait | Respons kami tidak berubah sejak Q4 2022: "Kami telah mengklarifikasi dalam panggilan WICG bahwa Chrome berkomitmen untuk memberikan solusi yang dapat digunakan yang juga mempertimbangkan kepentingan privasi pengguna. Untuk itu, kami akan mengapresiasi masukan dari komunitas terkait kasus penggunaan tertentu yang mungkin dipengaruhi oleh batas domain, sehingga tim dapat mempertimbangkan cara untuk menyelesaikan kasus penggunaan ini sambil terus melindungi privasi pengguna." |
| Pengiriman FPS alternatif | Proposal cara alternatif mengirimkan daftar global untuk FPS | Saat ini, kami sedang bersiap untuk mengirimkan Set Pihak Pertama (FPS) di Chrome, dan telah menyiapkan repositori GitHub terpusat untuk menerima pengiriman set. Karena kami berharap FPS akan mengisi kesenjangan dengan solusi platform web yang ada sebagai persiapan untuk penghentian penggunaan cookie pihak ketiga, kami berharap dapat belajar dari mereka bagaimana FPS dimanfaatkan oleh penulis situs. Seiring bertambahnya daftar kumpulan dan ekosistem beradaptasi dengan dunia cookie pihak ketiga, kami juga dapat matang proses hingga kami dapat mempertimbangkan skema terdesentralisasi alternatif seperti yang diusulkan. Dengan proses saat ini, kami berharap dapat menetapkan masa aktif, yang akan memungkinkan kami mengembangkan proses pengambilan seiring waktu. Kita dapat meninjau kembali ide ini setelah proses pengiriman matang. |
| Moderasi repo | Terapkan moderasi komunitas repo FPS Submission untuk mencegah penyalahgunaan. Pihak tidak bertanggung jawab dapat dengan mudah membebani proses yang menggunakan origin burner untuk mengusulkan set, dan volume permintaan yang besar dapat memengaruhi operasi untuk proposal set asli. | Kami mencoba melakukan pemeriksaan seobjektif mungkin dengan mengandalkan pemeriksaan validasi teknis. Kami pikir ini adalah pendekatan yang paling terukur untuk proses pengiriman. Sejalan dengan tujuan ini, kami juga akan berusaha memastikan proses tersebut tahan terhadap pengiriman spam / burner. |
| Subset terkait | Apakah FPS dapat mendukung kasus penggunaan alur Vendor/SaaS pihak ketiga melalui Subset Terkait? | Alur vendor / SaaS pihak ketiga bukanlah kasus penggunaan yang saat ini dipertimbangkan dalam cakupan Set Pihak Pertama. Kami menerima masukan tambahan tentang cara cookie lintas situs digunakan untuk kasus penggunaan ini. |
| Integrasi FPS + CHIPS | Meminta integrasi FPS + CHIPS untuk mendukung kasus penggunaan seperti pengujian A/B | Kami membahas kasus penggunaan ini dan juga mempertimbangkan untuk membahas hal ini lebih lanjut dalam panggilan WICG dan menerima input tambahan di sini. |
| GDPR | Proposal untuk subset FPS baru yang akan dibuat modelnya berdasarkan konsep GDPR | Kami membahas proposal ini secara internal dan membandingkannya dengan masukan lain yang diterima serta tujuan privasi kami. Kami telah memberikan jawaban yang menjelaskan mengapa kami tidak akan memenuhi proposal ini untuk saat ini. |
| Memori | Perubahan yang diharapkan dalam ukuran memori browser saat daftar FPS digabungkan | Browser memiliki prioritas untuk menyimpan jenis daftar ini dengan dampak memori minimal, seperti Daftar Perlindungan Pelacakan Pemutusan Koneksi. Meskipun daftar Set Pihak Pertama akan disalin ke setiap klien Chrome secara lokal, kami akan terus memantau ukuran file dan yakin bahwa kami dapat mengoptimalkan jejak memori. |
API Fenced Frames
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Batasan Frame dengan Fence | Kejelasan seputar batasan yang diberlakukan oleh Frame dengan Fence | Pada bulan Maret, kami memperbarui penjelasan tentang Fenced Frames yang memberikan informasi tentang kemampuannya dan kami menerima masukan tambahan. |
| Luaskan informasi akses | Permintaan untuk memperluas akses ke informasi di sekitar frame di sekitar | Kami ingin lebih memahami mengapa hal ini merupakan persyaratan dari ekosistem, dan kami menerima masukan tambahan. |
| Frame dan iframe dengan Fence | Pertanyaan mengenai kesamaan fitur antara Fenced Frames dan iframe | Semua API dan laporan Privacy Sandbox yang tersedia akan tersedia untuk iframe dan untuk FencedFrames dengan cara yang sama. |
| Mengubah Ukuran Frame dengan Fence | Membatasi perubahan ukuran frame memengaruhi kasus penggunaan tertentu. | Kami tertarik untuk mempelajari lebih lanjut jenis kasus penggunaan yang terpengaruh oleh pembatasan ini dan akan menerima masukan tambahan. |
API Penyimpanan Bersama
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Worklet pihak ketiga | Dapatkah pihak ketiga menulis ke Penyimpanan Bersama, yang dipartisi berdasarkan origin? Atau memanggil worklet lain untuk pengukuran pihak ketiga? | Asal konteks penjelajahan tempat kode dijalankan menentukan penyimpanan bersama milik siapa data ditulis. Saat kode pihak ketiga ditambahkan ke halaman, kode pihak ketiga dapat disematkan sebagai iframe dengan konteks penjelajahannya sendiri, yang memungkinkan kode pihak ketiga menulis ke originnya sendiri. Kode pihak ketiga juga dapat disematkan sebagai skrip, bukan iframe, yang tidak mengalihkan konteks penjelajahan, dan pihak ketiga dapat menulis ke penyimpanan bersama sematan. Perhatikan bahwa hanya pemilik penyimpanan bersama tersebut yang dapat membaca dari penyimpanan bersama tersebut. |
| Penghapusan Duplikat | Penghapusan duplikat tidak mungkin dilakukan untuk interaksi di luar ekosistem Chrome. | Penyimpanan Bersama dimaksudkan untuk menyediakan output jangkauan unik berbasis browser Chrome di dalam Chrome. Kami tertarik untuk bekerja sama dengan teknologi iklan guna memahami bagaimana output ini dapat digunakan sebagai bagian dari model jangkauan mereka yang lebih luas. Kami memahami bahwa output itu sendiri mungkin hanya menghitung sebagian interaksi dan tertarik untuk bekerja sama dengan teknologi iklan guna mempelajari metodologi pemodelan tambahan yang dapat digunakan berlapis-lapis. |
| Periode lihat balik konversi | Meminta rasio konversi ke periode lihat balik agar dapat melihat perubahan konversi dari waktu ke waktu | Hal ini dapat diterapkan dengan memproses berbagai jalur konversi di sisi klien menggunakan Penyimpanan Bersama, yang memberikan fleksibilitas tambahan untuk analisis lanjutan melalui penyimpanan browser tanpa partisi yang aman. |
| Periode masa berlaku item | Minta untuk memperpanjang periode masa berlaku menjadi 90 hari | Kebijakan retensi data diperbarui pada November 2022, dan menyatakan bahwa setiap kunci dihapus setelah tiga puluh hari penulisan terakhir. Kami menerima masukan tambahan untuk memahami apakah kebijakan baru akan berfungsi untuk ekosistem. |
| Rotasi materi iklan | Kasus penggunaan rotasi materi iklan tidak mencerminkan tindakan sebenarnya setelah lelang. | Kami ingin mengetahui dari lebih banyak perusahaan teknologi iklan sisi beli tentang apakah dokumentasi rotasi materi iklan akurat atau tidak. |
CHIP
Tidak ada masukan yang diterima untuk kuartal ini.
FedCM
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Endpoint pernyataan identitas | Mengizinkan permintaan arbitrer secara eksplisit ke endpoint pernyataan identitas. | Kami telah berkolaborasi dengan Mozilla terkait permintaan pull ini untuk membatasi kemampuan situs dalam membuat permintaan kredensial lintas origin secara diam-diam tanpa menyebabkan gangguan bagi pengguna dan akan terus meninjau serta menangani masukan lainnya. |
| Mengisi otomatis identitas | Dapatkah FedCM digunakan untuk mengisi otomatis formulir login dengan penyedia identitas dari daftar FedCM? | Kekhawatiran untuk kasus penggunaan ini adalah bahwa hal ini dapat mengakibatkan kebocoran informasi saat situs yang belum berinteraksi dengan pengguna dapat menjalankan kueri IDP terakhir yang digunakan oleh pengguna. Kami membahas masalah ini lebih lanjut dan menerima masukan tambahan. |
| Pemilihan akun kontekstual | Proposal untuk menambahkan sinyal kontekstual di UI pemilihan akun | Kami sedang mempertimbangkan proposal ini dan menyambut diskusi tambahan. |
Memerangi spam dan penipuan
Private State Token API (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
|---|---|---|
| Survei pengumpulan kemampuan | Pada awal Kuartal 1, kami selesai mengumpulkan hasil survei yang menunjukkan kemampuan yang diperlukan untuk berbagai kasus penggunaan antipenipuan, lalu membagikannya kepada publik (menit, hasil) | Kami berencana menerapkan masukan ini saat kami mengembangkan proposal dan prototipe baru untuk API yang dibuat khusus dan menjaga privasi untuk kemampuan antipenipuan. Kami berharap kami akan memprioritaskan pengembangan jika ada kebutuhan yang memadai dan ada teknologi yang dapat kami bangun untuk memperkenalkan kemampuan ke web, sekaligus menjaga privasi pengguna. Misalnya, integritas perangkat dan booting memiliki peringkat tinggi dan banyak platform memiliki API yang sudah ada yang membagikan penilaian integritas perangkat dengan aman, sehingga ini adalah kandidat yang baik untuk mengeksplorasi dalam grup komunitas. |
| Niat PST untuk Mengirimkan masukan | Sebagai bagian dari niat untuk mengirimkan produk, kami mendapatkan kekhawatiran dalam melanjutkan karena kami menggunakan Privacy Pass versi lama. Kami juga menerima masukan bahwa spesifikasinya tidak jelas di bagian tertentu, dan harus ditingkatkan untuk memfasilitasi kompatibilitas browser. | Kami berencana untuk menerapkan banyak perubahan spesifikasi yang disarankan sebelum
pengiriman ke GA, serta beberapa perubahan API. Masukan tersebut diberikan
pada akhir Q1, jadi kami menindaklanjuti masalah
github dengan detail spesifik dan pembaruan untuk rencana peluncuran kami (sedang
berlangsung sejak publikasi laporan masukan ini). Untuk perubahan yang lebih besar pada API, kami terbuka untuk mempertimbangkannya, tetapi kami merasa cara terbaik ke depannya adalah melanjutkan peluncuran ke ketersediaan umum dan mendapatkan masukan langsung dari lebih banyak developer. Kami berharap dapat melanjutkan diskusi ini dan melakukan standardisasi browser. Jika dan ketika standar baru muncul, kami akan mempertimbangkan untuk mengadopsi dan mengembangkan rencana untuk beralih ke standar tersebut dengan hati-hati. |