Android Chrome 88 और डेस्कटॉप Chrome 92 में SharedarrayBuffer के अपडेट

Jake Archibald
Eiji Kitamura

यह कहना सही होगा कि SharedArrayBuffer को वेब पर थोड़ी परेशानी हुई है, लेकिन अब सब ठीक हो रहा है. यहां आपके जानने योग्य तथ्य दिए गए हैं:

कम शब्दों में जानकारी

  • फ़िलहाल, SharedArrayBuffer की सुविधा Firefox 79 और इसके बाद के वर्शन पर काम करती है. यह सुविधा Android के लिए, Chrome 88 में उपलब्ध होगी. हालांकि, यह सुविधा सिर्फ़ उन पेजों के लिए उपलब्ध है जो क्रॉस-ऑरिजिन आइसोलेटेड हैं.
  • फ़िलहाल, SharedArrayBuffer डेस्कटॉप के लिए उपलब्ध है. हालांकि, Chrome के वर्शन 92 से यह सिर्फ़ क्रॉस-ऑरिजिन आइसोलेशन वाले पेजों पर काम करेगा. अगर आपको लगता है कि आपके पास समय रहते यह बदलाव करने का विकल्प नहीं है, तो कम से कम Chrome 113 तक मौजूदा व्यवहार को बनाए रखने के लिए, ओरिजिन ट्रायल के लिए रजिस्टर करें.
  • अगर आपको SharedArrayBuffer का इस्तेमाल जारी रखने के लिए, क्रॉस-ऑरिजिन आइसोलेशन को चालू करना है, तो इस बात का आकलन करें कि इसका असर आपकी वेबसाइट पर मौजूद दूसरे क्रॉस-ऑरिजिन एलिमेंट पर क्या होगा. जैसे, विज्ञापन प्लेसमेंट. देखें कि असर और दिशा-निर्देश समझने के लिए, SharedArrayBuffer का इस्तेमाल आपके तीसरे पक्ष के किसी भी रिसॉर्स ने किया है या नहीं.

क्रॉस-ऑरिजिन आइसोलेशन की खास जानकारी

किसी पेज को क्रॉस-ऑरिजिन आइसोलेटेड बनाया जा सकता है. इसके लिए, पेज को इन हेडर के साथ दिखाएं:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

ऐसा करने के बाद, आपका पेज क्रॉस-ऑरिजिन कॉन्टेंट तब तक लोड नहीं कर पाएगा, जब तक कि रिसॉर्स Cross-Origin-Resource-Policy हेडर या CORS हेडर (Access-Control-Allow-* वगैरह) के ज़रिए साफ़ तौर पर इसकी अनुमति नहीं देता.

रिपोर्टिंग एपीआई भी उपलब्ध है, ताकि आप उन अनुरोधों का डेटा इकट्ठा कर सकें जो Cross-Origin-Embedder-Policy और Cross-Origin-Opener-Policy की वजह से पूरे नहीं हो पाए.

अगर आपको लगता है कि आपके पास Chrome 92 के लिए समय से ये बदलाव करने का विकल्प नहीं है, तो कम से कम Chrome 113 तक डेस्कटॉप पर Chrome के मौजूदा व्यवहार को बनाए रखने के लिए, ओरिजिन ट्रायल के लिए रजिस्टर करें.

क्रॉस-ऑरिजिन आइसोलेशन के बारे में ज़्यादा जानकारी और दिशा-निर्देश पाने के लिए, इस पेज पर सबसे नीचे मौजूद ज़्यादा पढ़ें सेक्शन देखें.

हम यहां कैसे पहुंचे?

SharedArrayBuffer, Chrome 60 में आया था. यह जुलाई 2017 में हुआ था. अगर आपको Chrome के वर्शन के बजाय तारीखों के हिसाब से समय पता करना है, तो यह जानकारी आपके लिए है. छह महीने के लिए.

जनवरी 2018 में, कुछ लोकप्रिय सीपीयू में एक सुरक्षा से जुड़ी समस्या का पता चला था. पूरी जानकारी के लिए, एलान देखें. इसका मतलब है कि कोड, ऐसी मेमोरी को पढ़ने के लिए हाई-रिज़ॉल्यूशन वाले टाइमर का इस्तेमाल कर सकता है जिसका ऐक्सेस उसके पास नहीं होना चाहिए.

ब्राउज़र वेंडर के लिए यह एक समस्या थी, क्योंकि हम साइटों को JavaScript और WASM के तौर पर कोड को लागू करने की अनुमति देना चाहते थे. हालांकि, हम इस बात पर सख्त नियंत्रण रखना चाहते थे कि यह कोड कितनी मेमोरी ऐक्सेस कर सकता है. अगर आप मेरी वेबसाइट पर आते हैं, तो मुझे उस इंटरनेट बैंकिंग साइट से कुछ भी नहीं पढ़ना चाहिए जिसे आपने भी खोला है. असल में, मुझे यह भी पता नहीं होना चाहिए कि आपने इंटरनेट बैंकिंग साइट खोली है. ये वेब सुरक्षा के बुनियादी सिद्धांत हैं.

