شرح Browser Fingerprinting: أكثر من 20 إشارة تستخدمها أنظمة Anti-Bot لاكتشاف Automation

تقنية browser fingerprinting هي السبب في اكتشاف Automation التي توصف بأنها “stealth”. وهي أيضًا السبب في أن scriptين لـ Automation يشغّلان code متطابقًا من الجهاز نفسه قد يحققان نسب نجاح مختلفة تمامًا: أحدهما يبدو كزائر حقيقي، والآخر يبدو كـ bot، بينما يكمن الفرق في عشرات signals التي لا يرسلها أي من المطورين عن قصد.

هذا الدليل مرجع كامل يشرح ماهية هذه signals، وكيف تقرؤها أنظمة anti-bot، ولماذا يكون مزيج signals أهم من أي surface منفرد. وهو موجّه إلى بناة AI agent ومشغلي Automation ومهندسي الأمن الذين يحتاجون إلى فهم signal stack كاملًا قبل تصميم حلولهم.

ما Browser Fingerprinting؟

يُعرَّف browser fingerprinting بأنه العملية التي يجمع بها website خصائص قابلة للقياس من browser الزائر وجهازه وشبكته، ثم يدمجها في identifier أو classification يُستخدم للتعرّف إلى ذلك الزائر أو تمييزه أو اكتشافه. وتعمل هذه العملية سواء قبل الزائر cookies أم لم يقبلها، لأن البيانات المقروءة تصف browser environment نفسه لا بيانات مخزنة فيه.

الـ fingerprint ليس قيمة واحدة، بل vector يضم عشرات signals: canvas readbacks، وAudioContext output، وnavigator properties، وأبعاد screen، وقوائم fonts، وtimezone، وخصائص network. تكون هذه signals ضعيفة منفردة، لكنها مجتمعة فريدة بما يكفي لتحديد session أو تصنيفها. ووفق بحث Panopticlick الصادر عن Electronic Frontier Foundation، يعرض browser العادي fingerprint vector فريدًا بين مئات الآلاف من الزوار.

وفي اكتشاف Automation تحديدًا، تقارن أنظمة anti-bot بين signal vector المرصود والأنماط المميزة للـ automated browser. وهي لا تسأل: “من هذا الشخص؟” بل تسأل: “هل يتسق هذا المزيج من signals مع browser حقيقي يستخدمه إنسان، أم مع نمط Automation معروف؟”

كيف يعمل Browser Fingerprinting؟

يعمل browser fingerprinting عبر تشغيل JavaScript، وأحيانًا network-layer probes، لقراءة خصائص browser القابلة للقياس ثم مقارنة vector الناتج بالأنماط المتوقعة. وتجري العملية في ثلاث مراحل.

المرحلة 1: Passive Collection

قبل تشغيل أي script، تكشف network layer بالفعل عدة signals: TLS Client Hello fingerprint، وترتيب HTTP/2 frames، وAccept-Language headers، وموقع IP الجغرافي. تُقرأ هذه signals في connection layer ولا تحتاج إلى JavaScript داخل الصفحة.

المرحلة 2: Active Script-Based Collection

بعد تحميل الصفحة، يقرأ JavaScript خصائص navigator، ويفحص rendering canvas، ويشغّل صوتًا غير مسموع، ويعدّد fonts، ويتحقق من سلوك WebRTC، ويفحص screen metrics. وفي هذه المرحلة تُؤخذ عينات معظم fingerprint surfaces.

المرحلة 3: Cross-Surface Coherence Checks

بعد ذلك يُقيَّم vector بحثًا عن الاتساق الداخلي. إذا كانت القيمة المعلنة navigator.platform = "MacIntel" فيجب أن تتوافق معها GPU strings وقائمة fonts وخصائص audio وtimezone بالطريقة المتوقعة من أجهزة Apple الحقيقية. ويكون عدم التطابق عبر vector إشارة bot أقوى من أي surface منفرد.

هذه المرحلة الثالثة هي ما يهزم معظم أساليب “stealth” على page level. فترقيع property واحدة من دون مواءمة كل surfaces التابعة لها ينشئ coherence failure تبحث عنه detection systems تحديدًا.

Network-Layer Fingerprints

تؤخذ عينات network-layer fingerprints قبل أن ينفذ browser سطرًا واحدًا من JavaScript الخاص بالصفحة. ويصعب انتحالها خصوصًا لأنها تأتي من operating system أو browser binary، لا من page environment.

