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 pengguna saat mereka 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 dan browser yang berbeda, memiliki ukuran layar yang berbeda, dan menginstal font yang berbeda. Jika saya telah menginstal font "Dejavu Sans" dan Anda tidak, situs mana pun dapat mengetahui perbedaan antara Anda dan saya dengan memeriksa font tersebut. Inilah cara kerja pembuatan sidik jari; Anda membuat kumpulan titik data ini, dan setiap titik data memberikan lebih banyak cara untuk membedakan pengguna.

Definisi yang lebih formal mungkin terlihat seperti ini: Pelacakan sidik jari adalah tindakan menggunakan karakteristik yang jelas dan tidak jelas dari penyiapan pengguna yang berumur panjang untuk mencoba membedakannya dari sebanyak mungkin pengguna lain.

Mengapa pelacakan sidik jari menghambat privasi pengguna

Ada beberapa kasus ekstrem saat sidik jari pengguna penting: misalnya, deteksi penipuan. Namun, sidik jari juga dapat digunakan untuk melacak pengguna di seluruh situs, dan pelacakan tersebut sering kali dilakukan tanpa izin pengguna, atau, dalam beberapa kasus, atas dasar izin 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. Sidik jari dapat digunakan untuk mengenali bahwa pengguna yang sama masih berada di situs yang sama, atau untuk mengenali pengguna yang sama di dua profil browser yang berbeda secara bersamaan. Artinya, sidik jari dapat digunakan untuk melacak pengguna di seluruh situs. Metode pelacakan deterministik dan terbuka, seperti menyimpan cookie dengan ID unik khusus pengguna, dapat diamati dan dikontrol oleh pengguna hingga batas tertentu (dan modul sebelumnya menjelaskan beberapa pendekatan ini). Namun, sidik jari lebih sulit dihindari karena bersifat rahasia; sidik jari mengandalkan karakteristik yang tidak berubah dan kemungkinan besar terjadi secara tidak terlihat. Itulah sebabnya proses ini disebut "pembuatan sidik jari". Sulit untuk mengubah sidik jari Anda, baik sidik jari digital maupun sidik jari di ujung 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, pengguna akan mengidentifikasi diri mereka kepada Anda, dengan izin mereka, dan dengan cara yang dapat mereka pilih secara sepihak kapan saja mereka mau. Ini adalah metode yang melindungi privasi untuk memahami pengguna mana yang {i>login<i}. Aplikasi Anda mungkin tidak memerlukan pengguna untuk login sama sekali, yang bahkan lebih melindungi privasi pengguna (dan Anda kemudian mengumpulkan hanya data yang Anda perlukan).

Anjuran

Nilai pihak ketiga Anda untuk mendapatkan 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. Anda mungkin dapat memeriksa permintaan tersebut untuk melihat data mana yang diteruskan kembali ke pengirim, 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.

Sebaiknya baca juga kebijakan privasi layanan dan dependensi pihak ketiga untuk mencari indikasi pengambilan sidik jari yang 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 di sini yang harus dibuat antara teknik 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, sering kali karena secara historis, pada awal kemunculan superhighway informasi, informasi tersebut 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 itu: mengukur kemampuan sidik jari

Ukuran teknis untuk jumlah informasi yang diberikan setiap titik data ini disebut entropi dan diukur dalam bit. Fitur yang memiliki banyak kemungkinan nilai yang berbeda (seperti daftar font yang diinstal) dapat berkontribusi banyak bit ke total, sehingga sesuatu yang tidak memiliki banyak kemampuan pembeda (seperti sistem operasi yang Anda gunakan) mungkin hanya menambahkan beberapa. HTTP Almanac menjelaskan cara library sidik jari yang ada mengotomatiskan proses penggabungan respons dari berbagai API menjadi "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. Inilah cara kerja sidik jari; daftar hal yang Anda sukai 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 menyadari banyak cara yang berbeda bagi situs (atau pihak ketiga yang disertakan di situs) untuk menghitung sidik jari yang membedakan pengguna, atau untuk berbagai bit informasi yang 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 diambil sidik jarinya, tetapi akhirnya tetap begitu, 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 setelah rilis, seperti rendering piksel yang tepat dari anti-aliasing 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 utama untuk berbagai API hardware dan perangkat (seperti akses NFC dan Bluetooth dari aplikasi web sisi klien), dengan masalah sidik jari dan privasi yang dikutip sebagai alasan mengapa API tersebut belum diterapkan. 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 dilakukan oleh vendor browser adalah mencegah akses API atau data tanpa semacam izin pengguna yang eksplisit. 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. Mewajibkan izin untuk melihat geolokasi tidak mengurangi entropi tambahan yang ditambahkan lokasi ke keunikan sidik jari tersebut, tetapi pada dasarnya menghilangkan penggunaan geolokasi untuk sidik jari karena 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 memberi tahu pengguna bahwa Anda mencoba mengidentifikasinya, Anda tidak memerlukan teknik sidik jari: minta pengguna membuat akun dan login dengan akun tersebut.

