يعتقد قطاع واسع من مستخدمي الإنترنت أن التصفح عبر نافذة التخفي أو النوافذ الخاصة يضمن إزالة كل أشكال التتبع الرقمي. في نماذج الأمان التقليدية، يؤدي إغلاق الجلسة الخاصة بالفعل إلى مسح ملفات تعريف الارتباط المؤقتة وسجلات التخزين المحلي وقواعد بيانات IndexedDB. ومع ذلك، طورت شبكات التحليلات الإعلانية تقنيات أعمق ترتكز على الخصائص الهيكلية لبروتوكولات الإنترنت الأساسية. ومن خلال استغلال آليات التخزين المؤقت للبروتوكولات، يتم بناء معرفات دائمة عبر الجلسات تُعرف باسم الكوكيز الفائقة (Supercookies).

تبرز في هذا المجال وسيلتان متطورتان للتتبع ذي الحالة: متجهات حالة أمان النقل الصارم (HSTS) وأشجار إعادة التوجيه لذاكرة الأيقونات المفضلة (Favicon). تستغل هذه الأساليب ميزات الأداء والأمان المدمجة في المتصفحات الحديثة لكتابة معرف رقمي فريد مباشرة على جهاز المستخدم دون الاعتماد على ملفات تعريف الارتباط المعتادة.

[متصفح المستخدم]
  │
  ├─ تخزين الكوكيز المعتاد   ──> [يُمحى عند إغلاق التصفح الخاص]
  ├─ التخزين المحلي / IndexedDB ──> [يُمحى عند إغلاق التصفح الخاص]
  │
  ├─ جدول حالات بروتوكول HSTS ──> [يظل محفوظاً في ملف تعريف الشبكة]
  └─ قاعدة بيانات الأيقونات SQLite ──> [مشتركة بين النوافذ والتبويبات]

الهندسة التقنية لكوكيز HSTS الفائقة

تفرض مواصفة أمان النقل الصارم HTTP (المعروفة باسم HSTS والمعتمدة في معيار RFC 6797) على المتصفح التواصل مع النطاق حصرياً عبر اتصالات HTTPS المشفرة. عندما يرسل خادم الويب ترويسة الاستجابة Strict-Transport-Security: max-age=31536000; includeSubDomains، يُسجل المتصفح سياسة أمان محلية. وعلى مدار الأيام الـ 365 التالية، يتم تحويل أي محاولة للوصول إلى هذا النطاق عبر بروتوكول HTTP غير المشفر تلقائياً إلى HTTPS قبل مغادرة الحزم لمحول الشبكة.

ورغم أن الهدف الأساسي للمعيار هو منع هجمات خفض مستوى التشفير، إلا أنه ينشئ عملياً خانة تخزين ثنائية أحادية البت: فإما أن النطاق الفرعي مسجل في جدول HSTS المحلي (القيمة 1)، أو أنه غير موجود (القيمة 0).

مصفوفة خوادم التتبع (tracker-network.example)
  ├── bit00.tracker-network.example (تم تسجيل HSTS = 1)
  ├── bit01.tracker-network.example (لم يتم التسجيل = 0)
  ├── bit02.tracker-network.example (تم تسجيل HSTS = 1)
  └── ... (من 32 إلى 64 نطاقاً فرعياً مستقلاً)

