توضّح هذه الصفحة بعض أفضل الممارسات لإعداد سياسة المُحيل واستخدام المُحيل في الطلبات الواردة.
ملخّص
- يؤدي تسرُّب المعلومات غير المتوقَّع من مصادر متعددة إلى إلحاق الضرر بخصوصية مستخدمي الويب. ويمكن أن تساعدك سياسة المُحيل الوقائية.
- ننصحك بضبط سياسة المُحيل
strict-origin-when-cross-origin
. تحافظ هذه الطريقة على معظم فائدة المُحيل، مع الحدّ من خطر تسرُّب البيانات من مصادر متعددة. - لا تستخدِم المُحيلين للحماية من تزوير طلبات جميع المواقع الإلكترونية (CSRF). استخدِم رموز CSRF المميزة بدلاً من ذلك، والعناوين الأخرى كطبقة أمان إضافية.
سياسة المُحيل والمحيل 101
يمكن أن تتضمّن طلبات HTTP عنوان Referer
اختياري، ما يشير إلى عنوان URL المصدر أو صفحة الويب الذي تم تقديم الطلب منه. يحدّد عنوان Referrer-Policy
البيانات المتاحة في عنوان Referer
.
في المثال التالي، يشتمل عنوان Referer
على عنوان URL الكامل للصفحة على site-one
التي تم تقديم الطلب منها.
قد يتوفّر عنوان Referer
في أنواع مختلفة من الطلبات:
- طلبات التنقّل، عندما ينقر أحد المستخدمين على رابط.
- طلبات الموارد الفرعية، عندما يطلب المتصفح الصور وإطارات iframe والنصوص البرمجية والموارد الأخرى التي تحتاجها الصفحة.
بالنسبة إلى عمليات التنقّل وإطارات iframe، يمكنك أيضًا الوصول إلى هذه البيانات من خلال JavaScript باستخدام
document.referrer
.
يمكنك تعلم الكثير من قيم Referer
. على سبيل المثال، قد تستخدمها خدمة إحصاءات لتحديد أنّ% 50 من زوّار site-two.example
جاءوا من social-network.example
. أمّا إذا تم إرسال عنوان URL الكامل، بما في ذلك المسار وسلسلة طلب البحث في Referer
على مستوى المصادر، قد يؤدي ذلك إلى تعريض خصوصية المستخدم للخطر وإنشاء مخاطر أمنية:
تحتوي عناوين URL من رقم 1 إلى رقم 5 على معلومات خاصة، وقد تحتوي أحيانًا على معلومات حساسة أو تحدد الهوية. قد يؤدي تسرُّب هذه البيانات بشكل صامت عبر المصادر إلى تعريض خصوصية مستخدمي الويب للخطر.
عنوان URL رقم 6 هو عنوان URL للإمكانات. إذا تلقّى أي شخص غير المستخدم المقصود هذه الرسالة، يمكن لجهة ضارة التحكم في حساب هذا المستخدم.
لتحديد بيانات المُحيل التي تتم إتاحتها للطلبات من موقعك الإلكتروني، يمكنك ضبط سياسة المُحيل.
ما هي السياسات المتوفرة وما أوجه اختلافها؟
يمكنك اختيار واحدة من ثماني سياسات. استنادًا إلى السياسة، يمكن أن تكون البيانات
المتاحة من عنوان Referer
(وdocument.referrer
) على النحو التالي:
- ما مِن بيانات (لا يتوفّر عنوان
Referer
) - المصدر فقط
- عنوان URL الكامل: المصدر والمسار وسلسلة طلب البحث
بعض السياسات مصمَّمة لتعمل بشكل مختلف استنادًا إلى السياق: الطلب من مصادر متعددة أو طلب من مصدر واحد، سواء كانت وجهة الطلب آمنة مثل المصدر، أو كليهما. ويفيد ذلك في الحدّ من مقدار المعلومات التي تتم مشاركتها بين المصادر أو في المصادر الأقل أمانًا، مع الحفاظ على ثراء المُحيل ضمن موقعك الإلكتروني.
يعرض الجدول التالي كيفية تقييد سياسات المُحيل لبيانات عناوين URL المتاحة من عنوان المُحيل وdocument.referrer
:
نطاق السياسة | اسم السياسة | المُحيل: لا توجد بيانات | المُحيل: المصدر فقط | المُحيل: عنوان URL الكامل |
---|---|---|---|---|
لا يأخذ في الاعتبار سياق الطلب | no-referrer |
علامة اختيار | ||
origin |
علامة اختيار | |||
unsafe-url |
علامة اختيار | |||
يركز على الأمان | strict-origin |
الطلب من HTTPS إلى HTTP | الطلب من HTTPS إلى HTTPS أو HTTP إلى HTTP |
|
no-referrer-when-downgrade |
الطلب من HTTPS إلى HTTP | الطلب من HTTPS إلى HTTPS أو HTTP إلى HTTP |
||
تركّز على الخصوصية | origin-when-cross-origin |
طلب مشترك المصدر | طلب من المصدر نفسه | |
same-origin |
طلب مشترك المصدر | طلب من المصدر نفسه | ||
التركيز على الخصوصية والأمان | strict-origin-when-cross-origin |
الطلب من HTTPS إلى HTTP | طلب متعدد المصادر من HTTPS إلى HTTPS أو من HTTP إلى HTTP |
طلب من المصدر نفسه |
توفر خدمة MDN قائمة كاملة من السياسات وأمثلة السلوك.
في ما يلي بعض الأمور التي يجب مراعاتها عند ضبط سياسة المُحيل:
- وتراعي جميع السياسات التي تأخذ المخطَّط (HTTPS في مقابل HTTP)
(
strict-origin
وno-referrer-when-downgrade
وstrict-origin-when-cross-origin
) الطلبات من مصدر HTTP إلى مصدر HTTP آخر بالطريقة نفسها التي تتعامل بها الطلبات من مصدر HTTPS إلى مصدر HTTPS آخر، على الرغم من أنّ بروتوكول HTTP يكون أقل أمانًا. ويرجع ذلك إلى أنّ ما يهمّ بالنسبة إلى هذه السياسات هو ما إذا كان الرجوع إلى إصدار سابق من الأمان قد يكشف عن بيانات من مصدر مشفر إلى مصدر غير مشفّر، كما هو الحال في طلبات HTTPS → HTTP. يكون طلب HTTP ← HTTP غير مشفّر تمامًا، وبالتالي لا توجد إمكانية الرجوع إلى إصدار سابق. - إذا كان الطلب من المصدر نفسه، يعني ذلك أنّ المخطط (HTTPS أو HTTP) هو نفسه، وبالتالي لا يتم خفض مستوى الأمان.
سياسات المُحيل التلقائية في المتصفحات
اعتبارًا من تشرين الأول (أكتوبر) 2021
إذا لم يتم ضبط سياسة مُحيل، يستخدم المتصفِّح سياسته التلقائية.
المتصفح | Referrer-Policy / السلوك التلقائي |
---|---|
Chrome |
والقيمة التلقائية هي strict-origin-when-cross-origin .
|
Firefox |
والقيمة التلقائية هي strict-origin-when-cross-origin .بدءًا من الإصدار 93، بالنسبة إلى مستخدمي ميزة "الحماية الصارمة من التتبُّع" و"التصفّح بخصوصية تامّة"، يتم تجاهل سياسات المُحيل الأقل تقييدًا no-referrer-when-downgrade
وorigin-when-cross-origin وunsafe-url
لطلبات البحث من مواقع إلكترونية متعددة،
ما يعني أنّه يتم دائمًا قطع المُحيل
عند الطلب من مواقع إلكترونية متعددة، بغض النظر عن سياسة الموقع الإلكتروني.
|
Edge |
والقيمة التلقائية هي strict-origin-when-cross-origin .
|
Safari |
ويشبه هذا الإعداد التلقائي السمة strict-origin-when-cross-origin ،
مع بعض الاختلافات المحددة. يُرجى الاطّلاع على مقالة
منع التتبُّع لمنع التتبُّع لمزيد من التفاصيل.
|
أفضل الممارسات لضبط سياسة المُحيل
هناك طرق مختلفة لضبط سياسات المُحيل لموقعك الإلكتروني:
- على شكل عنوان HTTP
- ضمن HTML
- من JavaScript على أساس كل طلب
يمكنك ضبط سياسات مختلفة لصفحات أو طلبات أو عناصر مختلفة.
يتم عرض كل من عنوان HTTP والعنصر الوصفية على مستوى الصفحة. ترتيب الأولوية لتحديد السياسة الفعالة لأحد العناصر هو ما يلي:
- سياسة على مستوى العنصر
- سياسة على مستوى الصفحة
- الإعداد التلقائي للمتصفّح
مثال:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
تم طلب الصورة باستخدام سياسة no-referrer-when-downgrade
، وتتّبع جميع
طلبات الموارد الفرعية الأخرى من هذه الصفحة سياسة strict-origin-when-cross-origin
.
كيف يمكن الاطّلاع على سياسة المُحيل؟
يكون securityheaders.com مفيدًا لتحديد السياسة التي يستخدمها موقع إلكتروني أو صفحة معيّنة.
يمكنك أيضًا استخدام أدوات المطوّرين في Chrome أو Edge أو Firefox للاطّلاع على سياسة المُحيل المستخدَمة لطلب محدَّد. في وقت كتابة هذا التقرير، لا يعرض متصفّح Safari
العنوان Referrer-Policy
، لكنّه يعرض محتوى Referer
الذي تم إرساله.
ما السياسة التي يجب أن تحددها لموقعك الإلكتروني؟
ننصحك بشدة بتحديد سياسة لتحسين الخصوصية، مثل strict-origin-when-cross-origin
(أو أكثر صرامة).
لمَ يتم الحديث "بصراحة"؟
في حال عدم ضبط سياسة مُحيل، سيتم استخدام السياسة التلقائية للمتصفّح، وفي كثير من الأحيان تؤجّل المواقع الإلكترونية إلى الإعدادات التلقائية للمتصفّح. وهذا ليس مثاليًا للأسباب التالية:
- تختلف السياسات التلقائية الخاصة بالمتصفّحات المختلفة، لذا إذا اعتمدت على الإعدادات التلقائية للمتصفّح، لن يعمل موقعك الإلكتروني على نحو متوقَّع على مستوى المتصفحات.
- تستخدم المتصفّحات إعدادات تلقائية أكثر صرامة، مثل
strict-origin-when-cross-origin
، وآليات مثل اقتطاع المُحيل للطلبات من مصادر متعددة. يمنحك تفعيل سياسة تحسين الخصوصية بشكل صريح قبل تغيير الإعدادات التلقائية للمتصفّح إمكانية التحكّم ويساعدك في إجراء الاختبارات على النحو الذي تراه مناسبًا.
ما سبب استخدام strict-origin-when-cross-origin
(أو أكثر صرامة)؟
أنت بحاجة إلى سياسة آمنة وتحسّن الخصوصية ومفيدة. يعتمد ما تعنيه كلمة "مفيد" على ما تريده من المُحيل:
- آمن: إذا كان موقعك الإلكتروني يستخدم بروتوكول HTTPS (وإذا لم يكن مفعلاً، اجعله
أولوية)، يعني ذلك أنّك لا تريد تسرّب عناوين URL الخاصة بموقعك الإلكتروني في طلبات ليست تستخدم HTTPS. ونظرًا لأن أي شخص على الشبكة يمكنه رؤية هذه الأشياء، فإن التسريبات
سوف تعرض المستخدمين لهجمات الوسيط. تساعد السياسات
no-referrer-when-downgrade
وstrict-origin-when-cross-origin
وno-referrer
وstrict-origin
في حل هذه المشكلة. - تحسين الخصوصية: بالنسبة إلى طلب من مصادر متعددة، يشارك
no-referrer-when-downgrade
عنوان URL الكامل، ما قد يتسبب في حدوث مشاكل في الخصوصية. يتشاركstrict-origin-when-cross-origin
وstrict-origin
في الأصل فقط، ولا يشاركno-referrer
أي شيء على الإطلاق. يتيح لك ذلك استخدامstrict-origin-when-cross-origin
وstrict-origin
وno-referrer
كخيارات لتحسين الخصوصية. - الإفادة: لا يشارك
no-referrer
وstrict-origin
عنوان URL الكامل مطلقًا، حتى في الطلبات ذات المصدر نفسه. إذا كنت بحاجة إلى عنوان URL الكامل، ننصحك باستخدامstrict-origin-when-cross-origin
.
يعني كل ذلك أنّ strict-origin-when-cross-origin
هو خيار معقول بشكل عام.
مثال: ضبط سياسة strict-origin-when-cross-origin
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
أو من جهة الخادم، على سبيل المثال في Express:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
ماذا لو كانت السمة strict-origin-when-cross-origin
(أو الأكثر صرامة) لا تناسب جميع حالات استخدامك.
في هذه الحالة، اتّبِع نهجًا تقدّميًا من خلال ضبط سياسة وقائية، مثل
"strict-origin-when-cross-origin
"، لموقعك الإلكتروني، ووضع سياسة أكثر منحًا للأذونات في ما يتعلّق بطلبات محددة أو عناصر HTML.
مثال: سياسة على مستوى العنصر
index.html
:
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
قد يضع Safari أو WebKit حدًا أقصى على document.referrer
أو عنوان Referer
لطلبات المواقع الإلكترونية المتعدّدة.
يُرجى الاطّلاع على التفاصيل.
مثال: سياسة على مستوى الطلب
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
ما الذي يجب مراعاته أيضًا؟
يجب أن تعتمد سياستك على موقعك الإلكتروني وحالات الاستخدام التي تحدّدها أنت وفريقك وشركتك. إذا كانت بعض عناوين URL تحتوي على بيانات تعريفية أو حساسة، يمكنك وضع سياسة وقائية.
أفضل الممارسات المتعلّقة بالطلبات الواردة
في ما يلي بعض الإرشادات حول الإجراءات التي يجب اتّخاذها إذا كان موقعك الإلكتروني يستخدم عنوان URL المُحيل للطلبات الواردة.
حماية بيانات المستخدمين
قد يحتوي Referer
على بيانات خاصة أو شخصية أو تحدّد الهوية، لذا احرص على التعامل معها على هذا الأساس.
يمكن للمُحيلين الواردين تغيير {referer-can-change}
هناك بعض القيود المفروضة على استخدام المُحيل من الطلبات الواردة من مصادر متعددة:
- إذا لم تكن لديك إمكانية التحكم في تنفيذ باعث الطلب، لن تتمكّن
من وضع افتراضات بشأن عنوان
Referer
(وdocument.referrer
) الذي تلقّاه. قد يقرّر منشئ الطلب في أي وقت التبديل إلى سياسةno-referrer
أو بشكل عام إلى تطبيق سياسة أكثر صرامة من السياسة التي استخدمها في السابق. يعني ذلك أنّك تتلقّى بيانات أقل من "Referer
" مقارنةً بالفترة السابقة. - تستخدم المتصفّحات بشكل متزايد سياسة المُحيل
strict-origin-when-cross-origin
بشكل تلقائي. وهذا يعني أنّك قد تتلقّى الآن المصدر فقط في الطلبات الواردة من مصادر متعددة، بدلاً من عنوان URL المُحيل الكامل، وذلك في حال لم يتم تحديد سياسة للموقع الإلكتروني للمرسِل. - قد تُغيّر المتصفّحات الطريقة التي تدير بها
Referer
. على سبيل المثال، قد يقرّر بعض مطوّري المتصفِّحات دائمًا قطع المُحيلين إلى المصادر في طلبات الموارد الفرعية المتعددة المصادر، وذلك لحماية خصوصية المستخدم. - قد يحتوي عنوان
Referer
(وdocument.referrer
) على بيانات أكثر مما تحتاج إليه. على سبيل المثال، قد يحتوي الطلب على عنوان URL كامل إذا كنت تريد معرفة ما إذا كان الطلب من مصادر متعددة.
بدائل Referer
قد تحتاج إلى التفكير في بدائل في الحالات التالية:
- من الميزات الأساسية لموقعك الإلكتروني استخدام عنوان URL المُحيل للطلبات الواردة من مصادر متعددة.
- لم يعُد موقعك الإلكتروني يتلقّى الجزء من عنوان URL المُحيل الذي يحتاجه في طلب من مصادر متعددة. يحدث ذلك عندما يغيِّر مصدر الطلب سياسته أو عندما لا يتم ضبط سياسة ويتم تغيير السياسة التلقائية للمتصفِّح (كما هو الحال في Chrome 85).
لتحديد البدائل، عليك أولاً تحليل جزء المُحيل الذي تستخدمه.
إذا كنت بحاجة إلى المصدر فقط
- وإذا كنت تستخدم المُحيل في نص برمجي لديه إذن وصول عالي المستوى إلى الصفحة،
يمكنك استخدام
window.location.origin
كبديل. - في حال توفّر عناوين مثل
Origin
وSec-Fetch-Site
، تمنحكOrigin
أو تصف ما إذا كان الطلب من مصادر متعددة، وقد يكون هذا ما تحتاج إليه بالضبط.
إذا كنت بحاجة إلى عناصر أخرى لعنوان URL (المسار، معلمات طلب البحث...)
- قد تعالج معلَمات الطلب حالة الاستخدام، ما يوفّر عليك عناء تحليل المُحيل.
- إذا كنت تستخدم المُحيل في نص برمجي لديه إذن وصول عالي المستوى إلى الصفحة،
قد يعمل
window.location.pathname
كبديل. يمكنك استخراج قسم المسار فقط لعنوان URL وتمريره كوسيطة، كي لا يتم نقل أي معلومات من المحتمل أن تكون حساسة في معلمات عنوان URL.
إذا لم تتمكن من استخدام البدائل التالية:
- تحقَّق مما إذا كان بإمكانك تغيير أنظمتك لتتوقّع أن توفّر ميزة إصدار الطلبات (على سبيل المثال
site-one.example
) المعلومات التي تحتاجها بشكل صريح بطريقة معيّنة.- الإيجابي: أكثر وضوحًا، ويحافظ على الخصوصية بشكل أكبر لمستخدمي
site-one.example
، وحماية أكبر للمستقبل - السلبيات: المزيد من العمل من جانبك أو من أجل مستخدمي نظامك.
- الإيجابي: أكثر وضوحًا، ويحافظ على الخصوصية بشكل أكبر لمستخدمي
- تأكّد ممّا إذا كان الموقع الإلكتروني الذي يرسل الطلبات قد يوافق على تعيين عنصر مُحيل لكل عنصر أو لكل طلب
no-referrer-when-downgrade
.- السلبيات: من المحتمل أن تكون عملية الحفاظ على الخصوصية أقل لمستخدمي
site-one.example
، ومن المحتمل ألا تكون متوافقة مع جميع المتصفحات.
- السلبيات: من المحتمل أن تكون عملية الحفاظ على الخصوصية أقل لمستخدمي
الحماية من التزوير على مواقع إلكترونية متعددة (CSRF)
يمكن أن يقرّر انبعاث الطلب دائمًا عدم إرسال المُحيل من خلال ضبط
سياسة no-referrer
، وقد ينتحل مستخدم ضار المُحيل.
استخدِم رموز CSRF
كالحماية الأساسية. للحصول على حماية إضافية، استخدِم
SameSite،
وبدلاً من Referer
، استخدِم عناوين مثل
Origin
(المتوفّرة في طلبات POST وCORS)
وSec-Fetch-Site
إذا كانت متاحة.
السجلّ وتصحيح الأخطاء
يُرجى الحرص على حماية بيانات المستخدمين الشخصية أو الحسّاسة التي قد تكون في
Referer
.
إذا كنت تستخدم المصدر فقط، تحقَّق مما إذا كان بإمكانك استخدام العنوان Origin
كبديل. قد يمنحك هذا المعلومات التي تحتاجها لتصحيح الأخطاء
في الأغراض بطريقة أبسط ودون الحاجة إلى تحليل المُحيل.
الدفع
قد يعتمد مقدّمو خدمات الدفع على العنوان Referer
للطلبات الواردة في عمليات فحص الأمان.
مثال:
- ينقر المستخدم على زر شراء في
online-shop.example/cart/checkout
. - يعيد
online-shop.example
التوجيه إلىpayment-provider.example
لإدارة المعاملة. - يتحقّق
payment-provider.example
منReferer
لهذا الطلب بمقارنتها بقائمة من قيمReferer
المسموح بها التي أعدّها التجّار. وإذا لم يطابق أي إدخال في القائمة، سيتم رفض الطلب من خلالpayment-provider.example
. في حال عدم التطابق، يمكن للمستخدم المتابعة إلى المعاملة.
أفضل الممارسات لعمليات فحص الأمان لتدفق الدفع
بصفتك مقدّم خدمات دفع، يمكنك استخدام Referer
كإجراء تحقُّق أساسي ضد بعض
الهجمات. مع ذلك، لا يشكّل عنوان Referer
في حد ذاته أساسًا موثوقًا لإجراء عملية تحقّق. يمكن للموقع الإلكتروني الذي يقدّم الطلب، سواء كان تاجرًا شرعيًا أم لا، ضبط
سياسة no-referrer
تجعل معلومات Referer
غير متوفّرة
لمقدّم الدفع.
إنّ الاطّلاع على Referer
قد يساعد مقدّمي خدمات الدفع في رصد المهاجمين الذين لم يضعوا سياسة no-referrer
. في حال استخدام "Referer
" كأول تحقُّق:
- لا تتوقع وجود
Referer
دائمًا. إذا كانت موجودة، تحقق منها مقابل الحد الأدنى من البيانات التي يمكن تضمينها، وهي الأصل.- عند إعداد قائمة قيم
Referer
المسموح بها، احرِص على تضمين الأصل وليس فقط أي مسار. - على سبيل المثال، يجب أن تكون قيم
Referer
المسموح بها للسمةonline-shop.example
online-shop.example
وليسonline-shop.example/cart/checkout
. إذا كنت تتوقّع عدم استخدامReferer
على الإطلاق أو قيمةReferer
تمثّل أصل الموقع الإلكتروني المطلوب فقط، فإنك تمنع الأخطاء التي قد تنتج عن وضع افتراضات حولReferrer-Policy
لدى التاجر.
- عند إعداد قائمة قيم
- إذا لم تتوفّر سمة
Referer
أو إذا كانت متوفّرة وتم التحقّق من أصلReferer
الأساسي بنجاح، يمكنك الانتقال إلى طريقة أخرى أكثر موثوقية لإثبات الهوية.
للتحقّق من عمليات الدفع بشكل أكثر موثوقية، اسمح لمقدِّم الطلب بتجزئة مَعلمات الطلب باستخدام مفتاح فريد. يمكن لمقدّمي خدمات الدفع بعد ذلك احتساب التجزئة نفسها من جانبك وقبول الطلب فقط إذا كان مطابقًا للعملية الحسابية.
ماذا يحدث Referer
إذا كان موقع إلكتروني لتاجر يستخدم بروتوكول HTTP لا يتضمن سياسة مُحيلة
يُعيد التوجيه إلى مقدّم خدمة الدفع الذي يستخدم بروتوكول HTTPS؟
لا يظهر Referer
في الطلب المُرسَل إلى مقدّم خدمة الدفع HTTPS، لأنّ
معظم المتصفحات تستخدم strict-origin-when-cross-origin
أو
no-referrer-when-downgrade
تلقائيًا عندما لا يتم ضبط سياسة للموقع الإلكتروني.
لن يؤدّي تغيير Chrome إلى سياسة تلقائية جديدة إلى تغيير هذا السلوك.
الخلاصة
تُعد سياسة المُحيل الوقائية طريقة رائعة لمنح المستخدمين مزيدًا من الخصوصية.
لمعرفة مزيد من المعلومات حول الأساليب المختلفة لحماية المستخدمين، راجع مجموعة الأمان والسلامة
المراجع
- فهم "الموقع الإلكتروني نفسه" و "المصدر نفسه"
- عنوان أمان جديد: سياسة المُحيل (2017)
- سياسة المُحيل بشأن MDN
- عنوان المرجع: مخاوف تتعلق بالخصوصية والأمان بشأن MDN
- تغيير Chrome: غرض Blink التنفيذ
- تغيير في Chrome: هدف Blink للشحن
- تغيير Chrome: إدخال الحالة
- تغيير إصدار Chrome: مشاركة مدونة إصدار تجريبي 85
- يقطع المُحيل سلسلة GitHub: الإجراءات التي تتخذها المتصفحات المختلفة
- مواصفات سياسة المُحيل
نقدّر الكثير من المراجعين على مساهماتهم وملاحظاتهم، وبالأخص "كوستوبا غوفيند" و"ديفيد فان كليف" و"مايك ويست" و"سام دوتون" و"روان ميروود" و"جيكسيك" و"كايس باسك".