تبصيم الأجهزة في عالم ما بعد ملفات تعريف الارتباط: الخريطة التنظيمية والتقنية لعام 2026

تختزل عبارة «عالم ما بعد ملفات تعريف الارتباط» قصتين شديدتي الاختلاف في قصة واحدة، وهذا الخلط هو مصدر معظم الالتباس حول ما إذا كان تبصيم الأجهزة لا يزال قابلًا للتطبيق في 2026. القصة الأولى تقنية: قيّدت المتصفحات ملفات تعريف الارتباط من الأطراف الثالثة ثم أزالتها، وبنت آليات بديلة. والأخرى قانونية: أوضحت الجهات التنظيمية أن التبصيم يخضع للقواعد نفسها التي تخضع لها ملفات تعريف الارتباط. القصتان حقيقيتان، وكلتاهما مهمة، وكلتاهما كثيرًا ما تُقرأ خطأً على أنها «موت التبصيم» في حين أن ما تُثبتانه في الواقع أكثر تحديدًا بكثير.

يرسم هذا المقال خريطة القصتين معًا — ما تغيّر في المتصفحات، وما يقوله القانون، وكيف تتفاعل الاثنتان — بخيط ناظم ثابت: الغرضُ من التعريف، لا الآلية، هو ما يحدّد كلًّا من الجدوى التقنية والموقف القانوني. الجمهور المستهدف هو أصحاب المصلحة في مجالات الخصوصية والقانون والهندسة ممن يقررون ما إذا كان ينبغي نشر ذكاء الأجهزة وكيفية ذلك.

ما الذي أزاله «عالم ما بعد ملفات تعريف الارتباط» فعليًا

أزال تحوّل ما بعد ملفات تعريف الارتباط ملفاتِ الارتباط من الأطراف الثالثة — آلية التتبّع عبر المواقع — مع إبقاء حالةِ الطرف الأول وتعريفِ الجهاز من الطرف الأول سليمين. هذا التمييز هو أهم حقيقة مفردة لتقييم التبصيم، وهو الأكثر ضياعًا في النقاش.

ملف الارتباط من طرف ثالث يضبطه نطاق غير النطاق الظاهر في شريط العناوين، ويتيح لذلك الطرف الثالث التعرّفَ على المستخدم عبر كل المواقع غير المترابطة التي تعمل عليها شفرته. هذا هو محرّك الإعلانات السلوكية عبر المواقع، وهو ما فكّكته المتصفحات. أما ملف الارتباط من الطرف الأول — الذي يضبطه الموقع الذي تزوره فعلًا، ولا يقرؤه سوى ذلك الموقع — فلم يكن هدفًا قط ولا يزال يعمل.

تحرّكت المتصفحات وفق جداول زمنية مختلفة وبآليات مختلفة، لكن الاتجاه كان موحّدًا: القضاء على حالة الأطراف الثالثة عبر المواقع، والحفاظ على علاقة الطرف الأول.

Safari (منع التتبّع الذكي، ITP). تحجب ميزة ITP من Apple ملفاتِ الارتباط من الأطراف الثالثة افتراضيًا منذ 2020، وقد شدّدت تدريجيًا أعمارَ التخزين من الطرف الأول للحالة المضبوطة بالبرمجة للحد من التحايلات التتبعية. تستهدف ITP حالةَ استخدام التتبّع عبر المواقع تحديدًا.

Firefox (الحماية المعزَّزة من التتبّع / الحماية الكاملة لملفات الارتباط). يحجب Firefox ملفاتِ ارتباط التتبّع من الأطراف الثالثة افتراضيًا، ويقسّم التخزينَ لكل موقع، فيحصل الطرف الثالث على وعاء ملفات ارتباط منفصل في كل موقع بدلًا من هوية واحدة مشتركة عبرها جميعًا. ومجددًا — الربطُ عبر المواقع هو الهدف.

Chrome (Privacy Sandbox). كان مسار Chrome أطول وأكثر إثارة للجدل. فبدلًا من مجرد حجب ملفات الارتباط من الأطراف الثالثة، بنت Google مبادرة Privacy Sandbox — مجموعة من الواجهات البرمجية المحدودة بغرضها (Topics لإشارات الاهتمام، وProtected Audience لإعادة الاستهداف، وAttribution Reporting لقياس التحويلات) بهدف تحقيق نتائج إعلانية دون معرّفات عابرة للمواقع. تبدّل الإطلاق وجدول الإيقاف والوضع الدقيق للخيار المعروض على المستخدم مرارًا خلال 2024–2026، لكن النيّة المعمارية ظلّت قائمة: استبدال المعرّف العابر للمواقع بآليات مجمّعة محدودة النطاق تحفظ الخصوصية. أما الأثر على التبصيم تحديدًا فمشمول في أثر Privacy Sandbox.

