Terima kasih telah menonton Google I/O. Tonton konten secara on-demand.

Halaman ini diterjemahkan oleh Cloud Translation API.

Pelacakan sidik jari

Pelacakan sidik jari berarti mencoba mengidentifikasi seorang pengguna saat ia kembali ke situs Anda, atau mengidentifikasi pengguna yang sama di berbagai situs. Ada banyak karakteristik yang dapat berbeda antara penyiapan Anda dan orang lain. Misalnya, Anda mungkin menggunakan jenis perangkat yang berbeda dan {i>browser<i} yang berbeda, memiliki ukuran layar yang berbeda, dan memasang {i>font<i} yang berbeda. Jika saya menggunakan {i>font<i} "Dejavu Sans" diinstal dan Anda tidak, maka situs web mana pun dapat membedakan antara Anda dan saya dengan memeriksa {i>font<i} tersebut. Ini adalah cara pelacakan sidik jari berfungsi; Anda membangun kumpulan titik data ini, dan masing-masing memberikan lebih banyak cara untuk membedakan pengguna.

Definisi yang lebih formal mungkin terlihat seperti ini: Pelacakan sidik jari adalah tindakan penggunaan yang jelas dan tidak jelas dilakukan dalam jangka panjang konfigurasi pengguna untuk mencoba membedakannya dari sebanyak mungkin pengguna lain.

Mengapa pelacakan sidik jari menghambat privasi pengguna

Ada beberapa kasus ekstrem di mana pelacakan sidik jari pengguna itu penting: misalnya deteksi penipuan. Tetapi pelacakan sidik jari juga dapat digunakan untuk melacak pengguna di seluruh situs, dan pelacakan sering kali dilakukan tanpa persetujuan pengguna, atau, dalam beberapa kasus, berdasarkan tentang persetujuan yang tidak valid yang tidak memberi tahu pengguna secara memadai. Setelah selesai, pengguna tersebut akan sering mendapati merasa cemas dan merasa dikhianati.

Pelacakan sidik jari berarti menemukan cara untuk secara diam-diam membedakan satu pengguna dari pengguna lainnya. Pelacakan sidik jari dapat digunakan untuk mengenali bahwa itu masih pengguna yang sama di situs web yang sama, atau untuk mengenali pengguna yang sama di dua profil browser yang berbeda pada saat yang sama. Artinya, pelacakan sidik jari dapat digunakan untuk melacak pengguna di berbagai situs. Metode pelacakan yang determenistik dan terbuka, seperti menyimpan cookie dengan ID khusus pengguna unik, hingga batas tertentu dapat diamati oleh pengguna dan dikontrol (dan modul sebelumnya menjelaskan beberapa pendekatan ini). Namun, pelacakan sidik jari lebih sulit dihindari karena tertutup; itu bergantung pada karakteristik yang tidak berubah dan kemungkinan besar terjadi secara tidak terlihat. Inilah mengapa disebut "sidik jari". Sangat sulit untuk mengubah sidik jari, baik sidik jari digital, atau sidik jari di ujung jari dari jari Anda.

Vendor browser mengetahui bahwa pengguna tidak suka dilacak, dan terus menerapkan fitur untuk membatasi pelacakan sidik jari (beberapa di antaranya kita lihat di modul sebelumnya). Di sini, kami akan melihat bagaimana fitur ini dapat memengaruhi bisnis Anda persyaratan dan bagaimana tetap melakukan apa yang ingin Anda lakukan dengan cara yang melindungi privasi. Ini selengkapnya tentang cara perlindungan browser terhadap pelacakan sidik jari akan memengaruhi tindakan yang Anda lakukan dan caranya, bukan cara hal tersebut menghentikan Anda melakukan pelacakan sidik jari.

Dalam praktiknya, sebagian besar developer dan sebagian besar bisnis tidak perlu mengambil sidik jari pengguna. Jika aplikasi Anda mengharuskan pengguna untuk login, maka pengguna Anda mengidentifikasi diri mereka untuk Anda, dengan persetujuan mereka, dan dengan cara yang dapat mereka pilih secara sepihak untuk tidak ikut serta kapan pun mereka mau. Ini adalah metode yang melindungi privasi untuk memahami pengguna mana yang {i>login<i}. Aplikasi Anda mungkin tidak mengharuskan pengguna untuk login, yang bahkan lebih melindungi privasi (dan Anda kemudian mengumpulkan hanya data yang Anda butuhkan).

