← Bloga geri dön

Chrome 152'de navigator.cpuPerformance: Antidetekt ve Scraping için Yeni Algılama Sinyali

25 Ağustos 2026 Chrome 152, navigator.cpuPerformance özelliğini getirdi — bu özellik, bir sayıya 0 ile 4 arasında işlemci sınıfını bildiriyor. Bu sadece 2,3 bit entropi, ancak ücretsiz okunuyor, oturumlar arasında değişmiyor ve çekirdek sayısı, bellek ve GPU ile tutarlılık açısından kontrol ediliyor. Kimlerin bunu en çok etkilediğini ve şu anda profilinizde neyi kontrol etmeniz gerektiğini inceleyelim.

📅21 Eylül 2026
Chrome 152'de navigator.cpuPerformance: Antidetekt ve Scraping için Yeni Algılama Sinyali

25 Ağustos 2026'da Chrome 152, Windows, Mac, Linux, ChromeOS ve Android için kararlı kanala geldi ve navigator.cpuPerformance özelliğini getirdi. Site tarafından senkron olarak, izinler olmadan ve tek bir hesaplama döngüsü olmadan okunan 0 ile 4 arasında bir sayı. Bu özellik, video aramaları ve yayınlar için bir ipucu olarak tasarlandı: zayıf bir cihaza 240p verirken, güçlü bir cihaza 1080p ile efektler sunmak. Yayınlandıktan iki hafta sonra, veri madenciliği endüstrisi başka bir konuyu tartışıyor: anti-bot sistemlerinin, tarayıcınızın çalıştığı donanım hakkında ucuz ve kararlı bir sinyali var.

Tarayıcı tam olarak ne veriyor

Bu özellik, gigahertz veya işlemci modelini değil, bir "performans sepetini" döndürüyor. WICG açıklama notuna göre dört artı sıfır seviyeleri:

  • 0 — cihazın sınıflandırılması mümkün olmadı;
  • 1 — ağır görevler için neredeyse kullanılamaz;
  • 2 — zayıf ama çalışır durumda;
  • 3 — normal senaryolar için rahat;
  • 4 — yüksek performanslı, çoklu görev için yeterli.

Spesifikasyon, satıcıyı, model adını ve çekirdek sayısını ifşa etmeyi doğrudan yasaklıyor, HTTPS gerektiriyor ve gizlilik hedefi koyuyor: her sepet, internetteki cihazların önemli bir kısmını kapsamalı — yüzlerce farklı CPU modeline kadar, böylece değer, izleyici kitlesini tek hanelere indirmemeli.

Gerçek uygulama, Chromium'da spesifikasyondan daha basit oldu. Zyte'nin analizinde sınıflandırmanın öncelikle mantıksal çekirdek sayısına ve gömülü bir artış ve azalma tablosuna dayandığı gösteriliyor: frekans hiç dikkate alınmıyor, oysa spesifikasyon bunu mümkün kılıyor. AMD Ryzen, Intel Gracemont çekirdekleri, Apple silicon ve Intel Core Ultra artış alırken; Intel Atom ve Core 2 döneminin işlemcileri azalma alıyor. Kaba bir ilişki şöyle görünüyor: tek çekirdekli ve çok zayıf makineler birinci seviyeye, iki–dört çekirdek ikinciye, dört–on çekirdek veya modern enerji verimli çipler üçüncüye, sekiz ve daha fazla çekirdek ise Core Ultra, Apple M serisi ve on çekirdekten fazlası dördüncüye düşüyor.

Bunun bir sinyal tespiti olmasının nedeni, sadece başka bir entropi biti olmaması

Tek başına değer zayıf: beş seçenek — bu yaklaşık 2,3 bit entropi, arayüz dili kadar bile değil. Tehlike, üç başka özellikte yatıyor.

Ücretsizdir. Gerçek JS yürütme hızını zamanlama ile almak için, tespit eden scriptin işlemciyi onlara milisaniyelerce meşgul etmesi gerekiyor ve bu, profil oluşturucuda belirgin. Burada — özelliğin senkron okuması, sıfır maliyet, sıfır iz.

Kararlıdır. Değer, kontrol anındaki makine yükünden bağımsızdır: bu bir donanım sınıfıdır, mevcut kullanım değil. Oturumlar, yeniden başlatmalar ve IP değişiklikleri arasında aynı kalır — yani uzun ömürlü bir profil tanımlayıcısının parçası olarak uygundur.

Çelişmezlik açısından kontrol edilebilir. Bu en önemli nokta. Modern anti-bot motorları nadiren tek bir alan üzerinden yasaklar — bir set içinde içsel çelişkiler ararlar. Dördüncü seviye olduğunu iddia eden bir cihaz, bunu inandırıcı bir navigator.hardwareConcurrency, makul bir navigator.deviceMemory, modern bir GPU render dizesi ve uygun bir JS yürütme hızı ile doğrulamak zorundadır. Dördüncü seviye veren ve aynı zamanda iki çekirdekli bir sanal makine gibi benchmark yapan bir profil, basit bir çapraz kontrol ile yakalanır.

