يقدّم Chrome تجربة جديدة تتيح للمستخدم اختيار ملفّات تعريف الارتباط التابعة لجهات خارجية. عليك إعداد موقعك الإلكتروني للمستخدمين الذين يختارون التصفّح بدون ملفات تعريف الارتباط التابعة لجهات خارجية.
تحتوي هذه الصفحة على معلومات حول ما قد يتأثّر بالتغييرات القادمة.
رحلات المستخدِمين الشائعة
تعتمد العديد من عمليات الدفع والتسوّق على ملفات تعريف الارتباط التابعة لجهات خارجية. يسرد الجدول التالي بعض تجارب المستخدِمين التي قد تتأثّر في حال إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، ويقترح واجهات برمجة تطبيقات بديلة يمكن للمطوّرين استخدامها لتجنّب تعطُّل التجارب. قد لا تكون هذه القائمة شاملة، وقد يتم تعديلها عند توفّر المزيد من حلول "مساحة المحاكاة" في ما يتعلّق بالخصوصية. ننصحك بمشاركة ملاحظاتك إذا واجهت أيّ سيناريوهات إضافية متأثرة.
اختبار تجارب المستخدمين المتعلّقة بالدفعات
إنّ أفضل طريقة لاختبار ما إذا كانت مسارات المستخدِمين تتأثّر بملفّات تعريف الارتباط التابعة لجهات خارجية بسبب القيود هي مراجعتها مع تفعيل علامة اختبار ملفات تعريف الارتباط التابعة لجهات خارجية.
لضمان عمل موقعك الإلكتروني على النحو المتوقّع، اختبِر الخطوات التالية مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية:
- الدفع على مواقع إلكترونية متعددة: اختبِر عمليات الدفع التي تعتمد على
مزوّد خدمة دفع تابع لجهة خارجية (مثل الدفع من خلال <example-provider>). تأكَّد مما يلي:
- تتم إعادة التوجيه بنجاح.
- تم تحميل بوابة الدفع بشكل صحيح.
- يمكن إكمال عملية الدفع بدون حدوث أخطاء.
- تتم إعادة توجيه المستخدم إلى موقعك الإلكتروني على الويب على النحو المتوقّع.
- لوحات بيانات الدفعات: اختبِر عمل التطبيقات المصغّرة في لوحة بيانات المعاملات على النحو المتوقع مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية. تأكَّد من أنّ المستخدم يمكنه إجراء ما يلي:
- انتقِل إلى لوحة البيانات.
- تظهر جميع الدفعات على النحو المتوقّع.
- التنقّل بدون أخطاء بين الأقسام المختلفة في لوحة التحكّم (مثل سجلّ المعاملات وتفاصيل الدفع)
- إدارة طرق الدفع: اختبِر التطبيقات المصغّرة لإدارة طرق الدفع للتأكّد من أنّها تعمل على النحو المتوقّع. مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية، اختبِر ما يلي:
- تعمل إضافة طريقة دفع أو حذفها على النحو المتوقّع.
- لن تتأثر عمليات الدفع باستخدام طرق الدفع المحفوظة سابقًا.
- رصد الاحتيال: قارِن طريقة عمل حلّ رصد الاحتيال
مع ملفات تعريف الارتباط التابعة لجهات خارجية وبدونها.
- هل يؤدي حظر ملفات تعريف الارتباط التابعة لجهات خارجية إلى إضافة خطوات إضافية، مما يؤدي إلى زيادة صعوبة استخدام التطبيق؟
- هل يمكنه رصد الأنماط المريبة عندما يتم حظر ملفات تعريف الارتباط التابعة لجهات خارجية في المتصفّح؟
- زر الدفع المخصّص: اختبِر ما إذا كانت أزرار الدفع تظهر بشكلٍ
صحيح مع حظر ملفات تعريف الارتباط التابعة لجهات خارجية.
- هل سيظل بإمكان المستخدم إكمال عمليات الشراء حتى إذا لم يعرض الزر المخصّص طريقته المفضّلة؟
عمليات الدفع على مواقع إلكترونية متعددة
قد يعتمد بعض مقدّمي خدمات الدفع على ملفات تعريف الارتباط التابعة لجهات خارجية للسماح للمستخدمين بالوصول إلى حساباتهم على مواقع إلكترونية متعددة للتجّار بدون الحاجة إلى إعادة المصادقة. قد تتأثر رحلة المستخدِم هذه بالنسبة إلى مَن يختار التصفُّح بدون ملفات تعريف الارتباط التابعة لجهات خارجية.
نماذج الدفع المضمّنة
ننصحك باتّباع الخطوات التالية:
- توفّر شركة
payment-provider.example
خدمات الدفع للمواقع الإلكترونية للتجّار، وتخزّن بيانات الدفع والجلسات للمستخدمين. merchant.example
هو موقع إلكتروني يتضمّن نموذج دفع مقدَّمًا منpayment-provider.example
.
سجّل مستخدم للتو الدخول إلى payment-provider.example
(على سبيل المثال، أثناء
إكمال عملية الدفع على موقع إلكتروني آخر). يبدأ المستخدِم عملية دفع على
merchant.example
.
في حال توفّر ملفات تعريف الارتباط التابعة لجهات خارجية، سيتمكّن payment-provider.example
من الوصول إلى ملف تعريف الارتباط
للجلسة ذات المستوى الأعلى الذي تم ضبطه على payment-provider.example
في سياق المستوى الأعلى، وذلك من خلال payment-provider.example
نموذج الدفع المضمّن في merchant.example
.
ومع ذلك، في حال حظر ملفات تعريف الارتباط التابعة لجهات خارجية، لن يتمكّن المحتوى المضمّن من الوصول إلى
ملفّات تعريف الارتباط ذات المستوى الأعلى الخاصة به.

