تعمل العديد من واجهات برمجة تطبيقات "مبادرة حماية الخصوصية" على تكثيف جهود الوصول إلى مدى التوفّر للجمهور العام في إصدار Chrome الثابت استعدادًا للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية اعتبارًا من عام 2024. ستساعد بعض واجهات برمجة التطبيقات هذه في الحفاظ على الحالات الأساسية لاستخدام ملفات تعريف الارتباط على مواقع إلكترونية متعددة، مثل الشرائح وواجهة برمجة التطبيقات المعروفة حاليًا باسم مجموعات نطاقات الطرف الأول (FPS). في هذه المشاركة، سنقدّم ميزة "مجموعات المواقع الإلكترونية المرتبطة" (RWS)، وهي الاسم الجديد الذي يُطلق على FPS، والذي يعكس الغرض منها بشكل أفضل، ونقدّم معلومات عن حالات الاستخدام الرئيسية بالإضافة إلى تعديل بشأن الحدّ الأقصى لنطاق النطاق الفرعي المرتبط.
الحفاظ على رحلات المستخدم المهمة
تم تصميم RWS لتقليل انقطاعات ميزات محددة موجَّهة للمستخدمين بعد أن يبدأ Chrome في تقييد الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. يكمن هدفنا في السماح للمستخدمين بتصفّح الويب بأقلّ نسبة ممكنة من انقطاع الخدمة مع الالتزام بأهداف الخصوصية التي وضعتها "مبادرة حماية الخصوصية". لتحقيق هذا التوازن، تستهدف RWS حالات استخدام معيّنة تتعلّق بوظائف الموقع الإلكتروني:
- تعالج حالة استخدام ccTLD الأعطال، مثل مثال تسجيل الدخول المقدَّم في أداة التتبُّع المتاحة للجميع. غالبًا ما يتم التعامل مع مثل هذه الحالات في المنظومة المتكاملة من خلال استثناءات تستند إلى الإرشادات (راجِع المرجع 1).
- تتناول حالة استخدام نطاق الخدمة إحدى الممارسات الشائعة لمطوّري البرامج لعزل الوظائف الحساسة (مثل دعم تدفق المصادقة) عن النطاقات الموجّهة للمستخدمين. يمكن معالجة مثل هذه الحالات في المنظومة المتكاملة من خلال استثناءات مستهدَفة (راجِع المرجع 2).
- توفّر حالة استخدام النطاق المرتبط مزيدًا من المرونة لأنواع النطاقات التي قد تتطلّب الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية في تجارب المستخدمين المهمة (اطّلِع على المرجع 3). يستخدم النطاقان المرتبطان بـ ccTLD ونطاق الخدمة عمليات فحص تقنية صارمة استنادًا إلى خصائص النطاق للحدّ من إساءة الاستخدام، إلّا أنّ النطاق المرتبط يستخدم حدًا رقميًا. يمكنك الاطّلاع على المزيد من المعلومات حول هذا الموضوع في القسم التالي.
تمت زيادة حد النطاقات المرتبطة إلى خمسة نطاقات
اقترح Chrome سابقًا حدًا رقميًا يبلغ ثلاثة نطاقات للمجموعة الفرعية المرتبطة (بالإضافة إلى نطاق أساسي واحد)، تماشيًا مع هدفنا لمنع إساءة استخدام التتبّع على نطاق واسع. لقد وصلتنا ملاحظات من المشاركين في معايير الويب تفيد بأنّ الحدّ كان منخفضًا جدًا لأنواع مختلفة من حالات الاستخدام.
لقد قرّرنا زيادة حد النطاقات المرتبطة إلى خمسة نطاقات (بالإضافة إلى نطاق أساسي واحد) والتي تتطابق على أفضل نحو مع طريقة التنفيذ الأكثر تشابهًا التي يوفّرها متصفّح رئيسي آخر (راجع المرجع 4). سيسري هذا بدءًا من إصدار Chrome 117.
بما أنّ RWS غير مخصّصة كحل للإعلانات، فإننا لا نأخذ في الاعتبار الملاحظات حول كيفية تحسين RWS لعرض حالات استخدام الإعلانات بشكل أفضل. بالنسبة إلى حالات استخدام الإعلانات، على المطوّرين استكشاف استخدام Topics API وProtected Audience API وAttribution Reporting API وتقديم الملاحظات بشأنها وفقًا لذلك.
يمكن للمستخدمين اختيار حالات الاستخدام الموسَّع لأكثر من خمسة نطاقات مرتبطة.
بالنسبة إلى تجارب المستخدمين المتأثرة التي لا تتوافق مع هذا الحد الأقصى، يعمل Chrome على مسار يطلب من المستخدم الاستفادة أيضًا من واجهة برمجة التطبيقات Storage Access API (SAA)، وهو معيار تعتمده المتصفحات الأخرى. بالنسبة إلى حالات الاستخدام التي تتطلّب أكثر من خمسة نطاقات مرتبطة، ننصح المطوّرين بتقييم كيفية إتاحة SAA في السياقات التي لا تستخدم نظام أسماء النطاقات (RWS). نحن نتّبع عملية إطلاق Blink بشكل منفصل لهذه الميزة، والتي سيتم طرحها في إصدار Chrome لسطح المكتب بدءًا من Chrome 117.
الخطوات التالية
نحن ممتنّون لملاحظات المنظومة المتكاملة التي ساعدت في تشكيل واجهة برمجة التطبيقات حتى الآن. وقد استثمرنا في RWS كطريقة لتزويد المطوّرين بإمكانية التنبؤ والتحكّم والتحكُّم في الحفاظ على تجربة المستخدم النهائي في المواقع الإلكترونية التي ينشئونها. نحن متحمسون لمعرفة كيف يستخدم المطوّرون RWS في سعينا إلى تكثيف جهودنا. يتم حاليًا عملية الإرسال، وتشكّل أداة إنشاء RWS JSON نقطة انطلاق رائعة للمساعدة في عمليات الإرسال.
اتّبِع سلسلة محادثات Intent to Ship (هدف الشحن) لتتبُّع مستوى التقدّم، واطّلِع على هذه المواد للحصول على إرشادات حول عملية التنفيذ.
المراجع
- هناك اتفاق عام عبر المتصفحات على أن حالات استخدام ملفات تعريف الارتباط على مواقع إلكترونية متعددة هذه ضرورية، ولكنها اتخذت مناهج مختلفة لتفعيلها. نفّذ كل من Firefox (code) وSafari (رمز برمجي) الدليل الإرشادي المنبثق الذي يعالج العطل الذي تم رصده، على سبيل المثال في عملية تسجيل الدخول إلى Nintendo.
- هناك أيضًا أمثلة متعددة تُستبعد فيها استثناءات الرموز الثابتة للمتصفِّحات لتقليل انقطاع الخدمة للمستخدمين. يمنح Firefox إمكانية الوصول إلى مساحة التخزين عند تدفق عمليات إعادة التوجيه بين Microsoft Teams وlogin.microsoftonline.us.
- يوفّر Firefox عنصر "shim" الذي يستدعي requestStorageAccessForOrigin نيابةً عن facebook.com عندما يسجّل المستخدم الدخول إلى instagram.com. ويمكن الاطّلاع أيضًا على مثال على تجميع المواقع الإلكترونية في الاستثناءات الثابتة في Safari لتجميع طلبات الوصول إلى مساحة التخزين لنطاقات متعددة.
- يمنح Firefox تلقائيًا أول 5 طلبات بحث من نوع requestStorageAccess التي أجراها موقع إلكتروني تابع لجهة خارجية (الرمز) زارها المستخدم من قبل. في Chrome، ستحصل النطاقات الخمسة الأولى المدرجة في المجموعة الفرعية المرتبطة بالإضافة إلى النطاق الأساسي للمجموعة نفسها على إمكانية الوصول التلقائي لملفات تعريف الارتباط التابعة لجهات خارجية من خلال RWS.