فحص بصمة المتصفح: كشف تفرد Canvas و WebGL و AudioContext والأجهزة

تقييم شامل للبصمة والبيئة

فحص بصمة المتصفح

بصمة المتصفح هي معرّف فريد يُنشأ عبر جمع سمات عتاد الجهاز، والخطوط، وتقنيات تصيير الرسوميات.

SHA-256 Hash جاري الفحص...
كشف التلاعب والتحوير
جاري الفحص...
التعرف على الروبوتات (Bot)
جاري الفحص...
تسريب WebRTC
جاري الفحص...
درجة التفرد
جاري الفحص...

الأجهزة والبيئة الأساسية

جاري الفحص...

                            

الرسوميات والعرض المرئي

جاري الفحص...

                            

المتصفح والأمان

جاري الفحص...

                            

البصمات الدقيقة المتقدمة

جاري الفحص...

                            

الشبكة و WebRTC

جاري الفحص...

                            

مسابير القدرات والبيئة

جاري الفحص...

                            

ملخص تقييم البصمة ومساحات الانكشاف

جاري الفحص...
جاري الفحص...
تحليل بصمة حزمة بروتوكولات الشبكة عبر الطبقات

الجمع بين تفرد بصمة المتصفح (Canvas / WebGL) وبصمات حزم TCP/TLS/QUIC على مستوى الخادم لتقييم شامل لمخاطر التتبع ومقاومة الارتباط.

فحص بصمة حزمة بروتوكولات الشبكة →

الأسئلة الشائعة حول بصمة المتصفح والخصوصية

تعرف على كيفية عمل بصمات المتصفح، وتناقضات الطبقات المتعددة، وحدود متصفحات مكافحة التتبع، وحقيقة التصفح المتخفي.

إن تغيير ترويسة User-Agent وحدها لا يفشل فقط في تمويه متصفحك، بل يخلق أيضاً "تناقضات عبر الطبقات" صارخة تُطلق أنظمة كشف الاحتيال المتقدمة: أولاً، عدم تطابق طبقة التطبيقات مع مكدس النقل: إذا قمت بضبط UA لمتصفح Windows ليظهر كأنه iPhone Safari، فإن ترويسة HTTP تزعم أنه جهاز Apple محمول، لكن حزمة TCP SYN الخاصة بك تُظهر بصمة نواة Windows (بدون خيار TS وترتيب خيارات هو MSS, NOP, WS, NOP, NOP, SACK_PERM)، مما يتعارض مباشرة مع تسلسل خيارات Apple المكون من 8 خيارات. ثانياً، ثوابت بروتوكولي 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 وتعديل واجهات برمجة التطبيقات كلاً من Function.prototype.toString و Object.getOwnPropertyDescriptor وسلاسل وراثة النماذج الأولية. ثانياً، ثوابت معالج الرسوميات والمظلل (Shader): في حين تغير الضوضاء المحقونة تجزئة الصورة المعروضة، فإن دقة الفاصلة العائمة لمعالج الرسوميات الفيزيائي وأنماط التنقيط للمظلل تظل ثابتة؛ وغالباً ما تشكل الضوضاء الاصطناعية توقيعاً يسهل التعرف عليه بذاته. ثالثاً، حزم الشبكة الأساسية غير المعدلة: تعمل معظم متصفحات مكافحة الكشف على مستوى JavaScript فقط ولا تحاكي خصائص مصافحة TCP/TLS لنظام التشغيل المضيف.

كلا. تم تصميم وضع التصفح المتخفي حصرياً لمنع "آثار التصفح المحلية على جهازك الخاص"، وليس لمنع "التعرف عن بُعد بواسطة مواقع الويب". عند إغلاق نافذة التصفح المتخفي، يتم التخلص من ملفات تعريف الارتباط المحلية و localStorage وسجل التصفح. ومع ذلك، تعمل بصمة المتصفح عن طريق قياس سمات العتاد والبرامج الفعلية عبر JavaScript (بما في ذلك عرض رسومات GPU، ودقة مظهر WebGL، والخطوط المثبتة، واستجابة مذبذب الصوت، وتزامن وحدة المعالجة المركزية، وعمق الألوان). ونظراً لأن عتادك الفعلي، وبرامج تشغيل الرسوميات، ومحرك عرض المتصفح متطابقة تماماً في وضع التصفح المتخفي، فإن تجزئة البصمة الناتجة التي تولدها الخوادم البعيدة تظل دون تغيير.

