Uji Sidik Jari Peramban: Periksa Keunikan Canvas, WebGL, Audio & Perangkat

Penilaian Mendalam Sidik Jari & Lingkungan

Uji Sidik Jari Peramban

Sidik jari peramban membuat ID perangkat unik dengan mengumpulkan karakteristik perangkat keras, font, dan rendering grafis.

SHA-256 Hash Memeriksa...
Status Manipulasi
Memeriksa...
Deteksi Bot
Memeriksa...
Kebocoran WebRTC
Memeriksa...
Skor Keunikan
Memeriksa...

Perangkat Keras & Lingkungan Dasar

Memeriksa...

                            

Rendering Grafis

Memeriksa...

                            

Peramban & Keamanan

Memeriksa...

                            

Sidik Jari Mikro Lanjutan

Memeriksa...

                            

Jaringan & WebRTC

Memeriksa...

                            

Probe Kemampuan & Lingkungan API

Memeriksa...

                            

Ringkasan Penilaian Sidik Jari

Memeriksa...
Memeriksa...
Analisis Sidik Jari Tumpukan Jaringan Lintas Lapisan

Gabungkan keunikan Canvas/WebGL di sisi peramban dengan sidik jari paket TCP/TLS/QUIC di sisi server untuk evaluasi pelacakan spektrum penuh.

Uji Sidik Jari Jaringan →

Pertanyaan yang Sering Diajukan Tentang Sidik Jari Peramban

Pelajari cara kerja sidik jari peramban, deteksi kontradiksi lintas lapisan, keterbatasan peramban anti-deteksi, dan fakta mode penyamaran.

Mengubah hanya header User-Agent Anda tidak hanya gagal menyamarkan peramban Anda, tetapi juga menciptakan "kontradiksi lintas lapisan" yang mencolok yang memicu deteksi penipuan tingkat lanjut: Pertama, ketidakcocokan lapisan aplikasi vs. tumpukan transport: jika Anda menyetel UA peramban Windows ke iPhone Safari, header HTTP Anda mengklaim seluler Apple, namun paket TCP SYN Anda menyajikan tanda tangan kernel Windows (tanpa opsi TS dan urutan opsi MSS, NOP, WS, NOP, NOP, SACK_PERM), yang secara langsung bertentangan dengan urutan 8 opsi Apple. Kedua, invarian protokol HTTP/3 dan HTTP/2: mesin Chromium, WebKit, dan Gecko berbeda dalam cara yang tidak dapat dipalsukan, seperti pemetaan jenis aliran searah HTTP/3 (Chromium: 2:control,10:encoder vs. WebKit: 2:control,6:encoder) dan urutan pseudo-header HTTP/2 (Chromium: m,a,s,p vs. non-Chromium: m,s,a,p). Mengubah string UA hanya memodifikasi header superfisial sambil meninggalkan lapisan transport yang lebih rendah dalam konflik langsung.

💡 Pelajari lebih lanjut tentang tanda tangan tingkat transport dalam Analisis Anonimitas Proksi kami.

Peramban anti-deteksi biasanya menambal Chromium atau menyuntikkan hook JavaScript untuk menimpa properti navigator, menyuntikkan derau ke keluaran Canvas/WebGL, dan mensimulasikan konteks layar atau audio. Namun, sistem deteksi tingkat lanjut dengan mudah menemukan artefak khas: Pertama, manipulasi prototipe dan fungsi asli: proksi JS dan monkey-patching API sering mengubah Function.prototype.toString, Object.getOwnPropertyDescriptor, dan rantai warisan prototipe. Kedua, invarian GPU dan shader: meskipun derau yang disuntikkan mengubah hash gambar yang dirender, presisi titik mengambang GPU fisik dan pola rasterisasi shader tetap tetap; derau buatan sering kali membentuk tanda tangan yang mudah diidentifikasi itu sendiri. Ketiga, tumpukan jaringan yang mendasarinya tidak tersentuh: sebagian besar peramban anti-deteksi hanya beroperasi pada tingkat JavaScript dan tidak mensimulasikan karakteristik jabat tangan TCP/TLS sistem operasi host.