حلّ قابل للتخصيص باستخدام FedCM
على payment-provider.example
التفكير في تنفيذ
FedCM ليعمل بدور
موفّر الهوية. يمكن أن يكون هذا النهج مناسبًا في الحالات التالية:
payment-provider.example
مضمّنة في مواقع إلكترونية خارجية غير ذات صلة- تمّ تضمين
payment-provider.example
في أكثر من خمسة مواقع إلكترونية ذات صلة.
تتمثل الفائدة الرئيسية من FedCM في أنّ واجهة المستخدم يمكن أن تقدّم للمستخدمين سياقًا إضافيًا لتحديد خياراتهم. بعد الحصول على إذن المستخدم، يسمح إطار عمل FedCM بمشاركة
البيانات المخصّصة
بين الطرف المعني (merchant.example
) وموفِّر الهوية
(payment-provider.example
). يمكن للطرف المعني اختيار السماح لموفِّر هوية واحد أو أكثر
باستخدام إطار العمل، ولن يتم عرض واجهة مستخدم FedCM إلا
بشكل مشروط.
استنادًا إلى الاحتياجات، يمكن للمطوّرين الاختيار بين الوضع التلقائي لظهور طلب FedCM تلقائيًا عندما يسجّل المستخدم الدخول باستخدام موفّر هوية، أو الوضع النشط عندما يجب بدء عملية تسجيل الدخول بعد إجراء من جانب المستخدم، مثل النقر على زر الدفع.
يعمل FedCM أيضًا كأحد إشارات الثقة لواجهة برمجة التطبيقات Storage Access API (SAA)، مما يسمح للمحتوى المضمّن بالوصول إلى ملفات تعريف الارتباط غير المقسّمة ذات المستوى الأعلى بعد أن يوافق العميل على تسجيل الدخول باستخدام مقدّم المحتوى المضمّن، بدون الحاجة إلى توجيه طلب إضافي إلى العميل.
حلّ يركز على الوصول إلى مساحة التخزين
واجهة برمجة تطبيقات أخرى يجب أخذها في الاعتبار هي
Storage Access API (SAA).
باستخدام SAA، سيُطلب من المستخدم السماح payment-provider.example
بالإدراج لأجل
الوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى. إذا وافق المستخدم على الوصول، يمكن عرض النموذج كما هو الحال عندما تكون ملفات تعريف الارتباط التابعة لجهات خارجية متاحة.
تمامًا كما هو الحال مع FedCM، على المستخدم الموافقة على الطلب على كل موقع إلكتروني جديد
يتم فيه تضمين payment-provider.example
. اطّلِع على demo
لواجهة برمجة التطبيقات لفهم آلية عملها.
إذا لم تكن رسالة طلب SAA التلقائية تناسب احتياجاتك، ننصحك بتنفيذ FedCM
للحصول على تجربة أكثر تخصيصًا.
تقليل الصعوبات التي يواجهها المستخدمون على عدد صغير من المواقع الإلكترونية ذات الصلة
إذا كان كلّ من موقع التاجر الإلكتروني وموفّر خدمة الدفع ينتميان إلى الشركة نفسها،
يمكنك استخدام واجهة برمجة التطبيقات
Related Website Sets (RWS)
للإعلان عن العلاقات بين النطاقات. يمكن أن يساعد ذلك في تقليل الصعوبات التي يواجهها المستخدِم: على سبيل المثال، إذا كانinsurance.example
و
payment-portal-insurance.example
في RWS نفسه،
سيحصلpayment-portal-insurance.example
تلقائيًا على إذن بالوصول إلى ملفّات تعريف الارتباط
ذات المستوى الأعلى عند طلب الوصول إلى مساحة التخزين ضمن عملية تضمين
payment-portal-insurance.example
.
الحلول التجريبية الأخرى
هناك واجهة برمجة تطبيقات تجريبية أخرى قد تكون مفيدة في هذا السيناريو وهي النوافذ المنبثقة المقسّمة. إنّ واجهة برمجة التطبيقات قيد التطوير النشط حاليًا.
باستخدام النوافذ المنبثقة المقسّمة، يمكن أن يُطلب من المستخدم إدخال بيانات الاعتماد الخاصة به لتسجيل الدخول إلى payment-provider.example
ضمن نافذة منبثقة فتحها
merchant.example
. سيتم
تقسيم
مساحة التخزين من قِبل المستخدم الذي فتح الملف merchant.example
. في هذه الحالة، سيتمكّن payment-provider.example
embed من الوصول إلى قيم التخزين التي تم ضبطها في النافذة المنبثقة. باستخدام هذا
الحلّ، على المستخدم تسجيل الدخول إلى مقدّم خدمة الدفع على كل موقع إلكتروني.
عمليات الدفع باستخدام رابط الدفع
يقدّم بعض مقدّمي خدمات الدفع خدمة لإنشاء رابط دفع يعرض صفحة دفع مخصّصة لموقع التاجر الإلكتروني. غالبًا ما يتم تنفيذ خدمة رابط الدفع وبوابة مستخدم لموفّر الدفع على نطاقات مختلفة، مثل payment-provider.example
وpayment-link.example
.
تضمِّن payment-link.example
نموذج دفع مقدَّمًا من
payment-provider.example
. هذا نموذج مختلف عن نمط
نموذج الدفع المضمّن.
إنّ FedCM وSAA وRWS هي خيارات جيدة أيضًا في هذه الحالة.
لوحات بيانات الدفعات
تعرض بعض التطبيقات لوحات بيانات المعاملات للمستخدمين على عدة مواقع إلكترونية، ما يوفر عرضًا مركزيًا لأنشطتهم المالية. يتطلّب ذلك أن تتمكّن لوحة البيانات من الوصول إلى البيانات الخاصة بالمستخدمين على مستوى نطاقات متعددة.
ننصحك باتّباع الخطوات التالية:
- يوفّر
earnings.example
لوحة بيانات العائدات التي يمكن تضمينها في تطبيقات الويب المختلفة. تخزّن هذه الخدمة بيانات أرباح المستخدمين ومعلومات الجلسات. catsitting.example
وdogsitting.example
موقعان إلكترونيّان منفصلان يضمّن كلاهما لوحة بياناتearnings.example
.
يسجّل مستخدم الدخول إلى حسابه على earnings.example
. عند زيارة
catsitting.example
أو dogsitting.example
، يمكنهم الاطّلاع على أرباحهم. تعتمد لوحة بيانات earnings.example
المضمّنة على ملفات تعريف الارتباط ذات المستوى الأعلى وتعرض
معلومات الأرباح المخصّصة للمستخدم.
تمامًا كما هو الحال في الأمثلة الأخرى، لن يتمكّن earnings.example
من الوصول إلى
ملفات تعريف الارتباط ذات المستوى الأعلى عندما تكون ملفات تعريف الارتباط التابعة لجهات خارجية غير مفعّلة.

