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

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

قد يبدو التعريف الأكثر رسمية كما يلي: البصمات الرقمية هي عملية استخدام خصائص طويلة الأمد واضحة وغير واضحة لإعداد المستخدم لمحاولة تمييزه عن أكبر عدد ممكن من المستخدمين الآخرين.

لماذا يعيق البصمات الرقمية خصوصية المستخدم

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

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

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

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

الإجراءات الموصى بها

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

وننصحك أيضًا بقراءة سياسات الخصوصية الخاصة بخدماتك التابعة لجهات خارجية والتبعيات المرتبطة بها للبحث عن مؤشرات للبصمات الرقمية المستخدَمة. يُشار إليها أحيانًا باسم "المطابقة الاحتمالية" أو كجزء من مجموعة من أساليب المطابقة الاحتمالية، بدلاً من "المطابقة الحتمية".

آلية عمل البصمات الرقمية

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

الجانب: البصمات الرقمية السلبية والنشطة

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

جانبًا: قياس قابلية بصمات الأصابع

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

ما الذي تفعله المتصفحات ضد البصمات الرقمية؟

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

عدم توافق بعض واجهات برمجة التطبيقات الفعّالة

إنّ استجابة مورّدي المتصفحات لكل من هذه الأساليب في احتساب الملف المرجعي للمستخدم هي إيجاد طرق لتقليل مقدار القصور المتاح من واجهات برمجة التطبيقات هذه. والخيار الأكثر تقييدًا هو عدم تنفيذها في المقام الأول. وقد فعلت بعض المتصفحات الرئيسية مجموعة متنوعة من واجهات برمجة تطبيقات الأجهزة والأجهزة (مثل الوصول عبر NFC والبلوتوث من تطبيقات الويب من جهة العميل)، مع ذكر المخاوف بشأن الخصوصية والبصمة كأسباب لعدم تنفيذ هذه الواجهات. ومن الواضح أنّ ذلك يمكن أن يؤثر في تطبيقاتك وخدماتك، إذ لا يمكنك استخدام واجهة برمجة تطبيقات على الإطلاق في متصفّح لا ينفِّذها، ويمكن أن يحدّ ذلك من بعض أساليب الأجهزة أو قد يوقفها تمامًا.

مدخل أذونات المستخدم

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

إضافة عدم القدرة على التوقع

هناك نهج ثالث يتم اتباعه في بعض الحالات يتمثل في أن يستخدم مورّدو المتصفحات أسلوب "دمج" الردود من واجهات برمجة التطبيقات لجعلها أقل دقة وبالتالي أقل تحديدًا. تم وصف ذلك كجزء من آلية الاستجابة العشوائية في وحدة البيانات كإجراء يمكنك فعله عند جمع البيانات من المستخدمين لتجنُّب جمع البيانات التي تحدّد الهوية عن غير قصد. ويمكن لمورّدي المتصفِّح اتّباع هذا المنهج للتعامل مع بيانات واجهة برمجة التطبيقات التي يتم إتاحتها لتطبيقات الويب والأطراف الثالثة أيضًا. مثال على ذلك هو واجهات برمجة تطبيقات التوقيت الدقيقة للغاية المستخدمة لقياس أداء الصفحة من window.performance.now(). ويتعرّف المتصفّح على هذه القيم بدقة ميكرو ثانية، ولكن يتم تقليل دقة القيم عمدًا من خلال التقريب إلى أقرب حد بمدّة 20 ميكرو ثانية لتجنُّب استخدامها في البصمات الرقمية (وكذلك للحفاظ على الأمان لتجنُّب حدوث هجمات التوقيت، مع الاعتراف به). والهدف هنا هو ضمان بقاء واجهات برمجة التطبيقات مفيدة، ولكن مع جعل الردود أقل تحديدًا: في الواقع، توفير "مناعة الجماعات" من خلال جعل جهازك يبدو أشبه بجهاز أي شخص آخر بدلاً من أن يكون فريدًا بالنسبة إليك. يقدّم Safari نسخة مبسّطة من إعدادات النظام لهذا السبب.

فرض ميزانية الخصوصية

