navigator.cpuPerformance di Chrome 152: sinyal baru untuk deteksi anti-deteksi dan pengambilan data

25 Agustus 2026, Chrome 152 telah tiba di saluran stabil di Windows, Mac, Linux, ChromeOS, dan Android — dan membawa properti navigator.cpuPerformance. Satu angka dari 0 hingga 4 yang dibaca situs secara sinkron, tanpa izin dan tanpa satu siklus perhitungan pun. Ini dirancang sebagai petunjuk untuk panggilan video dan streaming: perangkat lemah diberikan 240p tanpa blur latar belakang, perangkat kuat — 1080p dengan efek. Dua minggu setelah rilis, industri pengambilan data membahas hal lain: sistem anti-bot kini memiliki sinyal murah dan stabil tentang perangkat keras yang menjalankan browser Anda.

Apa yang sebenarnya diberikan oleh browser

Properti ini tidak mengembalikan gigahertz atau model prosesor, tetapi "kelas" kinerja. Menurut catatan penjelasan WICG, ada empat tier ditambah nol:

• 0 — klasifikasi perangkat gagal;
• 1 — hampir tidak layak untuk tugas berat;
• 2 — lemah, tetapi berfungsi;
• 3 — nyaman untuk skenario biasa;
• 4 — berkinerja tinggi, dengan cadangan untuk multitasking.

Spesifikasi secara langsung melarang pengungkapan vendor, nama model, dan jumlah inti, mengharuskan HTTPS, dan menetapkan tujuan privasi: setiap kelas harus mencakup proporsi signifikan dari perangkat di internet — sekitar ratusan model CPU yang berbeda, agar nilai tidak mempersempit audiens menjadi satuan.

Implementasi nyata di Chromium ternyata lebih sederhana daripada spesifikasi. Dalam analisis Zyte, ditunjukkan bahwa klasifikasi terutama bergantung pada jumlah inti logis dan tabel peningkatan dan penurunan yang tersemat: frekuensi sama sekali tidak diperhitungkan, meskipun spesifikasi mengizinkannya. Peningkatan diberikan kepada AMD Ryzen, inti Intel Gracemont, Apple silicon, dan Intel Core Ultra; penurunan — Intel Atom dan prosesor era Core 2. Keterikatan kasar terlihat seperti ini: mesin satu inti dan sangat lemah masuk ke tier pertama, dua–empat inti memberikan tier kedua, empat–sepuluh inti atau chip efisiensi energi modern — tier ketiga, dan delapan atau lebih inti pada Core Ultra, seri Apple M, dan semua yang memiliki sepuluh inti atau lebih — tier keempat.

Mengapa ini adalah sinyal deteksi, bukan sekadar byte entropi lainnya

Nilai itu sendiri lemah: lima opsi — sekitar 2,3 bit entropi, lebih sedikit daripada yang diberikan oleh bahasa antarmuka. Bahaya terletak pada tiga properti lainnya.

Ini gratis. Untuk mendapatkan kecepatan eksekusi JS yang sebenarnya dengan timing, skrip deteksi perlu menggunakan prosesor selama puluhan milidetik, dan ini terlihat di profiler. Di sini — pembacaan properti secara sinkron, tanpa biaya, tanpa jejak.

Ini stabil. Nilai tidak tergantung pada beban mesin pada saat pemeriksaan: ini adalah kelas perangkat keras, bukan pemanfaatan saat ini. Antara sesi, restart, dan perubahan IP, ia tetap sama — artinya, cocok sebagai bagian dari pengidentifikasi profil yang tahan lama.

Ini diperiksa untuk konsistensi. Ini yang utama. Mesin anti-bot modern jarang memblokir berdasarkan satu bidang — mereka mencari kontradiksi internal dalam set. Perangkat yang mengklaim tier keempat harus mengonfirmasi dengan navigator.hardwareConcurrency yang kredibel, navigator.deviceMemory yang masuk akal, string GPU-renderer yang modern, dan kecepatan eksekusi JS yang sesuai. Profil yang memberikan tier 4 dan pada saat yang sama menjalankan benchmark sebagai mesin virtual dua inti, dapat terdeteksi dengan pemeriksaan silang yang sepele.

