Bersiaplah menghadapi akhir cookie pihak ketiga di Chrome. Uji situs Anda sekarang untuk menemukan kerusakan apa pun.

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. Banyak karakteristik yang mungkin berbeda antara konfigurasi Anda dan konfigurasi orang lain. Misalnya, Anda mungkin menggunakan jenis perangkat dan browser yang berbeda, memiliki ukuran layar yang berbeda, dan menginstal font yang berbeda. Jika saya menginstal {i>font<i} "Dejavu Sans" dan Anda tidak menginstal {i>font<i}, maka situs web apa pun dapat membedakan antara Anda dan saya dengan memeriksa {i>font<i} tersebut. Begitulah cara kerja sidik jari; 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 menggunakan karakteristik konfigurasi yang sudah lama ada dan tidak jelas dari konfigurasi pengguna untuk mencoba membedakannya dari sebanyak mungkin pengguna lain.

Mengapa pelacakan sidik jari mengganggu privasi pengguna

Ada beberapa kasus ekstrem ketika pelacakan sidik jari terhadap pengguna penting: misalnya deteksi penipuan. Namun, pelacakan sidik jari juga dapat digunakan untuk melacak pengguna di seluruh situs, dan pelacakan tersebut sering kali dilakukan tanpa sepengetahuan pengguna, atau, dalam beberapa kasus, berdasarkan izin yang tidak valid yang tidak memberikan informasi yang memadai kepada pengguna. Ketika hal itu dilakukan, pengguna tersebut akan sering merasa hal ini agak mengkhawatirkan dan merasa dikhianati.

Pelacakan sidik jari berarti menemukan cara untuk secara diam-diam membedakan antara satu pengguna dengan pengguna lain. Pelacakan sidik jari dapat digunakan untuk mengenali bahwa pengguna masih sama berada di situs yang sama, atau untuk mengenali pengguna yang sama di dua profil browser berbeda secara bersamaan. Artinya, pelacakan sidik jari dapat digunakan untuk melacak pengguna di seluruh situs. Metode pelacakan yang deterministik dan terbuka, seperti menyimpan cookie dengan ID khusus pengguna yang unik, hingga batas tertentu dapat diamati oleh pengguna dan dikontrol (dan modul sebelumnya menjelaskan beberapa pendekatan ini). Namun, pelacakan sidik jari lebih sulit dihindari secara persis karena tersembunyi; fitur ini bergantung pada karakteristik yang tidak berubah dan kemungkinan besar terjadi secara tidak terlihat. Inilah sebabnya mengapa fitur ini disebut "sidik jari". Terkadang sulit untuk mengubah sidik jari Anda, baik sidik jari digital maupun yang ada di ujung jari Anda.

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

Dalam praktiknya, sebagian besar developer dan sebagian besar bisnis tidak perlu menggunakan sidik jari. Jika aplikasi Anda mengharuskan pengguna untuk login, pengguna akan mengidentifikasi diri mereka kepada Anda, dengan persetujuan mereka, dan dengan cara yang memungkinkan mereka memilih untuk tidak ikut secara sepihak kapan pun mereka memilih. Tindakan ini adalah metode yang melindungi privasi untuk memahami pengguna mana yang login. Aplikasi Anda mungkin tidak mengharuskan pengguna untuk login sama sekali, yang bahkan lebih melindungi privasi pengguna (dan Anda kemudian mengumpulkan data yang dibutuhkan).

Anjuran

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

Ada baiknya juga membaca kebijakan privasi layanan dan dependensi pihak ketiga Anda untuk mencari indikasi penggunaan pelacakan sidik jari. Hal ini terkadang disebut sebagai "pencocokan probabilistik", atau sebagai bagian dari rangkaian teknik pencocokan probabilistik, bukan "pencocokan deterministik".

Cara kerja pelacakan sidik jari

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

Selain: pelacakan sidik jari pasif dan aktif

