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

البصمات الرقمية تعني محاولة تحديد هوية المستخدم عند عودته إلى موقعك الإلكتروني، أو تحديد المستخدم نفسه على مواقع إلكترونية مختلفة. قد تختلف العديد من الخصائص بين الإعداد الخاص بك وسمات شخص آخر. على سبيل المثال، ربما تستخدم نوعًا مختلفًا من الأجهزة. ومتصفح مختلف، ولها حجم شاشة مختلف، وخطوط مختلفة مثبتة. إذا كان لديّ الخط "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> بشكل غير متوقّع قد تكشف أيضًا عن بعض الطُرق التي تستحق المزيد من التدقيق. كما ينبغي أيضًا البحث عن استخدامات مصطلح "المطابقة الاحتمالية" في مجال التسويق أو المواد التقنية التي تصف طرفًا ثالثًا قد يشير هذا في بعض الأحيان إلى استخدام تقنيات البصمات الرقمية.

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

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

ولكن بعد أن يتم تدقيق الموقع، يتم اختبار واجهات برمجة التطبيقات للتأكد من عدم تعطل أي شيء في الإصدارات الأحدث للمتصفح (أو في "إصدار تجريبي" قادم و"preview" الإصدارات) يمكن أن تكون مؤتمتة، وينبغي أن تكون إلى حد كبير جزءًا من حزمة الاختبار الحالية. شيء ما التي يجب مراعاتها عند استخدام أدوات الاختبار التلقائية، عند التعامل مع تغطية مساحة عرض واجهة برمجة التطبيقات، هو أنّ معظم المتصفحات تسمح بمستوى معيّن من التحكم في واجهات برمجة التطبيقات والميزات المتاحة. يجري Chrome ذلك من خلال مفاتيح تبديل سطر الأوامر، كما هو الحال بالنسبة إلى Firefox، وإمكانية الوصول إلى هذه العناصر في أداة الاختبار الإعداد إجراء اختبارات معينة مع إيقاف واجهات برمجة التطبيقات أو تشغيلها. (انظر على سبيل المثال، قصة السرو المكوّن الإضافي لتشغيل المتصفح المعلَمة 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، وهو متصفح تم إطلاقه في آن واحد مع أول رواد الفضاء الصعود إلى محطة الفضاء الدولية (ISS) منذ أكثر من عقدين. تعتبر سلسلة وكيل المستخدم مصدرًا غنيًا لقصور البصمات الرقمية، وبطبيعة الحال، وللتخفيف من إمكانية بصمة الإصبع، قد تكون الشركات المصنّعة للمتصفحات قد جمّدت رأس وكيل المستخدم من قبل أو تعمل على نحو القيام بذلك. هذا مثال آخر على تغيير البيانات التي توفّرها واجهة برمجة التطبيقات بدون الحاجة إلى إزالتها بالكامل. سيؤدي إرسال رأس فارغ لوكيل المستخدم إلى تعطّل عدد لا يحصى من المواقع الإلكترونية التي تفترض وجودها. بشكل عام، ما تفعله المتصفحات هو إزالة بعض التفاصيل منه، ثم إبقائه دون تغيير تقريبًا من ذلك الوقت فصاعدًا. (يمكنك رؤية حدوث ذلك في Safari وChrome وFirefox). تساعد هذه الحماية من البصمات الرقمية التفصيلية تعني في الأساس أنه لا يمكنك الاعتماد على دقة عنوان وكيل المستخدم بعد الآن، وإذا كنت للقيام بذلك من المهم العثور على مصادر بيانات بديلة.

وبمعنى آخر، لن يتم إزالة البيانات في وكيل المستخدم بشكل كامل، ولكنها متوفرة بدرجة أقل أو غير دقيق أحيانًا لأنه قد يتم الإبلاغ عن رقم أقدم ولكنه لا يتغير. على سبيل المثال، يتم استخدام أحرف كبيرة بالكامل في Firefox وSafari وChrome رقم إصدار نظام التشغيل macOS الذي تم الإبلاغ عنه إلى عشرة أرقام (يُرجى الاطّلاع على تحديث بشأن تقليل سلسلة وكيل المستخدم لمزيد من المناقشة هنا). تتوفّر التفاصيل الدقيقة حول الطريقة التي يخطّط بها Chrome لتقليل البيانات في سلسلة وكيل المستخدم في تقليل وكيل المستخدم. باختصار، يمكنك توقّع أنّ رقم إصدار المتصفّح الذي تم الإبلاغ عنه سيحتوي فقط على رقم إصدار رئيسي (وبالتالي سيظهر بالشكل 123.0.0.0، حتى إذا كان المتصفح هو الإصدار 123.10.45.108)، وسيكون إصدار نظام التشغيل بدون تفاصيل تجميد واحد من عدد صغير من الخيارات غير المتغيرة. لذا فإن إصدار Chrome الخيالي 123.45.67.89 الذي يعمل على نظام التشغيل "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 من Safari الذي يعمل بنظام التشغيل 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 summarises بعض الحجج وأسباب التغيير، ويقدم روان ميروود مجموعة شرائح ببعض الاستراتيجيات للابتعاد عن استخدام وكيل المستخدِم للتمييز، في سياق اقتراح تلميحات برامج 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، والتي تسمي نظام التشغيل. (تحليل هذه العناوين أقل سهولة مما قد يبدو عليها لأنها العناوين المهيكلة بدلاً من السلاسل البسيطة، ويتم فرض ذلك من خلال المتصفحات التي ترسل العبارة "خبيثة" والتي سيتم التعامل معها بشكل غير صحيح إذا لم يتم تحليلها بشكل صحيح. وهي، مثل ما ورد سابقًا، مثل "اختبار التحقّق من صحة معلومات الخطأ" الذي يجريه المتصفح بشكل استباقي. يجب أن يتعامل المطوّر الذي يستخدم هذه البيانات مع ذلك بشكل صحيح؛ لأن البيانات مصممة بشكل يؤدي إلى أن يؤدي التحليل غير السليم أو الكسول إلى نتائج سيئة، مثل عرض علامات تجارية لا أو السلاسل التي لا تغلق بشكل صحيح). ولحسن الحظ، يتم توفير هذه البيانات أيضًا من خلال المتصفح لـ JavaScript بشكل مباشر navigator.userAgentData، والذي قد يظهر في متصفّح داعم على النحو التالي:

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