Tidak. Mode penyamaran dirancang secara eksklusif untuk mencegah "jejak penjelajahan lokal di perangkat Anda sendiri," bukan untuk mencegah "identifikasi jarak jauh oleh situs web." Saat jendela penyamaran ditutup, cookie lokal, localStorage, dan riwayat dibuang. Namun, sidik jari peramban bekerja dengan mengukur atribut perangkat keras dan perangkat lunak fisik melalui JavaScript (termasuk rendering grafis GPU, presisi shader WebGL, font terpasang, respons osilator audio, konkurensi CPU, dan kedalaman warna). Karena perangkat keras fisik, driver grafis, dan mesin rendering peramban Anda identik dalam mode penyamaran, hash sidik jari yang dihasilkan oleh server jarak jauh tidak berubah.

Ini bukan positif palsu—ini mencerminkan arsitektur mendasar iOS: Pertama, Pedoman Apple App Store mewajibkan bahwa semua peramban web di iOS/iPadOS (termasuk Chrome, Edge, Firefox, dan Opera) harus menggunakan mesin rendering WKWebView / WebKit Apple dan dilarang menjalankan mesin Chromium Blink atau Gecko. Kedua, verifikasi protokol: pada iOS, Chrome (CriOS) menunjukkan pemetaan aliran HTTP/3 eksklusif WebKit (2:control,6:encoder), sama sekali berbeda dari Chromium di desktop atau Android (2:control,10:encoder). Chrome di iOS secara efektif merupakan peramban WebKit dengan antarmuka pengguna Google, dan mengidentifikasinya sebagai WebKit secara teknis akurat.

Ya, namun di bawah kondisi ketat dan batas yang jelas, dan ini sepenuhnya berbeda dari autentikasi pengguna. Pemulihan identitas di situs ini menggunakan model pembobotan empat lapisan: 1) Lapisan Jangkar Perangkat Keras (string model GPU, latensi dasar audio, jumlah perangkat media); 2) Lapisan Entropi Tinggi Sistem (daftar font terpasang, suara sintesis ucapan); 3) Lapisan Dinamis Peramban (hash rendering Canvas, hash komputasi AudioContext); 4) Lapisan Lingkungan Tampilan (resolusi layar, zona waktu). Setelah menggabungkan keempat lapisan, kedua kondisi berikut harus dipenuhi secara bersamaan untuk mengklaim identitas yang ada: skor total harus melewati ambang batas, dan setidaknya satu fitur inti berentropi tinggi harus cocok (daftar font, daftar sintesis suara, Canvas, atau Audio). Kondisi kedua ini disengaja: atribut publik berentropi rendah seperti model GPU, zona waktu, dan resolusi layar berulang secara luas di seluruh batch perangkat keras yang identik, dan tidak ada kombinasinya yang diizinkan untuk menetapkan identitas dengan sendirinya; versi sebelumnya tanpa gerbang ini bisa salah mencocokkan dua orang asing yang berbeda. Selain itu, lapisan jangkar perangkat keras memberlakukan veto ketat: jika core logis CPU berbeda, memori berbeda lebih dari 4GB, latensi dasar audio berbeda lebih dari 0,005 detik, atau titik sentuh maksimal berbeda, kandidat langsung diklasifikasikan sebagai mesin yang berbeda dan dikeluarkan sebelum penilaian.

⚠ Tujuan dari mekanisme ini adalah untuk menyelaraskan pengamatan berulang secara konsisten dari perangkat yang sama, bukan untuk membuktikan siapa Anda—ini bukan autentikasi identitas dan tidak boleh digunakan untuk tujuan tersebut.

Keduanya adalah "fitur sistem berentropi tinggi" yang tidak memerlukan izin dan berjalan sepenuhnya tanpa suara tanpa artefak halaman yang terlihat. Sidik Jari AudioContext: Merender buffer audio secara offline di OfflineAudioContext dengan mengalirkan Oscillator melalui DynamicsCompressor, membaca kembali nilai sampel floating-point dan melakukan hashing. Grafik pemrosesan audio yang sama menghasilkan sedikit perbedaan bit terkecil di berbagai implementasi peramban, pustaka matematika, dan backend floating-point, semuanya tanpa memutar suara yang dapat didengar. Tepat di sebelahnya tetapi benar-benar independen adalah AudioContext.baseLatency: nilai ini mencerminkan ukuran buffer output kartu audio yang diatur oleh driver audio dan perangkat keras; sistem kami memperlakukannya sebagai jangkar perangkat keras (perbedaan melebihi 0,005 detik langsung mendiskualifikasi kecocokan) bukan hash identitas—mereka memiliki asal yang berbeda dan tidak boleh dicampuradukkan. Sidik Jari Enumerasi Font: Mengukur kotak batas string uji yang dirender dengan setiap font dari daftar kandidat terhadap font fallback default; perbedaan menunjukkan bahwa font terpasang. Font yang terpasang mencerminkan perangkat lunak yang terpasang di mesin Anda (paket seperti Office, Adobe, alat dev, dan paket IME membawa font tersendiri), menjadikan daftar font biasanya merupakan metrik pembeda tertinggi tunggal di seluruh kumpulan fitur.