Ada perbedaan yang berguna di sini yang dapat digambarkan antara teknik pelacakan sidik jari pasif dan aktif. Teknik pelacakan sidik jari pasif adalah teknik yang menggunakan informasi yang diberikan ke situs secara default; teknik pelacakan sidik jari aktif adalah teknik yang secara eksplisit menginterogasi browser untuk mendapatkan informasi tambahan. Alasan perbedaan ini penting adalah browser dapat mencoba mendeteksi dan menangkap, atau mengurangi, teknik aktif. API dapat dibatasi atau di-gateway di belakang dialog yang meminta izin pengguna (sehingga memberi tahu pengguna bahwa mereka sedang 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 perkembangan informasi di jalan raya informasi, informasi tersebut diberikan ke semua situs. String agen pengguna adalah contohnya, dan kita akan melihat hal ini secara lebih mendetail lebih lanjut. Bagian ini dianggap bermanfaat dalam memberikan banyak informasi tentang browser, versi, dan sistem operasi pengguna, agar situs dapat memilih untuk menyajikan berbagai hal berdasarkan hal tersebut. Namun, hal ini juga meningkatkan jumlah informasi pembeda yang tersedia, yaitu informasi yang membantu mengidentifikasi satu pengguna dari pengguna lain; sehingga informasi tersebut semakin tidak tersedia lagi, atau setidaknya dibekukan sehingga tidak lagi membedakan. Jika hal yang Anda lakukan bergantung pada informasi ini—misalnya, jika Anda mengambil cabang kode yang berbeda bergantung pada agen pengguna—kode ini dapat rusak karena browser semakin membekukan atau menghentikan informasi tersebut. Pengujian adalah pertahanan terbaik di sini ( lihat nanti).

Selain: mengukur kemampuan sidik jari

Ukuran teknis untuk banyaknya informasi yang disediakan 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 pada banyak bit pada total, sehingga sesuatu yang tidak memiliki banyak daya pembeda (seperti sistem operasi yang Anda gunakan) hanya dapat menambah sedikitnya. HTTP Almanac menjelaskan bagaimana library pelacakan sidik jari yang ada mengotomatiskan proses penggabungan respons dari berbagai API yang berbeda ke dalam sebuah "hash", yang dapat mengidentifikasi hanya sekelompok kecil pengguna, bahkan mungkin hanya satu pengguna. Maud Nalpas membahasnya secara mendetail di video YouTube ini. Namun, singkatnya, bayangkan bahwa Anda akan melihat daftar teman dengan musik favorit, makanan favorit, dan bahasa yang mereka gunakan ... tetapi namanya sudah dihapus. Sangat mungkin bahwa daftar seseorang akan mengidentifikasi mereka secara unik di antara teman-teman Anda, atau setidaknya mempersempit daftar menjadi hanya beberapa orang. Beginilah cara kerja pelacakan sidik jari; daftar hal-hal yang Anda suka akan menjadi "hash". Dengan hash tersebut, identifikasi pengguna sebagai orang yang sama di dua situs berbeda yang tidak terhubung menjadi lebih mudah. Tujuannya adalah untuk melakukan pelacakan: mengakali keinginan pengguna akan privasi.

Apa yang dilakukan browser terhadap pelacakan sidik jari?

Yang penting, vendor browser sangat menyadari banyak cara berbeda yang dapat dilakukan situs (atau pihak ketiga yang disertakan dalam situs) untuk menghitung sidik jari pembeda bagi pengguna, atau bit informasi yang berbeda agar dapat 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 berkontribusi untuk membedakan Anda dengan saya, jika Anda dan saya menggunakan browser yang berbeda). Beberapa cara tidak sengaja dibuat agar dapat diberi sidik jari tetapi akhirnya menjadi 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 menjadi kontributor sidik jari baik setelah rilis, seperti rendering piksel yang tepat dari antialias font pada elemen kanvas. Ada banyak hal lainnya, dan setiap cara yang membedakan browser Anda dari milik saya, menambahkan entropi sehingga berpotensi berkontribusi pada cara untuk membedakan antara Anda dan saya, serta mengidentifikasi setiap individu seunik mungkin di berbagai situs web. https://amiunique.org memiliki daftar yang panjang (tapi jelas tidak komprehensif) fitur yang berkontribusi pada sidik jari, dan daftar ini terus bertambah jika pengguna tidak mengharapkan pengguna atau sidik jari tersebut