كل واحدة من هذه الآليات تستهدف الأمر نفسه: تعرُّف طرف ثالث على المستخدم عبر مواقع لا يملكها. ولا واحدة منها تستهدف — ولا يمكنها أن تستهدف، دون كسر الويب — تعرُّفَ موقعٍ على زوّاره على صفحاته الخاصة. تلك هي الفجوة التي يعيش فيها تبصيم مكافحة الاحتيال.

تبصيم الاحتيال من الطرف الأول حالةُ استخدام مختلفة

التبصيم لمنع الاحتيال هو من الطرف الأول وأحادي الموقع بطبيعته: تعرّف منصةٌ على زوّارها على صفحاتها الخاصة لاتخاذ قرارات أمنية. وهذا يختلف فئويًا عن حالة استخدام الإعلانات عبر المواقع التي فكّكتها المتصفحات، وآليات المتصفح لا تقيّده — لأنها لا تستطيع، دون كسر وظيفة أساسية يعتمد عليها كل موقع.

تأمّل ما الذي كان يتعيّن على المتصفح كسرُه لإيقاف تعريف الجهاز من الطرف الأول. كان عليه منعُ الموقع من قراءة خصائص المتصفح الذي يعرض صفحاته الخاصة — حجم الشاشة، واللغة، والتوقيت وسلوك العرض الذي يحتاجه الموقع ليعمل، والحزمة الشبكية التي يتحدث إليها أصلًا. هذه ليست خطاطيف تتبّع؛ بل هي السطح الأساسي الذي يعمل عليه تطبيق الويب. تقييدها يكسر وظائف مشروعة، لذا تقيّد المتصفحات التركيبَ العابر للمواقع وإساءةَ استخدام هذه الإشارات، لا ملاحظتها من الطرف الأول.

لهذا يهمّ التمييز بين الجهاز وملف الارتباط. فنظام مكافحة الاحتيال الذي يعرّف جهازًا عائدًا على منصة واحدة لا يعيد بناء ملف ارتباط من طرف ثالث — بل يفعل شيئًا لم تُحسنه ملفات الارتباط من الأطراف الثالثة أصلًا: إنتاج هوية مستقرة تقاوم المسح، لغرض أمن الموقع نفسه. ويفعل ذلك دون ملفات ارتباط على الإطلاق، بما يتجاوز مسألة إيقاف ملفات الارتباط برمّتها.

لذا فحكم الجدوى التقنية مباشر: تقلّل تغييرات المتصفحات في عالم ما بعد ملفات الارتباط من التبصيم العابر للمواقع (أصعب وأكثر تقييدًا) وتترك تبصيمَ الاحتيال من الطرف الأول سليمًا في جوهره. نظام مكافحة احتيال يعتمد على مشاركة الإشارات عبر المواقع سيكون في ورطة؛ أما المبني حول هوية الجهاز من الطرف الأول فلا.

ماذا يقول GDPR وePrivacy فعلًا عن التبصيم

يتعامل القانون الأوروبي مع تبصيم الأجهزة بالطريقة نفسها التي يتعامل بها مع ملفات تعريف الارتباط: ينظّم حسب الغرض وحسب الوصول إلى جهاز المستخدم، لا حسب التقنية بعينها. لا يفلت التبصيم من القواعد بحجة أنه ليس ملف ارتباط، ولا يقع تحتها تلقائيًا أيضًا — فالتحليل يدور حول سبب قيامك به.

تنطبق أداتان، وتعملان بالتتابع.

توجيه ePrivacy (المادة 5(3)) ينظّم فعلَ تخزين المعلومات في المعدّات الطرفية للمستخدم أو الوصول إلى معلومات مخزّنة فيها بالفعل. هذا هو «قانون ملفات الارتباط»، لكن نصّه محايد تقنيًا — إذ يشمل «المعلومات» و«الوصول»، وهو ما قرأته الجهات التنظيمية (وإرشادات المجلس الأوروبي لحماية البيانات) باتساق على أنه يشمل تقنيات التبصيم التي تصل إلى خصائص الجهاز. لذا فإن قراءة إشارات من جهاز تقع ضمن نطاق ePrivacy بصرف النظر عن وجود ملف ارتباط.