لوحات بيانات الطرف الأول
في الحالات التي ينتمي فيها جميع النطاقات الثلاثة إلى الجهة نفسها، ننصحك باستخدام
SAA
مع
RWS.
باستخدام SAA، يمكن لشركة earnings.example
الوصول إلى ملف تعريف الارتباط من المستوى الأعلى بإذن
المستخدِم. إذا كان هذا الطرف يستخدم earnings.example
على أربعة نطاقات أو أقل،
يمكن أن يؤدي الإفصاح عن العلاقات بينها باستخدام RWS إلى توفير تجربة
سلسة للمستخدم.
إذا أدرج الطرف نفسه التطبيق المصغّر على أكثر من خمسة نطاقات، لا يمكنه الإفصاح عن العلاقات بين جميع المواقع الإلكترونية التي تضمّنت التطبيق المصغّر ونطاق التطبيق المصغّر، لأنّ ميزة RWS لا تتيح سوى ستة مواقع إلكترونية كحدّ أقصى في مجموعة، أي موقع إلكتروني أساسي وخمسة مواقع إلكترونية مرتبطة.
توزيع لوحات البيانات على نطاق واسع
في الحالات التالية، SAA و RWS قد لا يكونا الحلّ الأمثل:
- إذا كنت توزّع حلّاً للوحة بيانات للمواقع الإلكترونية التابعة لجهات خارجية
- إذا كان لديك أكثر من خمسة مواقع إلكترونية تضمّ تطبيقك المصغّر في لوحة البيانات
في هذه الحالة، على earnings.example
التفكير في تنفيذ
FedCM ليعمل بدور
موفّر الهوية. وهذا يعني أنّ المستخدم سيحتاج إلى تسجيل الدخول إلى
dogsitting.example
باستخدام حساب مُدار من قِبل earnings.example
.
يوفّر FedCM واجهة مستخدم قابلة للتخصيص يمكن أن تساعد في إبلاغ المستخدم بوضوح
بالمعلومات التي تتم مشاركتها. باستخدام FedCM، يمكن لتطبيق dogsitting.example
طلب
earnings.example
مشاركة
أذونات مخصّصة،
مثلاً، للوصول إلى بيانات المعاملات.
تُعدّ FedCM أيضًا
إشارة ثقة لواجهة برمجة التطبيقات Storage Access API،
وسيتم منح عملية تضمين earnings.example
إذن الوصول إلى مساحة التخزين الخاصة
بملفات تعريف الارتباط ذات المستوى الأعلى بدون طلب إضافي من المستخدم بشأن طلب البيانات من واجهة برمجة التطبيقات SAA.
إعدادات لوحة البيانات الخاصة بالموقع الإلكتروني
إذا لم تكن البيانات بحاجة إلى المشاركة على مواقع إلكترونية متعددة، ننصحك بمحاولة تقسيم ملفات تعريف الارتباط باستخدام CHIPS. يمكن أن تكون تنسيقات CHIPS مفيدة لتخزين الإعدادات المفضّلة الخاصة بالموقع، مثل تنسيق لوحة البيانات أو عوامل الفلترة.
إدارة طرق الدفع
من الإجراءات الشائعة الأخرى أن يعرض المستخدم طرق الدفع ويُعدّلها داخل عنصر مضمّن بدون مغادرة الموقع الإلكتروني المضيف.
اتّبِع الخطوات التالية:
- توفّر
payments.example
أداة لإدارة الدفع يمكن دمجها في المواقع الإلكترونية. تخزّن هذه الخدمة بيانات دفعات المستخدم ومعلومات الجلسات. shop.example
هو موقع إلكتروني يضمّ أداةpayments.example
لسماح المستخدمين بالاطّلاع على طرق الدفع المفضّلة المرتبطة بحسابهم علىshop.example
أو تعديلها أو اختيارها.
على مقدّمي خدمات الدفع الذين ينفذون ميزة "إدارة طرق الدفع" أن يخطّطوا أيضًا
ليصبحوا مقدّمي هوية باستخدام
FedCM. باستخدام
FedCM، سيتمكّن المستخدم من تسجيل الدخول إلى "الطرف الموثوق به" (shop.example
)
باستخدام الحساب الذي يديره "موفِّر الهوية" (payments.example
).
يسمح إطار عمل FedCM بمشاركة البيانات المخصّصة بين الطرف المستفيد ومزوّد الهوية، وذلك بعد الحصول على إذن المستخدم. تتمثل الفائدة الرئيسية لاستخدام FedCM في أنّ واجهة المستخدم يمكنها أن تقدّم للمستخدمين مزيدًا من السياق لاختياراتهم. ويعمل أيضًا كأحد إشارات الثقة لواجهة برمجة التطبيقات Storage Access API، مما يسمح للمحتوى المضمّن بالوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى.
في حال إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، لن تتمكّن عملية تضمين payments.example
من الوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى. في هذه الحالة، يمكن أن تساعد SAA في ضمان التشغيل السليم من خلال طلب الوصول إلى مساحة التخزين.
في بعض الأحيان، لا تحتاج المعلومات التي تم ضبطها في عملية التضمين إلى المشاركة على
المواقع الإلكترونية الأخرى التي تستخدم ميزة التضمين. قد يحتاج payments.example
إلى تخزين إعدادات الإعدادات المفضّلة المختلفة للمستخدمين لكل موقع إلكتروني محدّد يتم تضمين المحتوى فيه. في هذه الحالة، ننصحك بمحاولة
تقسيم ملفات تعريف الارتباط باستخدام
CHIPS. باستخدام ميزة
CHIPS، لن تتمكّن payments.example
المضمّنة في shop.example
من الوصول إلى ملف تعريف الارتباط الذي تم ضبطه في payments.example
المضمّنة في another-shop.example
.
من واجهة برمجة التطبيقات التجريبية الأخرى التي يمكن استخدامها في مسار المستخدِم هذا هو
النوافذ المنبثقة المقسّمة.
عندما يسجّل المستخدم الدخول إلى payments.example
ضمن نافذة منبثقة فتحها
shop.example
، سيتم تقسيم مساحة التخزين بواسطة المستخدم الذي فتح النافذة، وسيتمكن رمز التضمين
payments.example
من الوصول إلى قيم مساحة التخزين التي تم ضبطها ضمن
النافذة المنبثقة. ومع ذلك، تتطلّب هذه الطريقة من المستخدمين إدخال بيانات الاعتماد لتسجيل الدخول إلى
مقدّم خدمة الدفع على كل موقع إلكتروني.
رصد الاحتيال
يمكن لأنظمة تحليل المخاطر تحليل البيانات المخزّنة في ملفات تعريف الارتباط لتحديد النماذج التي تختلف عن المعتاد. على سبيل المثال، إذا غيّر مستخدم فجأة عنوان الشحن، وأجرى عدة عمليات شراء كبيرة باستخدام جهاز جديد، قد تزيد نتيجة الاحتيال المحتمَل. تكون ملفات تعريف الارتباط لرصد الاحتيال عادةً ملفات تعريف ارتباط تابعة لجهات خارجية، يتم ضبطها على مواقع التجّار الإلكترونية من قِبل مقدّمي خدمات الدفع أو التطبيقات المصغّرة لخدمات منع الاحتيال.
على الرغم من أنّ قيود ملفات تعريف الارتباط التابعة لجهات خارجية لن تؤدي إلى إيقاف أنظمة رصد الاحتيال، قد تتسبب في حدوث مشاكل إضافية للمستخدمين. إذا لم يتمكّن النظام من التحقق بشكلٍ واثق من أنّ المستخدم شرعي بسبب ملفات تعريف الارتباط المحظورة، قد يتطلّب ذلك إجراء عمليات فحص إضافية، مثل إكمال عملية إثبات الهوية.
لدعم ميزة رصد عمليات الاحتيال عند حظر ملفات تعريف الارتباط التابعة لجهات خارجية، ننصحك بدمج واجهة برمجة التطبيقات Private State Tokens (PST) API في حلّ رصد عمليات الاحتيال. باستخدام PST، يمكن لمقدّم خدمة الدفع التسجيل بصفته مُصدِر رموز مميّزة ومنح المستخدمين رموزًا مميّزة لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية. ويمكن بعد ذلك تحصيل قيمة هذه الرموز المميَّزة على مواقع التجّار الإلكترونية للتحقّق مما إذا كان المستخدم موثوقًا به. اطّلِع على مستندات مطوّري برامج PST لمعرفة تفاصيل التنفيذ.
تختبِر "مبادرة حماية الخصوصية" واجهات برمجة تطبيقات أخرى لمكافحة الاحتيال.
زر دفع مخصّص
إنّ أزرار الدفع (مثل الدفع باستخدام <طريقة الدفع المفضّلة>) المضمّنة في مواقع التجار الإلكترونية تعتمد غالبًا على معلومات على مستوى الموقع الإلكتروني يضبطها مقدّم خدمة الدفع. يتيح ذلك التخصيص، ويمكن للمستخدمين الاستفادة من عملية دفع سلسة باستخدام طريقة الدفع المفضّلة لديهم. في حال حظر ملفات تعريف الارتباط التابعة لجهات خارجية في متصفح العميل، قد يؤثّر ذلك في عرض زر الدفع المخصّص.
على الرغم من أنّ SAA يمكن أن يسمح بالوصول إلى مساحة التخزين، قد لا تؤدي المطالبة المطلوبة إلى تحسين تجربته.
نحن نستكشف حلًا محتمَلاً يستهدف حالة الاستخدام هذه على وجه التحديد: استخدام إطارات محصورة مع إمكانية الوصول إلى البيانات المحلية غير المقسّمة. واجهة برمجة التطبيقات في مرحلة تطوير نشطة حاليًا، ويمكنك تحديد مستقبلها. جرِّب هذه الميزة بنفسك وقدِّم ملاحظاتك.
الحصول على مساعدة
يُرجى الإبلاغ عن أي مشاكل في الرابط على الرابط التالي: goo.gle/report-3pc-broken. يمكنك أيضًا إرسال نموذج ملاحظات أو الإبلاغ عن مشكلة على GitHub في مستودع دعم المطوّرين في مبادرة "حماية الخصوصية".