25 अगस्त 2026 को Chrome 152 स्थिर चैनल पर Windows, Mac, Linux, ChromeOS और Android के लिए आया - और navigator.cpuPerformance विशेषता लाया। यह 0 से 4 के बीच एक संख्या है, जिसे साइट समकालिक रूप से पढ़ती है, बिना अनुमतियों के और बिना किसी गणना चक्र के। इसे वीडियो कॉल और स्ट्रीम के लिए एक संकेत के रूप में डिज़ाइन किया गया है: कमजोर डिवाइस को 240p बिना पृष्ठभूमि धुंधलाने के देने के लिए, और शक्तिशाली को 1080p प्रभावों के साथ। रिलीज के दो सप्ताह बाद, स्क्रैपिंग उद्योग एक और चीज़ पर चर्चा कर रहा है: एंटी-बॉट सिस्टम के पास उस हार्डवेयर के बारे में एक सस्ता और स्थिर संकेत है जिस पर आपका ब्राउज़र चल रहा है।
ब्राउज़र वास्तव में क्या देता है
यह विशेषता गीगाहर्ट्ज़ या प्रोसेसर मॉडल को नहीं लौटाती, बल्कि प्रदर्शन का एक "टियर" लौटाती है। WICG के स्पष्टीकरण नोट्स के अनुसार, टियर्स चार प्लस शून्य हैं:
- 0 - डिवाइस को वर्गीकृत नहीं किया जा सका;
- 1 - भारी कार्यों के लिए लगभग अनुपयुक्त;
- 2 - कमजोर, लेकिन कार्यशील;
- 3 - सामान्य परिदृश्यों के लिए आरामदायक;
- 4 - प्रदर्शनकारी, मल्टीटास्किंग के लिए पर्याप्त।
विशेषज्ञता स्पष्ट रूप से विक्रेता, मॉडल नाम और कोर की संख्या को प्रकट करने से मना करती है, HTTPS की आवश्यकता होती है और गोपनीयता का लक्ष्य रखती है: प्रत्येक टियर को इंटरनेट पर उपकरणों के एक महत्वपूर्ण हिस्से को कवर करना चाहिए - सैकड़ों विभिन्न CPU मॉडल के आसपास, ताकि मान मूल्य को एकल में संकुचित न करे।
Chromium में वास्तविक कार्यान्वयन विशेषज्ञता से सरल निकला। Zyte के विश्लेषण में दिखाया गया है कि वर्गीकरण मुख्य रूप से तार्किक कोर की संख्या और एक अंतर्निहित तालिका पर आधारित है: आवृत्ति को बिल्कुल भी ध्यान में नहीं रखा जाता, हालांकि स्पेक यह अनुमति देता है। वृद्धि AMD Ryzen, Intel Gracemont कोर, Apple सिलिकॉन और Intel Core Ultra को मिलती है; कमी Intel Atom और Core 2 युग के प्रोसेसर को मिलती है। मोटे तौर पर, एकल-कोर और बहुत कमजोर मशीनें पहले टियर में आती हैं, दो से चार कोर दूसरे में, चार से दस कोर या आधुनिक ऊर्जा-कुशल चिप्स तीसरे में, और आठ या अधिक कोर Core Ultra, Apple M-सीरीज़ और दस कोर से ऊपर की सभी चीज़ें चौथे में आती हैं।
यह संकेत क्यों है, न कि बस एक और एंट्रोपी का बाइट
स्वयं में मान कमजोर है: पांच विकल्प - यह लगभग 2.3 बिट एंट्रोपी है, जो इंटरफेस भाषा से कम है। खतरा तीन अन्य विशेषताओं में है।
यह मुफ्त है। वास्तविक JS निष्पादन गति को समय के साथ मापने के लिए, डिटेक्ट स्क्रिप्ट को प्रोसेसर को दर्जनों मिलीसेकंड के लिए व्यस्त करना होगा, और यह प्रोफाइलर में स्पष्ट है। यहाँ - विशेषता का समकालिक पढ़ना, शून्य लागत, शून्य निशान।
यह स्थिर है। मान जांच के समय मशीन की लोडिंग पर निर्भर नहीं करता: यह हार्डवेयर का वर्ग है, न कि वर्तमान उपयोग। सत्रों, पुनरारंभों और IP परिवर्तनों के बीच यह वही रहता है - अर्थात्, यह दीर्घकालिक प्रोफ़ाइल पहचानकर्ता के हिस्से के रूप में उपयुक्त है।
यह असंगति के लिए जांचा जा सकता है। यह मुख्य बात है। आधुनिक एंटी-बॉट इंजन शायद ही कभी एक क्षेत्र के आधार पर बैन करते हैं - वे सेट में आंतरिक असंगतियों की तलाश करते हैं। डिवाइस, जिसने चौथे टियर का दावा किया है, को इसे विश्वसनीय navigator.hardwareConcurrency, उचित navigator.deviceMemory, आधुनिक GPU-रेनडरिंग स्ट्रिंग और JS निष्पादन की संबंधित गति के साथ पुष्टि करनी चाहिए। एक प्रोफ़ाइल जो टियर 4 देती है और साथ ही बेंचमार्क को दो-कोर वर्चुअल मशीन के रूप में निष्पादित करती है, साधारण क्रॉस-चेकिंग द्वारा पकड़ी जाती है।
अलग से, "डेटा सेंटर बनाम जीवित उपयोगकर्ता" का लगभग तैयार जल विभाजन प्राप्त होता है: एक सामान्य क्लाउड इंस्टेंस दो vCPU पर ईमानदारी से पहले टियर की रिपोर्ट करता है, जबकि उपभोक्ता लैपटॉप और फोन तीसरे-चौथे में रहते हैं। एक स्क्रैपर के लिए, जो सस्ते VPS पर हेडलेस मोड में चल रहा है और सामान्य Chrome के रूप में खुद को प्रस्तुत करता है Windows पर, यह एक असुविधाजनक संयोजन है।
यह hardwareConcurrency से कैसे भिन्न है, जो हमेशा था
एक उचित प्रश्न: कोर की संख्या को साइट पहले भी navigator.hardwareConcurrency के माध्यम से पढ़ती थी, और मेमोरी की मात्रा को navigator.deviceMemory के माध्यम से। क्या बदला है?
संयोगिता बदल गई है। hardwareConcurrency - कच्चा संख्या है, और इसे लंबे समय से और सर्वत्र बदल दिया गया है: आपने तीस दो के बजाय आठ रखा, और सवाल खत्म। cpuPerformance - एक व्युत्पन्न मात्रा है, जो ब्राउज़र द्वारा अंतर्निहित तालिका के अनुसार गणना की गई है। जब सेट में दो क्षेत्र होते हैं, जिनमें से एक दूसरे से गणना की जाती है, तो किसी भी एकतरफा संपादन के कारण उनके बीच का संबंध टूट जाता है। चार कोर सेट किए गए, जबकि टियर चौथा बना रहा - कार्यान्वयन की तर्क के अनुसार, ऐसा संयोजन या तो Apple सिलिकॉन, या Core Ultra, या दस कोर की आवश्यकता होती है; इसका मतलब है कि या तो कोर की संख्या झूठी है, या GPU स्ट्रिंग झूठी है, और डिटेक्टर के लिए असंगति का तथ्य देखना पर्याप्त है, यह पता लगाए बिना कि झूठ कहाँ है।
इसीलिए पुराने चेकलिस्ट "प्रोफ़ाइल में कौन से क्षेत्र बदलने हैं" एक ही बिंदु पर नहीं, बल्कि पूरे ब्लॉकों में पुरानी हो जाती हैं: सही सवाल अब "क्या बदलना है", बल्कि "हमारे पास कुल मिलाकर कौन सी असंगत हार्डवेयर कॉन्फ़िगरेशन है" है।
किसे इससे सबसे ज्यादा प्रभावित होता है
केवल Chromium - और यह कोई शमनकारी परिस्थिति नहीं है। WebKit ने इस API पर "विपरीत" स्थिति अपनाई है, Mozilla ने सार्वजनिक स्थिति नहीं दी है, इसलिए Safari और Firefox में यह विशेषता शायद नहीं होगी। लेकिन उत्पादन स्वचालन का अधिकांश हिस्सा - Playwright, Puppeteer, nodriver, Patchright, एजेंट ब्राउज़र - विशेष रूप से Chromium पर आधारित है। इसका मतलब है कि संकेत ठीक उसी निचे में आता है, जहाँ इसकी सबसे कम उम्मीद होती है।
सबसे अधिक चोट असंगति मोबाइल प्रोफाइल के अनुकरण पर लगती है। यदि एंटी-डिटेक्ट प्रोफ़ाइल खुद को Android स्मार्टफोन के रूप में प्रस्तुत करता है, और cpuPerformance इसके तहत "4" का उत्तर देता है, क्योंकि ब्राउज़र भौतिक रूप से Ryzen डेस्कटॉप पर चल रहा है - यह कोई छोटी असंगति नहीं है, बल्कि संकेतों का एक परस्पर-विरोधी जोड़ा है। वही फर्मा-परिदृश्यों के साथ है, जहाँ विभिन्न "डिवाइसों" के दर्जनों प्रोफाइल एक ही होस्ट मशीन पर रहते हैं और इसलिए समान टियर देते हैं।
यह पार्सिंग-स्टैक के लिए क्या बदलता है
उन लोगों के लिए कुछ व्यावहारिक परिणाम जो हेडलेस ब्राउज़रों को पैक में चलाते हैं।
- कंटेनर होस्ट को विरासत में लेते हैं। डॉकर में ब्राउज़र होस्ट मशीन के कोर को देखता है, न कि cgroup की सीमाओं को - इसका मतलब है कि एक मोटे सर्वर पर दस कंटेनर दस समानतम अधिकतम टियर्स देंगे। प्रोफाइल की विविधता, जिसे आपने user-agent में सावधानी से चित्रित किया, हार्डवेयर स्तर पर अनुपस्थित है।
- सस्ता VPS अब अधिक स्पष्ट है। दो vCPU - यह पहला टियर है, और डेस्कटॉप Chrome पर पहला टियर जीवित लोगों में शायद ही कभी मिलता है। पहले कमजोर सर्वर बस धीमा था; अब यह भी चिह्नित है।
- साइट के लिए संकेत मुफ्त है। भारी जांच जैसे समय-आधारित बेंचमार्क साइटें चयनात्मक रूप से शामिल करती हैं, क्योंकि वे उपयोगकर्ता के समय की कीमत होती हैं। विशेषता का पढ़ना कुछ नहीं है, इसलिए इसे मूल सेट में जोड़ा जाएगा, यहां तक कि वे साइटें जो पहले IP प्रतिष्ठा और हेडर तक सीमित थीं।
- यह Compute Pressure के साथ रखा जाएगा। Chrome के रिलीज़ नोट्स में सीधे नए API को Compute Pressure API के साथ संयोजित करने का सुझाव दिया गया है - अर्थात् "हार्डवेयर का वर्ग और देखी गई लोड" का संयोजन मूल रूप से एक मानक परिदृश्य के रूप में सोचा गया है, और एंटी-बॉट को कुछ भी आविष्कार करने की आवश्यकता नहीं होगी।
अलग से यह मान लेना उचित है कि "अच्छा" प्रोफ़ाइल एक बार इकट्ठा करना और वर्षों तक पुन: उपयोग करना पर्याप्त है। ब्राउज़र बिना अंतिम उपयोगकर्ताओं के लिए घोषणाओं के ऐसे गुण जोड़ते हैं: Chrome 152 के रिलीज़ और पहले सार्वजनिक विश्लेषणों के बीच सप्ताह बीत चुके हैं, जिसके दौरान प्रोफाइल ने बिना किसी संदेह के नया क्षेत्र दिया। क्षेत्रों के सेट की जांच एक रिलीज़ चक्र में एक बार करना समझदारी है, न कि साल में एक बार।
व्यवहार में क्या करना है
- वर्तमान मान निकालें। प्रोफ़ाइल की कंसोल में:
navigator.cpuPerformance,navigator.hardwareConcurrency,navigator.deviceMemoryऔर WebGL रेंडरिंग स्ट्रिंग। चार के रूप में रिकॉर्ड करें, न कि एक-एक क्षेत्र के रूप में - आपको वास्तव में जोड़ी के रूप में जांचा जाएगा। - टियर को प्रोफ़ाइल की किंवदंती से मिलाएं। मोबाइल किंवदंती - पहला-तीसरा टियर, बजट लैपटॉप - दूसरा-तीसरा, प्रमुख डेस्कटॉप - चौथा। टियर 4 पुराने Android के रूप में या टियर 1 M-सीरीज़ पर MacBook के रूप में समान रूप से संदिग्ध हैं।
- गुण को सीधे न बदलें।
Object.definePropertyके माध्यम से प्रतिस्थापन गेटर के पुनर्परिभाषा के निशान और वास्तविक निष्पादन गति के साथ असंगति द्वारा पकड़ा जाता है। यदि बदलना है, तो ब्राउज़र के निर्माण के स्तर पर या अंतर्निहित तंत्र के माध्यम से। - कानूनी ओवरराइड के बारे में याद रखें। Chrome उपयोगकर्ता को सेटिंग्स में एक हैंडल देता है (Performance → Speed → Override CPU performance tier), और प्रशासकों को - कॉर्पोरेट नीति। यह जानना उपयोगी है कि मूल्य न केवल "वास्तविक" हो सकता है, बल्कि हाथों से सेट किया गया भी हो सकता है, और प्रोफाइल के पूल पर समान ओवरराइड खुद एक चिह्न बन जाता है।
- प्रोफाइल को विभिन्न हार्डवेयर पर फैलाएं। यदि आपकी सभी प्रोफाइल एक ही सर्वर पर हैं, तो उनका टियर समान होगा - चाहे वे कौन से उपकरणों का चित्रण करें। यह वह स्थिति है जहाँ विभिन्न कॉन्फ़िगरेशन वाली कई मशीनों का पार्क ईमानदारी से समस्या का समाधान करता है, जबकि पैच नहीं।
समान परिवार के पड़ोसी संकेत के बारे में अधिक जानकारी के लिए - डिवाइस मेमोरी के आकार के आधार पर फ़िंगरप्रिंट के विश्लेषण में, और ऐसे गुणों के साथ काम करने वाले स्टेल्थ ब्राउज़रों के लिए nodriver, Camoufox और Patchright का बेंचमार्क है।
यहाँ प्रॉक्सी कहाँ है
साफ कहें: प्रॉक्सी ब्राउज़र के फ़िंगरप्रिंट को ठीक नहीं करती है। cpuPerformance क्लाइंट की ओर से गणना की जाती है, और कोई IP इसे नहीं बदलेगा। लेकिन एंटी-बॉट निर्णय परतों के योग के आधार पर लेते हैं, और आमतौर पर परतों के चौराहे पर ही विफलता होती है।
सस्ते सेटअप गिरने की सामान्य श्रृंखला इस प्रकार है: ज्ञात होस्टिंग नेटवर्क से IP, प्रोसेसर का पहला टियर, JS में हेडलेस संकेत - तीन स्वतंत्र संकेत, जिनमें से प्रत्येक अलग से सहनीय है, और एक साथ वे एक स्पष्ट निर्णय में जोड़ते हैं। इस योग से नेटवर्क परत को हटाना सस्ता और अधिक विश्वसनीय है, बजाय इसके कि ब्राउज़र के क्षेत्रों के साथ लड़ाई करें: रिहायशी IP से अनुरोध सामान्य घरेलू प्रदाता के ट्रैफ़िक के रूप में दिखाई देता है, और "डेटा सेंटर" परिकल्पना डिटेक्टर से अपने आप हट जाती है। मोबाइल किंवदंतियों के लिए तर्क वही है - मोबाइल प्रॉक्सी को मोबाइल प्रोफ़ाइल का समर्थन करना चाहिए, अन्यथा विरोधाभास बस प्रोसेसर से नेटवर्क पर चला जाता है।
संक्षेप में
Chrome 152 ने न केवल एक नया फ़िंगरप्रिंट जोड़ा, बल्कि क्रॉस-चेकिंग की तालिका में एक नई पंक्ति भी जोड़ी। दो से थोड़ा अधिक बिट स्वयं में किसी को नहीं बताते - असंगति बताती है: घोषित उपकरण को प्रोसेसर के वर्ग, मेमोरी की मात्रा, ग्राफिक्स कार्ड, निष्पादन गति और उस नेटवर्क के साथ मेल खाना चाहिए, जिससे अनुरोध आया। इस सप्ताह प्रोफाइल का ऑडिट एक लाइन के साथ कंसोल से शुरू करना चाहिए और सवाल "क्या ऐसा हार्डवेयर वास्तव में उस व्यक्ति के पास है जिसके रूप में हम खुद को प्रस्तुत करते हैं?"।