تحديثات SharedArrayBuffer في الإصدار 88 من متصفّح Chrome على نظام التشغيل Android والإصدار 92 من متصفّح Chrome لأجهزة الكمبيوتر المكتبي

من العدل القول إنّ SharedArrayBuffer واجه بعض المشاكل عند إطلاقه على الويب، ولكن الأمور بدأت تستقر. في ما يلي ما تحتاج إلى معرفته:

باختصار

  • تتوفّر SharedArrayBuffer حاليًا في الإصدار 79 من Firefox والإصدارات الأحدث، وستتوفّر في الإصدار 88 من Chrome على Android. ومع ذلك، لا تتوفّر إلا للصفحات التي تحظر الوصول من نطاقات أخرى.
  • يتوفّر SharedArrayBuffer حاليًا في متصفّح Chrome على الكمبيوتر المكتبي، ولكن اعتبارًا من الإصدار 92 من Chrome، سيقتصر على الصفحات المعزولة من نطاقات أخرى. إذا كنت تعتقد أنّه لا يمكنك إجراء هذا التغيير في الوقت المناسب، يمكنك التسجيل في تجربة المصدر للاحتفاظ بالسلوك الحالي حتى الإصدار 113 من Chrome على الأقل.
  • إذا كنت تنوي تفعيل ميزة "العزل المشترك المصدر" لمواصلة استخدام SharedArrayBuffer، عليك تقييم التأثير الذي سيحدثه ذلك في العناصر الأخرى المشتركة المصدر على موقعك الإلكتروني، مثل مواضع الإعلانات. تحقَّق مما إذا كان SharedArrayBuffer يتم استخدامه من قِبل أي من المراجع التابعة لجهات خارجية لفهم التأثير والإرشادات.

نظرة عامة على ميزة "عزل عناوين URL التابعة للنطاق نفسه"

يمكنك جعل الصفحة تحظر الوصول من نطاقات آخرى من خلال عرضها مع العناوين التالية:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

بعد إجراء ذلك، لن تتمكّن صفحتك من تحميل محتوى من مصادر متعددة ما لم يسمح المورد بذلك بشكل صريح من خلال عنوان Cross-Origin-Resource-Policy أو عناوين CORS (Access-Control-Allow-* وما إلى ذلك).

تتوفّر أيضًا واجهة برمجة تطبيقات لإعداد التقارير، ما يتيح لك جمع بيانات عن الطلبات التي تعذّر تنفيذها نتيجة الخطأين Cross-Origin-Embedder-Policy وCross-Origin-Opener-Policy.

إذا كنت تعتقد أنّه لا يمكنك إجراء هذه التغييرات في الوقت المناسب قبل طرح الإصدار 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… -->

تتضمّن واجهات برمجة التطبيقات هذه سلوكًا &quot;قديمًا&quot; يسمح باستخدام المحتوى من مصادر أخرى بدون موافقة من المصدر الآخر. يتم تقديم هذه الطلبات باستخدام ملفات تعريف الارتباط الخاصة بالمصدر الآخر، لذا يكون الطلب كاملاً ومسجّلاً الدخول إليه. في الوقت الحالي، تتطلّب واجهات برمجة التطبيقات الجديدة أن يوافق المصدر الآخر على استخدام CORS.

تجاوزنا هذه المشكلة في واجهات برمجة التطبيقات القديمة من خلال منع المحتوى من الدخول إلى عملية صفحة الويب إذا بدا "غير صحيح"، وأطلقنا على هذه العملية اسم حظر القراءة من مصادر متعددة. لذلك، في الحالات المذكورة أعلاه، لن نسمح بإدخال JSON في العملية لأنّه ليس تنسيقًا صالحًا لأي من واجهات برمجة التطبيقات هذه. ويستثنى من ذلك إطارات iframe. بالنسبة إلى الإطارات المضمّنة (iframe)، نضع المحتوى في عملية مختلفة.

بعد تطبيق هذه الإجراءات، أعدنا طرح SharedArrayBuffer في الإصدار 68 من Chrome (يوليو 2018)، ولكن على أجهزة الكمبيوتر فقط. وقد حالت متطلبات المعالجة الإضافية دون توفير الميزة نفسها على الأجهزة الجوّالة. تمت الإشارة أيضًا إلى أنّ حلّ Chrome كان غير مكتمل، لأنّنا كنا نحظر فقط تنسيقات البيانات &quot;غير الصحيحة&quot;، في حين أنّه من المحتمل (على الرغم من أنّه أمر غير معتاد) أن تحتوي ملفات 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 لأجهزة الكمبيوتر.

  1. طلب رمز مميز لأصلك
  2. أضِف الرمز المميّز إلى صفحاتك. يمكنك إجراء ذلك بإحدى الطريقتَين التاليتَين:
    • أضِف علامة origin-trial <meta> إلى رأس كل صفحة. على سبيل المثال، قد يبدو ذلك على الشكل التالي:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • إذا كان بإمكانك ضبط الخادم، يمكنك أيضًا إضافة الرمز المميّز باستخدام عنوان Origin-Trial HTTP. يجب أن يظهر عنوان الاستجابة الناتج على النحو التالي:
      Origin-Trial: TOKEN_GOES_HERE

محتوى إضافي للقراءة

صورة البانر من تصوير دانيال غريغوار على Unsplash