navigator.cpuPerformance: سیگنال جدید شناسایی Chrome 152

25 اوت 2026 سال Chrome 152 به کانال پایدار در ویندوز، مک، لینوکس، ChromeOS و اندروید آمد — و ویژگی navigator.cpuPerformance را به همراه آورد. یک عدد از 0 تا 4 که سایت به صورت همزمان می‌خواند، بدون مجوزها و بدون یک تک محاسبات. این ویژگی به عنوان یک راهنمایی برای تماس‌های ویدیویی و استریم‌ها طراحی شده است: به دستگاه ضعیف 240p بدون تاری پس‌زمینه بدهید، به دستگاه قوی 1080p با افکت‌ها. دو هفته پس از انتشار، صنعت اسکرپینگ به موضوع دیگری می‌پردازد: سیستم‌های ضد ربات سیگنال ارزان و پایداری از سخت‌افزاری که مرورگر شما روی آن اجرا می‌شود، به دست آورده‌اند.

مرورگر چه چیزی را ارائه می‌دهد

این ویژگی نه گیگاهرتز و نه مدل پردازنده را برمی‌گرداند، بلکه «سبد» عملکرد را ارائه می‌دهد. طبق توضیحات WICG، تیپ‌ها چهار به علاوه صفر هستند:

0 — شناسایی دستگاه ممکن نشد؛
1 — تقریباً برای کارهای سنگین نامناسب است؛
2 — ضعیف، اما کارا؛
3 — راحت برای سناریوهای معمولی؛
4 — با عملکرد بالا، با ظرفیت برای چندوظیفگی.

مشخصات به وضوح افشای فروشنده، نام مدل و تعداد هسته‌ها را ممنوع می‌کند، HTTPS را الزامی می‌کند و هدف حفظ حریم خصوصی را تعیین می‌کند: هر سبد باید درصد قابل توجهی از دستگاه‌ها در اینترنت را پوشش دهد — حدود صدها مدل مختلف CPU، تا مقدار آن مخاطب را به واحدها محدود نکند.

پیاده‌سازی واقعی در Chromium ساده‌تر از مشخصات بود. در تحلیل Zyte نشان داده شده است که طبقه‌بندی عمدتاً بر اساس تعداد هسته‌های منطقی و جدول داخلی افزایش و کاهش است: فرکانس به طور کلی در نظر گرفته نمی‌شود، هرچند که مشخصات این اجازه را می‌دهد. افزایش شامل AMD Ryzen، هسته‌های Intel Gracemont، Apple silicon و Intel Core Ultra است؛ کاهش شامل Intel Atom و پردازنده‌های دوره Core 2 می‌شود. پیوند خشن به این شکل است: ماشین‌های تک‌هسته‌ای و بسیار ضعیف به تیپ اول می‌رسند، دو تا چهار هسته تیپ دوم را می‌دهند، چهار تا ده هسته یا چیپ‌های انرژی‌کارآمد مدرن — تیپ سوم، و هشت و بیشتر هسته در Core Ultra، سری M اپل و هر چیزی که از ده هسته بیشتر باشد — تیپ چهارم.

چرا این یک سیگنال شناسایی است، نه فقط یک بایت دیگر از انتروپی

به خودی خود مقدار ضعیف است: پنج گزینه — حدود 2.3 بیت انتروپی، کمتر از آنچه که زبان رابط ارائه می‌دهد. خطر در سه ویژگی دیگر است.

این رایگان است. برای اندازه‌گیری سرعت واقعی اجرای JS، اسکریپت شناسایی باید پردازنده را برای ده‌ها میلی‌ثانیه مشغول کند و این در پروفایلر قابل مشاهده است. در اینجا — خواندن همزمان ویژگی، بدون هزینه، بدون ردپا.

این پایدار است. مقدار به بارگذاری ماشین در زمان بررسی بستگی ندارد: این کلاس سخت‌افزار است، نه استفاده فعلی. بین جلسات، راه‌اندازی مجدد و تغییرات IP، همان باقی می‌ماند — یعنی به عنوان بخشی از یک شناسه پایدار مناسب است.

