تست اثر انگشت مرورگر: بررسی یکتایی دستگاه، Canvas، WebGL و AudioContext

تغییر دادن صرف هدر User-Agent نه تنها در پنهان کردن هویت مرورگر شما ناکام می‌ماند، بلکه «تناقضات بین‌لایه‌ای» فاحشی ایجاد می‌کند که باعث تحریک سیستم‌های پیشرفته تشخیص تقلب می‌شود: نخست، عدم تطابق لایه کاربرد با پشته انتقال: اگر هدر UA یک مرورگر ویندوز را روی Safari آیفون تنظیم کنید، هدر HTTP شما ادعای موبایل Apple را دارد، اما بسته TCP SYN شما امضای هسته Windows را نشان می‌دهد (بدون گزینه TS و با ترتیب گزینه‌های MSS, NOP, WS, NOP, NOP, SACK_PERM)، که مستقیماً در تناقض با توالی 8 گزینه‌ای Apple است. دوم، ثابت‌های پروتکل HTTP/3 و HTTP/2: موتورهای Chromium، WebKit و Gecko تفاوت‌های غیرقابل جعلی دارند، مانند نگاشت‌های نوع جریان یک‌طرفه در HTTP/3 (در Chromium به صورت 2:control,10:encoder در مقابل WebKit به صورت 2:control,6:encoder) و ترتیب شبه‌هدرهای HTTP/2 (در Chromium به صورت m,a,s,p در مقابل غیر Chromium به صورت m,s,a,p). تغییر رشته UA صرفاً یک هدر سطحی را تغییر می‌دهد، در حالی که لایه‌های انتقال زیرین را در تعارض مستقیم باقی می‌گذارد.

💡 درباره امضاهای سطح انتقال در تحلیل ناشناسی پروکسی ما بیشتر بدانید.

مرورگرهای ضدتشخیص معمولاً کدهای Chromium را پچ می‌کنند یا قلاب‌های JavaScript را تزریق می‌نمایند تا ویژگی‌های navigator را بازنویسی کنند، به خروجی‌های Canvas/WebGL نویز اضافه کنند و زمینه‌های صفحه نمایش یا صوتی را شبیه‌سازی نمایند. با این حال، سیستم‌های تشخیص پیشرفته به آسانی آثار آشکارساز آن‌ها را شناسایی می‌کنند: نخست، دستکاری توابع بومی و پروتوتایپ: استفاده از پروکسی‌های JS و مانکی‌پچ کردن APIها اغلب باعث تغییر Function.prototype.toString، Object.getOwnPropertyDescriptor و زنجیره‌های وراثت پروتوتایپ می‌شود. دوم، ثابت‌های GPU و شیدر (shader): در حالی که نویز تزریق‌شده هش تصویر رندرشده را تغییر می‌دهد، دقت فیزیکی ممیز شناور GPU و الگوهای شطرنجی‌سازی شیدر ثابت می‌مانند؛ نویز مصنوعی اغلب خود یک امضای به راحتی قابل شناسایی تشکیل می‌دهد. سوم، دست‌نخورده ماندن پشته‌های شبکه زیرین: بیشتر مرورگرهای ضدتشخیص صرفاً در سطح JavaScript عمل می‌کنند و ویژگی‌های دست‌دادن TCP/TLS سیستم‌عامل میزبان را شبیه‌سازی نمی‌کنند.

خیر. حالت ناشناس (Incognito) منحصراً برای جلوگیری از «ردپاهای مرور محلی روی دستگاه خودتان» طراحی شده است، نه برای جلوگیری از «شناسایی از راه دور توسط وب‌سایت‌ها». هنگامی که یک پنجره ناشناس بسته می‌شود، کوکی‌های محلی، localStorage و تاریخچه مرور حذف می‌شوند. با این حال، انگشت‌نگاری مرورگر از طریق اندازه‌گیری ویژگی‌های سخت‌افزاری و نرم‌افزاری فیزیکی توسط JavaScript کار می‌کند (شامل رندرینگ گرافیکی GPU، دقت سایه‌زن WebGL، فونت‌های نصب‌شده، پاسخ نوسان‌ساز صوتی، همزمانی CPU، و عمق رنگ). از آنجا که سخت‌افزار فیزیکی، درایورهای گرافیک و موتور رندرینگ مرورگر شما در حالت ناشناس کاملاً یکسان هستند، هش اثر انگشت حاصل که توسط سرورهای راه دور تولید می‌شود بدون تغییر باقی می‌ماند.

این یک مثبت کاذب نیست—بلکه معماری بنیادین iOS را بازتاب می‌دهد: نخست، دستورالعمل‌های اپ استور Apple ملزم می‌کنند که همه مرورگرهای وب در iOS/iPadOS (از جمله Chrome، Edge، Firefox و Opera) باید از موتور رندرینگ WKWebView / WebKit شرکت Apple استفاده کنند و از اجرای موتورهای Chromium Blink یا Gecko منع شده‌اند. دوم، تایید پروتکل: در iOS، مرورگر Chrome (با شناسه CriOS) نگاشت جریان HTTP/3 منحصر به WebKit را نشان می‌دهد (2:control,6:encoder)، که کاملاً متمایز از Chromium در دسکتاپ یا Android است (2:control,10:encoder). مرورگر Chrome در iOS در واقع یک مرورگر WebKit با رابط کاربری Google است، و شناسایی آن به عنوان WebKit از نظر فنی کاملاً دقیق است.