TLS Fingerprint ‏(JA3 / JA4)

تحتوي رسالة TLS Client Hello، التي تُرسل في بداية كل اتصال HTTPS، على cipher suites التي يدعمها client بترتيب محدد، إضافة إلى extensions وsupported elliptic curves وsignature algorithms. ويُسمى hash الناتج من هذا المزيج JA3 fingerprint، أو JA4 في نسخته الأحدث. تنتج إصدارات Chromium المختلفة قيم JA3/JA4 hash مختلفة، كما تنتج Automation libraries التي تبني TLS handshakes بنفسها بدل المرور عبر Chromium قيمًا لا تطابق أي browser حقيقي. وكما توضح مواصفة JA3 مفتوحة المصدر من Salesforce، تُستخدم هذه التقنية على نطاق واسع في أبحاث الأمن واكتشاف bot.

HTTP/2 Fingerprint

يختلف ترتيب HTTP/2 frames ومحتواها، مثل SETTINGS وWINDOW_UPDATE وHEADERS، بحسب client implementation. يرسل Chrome الحقيقي ترتيبًا محددًا للـ frames، بينما ترسل كثير من HTTP/2 clients المستخدمة في Automation ترتيبًا مختلفًا. وتُقرأ هذه الإشارة عند network edge.

ترتيب Header وحالة الأحرف

تُعد HTTP headers غير مرتبة وفق specification، لكن browsers الحقيقية ترسلها بترتيب ثابت وحالة أحرف محددة (User-Agent لا user-agent). وكثيرًا ما تنتج Automation libraries ترتيبًا أو حالة أحرف مختلفة.

الموقع الجغرافي للـ IP وASN

يحمل IP address نفسه metadata تشمل geolocation وASN، أي الشبكة التي ينتمي إليها، وسمعتها. ويكون datacenter IP صادرًا عن cloud provider معروف إشارة bot أقوى من residential IP صادر عن ISP. وكما توضح وثائق GeoIP من MaxMind، تستطيع geolocation databases التمييز بين residential وdatacenter وmobile IP بدرجة دقة معقولة.

Rendering Surfaces

تستفيد rendering fingerprints من أن GPU وdriver وgraphics stack تنتج فروقًا طفيفة في output حتى مع input متطابق. وهي قوية خصوصًا لأنها تعكس hardware فعليًا لا مجرد software configuration.

Canvas 2D Fingerprint

ترسم الصفحة نصوصًا وأشكالًا محددة داخل عنصر <canvas> مخفي، ثم تقرأ pixel data باستخدام toDataURL(). تختلف قيم pixel الدقيقة باختلاف operating system وإصدار browser وfont rendering library وGPU. ينتج اختبار canvas نفسه على browser نفسه hash ذاته؛ ويتطلب الانتحال مطابقة لاختبار واحد فحسب، بل لكل variation قد يشغّلها detection script.

WebGL Fingerprint

تستعلم الصفحة من WebGL عن GPU vendor وrenderer strings، مثل “Apple Inc.” و“Apple M2 Pro”، ثم ترسم test geometry وتقرأ framebuffer. ويمكن استخدام كل من strings وrendering result في fingerprinting. ويكشف WebGL كذلك supported extensions وparameter limits وshader precision، وكلها ذات صلة بالـ fingerprint.

Client Rects وBounding Boxes

تختلف أبعاد عناصر DOM المعروضة (getBoundingClientRect()) على مستوى sub-pixel باختلاف font rendering وإصدار browser. وحتى عندما تكون fonts متطابقة، يختلف anti-aliasing بين operating systems وGPU drivers.

Audio Surfaces

AudioContext Fingerprint

تنشئ الصفحة OscillatorNode، وتولد tone، وتعالجه عبر analyzer، ثم تقرأ waveform الناتج. يختلف output تبعًا لـ audio library وطريقة التعامل مع sample rate وfloating-point implementation بين المنصات. وهذا من أصعب surfaces التي يمكن انتحالها باتساق.

Speech Synthesis Voices

speechSynthesis.getVoices() يعيد قائمة text-to-speech voices المثبتة في النظام. وتعتمد القائمة على OS: لدى macOS مجموعة محددة، ولدى Windows مجموعة أخرى، بينما تختلف Linux باختلاف distribution. ولا تكشف هذه القائمة OS فقط، بل قد تميز بين إصداراته.