Secara terpisah, ini hampir menciptakan batasan antara "data center" dan "pengguna nyata": instans cloud tipikal dengan dua vCPU secara jujur melaporkan tier pertama, sementara laptop dan ponsel konsumen berada di tier ketiga–keempat. Bagi scraper yang berjalan di VPS murah dalam mode headless dan pada saat yang sama mengaku sebagai Chrome biasa di Windows, ini adalah kombinasi yang tidak menguntungkan.

Apa bedanya dengan hardwareConcurrency, yang selalu ada

Pertanyaan yang wajar: jumlah inti sebelumnya dibaca situs melalui navigator.hardwareConcurrency, dan jumlah memori melalui navigator.deviceMemory. Apa yang berubah?

Yang berubah adalah keterkaitan. hardwareConcurrency adalah angka mentah, dan telah dipalsukan sejak lama dan di mana-mana: mengganti delapan dengan tiga puluh dua, dan masalah selesai. cpuPerformance adalah ukuran turunan, dihitung oleh browser itu sendiri berdasarkan tabel yang tersemat. Begitu dua bidang muncul dalam set, satu dari yang lain dihitung, setiap modifikasi sepihak merobek hubungan antara keduanya. Menetapkan empat inti, tetapi tier tetap keempat — menurut logika implementasi, kombinasi ini memerlukan baik Apple silicon, Core Ultra, atau sepuluh inti; berarti, baik jumlah inti yang salah, atau string GPU yang salah, dan detektor cukup memperhatikan fakta ketidakcocokan, tanpa mencari tahu di mana kebohongan itu.

Itulah sebabnya daftar periksa lama "bidang mana yang harus dipalsukan dalam profil" menjadi usang tidak hanya pada satu poin, tetapi pada seluruh blok: pertanyaan yang benar sekarang bukan "apa yang harus dipalsukan", tetapi "konfigurasi perangkat keras yang konsisten apa yang kita dapatkan secara keseluruhan".

Siapa yang paling terkena dampak

Hanya Chromium — dan ini bukan keadaan yang meringankan. WebKit mengambil posisi "menentang" terhadap API ini, Mozilla tidak menyatakan posisi publik, jadi di Safari dan Firefox, properti ini kemungkinan besar tidak akan ada. Namun, sebagian besar otomatisasi produksi — Playwright, Puppeteer, nodriver, Patchright, browser berbasis agen — dibangun di atas Chromium. Artinya, sinyal ini datang tepat ke ceruk di mana ia paling tidak diharapkan.

Kontradiksi ini paling menyakitkan bagi emulasi profil seluler. Jika profil anti-deteksi mengklaim dirinya sebagai smartphone Android, dan cpuPerformance di bawahnya menjawab "4", karena browser secara fisik dijalankan di desktop dengan Ryzen, — ini bukan ketidakakuratan kecil, tetapi pasangan sinyal yang saling eksklusif. Hal yang sama berlaku untuk skenario farm, di mana puluhan profil dengan "perangkat" yang berbeda hidup di satu mesin host dan karena itu memberikan tier yang identik.

Apa yang berubah untuk tumpukan parsing

Beberapa konsekuensi praktis bagi mereka yang menjalankan browser headless dalam jumlah besar.

• Kontainer mewarisi host. Browser dalam docker melihat inti mesin host, bukan batas cgroup, — artinya, sepuluh kontainer di satu server besar akan memberikan sepuluh tier maksimum yang sama. Keragaman profil yang Anda gambarkan dengan cermat dalam user-agent, tidak ada di tingkat perangkat keras.
• VPS murah kini lebih terlihat. Dua vCPU — ini adalah tier pertama, dan tier pertama di Chrome desktop di Windows jarang ditemui pada orang hidup. Sebelumnya server lemah hanya lambat; sekarang ia juga teridentifikasi.
• Sinyal gratis untuk situs. Pemeriksaan berat seperti benchmark timing situs dilakukan secara selektif, karena mereka menghabiskan waktu pengguna. Pembacaan properti tidak memerlukan biaya, sehingga akan ditambahkan ke set dasar bahkan oleh situs yang sebelumnya hanya bergantung pada reputasi IP dan header.
• Ini akan berdekatan dengan Compute Pressure. Dalam catatan rilis Chrome secara langsung menyarankan untuk menggabungkan API baru dengan Compute Pressure API — artinya, kombinasi "kelas perangkat keras ditambah beban yang diamati" pada awalnya dirancang sebagai skenario standar, dan anti-bot tidak perlu menciptakan apa pun.