بله، اما تحت شرایط سخت‌گیرانه و با مرزهای مشخص، و این موضوع کاملاً با احراز هویت کاربر متفاوت است. بازیابی هویت در این سایت از یک مدل وزن‌دهی چهارلایه استفاده می‌کند: 1) لایه لنگر سخت‌افزاری (رشته مدل GPU، تاخیر پایه صوتی، تعداد دستگاه‌های چندرسانه‌ای)؛ 2) لایه آنتروپی بالای سیستم (فهرست فونت‌های نصب‌شده، صداهای سنتز گفتار)؛ 3) لایه تغییرپذیر مرورگر (هش رندرینگ Canvas، هش محاسباتی AudioContext)؛ 4) لایه محیط نمایش (وضوح صفحه نمایش، منطقه زمانی). پس از تجمیع هر چهار لایه، هر دو شرط زیر باید به طور همزمان برقرار باشند تا انتساب به یک هویت موجود پذیرفته شود: نمره کل باید از حد آستانه عبور کند، و حداقل یک ویژگی اصلی با آنتروپی بالا باید مطابقت داشته باشد (فهرست فونت‌ها، فهرست سنتز صدا، Canvas یا Audio). این شرط دوم عمدی است: ویژگی‌های عمومی با آنتروپی پایین مانند مدل GPU، منطقه زمانی و وضوح صفحه نمایش به طور گسترده در میان محموله‌های سخت‌افزاری یکسان تکرار می‌شوند و هیچ ترکیبی از آن‌ها مجاز نیست به تنهایی هویت را اثبات کند؛ نسخه‌های اولیه‌ای که فاقد این درگاه بودند ممکن بود به اشتباه دو فرد غریبه و مجزا را به هم منطبق کنند. علاوه بر این، لایه لنگر سخت‌افزاری یک وتوی سخت‌گیرانه را اعمال می‌کند: اگر هسته‌های منطقی CPU تفاوت داشته باشند، حافظه بیش از 4GB اختلاف داشته باشد، تاخیر پایه صوتی بیش از 0.005 ثانیه متفاوت باشد، یا حداکثر نقاط لمسی تفاوت داشته باشند، کاندیدا بلافاصله به عنوان یک دستگاه متفاوت طبقه‌بندی شده و پیش از امتیازدهی کنار گذاشته می‌شود.

⚠ هدف این سازوکار هم‌راستا کردن مداوم مشاهدات مکرر از یک دستگاه یکسان است، نه اثبات این‌که شما چه کسی هستید—این به منزله احراز هویت نیست و هرگز نباید برای چنین هدفی استفاده شود.

هر دو از «ویژگی‌های آنتروپی بالای سیستم» هستند که به هیچ مجوزی نیاز ندارند و کاملاً بی‌صدا و بدون هیچ اثر مشهودی در صفحه اجرا می‌شوند. انگشت‌نگاری AudioContext: یک بافر صوتی را به صورت آفلاین در OfflineAudioContext با هدایت یک Oscillator از میان DynamicsCompressor رندر می‌کند و با بازخوانی مقادیر نمونه‌های ممیز شناور، آن‌ها را هش می‌نماید. همین گراف پردازش صوتی یکسان، اختلافات بسیار ریزی در کم‌ارزش‌ترین بیت‌ها (least-significant-bit) در میان پیاده‌سازی‌های مختلف مرورگر، کتابخانه‌های ریاضی و بک‌اندهای ممیز شناور تولید می‌کند، بدون آن‌که صدایی شنیده شود. در مجاورت آن اما کاملاً مستقل، مقدار AudioContext.baseLatency قرار دارد: این مقدار بیانگر اندازه بافر خروجی کارت صدا است که توسط درایورهای صوتی و سخت‌افزار تعیین می‌شود؛ سیستم ما با آن به عنوان یک لنگر سخت‌افزاری برخورد می‌کند (اختلافی بیش از 0.005 ثانیه بلافاصله موجب رد تطابق می‌شود) نه یک هش هویت—این دو منشا متفاوتی دارند و نباید با یکدیگر خلط شوند. انگشت‌نگاری شمارش فونت (Font Enumeration): ابعاد کادر محاطی (bounding box) یک رشته متنی آزمایشی رندرشده با هر فونت از یک فهرست کاندیدا را در مقایسه با فونت‌های پیش‌فرض پشتیبان (fallback) اندازه می‌گیرد؛ وجود تفاوت نشان می‌دهد که آن فونت نصب شده است. فونت‌های نصب‌شده منعکس‌کننده نرم‌افزارهای نصب‌شده روی دستگاه شما هستند (بسته‌هایی مانند Office، Adobe، ابزارهای توسعه، و بسته‌های IME فونت‌های متمایزی به همراه دارند)، که باعث می‌شود فهرست فونت معمولاً بالاترین قدرت تفکیک را در میان کل مجموعه ویژگی‌ها داشته باشد.