Navigator Surfaces

يكشف object المسمى navigator مجموعة من browser identity properties. ترقيع بعض إعدادات stealth لعدد قليل منها، لكن coherent identity يتطلب ترقيعها كلها باتساق.

User-Agent String

هذه أوضح property وأكثرها ترقيعًا. وبحلول 2026، تتعامل detection systems المتقدمة مع user-agent بوصفه signal واحدة ضمن كثير غيرها؛ فوجود UA نظيف مع navigator.platform بطابع Linux هو بحد ذاته flag.

Platform

navigator.platform يعيد قيمًا مثل “MacIntel” أو “Win32” أو “Linux x86_64”. ويجب أن تتطابق مع user agent وقائمة fonts وaudio output وGPU strings.

Languages وAccept-Language

navigator.languages يعيد اللغات المفضلة لدى المستخدم. ويجب أن تتوافق مع HTTP header المسمى Accept-Language ومع timezone وموقع IP الجغرافي. فالمستخدم الذي يعلن ["en-US", "en"] من Frankfurt IP وفي timezone باسم Europe/Berlin يثير الشبهة.

Hardware Concurrency

navigator.hardwareConcurrency يعيد عدد logical CPU cores. ويجب أن يكون الرقم منطقيًا للجهاز المعلن: MacBook Air لا يضم 64 core، ونادرًا ما يضم server VM أربعًا فقط.

Device Memory

navigator.deviceMemory يعيد قيمة RAM تقريبية بالـ GB بعد تقريبها إلى مجموعة صغيرة من القيم. ويجب أن تكون منطقية لفئة الجهاز المعلنة.

Plugins وMIME Types

تعيد إصدارات Chrome الحديثة قائمة plugins فارغة افتراضيًا، بينما كانت browsers الأقدم تعرض PDF viewers وFlash وغيرها. وتخطئ إعدادات stealth كثيرة هنا، فتعرض plugins من browsers قديمة داخل session تزعم استخدام إصدار Chrome حديث.

Display وLocale Surfaces

Screen Metrics

screen.width يشكل مع وscreen.height وscreen.availWidth وscreen.availHeight وwindow.devicePixelRatio. ويجب أن تتطابق مع فئة جهاز حقيقية. فوجود screen بدقة 1366×768 مع devicePixelRatio = 3 غير منطقي؛ إذ تحكم مجموعات hardware الفعلية هذه التركيبات.

Timezone

Intl.DateTimeFormat().resolvedOptions().timeZone يعيد معرف IANA timezone. ويجب أن يتطابق مع موقع IP الجغرافي وتفضيلات اللغة.

Fonts

قائمة fonts المتاحة للـ browser هي fingerprint surface عالية entropy. تأتي operating systems المختلفة مع default fonts مختلفة، وتضيف البرامج المثبتة المزيد. تعدّد detection systems الـ fonts عبر canvas measurement، فترسم الحروف بكثير من fonts وتتحقق من اختلاف العرض. ويجب أن تتطابق قائمة fonts مع OS المعلن.

Color Gamut ودعم HDR

تكشف browsers الحديثة screen.colorGamut وmedia queries المرتبطة بـ HDR. ويجب أن تتطابق هذه القيم مع فئة display المعلنة.

Network وIdentity Leakage Surfaces

تسرب WebRTC IP

قد يكشف STUN protocol في WebRTC الـ local IP حتى عندما يعمل browser خلف proxy. ومن دون معالجة صريحة، يستطيع browser موجّه عبر proxy تسريب residential IP الحقيقي عبر WebRTC ICE candidates. وهذا silent killer في Automation المعتمد على proxy. يتمثل mitigation القياسي في إجبار WebRTC على relay-only mode، ما يمنع التسرب لكنه يظل إعدادًا ملحوظًا يدل على تركيز شديد على الخصوصية أو على Automation.

تسرب DNS

حتى عندما يستخدم browser proxy، قد يجري DNS resolution عبر local resolver، فيكشف ISP الحقيقي. يعالج DNS-over-HTTPS المشكلة جزئيًا، لكنه يقدم fingerprint signals خاصة به.

حالة Permissions API