Ayrıca, "veri merkezi" ile "canlı kullanıcı" arasındaki neredeyse hazır bir ayrım ortaya çıkıyor: tipik bir bulut örneği iki vCPU ile dürüstçe birinci seviyeyi rapor ederken, tüketici dizüstü bilgisayarları ve telefonlar üçüncü-dördüncü seviyelerde yaşıyor. Düşük maliyetli bir VPS'de headless modda çalışan ve kendini sıradan bir Windows Chrome'u olarak gösteren bir scraper için bu rahatsız edici bir kombinasyon.

Bu, her zaman var olan hardwareConcurrency'den nasıl farklıdır

Makul bir soru: çekirdek sayısını site daha önce navigator.hardwareConcurrency aracılığıyla okudu, bellek miktarını ise navigator.deviceMemory ile. Ne değişti?

Bağlantı değişti. hardwareConcurrency — ham bir sayı ve uzun zamandır ve her yerde değiştirilmekte: otuz iki yerine sekiz koydunuz ve mesele kapandı. cpuPerformance — tarayıcı tarafından gömülü bir tabloya göre hesaplanan türev bir değerdir. Set içinde birinin diğerinden hesaplandığı iki alan ortaya çıktığında, herhangi bir tek taraflı düzenleme, aralarındaki bağı koparır. Dört çekirdek ayarladınız, ancak seviye dördüncü kaldı — uygulama mantığına göre bu kombinasyon ya Apple silicon ya da Core Ultra ya da on çekirdek gerektiriyor; bu nedenle, ya çekirdek sayısı yalan söylüyor ya da GPU dizesi yalan söylüyor ve dedektör, yalanın nerede olduğunu araştırmadan, uyuşmazlığın varlığını fark etmek için yeterlidir.

Tam olarak bu nedenle eski kontrol listeleri "profilde hangi alanların değiştirilmesi gerektiği" artık tek bir maddeyle değil, bütün bloklarla güncelleniyor: doğru soru artık "ne değiştirmek" değil, "toplamda hangi çelişmez donanım konfigürasyonu elde ediyoruz".

Bunu en çok kim etkiliyor

Yalnızca Chromium — ve bu bir hafifletici durum değil. WebKit bu API'ye karşı bir pozisyon aldı, Mozilla ise kamuya açık bir pozisyon belirtmedi, bu nedenle Safari ve Firefox'ta bu özellik muhtemelen olmayacak. Ancak üretim otomasyonunun büyük bir kısmı — Playwright, Puppeteer, nodriver, Patchright, ajan tarayıcılar — tam olarak Chromium üzerine inşa edilmiştir. Yani sinyal, en az beklenen nişin tam içine geliyor.

Çelişki, mobil profillerin taklit edilmesi üzerinde en fazla etkiyi yapıyor. Eğer anti-tespit profili kendini bir Android akıllı telefonu olarak gösteriyorsa ve cpuPerformance altında "4" yanıt veriyorsa, çünkü tarayıcı fiziksel olarak bir Ryzen masaüstünde çalışıyorsa — bu küçük bir hata değil, çelişkili sinyallerin bir çiftidir. Aynı şey, farklı "cihazlarla" bir ana makinede yaşayan onca profilin olduğu çiftlik senaryoları için de geçerlidir ve bu nedenle aynı seviyeyi verirler.

Bunun, parsing yığını için ne anlama geliyor

Headless tarayıcıları topluca çalıştıranlar için birkaç pratik sonuç.

  • Container'lar ana makineden miras alır. Docker'daki tarayıcı, ana makinenin çekirdeklerini görür, cgroup limitlerini değil — bu nedenle, tek bir şişman sunucuda on konteyner, on aynı maksimum seviyeyi verecektir. User-agent'ta titizlikle çizdiğiniz profil çeşitliliği, donanım düzeyinde yoktur.
  • Ucuz VPS artık daha belirgin. İki vCPU — bu birinci seviye ve masaüstü Chrome'da birinci seviye, canlı insanlar arasında pek sık rastlanmaz. Daha önce zayıf bir sunucu sadece yavaştı; şimdi aynı zamanda etiketlenmiş durumda.
  • Sinyal, site için ücretsizdir. Zamanlama benchmarkları gibi ağır kontroller, kullanıcı zamanını harcadıkları için siteler tarafından seçici olarak dahil edilir. Özelliğin okunması hiçbir maliyet gerektirmediğinden, daha önce IP itibarına ve başlıklara sınırlı kalan siteler bile bunu temel setlerine ekleyeceklerdir.
  • Compute Pressure ile yan yana yer alacak. Chrome'un sürüm notlarında, yeni API'nin Compute Pressure API ile birleştirilmesi açıkça önerilmektedir — yani "donanım sınıfı artı gözlemlenen yük" kombinasyonu başlangıçta standart bir senaryo olarak düşünülmüş ve anti-botların hiçbir şey icat etmesine gerek kalmayacaktır.