والأهم أن المادة 5(3) تتضمن استثناءات. فالموافقة ليست مطلوبة حين يكون الوصول ضروريًا بحصر إما لنقل اتصال أو لتقديم خدمة طلبها المستخدم صراحةً. فالأمنُ ومنعُ الاحتيال اللذان تعتمد عليهما فعلًا الخدمةُ التي طلبها المستخدم لهما أساس حقيقي لاستثناء الضرورة القصوى — وهي نقطة سنعود إليها أدناه.

اللائحة GDPR تنظّم معالجة أي بيانات شخصية ناتجة. فبصمة الجهاز التي يمكنها تمييز فرد بعينه هي بيانات شخصية، ومن ثمّ تحتاج معالجتها إلى أساس قانوني بموجب المادة 6. والأسس ذات الصلة بعمل مكافحة الاحتيال هي المصالح المشروعة (المادة 6(1)(f)) — وتسمّي حيثيات GDPR نفسها منعَ الاحتيال صراحةً كمصلحة مشروعة — و، عند الاقتضاء، الالتزام القانوني. هنا تكمن آليات الامتثال التفصيلية: حصر الغرض، وتقليل البيانات، والشفافية، وحدود الاحتفاظ، وتقييم موثَّق للمصالح المشروعة. أما الشكل العملي لنشر متوافق فمعروض في تبصيم الأجهزة المتوافق مع GDPR.

تتراكم الأداتان: يقرّر ePrivacy ما إذا كنت بحاجة إلى موافقة للوصول إلى الجهاز، ويقرّر GDPR ما إذا كان لديك أساس قانوني لمعالجة ما حصلت عليه. ولمنع الاحتيال، المسار المعقول هو استثناء الضرورة القصوى في ePrivacy إضافةً إلى المصالح المشروعة في GDPR — لكن لهذا المسار شروطًا، وهو ليس تلقائيًا.

هل يحتاج تبصيم الاحتيال إلى موافقة؟

يتوقف الأمر على الغرض، والانقسام حادّ: التبصيم للإعلان أو التحليلات أو التتبّع عبر المواقع يحتاج إلى موافقة؛ أما التبصيم الضروري بحصر لخدمة منع احتيال طلبها المستخدم فله أساس حقيقي للعمل دون الموافقة المسبقة نفسها. الآلية متطابقة في الحالتين — أما التكييف القانوني فيتباعد كليًا بناءً على السبب.

بالنسبة لأغراض الإعلان والتحليلات، لا حجة جدية: هذا تحديدًا ما كُتب من أجله شرط الموافقة في ePrivacy، وهو ليس ضروريًا بحصر لأي خدمة طلبها المستخدم، ويحتاج إلى موافقة مسبقة مستنيرة كما يحتاج أي ملف ارتباط تتبّع.

أما لمنع الاحتيال، فالحجة لاستثناء الضرورة القصوى حقيقية لكنها مشروطة. وتصمد بأقوى صورها حين:

• يكون التبصيم ضروريًا فعلًا لتقديم خدمة طلبها المستخدم — تأمين تسجيل دخوله، وحماية مدفوعاته، ومنع الاستيلاء على حسابه. فالأمن جزء مما يطلبه المستخدم حين يستخدم الخدمة.
• تقتصر المعالجة على الغرض الأمني ولا يُعاد توظيفها للتسويق أو التنميط أو أي شيء لم يطلبه المستخدم. حصر الغرض يؤدي دورًا حقيقيًا هنا؛ فما إن تغذّي البصمة نفسها الإعلانَ حتى تنهار حجة الاستثناء.
• يُصغَّر جمع البيانات إلى ما يحتاجه الغرض الأمني، ويكون الاحتفاظ محدودًا، وتكون المعالجة موثّقة وشفّافة (مُفصح عنها في إشعار الخصوصية حتى لو لم تكن الموافقة هي الأساس).

هذا ليس ثغرة ولا ينبغي معاملته كذلك. إنه استثناء مقيّد بالغرض لا يبقى إلا ما دام الغرض مقيّدًا. فنظام مكافحة احتيال يشارك إشاراته خِفيةً في رسم بياني إعلاني لم يعد يمارس معالجة أمنية ضرورية بحصر، ويفقد الاستثناء. الموقف المتين هو نشرٌ لمكافحة الاحتيال يكون، ويبقى، تمامًا كما يزعم: من الطرف الأول، وموجّهًا للأمن، ومُصغَّرًا، ومفصولًا عن التسويق.