Anjuran

Menilai pihak ketiga Anda untuk pelacakan sidik jari. Sebagai bagian dari modul pihak ketiga, Anda dapat mungkin sudah memiliki daftar layanan pihak ketiga apa pun yang Anda sertakan dan permintaan web yang mereka buat. Mungkin saja untuk memeriksa permintaan tersebut guna melihat data mana yang diteruskan kembali ke pencetus, jika ada. Namun, hal ini sering kali sulit; pelacakan sidik jari pada dasarnya adalah proses tersembunyi yang melibatkan permintaan data yang tidak tunduk kepada persetujuan pengguna.

Ada baiknya juga membaca kebijakan privasi layanan dan dependensi pihak ketiga Anda untuk mencari indikasi pelacakan sidik jari sedang digunakan. Ini kadang disebut sebagai "pencocokan probabilistik", atau sebagai bagian dari serangkaian teknik pencocokan probabilistik, sebagai kebalikan dari "pencocokan determenistik".

Cara kerja pelacakan sidik jari

Sering kali kombinasi pribadi Anda dari semua atribut ini bersifat unik bagi Anda, atau pada setidaknya untuk sekelompok kecil orang yang serupa; ini dapat digunakan untuk melacak Anda secara diam-diam.

Selain: pelacakan sidik jari pasif dan aktif

Ada perbedaan yang berguna antara teknik pelacakan sidik jari pasif dan aktif. Pelacakan sidik jari pasif teknik adalah salah satu yang menggunakan informasi yang diberikan ke situs web secara {i>default<i}; teknik pelacakan sidik jari aktif adalah salah satu yang secara eksplisit menginterogasi {i> browser <i}untuk informasi tambahan. Alasan perbedaan ini penting adalah karena browser dapat mencoba mendeteksi dan mencegat, atau mengurangi, teknik aktif. API dapat dibatasi, atau di-gateway melalui dialog meminta izin pengguna (dan karenanya memberi tahu pengguna bahwa izin tersebut digunakan, atau mengizinkan pengguna untuk menolaknya secara default). Teknik pasif adalah teknik yang menggunakan data yang telah diberikan ke situs web, sering kali karena secara historis, pada masa-masa awal kemunculan informasi superhighway, informasi itu diberikan ke semua situs. String agen pengguna adalah dari serangan ini, dan kita akan melihat ini lebih detail lebih lanjut. Cloud Functions dianggap berguna dalam menyediakan {i>browser<i}, versi, dan sistem operasi pengguna, agar {i>website<i} dapat memilih untuk menyajikan berbagai berdasarkan data tersebut. Namun, hal ini juga meningkatkan jumlah informasi pembeda yang tersedia, yang membantu mengidentifikasi satu pengguna dari yang lain; dan karenanya informasi tersebut semakin banyak tidak tersedia, atau setidaknya dibekukan sehingga tidak bisa dibedakan lagi. Jika yang Anda lakukan bergantung pada informasi ini—misalnya, jika Anda mengambil cabang kode tergantung pada agen-pengguna—maka kode ini bisa rusak karena browser semakin banyak membekukan atau menghentikan informasi tersebut. Pengujian adalah pertahanan terbaik di sini ( lihat nanti).

Selain: mengukur kemampuan sidik jari

Ukuran teknis untuk berapa banyak informasi yang disediakan oleh setiap titik data ini disebut entropi dan diukur dalam bit. Fitur di mana ada banyak kemungkinan nilai (seperti daftar font yang diinstal) dapat berkontribusi banyak bit secara keseluruhan, di mana sesuatu tanpa daya pembeda yang besar (seperti sistem operasi yang Anda gunakan) hanya dapat beberapa. HTTP Almanac menjelaskan bagaimana pelacakan sidik jari yang ada library ini mengotomatiskan proses penggabungan respons dari berbagai API ke dalam sebuah "hash", yang mungkin hanya mengidentifikasi sekelompok kecil pengguna, bahkan mungkin hanya satu. Maud Nalpas membahas hal ini secara detail dalam video YouTube ini, tetapi, singkatnya, bayangkan Anda melihat daftar teman Anda dengan musik favorit, makanan favorit, dan bahasa yang mereka gunakan ... tetapi dengan nama mereka dihapus. Kemungkinan besar daftar seseorang akan mengidentifikasi mereka secara unik di antara teman-teman Anda, atau setidaknya sempit hanya untuk beberapa orang. Beginilah cara kerja pelacakan sidik jari; daftar hal-hal yang Anda sukai akan menjadi "hash". Dengan {i>hash <i}itu, mengidentifikasi pengguna sebagai orang yang sama di dua situs berbeda yang tidak terhubung menjadi lebih mudah, yang merupakan tujuan pelacakan: untuk mengelak dari keinginan pengguna akan privasi.