💡 تفاوت پایداری ناشی از منشا تغییرات است: هش‌های Canvas و Audio هر زمان که نسخه مرورگر به‌روزرسانی شود (به دلیل تغییر در موتور رندرینگ و کتابخانه محاسبات ریاضی) تغییر می‌کنند، در حالی که فهرست فونت‌ها تنها زمانی تغییر می‌یابد که شما نرم‌افزاری را نصب یا حذف کنید—به همین دلیل این ویژگی بالاترین وزن را به خود اختصاص می‌دهد.

شاخص MSS (حداکثر اندازه سگمنت / Maximum Segment Size) حداکثر بار داده در هر سگمنت TCP است که در زمان دست‌دادن TCP اعلام می‌شود. سرور ما آن را مستقیماً از بسته SYN شما بدون نیاز به هیچ نرم‌افزار کلاینت یا تنظیماتی می‌خواند. افزودن مجدد سربار هدرهای IP و TCP مقدار MTU لینک را بازسازی می‌کند: 40 بایت برای IPv4 اضافه کنید، 60 بایت برای IPv6 اضافه کنید. مقادیر متداول معانی فنی متمایزی دارند: 1500 نشان‌دهنده اترنت استاندارد یا لینک‌های ابری سرور فیزیکی (bare-metal) است؛ 1492 نشان‌دهنده اینترنت پهن‌باند PPPoE (اتصالات خانگی DSL / FTTH) است که در آن هدر 8 بایتی PPPoE حجم داده را کاهش می‌دهد؛ کمتر یا مساوی 1420 نشان‌دهنده یک لایه کپسوله‌سازی اضافی است که معمولاً از تونل‌های VPN مانند WireGuard / Tailscale یا پروکسی‌های مبدا CDN ناشی می‌شود.

⚠ نکته کلیدی این است: MSS پیوند شبکه را توصیف می‌کند، نه دستگاه شما را. این شاخص صرفاً می‌تواند نشان دهد که «کپسوله‌سازی در طول این مسیر وجود دارد» و به خودی خود استفاده از پروکسی را اثبات نمی‌کند—اتصال خانگی PPPoE نیز 1500 نیست. آنچه ارزش تشخیصی واقعی ایجاد می‌کند تناقض است: هنگامی که موقعیت مکانی ادعاشده توسط لایه کاربرد به طور مداوم با ویژگی‌های پیوند انتقال در تعارض باشد (مانند ادعای اتصال مستقیم محلی در حالی که MSS دائماً در محدوده تونل قرار دارد)، این یک سیگنال معنادار خواهد بود. برای جزئیات به تحلیل ناشناسی پروکسی مراجعه کنید.

این جدی‌ترین نوع خطایی است که با بالاترین اولویت با آن برخورد می‌کنیم (ادغام مثبت کاذب / false positive merge)، و با سه خط دفاعی متوالی از آن محافظت می‌نماییم—اگر هر یک از خطوط دفاعی فعال شود، بازیابی هویت رد خواهد شد. نخست، جداسازی سخت باکت‌ها (Hard Bucket Isolation): هویت‌های کاندیدا کاملاً بر اساس پلتفرم OS و هسته موتور مرورگر دسته‌بندی می‌شوند و هیچ مقایسه بین‌باکتی صورت نمی‌گیرد—به این معنی که دو موتور مرورگر مختلف روی یک دستگاه فیزیکی یکسان، حتی با مشخصات سخت‌افزاری کاملاً یکسان، هرگز در یک هویت ادغام نخواهند شد. دوم، وتوی لنگر سخت‌افزاری (Hardware Anchor Veto): تعداد هسته‌های منطقی CPU، ظرفیت حافظه RAM (با تحمل 4GB)، تاخیر پایه صوتی (با تحمل 0.005 ثانیه)، و حداکثر نقاط لمسی: اگر دو طرف مقادیری گزارش کنند که فراتر از آستانه تحمل در تضاد باشند، کاندیدا قبل از امتیازدهی رد می‌شود. سوم، درگاه پذیرش ویژگی‌های اصلی (Core Feature Admission Gate): حتی با وجود یک نمره کل بالا، اگر کاندیدا با هیچ‌یک از ویژگی‌های اصلی با آنتروپی بالا (فونت‌ها، صداها، Canvas، Audio) مطابقت نداشته باشد، انتساب هویت رد می‌شود—این درگاه به طور خاص مانع از آن می‌شود که دسته‌ای از ویژگی‌های عمومی با آنتروپی پایین، نمره بالای غیرواقعی انباشته کنند.

⚠ افشای صادقانه: ما در حال حاضر هیچ نرخ اندازه‌گیری‌شده‌ای از ادغام کاذب در ترافیک واقعی محیط عملیاتی برای انتشار نداریم. این شاخص نیازمند ترافیک زنده و طولی در درازمدت برای سنجش دقیق است؛ اعلام هرگونه درصدی پیش از رسیدن به حجم نمونه کافی، غیرصادقانه خواهد بود.