این برای عدم تناقض بررسی می‌شود. این مهم‌ترین نکته است. موتورهای ضد ربات مدرن به ندرت بر اساس یک فیلد بن می‌کنند — آنها به دنبال تناقضات داخلی در مجموعه هستند. دستگاهی که تیپ چهارم را اعلام کرده، موظف است آن را با navigator.hardwareConcurrency معتبر، navigator.deviceMemory منطقی، رشته مدرن GPU-رندر و سرعت اجرای JS مربوطه تأیید کند. پروفایلی که تیپ 4 را ارائه می‌دهد و در عین حال بنچمارک را به عنوان یک ماشین مجازی دو هسته‌ای اجرا می‌کند، با یک بررسی متقابل ساده شناسایی می‌شود.

به طور جداگانه، تقریباً یک مرز آماده بین «دیتاسنتر» و «کاربر واقعی» شکل می‌گیرد: یک نمونه ابری معمولی با دو vCPU به طور صادقانه تیپ اول را گزارش می‌دهد، در حالی که لپ‌تاپ‌ها و تلفن‌های مصرف‌کننده در تیپ‌های سوم و چهارم زندگی می‌کنند. برای اسکرپر که روی VPS ارزان در حالت headless اجرا می‌شود و در عین حال خود را به عنوان Chrome معمولی در ویندوز معرفی می‌کند، این ترکیب ناخوشایند است.

این چه تفاوتی با hardwareConcurrency دارد که همیشه وجود داشته است

سوالی منطقی: تعداد هسته‌ها را سایت قبلاً از طریق navigator.hardwareConcurrency می‌خواند و حجم حافظه را از طریق navigator.deviceMemory. چه چیزی تغییر کرده است؟

ارتباط تغییر کرده است. hardwareConcurrency یک عدد خام است و آن را به راحتی و به طور گسترده‌ای تغییر می‌دهند: هشت را به جای سی و دو قرار دهید و موضوع حل می‌شود. cpuPerformance یک مقدار مشتق است که خود مرورگر بر اساس جدول داخلی محاسبه می‌کند. به محض اینکه در مجموعه دو فیلد وجود داشته باشد که یکی از دیگری محاسبه می‌شود، هر ویرایش یک‌طرفه ارتباط بین آنها را قطع می‌کند. چهار هسته را تنظیم کردید، اما تیپ همچنان چهارم باقی ماند — از نظر منطق پیاده‌سازی، این ترکیب نیاز به Apple silicon، Core Ultra یا ده هسته دارد؛ بنابراین یا تعداد هسته‌ها دروغ است، یا رشته GPU دروغ می‌گوید، و برای شناسایی‌کننده کافی است که خود تناقض را مشاهده کند، بدون اینکه بفهمد در کجا دروغ گفته شده است.

به همین دلیل است که چک‌لیست‌های قدیمی «کدام فیلدها را در پروفایل تغییر دهیم» نه تنها به یک مورد، بلکه به کل بلوک‌ها قدیمی می‌شوند: سوال درست اکنون این است که «چه ترکیب غیرمتناقضی از سخت‌افزار در مجموع داریم».

چه کسانی بیشتر تحت تأثیر قرار می‌گیرند

فقط Chromium — و این یک عامل تخفیف نیست. WebKit در این API موضع «مخالف» را اتخاذ کرده است، موزیلا موضع عمومی اعلام نکرده است، بنابراین احتمالاً این ویژگی در Safari و Firefox وجود نخواهد داشت. اما بخش عمده‌ای از اتوماسیون تولید — Playwright، Puppeteer، nodriver، Patchright، مرورگرهای عامل — دقیقاً بر اساس Chromium ساخته شده است. به این معنی که سیگنال دقیقاً به آن ناحیه می‌رسد که کمتر از همه انتظار می‌رود.