لا شيء من هذا يُعدّ مشورة قانونية، والتطبيق الدقيق يتوقف على الاختصاص القضائي، والتطبيقات الوطنية لـePrivacy، وقواعد القطاع، ومعالجتك المحددة — فما هنا هو الشكل التنظيمي العام، وأي نشر فعلي يحتاج إلى تقييم خاص للمصالح المشروعة ومراجعة قانونية.

البنية المعمارية المتينة

البنية التي تنجو من التحوّل التقني والقانوني معًا هي تلك التي كان التبصيم الموجَّه لمكافحة الاحتيال يتقارب نحوها أصلًا: من الطرف الأول، ومرجَّحة نحو إشارات جانب الخادم، ومحصورة بالغرض الأمني، ومستقلّة عن الآليات العابرة للمواقع.

تنبثق من الخريطة أعلاه ثلاثة التزامات تصميمية.

اعتمد على إشارات الطرف الأول وجانب الخادم. تقيّد تغييرات المتصفحات المجسّات العابرة للمواقع من جانب العميل بأشدّ صورها. أما إشارات جانب الخادم — بصمات الحزمة الشبكية، وخصائص TLS، وسلوك الاتصال — فتُلاحَظ من بنيتك التحتية الخاصة أثناء اتصال المستخدم بخدمتك، وهي من الطرف الأول بطبيعتها، ولا تخضع لقيود جانب العميل التي تشدّدها المتصفحات. فنظام مرجَّح نحو هذه الإشارات يتقادم بصورة أفضل من نظام مبني على مجسّات جانب العميل التي قد تُقلَّم.

أبقِ الغرض محصورًا ومرئيًا. تعتمد الجدوى القانونية كليًا على البقاء ضمن الغرض الأمني. وهذا يعني ألا تُعاد توظيف إشارات الاحتيال للتسويق، وألا يُبنى رسم بياني عابر للمواقع، والإفصاح عن المعالجة في إشعار الخصوصية، وتصغير الجمع، وتحديد الاحتفاظ. هذه ليست أعباء امتثال مركّبة لاحقًا — بل هي الشروط التي يكون النهج كله بموجبها قانونيًا.

لا تعتمد على مشاركة الإشارات عبر المواقع للحكم الأساسي. يمكن للذكاء المجمّع مجهول الهوية عبر العملاء أن يعزّز الكشف، لكن هوية الجهاز الأساسية ينبغي أن تقوم على إشارات الطرف الأول وحدها، حتى لا يستند النظام إلى الآليات العابرة للمواقع المقيَّدة تقنيًا والمستلزِمة للموافقة قانونيًا.

نظام تبصيم احتيال مبني بهذه الطريقة هو فعلًا نظام ما بعد ملفات الارتباط: لا يستخدم ملفات الارتباط، ولا يحتاجها، ولا يعوّل على حالة الأطراف الثالثة، ولا ينهار حين تُطلَق ميزة منع التتبّع التالية — لأنه لم يكن يمارس التتبّع عبر المواقع من الأساس.

بُني Tracio على هذا الشكل بالضبط. الهوية من الطرف الأول ودون ملفات ارتباط، مرجَّحة عبر إشارات الشبكة من جانب الخادم وإشارات الجهاز من جانب العميل، ومحصورة بالغرض في قرارات الأمن ومكافحة الاحتيال، ولا تغذّي رسمًا بيانيًا إعلانيًا. وهو مصمَّم ليبقى مستقرًا عبر تغييرات خصوصية المتصفح لأنه لا يعتمد على الآليات العابرة للمواقع التي تستهدفها تلك التغييرات. للاطلاع على آليات الامتثال التفصيلية، انظر دليل النشر المتوافق مع GDPR؛ ويغطّي المسرد المفاهيم الأساسية.

هل تريد أن ترى كيف تنسجم هوية جهاز من الطرف الأول وموجّهة للأمن مع وضع الخصوصية والامتثال لديك؟

ابدأ تجربتك المجانية — 2,500 عملية تحقّق مجانًا، دون حاجة إلى بطاقة ائتمان. احجز عرضًا توضيحيًا لمراجعة البنية المعمارية ومعالجة البيانات مع فريقنا.