Menambahkan ketidakpastian

Pendekatan ketiga yang dilakukan dalam beberapa kasus adalah vendor browser "mengacak" respons dari API agar tidak terlalu terperinci sehingga tidak terlalu 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 ini dengan akurasi mikrodetik, tetapi presisi nilai yang ditampilkan sengaja dikurangi dengan membulatkan ke batas terdekat 20 mikrodetik untuk menghindari penggunaannya dalam pembuatan sidik jari (dan juga untuk keamanan guna menghindari serangan waktu, tentu saja). 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 dianggap wajar untuk mengasumsikan bahwa rendering HTML atau CSS akan konstan untuk mesin rendering tertentu, terlepas dari browser atau platform tempat mesin tersebut berada (sehingga dapat menggoda untuk menguji hanya di satu browser berbasis Blink, misalnya). 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 sendiri untuk memandu kumpulan browser yang harus diprioritaskan saat pengujian.
Rangkaian browser yang baik untuk pengujian 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 juga dapat digunakan di perangkat yang kurang umum, seperti tablet, smartwatch, atau konsol game, uji juga di perangkat tersebut. Beberapa platform hardware dapat tertinggal dari seluler dan desktop untuk update browser, yang berarti bahwa beberapa API mungkin tidak diimplementasikan atau tidak tersedia pada browser pada platform tersebut.
Uji dengan satu atau beberapa browser yang mengklaim privasi pengguna sebagai motivator. Sertakan versi pra-rilis dan versi pengujian browser yang paling umum di masa mendatang jika Anda dapat melakukannya dan jika tersedia untuk Anda: pratinjau teknologi Safari, Canary 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, perhatikan lingkungan pengguna Anda dengan referensi ke analisis apa pun yang Anda miliki. Jika basis pengguna memiliki banyak ponsel Android lama, pastikan untuk menyertakannya dalam pengujian. Sebagian besar orang tidak memiliki hardware cepat dan rilis terbaru seperti yang dimiliki tim pengembangan.
Uji menggunakan profil bersih dan dalam mode penjelajahan rahasia/pribadi; kemungkinannya 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 mengambil sidik jari, atau akan menampilkan data yang di-fuzz untuk beberapa API. Hal ini membantu Anda mengonfirmasi apakah pihak ketiga yang disertakan dalam layanan Anda menggunakan data yang dapat diambil sidik jarinya, atau apakah layanan Anda sendiri bergantung pada hal tersebut. 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 sebelumnya di modul pihak ketiga, Anda juga perlu mengaudit dependensi pihak ketiga untuk mengetahui apakah dependensi tersebut menggunakan teknik 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

