Laporan triwulanan untuk Kuartal 3 2022 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 |
| (Juga dilaporkan pada Kuartal 2)
Kegunaan untuk berbagai jenis pemangku kepentingan |
Kekhawatiran bahwa teknologi Privacy Sandbox mengutamakan developer yang lebih besar dan bahwa situs khusus (lebih kecil) berkontribusi lebih besar daripada situs generik (lebih besar). | Update Kuartal 3:
Google telah berkomitmen kepada CMA untuk merancang dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, serta mempertimbangkan dampak terhadap persaingan dalam iklan digital serta terhadap penayang dan pengiklan, terlepas dari ukuran mereka. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini. Seiring berjalannya pengujian Privacy Sandbox, salah satu pertanyaan utama yang akan kami nilai adalah performa teknologi baru untuk berbagai jenis pemangku kepentingan. Masukan sangat penting dalam hal ini, terutama masukan 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 lebih banyak informasi kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan. |
| (Juga dilaporkan pada Kuartal 2)
Permintaan dokumentasi |
Permintaan lebih banyak resource yang menjelaskan cara mengelola pengujian, analisis, dan implementasi | Update Kuartal 3:
Kami menghargai bahwa developer merasa materi kami saat ini bermanfaat, dan berkomitmen untuk menyediakan lebih banyak materi dalam beberapa minggu dan bulan ke depan sehingga developer dapat terus memahami bagaimana teknologi baru dapat berguna bagi mereka. Kami juga mengadakan sesi waktu konsultasi publik untuk developer untuk berbagi praktik terbaik dan demo, beserta sesi Tanya Jawab dengan pemimpin produk dan engineer untuk diskusi/pertanyaan langsung. |
| Dukungan lintas browser | Vendor browser lain yang mengadopsi Privacy Sandbox API. | Vendor browser lainnya, seperti Apple, Mozilla, dan Microsoft, merupakan peserta aktif dalam forum publik yang membahas prinsip privasi dan pendekatan berbasis browser. Kami terdorong oleh diskusi kolaboratif di forum seperti pertemuan TPAC Tahunan W3C baru-baru ini dan forum PATCG W3C yang sedang berlangsung di mana kami melihat tanda-tanda konvergensi. |
| Perbedaan platform | Minta untuk menyelaraskan set fitur di web dan Android sebanyak mungkin guna membantu mengurangi resource yang diperlukan untuk transisi. | Kami berupaya keras untuk menyelaraskan pendekatan kami di Chrome dan Android untuk menghindari kebingungan/fragmentasi di seluruh industri. Perbedaan pendekatan kami sebagian besar disebabkan oleh perbedaan teknis yang diperlukan antara platform web dan aplikasi seluler yang telah dipertimbangkan oleh developer. |
| Referensi untuk menguji Privacy Sandbox API | Kesulitan dalam mengalokasikan
untuk menguji Privacy Sandbox API mengingat hambatan ekonomi saat ini. |
Google terus meningkatkan dokumentasi dan dukungan yang tersedia bagi penguji untuk memudahkan kerumitan dan membantu penggunaan API. Upaya ini mencakup: milis khusus API, waktu konsultasi, dan update berkelanjutan di developers.chrome.com. |
| Sinyal Tidak Ikut API Sandbox | Permintaan untuk memberikan sinyal 'pengguna telah memilih tidak ikut API sandbox', yang dapat digunakan teknologi iklan dan situs. | Kami telah melihat banyak kasus historis ketika situs web bereaksi terhadap pilihan pengguna seperti "nonaktifkan cookie pihak ketiga" dengan menekan pengguna untuk mengubah setelan mereka, terkadang termasuk memblokir akses situs, kecuali jika mereka melakukannya. Sinyal pilihan tidak ikut juga dapat digunakan sebagai sinyal tambahan untuk pelacakan sidik jari. Saat ini, Google tidak bermaksud memberikan sinyal ketidakikutsertaan |
| (Juga dilaporkan pada Kuartal 2)
Rentang waktu yang lebih jelas |
Jadwal rilis yang lebih jelas dan mendetail | Update Kuartal 3:
Seperti yang dijelaskan dalam Perubahan sebagai respons terhadap bagian masukan di bawah, Google memperbarui linimasa Privacy Sandbox pada bulan Juli guna memberikan waktu tambahan kepada pasar untuk pengujian dan masukan awal, serta lebih banyak waktu untuk menguji setelah Privacy Sandbox API sepenuhnya diluncurkan sebelum cookie pihak ketiga tidak digunakan lagi. |
| (Juga dilaporkan pada Kuartal 2)
Jadwal penghentian penggunaan cookie pihak ketiga |
Permintaan untuk menghindari penundaan lebih lanjut untuk penghentian penggunaan cookie pihak ketiga | Update Kuartal 3:
Pada bulan Juli, Chrome mengumumkan pembaruan waktu penghentian cookie pihak ketiga, yang mencerminkan komitmen kami untuk bertindak secara bertanggung jawab mengingat kompleksitas teknologi dan pentingnya teknologi tersebut bagi ekosistem. Masukan dari badan pengatur dan industri telah diperhitungkan sebelum perubahan ini, dan kami terus bekerja sama dengan semua pemangku kepentingan. |
| Cookie pihak pertama | Apakah pembatasan pada cookie pihak pertama juga diusulkan? Jika demikian, kekhawatiran tentang stabilitas jangka panjang, risiko dari perubahan browser yang lebih tidak dapat diprediksi, dan karenanya menyia-nyiakan upaya teknis sekarang. | Kami belum mempertimbangkan pembatasan cookie pihak pertama. Fokus Privacy Sandbox adalah penghentian penggunaan cookie pihak ketiga. |
Tampilkan Konten & Iklan yang Relevan
Topik
| Tema Masukan | Ringkasan | Respons Chrome |
| (Juga dilaporkan pada Kuartal 2)
Kegunaan untuk berbagai jenis pemangku kepentingan |
Terdapat kekhawatiran tentang manfaat situs bergantung pada tingkat traffic atau seberapa khusus konten situs tersebut. | Update Kuartal 3:
Kegunaan API akan dieksplorasi melalui pengujian. Sebagaimana diwajibkan dalam paragraf 17.c.ii dalam Komitmen, Google akan membagikan hasil pengujian tersebut kepada CMA. Chrome mengharapkan taksonomi dan parameter lainnya berkembang berdasarkan hasil pengujian. Evolusi taksonomi atau parameter mungkin tidak memerlukan perubahan inkompatibilitas mundur. Selain itu, Chrome mengharapkan masukan untuk terus memengaruhi evolusi Topics API setelah cookie pihak ketiga tidak digunakan lagi. |
| Privasi/Kebijakan | Permintaan untuk menghapus persyaratan pemfilteran topik per pemanggil. | Berdasarkan masukan dari KOF privasi, pendukung privasi, pakar keamanan, grup hak digital, dan lainnya dalam ekosistem tersebut, Chrome memilih desain ini untuk memberikan akses ke informasi hanya kepada mereka yang memiliki akses tersebut. Alasannya termasuk, tetapi tidak terbatas pada, membatasi kebocoran data lintas-sisi bertahap; memastikan transparansi dan kemudahan penjelasan; mengadopsi pendekatan yang mudah diterapkan dan dijelaskan; serta membatasi risiko pelacakan sidik jari. Penerbit dan pihak ketiga yang menerima Topics dapat memutuskan sendiri informasi apa yang akan dibagikan kepada pihak di situs mereka. Jika pihak ketiga membagikan informasi ini, Chrome sangat menganjurkan mereka untuk bersikap transparan kepada pengguna terkait aktivitas berbagi tersebut, dan menawarkan kontrol kepada mereka. |
| Situs yang salah dikategorikan | Situs salah dikategorikan ke topik yang salah, sehingga dapat menyebabkan penargetan iklan tidak akurat. | 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:
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. |
| Persyaratan akses | Persyaratan Topik saat ini untuk entitas DOM di halaman sebagai skrip atau iframe agar dapat diakses dapat menyebabkan perilaku yang tidak diinginkan oleh pemain di ekosistem iklan. | Kami telah menggabungkan perubahan di penjelasan GitHub. Kami bermaksud untuk mendukung Topics di header HTTP. |
| Taksonomi topik tidak cukup terperinci | Klasifikasi topik saat ini terlalu luas, dan tidak mencakup topik yang lebih terperinci, seperti topik regional. | Peningkatan pada taksonomi adalah upaya berkelanjutan, dan kami berharap taksonomi akan berkembang dengan pengujian dan input ekosistem.
Kami secara aktif meminta 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 (mis. lebih banyak topik dapat menimbulkan risiko pelacakan sidik jari) dan 2) kemampuan untuk mengambil topik yang diamati sebelumnya (misalnya dengan lebih banyak topik, mungkin ada lebih sedikit peluang bahwa teknologi iklan telah melihat topik yang dipilih di masa lalu). Memperluas dari #2, Google berupaya memaksimalkan kemampuan penelepon untuk mengambil topik yang diamati sebelumnya, sesuai persyaratan pemfilteran yang ada, dengan tujuan mencapai utilitas dan privasi. |
| Batas topik | Tiga topik per situs terlalu sedikit berisi informasi bagi pengiklan untuk menayangkan iklan. | Masukan dari ekosistem, khususnya hasil pengujian dari Uji Coba Origin kami, akan terus memengaruhi evolusi API. Perlu diperhatikan bahwa Topics diharapkan dapat melengkapi sinyal lain seperti kontekstual untuk membantu menemukan iklan yang sesuai bagi pengunjung. Jadi, mungkin ada lebih banyak informasi yang tersedia bagi pengiklan di luar topik. |
| (Juga dilaporkan pada Kuartal 2)
Kontrol dan keamanan pengguna |
Topik tertentu mungkin merupakan proxy untuk grup sensitif dan pengguna memerlukan kontrol lebih besar untuk mencegah hasil negatif. | Update Kuartal 3:
Topik mewakili langkah maju yang signifikan untuk kontrol dan transparansi pengguna. Pengguna dapat memilih untuk tidak mengikuti topik, meninjau topik yang telah ditetapkan untuk mereka, menghapus topik, dan memahami perusahaan mana yang berinteraksi dengan topik mereka di halaman tertentu. Selain itu, pengguna juga dapat menghapus Topik dengan menghapus histori penjelajahan mereka, yang merupakan asal topik. Kontrol ini saat ini diterapkan di browser Chrome pada tingkat perangkat. Kami menyambut baik diskusi berkelanjutan terkait kontrol pengguna yang lebih canggih, seperti yang disarankan oleh developer. Namun, kami perlu memastikan bahwa penambahan baru dikalibrasi dengan baik untuk mengatasi masalah yang muncul dan tidak mengakibatkan perubahan yang tidak disengaja. |
| Dampak pada SEO | Penayang yang menyesuaikan nama host situs mereka agar lebih mencerminkan Topics dapat berdampak negatif pada SEO. | Kami akan memperingatkan situs agar tidak mengubah nama host mereka hanya untuk keperluan Topics. Memang benar bahwa situs mungkin dapat memengaruhi topik yang ditetapkan dengan cara ini. Namun, manfaat melakukan hal tersebut bagi penayang tidaklah jelas, dan akan mengurangi nilai Topics untuk keseluruhan ekosistem jika situs mencoba "mengakali" model klasifikasi. Penetapan topik juga tidak bersifat tetap; kami berharap taksonomi akan terus berkembang dengan pengujian dan input. Sehubungan dengan pengujian ini, kami menyarankan masukan, termasuk contoh situs yang mungkin salah dikategorikan. |
| Penipuan & Penyalahgunaan | Sediakan cara bagi pihak sisi beli untuk memverifikasi bahwa topik yang mereka lihat benar-benar dihasilkan oleh browser. | Kami menghargai saran untuk mendukung mekanisme bagi pembeli teknologi iklan untuk memverifikasi topik yang diteruskan oleh penjual dalam lelang iklan terprogram. Kami mendorong ekosistem untuk berkontribusi pada diskusi aktif di sini. Meskipun saat ini kami berfokus pada peningkatan lain yang berprioritas lebih tinggi, kami menyadari bahwa hal ini bisa menjadi tambahan penting pada desain di masa mendatang. |
| Penipuan & Penyalahgunaan | Memungkinkan peninjauan publik terhadap pihak yang merupakan pengguna sah data Topics, melalui jenis postingan dan peninjauan publik yang sama seperti yang harus dilakukan kepada kumpulan pihak pertama. | Kami menghargai saran tersebut dan setuju bahwa akuntabilitas publik adalah alat yang penting untuk membantu mencapai sasaran Privacy Sandbox. Panggilan Topics API pada dasarnya bersifat publik, karena siapa pun dapat mengunjungi situs dan mengamati panggilan domain ke JavaScript API. Oleh karena itu, individu dan organisasi dapat melihat aktivitas yang relevan dan menilai situs mana yang menggunakan Topics dan cara menggunakannya. Kami yakin bahwa ini adalah pendekatan yang lebih baik daripada membuat penilaian terhadap bagian "legitimasi" situs terhadap fungsi Topics API itu sendiri. |
| Dampak pada sinyal pihak pertama | Sinyal topik mungkin sangat berharga dan akibatnya menurunkan nilai sinyal berbasis minat pihak pertama lainnya. | Kami meyakini bahwa periklanan menurut minat adalah kasus penggunaan yang penting bagi web, dan Topics dirancang untuk mendukung kasus penggunaan tersebut. Seperti dijelaskan di atas, pemangku kepentingan ekosistem lainnya telah menyatakan kekhawatiran bahwa Topics mungkin tidak cukup berguna untuk memberikan nilai. Dalam semua kasus, peningkatan pada taksonomi adalah upaya berkelanjutan, dan kami berharap taksonomi akan berkembang dengan pengujian dan masukan ekosistem. |
FLEDGE
| Tema Masukan | Ringkasan | Respons Chrome |
| Lelang FLEDGE | Cara SSP memformat data yang dikirim ke Google Ads untuk mengajukan bid di lelang FLEDGE. | Perusahaan yang berpartisipasi dalam pengujian dianjurkan untuk memublikasikan dokumentasi tentang rencana pengujian mereka dan bekerja sama jika sesuai.
Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA untuk memublikasikan catatan tentang desain eksperimen guna memberikan lebih banyak informasi bagi peserta pasar yang berencana untuk melakukan uji coba dan kesempatan untuk mengomentari pendekatan yang diusulkan. Tim Ad Manager telah memposting dokumentasi untuk penjual yang berminat menguji FLEDGE dengan penayang yang menggunakan Ad Manager sebagai server iklan mereka di sini. Terdapat detail teknis tambahan yang diuraikan di sini. |
| FLEDGE dalam Frame dengan Fence bertingkat | Frame dengan Fence memungkinkan pengujian yang tidak terlalu ketat, sekaligus membatasi lebih banyak pada masa mendatang yang tidak ditentukan. Rentang waktu yang tidak diketahui ini menghadirkan tantangan bagi ekosistem. | Perusahaan dapat menguji FLEDGE dengan Frame dengan Fence sekarang juga. Untuk memberikan opsi aktivasi yang lebih mudah, perusahaan dapat memilih untuk menerapkan FLEDGE terlebih dahulu. Setelah menerapkan FLEDGE, mereka dapat menguji Frame dengan Fence dengan desain FLEDGE. |
| Kebijakan penanganan data | Apa kebijakan penanganan data untuk grup minat / FLEDGE? | Dalam desain FLEDGE, semua data yang disimpan dalam grup minat, atau tentang orang-orang yang termasuk dalam grup minat, tetap ada di perangkat. Data ini tidak dikirim ke server Google.
Beberapa perlindungan privasi yang direncanakan Chrome untuk FLEDGE melibatkan interaksi dengan server k-anonymity yang dijalankan Google. Interaksi tersebut dirancang dengan cermat untuk menghindari pembagian informasi tentang pengguna, dan dijalankan di trusted execution environment (TEE) untuk memastikan kesamaan informasi di seluruh ekosistem iklan. \ Google telah berkomitmen kepada CMA untuk merancang dan menerapkan proposal Privacy Sandbox melalui cara yang tidak mendistorsi persaingan dengan memprioritaskan bisnis Google sendiri, serta mempertimbangkan dampak terhadap persaingan dalam iklan digital serta penayang dan pengiklan. Kami terus bekerja sama dengan CMA untuk memastikan pekerjaan kami mematuhi komitmen ini. |
| Kebijakan usia | Bagaimana cara Chrome memastikan bahwa audiens yang dibuat oleh FLEDGE mematuhi pembatasan usia? | Penayang dan pengiklan memiliki posisi terbaik untuk menilai apakah audiens yang mereka buat menggunakan FLEDGE mematuhi hukum yang berlaku. Untuk lebih melindungi pengguna, API Privacy Sandbox tidak akan aktif bagi pengguna yang login ke Chrome jika usia yang terkait dengan akunnya di bawah 18 tahun, meskipun selama periode pengujian. (Untuk pengguna yang logout, Chrome tidak mengumpulkan sinyal profil yang akan memungkinkan browser menyimpulkan usia pengguna.) |
| Layanan Kunci/Nilai FLEDGE | Kejelasan lebih lanjut tentang apa saja yang akan diizinkan oleh layanan Kunci/Nilai FLEDGE, seperti jumlah kunci dan seberapa sering kunci dapat diupdate. | Perusahaan yang menggunakan FLEDGE dapat memiliki kunci sebanyak yang dapat ditampung dalam RAM. Untuk detail selengkapnya, lihat penjelasan di sini.
Kami ingin menyediakan jalur yang lebih cepat untuk mengubah data dan menerima saran untuk persyaratan apa pun. |
| Pengujian | FLEDGE sulit diuji dengan Google Ads | Lihat dokumentasi aktivasi Google Ads tentang cara terbaik untuk berpartisipasi dan melakukan pengujian dalam uji coba origin. |
| API Layanan Bidding dan Lelang | Apa arah Google terkait Bidding and Auction Services API? Apakah akan diprioritaskan di atas atau di bawah FLEDGE browser Chrome pada lelang perangkat? | Kami tetap berkomitmen pada desain bidding di perangkat FLEDGE saat ini. Layanan Bidding dan Lelang telah diusulkan untuk mengeksplorasi kemungkinan solusi untuk mendukung sebagian kasus penggunaan di mana daya komputasi atau kecepatan jaringan perangkat mungkin terbatas. |
| Pelaporan gabungan | Permintaan untuk mendukung laporan gabungan berdasarkan semua sinyal yang tersedia untuk generateBid. | Kami berencana untuk segera menyampaikan informasi selengkapnya tentang hal ini secara publik. |
| Iklan Kontekstual | Menayangkan iklan kontekstual dengan FLEDGE. | Kami telah mempertimbangkan opsi ini dan untuk alasan yang dijelaskan dalam diskusi ini, untuk saat ini kami tidak akan merekomendasikan penggunaan FLEDGE untuk iklan kontekstual. |
| Pengujian di dunia nyata | Panduan tentang cara mengisolasi FLEDGE dari cookie pihak ketiga untuk pengujian di dunia nyata. | Kami sedang menyelidiki cara untuk menyediakan populasi uji.
Kami telah bekerja sama dengan CMA untuk mengembangkan pendekatan kami terhadap pengujian kuantitatif, dan mendukung CMA untuk memublikasikan catatan tentang desain eksperimen guna memberikan lebih banyak informasi kepada peserta pasar dan kesempatan untuk mengomentari pendekatan yang diusulkan. |
| Menguji FLEDGE dan Attribution Reporting API | Apa cara terbaik untuk menerapkan Attribution Reporting API dengan FLEDGE? Apakah Anda sebaiknya memisahkan FLEDGE & Atribusi atau melakukan pengujian bersama-sama? | Kami akhirnya akan mendukung pengujian FLEDGE dan Attribution Reporting API sebagai solusi terintegrasi, tetapi sebaiknya developer menguji Attribution Reporting API terlebih dahulu secara independen, lalu dengan FLEDGE saat integrasi selesai. |
| Visibilitas harga bid | Permintaan untuk meng-obfuscate harga bid. | Anda dapat menyetel titik henti sementara dalam `generateBid()` atau `scoreAd()` untuk mengakses nilai bid dari DevTools. Tim Chrome telah mempertimbangkan vektor serangan sempit yang dimunculkan dalam masukan tentang FLEDGE ini. Namun, model keamanan dan privasi Chrome menganggap pengguna dipercaya untuk melakukan apa pun yang mereka inginkan dengan informasi di perangkat mereka, dan akibatnya tidak ada cara yang valid untuk menyembunyikan data bid seperti yang diminta. |
| Permintaan dokumentasi | Dokumentasi dan contoh untuk pengujian di ekosistem langsung. | Kami menghargai bahwa developer merasa materi kami saat ini bermanfaat, dan berkomitmen untuk menyediakan lebih banyak materi dalam beberapa minggu dan bulan ke depan sehingga developer dapat terus memahami bagaimana teknologi baru dapat berguna bagi mereka.
Kami juga mengadakan waktu konsultasi developer eksternal untuk berbagi praktik terbaik dan demo beserta sesi Tanya Jawab dengan pemimpin produk dan engineer, sehingga diskusi/pertanyaan dapat diajukan secara live. |
| API Agregasi Pribadi | Minta informasi selengkapnya tentang Private Aggregation API? | Penjelasan publik tersedia dengan informasi terbaru yang dapat kami bagikan saat ini. Dokumentasi selengkapnya akan disediakan saat API ini dikembangkan dan kasus penggunaan ditentukan. |
| Latensi data | Apakah pengambilan data server Kunci/Nilai FLEDGE akan dilakukan secara real time? | Sejumlah kecil data yang tidak berlaku dalam hitungan menit, bukan jam, dapat diperkirakan sebelum data yang diperbarui dapat ditampilkan oleh server untuk kueri, seperti yang dijelaskan dalam Masalah GitHub terbuka. Kami juga memerlukan masukan dari developer. |
| Layanan Bidding dan Lelang | Apakah harga bid akan disembunyikan dari pengguna jika layanan bidding dan lelang (B&A) digunakan? | Untuk pendekatan sisi server B&A, harga bid individual tidak terlihat oleh pengguna, karena permintaan bid dibuat dari layanan lelang SSP langsung ke layanan lelang DSP, sehingga tidak tersedia lagi di browser.
Namun, harga bid yang menang akan tetap terlihat oleh browser (dibahas secara lebih mendetail di atas, mengenai permintaan untuk meng-obfuscate harga bid). |
| Layanan Bidding dan Lelang | Bagaimana cara melakukan load balancing untuk layanan bidding dan lelang? | Saat ini kami tidak memiliki panduan terkait load balancing, tetapi perspektif ini merupakan permasalahan penting dari sudut pandang performa dan privasi. Kami akan memberikan detail selengkapnya di masa mendatang. |
| Batas FLEDGE | Meminta untuk meningkatkan batas durasi joinAdInterestGroup dari 30 hari menjadi 90 hari. | Kami merasa bahwa jangka waktu retensi data 30 hari ini sejalan dengan API iklan Privacy Sandbox lainnya, seperti batas 30 hari di Attribution Reporting dan tinjauan 3 minggu di Topics. Jangka waktu ini membahas kebutuhan teknologi iklan dan ekspektasi privasi pengguna.
Namun, kami tetap menantikan masukan lebih lanjut selagi kami terus membahas masalah ini di sini. |
| Penyimpanan Bersama di FLEDGE | Apakah mungkin menggunakan Shared Storage API di FLEDGE? | Kami bermaksud untuk mendukung Shared Storage API di FLEDGE pada masa mendatang dan sedang berupaya untuk menyediakannya dalam Uji Coba Origin mendatang. |
| Kontrol frekuensi menurut klik | Apakah mungkin untuk memiliki pembatasan frekuensi berdasarkan klik (bukan kemenangan) di FLEDGE? | FLEDGE memang menentukan bahwa Fenced Frame dapat memanggil navigator.leaveAdInterestGroup() (tanpa parameter) untuk keluar dari grup minat yang menyebabkan iklan ditampilkan; panggilan ini dapat dilakukan saat pertama kali klik diterima untuk mencegah bidding di masa mendatang, sebagai bentuk pembatasan frekuensi. Saat ini, solusi ini tidak akan berfungsi untuk pembatasan setelah lebih dari satu klik. |
| FLEDGE dalam Frame dengan Fence bertingkat. | Tidak dapat melaporkan klik melalui Pelaporan Iklan Frame dengan Fence, jika terjadi di Frame dengan Fence bertingkat. | Kami telah memublikasikan proposal untuk memperbaiki masalah di sini. |
| Pengukuran | Memerlukan panduan tentang cara mengumpulkan data latensi tentang bidder di lelang FLEDGE. | Kami sedang berupaya untuk segera memublikasikan dokumen pengukuran performa. |
| Pelaporan | Bagaimana pelaporan FLEDGE akan ditangani? | Pelaporan FLEDGE tentang Kemenangan, Hasil Lelang, Peristiwa, misalnya, klik akan tersedia melalui FLEDGE API seperti reportResult(). Dalam pelaporan dengan konversi iklan, integrasi dengan Attribution Reporting API tidak akan bergantung pada FLEDGE, tetapi ada diskusi berkelanjutan dengan ekosistem tentang kemungkinan pendekatan.
Private Aggregation API juga dapat digunakan untuk melaporkan hasil lelang dari dalam lingkungan eksekusi yang terisolasi. Lihat penjelasan di sini. |
| Ukuran grup minat | Apakah ada cara bagi teknologi iklan untuk memeriksa ukuran grup minat (yaitu jumlah pengguna dalam grup)? | Keanggotaan grup minat disimpan oleh browser, di perangkat pengguna, dan tidak dibagikan ke vendor browser atau orang lain.
Namun, pemilik grup minat dapat secara teoritis melacak setiap panggilan ke navigator.joininterestgroup(...). Melacak panggilan ini tidak menjamin ukuran IG yang tepat (karena pengguna dapat keluar dari grup kapan saja), tetapi hal ini memberi pemilik batas atas dan perkiraan berapa ukurannya. |
| Performa | Apakah kode JS/WebAssembly Bidding dikompilasi di setiap lelang? | Kode JS/WebAssembly bidding dikompilasi sekali selama setiap lelang. |
| Performa | Apa yang dimaksud dengan cakupan biddingDurationMsec? | biddingDurationMsec mencakup kompilasi waktu skrip. Daftar ini tidak menyertakan waktu download, waktu kompilasi wasm, waktu jaringan; waktu pengambilan dari server nilai kunci atau apa pun sebelum kompilasi JS. |
| Penyesuaian | Apakah mungkin untuk mengupdate adComponent agar dapat disesuaikan untuk pengguna? | adComponent dapat diperbarui saat Grup Minat diperbarui oleh pemanggil saat memanggil joinInterestGroup atau saat Chrome melakukan panggilan ke dailyUpdateURL. Hal ini memungkinkan pemanggil untuk memperbarui adComponent berdasarkan pengetahuan pengguna dari situs saat ini atau berdasarkan informasi k-anonim.Anda dapat menemukan proposal asli turtledove tingkat produk di sini yang menyertakan beberapa analisis oleh RTB House tentang dampak metrik inti untuk kasus penggunaan rekomendasi. |
| Grup minat | Apakah mungkin bagi pemilik grup minat untuk menghapus pengguna tertentu secara bersyarat? | Keanggotaan grup minat hanya disimpan di browser pengguna dan hanya dapat dihapus di sisi pengguna (mis. dengan menghapus data situs).
Namun, pemilik grup minat dapat memanggil navigator.leaveAdInterestGroup() (dengan beberapa logika bersyarat di sekitarnya), jika pengguna kembali ke halaman yang berada di bawah kontrol pemilik grup minat. |
| Performa | Bagaimana cara mengukur performa generateBid? | Waktu kompilasi dan eksekusi dapat diukur dengan biddingDurationMsec. Waktu download dapat diukur dengan chrome://net-export. Di Chrome versi terbaru, waktu kompilasi dan eksekusi akan muncul di tab DevTools Performance. |
| Frekuensi pembaruan grup minat | Berapa frekuensi pembaruan grup minat dari browser? | Untuk grup minat yang belum diperbarui dalam 24 jam terakhir, Chrome akan mencoba memperbaruinya saat navigator.updateAdInterestGroups() dipanggil atau saat grup tersebut memiliki kesempatan untuk berpartisipasi dalam lelang. Untuk detail selengkapnya, lihat penjelasan di sini. |
| Penyedia Layanan Agregasi | Kapan penyedia cloud lain akan didukung di Layanan Agregasi? | Saat ini, kami tidak memiliki info terbaru untuk waktu tertentu, tetapi akan membagikan info lainnya segera setelah kami melakukannya. Saat ini, hanya AWS yang memenuhi persyaratan keamanan layanan agregasi. |
| Linimasa Pengujian FLEDGE | Berapa lama FLEDGE akan melakukan pengujian di BYOS? Apakah akan ada cukup waktu untuk beralih dari model BYOS ke model berbasis TEE? | Guna memastikan ekosistem memiliki waktu yang cukup untuk melakukan pengujian, kami tidak mewajibkan penggunaan TEE hingga beberapa saat setelah cookie pihak ketiga tidak digunakan lagi. Kami akan memberikan pemberitahuan penting kepada developer untuk memulai pengujian dan adopsi sebelum transisi ini berlangsung. Saat ini, tidak ada informasi lebih lanjut, tetapi kami akan membagikan info lebih lanjut segera setelah update tersedia. Temukan informasi terbarunya di sini. |
| Batas ukuran data | Berapa batas ukuran data untuk wasm dalam fungsi bidding. | Ada persyaratan bahwa pembaruan grup minat tidak boleh menghasilkan grup minat yang melebihi 50 kb, seperti yang telah dibahas di sini, tetapi batas ukuran data untuk wasm belum ditentukan sehingga kami akan menghargai masukan tentang topik ini. |
| Sinyal lelang | Apakah akan ada struktur data standar untuk AuctionSignals? | Saat ini belum ditentukan, tetapi kami terbuka untuk menerima masukan. |
| Membuat Kueri Server Teknologi Iklan | Apakah saya dapat mengkueri data server teknologi iklan secara real time dari server K/V? | Tidak, server K/V berjalan dalam model kepercayaan yang menerapkan "No network, disk access, timer, atau logging" untuk menghindari kebocoran data pengguna. Lihat penjelasan model kepercayaan di sini untuk detail selengkapnya. |
| Frekuensi pembaruan adComponents | Memperbarui kolom adComponents (saat ini hanya dalam setelan IG) berdasarkan histori penjelajahan pengguna saat ini tidak dapat dilakukan | Privacy Sandbox bertujuan untuk mendukung kebutuhan ekosistem web tanpa pelacakan lintas situs, yang berarti mencegah akses ke histori penjelajahan. Sebaiknya gunakan alternatif seperti Topics. |
| Hasil lelang | Apakah ada cara bagi teknologi iklan untuk mengetahui rasio pemenang lelang? | Hasil lelang dilaporkan dengan memanggil fungsi reportResult() dan reportWin() di kode lelang yang diberikan oleh penjual dan pembeli yang menang, sehingga masing-masing memiliki peluang untuk melakukan pencatatan log dan pelaporan tentang hasil lelang. |
| (Juga dilaporkan pada Kuartal 2)
Dukungan untuk penargetan Grup Minat negatif |
API untuk mendukung penargetan grup minat negatif: menampilkan iklan hanya jika pengguna tidak termasuk dalam grup minat. | Update Q3:
Kami telah menyampaikan proposal baru dan meminta masukan. |
Mengukur Iklan Digital
Attribution Reporting (dan API lainnya)
| Tema Masukan | Ringkasan | Respons Chrome |
| Persyaratan OT | Hapus batasan Kebijakan-Izin selama / untuk OT saja. | Lihat perubahan yang diumumkan pada Kebijakan Izin selama pengujian. Kekhawatiran pemangku kepentingan dasar yang ditangani oleh perubahan ini, memungkinkan DSP menguji API pada jumlah iframe lintas origin yang lebih tinggi. Awalnya, DSP perlu berkoordinasi dengan Penayang/SSP untuk memastikan kebijakan izin yang tepat telah ditetapkan agar dapat menguji API di iframe lintas origin, tetapi dengan perubahan ini, DSP akan dapat memanggil API secara default dan SSP/Publishers dapat menonaktifkan API jika diperlukan selama Uji Coba Origin. |
| Kebisingan | Masukan bahwa tingkat derau terlalu tinggi dan berdampak pada kegunaan pelaporan. | Kami menerima masukan terkait derau, yang akan kami gunakan untuk menentukan cara menetapkan parameter terkait derau tertentu. Kami juga ingin memublikasikan lebih banyak referensi, alat, dan dokumen lain untuk membantu penguji dalam hal ini. |
| Konversi lintas-domain | Bagaimana cara melacak konversi yang merupakan lintas domain, seperti dengan 2 tujuan atau lebih? | Kami saat ini sedang mendiskusikan dan mencari masukan terkait pertanyaan ini. |
| Persyaratan proses debug | Ingin mengizinkan developer memeriksa anggaran privasi yang tersisa saat men-deploy / menguji untuk laporan ringkasan? | Anda dapat memantau permintaan fitur di sini. |
| Kebijakan penggunaan API | Masukan yang menyarankan kebijakan terkait siapa yang dapat menggunakan API tertentu berdasarkan batasan untuk hal-hal seperti pelacakan sidik jari | Ini adalah ide yang sangat menarik dan kami akan dengan senang hati terlibat lebih lanjut dengan penyedia browser lain dan ekosistem web yang lebih luas. |
| Setelan masa berakhir dalam laporan konversi | Permintaan untuk mendukung filter / masa berlaku laporan habis selama kurang dari 24 jam. | Masa berlaku tingkat jam merupakan sumber masalah privasi karena memungkinkan teknologi iklan mengetahui secara pasti jam berapa pengguna mengunjungi situs pengiklan. Masa berlaku tingkat hari akan memungkinkan teknologi iklan memfilter tayangan iklan tidak valid tanpa menentukan jam berapa pengguna mengunjungi situs. |
| Akhir masa berlaku token OT | Minta untuk memperpanjang validitas token OT yang ada untuk mengurangi overhead operasional. | Kami menyadari bahwa token harus diperpanjang dan berupaya untuk mempermudah developer serta memberikan pemberitahuan tambahan. |
| Dukungan regional | Layanan agregasi saat ini tidak mendukung semua region. | Ini adalah batasan untuk versi beta saat ini. Kami berharap dapat mendukung wilayah lainnya seiring berjalannya pengujian, tetapi belum ada tanggal pasti untuk hal ini. |
| Penundaan pelaporan tingkat peristiwa | Penundaan 2–30 hari dalam pelaporan tingkat peristiwa mungkin terlalu lama untuk kasus penggunaan tertentu. | Kami telah membagikan proposal di sini untuk memungkinkan teknologi iklan mengontrol kapan laporan tingkat peristiwa dikirim dengan masa berlaku habis. Durasi defaultnya adalah 30 hari, tetapi dapat disetel lebih singkat. |
| (Juga dilaporkan pada Kuartal 2)
Atribusi multi-sentuh |
Izinkan atribusi multi-sentuh, seperti lintas perangkat atau lintas aplikasi. | Update Kuartal 3:
Metode atribusi multi-sentuh saat ini memerlukan penggabungan tayangan pengguna (dan juga identitas) secara deterministik di berbagai situs. Akibatnya, fungsi yang ada saat ini tidak selaras dengan sasaran Privacy Sandbox, yang bertujuan untuk mendukung kasus penggunaan iklan utama tanpa pelacakan lintas situs. |
| Linimasa integrasi FLEDGE & Attribution Reporting | Bagaimana linimasa untuk integrasi FLEDGE dan Attribution Reporting API? | Saat ini, kami tidak memiliki informasi terbaru untuk dibagikan, tetapi akan memberikan lebih banyak informasi secara publik setelah kami dapat berkomitmen pada rentang waktu tertentu. |
| Beberapa Jenis Pemicu | Meminta fleksibilitas yang lebih besar dalam pendaftaran pemicu. | Kami telah mengusulkan sistem penghapusan duplikat untuk API gabungan yang akan memberi teknologi iklan lebih banyak fleksibilitas terkait cara mereka mengontrol laporan agregat dan tingkat peristiwa. |
| Pengukuran | Meminta untuk menerima data pengukuran tentang apakah inventaris berperforma baik. | Kami menghargai masukan Anda dan meminta kejelasan tambahan terkait kasus penggunaan untuk permintaan ini. |
| Masa berlaku konversi | Permintaan untuk mendukung masa berlaku konversi pada tag pemicu, bukan hanya tag sumber. | Kami menghargai masukan Anda dan meminta kejelasan tambahan terkait kasus penggunaan untuk permintaan ini. |
| Pelaporan batch | Meminta pengukuran tambahan dalam pelaporan batch. | Kami menghargai masukan tersebut seiring kami terus memikirkan dampaknya terhadap layanan agregasi. Kami ingin mendengar pendapat teknologi iklan tentang pengelompokan laporan dan perkiraan frekuensinya serta masukan apa pun tentang perubahan strategi pengelompokan sepanjang tahun ini. |
| Epsilon | Kapan nilai epsilon akan ditentukan? | Kami secara aktif bekerja sama dengan penguji ekosistem untuk menyelesaikan nilai epsilon dan cara penerapannya di GA. Nilai tersebut akan terlihat secara publik, bersama dengan diskusi yang mengarah pada keputusan nilai. Jika Anda memiliki masukan, posting di masalah GH ini. |
Batasi Pelacakan Terselubung
Pengurangan Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
| Dependensi Deployment | Mengatasi dependensi deployment Agen Pengguna Terstruktur (SUA). | Kami telah meluncurkan "Fase 4", atau pengurangan versi minor untuk 100% pengguna Chrome pada versi 101 dan yang lebih baru. Lihat perubahannya di sini. |
| Pengujian | Permintaan untuk memperpanjang Uji Coba Origin Pengurangan Agen Pengguna dari Meta. | Kami memperpanjang Uji Coba Origin, dan memperoleh izin untuk menghapus batas traffic agar dapat mengakomodasi situs yang lebih besar. Batas traffic longgar berlaku untuk situs mana pun, besar atau kecil. |
Petunjuk Klien Agen Pengguna
| Tema Masukan | Ringkasan | Respons Chrome |
| (Juga dilaporkan pada Kuartal 2)
Masalah Anti-Penipuan / Anti-Penyalahgunaan |
Fitur tertentu yang mungkin hilang melalui UA-CH: Pelacak pengalihan klik dan klik palsu. | Update Q3:
Kami telah menerima masukan positif dari berbagai perusahaan yang melaporkan bahwa mereka tidak menemukan adanya efek buruk pada pipeline antipenipuan mereka (Hasilnya di sini dan di sini). Tim terus menyelidiki potensi masalah ini dengan pemangku kepentingan antipenipuan dan pengukuran. |
| Kebijakan-Izin | Apakah Kebijakan-Izin di-cache? | Kebijakan Izin tidak di-cache seperti yang dijelaskan dalam masalah GitHub ini. |
Penangkap Anggur (WIP)
| Tema Masukan | Ringkasan | Respons Chrome |
| Kasus penggunaan geolokasi | Gnatcatcher dapat mencegah kasus penggunaan geolokasi yang sah agar tidak berfungsi di masa mendatang, seperti personalisasi konten berdasarkan geolokasi. | Kami bekerja sama dengan para pemangku kepentingan untuk memastikan bahwa Chrome terus mendukung kasus penggunaan alamat IP yang sah. |
Memperkuat batas privasi lintas situs
Set Pihak Pertama
| Tema Masukan | Ringkasan | Respons Chrome |
| Kebijakan | Kekhawatiran bahwa FPS tidak konsisten dengan ketentuan komitmen CMA terkait "Legislasi Perlindungan Data yang Berlaku", atas dasar bahwa GDPR tidak menerapkan batasan pada jumlah situs dalam set sementara FPS memperkirakan batas 3. | Google telah berkomitmen kepada CMA untuk merancang dan menerapkan proposal Privacy Sandbox dengan cara yang tidak mengganggu persaingan dengan memprioritaskan bisnis Google sendiri, 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 pekerjaan kami mematuhi komitmen ini. Detail selengkapnya disertakan dalam bagian "Perubahan sebagai respons terhadap masukan" di bawah. |
| Dokumentasi | Meminta contoh tambahan dan memperbarui penjelasan yang ada. | Contoh dalam penjelasan kami sedang dalam peninjauan, dan akan memperjelas atau menghapus contoh yang diperlukan. |
| Berbagi preferensi | Proposal untuk membuat preferensi di seluruh kumpulan pihak yang sama. | Kami menyambut baik masukan tersebut dan secara aktif mendiskusikan ide tersebut di sini. |
| Penegakan | Proses penegakan yang transparan berisiko disalahgunakan oleh pihak tidak bertanggung jawab. | Kami menghargai masukan Anda dan secara aktif terlibat dalam diskusi dengan para pemangku kepentingan di GitHub (dengan mempertimbangkan poin-poin yang dibahas dalam masalah ini dan ingin menyertakan saran yang diajukan dalam masalah ini) serta forum lainnya untuk menilai risiko dan mengidentifikasi potensi mitigasi. |
| Kepemilikan bersama | Proposal deklarasi yang dapat dibaca mesin untuk kepemilikan bersama. | Masukan untuk proposal kami diterima dan disarankan. |
| Kepemilikan subdomain | Apakah subdomain berbeda dengan pengontrol data berbeda, kebijakan privasi yang berbeda, atau dioperasikan oleh entitas yang berbeda harus menjadi bagian dari Set Pihak Pertama yang sama? | Berdasarkan masukan tersebut, kami berencana menghapus kasus penggunaan eTLD yang umum. |
| Mitigasi Penyalahgunaan | Meminta detail selengkapnya tentang langkah-langkah mitigasi penyalahgunaan. | Pengelolaan prosesnya sedang dalam pertimbangan dan detail selengkapnya akan disampaikan dalam beberapa bulan mendatang. |
| Potensi vektor serangan | Kumpulan terkait yang bersifat menipu untuk halaman yang mudah ditemukan dapat digunakan untuk mengarahkan traffic ke halaman lain yang disajikan sendiri secara menipu. | Kami secara aktif mengumpulkan masukan publik dan menyelidiki kemungkinan cara untuk mengatasi masalah ini. |
| Setel validasi | Memvalidasi kumpulan melalui kebijakan umum yang diberi izin. | Berbagai anggota komunitas standar web dan ekosistem yang lebih luas telah menunjukkan bahwa hal ini tidak mungkin. |
| Batas domain | Permintaan untuk menambah jumlah domain terkait. | Kami aktif berdiskusi terkait batas domain di FPS, dan akan mengharapkan lebih banyak masukan dari komunitas mengenai jumlah domain terkait yang mereka butuhkan untuk kasus penggunaannya. |
| Interaksi layanan subset | Masalah terkait layanan dan Interaksi Subset terkait. | Kami menghargai masukan Anda dan akan berupaya untuk membuatnya lebih eksplisit dalam spesifikasi mendatang. |
| (Juga dilaporkan pada Kuartal 2)
Meningkatkan privasi |
Terlalu banyak situs dalam kumpulan yang sama dapat mengakibatkan hasil yang serupa dengan cookie pihak ketiga. | Update Kuartal 3:
Proposal terbaru menyarankan batas tiga domain untuk subset "terkait" (yang tidak mencakup ccTLD dan domain layanan). Chrome secara aktif berinteraksi dengan ekosistem untuk menentukan apakah batasan ini sesuai. |
| (Juga dilaporkan pada Kuartal 2)
Persyaratan kebijakan privasi umum |
Anda tidak dapat menjaga kebijakan privasi yang sama di semua produk dan wilayah hukum yang perlu menjadi bagian dari kumpulan yang sama. | Update Kuartal 3:
Kebijakan privasi umum tidak lagi diwajibkan untuk menjadi bagian dari kumpulan yang sama. |
API Fenced Frames
| Tema Masukan | Ringkasan | Respons Chrome |
| Mengapa elemen baru dan bukan atribut di iframe? | Pertanyaan mengenai proposal Frame Bertingkat, bukan proposal iFrame yang ada. | Kami menerima masukan Anda dan terbuka terhadap ide-ide untuk menyelaraskan kondisi saat ini seperti yang telah dibahas di sini. |
| Intersection observer dalam frame dengan fence | Pertanyaan terkait visibilitas informasi di dalam Frame dengan Fence. | Diskusi ini dilakukan secara aktif dan dalam periode pemberian komentar dalam dokumen ini serta di GitHub. Kami mempersilakan partner untuk membagikan kasus penggunaan kepada kami agar lebih memahami cara memberikan dukungan. |
| Mendukung inventaris Video & Native | Apakah Frame dengan Fence mendukung inventaris Video & Native? | Dalam hal kemampuan pemutaran video, Fenced Frames tidak berbeda dari iframe dan itulah sebabnya mengapa tidak secara eksplisit disebutkan dalam dokumentasi publik. Jika ada masalah dengan iklan video, sebaiknya Anda memberikan masukan agar kami dapat menyelidiki lebih lanjut. |
| Paket Web | Apakah penayangan / rendering iklan menurut Paket web akan menjadi persyaratan di masa mendatang dengan Fenced Frame x FLEDGE? | Sasaran jangka panjangnya adalah mendukung Paket Web untuk merender konten iklan dalam frame dengan fence. Namun, implementasi FLEDGE saat ini tidak mendukung hal ini, dan memerlukan rendering aset HTML yang diambil dari renderUrl. |
| Dimensi aset | Meminta render_url untuk mendukung makro bagi tinggi dan lebar slot agar kami dapat merespons dengan materi iklan yang berukuran sesuai | Hal ini secara aktif dibahas di sini. |
API Penyimpanan Bersama
| Tema Masukan | Ringkasan | Respons Chrome |
| Integrasi FLEDGE | Bagaimana Penyimpanan Bersama & FLEDGE akan diintegrasikan? | Meskipun saat ini kami tidak mengupayakan hal itu, kami tertarik untuk mempelajari ide tersebut agar dapat memastikan bahwa perlindungan privasi dapat terjaga. Kami mengimbau pihak yang tertarik untuk mengajukan saran terkait potensi kasus penggunaan yang dapat didukung proposal ini di repositori github Shared Storage atau repositori github FLEDGE. . |
| Retensi data | Menghapus Penyimpanan Bersama akan mengurangi utilitas. Apakah ekstensi pada periode retensi atau kemampuan untuk menghapus kunci/nilai individual telah dipertimbangkan sebagai alternatif? | Kami selalu mencari cara untuk menyeimbangkan privasi pengguna dan kompromi utilitas. Kami terbuka terhadap masukan terkait penyesuaian, dan mendorong partner untuk memberikan lebih banyak masukan dan detail saat menguji penyimpanan bersama. |
| Sinyal Negatif | Sinyal negatif dari Mozilla terkait proposal Penyimpanan Bersama. | Kami berterima kasih kepada Mozilla atas tinjauan cermat mereka terhadap proposal kami. Kami berencana menanggapi masukan mereka dalam waktu dekat. |
CHIP
| Tema Masukan | Ringkasan | Respons Chrome |
| Persyaratan yang dipartisi | Menambahkan persyaratan perilaku eksplisit untuk atribut "Terpartisi" pada cookie Pihak Pertama. | Kami telah membahas hal ini melalui panggilan PrivacyCG, dan telah menindaklanjuti masalah GitHub dengan catatan. Kami terus bekerja sama dengan browser, developer, dan komunitas privasi untuk menyelaraskan perilaku dan menentukannya. |
| Sematan terautentikasi | CHIPS dapat memengaruhi alur login SSO saat ini karena partisi yang berbeda memengaruhi penyematan yang diautentikasi. | Kami mengetahui kasus penggunaan sematan terautentikasi dan sedang berupaya untuk mencari solusi. |
| Batas Partisi Cookie | Perlu diperhatikan bahwa batas 10 cookie saat ini mungkin tidak cukup untuk kasus penggunaan tertentu. | Kami beralih dari batas jumlah cookie menjadi batas memori 12 kb. Hal tersebut memungkinkan kami mengatasi masalah terkait batas cookie sambil memastikan performa dan jejak memori browser tidak terpengaruh secara negatif. |
| Linimasa Uji Coba Origin | Memperluas OT mengikuti penghapusan persyaratan batasan nama host. | Kami telah memperpanjang batas waktu uji coba origin setelah mendapatkan masukan dari ekosistem. |
| Batasan pengujian di Chrome | Kemungkinan pengujian CHIPS di Firefox karena keterbatasan saat ini di Chrome. | Implementasi Firefox kira-kira berbeda, Chrome memiliki batas cookie yang lebih rendah, dan CHIPS adalah mekanisme keikutsertaan, tetapi Firefox dipartisi secara default. |
| (Juga dilaporkan pada Kuartal 2)
Sematan terautentikasi |
Apakah status login dipertahankan dengan CHIPS? | Update Kuartal 3:
Status login saat ini tidak dipertahankan, tetapi bukan kasus penggunaan yang dimaksudkan untuk CHIPS. Kami mengetahui kasus penggunaan sematan terautentikasi dan sedang berupaya untuk mencari solusi. |
FedCM
| Tema Masukan | Ringkasan | Respons Chrome |
| (Juga dilaporkan pada Kuartal 2)
Potensi vektor serangan |
Potensi vektor serangan melalui dekorasi tautan dan serangan pengaturan waktu. | Update Kuartal 3:
Kami telah bekerja sama dengan Mozilla untuk mencapai pemahaman umum tentang cara mengatasi masalah serangan waktu dan detailnya ada di sini. Kami sedang membuat prototipe perubahan arsitektur ini dan berharap dapat menjalankan eksperimen dalam beberapa kuartal ke depan. |
| Penyedia identitas | Pemilih akun: penyedia identitas tunggal. Permintaan untuk mengizinkan beberapa penyedia identitas. | Kami telah bekerja sama dengan vendor Browser dan FedID CG tentang cara mengizinkan beberapa penyedia identitas dan telah sampai pada rumusan yang tampaknya patut dicoba. Deskripsi proposal ada di sini dan kami berharap dapat mengembangkan prototipe serta menjalankan eksperimen dalam beberapa kuartal ke depan. |
| Masalah umum pada Federation | Permintaan untuk menghitung kasus saat penggabungan mungkin mengalami masalah terkait penghentian penggunaan cookie pihak ketiga. | CG FedID memiliki item pekerjaan yaitu untuk memerinci penyebab federasi di sini dan di sini. Mereka juga membuat matriks keputusan untuk memetakan kerusakan ke Web Platform API di sini. |
| Parameter kata benda | Dapatkah parameter Nounce memengaruhi alur login? | Hal ini dapat dianggap sebagai pelacakan lintas situs, tetapi kami masih mengumpulkan masukan dan menganalisis cara menangani kasus tersebut. |
| Persetujuan pengguna | Menautkan pihak tepercaya (RP) dan izin pengguna yang berbeda untuk setiap origin. | Spesifikasi ini tidak dapat mengontrol cara asal dalam domain yang sama membagikan cookie. Spesifikasi ini memungkinkan idtoken dari asal IDP ke asal RP, tetapi RP bebas memilih apakah status login pengguna harus disimpan dalam cookie yang dikunci ke satu asal tersebut atau cookie yang dibagikan dengan origin dalam domain yang sama. |
| Akun IDP
portabilitas |
Opsi pengguna untuk memigrasikan IDP jika mereka memilih saat mentransfer di antara dua IDP. | Sepertinya pengguna perlu melakukannya langsung di halaman pendaftaran IDP pilihan mereka yang baru, bukan melalui FedCM API. |
| Penghapusan akun | Pencabutan IDP memperhitungkan penghapusan akun dengan IDP. | Permintaan fitur ini terbuka untuk masukan dan dalam penyelidikan. |
| Klaim UI | Klaim tentang aspek antarmuka khusus browser. | Lihat permintaan pull untuk mengatasi hal ini. |
| Pemeriksaan Rujukan IDP | IDP memeriksa perujuk RP. | Menambahkan pemeriksaan perujuk IDP wajib ke spesifikasi. Lihat permintaan pull. |
| Alur login | Minta alur login disesuaikan berdasarkan preferensi RP. | Kami menyambut baik ide ini dan secara aktif mendiskusikannya. |
Memerangi spam dan penipuan
API Trust Tokens
| Tema Masukan | Ringkasan | Respons Chrome |
| Penipuan & Penyalahgunaan | Alat untuk memastikan bahwa bot tidak menipu penerbit agar memberinya token, bahwa bot tidak mengambil alih token yang diberikan kepada pengguna sungguhan dan untuk mencegah bot mengeluarkan token berbahaya? | Meskipun bot mungkin bisa mendapatkan token dari penerbit, penerbit sebaiknya membatasi frekuensi penerbitan token, metode andal untuk menerbitkan token, serta memperbarui logika penerbitannya karena pelaku kejahatan mencoba untuk mengakalinya. Penerbit yang tidak memiliki logika yang cukup kuat dalam menerbitkan token kemungkinan akan menjadi kurang tepercaya dalam ekosistem karena prioritas situs bergantung pada penerbit yang lebih andal. |
| Penipuan & Penyalahgunaan | Apakah ada cara bagi penebus Trust Token untuk dapat menentukan bahwa mereka hanya akan menerima Trust Token dari entitas tertentu? | Ya, ini mungkin saja. Bagian Penukaran Token Kepercayaan di penjelasan menjelaskan cara kerjanya. |
| Penipuan & Penyalahgunaan | Apakah ada cara bagi penerbit Trust Token untuk menentukan daftar penebus dan tidak mengizinkan orang lain untuk menukarkan token? | Saat ini belum bisa, tetapi tim kami sedang menyelidiki kasus penggunaan ini. |
| Linimasa | Kapan Trust Token API akan tersedia secara umum? | Segera setelah kami berkomitmen untuk menetapkan rentang waktu, kami akan membagikan lebih banyak informasi secara publik. |
| (Juga dilaporkan pada Kuartal 2)
Overhead pemeliharaan |
Tidak jelas berapa lama versi protokol akan didukung. | Update Kuartal 3:
Dukungan tambahan dalam API untuk mendukung beberapa versi serentak ditambahkan untuk memungkinkan transisi yang lancar antar-versi, meskipun jangka waktu untuk dukungan / penghentian masih dalam proses. |