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

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

في ما يلي ملخّص عن هذه الميزة:

  • تتوفّر ميزة SharedArrayBuffer حاليًا في الإصدار 79 من Firefox والإصدارات الأحدث، وستتوفّر في الإصدار 88 من Chrome على Android. ومع ذلك، لا يتوفّر هذا الخيار إلا للصفحات التي تمنع الوصول من نطاقات أخرى.
  • يتوفّر 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 الحالي على سطح المكتب حتى الإصدار 113 على الأقل من Chrome.

اطّلِع على قسم مراجع إضافية في أسفل هذه الصفحة للحصول على مزيد من الإرشادات والمعلومات حول عزل مصادر البيانات المختلفة.

كيف وصلنا إلى هذا الحدّ؟

تم طرح SharedArrayBuffer في الإصدار 60 من Chrome (أي في تموز (يوليو) 2017، بالنسبة إلى من يصنّف الوقت حسب التواريخ بدلاً من إصدارات Chrome)، وكان كل شيء رائعًا. لمدة 6 أشهر

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

كانت هذه مشكلة بالنسبة إلى مورّدي المتصفّحات، لأنّنا نريد السماح للمواقع الإلكترونية بتنفيذ رمزبرمجي في شكل JavaScript وWASM، ولكن مع التحكّم بشكل صارم في الذاكرة التي يمكن للرمز البرمجي الوصول إليها. إذا وصلت إلى موقعي الإلكتروني، لن أتمكّن من قراءة أي شيء من موقع المعاملات المصرفية على الإنترنت الذي يكون مفتوحًا أيضًا. في الواقع، من المفترض ألا أعرف حتى أنّك فتحت موقع المصرف على الإنترنت. هذه هي أساسيات أمان الويب.

للتخفيف من هذه المشكلة، خفّضنا درجة دقة الموقّتات العالية الدقة، مثل performance.now(). ومع ذلك، يمكنك create موقّت عالي الدقة باستخدام 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 لأجهزة الكمبيوتر المكتبي.

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

مراجع إضافية

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