تعرض Permissions API حالة permissions مثل notifications وgeolocation وcamera. وقد تكون حالة default-deny لجميع permissions إشارة bot، لأن المستخدمين الحقيقيين لديهم histories متنوعة.

لماذا تمثل Fingerprint Coherence المشكلة الحقيقية؟

Fingerprint coherence هي خاصية fingerprint vector التي تجعل كل surface قابلة للرصد متسقة مع بقية surfaces بالطريقة التي تنتجها hardware حقيقية. وهذا هو المبدأ الذي يهزم معظم أساليب “stealth”.

يستطيع stealth plugin تغيير navigator.webdriver إلى false، وتجاوز user agent، وإضافة noise إلى canvas readbacks. لكنه لا يستطيع بسهولة ضمان أن:

• يعلن user agent عن Chrome 131 على macOS
• تعرض platform القيمة “MacIntel”
• تطابق قائمة fonts تثبيت macOS حقيقيًا
• يطابق GPU vendor string شريحة Apple
• يطابق AudioContext output نظام CoreAudio من Apple
• تكون timezone في Pacific أو Eastern، لا Berlin أو Tokyo
• يطابق accept-language المنطقة الزمنية
• يوجد proxy IP في United States وفي منطقة متسقة مع timezone
• تكون أبعاد screen منطقية لـ Apple display

عندما يختل أي عنصر من هذه العناصر، تضع detection systems علامة على session، لا لأن surface المنفردة مريبة، بل لأن المزيج غير منطقي. ولهذا يوجد سقف لقدرات Tier 3 stealth plugins التي تعمل على page level: تستطيع انتحال properties منفردة، لكنها لا تستطيع بسهولة إنشاء profile متسق عبر كل surface تابعة.

تحل engine-level fingerprint patches، أي التعديلات داخل Chromium binary نفسه، هذه المشكلة بإنشاء profiles تُشتق فيها جميع surfaces من coherent identity model واحد. تستخدم أدوات مثل Clawbrowser مكتبة Rust مدمجة لإنشاء coherent fingerprint profile وتحميله في shared memory عند بدء browser، بحيث يقرأ renderer وGPU code القيم المحلية نفسها للعملية من دون page-level glue.

يؤثر موضع تشغيل identity model في مقدار سيطرتك على profile persistence وnetwork routing وbrowsing data. وتشرح مقارنة Clawbrowser وBrowserbase المفاضلات بين local fingerprint management وcloud browser infrastructure.

أمثلة واقعية على Coherence Failure

المثال 1: مفارقة German Residential Proxy

يشتري operator residential proxies في Germany لجمع بيانات German job board. يستخدم script لديه playwright-stealth، الذي يرقّع navigator properties ليزعم أنه US Chrome. فتقدم session قيم en-US وAmerica/New_York مع German residential IP. يكتشف Cloudflare bot management عدم التطابق فورًا. والحل ليس stealth patches أفضل، بل ضبط locale وtimezone وIP لتتطابق كلها مع Germany.

المثال 2: Headless Container Fingerprint

يشغّل development laptop نظام macOS مع مجموعة fonts كاملة وApple GPU. وتشغّل CI environment نظام Linux داخل Docker مع default Debian font set وsoftware rendering عبر llvmpipe. نفس Playwright script ونفس stealth plugin ونفس accounts، لكن fingerprint vectors مختلفة تمامًا. يبدو debugging في production وكأن “script تعطل”، بينما المشكلة الحقيقية هي environmental drift.

المثال 3: Reused Canvas Fingerprint

تبدّل scraping operation قيم user agent بين 1,000 session. لكن كل هذه sessions تستخدم الجهاز نفسه وcanvas readback نفسه وWebGL renderer string نفسه. فتجمعها detection systems في identity واحدة بصرف النظر عن تدوير user-agent، لأن canvas/WebGL hash متطابق بينها جميعًا.

Browser Fingerprinting مقارنة بـ Cookies

الجانب	Cookies	Browser fingerprinting
موضع التخزين	Browser disk	لا مكان — تُشتق عند request time
تحكم المستخدم	يمكن مسحها أو حظرها أو رفضها	لا يمكن إيقافها
الاستمرارية	حتى انتهاء الصلاحية أو الحذف	تستمر عبر sessions والأجهزة ذات identity نفسها
النطاق	لكل domain	لكل browser instance
الاستخدام في tracking	يتطلب عادة explicit consent وفق GDPR	يُستخدم في tracking وكذلك في security/anti-bot
هل يحدد returning user؟	نعم، إذا استمرت cookie	غالبًا، بحسب entropy

