من الإنصاف القول إنّ SharedArrayBuffer قد واجه بعض الصعوبات في الظهور على
الويب، ولكنّ الأمور بدأت تتحسن. في ما يلي ما تحتاج إلى معرفته:
باختصار
- تتوفّر ميزة
SharedArrayBufferحاليًا في الإصدار 79 من Firefox والإصدارات الأحدث، وستتوفّر في الإصدار 88 من Android Chrome. ومع ذلك، لا يتوفّر هذا الخيار إلا للصفحات التي تمنع الوصول من نطاقات أخرى. - يتوفّر
SharedArrayBufferحاليًا في متصفّح Chrome لأجهزة الكمبيوتر المكتبي، ولكن اعتبارًا من الإصدار Chrome 92، سيقتصر على الصفحات المعزولة عن نطاقات أخرى. إذا كنت تعتقد أنّه لن تتمكّن من إجراء هذا التغيير في الوقت المناسب، يمكنك التسجيل في فترة تجريبية للإصدار الأصلي من Chrome للاحتفاظ بالسلوك الحالي حتى الإصدار Chrome 113 على الأقل. - إذا كنت تنوي تفعيل عزل مصادر البيانات لمواصلة استخدام
SharedArrayBuffer، عليك تقييم التأثير الذي سيحدثه ذلك على عناصر مصادر البيانات الأخرى على موقعك الإلكتروني، مثل مواضع الإعلانات. تحقّق مما إذا كانSharedArrayBufferيستخدمه أيّ من مواردك التابعة لجهات خارجية لفهم التأثير والحصول على guidance.
نظرة عامة على عزل عناوين URL التابعة للنطاق نفسه
يمكنك جعل الصفحة معزولة عن النطاقات الأخرى من خلال عرض الصفحة باستخدام علامتَي الاقتباس التاليتَين:
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 الأوّلي للاحتفاظ بسلوك 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 متطلبات مماثلة
على أجهزة الكمبيوتر المكتبي، وذلك من أجل تحقيق اتساق ومنع الوصول من نطاقات أخرى
بشكل كامل.
تأخير تغيير 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