سياسة المُحيل التلقائية الجديدة في Chrome - scratch-origin-when-cross-origin

مود نالباس
مود نالباس

معلومات مهمة قبل البدء:

  • إذا كنت غير متأكد من الفرق بين "site" و"origin" (أصلي)، اطّلِع على مقالة فهم "نفس الموقع الإلكتروني" و"المصدر نفسه".
  • لا يحتوي عنوان Referer على حرف R بسبب خطأ إملائي أصلي في المواصفات. تتم كتابة العنوان Referrer-Policy وreferrer في JavaScript وDOM بشكل صحيح.

ملخّص

  • تتطوّر المتصفّحات نحو سياسات المُحيل التلقائية لتعزيز الخصوصية بهدف توفير عنصر احتياطي جيد في حال عدم تحديد سياسة للموقع الإلكتروني.
  • يخطّط Chrome لتفعيل "strict-origin-when-cross-origin" كسياسة تلقائية تدريجيًا في الإصدار 85، ما قد يؤثّر في حالات الاستخدام التي تعتمد على قيمة المُحيل من مصدر آخر.
  • وهذا هو الخيار التلقائي الجديد، ولكن سيظلّ بإمكان المواقع الإلكترونية اختيار سياسة من اختيارها.
  • لتجربة التغيير في Chrome، يُرجى تفعيل العلامة على chrome://flags/#reduced-referrer-granularity. يمكنك أيضًا الاطّلاع على هذا العرض التوضيحي للاطّلاع على التغيير عملي.
  • بخلاف سياسة المُحيل، قد تتغير طريقة تعامل المتصفحات مع المُحيلين، لذا راقبها.

ما الذي سيتغير ولماذا؟

قد تتضمّن طلبات HTTP عنوان Referer الاختياري، ما يشير إلى عنوان URL المصدر أو صفحة الويب الذي تم تقديم الطلب منه. يحدّد العنوان Referer-Policy البيانات التي يتم إتاحتها في عنوان Referer، ومعلومات التنقّل وإطارات iframe في "document.referrer" للوجهة.

ويتم تحديد المعلومات التي يتم إرسالها في عنوان Referer في أي طلب من موقعك الإلكتروني تحديدًا من خلال عنوان Referrer-Policy الذي تم ضبطه.

الرسم البياني: أرسل المُحيل طلبًا.
سياسة المُحيل والمحيل

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

بالنسبة إلى عمليات التنقّل وإطارات iframe، يمكن أيضًا الوصول إلى البيانات المتوفّرة في عنوان Referer من خلال JavaScript باستخدام document.referrer.

حتى وقت قريب، كانت no-referrer-when-downgrade سياسة تلقائية واسعة الانتشار في جميع المتصفحات. ومع ذلك، فإنّ العديد من المتصفّحات الآن في مرحلة ما من الانتقال إلى الإعدادات التلقائية لتعزيز الخصوصية.

يخطّط Chrome لتغيير سياسته التلقائية من no-referrer-when-downgrade إلى strict-origin-when-cross-origin، بدءًا من الإصدار 85.

ويعني ذلك أنّه إذا لم يتم ضبط أي سياسة لموقعك الإلكتروني، سيستخدم Chrome strict-origin-when-cross-origin تلقائيًا. تجدر الإشارة إلى أنه لا يزال بإمكانك ضبط سياسة من اختيارك، لن يؤثر هذا التغيير إلا في المواقع الإلكترونية التي لم يتم تحديد سياسة لها.

ما معنى هذا التغيير؟

يوفر strict-origin-when-cross-origin مزيدًا من الخصوصية. وفقًا لهذه السياسة، يتم إرسال المصدر فقط في العنوان Referer للطلبات من مصادر متعددة.

ويمنع ذلك تسرُّب البيانات الخاصة التي يمكن الوصول إليها من أجزاء أخرى من عنوان URL الكامل، مثل المسار وسلسلة طلب البحث.

رسم بياني: يتم إرسال المُحيل
      بناءً على السياسة، لطلب من مصادر متعددة.
تم إرسال المُحيل (وdocument.referrer) لطلب من مصادر متعددة، استنادًا إلى السياسة.

مثال:

طلب مشترك المصدر، يتم إرساله من https://site-one.example/stuff/detail?tag=red إلى https://site-two.example/...:

  • مع no-referrer-when-downgrade: المُحيل: https://site-one.example/stuff/detail?tag=red.
  • باستخدام strict-origin-when-cross-origin: المُحيل: https://site-one.example/.

ما الميزات التي لم تتغير؟

  • مثلما هو الحال مع no-referrer-when-downgrade، السمة strict-origin-when-cross-origin آمنة: لا يتوفّر مُحيل (العنوان Referer وdocument.referrer) عند إجراء الطلب من مصدر HTTPS (آمن) إلى مصدر HTTP (غير آمن). بهذه الطريقة، إذا كان موقعك الإلكتروني يستخدم بروتوكول HTTPS (وإذا لم يكن يستخدم بروتوكول HTTPS، يُرجى منحه أولوية)، لن يتم تسريب عناوين URL الخاصة بموقعك الإلكتروني في طلبات لا تستخدم بروتوكول HTTPS، لأنّه يمكن لأي مستخدم على الشبكة الاطّلاع على تلك العناوين، ما قد يعرّض المستخدمين لهجمات الوسيط.
  • وضمن المصدر نفسه، تكون قيمة العنوان Referer هي عنوان URL الكامل.