الفرق العملي الأساسي هو أن cookies تتطلب موافقة المستخدم في معظم الولايات القضائية، بينما يندرج fingerprinting لأغراض الأمن، مثل fraud detection وbot mitigation، عادة ضمن استثناءات legitimate interest. ولهذا تظهر cookie banners، بينما يعمل fingerprint-based detection من دون أن يراه المستخدم.

الأسئلة الشائعة

كم عدد Fingerprint Signals التي تستخدمها أنظمة Anti-Bot فعليًا؟

تستخدم أنظمة production عشرات signals. يختلف العدد الدقيق بحسب vendor، لكن الأبحاث العامة مثل وثائق مشروع FingerprintJS مفتوح المصدر تصف أكثر من 60 signal في fingerprint vector القياسي، وعادة ما تقرأ enterprise anti-bot vendors عددًا أكبر.

هل يمكنني تعطيل Fingerprinting في Browser؟

جزئيًا. تحاول browsers مثل Tor Browser وBrave تقليل fingerprint entropy عبر توحيد كثير من surfaces، وينفذ وضع Resist Fingerprinting في Firefox عملًا مشابهًا. يقلل ذلك قابلية التعرف لكنه لا يلغيها، كما ينشئ fingerprint signature خاصة تستطيع أنظمة anti-bot تحديدها بوصفها “fingerprint-resistant browser”.

لماذا لا تمنع VPN خدمة Fingerprinting؟

تخفي VPN الـ IP address، وهو fingerprint surface واحدة من بين كثير. لكنها لا تفعل شيئًا تجاه canvas أوWebGL أوaudio أوnavigator properties أوscreen أوfonts أوtimezone أوأي browser-side signal آخر. وقد تجعل VPN الوضع أسوأ إذا قال IP إنه في “Frankfurt” بينما لا تزال كل surfaces الأخرى تقول “California”.

هل Browser Fingerprinting قانوني؟

نعم في معظم الولايات القضائية، خصوصًا عند استخدامه لأغراض أمنية مثل fraud detection وbot mitigation. أما fingerprinting لأغراض marketing أوbehavioral tracking فيخضع لقواعد الخصوصية مثل GDPR وCCPA على نحو مشابه لـ cookies. ويتطور المشهد القانوني باستمرار، لذا استشر مختصًا قانونيًا مؤهلًا في مسائل الامتثال المحددة.

ما الفرق بين Browser Fingerprinting وDevice Fingerprinting؟

يقرأ browser fingerprinting signals المتاحة عبر browser APIs وسلوك network. ويشمل device fingerprinting signals إضافية من native apps وmobile SDKs وبيانات على operating-system level لا يستطيع browser الوصول إليها. ويتداخل المجالان بدرجة كبيرة؛ ويشير “browser fingerprinting” عادة إلى المجموعة المتاحة عبر web.

الخلاصة: Coherence يتفوق على Spoofing

الخلاصة من أكثر من عشرين signal ليست “رقّع كل signal”، بل إن signals تتفاعل، وأن ترقيع واحدة من دون مواءمة البقية ينشئ fingerprint أسوأ من عدم الترقيع أصلًا. ويمثل fingerprint coherence، أي محاذاة كل surface مع الأخرى ومع network egress، الحل الدائم الوحيد.

ولهذا يكون المكان الأعلى تأثيرًا لمعالجة fingerprinting داخل browser binary نفسه، مع profile-bound proxy routing يضمن تطابق موقع IP الجغرافي مع timezone وlocale وتفضيلات اللغة. ستواصل page-level patches فقدان فعاليتها، بينما تظل coherent profiles المنشأة في engine layer هي الإصلاح البنيوي.

Clawbrowser بُني حول هذا المبدأ. تُنشأ profiles لتطابق تركيبات واقعية: platform وfonts وtimezone وموقع proxy الجغرافي مصطفة معًا، فلا تظهر signals المتناقضة التي تؤدي إلى CAPTCHA وفحوص anti-bot يمكن تجنبها. ولمزيد من التفاصيل عن runtime architecture والتغطية surface by surface، راجع Clawbrowser documentation.