تجمع محركات الرصد هذه الخانات الثنائية لبناء معرف رقمي متكامل:

  1. مرحلة كتابة الحالة: عند زيارة المستخدم لموقع يحتوي على شيفرة تتبع برمجية، تُطلق الشيفرة سلسلة من الطلبات الخفية إلى 32 نطاقاً فرعياً مخصصاً (bit01 إلى bit32). ولكل خانة في المعرف الثنائي المحسوب للجهاز (مثل 11010010...)، يُرجع الخادم استجابة HTTPS تحتوي على ترويسة HSTS فقط للنطاقات الفرعية المقابلة لقيمة البت 1. أما النطاقات المقابلة للصفر، فإما ألا تُمنح الترويسة أو لا يتم الاتصال بها عبر HTTPS.
  2. مرحلة قراءة الحالة: في الزيارات اللاحقة أو عبر مواقع شريكة أخرى، تُرسل الشيفرة طلبات صور HTTP عادية (http://bitXX...) إلى كافة النطاقات الفرعية الـ 32. فإذا كان النطاق مسجلاً مسبقاً في جدول HSTS، يقوم المتصفح تلقائياً بترقية الطلب داخلياً إلى https://. وإذا لم يكن مسجلاً، يُرسل الطلب بنص صريح عبر http://.
  3. إعادة تكوين المعرف: يرصد خادم التتبع المنافذ المستقبلة للطلبات: المنفذ الآمن 443 (HTTPS) أم المنفذ العادي 80 (HTTP). ومن خلال تعيين المنفذ 443 كقيمة ثنائية 1 والمنفذ 80 كقيمة صفر، يعيد الخادم تركيب المعرف المكون من 32 بت في غضون أجزاء من الثانية.

ونظراً لأن واجهات مسح بيانات المتصفح تفصل عادة بين ملفات تعريف الارتباط وبيانات الأمان الشبكي للبروتوكولات، تظل جداول HSTS محفوظة في كثير من الأحيان بعد عمليات التنظيف التقليدية.

تحديد الهوية عبر ذاكرة الأيقونات المفضلة

يوفر التخزين المؤقت لأيقونات المواقع (Favicons) مسار تتبع بالغ الدقة. تخزن المتصفحات الحديثة أيقونات المواقع في قاعدة بيانات SQLite محلية مخصصة (مثل جدول Favicons في متصفحات كروميوم) لعرض التبويبات وقوائم العلامات وسجل التصفح بسرعة دون انتظار استجابة الشبكة.

وبخلاف الذاكرة المؤقتة لملفات الويب التي تخضع لإرشادات Cache-Control، كانت طلبات استرداد الأيقونات المفضلة تُعالج تاريخياً خارج بيئة العزل الصارمة للمستند:

[محرك تصفح الويب]
  │
  ├─ الخطوة 1: طلب وثيقة الصفحة الأساسية
  │
  ├─ الخطوة 2: اكتشاف وسم الأيقونة <link rel="icon" href="/node-A.ico">
  │
  ├─ الخطوة 3: الاستعلام من قاعدة SQLite المحلية للأيقونات
  │     ├── الأيقونة موجودة: قراءة من القرص (دون إرسال طلب للشبكة)
  │     └── الأيقونة مفقودة: إرسال طلب شبكي HTTP GET إلى الخادم
  │
  └─ مصفوفة التحليل: تسجيل الطلبات الواصلة لتحديد التسلسل الثنائي

أثبتت أبحاث قُدمت في مؤتمر USENIX للأمان الرقمي قدرة خوادم التحليل على إنشاء شجرة تفرع ديناميكية تعتمد على توجيهات HTTP 302 عبر مسار من الأيقونات. إذا كان المتصفح قد خزن الأيقونة من تفرع سابق، فإنه يقرؤها محلياً ويتوقف عن إرسال الطلبات؛ أما إذا كانت غير مخزنة، فيصدر طلباً عبر الشبكة. وعبر مراقبة الاتصالات التي تصل إلى الخادم، يتحدد المسار الدقيق للجهاز داخل شجرة القرار، مما ينتج بصمة رقمية ثابتة ترتبط بعتاد المستخدم.

حدود آليات الحماية المدمجة في المتصفحات

أدخل مطورو برامج التصفح تدابير هندسية متقدمة للحد من هذه المخاطر:

  • تقسيم حالات التخزين (State Partitioning): تعتمد المحركات الحديثة مفاتيح عزل مزدوجة (مثل الحماية الشاملة للكوكيز في فايرفوكس وتقسيم شبكة الاتصال في كروميوم). يتكون مفتاح التخزين من دمج نطاق الموقع الأساسي مع نطاق المورد (top_level_site, resource_site). وبذلك، لا يمكن قراءة الحالة المسجلة على موقع معين مباشرة من موقع آخر.
  • جداول HSTS المؤقتة لجلسات التخفي: تُنشئ الإصدارات المحدثة من المتصفحات جدول HSTS مؤقتاً لنوافذ التصفح الخاص، يتم التخلص منه بالكامل بمجرد إغلاق النافذة.

ومع ذلك، فإن العزل على مستوى المتصفح لا يعالج مشكلة تحليل بيانات التعريف الشبكية:

  1. التمويه عبر سجلات CNAME للنطاق الأساسي: عندما يفوض مالك الموقع نطاقاً فرعياً لمنصة تتبع خارجية عبر سجل DNS CNAME، تعمل المنصة بصفتها طرفاً أول، مما يُبطل حدود العزل بين المواقع.
  2. عناصر WebView المشتركة على الهواتف: في بيئتي أندرويد و iOS، تعتمد التطبيقات على مكون WebView المدمج بالنظام لعرض صفحات الويب، وغالباً ما تتشارك هذه المكونات مكدس الشبكة والذاكرة المؤقتة دون تطبيق عزل صارم.
  3. ربط الهوية عبر البيانات الوصفية للشبكة: حتى مع تقسيم الذاكرة المؤقتة، تستطيع خوادم التتبع ربط الأقسام المستقلة ببعضها باستخدام عنوان IP العام للعميل، ورقم النظام المستقل لمزود الخدمة (ASN)، وبصمة مكدس TLS.

عزل مسارات التتبع باستخدام RiceGuard

تنجح حواجز المتصفح في حماية التخزين المحلي على القرص، لكنها تعجز عن حجب بيانات الشبكة التي تعتمد عليها خوادم الرصد لتأكيد الهوية. فعندما يستقبل خادم التحليلات طلبات قادمة من مساحات تخزين معزولة، فإنه يقارنها استناداً إلى عنوان IP ومسار المزود.

يقدم VPNRice حلاً وقائياً على مستوى الطبقة الثالثة (Layer 3) عبر بروتوكول RiceGuard:

[متصفح الجهاز والتطبيقات المحلية]
  │
  │ (فحوصات HSTS / استعلامات النطاقات الفرعية / طلبات الأيقونات)
  ▼
[واجهة شبكة RiceGuard الافتراضية]
  │
  ├─ نفق تشفير Chacha20-Poly1305 الفائق (RFC 8439)
  ├─ وكيل DNS مشفر مانع للتسريب (اعتراض المنفذين 53 و 853)
  │
  ▼
[مجموعة خوادم الخروج التابعة لـ VPNRice]
  │
  ├─ عناوين IP عامة مشتركة ذات كثافة عالية
  ├─ فصل الارتباط ببيانات مزود خدمة الإنترنت المنزلي
  │
  ▼
[خوادم الويب المستهدفة ومنصات التتبع]
  1. فصل ركائز الهوية الشبكية: يوجه RiceGuard حركة مرور البيانات بالكامل عبر أنفاق WireGuard المحصنة. وعندما ترصد أنظمة التتبع فحوصات HSTS أو اتصالات الأيقونات، يظهر عنوان خوادم VPNRice كمصدر للاتصال، مما يمنع ربط بيانات التخزين المؤقت باشتراك الإنترنت المنزلي أو الموقع الجغرافي.
  2. عزل استعلامات DNS عبر نفق مشفر: يتطلب فحص كوكيز HSTS إرسال عشرات الاستعلامات المتلاحقة للنطاقات الفرعية (bit01 إلى bit32). يقوم RiceGuard بحصر معالجة أسماء النطاقات داخل خوادم DNS خاصة لا تحتفظ بأي سجلات، مانعاً المتلصصين ومزودي الخدمة من التقاط هذه الأنماط الاستعلامية.
  3. تدوير نقاط الخروج بكفاءة: من خلال توزيع الاتصالات الصادرة عبر خوادم متعددة في مواقع مختلفة، يعطل النظام تكوين ملفات تعريف طويلة الأمد، مما يجعل محاولات ربط أقسام الذاكرة غير مجدية.

توصيات لضبط أمان الجهاز

للحد من مخاطر التتبع عبر ذاكرة البروتوكولات المؤقتة، يُنصح بتطبيق الإجراءات التالية:

  • تنظيف سجلات HSTS دورياً: في المتصفحات المبنية على نواة كروميوم، انتقل إلى صفحة chrome://net-internals/#hsts، واكتب اسم النطاق المراد إزالته في حقل "Delete domain security policies" ثم أكد الحذف.
  • التأكد من عزل الشبكة في فايرفوكس: في صفحة about:config، تحقق من ضبط الإعداد privacy.partition.network_state على القيمة true لضمان عزل الاتصالات والذاكرة المؤقتة استناداً إلى النطاق الرئيسي.
  • الاعتماد على اتصال VPN مستمر في الطبقة الثالثة: احرص على تشغيل VPNRice باستمرار على الهواتف وأجهزة الكمبيوتر. يضمن التشفير الكامل لحزم الشبكة عدم استغلال سلوكيات البروتوكولات والذاكرة المؤقتة في كشف عنوانك ومواصفات عتادك الحقيقية.