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

यह कहना सही है कि 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 हेडर या सीओआरएस हेडर (Access-Control-Allow-* वगैरह) के ज़रिए इसकी अनुमति नहीं देता.

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

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

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

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

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… -->

इन एपीआई में 'लेगसी' सेटिंग लागू होती है. इसकी मदद से, दूसरे ऑरिजिन से ऑप्ट-इन किए बिना अन्य ऑरिजिन के कॉन्टेंट का इस्तेमाल किया जा सकता है. ये अनुरोध दूसरे ऑरिजिन की कुकी से किए जाते हैं, इसलिए यह पूरा 'लॉग इन' किया हुआ होता है. मौजूदा समय में, नए एपीआई को सीओआरएस का इस्तेमाल करके ऑप्ट-इन करने के लिए, अन्य ऑरिजिन की ज़रूरत होती है.

हमने इन पुराने एपीआई को ठीक करने के लिए काम किया. इसके लिए, हमने कॉन्टेंट को वेबपेज की प्रोसेस में शामिल होने से रोका, अगर वह 'गलत' लग रहा था. हमने इसे क्रॉस-ऑरिजिन रीड ब्लॉकिंग नाम दिया. इसलिए, ऊपर दिए गए मामलों में, हम JSON को प्रोसेस में शामिल होने की अनुमति नहीं देंगे, क्योंकि यह उनमें से किसी भी एपीआई के लिए मान्य फ़ॉर्मैट नहीं है. जैसे, iframes को छोड़कर. iframes के लिए, हम कॉन्टेंट को एक अलग प्रोसेस में रखते हैं.

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

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

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 पर डैनियल ग्रेगॉयर की बैनर फ़ोटो