एक ही ऑरिजिन वाले 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, Site-keyed agent clusters पर अलग-अलग दस्तावेज़ों, टैब, और फ़्रेम को अंदरूनी तौर पर मैनेज करता रहा है. इसका मतलब है कि एक ही साइट के दस्तावेज़ों को एक ही प्रोसेस में हैंडल किया जाता है (यह तरीका हर ब्राउज़र के हिसाब से अलग-अलग होता है). हाल ही में, Chrome ने इन्हें और ज़्यादा बारीकी से काम करने वाली इकाइयों में हैंडल करना शुरू किया: ऑरिजिन. हम इसे ऑरिजिन-की एजेंट क्लस्टर कहते हैं. हालांकि, ऐसा करना काफ़ी महंगा होता है. इसलिए, ऑरिजिन के हिसाब से बने एजेंट क्लस्टर सिर्फ़ सीमित वेबसाइटों पर ही लागू किए गए थे.

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

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

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

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

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

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

Unsplash पर मार्कस विंकलर की फ़ोटो