فهم أعمق لـ "مبادرة حماية الخصوصية"

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

Sam Dutton

ملخّص

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

الحالة الحالية للخصوصية على الويب

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

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

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

هذه معضلة تواجه الويب. كيف يمكن دعم حالات الاستخدام المشروعة التابعة لجهات خارجية بدون السماح بتتبُّع المستخدمين على مختلف المواقع الإلكترونية؟

وعلى وجه الخصوص، كيف يمكن للمواقع الإلكترونية تمويل المحتوى من خلال السماح لجهات خارجية بعرض الإعلانات وقياس أداء الإعلانات بدون السماح بتلخيص بيانات المستخدمين الفرديين؟ كيف يمكن للمعلنين ومالكي المواقع الإلكترونية تقييم مصداقية المستخدم بدون اللجوء إلى الأنماط المظلمة، مثل البصمات الرقمية على الجهاز؟

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

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

لمحة عن "مبادرة حماية الخصوصية"

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

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

شكَّل هذا تحولاً في طريقة عمل المتصفّحات. تتضمّن رؤية "مبادرة حماية الخصوصية" للمستقبل متصفّحات توفّر أدوات محدّدة لتلبية حالات استخدام معيّنة مع الحفاظ على خصوصية المستخدم. يحدّد نموذج خصوصية محتمل للويب المبادئ الأساسية لواجهات برمجة التطبيقات:

  • لإنشاء نطاق نشاط الويب الذي يمكن لمتصفّح المستخدم من خلاله السماح للمواقع الإلكترونية بمعاملة شخص على أنّه يمتلك هوية واحدة
  • لتحديد الطرق التي يمكن أن تتنقل بها المعلومات عبر حدود الهوية دون المساس بذلك الفصل.

اقتراحات "مبادرة حماية الخصوصية"

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

يمكنك التعليق على التعليقات التوضيحية للاقتراح عن طريق تقديم المشاكل مقابل كل مستودع:

  • نموذج الخصوصية للويب
    أنشئ نطاق نشاط الويب الذي يمكن لمتصفّح المستخدم من خلاله السماح للمواقع الإلكترونية بمعاملة شخص على أنّه يمتلك هوية واحدة. عليك تحديد الطرق التي يمكن أن تتنقل بها المعلومات عبر حدود الهوية بدون المساس بهذا الفصل.
  • ميزانية الخصوصية
    ضع حدًا لإجمالي بيانات تحديد الهوية التي يمكن للمواقع الإلكترونية الوصول إليها. عليك تحديث واجهات برمجة التطبيقات لتقليل مقدار البيانات التي قد تحدّد الهوية التي تم الكشف عنها. اجعل الوصول إلى البيانات التي يُحتمل أن تكون قابلة للقياس قابلاً للقياس.
  • Gnatcatcher
    الحدّ من إمكانية تحديد هوية المستخدمين الفرديين من خلال الوصول إلى عنوان IP الخاص بجهازهم
  • واجهة برمجة تطبيقات Trust Token
    تعمل هذه السياسة على تفعيل مصدر يثق في مستخدم ليرسل إليه رموزًا مميّزة للتشفير يتم تخزينها من خلال متصفّح المستخدم كي يتمكّن من استخدامها في سياقات أخرى لتقييم مصداقية المستخدم.
  • مجموعات نطاقات الطرف الأول
    السماح لأسماء النطاقات ذات الصلة التي يملكها الكيان نفسه بالإعلان عن انتمائها إلى الطرف الأول نفسه
  • التقارير المجمَّعة
    توفير آليات للحفاظ على الخصوصية لإتاحة مجموعة متنوعة من حالات الاستخدام مثل قياس الإحالات الناجحة بعد رؤية الإعلان فقط والعلامة التجارية والتحسّن ومدى الوصول إلى الجمهور
  • تقارير تحديد المصدر
    توفير قياس للحفاظ على الخصوصية للنقرات والمشاهدات باستخدام تقارير مجمّعة على مستوى الحدث
  • Topics API
    مكِّن الإعلانات التي تستهدف الاهتمامات، بدون الحاجة إلى اللجوء إلى تتبع المواقع التي يزورها المستخدم. وقد استندت عملية تصميم واجهة برمجة التطبيقات إلى ملاحظات المنتدى من تجارب "التعلُّم الموحّد للمجموعات النموذجية" (FLoC) السابقة، وهي تحلّ محلّ اقتراح "التعلُّم الموحّد للمجموعات النموذجية" (FLoC).
  • FLEDGE
    توفِّر هذه السياسة حلاً لحالات استخدام تجديد النشاط التسويقي، مُصمَّمة بحيث لا يمكن لجهات خارجية استخدامها لتتبُّع سلوك تصفح المستخدم على جميع المواقع الإلكترونية.

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

