يمكننا القول إنّ SharedArrayBuffer قد واجه بعض الصعوبات في الظهور على
الويب، ولكنّ الأمور بدأت تتحسن. في ما يلي ما تحتاج إلى معرفته:
باختصار
- تتوفّر
SharedArrayBufferحاليًا في Firefox 79 والإصدارات الأحدث، وستتوفّر في Android Chrome 88. ومع ذلك، لا يتوفّر هذا الخيار إلا للصفحات التي تمنع الوصول من نطاقات أخرى. - يتوفّر
SharedArrayBufferحاليًا في متصفّح Chrome لأجهزة الكمبيوتر المكتبي، ولكن اعتبارًا من الإصدار Chrome 92، سيقتصر على الصفحات المعزولة عن نطاقات أخرى. إذا كنت تعتقد أنّه لن تتمكّن من إجراء هذا التغيير في الوقت المناسب، يمكنك التسجيل في فترة تجريبية للإصدار الأصلي من Chrome للاحتفاظ بالسلوك الحالي حتى الإصدار Chrome 113 على الأقل. - إذا كنت تنوي تفعيل عزل مصادر البيانات لمواصلة استخدام
SharedArrayBuffer، عليك تقييم التأثير الذي سيحدثه ذلك على عناصر مصادر البيانات الأخرى على موقعك الإلكتروني، مثل مواضع الإعلانات. تحقّق مما إذا كان أيّ من مواردك التابعة لجهات خارجية يستخدمSharedArrayBufferلفهم تأثيره والاطّلاع على الإرشادات.
نظرة عامة على عزل عناوين URL التابعة للنطاق نفسه
يمكنك جعل الصفحة معزولة عن النطاقات الأخرى من خلال عرض الصفحة باستخدام عناوين HTTP التالية:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
بعد إجراء ذلك، لن تتمكّن صفحتك من تحميل محتوى من مصادر متعددة ما لم يسمح المورد بذلك صر��حةً من خلال عنوان Cross-Origin-Resource-Policy
أو عناوين CORS
(Access-Control-Allow-* وما إلى ذلك).
تتوفّر أيضًا Reporting API، ما يتيح لك جمع بيانات عن الطلبات التي تعذّر إجراؤها نتيجةً لخطأ في Cross-Origin-Embedder-Policy وCross-Origin-Opener-Policy.
إذا كنت تعتقد أنّه لا يمكنك إجراء هذه التغييرات في الوقت المناسب لإصدار Chrome 92، يمكنك التسجيل في إصدار تجريبي من الإصدار الأصلي للاحتفاظ بالسلوك الحالي لتطبيق Chrome على أجهزة الكمبيوتر المكتبي حتى الإصدار 113 من Chrome على الأقل.
اطّلِع على قسم مراجع إضافية في أسفل هذه الصفحة للحصول على مزيد من الإرشادات والمعلومات حول عزل مصادر البيانات المختلفة.
كيف وصلنا إلى هنا؟
تم طرح SharedArrayBuffer في الإصدار 60 من Chrome (أي في تموز (يوليو) 2017، إذا كنت ممن يحسبون الوقت بالتاريخ بدلاً من إصدارات Chrome)، وكان كل شيء رائعًا.
لمدة 6 أشهر.
في كانون الثاني (يناير) 2018، تم الكشف عن ثغرة أمنية في بعض وحدات المعالجة المركزية الشائعة. يُرجى الاطّلاع على الإشعار لمعرفة التفاصيل الكاملة، ولكن هذا يعني بشكل أساسي أنّه يمكن للرمز استخدام أدوات توقيت عالية الدقة لقراءة الذاكرة التي لا يُسمح له بالوصول إليها.
كانت هذه مشكلة بالنسبة إلى مورّدي المتصفّحات، لأنّنا نريد السماح للمواقع الإلكترونية بتنفيذ الرمز البرمجي في شكل JavaScript وWASM، ولكن مع التحكّم بشكل صارم في الذاكرة التي يمكن أن يصل إليها الرمز البرمجي. إذا وصلت إلى موقعي الإلكتروني، لن أتمكّن من قراءة أي شيء من موقع المعاملات المصرفية على الإنترنت الذي يكون مفتوحًا أيضًا. في الواقع، من المفترض ألا أعرف حتى أنّك فتحت موقع المصرف على الإنترنت. هذه هي أساسيات أمان الويب.
وللحدّ من ذلك، خفّضنا درجة دقة الموقّتات العالية الدقة، مثل performance.now(). ومع ذلك، يمكنك إنشاء موقّت عالي الدقة باستخدام
SharedArrayBuffer من خلال تعديل الذاكرة في حلقة ضيقة في أحد خيوط العمل، وقراءة
الذاكرة مرة أخرى في سلسلة محادثات أخرى. لم يكن من الممكن تخفيف هذا التأثير بشكل فعّال بدون
التأثير بشكل كبير في الرموز البرمجية التي تم إنشاؤها بحسن نية، لذلك تم إيقاف SharedArrayBuffer
تمامًا.
ومن الإجراءات العامة للتخفيف من هذه المشكلة التأكّد من أنّ عملية النظام في صفحة الويب لا تحتوي على بيانات حسّاسة من مكان آخر. منذ البداية، ركز فريق Chrome على استخدام بنية برمجية متعددة العمليات (هل تتذكر المَثُل الهزلي؟)، ولكن كانت هناك حالات تؤدي فيها البيانات من مواقع إلكترونية متعددة إلى العملية نفسها:
<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->
تعتمد واجهات برمجة التطبيقات هذه سلوكًا "قديمًا" يسمح باستخدام محتوى من مصادر أخرى بدون الموافقة من المصدر الآخر. يتم تقديم هذه الطلبات باستخدام ملفات تعريف الارتباط من المصدر الآخر، لذا يكون الطلب كاملاً "بعد تسجيل الدخول". في الوقت الحالي، تتطلّب واجهة برمجة التطبيقات الجديدة منح الإذن للمصدر الآخر باستخدام CORS.
لقد تجنّبنا استخدام واجهات برمجة التطبيقات القديمة هذه من خلال منع المحتوى من الدخول إلى عملية الصفحة الإلكترونية إذا بدا "غير صحيح"، وأطلقنا على ذلك اسم حظر القراءة من مصادر متعددة. لذلك، في الحالات أعلاه، لن نسمح بدخول تنسيق JSON إلى العملية، لأنّه ليس تنسيقًا صالحًا لأيّ من واجهات برمجة التطبيقات هذه. باستثناء إطارات iframe. بالنسبة إلى إطارات iframe، تتم معالجة المحتوى في عملية مختلفة.
بعد تنفيذ هذه الإجراءات، أعدنا استخدام SharedArrayBuffer في الإصدار 68 من Chrome (تموز/يوليو 2018)، ولكن على أجهزة الكمبيوتر المكتبي فقط. بسبب المتطلبات الإضافية للعملية، لم يكن بإمكاننا
تنفيذ الإجراء نفسه على الأجهزة الجوّالة. لوحظ أيضًا أنّ حلّ Chrome
لم يكن كاملاً، لأنّنا كنا نحظر فقط تنسيقات البيانات "غير الصحيحة"، في حين أنّه
من الممكن (على الرغم من أنّه غير معتاد) أن تحتوي ملفات CSS/JS/الصور الصالحة على عناوين URL يمكن تخمينها والتي بدورها
قد تحتوي على بيانات خاصة.
اجتمع خبراء معايير الويب لوضع حلّ كامل ومتوافق مع ��ميع ��لمتص��ّحات. ��ان الحلّ هو منح الصفحات طريقة للقول "أتخلّى بموجب هذا عن
إمكانية إدخال محتوى من مصدر آخر في هذه العملية بدون موافقتهم".
يتم إجراء هذا البيان من خلال عنوانَي COOP وCOEP
المُرسَلَين مع الصفحة. يفرض المتصفّح ذلك، وفي المقابل تحصل الصفحة على
إذن الوصول إلى SharedArrayBuffer وواجهات برمجة التطبيقات الأخرى التي تتمتع بصلاحيات مماثلة. يمكن لمواقع المصدر الأخرى
الموافقة على تضمين المحتوى من خلال
Cross-Origin-Resource-Policy
أو CORS.
كان Firefox هو أول مطوّر يطرح SharedArrayBuffer مع هذا التقييد، في
الإصدار 79 (تموز/يوليو 2020).
بعد ذلك، في كانون الثاني (يناير) 2021، كتبتُ هذه المقالة وقرأتها. مرحبًا،
وهذا هو ما نحن عليه الآن. يعيد الإصدار 88 من Chrome استخدام SharedArrayBuffer في
نظام التشغيل Android للصفحات التي تم عزلها من نطاقات أخرى، ويضيف الإصدار 92 من Chrome متطلبات
الإصدار 88 نفسها إلى أجهزة الكمبيوتر المكتبي، وذلك من أجل تحقيق الاتساق وتنفيذ حظر الوصول من نطاقات أخرى بشكل كامل.
تأخير تغيير Chrome لأجهزة الكمبيوتر المكتبي
هذا استثناء مؤقت في شكل "تجربة المصدر" يمنح المستخدمين
مزيدًا من الوقت لتنفيذ الصفحات التي تم عزلها عن مصادر متعددة. ويُتيح استخدام
SharedArrayBuffer بدون الحاجة إلى عزل الصفحة عن مصادر أخرى. تنتهي صلاحية
الاستثناء في الإصدار 113 من Chrome، ولا ينطبق إلا على Chrome
لأجهزة الكمبيوتر المكتبي.
- اطلب رمزًا مميّزًا لمصدرك.
- أضِف الرمز المميّز إلى صفحاتك. هناك طريقتان لإجراء ذلك:
- أضِف علامة
origin-trial<meta>إلى رأس كل صفحة. على سبيل المثال، قد يبدو هذا على النحو التالي:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - إذا كان بإمكانك ضبط إعدادات الخادم، يمكنك أيضًا إضافة الرمز المميّز
باستخدام عنوان HTTP
Origin-Trial. يجب أن يشبه عنوان الاستجابة الناتج الشكل التالي:
Origin-Trial: TOKEN_GOES_HERE
- أضِف علامة
مراجع إضافية
- دليل لتفعيل ميزة "حظر الوصول من نطاقات أخرى"
- كيفية عزل صفحاتك عن مصادر أخرى
- سبب الحاجة إلى عزل المحتوى المضمّن من مصادر خارجية
صورة البانر مقدمة من دانيال غريغوري على Unsplash