تمتلك العديد من المؤسسات مواقع ذات صلة بأسماء نطاقات مختلفة، مثل
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 هو تابع لجهة خارجية.
يتم تحديد تضمين ملفات تعريف الارتباط من خلال سمة SameSite لملف تعريف الارتباط:
- الموقع نفسه
سياق مع
يجعل
SameSite=LaxأوStrictأوNoneملف تعريف الارتباط الطرف الأول. - يؤدي استخدام سياق مواقع إلكترونية متعددة باستخدام
SameSite=Noneإلى إنشاء ملفات تعريف الارتباط تابعة لجهة خارجية.
ومع ذلك، هذا ليس دائمًا واضحًا جدًا. تخيل أن 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 أنّ الطرف الأول يمكن أن يكون أكبر
من موقع واحد فقط.
يتمثل جزء مهم من اقتراح مجموعات نطاقات الطرف الأول في ضمان أن تكون السياسة عبر المتصفحات دون إساءة الاستخدام. على سبيل المثال، يجب ألا يُسمح لمجموعات نطاقات الطرف الأول تتيح تبادل معلومات المستخدم عبر المواقع غير ذات الصلة، أو تجميع من المواقع التي لا تمتلكها الجهة نفسها. تكمن الفكرة في التأكد من أن ترتبط مجموعة نطاقات الطرف الأول بشيء يفهمه المستخدم على أنه طرف أول ولا تُستخدم كطريقة لمشاركة الهوية بين الأطراف المختلفة.
ويمكن أن يسجّل الموقع الإلكتروني مجموعة الطرف الأول إرسال مجموعة النطاقات المقترَحة إلى أداة تتبُّع عامة (مثل مستودع جيت هب المخصص) إلى جانب المعلومات اللازمة لتلبية احتياجات .
بعد التحقّق من تأكيد مجموعة الطرف الأول وفقًا للسياسة، يمكن للمتصفّحات ثم استرجاع قوائم المجموعات من خلال عملية التحديث.
هناك سياسة محددة لمرحلة التجربة والتقييم ليست نهائية، ولكن المبادئ من المحتمل أن تظل كما هي:
- يجب أن تكون النطاقات في مجموعة الطرف الأول مملوكة وتحت إدارة الشركة نفسها التنظيم.
- يجب أن يتمكّن المستخدمون من التعرّف على النطاقات كمجموعة.
- يجب أن تتشارك النطاقات سياسة خصوصية مشتركة.
كيفية تعريف مجموعة الطرف الأول
بعد تحديد أعضاء الطرف الأول لمؤسستك ومالكه الخطوة الحاسمة هي تقديم مجموعتك المقترحة للموافقة عليها. المطابقة التامة العملية لا تزال قيد المناقشة.
للإعلان عن مجموعة الطرف الأول، هي موارد 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، ولن يتم تضمين ملف تعريف الارتباط.
حتى تصبح السمة 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
كيف يمكنك المشاركة؟
إذا كانت لديك مجموعة من المواقع التي تتوافق مع المعايير المذكورة أعلاه، فهناك عدد الخيارات للمشاركة. والاستثمار الأبسط هو القراءة والانضمام المناقشة حول الاقتراحين:
- مناقشة مجموعة خاصة بمنتدى الخصوصية على منصة First-Party Sets
- مناقشة سمة ملفات تعريف الارتباط في SameParty
أثناء مرحلة الاختبار، يمكنك تجربة الوظائف باستخدام
علامة سطر أوامر --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 في بيئة مباشرة للاطّلاع على كيفية
تأثير مجموعة الطرف الأول في ملفات تعريف الارتباط.
إذا كان لديك النطاق الترددي لإجراء التجربة وإرسال الملاحظات، يمكنك أيضًا الاشتراك للفترة التجريبية لمجموعات الطرف الأول 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 في الغالب على ملفات تعريف الارتباط التابعة لجهات خارجية تسجيل دخول أكثر سلاسة للمستخدمين. إنها حالة استخدام صالحة، ولكنها لا مناسبة لمجموعات نطاقات الطرف الأول نظرًا لوجود اختلاف واضح بين المؤسسات. الاقتراحات المبكرة مثل WebID هي واستكشاف طرق لإتاحة حالات الاستخدام هذه.