"ميزانية الخصوصية" هي اقتراح يقترح أن تقدّر المتصفّحات المعلومات التي تحصل عليها من كل مساحة عرض خاصة ببصمة الإصبع. لم يتم تنفيذه بعد في المتصفّحات. والهدف من ذلك هو السماح بواجهات برمجة تطبيقات فعّالة مع الحفاظ على خصوصية المستخدم. مزيد من المعلومات حول اقتراح ميزانية الخصوصية

استخدام بيئة اختبار واسعة

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

الإجراءات الموصى بها

• تحقّق من الإحصاءات والجمهور المستهدَف لتوجيه مجموعة المتصفّحات التي يجب أن تعطي الأولوية عند الاختبار لها.
• وهناك مجموعة جيدة من المتصفحات التي يمكن اختبارها هي Firefox وChrome وEdge وSafari على الكمبيوتر المكتبي وChrome وSamsung Internet على نظام التشغيل Android وSafari على iOS. ويضمن ذلك إجراء اختبار على المحركات الثلاثة الرئيسية للعرض (Gecko في Firefox والشرائح المختلفة لـ Blink في Chrome وEdge وSamsung Internet وWebkit في Safari) وعلى كل من الأنظمة الأساسية للأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي.
• وإذا كان من الممكن استخدام موقعك أيضًا على أجهزة أقل شيوعًا، مثل الأجهزة اللوحية أو الساعات الذكية أو وحدات تحكم الألعاب، فاختبِر ذلك الموقع أيضًا. قد تتأخّر بعض الأنظمة الأساسية للأجهزة عن تحميل تحديثات المتصفّح للأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي، ما يعني أنّ بعض واجهات برمجة التطبيقات قد لا يتم تنفيذها أو قد لا تتوفّر في المتصفّحات على هذه الأنظمة الأساسية.
• نفِّذ اختبارًا باستخدام متصفح واحد أو أكثر يدّعي أنّ خصوصية المستخدم هي دافعك. احرص على تضمين الإصدارات القادمة للإصدار التجريبي والاختباري من المتصفحات الأكثر شيوعًا التي يمكنك استخدامها وما إذا كانت متاحة لك: معاينة التكنولوجيا في Safari وإصدار Canary من Chrome والقناة التجريبية من Firefox. ويمنحك ذلك أفضل فرصة لتحديد حالات تعطُّل واجهة برمجة التطبيقات والتغييرات التي تؤثر في مواقعك الإلكترونية قبل أن تؤثّر هذه التغييرات في المستخدمين. وبالمثل، ضع بيئات المستخدمين في الاعتبار عند الإشارة إلى أي تحليلات لديك. إذا كانت قاعدة المستخدمين تحتوي على أعداد كبيرة من هواتف Android القديمة، فتأكد من تضمينها في اختباراتك. لا يمتلك معظم الأشخاص الأجهزة السريعة وأحدث الإصدارات التي يمتلكها فريق التطوير.
• نفِّذ اختبارًا باستخدام ملف شخصي نظيف وفي وضع التصفُّح المتخفي/التصفّح بخصوصية تامّة، فمن المحتمل أنك سبق أن منحت الأذونات المطلوبة في ملفك الشخصي. اختبِر ما يحدث إذا رفضت منح الإذن بالوصول إلى الموقع الإلكتروني لطرح أي سؤال.
• اختبِر صفحاتك بوضوح في وضع الحماية من بصمة الإصبع في Firefox. وسيؤدي هذا إلى عرض مربعات حوار الأذونات إذا كانت صفحتك تحاول إنشاء ملف مرجعي، أو عرض بيانات ضبابية لبعض واجهات برمجة التطبيقات. يساعدك ذلك في التأكّد مما إذا كانت الجهات الخارجية المضمّنة في خدمتك تستخدم بيانات قابلة للبصمات الرقمية، أو ما إذا كانت خدمتك الخاصة تعتمد على ذلك. يمكنك بعد ذلك التفكير فيما إذا كان التداخل المتعمد يجعل من الصعب القيام بما تحتاجه. ننصحك بإجراء التصحيحات وفقًا لذلك للحصول على تلك البيانات من مصدر آخر، أو إجراء ذلك بدونها، أو استخدام بيانات أقل دقّة.
• كما ناقشنا سابقًا في وحدة الجهات الخارجية، من المهم أيضًا مراجعة تبعيات الجهات الخارجية لمعرفة ما إذا كانت تستخدم تقنيات البصمات الرقمية. من الصعب رصد البصمة السلبية (ومستحيل إذا استخدمها طرف ثالث على الخادم الخاص بها)، إلا أنّ وضع البصمة الرقمية قد يضع علامة على بعض تقنيات البصمات الرقمية، وقد يكشف أيضًا البحث عن استخدامات navigator.userAgent أو إنشاء غير متوقّع لكائنات <canvas> عن بعض الأساليب التي تستحق المزيد من التدقيق. كما أنه من المفيد البحث عن استخدامات مصطلح "المطابقة الاحتمالية" في المواد التسويقية أو التقنية التي تصف طرفًا ثالثًا؛ حيث يمكن أن يشير ذلك في بعض الأحيان إلى استخدام تقنيات البصمات الرقمية.