💡 Perbedaan stabilitas berasal dari apa yang memicu perubahan: hash Canvas dan Audio bergeser setiap kali versi peramban diperbarui (karena perubahan mesin rendering dan pustaka matematika), sedangkan daftar font hanya berubah saat Anda memasang atau menghapus perangkat lunak—itulah sebabnya daftar font memiliki bobot tertinggi.

MSS (Maximum Segment Size) adalah muatan maksimum per segmen TCP yang diumumkan selama jabat tangan TCP. Server kami membacanya langsung dari paket SYN Anda tanpa memerlukan perangkat lunak atau konfigurasi klien apa pun. Menambahkan kembali overhead header IP dan TCP akan merekonstruksi MTU tautan: tambahkan 40 byte untuk IPv4, tambahkan 60 byte untuk IPv6. Nilai umum membawa arti teknis yang berbeda: 1500 menunjukkan Ethernet standar atau tautan cloud bare-metal; 1492 menunjukkan broadband PPPoE (koneksi perumahan DSL / FTTH), di mana header PPPoE 8-byte mengurangi muatan; kurang dari atau sama dengan 1420 menunjukkan lapisan enkapsulasi tambahan, biasanya dari terowongan VPN seperti WireGuard / Tailscale atau proksi asal CDN.

⚠ Poin kuncinya adalah: MSS mendeskripsikan tautan jaringan, bukan perangkat Anda. Ini hanya dapat menunjukkan bahwa "enkapsulasi ada di sepanjang jalur ini," dan dengan sendirinya tidak membuktikan penggunaan proksi—PPPoE perumahan juga bukan 1500. Yang memberikan nilai diagnostik nyata adalah kontradiksi: ketika lokasi yang diklaim oleh lapisan aplikasi terus-menerus bertentangan dengan atribut tautan transport (seperti mengklaim koneksi langsung lokal sementara MSS secara konsisten berada dalam rentang terowongan), itu merupakan sinyal yang bermakna. Lihat Analisis Anonimitas Proksi untuk rincian lebih lanjut.

Ini adalah jenis kesalahan yang kami perlakukan dengan tingkat keparahan tertinggi (penggabungan positif palsu), dan kami menjaganya dengan tiga garis pertahanan berurutan—jika salah satu pertahanan terpicu, pemulihan ditolak. Pertama, Isolasi Bucket Keras: Kandidat identitas dipartisi secara ketat berdasarkan platform OS dan inti mesin peramban, dengan nol perbandingan lintas bucket—artinya dua mesin peramban yang berbeda pada mesin fisik yang sama, bahkan dengan parameter perangkat keras yang identik, tidak akan pernah digabungkan menjadi satu identitas. Kedua, Veto Jangkar Perangkat Keras: Jumlah core logis CPU, kapasitas RAM (toleransi 4GB), latensi dasar audio (toleransi 0,005 detik), dan titik sentuh maksimal: jika kedua belah pihak melaporkan nilai yang bertentangan melampaui toleransi, kandidat dibuang sebelum penilaian. Ketiga, Gerbang Penerimaan Fitur Inti: Bahkan dengan skor gabungan yang tinggi, jika kandidat cocok dengan nol fitur inti berentropi tinggi (font, suara, Canvas, Audio), klaim ditolak—gerbang ini secara khusus mencegah sekelompok atribut publik berentropi rendah mengumpulkan skor tinggi yang tidak sah.

⚠ Keterbukaan jujur: Saat ini kami tidak memiliki tingkat penggabungan salah yang diukur dari lalu lintas produksi organik untuk dipublikasikan. Metrik ini membutuhkan lalu lintas langsung longitudinal jangka panjang untuk dihitung secara akurat; menyatakan persentase apa pun sebelum mencapai ukuran sampel yang memadai adalah tidak jujur.