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

يقدّم 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. ومع ذلك، في حال حظر ملفات تعريف الارتباط التابعة لجهات خارجية، لن يتمكّن المحتوى المضمّن من الوصول إلى ملفّات تعريف الارتباط ذات المستوى الأعلى الخاصة به.

يعرض المخطّط البياني تفاعلًا مع موقع إلكتروني للتاجر (merchant.example) يستخدم تطبيقًا مصغّرًا للدفع من مقدّم خدمة تابع لجهة خارجية (payment-provider.example). عند حظر ملفات تعريف الارتباط التابعة لجهات خارجية، لا يمكن للتطبيق المصغّر الوصول إلى ملف تعريف الارتباط من المستوى الأعلى، ما قد يؤدي إلى تعطيل تجربة المستخدم.
عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، لن تتمكّن الأداة المصغّرة payment-provider.example من الوصول إلى ملف تعريف ارتباط جلسة المستخدم الذي تم ضبطه في سياق المستوى الأعلى على payment-provider.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 للحصول على تجربة أكثر تخصيصًا.

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 من الوصول إلى ملفات تعريف الارتباط ذات المستوى الأعلى عندما تكون ملفات تعريف الارتباط التابعة لجهات خارجية غير مفعّلة.

مخطّط بياني يوضّح سيناريو يتم فيه عرض معلومات أرباح المستخدم، المستضافة على earnings.example،
      في لوحة بيانات مضمّنة على dogsitting.example  عند حظر ملفات تعريف الارتباط التابعة لجهات خارجية،
      لا يمكن للوحة البيانات المضمّنة الوصول إلى ملف تعريف الارتباط من المستوى الأعلى، ما يمنع عرض بيانات الأرباح المخصّصة للمستخدم.
عند إيقاف ملفات تعريف الارتباط التابعة لجهات خارجية، لن تتمكّن الأداة "earnings.example" المضمّنة في "dogsitting.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 في مستودع دعم المطوّرين في مبادرة "حماية الخصوصية".