Apa yang dilakukan browser terhadap pelacakan sidik jari?

Yang penting, vendor browser sangat mengetahui berbagai cara untuk situs (atau pihak ketiga yang disertakan di situs) untuk menghitung sidik jari yang berbeda untuk pengguna, atau untuk bit informasi yang berbeda untuk berkontribusi pada keunikan sidik jari tersebut. Beberapa cara ini eksplisit dan disengaja, seperti string agen pengguna browser, yang sering mengidentifikasi browser, sistem operasi, dan versi yang digunakan (sehingga membantu membedakan Anda dengan saya, jika Anda dan saya menggunakan browser yang berbeda). Beberapa cara tidak sengaja dibuat agar dapat diakses dengan sidik jari tetapi akhirnya seperti daftar font, atau perangkat video dan audio yang tersedia untuk browser. (Browser tidak perlu menggunakan perangkat ini, cukup dapatkan daftarnya berdasarkan nama.) Dan beberapa telah ditetapkan sebagai kontributor sidik jari dengan baik setelah rilis, seperti rendering piksel yang tepat dari antialiasing font pada elemen kanvas. Masih banyak lagi, dan setiap cara yang membedakan browser Anda dengan milik saya menambah entropi dan berpotensi berkontribusi pada untuk membedakan antara Anda dan saya, dan mengidentifikasi setiap orang seunik mungkin di berbagai situs web. https://amiunique.org memiliki daftar panjang (tapi jelas tidak komprehensif) tentang potensi kontribusi sidik jari fitur baru, dan daftar ini terus bertambah (karena ada kepentingan moneter yang besar untuk dapat mengambil sidik jari pengguna, bahkan jika pengguna tidak menginginkannya atau mungkin tidak mengharapkannya).

Tidak mendukung API canggih tertentu

Respons dari vendor browser terhadap semua pendekatan untuk menghitung sidik jari pengguna ini adalah untuk menemukan cara untuk mengurangi jumlah entropi yang tersedia dari API tersebut. Opsi yang paling ketat adalah tidak menerapkannya sejak awal. Hal ini telah dilakukan oleh beberapa browser besar untuk berbagai perangkat keras dan API perangkat (seperti NFC dan akses Bluetooth dari aplikasi web sisi klien), dengan masalah pelacakan sidik jari dan privasi disebut sebagai alasan mengapa aplikasi tersebut belum diimplementasikan. Ini, tentu saja, dapat memengaruhi aplikasi dan layanan Anda: Anda tidak dapat menggunakan API sama sekali di browser yang tidak mengimplementasikannya, dan hal ini dapat membatasi atau sepenuhnya menghentikan beberapa pendekatan perangkat keras dari pertimbangan.

Gateway izin pengguna

Pendekatan kedua yang diambil oleh vendor browser adalah mencegah akses API atau data tanpa semacam izin eksplisit dari pengguna. Pendekatan ini sering kali dilakukan untuk alasan keamanan juga—sebuah situs web seharusnya tidak dapat mengambil gambar dengan {i>webcam<i} Anda tanpa izin Anda! Namun di sini, privasi dan keamanan memiliki kepentingan yang sama. Mengidentifikasi lokasi seseorang adalah pelanggaran privasi itu sendiri, tentu saja, tetapi juga merupakan penyebab keunikan sidik jari. Memerlukan izin melihat geolokasi tidak mengurangi entropi ekstra yang ditambahkan lokasi ke keunikan sidik jari tersebut, tetapi pada dasarnya menghilangkan penggunaan geolokasi untuk pelacakan sidik jari karena tindakan ini tidak lagi dilakukan secara tidak terlihat. Inti dari pelacakan sidik jari adalah untuk secara diam-diam membedakan pengguna satu sama lain. Jika Anda siap untuk pengguna mengetahui bahwa Anda mencoba mengidentifikasinya, maka Anda tidak memerlukan teknik pelacakan sidik jari: minta pengguna untuk membuat akun dengannya.

Menambahkan ketidakpastian