इसे कम करने के लिए, हमने performance.now() जैसे हाई रिज़ॉल्यूशन वाले टाइमर का रिज़ॉल्यूशन कम कर दिया है. हालांकि, SharedArrayBuffer का इस्तेमाल करके, हाई रिज़ॉल्यूशन वाला टाइमर create जा सकता है. इसके लिए, वर्कर्स के टाइट लूप में मेमोरी में बदलाव करें और उसे किसी दूसरी थ्रेड में फिर से पढ़ें. इस समस्या को ठीक करने के लिए, अच्छे इरादे से लिखे गए कोड पर काफ़ी असर पड़ता. इसलिए, 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 को छोड़कर. iframes के लिए, हम कॉन्टेंट को अलग प्रोसेस में डालते हैं.

इन समस्याओं को कम करने के बाद, हमने Chrome 68 (जुलाई 2018) में SharedArrayBuffer को फिर से उपलब्ध कराया. हालांकि, यह सिर्फ़ डेस्कटॉप पर उपलब्ध है. प्रोसेस से जुड़ी अतिरिक्त ज़रूरी शर्तों की वजह से, हम मोबाइल डिवाइसों पर ऐसा नहीं कर सके. यह भी ध्यान दिया गया कि Chrome का समाधान अधूरा था, क्योंकि हम सिर्फ़ 'गलत' डेटा फ़ॉर्मैट को ब्लॉक कर रहे थे. हालांकि, यह मुमकिन है कि अनुमान लगाए जा सकने वाले यूआरएल पर मौजूद मान्य सीएसएस/जेएस/इमेज में निजी डेटा हो.

वेब स्टैंडर्ड के लोग, क्रॉस-ब्राउज़र के लिए बेहतर समाधान ढूंढने के लिए एक साथ आए. इस समस्या को हल करने के लिए, पेजों को यह बताने का विकल्प दिया गया था कि "मैं दूसरे सोर्स के कॉन्टेंट को इस प्रोसेस में शामिल करने की अपनी अनुमति वापस लेता/लेती हूं. इसके लिए, कॉन्टेंट के मालिक को ऑप्ट-इन करना होगा". यह एलान, पेज के साथ दिखाए गए COOP और COEP हेडर के ज़रिए किया जाता है. ब्राउज़र इस शर्त को लागू करता है. इसके बदले, पेज को SharedArrayBuffer और मिलती-जुलती सुविधाओं वाले अन्य एपीआई का ऐक्सेस मिलता है. अन्य ऑरिजिन, Cross-Origin-Resource-Policy या CORS के ज़रिए, कॉन्टेंट को एम्बेड करने की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

Firefox ने सबसे पहले SharedArrayBuffer को इस पाबंदी के साथ, 79 वर्शन (जुलाई 2020) में लॉन्च किया था.

इसके बाद, जनवरी 2021 में मैंने यह लेख लिखा और आपने इसे पढ़ा. नमस्ते.

हम अभी इसी प्रोसेस में हैं. Chrome 88, क्रॉस-ऑरिजिन आइसोलेशन वाले पेजों के लिए, SharedArrayBuffer को Android पर वापस लाता है. साथ ही, Chrome 92, डेस्कटॉप पर भी यही ज़रूरी शर्तें लागू करता है. ऐसा, एक जैसी सुविधाएं देने और क्रॉस-ऑरिजिन आइसोलेशन को पूरी तरह से लागू करने के लिए किया जाता है.

डेस्कटॉप पर Chrome में होने वाले बदलाव को कुछ समय के लिए रोकना

यह 'ऑरिजिन ट्रायल' के तौर पर, कुछ समय के लिए लागू किया गया है. इससे लोगों को क्रॉस-ऑरिजिन आइसोलेटेड पेजों को लागू करने के लिए ज़्यादा समय मिलता है. यह पेज को क्रॉस-ऑरिजिन आइसोलेट किए बिना, SharedArrayBuffer को चालू करता है. यह अपवाद, Chrome 113 में खत्म हो जाएगा. यह अपवाद सिर्फ़ Chrome के डेस्कटॉप वर्शन पर लागू होता है.

  1. अपने ऑरिजिन के लिए टोकन का अनुरोध करें.
  2. अपने पेजों पर टोकन जोड़ें. ऐसा करने के दो तरीके हैं:
    • हर पेज के हेडर में origin-trial <meta> टैग जोड़ें. उदाहरण के लिए, यह कुछ ऐसा दिख सकता है:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • अगर आपके पास अपने सर्वर को कॉन्फ़िगर करने का विकल्प है, तो Origin-Trial एचटीटीपी हेडर का इस्तेमाल करके भी टोकन जोड़ा जा सकता है. इससे मिलने वाला रिस्पॉन्स हेडर कुछ इस तरह दिखेगा:
      Origin-Trial: TOKEN_GOES_HERE

इसके बारे में और पढ़ें

Unsplash पर डैनियल ग्रेगोर की दी गई बैनर फ़ोटो