Tidak mendukung API tertentu yang canggih

Respons dari vendor browser terhadap semua pendekatan untuk menghitung sidik jari pengguna adalah menemukan cara untuk mengurangi jumlah entropi yang tersedia dari API ini. 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 privasi dan pelacakan sidik jari disebut sebagai alasan mengapa keduanya belum diimplementasikan. Hal ini jelas dapat memengaruhi aplikasi dan layanan: Anda tidak dapat menggunakan API sama sekali di browser yang tidak menerapkannya, dan hal ini dapat membatasi atau sepenuhnya menghentikan beberapa pendekatan hardware dari pertimbangan.

Gateway izin pengguna

Pendekatan kedua yang diambil oleh vendor browser adalah mencegah akses API atau data tanpa semacam izin pengguna yang eksplisit. Pendekatan ini sering kali dilakukan untuk alasan keamanan—situs tidak boleh mengambil gambar dengan webcam tanpa izin Anda. Namun, di sini, privasi dan keamanan dapat memiliki kepentingan yang sama. Mengidentifikasi lokasi seseorang tentu saja merupakan pelanggaran privasi, tetapi juga berkontribusi terhadap keunikan sidik jari. Mewajibkan izin untuk 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 tidak lagi dilakukan secara tidak terlihat. Inti dari sidik jari adalah untuk secara diam-diam membedakan pengguna satu sama lain. Jika siap untuk mengetahui bahwa Anda mencoba mengidentifikasi pengguna, Anda tidak memerlukan teknik pelacakan sidik jari: minta pengguna membuat akun dan login dengannya.

Menambahkan ketidakpastian

Pendekatan ketiga yang diambil dalam beberapa kasus adalah agar vendor browser "mengaburkan" respons dari API untuk membuatnya kurang terperinci dan kurang 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 yang merupakan identifikasi. Vendor browser dapat menggunakan pendekatan ini untuk data API yang disediakan untuk aplikasi web dan juga pihak ketiga. Contohnya adalah API pengaturan waktu yang sangat akurat yang digunakan untuk mengukur performa halaman dari window.performance.now(). Browser mengetahui nilai ini hingga akurasi mikrodetik, tetapi nilai yang ditampilkan sengaja dikurangi secara presisi dengan membulatkan ke batas 20 mikrodetik terdekat untuk menghindari penggunaannya dalam pelacakan sidik jari (dan juga untuk keamanan guna menghindari serangan pengaturan waktu). Tujuannya di sini adalah untuk memastikan API tetap berguna, tetapi untuk membuat respons kurang mengidentifikasi: pada intinya, untuk memberikan "kekebalan kelompok" dengan membuat perangkat Anda terlihat lebih seperti perangkat orang lain, bukan aneh bagi Anda. Safari menampilkan 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. Ini belum diimplementasikan di browser. Tujuannya adalah untuk memungkinkan API yang andal sekaligus menjaga privasi pengguna. Pelajari proposal anggaran privasi lebih lanjut.

Menggunakan lingkungan pengujian yang luas

Semua ini akan memengaruhi cara Anda membuat aplikasi dan layanan. Secara khusus, ada beragam respons dan pendekatan di seluruh browser dan platform di wilayah ini. Artinya, menguji pekerjaan Anda di berbagai lingkungan yang berbeda sangat penting. Tentu saja hal ini penting, namun masuk akal untuk mengasumsikan bahwa rendering HTML atau CSS akan konstan untuk mesin rendering tertentu, apa pun browser atau platform yang digunakan mesin tersebut (sehingga Anda mungkin tergoda untuk menguji hanya di satu browser berbasis Blink). Hal ini terutama tidak berlaku untuk penggunaan API karena browser yang menggunakan mesin rendering yang sama mungkin sangat berbeda dalam cara memperkuat permukaan API terhadap pelacakan sidik jari.

