[OUTDATED] مجموعات نطاقات الطرف الأول وسمة SameParty

لدى العديد من المؤسسات مواقع إلكترونية ذات صلة بأسماء نطاقات مختلفة، مثل brandx.site وfly-brandx.site، أو نطاقات لبلدان مختلفة، مثل example.com وexample.rs وexample.co.uk وما إلى ذلك.

تعمل المتصفّحات على إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا لتحسين الخصوصية على الويب، ولكنّ المواقع الإلكترونية مثل هذه تعتمد غالبًا على ملفات تعريف الارتباط لتوفير وظائف تتطلّب الحفاظ على الحالة والوصول إليها على مستوى النطاقات (مثل تسجيل الدخول المُوحَّد وإدارة الموافقة).

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

يُعدّ اقتراح "مجموعات الطرف الأول" في مرحلة الاختبار حاليًا، لذا يُرجى الاطّلاع على المزيد من المعلومات لمعرفة طريقة عمله وكيفية تجربته.

ما الفرق بين ملفات تعريف الارتباط التابعة للطرف الأول والتابعة لجهة خارجية؟

لا تكون ملفات تعريف الارتباط بالضرورة خاصة بالطرف الأول أو تابعة لجهة خارجية، بل يعتمد ذلك على السياق الحالي الذي يتم تضمين ملف تعريف الارتباط فيه. يمكن إجراء ذلك إما في طلب في عنوان cookie أو من خلال document.cookie في JavaScript.

على سبيل المثال، إذا كان الموقع الإلكتروني video.site يتضمّن ملف تعريف ارتباط theme=dark، عند تصفّح video.site وتقديم طلب إلى video.site، يكون ذلك في سياق الموقع الإلكتروني نفسه وملف تعريف الارتباط المضمّن هو ملف تعريف ارتباط الطرف الأول.

ومع ذلك، إذا كنت تستخدم الموقع الإلكتروني my-blog.site الذي يضمّن مشغّلًا لإطار iframe لتطبيق video.site، عند تقديم الطلب من my-blog.site إلى video.site، يكون ذلك سياقًا على مواقع إلكترونية مختلفة ويكون ملف تعريف الارتباط theme تابعًا لجهة خارجية.

مخطّط بياني يعرض ملفّ تعريف ارتباط من video.site في سياقَين يكون ملف تعريف الارتباط على الموقع الإلكتروني نفسه عندما يكون السياق على المستوى الأعلى هو video.site أيضًا. يكون ملف تعريف الارتباط من عدة مواقع إلكترونية عندما يكون السياق على المستوى الأعلى هو my-blog.site مع video.site في إطار iframe.

يتم تحديد تضمين ملفّ تعريف الارتباط من خلال سمة SameSite الخاصة به:

ومع ذلك، لا يكون هذا الأمر واضحًا دائمًا. لنفترض أنّ brandx.site هو موقع إلكتروني لخدمات حجز السفر، ويستخدم أيضًا fly-brandx.site وdrive-brandx.site لتمييز رحلات الطيران وتأجير السيارات. على مدار عملية حجز رحلة واحدة، ينتقل الزوّار بين هذه المواقع الإلكترونية لاختيار خياراتهم المختلفة، ويتوقعون أن تظل "سلة التسوّق" التي تضم اختياراتهم محفوظة على هذه المواقع الإلكترونية. brandx.site تدير جلسة المستخدِم باستخدام ملف تعريف ارتباط SameSite=None للسماح به في سياقات المواقع الإلكترونية المختلفة. على الجانب الآخر، لا توفّر ملف تعريف الارتباط حاليًا حماية من التزوير العميق لطلبات المواقع الإلكترونية (CSRF). إذا كان evil.site يتضمّن طلبًا إلى brandx.site، سيتضمّن هذا ملف تعريف الارتباط.

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

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

سياسة مجموعات نطاقات الطرف الأول

تقترح مجموعات نطاقات الطرف الأول طريقة لتحديد هذه العلاقة بشكل صريح على مستوى مواقع إلكترونية متعددة يملكها ويشغّلها الطرف نفسه. سيتيح ذلك brandx.site تحديد علاقته بصفتها الطرف الأول مع fly-brandx.site وdrive-brandx.site وما إلى ذلك.

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

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

على الرغم من أنّ الخيار التلقائي هو التقسيم حسب الموقع الإلكتروني، ما يحلّ العديد من حالات استخدام الطرف الأول، يوضّح مثال brandx.site أنّ الطرف الأول يمكن أن يكون أكبر من موقع إلكتروني واحد فقط.

مخطّط بياني يعرض كيفية تضمين نسخة ملفّ تعريف الارتباط نفسها لمجموعة واحدة في سياقات على مستوى المواقع الإلكترونية عندما تكون جميع هذه المواقع الإلكترونية جزءًا من المجموعة نفسها

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

