تم تصميم مجموعات نطاقات الطرف الأول (FPS) لدعم تجربة تصفّح الويب للمستخدمين بعد إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا في Chrome. لقد تطور الاقتراح بشكل كبير في منتديات الويب المفتوحة خلال مرحلة الحاضنة لإطار عمل الخصوصية، أولاً في مجموعة منتدى الخصوصية التابعة لمنظمة W3C، والآن في مجموعة منتدى Web Incubator.
في مشاركة المدوّنة هذه، سنلخّص عملية التطور ونسلّط الضوء على التغييرات الرئيسية، ونناقش سبب اعتقادنا بأنّ هذه التغييرات تحسّن الخصوصية على الويب مع مواصلة دعم المنظومة المتكاملة.
الخلفية
غالبًا ما تعتمد المواقع الإلكترونية على الوصول إلى ملفات تعريف الارتباط الخاصة بها في سياق تابع لجهة خارجية لتقديم تجربتَين سلستَين ومخصّصتَين للمستخدمين. بالإضافة إلى واجهات برمجة التطبيقات التي تحافظ على خصوصية الإعلانات (Topics وProtected Audience API وAttribution)، سعى فريق Chrome إلى فهم نطاق السيناريوهات التي يتم فيها استخدام ملفات تعريف الارتباط التابعة لجهات خارجية، بخلاف أغراض تخصيص الإعلانات أو القياس، لمحاولة تقديم تجارب تصفّح محسّنة للمستخدمين.
تبيّن لنا أنّ المؤسسات قد تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية لأنّ بنية الويب الخاصة بها مصمّمة للاستفادة من نطاقات متعددة. على سبيل المثال، قد يكون لدى مؤسسة نطاق واحد لمدوّنتها عن المشي لمسافات طويلة ونطاق آخر لمتجر التخييم، وتريد تحسين تجارب المستخدمين على هذين الموقعَين الإلكترونيَين. يمكن أن تديرها مؤسسة أيضًا نطاقات متعددة برمز بلد مع بنية تحتية مشترَكة لخدمة الويب. في مثل هذه الحالات، سعينا إلى إنشاء حلّ يتوافق مع احتياجات هذه المؤسسات، مع الحفاظ على توقعات المستخدمين بشأن خصوصيتهم على الويب.
نقطة البداية
بما أنّ المتصفّح يستخدم حاليًا الحدّ على مستوى الموقع الإلكتروني لتفسير "الطرف الأول" في مقابل "الطرف الثالث"، ونظرًا لمجموعة النطاقات التي قد تديرها مؤسّسة، بدت مناسبة استبدال هذه الحدود الفنية بتعريف أكثر دقة.
في عام 2021، اقترح Chrome في البداية سمة ملف تعريف الارتباط SameParty لملف تعريف الارتباط
"مجموعة نطاقات الطرف الأول"، بحيث يمكن للمواقع الإلكترونية تحديد ملفات تعريف الارتباط التي تأتي من مواقع إلكترونية
ضمن "الطرف نفسه". لقد استخدمنا
سياسة وكيل المستخدم
لتحديد ما الذي يشكّل "الطرف نفسه". حاول تعريف السياسة هذا
الاستناد إلى الأطر الحالية لـ "الطرف" (على سبيل المثال، من مواصفة DNT في W3C) ودمج اقتراحات من المناقشات ذات الصلة بالخصوصية (مثل تقرير لجنة التجارة الفيدرالية لعام 2012 بعنوان
"حماية خصوصية المستهلكين في عصر التغيير السريع").
في ذلك الوقت، اعتقدنا أنّ هذا النهج يقدّم مرونة كافية لأنواع مختلفة من المؤسسات في جميع المجالات، مع الالتزام أيضًا بهدفنا الأساسي المتمثل في الحدّ من التتبّع الواسع النطاق من خلال ملفّات تعريف الارتباط التابعة لجهات خارجية.
ملاحظات حول الاقتراح الأوّلي
من خلال العديد من المحادثات مع الجهات المعنية في المنظومة المتكاملة للويب، تبيّن لنا أنّ هناك قيودًا على هذا التصميم الأولي.
تحديات الخصوصية في ما يتعلّق بالوصول السلبي إلى ملفات تعريف الارتباط من خلال سمة SameParty
مورّدو المتصفّحات الآخرون فضّلوا استخدام أسلوب فعال للوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية يتطلّب استخدام واجهة برمجة تطبيقات صريحة، بدلاً من وضع حدود يمكن ضمنها الحفاظ على الوصول السلبي إلى ملفات تعريف الارتباط. توفّر الطلبات النشطة للوصول إلى ملفات تعريف الارتباط إمكانية الاطّلاع على المتصفح والتحكّم فيه، ما يحدّ من خطر التتبّع الخفي من خلال ملفات تعريف الارتباط التابعة لجهات خارجية. بالإضافة إلى ذلك، ستسمح هذه الرؤية للمتصفّحات بمنح المستخدمين خيار السماح بالوصول إلى ملفات تعريف الارتباط هذه أو حظرها.
لقد قرّرنا اتّخاذ هذا الإجراء بهدف تحسين إمكانيات التشغيل التفاعلي للويب على جميع المتصفحات، فضلاً عن تحسين مزايا الخصوصية.
تحديات التنفيذ في السياسة المقترَحة
اقترحت السياسة الأصلية ثلاثة متطلبات لكي تكون النطاقات في مجموعة واحدة: "الملكية المشتركة" و"سياسة الخصوصية المشتركة" و "هوية المجموعة المشتركة".
من خلال المنظومة المتكاملة الأوسع نطاقًا، تبيّن لنا أنّ الملاحظات التي تلقّيناها بشأن السياسة تتبع أربعة مواضيع رئيسية.
الملكية المشتركة مقيّدة جدًا
في ما يتعلّق بمتطلبات "الملكية المشتركة"، تلقّينا ملاحظات تفيد بأنّ تعريف FPS الذي يركّز فقط على ملكية الشركات سيمنح الشركات الأكبر حجمًا قدرة أكبر على تجميع البيانات على مستوى مجموعة كبيرة من النطاقات والخدمات الموجّهة للمستخدمين، مقارنةً بالشركات الأصغر حجمًا. بما أنّ هدفنا هو إنشاء "مبادرة حماية الخصوصية" للمنظومة المتكاملة ككل، أخذنا هذه الملاحظات على محمل الجدّ وأعطينا الأولوية لحلّ أكثر شمولية.
سياسة واحدة تحدّ من إمكانية توسيع نطاق الإضافة إلى حالات الاستخدام
على الرغم من أنّ فكرة وضع سياسة شاملة لتنظيم حدود كانت تهدف إلى توفير مرونة لأنواع مختلفة من النطاقات التي يجب أن تكون في FPS الخاصة بالمؤسسة، تبيّن لنا أنّ بعض حالات الاستخدام المهمة لا يمكنها استيفاء تصميم هذه السياسة. على سبيل المثال، قد تتطلّب نطاقات الخدمات (مثل النطاقات التي تستضيف محتوًى من إنشاء المستخدمين) الوصول إلى ملفات تعريف الارتباط في سياق تابع لجهة خارجية بغرض مصادقة المستخدمين أو تحديد هويتهم. نادرًا ما تتضمّن هذه النطاقات ملفًا شخصيًا أساسيًا يمكن للمستخدم الوصول إليه، لذا لا يمكن استيفاء متطلبات "هوية المجموعة المشتركة" أو "سياسة الخصوصية المشتركة" مع النطاقات الأخرى في إطار الخدمة نفسها.
قد يختلف إدراك المستخدمين وفهمهم لهوية المجموعة.
لقد اقترحنا في الأصل وضع قيود لتحديد "هوية مجموعة مشتركة" كمحاولة لتحديد نطاق النطاقات ضمن مجموعة واحدة على تلك التي يمكن بسهولة ربطها بهوية مجموعة مشتركة. ومع ذلك، لم نتمكّن من تحديد وسائل فنية لقياس وتقييم ما إذا كان بإمكان "المستخدمين اكتشاف هوية المجموعة المشتركة بسهولة". وقد أدّى ذلك إلى احتمال إساءة الاستخدام والأسئلة حول التنفيذ.
لقد تلقّينا أيضًا ملاحظات تفيد بأنّ فهم معنى حدود "الملكية المشتركة" قد يختلف من مستخدم إلى آخر، ما يجعل من الصعب وضع إرشادات يمكن تطبيقها على جميع المواقع الإلكترونية.
من الصعب فرض سياسة ذاتية على نطاق واسع.
لقد تلقّينا العديد من الطلبات للحصول على إرشادات أكثر تفصيلاً، نظرًا لطبيعة المتطلبات المعيّنة (مثل "المعرّف المشترك للمجموعة") والحاجة إلى تغطية الاستثناءات أو الحالات الشاذة للآخرين (في ما يتعلّق "بسياسة الخصوصية المشتركة").
لضمان تطبيق السياسة بشكل عادل ومتسق، كان على Chrome أن يقدّم لمؤلفي المواقع الإلكترونية إرشادات أكثر تحديدًا. تبيّن لنا أنّ محاولة وضع إرشادات أكثر صرامة قد تضرّ بالمنظومة المتكاملة.
على الرغم من أنّنا اقترحنا في البداية أن يتولّى كيان مستقل لإنفاذ السياسات دور التحقيق في الامتثال للسياسة وإنفاذها، كان من الصعب في المنظومة المتكاملة الحالية العثور على كيان مستقل لإنفاذ السياسات لديه المهارة المناسبة لتنفيذ هذه المسؤوليات بطريقة غير متحيّزة. وبدلاً من ذلك، سعينا جاهدين إلى التركيز على سياسة يمكن تطبيقها من الناحية الفنية لضمان إمكانية تطبيق التنفيذ بشكلٍ متسق وموضوعي.
التطوّر
استجابةً للملاحظات التي تلقّيناها، أعدنا تصميم ميزة "عدد اللقطات في الثانية". عدنا إلى الصعوبات العميقة التي كنا نحاول معالجتها، وقرّرنا صياغة المقترح بشكل مباشر أكثر حول حالات الاستخدام المحدّدة التي كنا نحلّها.
حلّ المشاكل في حالات الاستخدام الرئيسية
طوّر فريق Chrome ثلاث "مجموعات فرعية" مختلفة مخصّصة لتلبية حالات الاستخدام الرئيسية على الويب. ولقد تم تحسين أسلوب المجموعات الفرعية مقارنةً بالأسلوب القديم من خلال أنّه أكثر خصوصية وتحديدًا وسهولة في تطبيقه بشكلٍ متسق.
- "نطاقات المستوى الأعلى لرموز البلدان" (ccTLD): قد تدير المؤسسات مواقع إلكترونية بنطاقات مختلفة لرموز البلدان من أجل توفير تجارب مترجَمة، وقد تظل هذه المواقع تتطلّب الوصول إلى الخدمات والبنية الأساسية المشتركة.
- نطاقات "الخدمة": قد تستخدم المواقع الإلكترونية نطاقات منفصلة لأغراض الأمان أو الأداء، وقد تتطلّب هذه المواقع الإلكترونية الوصول إلى هوية المستخدم لأداء وظائفها.
- النطاقات "المرتبطة": يمكن للمؤسسات الاحتفاظ بمواقع إلكترونية متعددة لعلامات تجارية أو منتجات مختلفة ومتعلّقة. قد يريدون الوصول إلى ملفات تعريف الارتباط على جميع المواقع الإلكترونية لاستخدامات مثل إحصاءات تجارب المستخدِمين على المواقع الإلكترونية ذات الصلة لفهم كيفية تفاعل قاعدة مستخدِمي المؤسسة مع مواقعها الإلكترونية بشكلٍ أفضل، أو لتذكر حالة تسجيل دخول المستخدِم على موقع إلكتروني ذي صلة بالاستناد إلى البنية الأساسية نفسها لتسجيل الدخول.
لكل حالة من حالات الاستخدام هذه، هناك متطلبات سياسة منفصلة، وعمليات تحقّق فنية مقابلة، وسلوك معيّن في التعامل مع المتصفّح (اطّلِع على مزيد من المعلومات في إرشادات الإرسال). تعالج هذه التغييرات القيود في الاقتراح الأصلي من خلال التخلي عن تصميم "يناسب الجميع"، والميل إلى استخدام إطار عمل مجزأ يستند إلى حالات الاستخدام.
فرصة للتشغيل التفاعلي من خلال الطلبات النشطة للوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية
يحرص Chrome على تعزيز إمكانية التشغيل التفاعلي مع المتصفّحات الأخرى للحفاظ على سلامة نظام الويب الأساسي. بما أنّ المتصفّحات الأخرى، مثل Safari وFirefox وEdge، تستخدم حاليًا واجهة برمجة التطبيقات Storage Access API (SAA) لتسهيل طلبات ملفات تعريف الارتباط النشطة، اخترنا الاستفادة من SAA في Chrome ليس فقط للمساعدة في معالجة الملاحظات الرئيسية التي تلقّيناها، ولكن أيضًا لدعم إمكانية التشغيل التفاعلي للويب.
لتوفير المزيد من المرونة للمطوّرين ومعالجة القيود المعروفة لـ SAA،
اقترحنا أيضًا واجهة برمجة التطبيقات requestStorageAccessForOrigin.
فرصة استخدام Storage Access API وFPS معًا
عند تنفيذ واجهة برمجة التطبيقات Storage Access API (SAA)، قد تختار المتصفّحات طلب الإذن من المستخدمين مباشرةً، وقد تختار متصفّحات أخرى السماح بعدد محدود من الطلبات بدون طلب الإذن.
يعتقد فريق Chrome أنّ واجهة برمجة التطبيقات لطلبات البحث الفوري يمكن أن توفّر طبقة شفافة فوق واجهة برمجة التطبيقات لطلبات البحث العادية، وذلك من خلال الحدّ من الصعوبات التي يواجهها المستخدمون ومنع الشعور بالإرهاق من الطلبات في حالات الاستخدام الرئيسية والمحدودة. توفّر ميزة FPS للمتصفّحات أيضًا مرونة في تقديم سياق إضافي للمستخدمين حول الاشتراك المحدد، إذا اختاروا مطالبة المستخدمين بالحصول على الإذن.
باستخدام مجموعات نطاقات الطرف الأول، يمكن للمطوّرين تحديد مواقعهم الإلكترونية المتأثرة التي تخدم حالات الاستخدام الرئيسية. يمنح ذلك المطوّرين إمكانية توقّع كيفية عمل مواقعهم الإلكترونية للمستخدمين، واتّخاذ تدابير للحدّ من التأثير على تجربتهم، وذلك من خلال الاستفادة من عدد اللقطات في الثانية أو بديل ملفّ تعريف ارتباط تابع لجهة خارجية. بالإضافة إلى ذلك، توفّر ميزة "FPS" للمطوّرين إمكانية توقّع أداء المنصة، على عكس الأساليب الاستقرائية التي قد تتغيّر بمرور الوقت أو تؤدي إلى سلوكيات مختلفة للمستخدمين.
أخيرًا، سيتمكّن المطوّرون الذين ينفذون ميزة SAA للعمل مع FPS في Chrome أيضًا من الاستفادة من ميزة SAA لتحسين أداء مواقعهم الإلكترونية على المتصفّحات الأخرى، حتى تلك التي لا توفّر FPS.
مناقشة مستمرة
نعتقد أنّ اقتراحنا الأخير يحقق التوازن الصحيح في مساحة صعيبة للتنازلات تراعي احتياجات المستخدمين والمطوّرين. نحن نقدّر ملاحظات الأطراف المعنية بالمنظومة المتكاملة للويب التي ساعدتنا في تطوير مقترح FPS.
ندرك أنّ الجهات المعنية في منظومة الويب المتكاملة لا تزال تتعرّف على الاقتراح المعدَّل. يُرجى التواصل معنا لنتمكّن من مواصلة تحسين التصميم بطريقة أكثر فائدة للمطوّرين ومواصلة تحسين الخصوصية على الويب. ستواصل Google أيضًا العمل مع هيئة Competition and Markets Authority (CMA) في المملكة المتّحدة لضمان الامتثال للالتزامات.
للتفاعل مع الجمهور، يمكنك الاطّلاع على المراجع التالية:
- فترة الحضانة في WICG
- تعليمات اختبار عدد اللقطات في الثانية
- مجموعات نطاقات الطرف الأول: دليل الدمج
- إرشادات إرسال لقطات في الثانية
العمل مع المنظومة المتكاملة
يسرّنا أن نرى شركات مثل Salesforce وCafeMedia تشارك الملاحظات الرئيسية وتعمل على تطوير مجموعات الطرف الأول. وقد لعبت هذه الأدوات دورًا رئيسيًا في تطوير التكنولوجيا. شارك العديد من الأشخاص الآخرين أيضًا أفكارهم حول مجموعات الطرف الأول وجهود Chrome في العمل مع المنظومة المتكاملة للويب:
"يعمل Chrome على تطوير مجموعات الطرف الأول بما يتوافق مع العديد من حالات الاستخدام، مثل الحفاظ على تجارب المستخدمين. يُظهر لنا ذلك أنّ فريق Google يعمل على فهم الأنواع المختلفة من احتياجات مالكي المواقع الإلكترونية على الويب". - Mercado Libre
"في VWO، نقدّر جهود Google لرفع معايير الخصوصية، مع ضمان معالجة حالات الاستخدام الحقيقية. من الرائع أنّ الفريق يتعاون مع منظومة المطوّرين المتكاملة، ويُجري تحسينات مستمرة على تنفيذ اقتراح مجموعات الطرف الأول استنادًا إلى الملاحظات الواردة من الجهات المعنية بالويب. يسرّنا أن نكون جزءًا من رحلة اختبار الاقتراح ونتطلع إلى دمجه في المتصفّح". - "نيتيش ميتال"، مدير قسم الهندسة في VWO