एक ही ऑरिजिन वाले Wasm मॉड्यूल को प्रतिबंधित करें

एक ही साइट के एनवायरमेंट के बीच WebAssembly मॉड्यूल शेयर करने की सुविधा, सिर्फ़ एक ही ऑरिजिन तक सीमित होगी.

Eiji Kitamura

एक ही साइट के क्रॉस-ऑरिजिन वाले एनवायरमेंट के बीच WebAssembly (Wasm) मॉड्यूल शेयर करने की सुविधा बंद कर दी जाएगी. इससे, एजेंट क्लस्टर को लंबे समय तक ऑरिजिन के दायरे में रखने की अनुमति मिल जाएगी. ऐसे में, जिन डेवलपर ने Wasm मॉड्यूल का इस्तेमाल किया है उन्हें यह पक्का करना होगा कि वे मॉड्यूल, एक ही ऑरिजिन पर इंस्टैंशिएट किए गए हों, ताकि Chrome 95 के बाद भी उनका इस्तेमाल किया जा सके.

Wasm मॉड्यूल क्या हैं और ये कैसे काम करते हैं

WebAssembly प्रोग्राम को मॉड्यूल में व्यवस्थित किया जाता है. ये मॉड्यूल, डिप्लॉयमेंट, लोडिंग, और कंपाइलेशन की इकाई होते हैं.

इस उदाहरण में दिए गए कोड में, https://iframe.site.example से इंपोर्ट किए गए Wasm मॉड्यूल को postMessage() के ज़रिए https://main.site.example के साथ शेयर किया गया है. ध्यान दें कि ये डोमेन एक ही साइट के, लेकिन अलग-अलग ऑरिजिन के हैं.

https://iframe.site.example पर Wasm मॉड्यूल:

(async () => {
  const instance = await WebAssembly.instantiateStreaming(fetch('./add.wasm'), {});
  iframe.contentWindow.postMessage(instance.module, `https://main.site.example`);
})();

Chrome 95 से, ईमेल भेजने वाले और पाने वाले का एक ही सोर्स होना ज़रूरी है. ऊपर दिए गए उदाहरण में, https://iframe.site.example की जगह https://main.site.example या https://main.site.example की जगह https://iframe.site.example होना चाहिए.

इसकी ज़रूरत क्यों है

Chrome, साइट के हिसाब से बने एजेंट क्लस्टर में अलग-अलग दस्तावेज़, टैब, और फ़्रेम को मैनेज करता रहा है. इसका मतलब है कि एक साइट वाले दस्तावेज़ एक ही प्रोसेस में मैनेज किए जाते हैं. एक ब्राउज़र के हिसाब से, इसके काम करने का तरीका अलग-अलग होता है. हाल ही में, Chrome ने उन्हें ज़्यादा बेहतर यूनिट: ऑरिजिन में मैनेज करना शुरू किया है. हम इसे ऑरिजिन के हिसाब से एजेंट क्लस्टर कहते हैं. हालांकि, ऐसा करने के लिए ज़्यादा संसाधनों की ज़रूरत होती है. इसलिए, ऑरिजिन-की वाले एजेंट क्लस्टर को सिर्फ़ कुछ वेबसाइटों पर लागू किया गया था.

हमारा प्लान है कि सभी एजेंट क्लस्टर को डिफ़ॉल्ट रूप से, ऑरिजिन के हिसाब से बनाया जाए. ऐसा करने के लिए, हमें उन सुविधाओं पर पाबंदी लगानी होगी जिनके लिए साइट-की वाले ऑरिजिन क्लस्टर की ज़रूरत होती है:

  • (सिर्फ़ Chrome के लिए) अब एक ही साइट के दूसरे क्रॉस-ऑरिजिन पेजों पर, SharedArrayBuffer या WebAssembly.Memory ऑब्जेक्ट नहीं भेजे जा सकते. यह सुविधा Chrome 92 से पहले से मौजूद है.
  • अब postMessage() की मदद से, एक ही साइट के दूसरे क्रॉस-ऑरिजिन पेजों पर WebAssembly.Module ऑब्जेक्ट नहीं भेजे जा सकते. इस बदलाव के बारे में ज़्यादा जानकारी यहां दी गई है.
  • अब आपके पास document.domain को सेट करने का विकल्प नहीं है. यह एक लेगसी सुविधा है, जो आम तौर पर एक जैसी साइट के क्रॉस-ऑरिजिन पेजों को एक-दूसरे के डीओएम को सिंक्रोनस ऐक्सेस करने की अनुमति देती है. हालांकि, ऑरिजिन-की एजेंट क्लस्टर में, यह सुविधा बंद रहती है.

ऊपर बताए गए सभी बदलावों को लागू करने के बाद, Chrome डिफ़ॉल्ट रूप से ऑरिजिन के हिसाब से एजेंट क्लस्टर का इस्तेमाल करेगा.

ऑरिजिन-की वाले एजेंट क्लस्टर के बारे में ज़्यादा जानने के लिए, Origin-Agent-Cluster हेडर की मदद से परफ़ॉर्मेंस को अलग करने का अनुरोध करना लेख पढ़ें.

अगले चरण और संसाधन

Chrome को डिफ़ॉल्ट रूप से ऑरिजिन-की वाले एजेंट क्लस्टर के साथ काम करने के लिए, हम document.domain को सिर्फ़ पढ़ने के लिए उपलब्ध कराएँगे. Chrome की टीम, इस बदलाव को 2022 में लागू करने की कोशिश कर रही है.

Unsplash पर, Markus Winkler की ओर से अपलोड की गई फ़ोटो