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

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

Eiji Kitamura

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

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

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

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

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 की ओर से अपलोड की गई फ़ोटो