Pengujian kode Anda untuk tujuan privasi sulit diotomatiskan, dan hal-hal yang harus dicari saat melakukan pengujian secara manual telah dijelaskan sebelumnya. Apa yang terjadi jika Anda menolak izin ke situs untuk API apa pun yang coba diaksesnya, misalnya, dan bagaimana hal itu ditampilkan kepada pengguna? Pengujian otomatis tidak dapat menilai apakah situs bertindak 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 di versi "beta" dan "pratinjau" mendatang) dapat diotomatiskan, dan sebagian besar harus dilakukan sebagai bagian dari rangkaian pengujian yang ada. Hal yang perlu dipertimbangkan dengan alat pengujian otomatis Anda, saat menggunakan cakupan platform API, adalah sebagian besar browser mengizinkan beberapa tingkat kontrol atas API dan fitur yang tersedia. Chrome melakukannya melalui tombol command line, seperti halnya Firefox, dan dengan memiliki akses ke tombol ini dalam penyiapan alat pengujian, Anda dapat menjalankan pengujian tertentu dengan API dinonaktifkan atau diaktifkan. (Lihat, misalnya, plugin peluncuran browser Cypress dan parameter launch.args puppeteer untuk mengetahui cara menambahkan flag browser saat peluncuran.)

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. Selama hampir waktu yang sama, orang-orang telah menasihati developer web untuk tidak menggunakan konten header agen pengguna untuk menayangkan konten yang berbeda ke browser yang berbeda, dan selama itu developer web tetap melakukannya, dengan sejumlah justifikasi dalam beberapa (tetapi tidak semua) kasus. 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 terlihat 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 harus menghapus API sepenuhnya. Mengirim header agen pengguna kosong akan merusak banyak situs yang mengasumsikan bahwa header tersebut ada. Jadi, secara umum, yang dilakukan browser adalah menghapus beberapa detail darinya, lalu mempertahankannya agar tidak berubah sejak saat itu. (Anda dapat melihat hal ini terjadi di Safari, Chrome, dan Firefox.) Perlindungan terhadap sidik jari mendetail ini pada dasarnya berarti Anda tidak dapat lagi mengandalkan header agen pengguna yang akurat, dan jika Anda melakukannya, Anda harus menemukan 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 dapat dilaporkan. Misalnya, Firefox, Safari, dan Chrome semuanya membatasi nomor versi macOS yang dilaporkan hingga sepuluh (lihat Pembaruan terkait 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 123.45.67.89 imajiner yang berjalan di "Windows 20" imajiner 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: Chrome 123, di Windows. Namun, informasi pembantu (arsitektur chip, versi Windows, versi Safari yang ditiru, versi minor browser) tidak akan tersedia lagi setelah pembekuan.

Bandingkan dengan agen pengguna Chrome "saat ini" 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 menampilkan platform dan nomor versi Safari, serta memberikan versi OS di iOS, tetapi semua yang lain dibekukan. Jadi, Safari versi 1234.5.67 imajiner yang berjalan di 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 mencakup nomor versi Safari, yang belum tentu tersedia.

Perubahan pada agen pengguna yang dilaporkan telah diperdebatkan dengan sengit. https://github.com/WICG/ua-client-hints#use-cases summarises merangkum beberapa argumen dan alasan perubahan tersebut, dan Rowan Merewood memiliki slide presentasi dengan beberapa strategi untuk bermigrasi dari penggunaan agen pengguna untuk diferensiasi, dalam konteks proposal UA Client Hints yang dijelaskan lebih lanjut.

Fuzzing

Fuzzing adalah istilah dari praktik keamanan, yaitu API dipanggil dengan nilai yang tidak terduga dengan harapan API tersebut menangani nilai yang tidak terduga tersebut dengan buruk dan mengekspos 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 HTML yang dimasukkan dengan benar (sehingga 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 Meja Bobby Kecil). Fuzzing, atau pengujian fuzz, lebih tepat digunakan untuk upaya otomatis guna memberikan banyak input yang tidak valid atau tidak terduga ke API dan memeriksa hasil untuk kebocoran keamanan, error, atau penanganan buruk lainnya. Ini semua adalah contoh pemberian informasi yang tidak akurat dengan sengaja. Namun, di sini, hal ini dilakukan secara preemptive oleh browser (dengan membuat agen pengguna sengaja salah), untuk mendorong developer agar berhenti mengandalkan data tersebut.

Anjuran

Periksa codebase Anda untuk mengetahui apakah ada dependensi pada string agen pengguna (penelusuran navigator.userAgent kemungkinan akan menemukan sebagian besar kemunculan dalam kode sisi klien Anda, dan kode backend Anda kemungkinan akan mencari User-Agent sebagai header), termasuk dependensi Anda.
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.
Anda mungkin aman. Jika Anda hanya menggunakan nilai inti merek, versi utama, dan platform, nilai tersebut hampir pasti masih 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 menguji dengan versi browser mendatang tersebut sendiri melalui build pratinjau teknologi atau beta, tetapi Anda juga dapat menetapkan string agen pengguna kustom untuk 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 browser 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
}