سنضيف أيضًا إلى قائمة التشغيل فيديوهات مدتها خمس دقائق تقدّم شرحًا بسيطًا لكل واجهة برمجة تطبيقات.

حالات الاستخدام والأهداف

قياس الإحالة الناجحة

الهدف: السماح للمعلنين بقياس أداء الإعلانات.

تتيح واجهة برمجة التطبيقات Attribution Reporting API إمكانية قياس حدثين مرتبطين معًا: 1- حدث على الموقع الإلكتروني للناشر، مثل مشاهدة مستخدم لإعلان أو النقر عليه. 1. إحالة ناجحة لاحقة على موقع إلكتروني لأحد المعلنين.

تتيح واجهة برمجة التطبيقات هذه قياس نسبة النقر إلى الظهور ومشاهدة مكتملة.

وتشمل الميزات الأخرى في واجهة برمجة التطبيقات هذه إعداد تقارير تحديد المصدر من تطبيق إلى آخر وإعداد تقارير تحديد المصدر من تطبيق إلى آخر.

توفِّر واجهة برمجة التطبيقات أيضًا نوعَين من تقارير تحديد المصدر:

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

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

يمكن استخدام كلا نوعَي التقارير في وقت واحد: فهم مكمّلان.

توضِّح مقالة مقدمة عن Attribution Reporting مزيدًا من المعلومات عن حالة هذه الميزات وكيفية تجربة واجهة برمجة التطبيقات هذه.

اختيار الإعلانات

الهدف: السماح للمعلنين بعرض إعلانات ملائمة للمستخدمين.

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

هناك العديد من الطرق لجعل الإعلانات ملائمة للمستخدم، منها ما يلي:

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

ويمكن اختيار بيانات الطرف الأول والإعلانات السياقية بدون معرفة أي شيء عن المستخدم بخلاف نشاطه داخل الموقع. ولا تتطلّب هذه الأساليب إجراء التتبُّع عبر المواقع الإلكترونية.

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

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

  • FLEDGE: لحالات استخدام تجديد النشاط التسويقي
    تم تصميم واجهة برمجة التطبيقات لكي لا تتمكّن جهات خارجية من استخدامها لتتبُّع سلوك تصفُّح المستخدم: يخزِّن متصفّح المستخدِم، وليس المعلِن أو منصّة تكنولوجيا الإعلان، مجموعات الاهتمامات التي يحدِّدها المعلِنون والتي يرتبط بها متصفّح المستخدِم. يدمج متصفّح المستخدِم بيانات مجموعة الاهتمامات وبيانات المشترين/البائعين للإعلانات ومنطق النشاط التجاري لإجراء "مزاد". على جهاز المستخدم لاختيار الإعلان بدلاً من مشاركة البيانات مع جهة خارجية

  • Topics API: لشرائح الجمهور التي تستهدف الاهتمامات
    مكِّن الإعلانات التي تستهدف الاهتمامات، بدون الحاجة إلى اللجوء إلى تتبع المواقع التي يزورها المستخدم. تقترح واجهة برمجة التطبيقات استخدام تكنولوجيا تعلُّم الآلة لاستنتاج المواضيع من أسماء المضيفين، وواجهة برمجة تطبيقات JavaScript تعرض مواضيع عامة قد تكون مهتمًا بها حاليًا، بناءً على أسماء المضيفين للمواقع الإلكترونية التي تمت زيارتها مؤخرًا.

مكافحة البصمات الرقمية

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