على سبيل المثال: طلب المصدر نفسه، المُرسل من https://site-one.example/stuff/detail?tag=red إلى https://site-one.example/...:

  • مع strict-origin-when-cross-origin: المُحيل: https://site-one.example/stuff/detail?tag=red

ما التأثير؟

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

من المحتمل أن يتأثر تسجيل جهة الخادم أو التحليلات التي تعتمد على عنوان URL المُحيل الكامل المتاح بانخفاض الدقة في هذه المعلومات.

الإجراءات المطلوبة منك

يخطط Chrome لبدء طرح سياسة المُحيل التلقائية الجديدة في 85 (تموز (يوليو) 2020 بالنسبة إلى الإصدار التجريبي، وآب (أغسطس) 2020 بالنسبة إلى الإصدارات الثابتة). اطّلِع على الحالة في إدخال حالة Chrome.

فهم التغيير واكتشافه

يمكنك الاطّلاع على هذا العرض التوضيحي لمعرفة التغييرات التلقائية الجديدة.

ويمكنك أيضًا استخدام هذا العرض التوضيحي لرصد السياسة التي يتم تطبيقها في النسخة الافتراضية من Chrome التي يتم تشغيلها.

اختبِر التغيير، وحدِّد ما إذا كان سيؤثر في موقعك الإلكتروني أم لا.

يمكنك تجربة التغيير بدءًا من الإصدار 81 من Chrome: انتقِل إلى chrome://flags/#reduced-referrer-granularity في متصفِّح Chrome وفعِّل العلامة. عند تفعيل هذه العلامة، ستستخدم جميع المواقع الإلكترونية التي ليس لديها سياسة سياسة strict-origin-when-cross-origin التلقائية الجديدة.

لقطة شاشة لمتصفِّح Chrome: كيفية تفعيل العلامة chrome://flags/#reduced-referrer-granularity.
تفعيل العلامة

يمكنك الآن التحقق من سلوك موقعك الإلكتروني والخلفية.

عليك معرفة ما إذا كانت قاعدة رموز موقعك الإلكتروني تستخدم المُحيل، إما من خلال عنوان Referer للطلبات الواردة على الخادم أو من document.referrer في JavaScript.

قد تتوقّف بعض الميزات على موقعك الإلكتروني أو تتصرف بشكل مختلف إذا كنت تستخدم مُحيل الطلبات من مصدر آخر إلى موقعك الإلكتروني (على وجه التحديد المسار و/أو سلسلة طلب البحث)، ويستخدم هذا المصدر سياسة المُحيل التلقائية للمتصفّح (أي أنّه لم يتم ضبط أي سياسة له).

إذا كان ذلك يؤثر في موقعك الإلكتروني، ننصحك بالاستعانة ببدائل

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

  • استخدِم أساليب وعناوين بديلة، مثل Origin وSec-fetch-Site، لحماية CSRF وتسجيله وحالات الاستخدام الأخرى. اطّلِع على سياسة المُحيل والمحيل: أفضل الممارسات.
  • ويمكنك التواصل مع الشركاء بشأن سياسة محدّدة إذا كان ذلك مطلوبًا وشفافًا للمستخدمين. قد يكون التحكّم في الوصول هو الحال عندما تستخدم المواقع الإلكترونية المُحيل لمنح إذن وصول محدَّد إلى مواردها إلى مصادر أخرى، ومع تغيير Chrome، ستتم مشاركة المصدر في عنوان Referer (وفي document.referrer).

لاحظ أن معظم المتصفحات تتحرك في اتجاه مماثل عندما يتعلق الأمر بالمُحيل (راجع الإعدادات الافتراضية للمتصفح وتطوراتها في Referer and Referrer-Policy: أفضل الممارسات.

تنفيذ سياسة صريحة لتعزيز الخصوصية على موقعك الإلكتروني

ما هو Referer الذي يجب إرساله في الطلبات التي أنشأها موقعك الإلكتروني، أي ما السياسة التي يجب أن تحدّدها لموقعك الإلكتروني؟

على الرغم من التغيير الذي حدث في Chrome، ننصحك بوضع سياسة صريحة لتحسين الخصوصية مثل سياسة strict-origin-when-cross-origin أو سياسة أكثر صرامة في الوقت الحالي.

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

راجع سياسة المُحيل والمحيل: أفضل الممارسات للحصول على تفاصيل حول تحديد سياسة.

لمحة عن Chrome Enterprise

تتوفّر سياسة Chrome Enterprise ForceLegacyDefaultReferrerPolicy لمشرفي تكنولوجيا المعلومات الذين يريدون فرض سياسة المُحيل التلقائية السابقة التي تبلغ no-referrer-when-downgrade في بيئات المؤسسات. يتيح هذا للمؤسسات وقتًا إضافيًا لاختبار تطبيقاتها وتحديثها.

ستتم إزالة هذه السياسة في الإصدار Chrome 88.

إرسال ملاحظات

هل لديك أي ملاحظات تريد مشاركتها أو تريد الإبلاغ عنها؟ يمكنك مشاركة ملاحظاتك وآرائك حول هدف Chrome في شحن أو تغريدة عن أسئلتك على البريد الإلكتروني @maudnals.

نشكر جميع المراجعين على المساهمات والملاحظات التي نتلقّاها من المراجعين، لا سيّما "كوستوبا غوفيند" و"ديفيد فان كليف" و"مايك ويست" و"سام دوتون" و"روان ميروود" و"جيكسي باسك" و"كايس باسك".

المراجِع