تناقض بیشتر بر روی شبیه‌سازی پروفایل‌های موبایل تأثیر می‌گذارد. اگر پروفایل ضد شناسایی خود را به عنوان یک گوشی هوشمند اندرویدی معرفی کند و cpuPerformance زیر آن «4» پاسخ دهد، زیرا مرورگر به طور فیزیکی بر روی دسکتاپی با Ryzen اجرا شده است — این یک عدم دقت کوچک نیست، بلکه یک جفت سیگنال متناقض است. همین امر در سناریوهای فارم نیز صدق می‌کند، جایی که ده‌ها پروفایل با «دستگاه‌های» مختلف بر روی یک ماشین میزبان زندگی می‌کنند و بنابراین تیپ یکسانی را ارائه می‌دهند.

این چه تغییری برای استک پارسینگ ایجاد می‌کند

چند نتیجه عملی برای کسانی که مرورگرهای headless را به صورت دسته‌ای اجرا می‌کنند.

کانتینرها میزبان را به ارث می‌برند. مرورگر در داکر هسته‌های ماشین میزبان را می‌بیند، نه محدودیت‌های cgroup — به این معنی که ده کانتینر بر روی یک سرور چرب، ده تیپ حداکثر یکسان را خواهند داد. تنوع پروفایل‌هایی که شما به دقت در user-agent ترسیم کرده‌اید، در سطح سخت‌افزار وجود ندارد.
VPS ارزان اکنون قابل مشاهده‌تر است. دو vCPU — تیپ اول است، و تیپ اول در Chrome دسکتاپ تحت ویندوز به ندرت در افراد واقعی دیده می‌شود. قبلاً سرور ضعیف فقط کند بود؛ اکنون همچنین علامت‌گذاری شده است.
سیگنال برای سایت رایگان است. بررسی‌های سنگین مانند بنچمارک‌های زمانی، سایت‌ها را به صورت انتخابی شامل می‌کنند، زیرا آنها زمان کاربر را هزینه می‌کنند. خواندن ویژگی هیچ هزینه‌ای ندارد، بنابراین حتی آن سایت‌هایی که قبلاً به شهرت IP و هدرها محدود می‌شدند، آن را به مجموعه پایه اضافه خواهند کرد.
این در کنار Compute Pressure قرار می‌گیرد. در یادداشت‌های انتشار Chrome به وضوح پیشنهاد می‌شود که API جدید را با Compute Pressure API ترکیب کنید — به این معنی که ترکیب «کلاس سخت‌افزار به علاوه بار مشاهده شده» به طور اولیه به عنوان یک سناریو استاندارد طراحی شده است و ضد ربات‌ها نیازی به اختراع هیچ چیزی نخواهند داشت.

به طور جداگانه، باید فرض را بازنگری کرد که کافی است یک بار «پروفایل خوب» را جمع‌آوری کرده و سال‌ها از آن استفاده کنید. مرورگرها بدون اعلام برای کاربران نهایی این ویژگی‌ها را اضافه می‌کنند: بین انتشار Chrome 152 و اولین تحلیل‌های عمومی، هفته‌هایی گذشت که پروفایل‌ها به آرامی فیلد جدیدی را ارائه می‌دادند، بدون اینکه از چیزی مطلع باشند. بررسی مجموعه فیلدها هر بار در چرخه انتشار معقول است، نه هر سال.

چه کار باید کرد به طور عملی

