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