Pendekatan ketiga yang diambil dalam beberapa kasus adalah membuat vendor browser "menjadi" respons dari API untuk membuatnya kurang terperinci sehingga tidak perlu terlalu banyak mengidentifikasi. Hal ini dijelaskan sebagai bagian dari mekanisme respons acak dalam modul data sebagai sesuatu yang dapat Anda lakukan saat mengumpulkan data dari pengguna, untuk menghindari pengumpulan data secara tidak sengaja. Vendor browser dapat menggunakan pendekatan ini terhadap data API yang juga tersedia untuk aplikasi web dan pihak ketiga. Contohnya adalah API pengaturan waktu yang sangat akurat yang digunakan untuk mengukur performa halaman dari window.performance.now(). Browser mengetahui nilai-nilai ini dengan akurasi mikrodetik, tetapi nilai yang dikembalikan sengaja dikurangi presisinya dengan membulatkan ke 20 mikrodetik terdekat untuk menghindari penggunaannya dalam pelacakan sidik jari (dan juga demi keamanan guna menghindari serangan waktu). Tujuannya adalah untuk memastikan API tetap bermanfaat, tetapi untuk membuat respons kurang mengidentifikasi: pada intinya, untuk memberikan "kekebalan kelompok" dengan membuat perangkat Anda lebih mirip dengan perangkat orang lain bukan aneh bagi Anda. Safari menghadirkan versi konfigurasi sistem yang disederhanakan karena alasan ini.

Menegakkan anggaran privasi

Anggaran Privasi adalah proposal yang menyarankan agar browser memperkirakan informasi yang diungkapkan oleh setiap platform pelacakan sidik jari. Solusi ini belum diimplementasikan di browser. Tujuannya adalah untuk memungkinkan API yang canggih sekaligus menjaga privasi pengguna. Pelajari proposal anggaran privasi lebih lanjut.

Menggunakan lingkungan pengujian yang luas

Semua ini akan memengaruhi cara Anda membangun aplikasi dan layanan. Secara khusus, ada beragam respons dan pendekatan lintas browser dan platform di area ini. Artinya, menguji pekerjaan Anda di beberapa lingkungan yang berbeda adalah penting. Hal ini, tentu saja, selalu penting, tetapi dapat diasumsikan bahwa rendering HTML atau CSS akan konstan selama beberapa waktu. terhadap mesin perenderan tertentu, apa pun browser atau platform tempat mesin tersebut berada (sehingga Anda mungkin ingin mencobanya hanya dengan satu Misalnya, browser berbasis blink). Ini jelas bukan kasus penggunaan API melainkan karena browser yang berbagi mungkin berbeda secara dramatis dalam hal cara pengerasan permukaan API terhadap pelacakan sidik jari.

Anjuran