اتخذت المتصفّحات خطوات لإيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا، إلا أنّ أساليب تحديد وتتبّع سلوك المستخدمين الفرديين، والذي يُعرف باسم البصمات الرقمية، استمرّ في التطوّر. تستخدم البصمات آليات لا يعرفها المستخدمون ولا يمكنهم التحكم فيها.

  • يهدف اقتراح ميزانية الخصوصية إلى الحدّ من إمكانية البصمات الرقمية من خلال تحديد مقدار بيانات بصمة الإصبع التي يتم عرضها من خلال واجهات برمجة تطبيقات JavaScript أو "الواجهات" الأخرى. (مثل عناوين طلبات HTTP) ووضع حد لكمية البيانات التي يمكن الوصول إليها.

  • سيتم تقليل نطاق مساحات عرض ملف مرجعي، مثل العنوان User-Agent، في حين ستخضع البيانات المتاحة من خلال آليات بديلة، مثل Client Hints (تلميحات العميل) لحدود ميزانية الخصوصية. وسيتم تعديل مساحات العرض الأخرى، مثل واجهات برمجة التطبيقات لاتجاه الجهاز ومستوى البطارية، للحفاظ على أقل قدر من المعلومات.

أمان عنوان IP

الهدف: التحكّم في الوصول إلى عناوين IP للحدّ من البصمات الرقمية الخفية، والسماح للمواقع الإلكترونية بإيقاف عرض عناوين IP كي لا يستهلك ميزانية الخصوصية

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

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

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

مكافحة الرسائل غير المرغوب فيها والاحتيال وهجمات الحرمان من الخدمات

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

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

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

  • تقترح Trust Tokens API نهجًا بديلاً يسمح بإثبات مصداقية المستخدم في سياق معيّن، مثل موقع على وسائل التواصل الاجتماعي، لنقل إعلان إلى سياق آخر، مثل عرض إعلان على موقع إخباري، بدون تحديد هوية المستخدم أو الربط بين الهويتي.

تفعيل ميزة انتماء النطاقات إلى الطرف الأول نفسه

الهدف: السماح للكيانات بالإفصاح عن أنّ أسماء النطاقات ذات الصلة مملوكة للطرف الأول نفسه.

تمتلك العديد من المؤسسات مواقع عبر نطاقات متعددة. يمكن أن يُمثِّل ذلك مشكلة في حال فرض قيود على تتبُّع هوية المستخدم على مستوى المواقع الإلكترونية التي تُصنَّف على أنّها "جهات خارجية". لكنها في الواقع تنتمي إلى نفس المؤسسة.

  • مجموعات الطرف الأول تهدف إلى جعل مفهوم الويب للطرف الأول والطرف الثالث أكثر توافقًا مع العالم الحقيقي من خلال السماح لنطاقات متعددة بالإعلان عن أنها تنتمي إلى الطرف الأول نفسه.

التعرف على المزيد

تفسيرات حول اقتراحات "مبادرة حماية الخصوصية"

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

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

مبادرة حماية الخصوصية

المناقشة والمشاركة

حالات الاستخدام والسياسات والمتطلبات

الملحق: مسرد المصطلحات المستخدمة في تفسيرات الاقتراح

نسبة النقر إلى الظهور (CTR)

نسبة المستخدمين الذين ينقرون على إعلان بعد أن شاهدوه. (راجع أيضًا الظهور.)

الإحالة الناجحة الناتجة عن النقر (CTC)

إحالة ناجحة منسوبة إلى إعلان تم النقر عليه.

الإحالة الناجحة

إتمام إجراء على موقع المعلن الإلكتروني من قِبل مستخدم سبق له التفاعل مع إعلان من هذا المعلن. على سبيل المثال، شراء منتج أو الاشتراك في رسالة إخبارية بعد النقر على إعلان يرتبط بالموقع الإلكتروني للمعلِن.

الخصوصية التفاضلية

مشاركة معلومات حول مجموعة بيانات للكشف عن أنماط السلوك بدون الكشف عن معلومات خاصة حول الأفراد أو ما إذا كانوا ينتمون إلى مجموعة البيانات

النطاق

راجِع نطاق المستوى الأعلى وeTLD.

eTLD وeTLD+1

"فعالة" يتم تحديد نطاقات المستوى الأعلى من خلال قائمة اللاحقة العامة. على سبيل المثال:

co.uk
appspot.com
glitch.me

تتيح نطاقات المستوى الأعلى الفعّالة أن يكون foo.appspot.com موقعًا مختلفًا عن bar.appspot.com. في هذه الحالة، يكون نطاق المستوى الأعلى الفعّال (eTLD) هو appspot.com، ويُعرف اسم الموقع الإلكتروني بالكامل (foo.appspot.com وbar.appspot.com) باسم eTLD+1.

راجِع أيضًا نطاق المستوى الأعلى.

الإنتروبيا

يشير ذلك المصطلح إلى مقياس لمقدار ما يكشف عنه أحد عناصر البيانات عن الهوية الفردية.