يمكن أن يكون أحد الطرق الممكنة لموقع إلكتروني لتسجيل مجموعة تابعة للطرف الأول هي أن يُرسِل الموقع الإلكتروني مجموعة النطاقات المقترَحة إلى خدمة تتبُّع عامة (مثل مستودع GitHub مخصّص) مع المعلومات اللازمة لاستيفاء سياسة المتصفّح.

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

تسري سياسة محدّدة على الفترة التجريبية الأصلية، وهي ليست نهائية، ولكن من المرجّح أن تظل المبادئ كما هي:

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

كيفية تحديد مجموعة الطرف الأول

بعد تحديد أعضاء مجموعة الطرف الأول لمؤسستك ومالكها، ستكون الخطوة الحاسمة هي إرسال المجموعة المقترَحة للموافقة عليها. لا تزال العملية الدقيقة قيد المناقشة.

لتعريف مجموعة نطاقات الطرف الأول، يجب أن تكون موارد JSON الثابتة التي تسرد الأعضاء والمالكي مستضافة على /.well-known/first-party-set في المستوى الأعلى من كل نطاق مُدرَج.

في مثال مجموعة الجهات الأولى brandx، يستضيف النطاق الخاص بالمالك العناصر التالية على https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

يستضيف كل عضو في المجموعة أيضًا موردًا ثابتًا بتنسيق JSON يشير إلى مالك المجموعة. في https://fly-brandx.site/.well-known/first-party-set، لدينا:

{ "owner": "brandx.site" }

وفي https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

هناك بعض القيود المفروضة على مجموعات الطرف الأول:

  • يمكن أن يكون للمجموعة مالك واحد فقط.
  • يمكن أن ينتمي العضو إلى مجموعة واحدة فقط، بدون تداخل أو اختلاط.
  • من المفترض أن تظل قائمة الأعضاء قابلة للقراءة نسبيًا وليست كبيرة جدًا.

كيف تؤثر مجموعات نطاقات الطرف الأول في ملفات تعريف الارتباط؟

المكوّن المطابق للكوكيز هو SamePartyسمة المقترَحة. يؤدي تحديد SameParty إلى توجيه المتصفّح إلى تضمين ملفّ تعريف الارتباط عندما يكون سياقه جزءًا من مجموعة الطرف الأول نفسها التي تمّ ضبطها كسياق المستوى الأعلى.

وهذا يعني أنّه إذا ضبط brandx.site ملف تعريف الارتباط هذا:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

بعد ذلك، عندما يكون الزائر على fly-brandx.site ويتم إرسال طلب إلى brandx.site، سيتم تضمين ملف تعريف الارتباط session في هذا الطلب. إذا أرسل موقع إلكتروني آخر غير تابع لمجموعة الطرف الأول، مثل hotel.xyz، طلبًا إلى brandx.site، لن يتم تضمين ملف تعريف الارتباط.

مخطّط بياني يعرض ملفّ تعريف الارتباط brandx.site المسموح به أو المحظور في سياقات على مستوى المواقع الإلكترونية كما هو موضّح

إلى أن تصبح سمة SameParty متاحة على نطاق واسع، استخدِم سمة SameSite معها لتحديد سلوك الردّ الاحتياطي لملفات تعريف الارتباط. يمكنك اعتبار سمة SameParty تمنحك إعدادًا بين SameSite=Lax و SameSite=None.

  • ستوسّع SameSite=Lax; SameParty وظائف Lax لتشمل سياقات الطرف نفسه في حال توفّرها، ولكن ستعود إلى قيود Lax في حال عدم توفّرها.
  • سيؤدي SameSite=None; SameParty إلى حصر وظيفة None في سياقات الطرف نفسه فقط حيثما كان ذلك متاحًا، ولكن سيعود إلى أذونات None الأوسع نطاقًا في حال عدم توفّر ذلك.

هناك بعض المتطلبات الإضافية:

  • يجب أن تتضمّن ملفات تعريف الارتباط SameParty Secure.
  • يجب ألا تتضمّن ملفات تعريف الارتباط SameParty SameSite=Strict.

يجب استخدام Secure لأنّ هذا الإجراء لا يزال على مستوى مواقع إلكترونية متعددة، وعليك الحدّ من هذه المخاطر من خلال ضمان اتصالات آمنة (HTTPS). وبالمثل، بما أنّ هذه علاقة على مستوى مواقع إلكترونية متعددة، فإنّ SameSite=Strict غير صالحة لأنّها لا تزال تسمح بحماية CSRF بشكلٍ صارم على مستوى الموقع الإلكتروني ضمن مجموعة.

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

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

قد يكون لدى مؤسستك نطاقات مختلفة من المستوى الأعلى لكلٍّ ممّا يلي:

  • نطاقات التطبيقات: office.com وlive.com وmicrosoft.com
  • النطاقات التي تحمل علامة تجارية: amazon.com وaudible.com / disney.com وpixar.com
  • النطاقات الخاصة بالبلد لتفعيل الترجمة: google.co.in، google.co.uk
  • نطاقات الخدمات التي لا يتفاعل معها المستخدمون مباشرةً، ولكنّها تقدّم خدمات على مواقع المؤسسة نفسها: gstatic.com، githubassets.com، fbcdn.net
  • نطاقات وضع الحماية التي لا يتفاعل معها المستخدمون مباشرةً، ولكنّها متوفّرة لأسباب تتعلّق بالأمان: googleusercontent.com وgithubusercontent.com