Periksa analisis dan audiens Anda untuk memandu kumpulan browser yang harus diprioritaskan saat melakukan pengujian.
Kumpulan browser yang bagus untuk diuji adalah Firefox, Chrome, Edge, Safari di desktop, Chrome dan Samsung Internet di Android, dan Safari di iOS. Hal ini memastikan Anda menguji di tiga mesin rendering utama (Gecko di Firefox, berbagai fork Blink di Chrome, Edge, dan Samsung Internet, serta Webkit di Safari), dan di platform seluler dan desktop.
Jika situs Anda mungkin juga digunakan di perangkat yang kurang umum, seperti tablet, smartwatch, atau konsol game, lakukan pengujian di situs tersebut juga. Beberapa platform hardware dapat tertinggal dari seluler dan desktop untuk update browser, yang berarti bahwa beberapa API mungkin tidak diimplementasikan atau tidak tersedia di browser pada platform tersebut.
Uji dengan satu atau beberapa browser yang mengklaim privasi pengguna sebagai motivator. Menyertakan versi pra-rilis dan pengujian mendatang browser yang paling umum, di mana Anda bisa, dan jika tersedia untuk Anda: Pratinjau teknologi Safari, Canary di Chrome, saluran Beta Firefox. Hal ini memberi Anda peluang terbaik untuk mengidentifikasi kerusakan API dan perubahan yang memengaruhi situs Anda sebelum perubahan tersebut memengaruhi pengguna Anda. Demikian pula, pastikan pengguna dengan mempertimbangkan setiap analitik yang Anda miliki. Jika basis pengguna memiliki banyak ponsel Android lama, pastikan untuk menyertakannya dalam pengujian. Kebanyakan orang tidak memiliki perangkat keras cepat dan rilis terbaru yang dilakukan oleh tim pengembangan.
Menguji menggunakan profil bersih dan dalam mode samaran/penjelajahan pribadi; kemungkinannya adalah Anda telah memberikan izin yang diperlukan di profil pribadi Anda. Uji apa yang terjadi jika Anda menolak izin ke situs untuk pertanyaan apa pun.
Uji halaman Anda secara eksplisit di perlindungan sidik jari Firefox mode. Tindakan ini akan menampilkan dialog izin jika halaman Anda mencoba pelacakan sidik jari, atau akan menampilkan data fuzzing untuk beberapa API. Tindakan ini membantu Anda mengonfirmasi apakah pihak ketiga yang disertakan dalam layanan Anda menggunakan data yang dapat diidentifikasi dengan sidik jari, atau apakah layanan Anda bergantung pada layanan Anda itu. Selanjutnya, Anda dapat mempertimbangkan apakah fuzzing yang disengaja mempersulit Anda untuk melakukan hal yang diperlukan. Pertimbangkan untuk membuat koreksi yang sesuai untuk mendapatkan data tersebut dari sumber lain, tidak menggunakannya, atau menggunakan data yang kurang terperinci.
Seperti yang telah dibahas dalam modul pihak ketiga, Anda juga perlu mengaudit dependensi untuk melihat apakah mereka menggunakan teknik pelacakan sidik jari. Pelacakan sidik jari pasif sulit dideteksi (dan mustahil jika pihak ketiga melakukannya di server mereka) tetapi mode sidik jari dapat menandai beberapa teknik pelacakan sidik jari, dan mencari penggunaan navigator.userAgent atau pembuatan objek <canvas> yang tidak terduga juga dapat mengungkapkan beberapa pendekatan yang perlu diselidiki lebih lanjut. Sebaiknya cari juga penggunaan istilah "pencocokan probabilistik" di bidang pemasaran atau materi teknis yang menggambarkan pihak ketiga; hal ini terkadang menunjukkan penggunaan teknik pelacakan sidik jari.

Alat pengujian lintas browser

Menguji kode Anda untuk tujuan privasi sulit diotomatiskan, dan hal-hal yang harus diperhatikan saat pengujian secara manual dijelaskan sebelumnya. Apa yang terjadi saat Anda menolak izin ke situs untuk API apa pun yang akan diakses, misalnya, dan bagaimana hal tersebut ditampilkan kepada pengguna? Pengujian otomatis tidak dapat menilai apakah situs bertindak sedemikian rupa untuk membantu pengguna memercayainya, atau sebaliknya mendorong pengguna untuk tidak memercayainya, atau berpikir bahwa ada sesuatu yang disembunyikan.

Namun, setelah situs diaudit, pengujian API untuk mengonfirmasi bahwa tidak ada yang rusak di versi browser yang lebih baru (atau dalam "beta" mendatang dan "preview" versi) dapat diotomatiskan, dan sebagian besar harus menjadi bagian dari rangkaian pengujian yang sudah ada. Sesuatu yang perlu dipertimbangkan dengan alat pengujian otomatis, saat bekerja dengan cakupan permukaan API, adalah bahwa sebagian besar browser mengontrol ketersediaan API dan fitur mana saja. Chrome melakukannya melalui tombol command line, seperti halnya Firefox, dan memiliki akses ke fitur ini di alat pengujian akan memungkinkan Anda menjalankan pengujian tertentu dengan API yang diaktifkan atau dinonaktifkan. (Lihat, misalnya, Cypress plugin peluncuran browser parameter launch.args nd puppeteer untuk cara untuk menambahkan tanda browser saat diluncurkan.)

Hanya mengandalkan string agen pengguna untuk informasi umum

Sebagai contoh lain, sejak awal web, browser mengirim deskripsi diri dengan setiap permintaan di Header Agen Pengguna HTTP. Hampir selama ini, orang-orang telah menganjurkan agar developer web tidak menggunakan konten header user-agent menyajikan konten yang berbeda ke browser yang berbeda, dan untuk semua waktu itu pengembang web tetap melakukannya, dengan jumlah bukti dalam beberapa kasus (tetapi tidak semua). Karena {i>browser<i} tidak ingin dipilih untuk pengalaman yang kurang optimal oleh situs web, hal ini menyebabkan setiap browser berpura-pura menjadi setiap browser lain, dan string agen pengguna akan tampak seperti:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