Secara terpisah, perlu untuk meninjau asumsi bahwa cukup untuk sekali mengumpulkan profil "baik" dan menggunakannya selama bertahun-tahun. Browser menambahkan properti semacam itu tanpa pengumuman kepada pengguna akhir: antara rilis Chrome 152 dan analisis publik pertama, ada minggu-minggu di mana profil dengan tenang memberikan bidang baru, tanpa curiga. Memeriksa set bidang sebaiknya dilakukan sekali dalam siklus rilis, bukan setahun sekali.

Apa yang harus dilakukan secara praktis

1. Ambil nilai saat ini. Di konsol profil: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory, dan string renderer WebGL. Catat dalam kelompok empat, bukan satu per satu — Anda akan diperiksa berdasarkan kombinasi tersebut.
2. Periksa tier dengan legenda profil. Legenda seluler — tier pertama–ketiga, laptop anggaran — tier kedua–ketiga, desktop flagship — tier keempat. Tier 4 yang mengklaim sebagai Android lama atau tier 1 yang mengklaim sebagai MacBook di seri M sama-sama mencurigakan.
3. Jangan ubah properti secara langsung. Penggantian melalui Object.defineProperty dapat terdeteksi melalui jejak penggantian getter dan perbedaan dengan kecepatan eksekusi yang sebenarnya. Jika ingin mengubah, lakukan di tingkat build browser atau melalui mekanisme bawaan.
4. Ingat tentang legal override. Chrome memberikan pengguna kontrol di pengaturan (Performance → Speed → Override CPU performance tier), dan kepada administrator — kebijakan perusahaan. Ini berguna untuk diketahui dari dua sisi: nilai dapat menjadi "nyata", tetapi juga ditetapkan secara manual, dan override yang sama secara massal pada kumpulan profil menjadi tanda itu sendiri.
5. Pisahkan profil berdasarkan perangkat keras yang berbeda. Jika semua profil Anda berada di satu server, tier mereka akan sama — terlepas dari perangkat apa yang mereka gambarkan. Ini adalah kasus di mana koleksi beberapa mesin dengan konfigurasi berbeda secara jujur menyelesaikan masalah, sementara patch tidak.

Lebih lanjut tentang sinyal terkait dari keluarga yang sama — dalam analisis sidik jari berdasarkan volume memori perangkat, dan untuk browser stealth yang bekerja dengan properti semacam itu secara default, ada benchmark nodriver, Camoufox, dan Patchright.

Di mana proxy di sini

Secara langsung: proxy tidak memperbaiki sidik jari browser. cpuPerformance dihitung di sisi klien, dan tidak ada IP yang dapat mengubahnya. Namun, anti-bot membuat keputusan berdasarkan total lapisan, dan biasanya di persimpangan lapisan itulah kegagalan terjadi.

Rantai tipikal di mana setup murah jatuh terlihat seperti ini: IP dari jaringan hosting yang dikenal, tier pertama prosesor, tanda-tanda headless dalam JS — tiga sinyal independen, masing-masing dapat diterima secara terpisah, tetapi bersama-sama mereka membentuk keputusan yang jelas. Menghilangkan lapisan jaringan dari jumlah ini lebih murah dan lebih andal daripada berjuang dengan bidang browser: dengan IP residensial, permintaan terlihat seperti lalu lintas dari penyedia rumah biasa, dan hipotesis "data center" pada detektor hilang dengan sendirinya. Untuk legenda seluler, logika yang sama berlaku — proxy seluler harus mendukung profil seluler, jika tidak, kontradiksi hanya berpindah dari prosesor ke jaringan.

Singkatnya

Chrome 152 tidak hanya menambahkan sidik jari baru, tetapi juga baris baru dalam tabel pemeriksaan silang. Dua bit lebih sedikit tidak mengungkapkan siapa pun — yang mengungkapkan adalah ketidakkonsistenan: perangkat yang diklaim harus sesuai dengan kelas prosesor, jumlah memori, kartu grafis, kecepatan eksekusi, dan jaringan dari mana permintaan datang. Audit profil minggu ini sebaiknya dimulai dengan satu baris di konsol dan pertanyaan "apakah perangkat keras semacam itu benar-benar ada untuk siapa kami mengaku?".