كيف يمكنك المشاركة؟

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

خلال مرحلة الاختبار، يمكنك تجربة الوظيفة باستخدام علامة سطر الأوامر --use-first-party-set وتقديم قائمة بالمواقع الإلكترونية مفصولة بفواصل.

يمكنك تجربة ذلك على الموقع الإلكتروني التجريبي على الرابط https://fps-member1.glitch.me/ بعد بدء Chrome باستخدام العلامة التالية:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

يكون ذلك مفيدًا إذا كنت تريد إجراء الاختبار في بيئة التطوير، أو إذا أردت تجربة إضافة سمة SameParty في بيئة علنية لمعرفة كيفية تأثير مجموعة الطرف الأول في ملفات تعريف الارتباط.

إذا كان لديك النطاق الترددي المطلوب لإجراء التجارب وتقديم الملاحظات، يمكنك أيضًا الاشتراك في الإصدار التجريبي من Origin لمجموعات الطرف الأول وSameParty الذي يتوفّر في Chrome من الإصدار 89 إلى الإصدار 93.

كيفية تعديل ملفات تعريف الارتباط للإصدار التجريبي من المصدر

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

الخيار الأول

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

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

قبل: set-cookie: cname=cval; SameSite=None; Secure

بعد: set-cookie: cname=cval; SameSite=None; Secure; SameParty

الخيار الثاني

يتطلّب الخيار الثاني مزيدًا من العمل، ولكنه يتيح لك فصل الإصدار التلقائي التجريبي تمامًا عن الوظائف الحالية، ويسمح على وجه التحديد باختبار تركيبة SameSite=Lax; SameParty.

قبل: set-cookie: cname=cval; SameSite=None; Secure

بعد:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

عند التحقّق من ملفّ تعريف الارتباط في الطلبات الواردة، من المفترض ألا يظهر سوى ملفّ تعريف الارتباط cname-fps في طلب على مستوى مواقع إلكترونية مختلفة إذا كانت المواقع الإلكترونية المعنيّة في المجموعة وكان المتصفّح في الفترة التجريبية الأصلية. يمكنك اعتبار هذا النهج بمثابة إطلاق متزامن لميزة معدَّلة قبل إيقاف الإصدار السابق.

لماذا قد لا تحتاج إلى مجموعة نطاقات الطرف الأول؟

بالنسبة إلى معظم المواقع الإلكترونية، يُعدّ حدود الموقع الإلكتروني مكانًا مقبولًا لرسم الحاجز أو حدود الخصوصية. هذا هو المسار الذي يتم اقتراحه باستخدام CHIPS (ملفات تعريف الارتباط التي تتضمّن حالة مجزّأة مستقلة)، ما سيمنح المواقع الإلكترونية مسارًا للموافقة من خلال سمة Partitioned للاستمرار في استخدام عمليات التضمين والموارد وواجهات برمجة التطبيقات والخدمات المهمة على جميع المواقع الإلكترونية، مع منع تسرُّب معلومات تحديد الهوية على جميع المواقع الإلكترونية.

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

  • يتم الاستضافة من مصادر مختلفة، وليس من مواقع إلكترونية مختلفة. في المثال أعلاه، إذا كان brandx.site يتضمّن fly.brandx.site وdrive.brandx.site، فإنّ هذين النطاقَين الفرعيين مختلفان ضمن الموقع الإلكتروني نفسه. يمكن أن تستخدم ملفات تعريف الارتباط SameSite=Lax ولا يلزم ضبطها.
  • إذا كنت توفّر مواقع إلكترونية أخرى تتضمّن عناصر مضمّنة تابعة لجهات خارجية في المقدّمة، يُعدّ مثال فيديو من video.site مضمّن في my-blog.site فاصلًا واضحًا لجهة خارجية. تُدير مؤسسات مختلفة المواقع الإلكترونية وينظر إليها المستخدمون ككيانَين منفصلَين. يجب ألا يكون الموقعان الإلكترونيان في مجموعة معًا.
  • إذا كنت توفّر خدمات تسجيل الدخول عبر وسائل التواصل الاجتماعي تابعة لجهات خارجية إنّ مزوّدي الهوية الذين يستخدمون أشياء مثل OAuth أو OpenId connect يميلون إلى الاعتماد على ملفات تعريف الارتباط التابعة لجهات خارجية لتوفير تجربة تسجيل دخول سلسة للمستخدمين. هذا مثال صالح للاستخدام، ولكنه ليس مناسبًا لمجموعات الطرف الأول لأنّ هناك فرقًا واضحًا في المؤسسات. إنّ الاقتراحات المبكّرة، مثل WebID، تبحث عن طرق لتفعيل حالات الاستخدام هذه.