Klaim ini, antara lain, adalah Mozilla/5.0, browser yang dirilis pada saat yang sama dengan astronot pertama naik ke Stasiun Luar Angkasa Internasional lebih dari dua dekade lalu. String agen pengguna adalah sumber entropi yang kaya untuk pelacakan sidik jari, tentu saja, dan untuk mengurangi kemampuan sidik jari, produsen browser telah membekukan header agen pengguna atau bekerja untuk melakukannya. Ini adalah contoh lain dalam mengubah data yang disediakan API tanpa perlu menghapus API sepenuhnya. Mengirim header agen pengguna kosong akan merusak banyak situs yang mengasumsikan bahwa header tersebut ada. Jadi secara umum, {i>browser<i} apa yang adalah menghapus beberapa detail darinya, dan kemudian menjaganya tetap tidak berubah mulai saat itu. (Anda dapat melihat ini terjadi di Safari, Chrome, dan Firefox.) Perlindungan terhadap pelacakan sidik jari yang terperinci pada dasarnya berarti Anda tidak dapat lagi mengandalkan {i>header<i} agen pengguna untuk akurat, dan jika Anda melakukannya, maka penting untuk mencari sumber data alternatif.

Untuk lebih jelasnya, data di agen pengguna tidak sepenuhnya dihapus, tetapi tersedia pada tingkat perincian yang lebih rendah, atau terkadang tidak akurat karena nomor yang lebih lama tetapi tidak berubah mungkin dilaporkan. Misalnya, Firefox, Safari, dan Chrome semuanya dibatasi nomor versi macOS yang dilaporkan menjadi sepuluh (lihat Pembaruan tentang pengurangan string agen pengguna untuk diskusi lebih lanjut di sini). Detail persis tentang cara Chrome berencana mengurangi data dalam string agen pengguna tersedia di Pengurangan Agen Pengguna tetapi, singkatnya, Anda dapat mengharapkan bahwa nomor versi browser yang dilaporkan hanya akan berisi versi utama (jadi nomor versi akan terlihat seperti 123.0.0.0, bahkan jika browsernya adalah versi 123.10.45.108), dan versi OS akan tanpa detail dan akan berhenti pada salah satu dari sejumlah kecil pilihan yang tidak berubah. Jadi Chrome versi imajiner 123.45.67.89 berjalan di Windows 20 akan melaporkan nomor versinya sebagai:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Informasi inti yang Anda perlukan (versi browser) masih tersedia: ini adalah Chrome 123, di Windows. Tapi anak perusahaan informasi (arsitektur chip, versi Windows, versi Safari yang ditiru, versi minor browser) tidak akan tersedia lagi setelah pembekuan.

Bandingkan ini dengan model "saat ini" Agen pengguna Chrome di platform lain:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

dan dapat dilihat bahwa satu-satunya yang berbeda adalah nomor versi Chrome (104) dan ID platform.

Demikian pula, string agen pengguna Safari menunjukkan platform dan nomor versi Safari, serta memberikan versi OS di iOS, tapi yang lainnya berhenti. Jadi Safari versi 1234.5.67 imajiner yang berjalan pada macOS 20 imajiner mungkin memberikan agen penggunanya sebagai:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

dan pada iOS 20 imajiner itu mungkin:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

Sekali lagi, informasi inti (ini Safari, yang ada di iOS atau macOS) sudah tersedia, dan iOS Safari masih menyediakan nomor versi iOS; tetapi banyak informasi tambahan yang tersedia di masa lalu telah dibekukan. Yang penting, ini termasuk paket Safari nomor versi, yang belum tentu tersedia.

Perubahan pada agen pengguna yang dilaporkan sangat diperdebatkan. https://github.com/WICG/ua-client-hints#use-cases summarises ringkasan beberapa argumen dan alasan perubahan, dan Rowan Merewood memiliki slide presentasi dengan beberapa strategi untuk beralih dari penggunaan agen pengguna untuk diferensiasi, dalam konteks proposal Petunjuk Klien UA yang dijelaskan lebih lanjut.

Proses fuzzing