هذه ليست نتيجة إيجابية خاطئة — بل تعكس البنية الأساسية لنظام 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)، ثم قراءة قيم عينات الفاصلة العائمة وحساب تجزئتها. ينتج عن نفس مخطط المعالجة الصوتية فروق طفيفة في البتات الأقل أهمية عبر تطبيقات المتصفحات المختلفة ومكتبات الرياضيات ومحركات الفاصلة العائمة، كل ذلك دون تشغيل أي صوت مسموع. مجاور لها ولكن مستقل تماماً توجد خاصية AudioContext.baseLatency: تعكس هذه القيمة حجم المخزن المؤقت لمخرج بطاقة الصوت الذي تحكمه برامج تشغيل الصوت والعتاد؛ يعاملها نظامنا كـ ركيزة عتاد (فارق يتجاوز 0.005 ثانية يستبعد التطابق فوراً) وليس كتجزئة هوية — فلهما أصول مختلفة ولا ينبغي الخلط بينهما. بصمة تعداد الخطوط: تقيس المربع المحيط لسلسلة نصية اختبارية معروضة بكل خط من قائمة المرشحين مقارنة بخطوط الرجوع الافتراضية؛ وتشير التناقضات إلى أن الخط مثبت. تعكس الخطوط المثبتة البرامج المثبتة على جهازك (حيث تجلب حزم مثل Office و Adobe وأدوات التطوير وحزم IME خطوطاً مميزة)، مما يجعل قائمة الخطوط عادة المقياس الفردي الأعلى تمييزاً في مجموعة السمات بأكملها.

💡 ينبع اختلاف الاستقرار مما يؤدي إلى حدوث التغييرات: تنحرف تجزئات Canvas والصوت كلما تم تحديث إصدار المتصفح (بسبب تغييرات محرك العرض ومكتبات الرياضيات)، بينما تتغير قائمة الخطوط فقط عندما تثبت أو تزيل برامج — ولهذا السبب تحظى بأعلى وزن.

يُمثل MSS (الحد الأقصى لحجم المقطع) أقصى حمولة بيانات لكل مقطع TCP يتم الإعلان عنها أثناء مصافحة TCP. ويقرأ خادمنا هذه القيمة مباشرة من حزمة SYN الخاصة بك دون الحاجة إلى أي برامج عميل أو إعدادات مسبقة. وبإعادة إضافة العبء الإضافي لترويسات IP و TCP، تتم إعادة بناء MTU للارتباط: أضف 40 بايت لـ IPv4، وأضف 60 بايت لـ IPv6. وتحمل القيم الشائعة دلالات تقنية متميزة: تشير 1500 إلى شبكة Ethernet القياسية أو ارتباطات السحابة المباشرة (bare-metal)؛ وتشير 1492 إلى النطاق العريض عبر PPPoE (اتصالات DSL / FTTH السكنية)، حيث تُقلل ترويسة PPPoE المكونة من 8 بايت من سعة الحمولة؛ بينما تشير القيمة أقل من أو تساوي 1420 إلى وجود طبقة تغليف إضافية، تنشأ عادةً عن أنفاق VPN مثل WireGuard / Tailscale أو وكلاء أصل CDN (CDN origin proxies).

⚠ النقطة الأساسية هي: يصف MSS ارتباط الشبكة، وليس جهازك. فهو يشير فقط إلى أن "التغليف موجود على طول هذا المسار"، ولا يثبت بمفرده استخدام البروكسي — إذ إن اتصالات PPPoE السكنية ليست 1500 أيضاً. ما يوفر قيمة تشخيصية حقيقية هو التناقض: فعندما يتعارض الموقع الذي تدعيه طبقة التطبيقات باستمرار مع سمات ارتباط النقل (مثل الادعاء باتصال مباشر محلي بينما يقع MSS باستمرار في نطاق الأنفاق)، يُشكل ذلك إشارة ذات دلالة واضحة. راجع تحليل إخفاء هوية البروكسي لمعرفة التفاصيل.

هذا هو نوع الخطأ الذي نتعامل معه بأعلى درجات الجدية (الدمج الإيجابي الخاطئ)، ونحمي ضده بثلاثة خطوط دفاع متسلسلة — إذا انطلق أي دفاع، يُرفض الاسترداد. أولاً، العزل الصارم للأقسام: يتم تقسيم هويات المرشحين بدقة حسب منصة نظام التشغيل ونواة محرك المتصفح، مع انعدام المقارنات عبر الأقسام — مما يعني أن محركي متصفح مختلفين على نفس الجهاز الفيزيائي، حتى مع تطابق معلمات العتاد، لن يُدمجا أبداً في هوية واحدة. ثانياً، حق الفيتو لركائز العتاد: عدد الأنوية المنطقية لـ CPU، وسعة ذاكرة RAM (تفاوت 4GB)، وزمن انتقال الصوت الأساسي (تفاوت 0.005 ثانية)، ونقاط اللمس القصوى: إذا أبلغ الجانبان عن قيم تتعارض بما يتجاوز التفاوت المسموح، يتم استبعاد المرشح قبل تسجيل النقاط. ثالثاً، بوابة قبول السمات الأساسية: حتى مع وجود درجة مركبة عالية، إذا كان المرشح يطابق صفر سمة من السمات الأساسية عالية الإنتروبيا (الخطوط، الأصوات، Canvas، الصوت)، يُرفض الادعاء — تمنع هذه البوابة على وجه التحديد مجموعة من السمات العامة منخفضة الإنتروبيا من جمع درجة عالية غير مستحقة.

⚠ إفصاح أمين: ليس لدينا حالياً معدل دمج خاطئ مقاس من حركة الإنتاج الفعلية لننشره. يتطلب هذا المقياس حركة مرور حية طولية طويلة الأجل لتحديده كمياً وبدقة؛ وسيكون ذكر أي نسبة مئوية قبل الوصول إلى حجم عينة مناسب أمراً غير أمين.