Anjuran

Periksa analisis dan audiens Anda sendiri untuk memandu kumpulan browser yang harus Anda prioritaskan saat melakukan pengujian.
Beberapa browser yang dapat diuji adalah Firefox, Chrome, Edge, Safari di desktop, Chrome dan Samsung Internet di Android, serta Safari di iOS. Ini memastikan Anda menguji di tiga mesin rendering utama (Gecko di Firefox, berbagai cabang 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, lakukan pengujian di perangkat tersebut. Beberapa platform hardware dapat tertinggal di belakang seluler dan desktop untuk update browser, yang berarti 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. Sertakan versi pra-rilis dan uji coba mendatang dari browser yang paling umum jika Anda bisa dan jika tersedia untuk Anda: pratinjau teknologi Safari, Canary Chrome, saluran Beta Firefox. Hal ini memberi Anda kesempatan terbaik untuk mengidentifikasi kerusakan API dan perubahan yang memengaruhi situs Anda sebelum perubahan tersebut memengaruhi pengguna Anda. Demikian pula, perhatikan lingkungan pengguna Anda dengan merujuk pada analisis yang Anda miliki. Jika basis pengguna Anda memiliki banyak ponsel Android lama, pastikan untuk menyertakannya dalam pengujian. Kebanyakan orang tidak memiliki hardware dan rilis terbaru yang cepat seperti yang dilakukan tim pengembangan.
Uji menggunakan profil bersih dan dalam mode penjelajahan samaran/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 dalam mode perlindungan sidik jari Firefox. Tindakan ini akan menampilkan dialog izin jika halaman Anda mencoba melakukan pelacakan sidik jari, atau akan menampilkan data fuzzed untuk beberapa API. Hal ini membantu Anda mengonfirmasi apakah pihak ketiga yang disertakan dalam layanan Anda menggunakan data yang dapat sidik jari, atau apakah layanan Anda sendiri bergantung pada data tersebut. Anda kemudian dapat mempertimbangkan apakah fuzzing yang disengaja membuatnya lebih sulit untuk melakukan yang Anda butuhkan. Pertimbangkan untuk melakukan koreksi yang sesuai untuk mendapatkan data tersebut dari sumber lain, melakukannya tanpa data tersebut, atau menggunakan data yang kurang terperinci.
Seperti yang telah dibahas sebelumnya dalam modul pihak ketiga, Anda juga harus mengaudit dependensi pihak ketiga untuk mengetahui apakah dependensi tersebut menggunakan teknik pelacakan sidik jari. Pelacakan sidik jari pasif sulit dideteksi (dan tidak mungkin jika pihak ketiga melakukannya di server mereka). Namun, mode pelacakan sidik jari mungkin menandai beberapa teknik pelacakan sidik jari, dan pencarian penggunaan navigator.userAgent atau pembuatan objek <canvas> yang tidak terduga juga dapat mengungkap beberapa pendekatan yang perlu diperhatikan lebih lanjut. Sebaiknya Anda juga mencari penggunaan istilah "pencocokan probabilistik" dalam materi pemasaran atau teknis yang menjelaskan pihak ketiga; terkadang hal ini dapat mengindikasikan penggunaan teknik pelacakan sidik jari.

Alat pengujian lintas browser

Sulit untuk mengotomatiskan pengujian kode Anda, dan hal-hal yang harus diperhatikan saat melakukan pengujian secara manual telah dijelaskan sebelumnya. Misalnya, apa yang terjadi saat Anda menolak izin ke situs untuk API apa pun yang coba diaksesnya, dan bagaimana hal tersebut ditampilkan kepada pengguna? Pengujian otomatis tidak dapat menilai apakah situs bertindak untuk membantu pengguna mempercayainya, atau sebaliknya, mendorong pengguna agar tidak mempercayainya, atau menganggap 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 pada versi "beta" dan "pratinjau" mendatang) dapat diotomatiskan, dan sebagian besar harus menjadi bagian dari rangkaian pengujian yang sudah ada. Hal yang perlu dipertimbangkan dengan alat pengujian otomatis, saat bekerja dengan cakupan platform API, adalah sebagian besar browser memungkinkan beberapa tingkat kontrol atas API dan fitur yang tersedia. Chrome melakukannya melalui tombol command line, seperti halnya Firefox, dan memiliki akses ke setelan ini dalam penyiapan alat pengujian akan memungkinkan Anda menjalankan pengujian tertentu dengan API yang dinonaktifkan atau diaktifkan. (Lihat, misalnya, plugin peluncuran browser Cypress dan parameter launch.args puppeteer untuk mengetahui cara menambahkan tanda browser saat diluncurkan.)

