एक ही ऑरिजिन वाले 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 होना चाहिए या इसके उलट होना चाहिए.

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

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 की फ़ोटो