مقدار فعلی را بگیرید. در کنسول پروفایل: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory و رشته رندرکننده WebGL. چهار تا را ثبت کنید، نه یکی یکی — شما دقیقاً با این ترکیب بررسی خواهید شد.
تیپ را با افسانه پروفایل مقایسه کنید. افسانه موبایل — تیپ اول تا سوم، لپ‌تاپ بودجه‌ای — تیپ دوم تا سوم، دسکتاپ پرچمدار — تیپ چهارم. تیپ 4 به عنوان یک اندروید قدیمی یا تیپ 1 به عنوان یک MacBook در سری M به یک اندازه مشکوک است.
ویژگی را به طور مستقیم تغییر ندهید. تغییر از طریق Object.defineProperty با ردپاهای بازتعریف گتر و با عدم تطابق با سرعت واقعی اجرا شناسایی می‌شود. اگر هم بخواهید تغییر دهید، باید در سطح ساخت مرورگر یا از طریق مکانیزم‌های داخلی باشد.
به اوورراید قانونی توجه کنید. Chrome به کاربر یک گزینه در تنظیمات می‌دهد (Performance → Speed → Override CPU performance tier) و به مدیران — سیاست شرکتی. این نکته را از دو طرف باید دانست: مقدار می‌تواند نه تنها «واقعی» باشد، بلکه به صورت دستی تنظیم شده باشد، و اوورراید یکسان در یک مجموعه پروفایل‌ها خود به یک علامت تبدیل می‌شود.
پروفایل‌ها را بر روی سخت‌افزارهای مختلف توزیع کنید. اگر همه پروفایل‌های شما بر روی یک سرور نشسته‌اند، تیپ آنها یکسان خواهد بود — صرف نظر از اینکه چه دستگاه‌هایی را نشان می‌دهند. این همان موردی است که پارک چندین ماشین با پیکربندی‌های مختلف به طور صادقانه مشکل را حل می‌کند، در حالی که پچ این کار را نمی‌کند.

جزئیات بیشتر در مورد سیگنال هم‌خانواده دیگر — در تحلیل اثر انگشت بر اساس حجم حافظه دستگاه، و برای مرورگرهای استیل که با چنین ویژگی‌هایی به طور پیش‌فرض کار می‌کنند، بنچمارک nodriver، Camoufox و Patchright وجود دارد.

اینجا پروکسی کجاست

به طور مستقیم بگوییم: پروکسی اثر انگشت مرورگر را تعمیر نمی‌کند. cpuPerformance در سمت کلاینت محاسبه می‌شود و هیچ IP آن را تغییر نمی‌دهد. اما ضد ربات بر اساس مجموع لایه‌ها تصمیم می‌گیرد و معمولاً در مرز لایه‌ها است که شکست رخ می‌دهد.

زنجیره معمولی که از آن طریق تنظیمات ارزان سقوط می‌کنند به این شکل است: IP از یک شبکه میزبانی شناخته شده، تیپ اول پردازنده، نشانه‌های headless در JS — سه سیگنال مستقل که هر کدام به تنهایی قابل تحمل هستند، اما با هم به یک حکم واضح می‌رسند. حذف لایه شبکه از این مجموع ارزان‌تر و مطمئن‌تر از جنگیدن با فیلدهای مرورگر است: با IP مسکونی درخواست به عنوان ترافیک یک ارائه‌دهنده خانگی معمولی به نظر می‌رسد و فرض «دیتاسنتری» برای شناسایی‌کننده خود به خود از بین می‌رود. برای افسانه‌های موبایل نیز منطق همان است — پروکسی موبایل باید از پروفایل موبایل پشتیبانی کند، در غیر این صورت تناقض به سادگی از پردازنده به شبکه منتقل می‌شود.

خلاصه

Chrome 152 نه تنها یک اثر انگشت جدید اضافه کرد، بلکه یک خط جدید در جدول بررسی‌های متقابل ایجاد کرد. دو و اندی بیت به خودی خود کسی را افشا نمی‌کند — عدم توافق افشا می‌کند: دستگاه اعلام شده باید با کلاس پردازنده، حجم حافظه، کارت گرافیک، سرعت اجرا و شبکه‌ای که درخواست از آن آمده است، مطابقت داشته باشد. این هفته، بررسی پروفایل‌ها باید با یک خط در کنسول و سوال «آیا چنین سخت‌افزاری واقعاً وجود دارد که ما خود را به عنوان آن معرفی می‌کنیم؟» آغاز شود.