Hanya mengandalkan string agen pengguna untuk informasi yang tidak akurat

Sebagai contoh lain, browser sejak awal web mengirim deskripsi tentang dirinya sendiri dengan setiap permintaan di header Agen Pengguna HTTP. Selama hampir lama, orang-orang telah mendesak developer web untuk tidak menggunakan konten header agen pengguna guna menyajikan konten yang berbeda ke browser yang berbeda, dan selama itu developer web telah melakukannya, dengan sejumlah alasan yang jelas di beberapa kasus. Karena browser tidak ingin disisihkan sebagai pengalaman yang kurang optimal oleh situs, hal ini menyebabkan setiap browser berpura-pura menjadi browser lain, dan string agen pengguna terlihat seperti ini:

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 waktu yang sama dengan astronot pertama yang naik ke Stasiun Luar Angkasa Internasional lebih dari dua dekade yang lalu. String agen pengguna merupakan sumber entropi yang kaya untuk pelacakan sidik jari, tentunya, dan untuk mengurangi kemampuan pelacakan sidik jari tersebut, produsen browser telah membekukan header agen pengguna atau sedang berupaya melakukannya. Ini adalah contoh lain dari mengubah data yang disediakan API tanpa harus menghapus API sepenuhnya. Mengirim header agen pengguna kosong akan merusak situs yang tak terhitung jumlahnya yang mengasumsikan bahwa situs tersebut ada. Jadi secara umum, yang dilakukan browser adalah menghapus sebagian detail darinya, lalu tidak mengubah apa pun sejak saat itu. (Anda dapat melihat hal ini terjadi di Safari, Chrome, dan Firefox.) Perlindungan terhadap pelacakan sidik jari mendetail ini pada dasarnya berarti Anda tidak lagi dapat mengandalkan akurasi header agen pengguna. Jika Anda melakukannya, penting untuk 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 angka yang lebih lama tetapi tidak berubah mungkin dilaporkan. Misalnya, Firefox, Safari, dan Chrome membatasi nomor versi macOS yang dilaporkan ke sepuluh (lihat Memperbarui pengurangan string agen pengguna untuk diskusi selengkapnya di sini). Detail persis tentang cara Chrome berencana mengurangi data dalam string agen pengguna tersedia di Pengurangan Agen Pengguna, tetapi, singkatnya, Anda dapat memperkirakan bahwa nomor versi browser yang dilaporkan hanya akan berisi versi utama (sehingga nomor versi akan terlihat seperti 123.0.0.0, meskipun browser adalah versi 123.10.45.108), dan versi OS akan memiliki satu nomor versi yang tidak berubah dan tidak akan dibebaskan. Jadi Chrome versi imajiner 123.45.67.89 yang berjalan pada "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: yaitu Chrome 123, di Windows. Namun, informasi anak perusahaan (arsitektur chip, versi Windows, versi Safari yang ditiru, dan versi minor browser) tidak akan tersedia lagi setelah pembekuan.

Bandingkan ini dengan agen pengguna Chrome "saat ini" pada platform yang berbeda:

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