أدوات الاختبار عبر المتصفحات

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

ومع ذلك، بعد أن تتم مراجعة الموقع الإلكتروني، يمكن إجراء اختبارات تلقائية لاختبار واجهات برمجة التطبيقات للتأكّد من عدم حدوث أي خلل في الإصدارات الأحدث من المتصفّح (أو في الإصدارات "التجريبية" و "المعاينة" القادمة)، ويجب أن يكون هذا الاختبار ضمن مجموعة الاختبار الحالية إلى حدّ كبير. عند العمل مع تغطية مساحة عرض واجهة برمجة التطبيقات، تتيح معظم المتصفحات مستوى معيّن من التحكّم في واجهات برمجة التطبيقات والميزات المتوفرة. وينفّذ Chrome ذلك من خلال مفاتيح تبديل سطر الأوامر، كما يفعل Firefox، وسيتيح لك الوصول إلى هذه المفاتيح في إعداد أداة الاختبار إجراء اختبارات معيّنة مع إيقاف أو تفعيل واجهات برمجة التطبيقات. (يمكنك مثلاً الاطّلاع على المكوّن الإضافي لإطلاق المتصفح في Cypress ومَعلمةlaunch.args في Cypress ومَعلمةlaunch.args لمعرفة طرق إضافة علامات المتصفّح عند تشغيلها.

الاعتماد فقط على سلسلة وكيل المستخدم للحصول على المعلومات التقريبية

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

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

ويدّعي هذا، من بين أمور أخرى، أن المتصفح Mozilla/5.0، وهو متصفح تم إطلاقه في نفس الوقت الذي استقل فيه أول رائد فضاء في محطة الفضاء الدولية قبل أكثر من عقدين. تشكّل سلسلة وكيل المستخدم مصدرًا غنيًا بالقصور لإنشاء البصمات الرقمية، وللحدّ من إمكانية البصمات الرقمية، فقد جمّدت الشركات المصنّعة للمتصفّح رأس وكيل المستخدم من قبل أو تعمل على تنفيذ ذلك. وهذا مثال آخر على تغيير البيانات التي توفرها واجهة برمجة التطبيقات بدون إزالة واجهة برمجة التطبيقات نهائيًا. سيؤدي إرسال عنوان وكيل مستخدم فارغ إلى تعطيل عدد لا يحصى من المواقع الإلكترونية التي تفترض أنّها متوفّرة. لذلك بشكل عام، ما تقوم به المتصفحات هو إزالة بعض التفاصيل منها، ثم إبقائها بدون تغيير تقريبًا من الآن فصاعدًا. (يمكنك ملاحظة حدوث ذلك في Safari وChrome وFirefox.) ويعني هذا الحماية من البصمة المُفصّلة أنّه لا يمكنك الاعتماد على دقة عنوان وكيل المستخدم بعد الآن، وفي حال إجراء ذلك، من المهم العثور على مصادر بيانات بديلة.

للتوضيح، لن تتم إزالة البيانات في وكيل المستخدم بشكل كامل، ولكنها تكون متاحة بدرجة دقة أقل أو تكون غير دقيقة أحيانًا بسبب عرض رقم قديم ولكنه غير متغير. على سبيل المثال، يستخدم كل من Firefox وSafari وChrome رقم إصدار نظام التشغيل macOS الذي تم الإبلاغ عنه على عشرة أرقام (يمكنك الاطّلاع على تحديث بشأن تخفيض سلسلة وكيل المستخدم لمزيد من النقاش هنا). التفاصيل الدقيقة للطريقة التي يخطط بها Chrome لخفض البيانات في سلسلة وكيل المستخدم متوفرة على تقليل وكيل المستخدم لذا فإن الإصدار 123.45.67.89 الخيالي من Chrome الذي يعمل على "Windows 20" سيسجل رقم الإصدار الخاص به على النحو التالي:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

لا تزال المعلومات الأساسية التي تحتاجها (إصدار المتصفح) متاحة: إنها Chrome 123، لنظام التشغيل Windows. إلا أن معلومات الشركات الفرعية (بنية الرقاقة وإصدار Windows وإصدار Safari الذي تحاكيه والإصدار الثانوي من المتصفح) لن تكون متاحة بعد إيقاف التحديثات.

قارِن هذا بوكيل مستخدم Chrome "الحالي" على نظام أساسي مختلف:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

يتضح لي أنّ الاختلاف الوحيد هو رقم إصدار Chrome (104) ومعرّف النظام الأساسي.

وبالمثل، تعرض سلسلة وكيل المستخدم في Safari النظام الأساسي ورقم إصدار Safari، وتقدم أيضًا أحد إصدارات نظام التشغيل iOS، ولكن كل شيء آخر ثابت. لذا، قد يُمنح الإصدار 1234.5.67 الخيالي الذي يعمل على نظام التشغيل macOS 20 الخيالي وكيل المستخدم التابع له على النحو التالي:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

وعلى إصدار iOS 20 الخيالي قد تكون:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

ومرة أخرى، تتوفر المعلومات الأساسية (أي Safari، على iOS أو macOS)، بينما لا يزال iOS Safari يوفّر رقم إصدار iOS، ولكن تم تجميد الكثير من المعلومات الإضافية التي كانت متوفرة في الماضي منذ ذلك الحين. والأهم من ذلك، أن ذلك يتضمن رقم إصدار Safari الذي لا يتوفر بالضرورة.

كان هناك نقاش شديد في التغييرات التي تم إجراؤها على وكيل المستخدم الذي تم الإبلاغ عنه. يلخّص https://github.com/WICG/ua-client-hints#use-cases بعض الحجج وأسباب التغيير، ويقدّم "روان ميريوود" مجموعة شرائح مع بعض الاستراتيجيات للتوقف عن استخدام وكيل المستخدم من أجل التميّز، في سياق تقديم شرح إضافي حول عميل UA.

تمويه ضبابي

يُطلق على مصطلح "التشويش" مصطلح من الممارسات الأمنية، حيث يتم استدعاء واجهات برمجة التطبيقات بقيم غير متوقعة على أمل أن تتعامل مع هذه القيم غير المتوقعة بصورة سيئة وتعرِّضها لمشكلة أمنية. يجب أن يكون مطوِّرو الويب على دراية بالنصوص البرمجية على المواقع الإلكترونية (XSS)، التي تتضمّن إضافة نص برمجي ضار إلى الصفحة، وغالبًا ما يكون ذلك لأنّ الصفحة لا تتخطى محتوى HTML الذي يتم إدخاله بشكل صحيح (لذا يتم إجراء طلب بحث يتضمّن النص <script>). سيكون مطوِّرو الواجهة الخلفية على دراية بميزة إدخال SQL، حيث تؤدي طلبات بحث قاعدة البيانات التي لم تتحقّق من صحة إدخال المستخدم بشكلٍ صحيح إلى عرض مشاكل الأمان (كما هو موضّح بوضوح في xkcd مع استخدام Little Boby Tables). يُستخدم تشويش تسلسل الأحداث، أو اختبار ضبابي، بشكل أكثر ملاءمةً للمحاولات الآلية لتقديم العديد من المدخلات غير الصالحة أو غير المتوقعة إلى واجهة برمجة التطبيقات وفحص النتائج بحثًا عن تسرُّب الأمان أو الأعطال أو غيرها من عمليات المعالجة السيئة. هذه كلها أمثلة على تقديم معلومات غير دقيقة عمدًا. مع ذلك، يتم هنا تنفيذ ذلك بشكل استباقي من خلال المتصفحات (من خلال جعل وكيل المستخدم غير صحيح عمدًا)، وذلك لتشجيع المطوّرين على التوقف عن الاعتماد على هذه البيانات.

الإجراءات الموصى بها

• تحقّق من قاعدة الرموز بحثًا عن أي اعتماد على سلسلة وكيل المستخدم (من المرجح أن يؤدي البحث عن navigator.userAgent إلى العثور على معظم مواضع الورود في الرمز من جهة العميل، ومن المرجّح أن يبحث رمز الخلفية عن User-Agent كرأس)، بما في ذلك التبعيات.
• إذا وجدت استخدامات في التعليمات البرمجية الخاصة بك، فتعرّف على ما يتحقق منه الرمز، واعثر على طريقة أخرى لإجراء ذلك التمييز (أو ابحث عن تبعية بديلة، أو تعامل مع إصدار التبعية الرئيسي من خلال تقديم المشكلات أو التحقق منها بحثًا عن التحديثات). أحيانًا يكون الاختلاف بين المتصفحات أمرًا ضروريًا لتفادي الأخطاء، ولكن لن يصبح وكيل المستخدم هو الوسيلة المناسبة للقيام بذلك عند تجميده.
• مع أطيب التحيات، إذا كنت تستخدم القيم الأساسية للعلامة التجارية والإصدار الرئيسي والنظام الأساسي فقط، من المؤكّد أنّها ستظل متوفّرة وستكون صحيحة في سلسلة وكيل المستخدم.
• يصف MDN طرقًا جيدة لتجنّب الاعتماد على سلسلة وكيل المستخدم ("browser sniffing")، وأسلوبها الرئيسي هو اكتشاف الميزات.
• إذا كنت تعتمد على سلسلة وكيل المستخدم بطريقة ما (حتى عند استخدام القيم الأساسية القليلة التي تبقى مفيدة)، ننصحك بإجراء اختبار مع وكلاء المستخدم القادمة التي ستكون في إصدارات المتصفح الجديدة. من الممكن إجراء الاختبار باستخدام إصدارات المتصفحات القادمة نفسها عن طريق إصدارات تجريبية أو معاينة تكنولوجية، ولكن من الممكن أيضًا تعيين سلسلة وكيل مستخدم مخصصة للاختبار. يمكنك إلغاء سلسلة وكيل المستخدم في Chrome وEdge وFirefox وSafari عند إجراء تطوير محلي للتحقق من كيفية تعامل الرمز مع قيم وكيل المستخدم المختلفة التي قد تتلقاها من المستخدمين.

تلميحات للعملاء

من بين الاقتراحات الرئيسية لتقديم هذه المعلومات User-Agent Client Hints، إلا أنّ هذه الميزة غير متاحة في جميع المتصفحات. وستجتاز المتصفّحات المتوافقة ثلاثة عناوين: Sec-CH-UA التي تحدّد العلامة التجارية للمتصفّح ورقم الإصدار، وSec-CH-UA-Mobile التي تشير إلى ما إذا كان الطلب صادرًا من جهاز جوّال، وSec-CH-UA-Platform التي تحدّد نظام التشغيل. (يعتبر تحليل هذه العناوين أقل سهولة مما يبدو لأنّها العناوين المنظَّمة بدلاً من السلاسل البسيطة، ويتم فرض ذلك من خلال المتصفّحات التي ترسل قيم "triky" والتي سيتم التعامل معها بشكل غير صحيح إذا لم يتم تحليلها بشكل صحيح. هذا، كما في السابق، مثال على "اختبار الزغب" الذي يتم إجراؤه بشكل استباقي من خلال المتصفح. وعلى المطوِّر الذي يستخدم هذه البيانات التعامل معها بشكل صحيح لأنّ البيانات مصمّمة بطريقة من المحتمل أن يؤدي التحليل غير الصحيح أو الكسول إلى نتائج سيئة، مثل عرض علامات تجارية غير غير متوفرة أو السلاسل غير المكتملة). ومن الجيّد أنّ هذه البيانات متاحة أيضًا من خلال المتصفِّح JavaScript مباشرةً باسم navigator.userAgentData، والذي قد يبدو في متصفّح متوافق على النحو التالي:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}