يُقاس قصور البيانات بالبت. كلما كشفت البيانات عن الهوية، زادت قيمة القصور.

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

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

أساليب لتحديد سلوك كل مستخدم على حدة وتتبُّعه. تستخدم البصمات آليات لا يعرفها المستخدمون ولا يمكنهم التحكم فيها.

سطح البصمات

أداة يمكن استخدامها (على الأرجح مع مساحات عرض أخرى) لتحديد مستخدم أو جهاز معيّن على سبيل المثال، تتيح طريقة JavaScript navigator.userAgent() وعنوان طلب HTTP User-Agent إمكانية الوصول إلى مساحة مرجعية (سلسلة وكيل المستخدم).

الطرف الأول

الموارد من الموقع الإلكتروني الذي تزوره حاليًا. على سبيل المثال، الصفحة التي تقرأها موجودة على الموقع web.dev وتتضمّن موارد من هذا الموقع الإلكتروني. راجِع أيضًا الخدمات التابعة لجهة خارجية.

ظهور

مشاهدة أحد الإعلانات (اطّلع أيضًا على نسبة النقر إلى الظهور).

المجهولة الهوية

يشير ذلك المصطلح إلى مقياس لإخفاء الهوية في مجموعة بيانات. في حال إخفاء الهوية بـ k، لا يمكن التمييز بين الأفراد الآخرين في مجموعة البيانات k-1. بعبارة أخرى، يحصل ك فرد على المعلومات نفسها (بما فيهم أنت).

رقم

رقم عشوائي يُستخدم مرة واحدة فقط في الاتصال المشفّر.

الأصل

أصل الطلب، بما في ذلك اسم الخادم بدون معلومات المسار. مثلاً: https://web.dev

السطح السلبي

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

تقترح "مبادرة حماية الخصوصية" استبدال مساحات العرض السلبية بطُرق نشطة للحصول على معلومات معيّنة، على سبيل المثال، استخدام "تلميحات العميل" مرة واحدة للحصول على لغة المستخدم بدلاً من توفير رأس لغة مقبولة لكل ردّ على كل خادم.

الناشر

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

مدى الوصول إلى الجمهور

إجمالي عدد الأشخاص الذين يشاهدون إعلانًا.

تجديد النشاط التسويقي

عرض إعلانات لأشخاص سبق لهم زيارة موقعك الإلكتروني. على سبيل المثال، يمكن أن يعرض متجر على الإنترنت إعلانات لتخفيضات على الألعاب للأشخاص الذين سبق لهم مشاهدة الألعاب على موقعه الإلكتروني.

الموقع

راجِع نطاق المستوى الأعلى وeTLD.

مساحات العرض

راجِع سطح بصمات الأصابع وسطح المكتب الخامل.

جهة خارجية

الموارد التي يتم عرضها من نطاق يختلف عن الموقع الإلكتروني الذي تزوره. على سبيل المثال، قد يستخدم موقع foo.com رمز تحليلات من google-analytics.com (عبر JavaScript) وخطوطًا من use.typekit.net (عبر عنصر رابط) وفيديو من vimeo.com (في iframe). راجِع أيضًا الطرف الأول.

نطاق المستوى الأعلى (TLD)

يتم سرد نطاقات المستوى الأعلى مثل .com و .org في قاعدة بيانات Root Zone.

لاحظ أن بعض "المواقع" هي في الواقع نطاقات فرعية فقط. على سبيل المثال، translate.google.com وmaps.google.com هما مجرد نطاقين فرعيين للنطاق google.com (وهو eTLD + 1).

.well-known

قد يكون من المفيد الوصول إلى سياسة أو معلومات أخرى حول المضيف قبل تقديم طلب. على سبيل المثال، يوجّه ملف robots.txt برامج زحف الويب إلى الصفحات التي يجب زيارتها والصفحات التي يجب تجاهلها. تحدّد مجموعة مهندسي شبكة الإنترنت (IETF) RFC8615 طريقة موحّدة لإتاحة الوصول إلى البيانات الوصفية على مستوى الموقع الإلكتروني في مواقع عادية في دليل فرعي /.well-known/. يمكنك الاطّلاع على قائمة بهذه الأنشطة على iana.org/assignments/well-known-uris/well-known-uris.xhtml.

نشكر كل من ساعدنا في كتابة هذه المشاركة ومراجعتها.

صورة من إعداد بيير بامين على موقع Unسبلاش