Ayrıca, "iyi" bir profil oluşturmanın ve yıllarca yeniden kullanmanın yeterli olduğu varsayımını gözden geçirmek önemlidir. Tarayıcılar, son kullanıcılar için duyurulmadan bu tür özellikleri ekliyor: Chrome 152'nin yayınlanması ile ilk kamuya açık analizler arasında, profiller yeni alanı herhangi bir şeyden habersiz bir şekilde sunarak geçen haftalar oldu. Alan setini, yılda bir kez değil, her sürüm döngüsünde kontrol etmek mantıklıdır.

Pratikte ne yapılmalı

  1. Mevcut değeri alın. Profil konsolunda: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory ve WebGL render dizesi. Dördü bir arada kaydedin, tek tek değil — sizi tam olarak bu kombinasyonla kontrol edecekler.
  2. Seviyeyi profil efsanesiyle karşılaştırın. Mobil efsane — birinci–üçüncü seviye, bütçe dizüstü bilgisayarı — ikinci–üçüncü, amiral gemisi masaüstü — dördüncü. Dördüncü seviye, eski bir Android gibi ya da birinci seviye, M serisi MacBook gibi görünüyorsa, her ikisi de şüpheli.
  3. Özelliği doğrudan değiştirmeyin. Object.defineProperty aracılığıyla değiştirme, getter'ın yeniden tanımlanması ve gerçek yürütme hızı ile çelişki nedeniyle yakalanır. Eğer değiştirecekseniz, bunu tarayıcı derleme düzeyinde veya yerleşik mekanizmalar aracılığıyla yapın.
  4. Yasal geçersiz kılmayı unutmayın. Chrome, kullanıcılara ayarlarda bir seçenek (Performans → Hız → CPU performans seviyesini geçersiz kıl) sunar ve yöneticilere kurumsal politika sağlar. Bu, iki açıdan bilinmesi faydalıdır: değer sadece "gerçek" değil, aynı zamanda elle ayarlanmış olabilir ve profiller havuzunda kitlesel olarak aynı geçersiz kılma, kendisi bir etiket haline gelir.
  5. Profilleri farklı donanımlara dağıtın. Tüm profilleriniz tek bir sunucuda bulunuyorsa, seviyeleri aynı olacaktır — hangi cihazları temsil ettiklerinden bağımsız olarak. Bu, birkaç farklı konfigürasyona sahip makine parkının sorunu dürüstçe çözdüğü bir durumdur, ancak bir yamanın çözüm sağlamadığı bir durumdur.

Benzer sinyalin ayrıntıları için, cihazın bellek hacmine göre parmak izi analizine ve bu tür özelliklerle kutudan çıkan stealth tarayıcılar için nodriver, Camoufox ve Patchright benchmark'ına göz atabilirsiniz.

Burada proxy nerede

Açıkça söylemek gerekirse: proxy, tarayıcı parmak izini düzeltmez. cpuPerformance istemci tarafında hesaplanır ve hiçbir IP bunu değiştiremez. Ancak anti-bot, katmanların toplamına göre karar verir ve katmanların kesişiminde genellikle bir başarısızlık meydana gelir.

Tipik bir zincir, ucuz kurulumların düştüğü yol şöyle görünür: bilinen bir barındırma ağından IP, işlemcinin birinci seviyesi, JS'deki headless belirtileri — her biri ayrı ayrı tolere edilebilir üç bağımsız sinyal, ancak birlikte kesin bir hükme dönüşür. Bu toplamdan ağ katmanını çıkarmak, tarayıcı alanlarıyla savaşmaktan daha ucuz ve güvenilir: residential IP ile yapılan istek, sıradan bir ev sağlayıcısının trafiği gibi görünür ve "veri merkezi" hipotezi dedektör için kendiliğinden ortadan kalkar. Mobil efsaneler için mantık aynıdır — mobil proxy, mobil profili desteklemelidir, aksi takdirde çelişki sadece işlemciden ağa geçer.

Kısaca

Chrome 152, yeni bir parmak izi eklemekten çok, çapraz kontroller tablosuna yeni bir satır ekledi. İki buçuk bit, kendi başına kimseyi ifşa etmez — ifşa eden tutarsızlıktır: belirtilen cihaz, işlemci sınıfı, bellek miktarı, grafik kartı, yürütme hızı ve isteğin geldiği ağ ile uyuşmalıdır. Bu hafta profillerin denetimine, konsolda bir satırla ve "bu tür bir donanım, kendimizi gösterdiğimiz kişi için gerçekten var mı?" sorusuyla başlamak gerekir.