Fuzzing adalah istilah dari praktik keamanan, di mana API dipanggil dengan nilai-nilai yang tidak terduga dengan harapan dapat menanganinya nilai-nilai yang tak terduga dengan buruk dan menyebabkan masalah keamanan. Developer web harus memahami pembuatan skrip lintas situs (XSS), yang melibatkan penambahan skrip berbahaya ke halaman, sering kali karena halaman tidak meng-escape dengan benar HTML yang dimasukkan (jadi Anda melakukan kueri penelusuran dengan teks <script> di dalamnya). Pengembang {i>back-end<i} akan mengetahui injeksi SQL, di mana kueri {i>database<i} yang tidak memvalidasi {i>input<i} pengguna dengan benar akan menimbulkan masalah keamanan (seperti yang diilustrasikan oleh xkcd dengan Tabel Bobby Kecil). Fuzzing, atau pengujian fuzz, lebih tepat digunakan untuk upaya otomatis guna memberikan banyak input tidak valid atau tidak terduga yang berbeda ke API dan untuk memeriksa hasil kebocoran keamanan, kerusakan, atau penanganan buruk lainnya. Ini semua adalah contoh pemberian informasi yang tidak akurat dengan sengaja. Namun, sedang dalam proses terlebih dahulu oleh browser (dengan membuat agen pengguna sengaja salah), untuk mendorong developer berhenti mengandalkan data tersebut.

Anjuran

Periksa codebase Anda untuk ketergantungan pada string agen pengguna (penelusuran untuk navigator.userAgent kemungkinan akan menemukan paling banyak kemunculan di kode sisi klien, dan kode backend Anda kemungkinan akan mencari User-Agent sebagai header), termasuk dependensi.
Jika Anda menemukan kegunaan dalam kode Anda sendiri, cari tahu apa yang diperiksa kode tersebut, dan temukan cara lain untuk melakukan diferensiasi tersebut (atau temukan dependensi pengganti, atau tangani dependensi upstream dengan melaporkan masalah atau memeriksa updatenya). Kadang-kadang diferensiasi browser diperlukan untuk mengatasi bug, tetapi agen pengguna akan makin tidak menjadi cara untuk melakukannya setelah dibekukan.
Kamu mungkin aman. Jika Anda hanya menggunakan nilai inti dari {i>brand<i}, versi utama, dan platform, maka hal ini hampir pasti masih menjadi tersedia dan benar dalam string agen pengguna.
MDN menjelaskan cara yang baik untuk menghindari ketergantungan pada string agen pengguna ("browser sniffing"), salah satunya adalah deteksi fitur.
Jika Anda bergantung pada string agen pengguna dalam beberapa cara (bahkan saat menggunakan beberapa nilai inti yang tetap berguna), ide untuk menguji dengan agen pengguna yang akan ada dalam rilis {i>browser<i} baru. Anda dapat melakukan pengujian dengan browser mendatang versi itu sendiri melalui build pratinjau teknologi atau beta, tetapi ada juga kemungkinan untuk menetapkan string agen pengguna kustom pengujian. Anda dapat mengganti string agen pengguna di Chrome, Edge, Firefox, dan Safari, saat melakukan pengembangan lokal, untuk memeriksa bagaimana kode Anda menangani berbagai nilai agen pengguna yang mungkin Anda terima dari pengguna.

Petunjuk Klien

Salah satu proposal utama untuk memberikan informasi ini adalah Petunjuk Klien Agen Pengguna, meskipun ini tidak didukung di seluruh browser. Browser pendukung akan meneruskan tiga header: Sec-CH-UA, yang memberi merek browser dan nomor versi; Sec-CH-UA-Mobile, yang menunjukkan apakah permintaan berasal dari perangkat seluler; dan Sec-CH-UA-Platform, yang menamai sistem operasi. (Mengurai {i>header<i} ini tidaklah mudah karena Header Terstruktur, bukan string sederhana, dan hal ini diberlakukan oleh browser yang mengirim "rumit" jika tidak diurai dengan benar, tidak akan ditangani dengan benar. Yaitu, seperti sebelumnya, contoh “pengujian fuzz” dilakukan secara preemtif oleh browser. Developer yang menggunakan data ini diperlukan untuk menangani Dengan benar, karena data dirancang sedemikian rupa sehingga penguraian yang tidak tepat atau lambat cenderung akan memberikan hasil yang buruk, seperti menampilkan merek yang tidak ada, atau string yang tidak tertutup dengan benar.) Untungnya, data ini juga disediakan oleh {i>browser<i} ke JavaScript secara langsung sebagai navigator.userAgentData, yang di browser pendukung mungkin terlihat seperti objek ini:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}