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

Jake Archibald
Eiji Kitamura

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

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

  • SharedArrayBuffer की सुविधा, फ़िलहाल Firefox 79 और इसके बाद के वर्शन पर काम करती है. यह सुविधा, Android Chrome 88 में उपलब्ध होगी. हालांकि, यह सुविधा सिर्फ़ उन पेजों के लिए उपलब्ध है जो क्रॉस-ऑरिजिन आइसोलेटेड हैं.
  • SharedArrayBuffer फ़िलहाल, डेस्कटॉप Chrome पर उपलब्ध है. हालांकि, 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-* वगैरह) के ज़रिए इसकी अनुमति दे.

इसमें Reporting API भी है. इसकी मदद से, Cross-Origin-Embedder-Policy और Cross-Origin-Opener-Policy की वजह से पूरे न हो पाए अनुरोधों का डेटा इकट्ठा किया जा सकता है.

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

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

हमें यह डेटा कैसे मिला?

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

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

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

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

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

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

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

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

और अब हम यहीं हैं. Chrome 88, क्रॉस-ऑरिजिन आइसोलेट किए गए पेजों के लिए, Android पर SharedArrayBuffer को वापस लाता है. साथ ही, 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 पर Daniel Gregoire ने खींची है