dan terlihat bahwa satu-satunya hal 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 yang lainnya dibekukan. Jadi Safari versi imajiner 1234.5.67 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 imajinernya 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, di iOS atau macOS) tersedia, dan iOS Safari masih memberikan nomor versi iOS; tetapi banyak informasi tambahan yang tersedia sebelumnya telah dibekukan. Yang penting, nomor ini termasuk nomor versi Safari, yang belum tentu tersedia.

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

{i>Fzzing<i}

Fuzzing adalah istilah dari praktik keamanan, ketika API dipanggil dengan nilai yang tidak terduga dengan harapan dapat 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). Developer back-end akan mengetahui injeksi SQL, ketika kueri database yang tidak memvalidasi input pengguna dengan benar akan mengekspos masalah keamanan (seperti yang diilustrasikan oleh xkcd dengan Little Bobby Tables). Fuzzing, atau pengujian fuzz, lebih tepat digunakan untuk upaya otomatis dalam memberikan berbagai input yang tidak valid atau tidak terduga ke API dan memeriksa hasilnya terkait kebocoran keamanan, error, atau penanganan buruk lainnya. Semua ini adalah contoh tindakan yang sengaja memberikan informasi tidak akurat. Namun, di sini hal tersebut dilakukan secara preemtif oleh browser (dengan membuat agen pengguna sengaja salah melakukan kesalahan), untuk mendorong developer agar tidak mengandalkan data tersebut.

Anjuran

Periksa codebase Anda untuk mengetahui apakah ada ketergantungan pada string agen pengguna (penelusuran untuk navigator.userAgent kemungkinan akan menemukan sebagian besar kejadian dalam kode sisi klien, 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 menemukan dependensi pengganti, atau bekerja dengan dependensi upstream dengan mengajukan masalah atau memeriksanya bersama update tersebut). Terkadang diferensiasi browser diperlukan untuk mengatasi bug, tetapi agen-pengguna akan semakin tidak menjadi cara untuk melakukannya setelah dibekukan.
Anda mungkin aman. Jika Anda hanya menggunakan nilai inti merek, versi utama, dan platform, hampir dipastikan bahwa nilai tersebut masih akan tersedia dan benar dalam string agen pengguna.
MDN menjelaskan cara yang baik untuk menghindari ketergantungan pada string agen pengguna ("browser sniffing"), yang utamanya adalah deteksi fitur.
Jika Anda sangat bergantung pada string agen pengguna (meskipun menggunakan beberapa nilai inti yang tetap berguna), sebaiknya lakukan pengujian dengan agen pengguna mendatang yang akan ada dalam rilis browser baru. Anda dapat melakukan pengujian dengan versi browser mendatang tersebut sendiri menggunakan 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 diterima dari pengguna.

Petunjuk Klien

Salah satu proposal utama untuk memberikan informasi ini adalah Petunjuk Klien Agen Pengguna, meskipun tidak didukung di semua browser. Browser yang mendukung akan meneruskan tiga header: Sec-CH-UA, yang memberikan merek dan nomor versi browser; Sec-CH-UA-Mobile, yang menunjukkan apakah permintaan berasal dari perangkat seluler; dan Sec-CH-UA-Platform, yang menyebutkan sistem operasi. (Mengurai header ini kurang mudah daripada yang terlihat karena header tersebut merupakan Header Terstruktur dan bukan string sederhana, dan hal ini diterapkan oleh browser yang mengirimkan nilai "trik", yang akan ditangani dengan tidak benar jika tidak diurai dengan benar. Ini, seperti sebelumnya, contoh “pengujian fuzz” yang dilakukan secara preemtif oleh browser. Developer yang menggunakan data ini harus menanganinya dengan benar karena data didesain sehingga penguraian yang tidak tepat atau lambat kemungkinan akan memberikan hasil yang buruk, seperti menampilkan merek yang tidak ada, atau string yang tidak dapat ditutup 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
}