आइसोलेटेड वेब ऐप्लिकेशन

वेब, वाकई में एक यूनीक ऐप्लिकेशन प्लैटफ़ॉर्म है. इस पर बनाए गए ऐप्लिकेशन को किसी भी ऑपरेटिंग सिस्टम पर तुरंत ऐक्सेस किया जा सकता है. इसके लिए, कोड में कोई बदलाव करने या उसे कंपाइल करने की ज़रूरत नहीं होती. जब भी कोई उपयोगकर्ता आपके ऐप्लिकेशन पर आता है, तो उसके पास हमेशा सबसे नया वर्शन होता है. इन्हें इंस्टॉल किया जा सकता है और ये ऑफ़लाइन भी काम कर सकते हैं. साथ ही, ये बेहद काम के होते हैं और इन्हें सिर्फ़ एक लिंक की मदद से आसानी से शेयर किया जा सकता है. एक वेब ऐप्लिकेशन बनाएं और वह हर जगह काम करे.

वेब का मकसद डिफ़ॉल्ट रूप से सुरक्षित होना है. इसलिए, इसके सुरक्षा मॉडल को बहुत ज़्यादा सुरक्षित होना चाहिए. जोड़ी गई नई सुविधाओं को सुरक्षित होना चाहिए, ताकि कोई सामान्य उपयोगकर्ता किसी यूआरएल के ज़रिए गलती से भी उन्हें ऐक्सेस न कर पाए. हम इस सुरक्षा मॉडल को ड्राइव-बाय वेब कहते हैं. यह कई ऐप्लिकेशन के लिए बेहतरीन है. साथ ही, कॉन्टेंट सिक्योरिटी पॉलिसी और क्रॉस-ऑरिजिन आइसोलेशन का इस्तेमाल करके, इसे ज़्यादा सुरक्षित बनाया जा सकता है. हालांकि, यह हर इस्तेमाल के उदाहरण के लिए काम नहीं करता. डेवलपर को कई अहम और बहुत शक्तिशाली एपीआई की ज़रूरत होती है. जैसे, डायरेक्ट सॉकेट और कंट्रोल किया गया फ़्रेम. हालांकि, वेब ड्राइव के लिए इन्हें सुरक्षित नहीं बनाया जा सकता.

फ़िलहाल, इन ऐप्लिकेशन के लिए वेब पर काम करने का विकल्प उपलब्ध नहीं है. कुछ लोगों के लिए, वेब का सुरक्षा मॉडल काफ़ी नहीं हो सकता. वे यह नहीं मानते कि सर्वर भरोसेमंद है. इसके बजाय, वे अलग-अलग वर्शन वाले और हस्ताक्षर किए गए स्टैंड-अलोन ऐप्लिकेशन को पसंद करते हैं. सुरक्षा के लिए एक नए और भरोसेमंद मॉडल की ज़रूरत है. आइसोलेटेड वेब ऐप्लिकेशन (आईडब्ल्यूए), मौजूदा वेब प्लैटफ़ॉर्म पर बनाए गए ऐप्लिकेशन मॉडल होते हैं. ये आइसोलेटेड, बंडल किए गए, वर्शन वाले, हस्ताक्षर किए गए, और भरोसेमंद होते हैं. इनसे डेवलपर को मदद मिलती है.

वेब पर भरोसे का स्पेक्ट्रम

वेब पर सुरक्षा और सुविधाओं को स्पेक्ट्रम के तौर पर देखा जा सकता है.

वेब पर भरोसे के स्पेक्ट्रम को दिखाने वाली इमेज. बाईं ओर, ड्राइव-बाय वेब को दिखाने वाला ग्लोब. बीच में, प्रोग्रेसिव वेब ऐप्लिकेशन. दाईं ओर, एक मछली का कटोरा है. इसमें एक सुनहरी मछली है. यह आइसोलेटेड वेब ऐप्लिकेशन को दिखाती है. एक काली लाइन, तीनों आइकॉन को हॉरिज़ॉन्टल तरीके से जोड़ती है. साथ ही, लाल रंग की डैश वाली लाइन, प्रोग्रेसिव वेब ऐप्लिकेशन को आइसोलेटेड वेब ऐप्लिकेशन से अलग करती है

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

इसके बाद, ज़्यादा भरोसेमंद आइसोलेटेड वेब ऐप्लिकेशन आते हैं.

ये नेटिव ऐप्लिकेशन की तरह काम करते हैं और उनकी तरह ही लगते हैं. साथ ही, ये सिस्टम के साथ बेहतर तरीके से इंटिग्रेट हो सकते हैं और इनमें कई बेहतरीन सुविधाएं होती हैं. उपयोगकर्ता, इन दोनों के बीच और ड्राइव-बाय-वेब के बीच स्विच नहीं कर सकते. अगर आपको इस लेवल की सुरक्षा या ये सुविधाएं चाहिए, तो आपके पास वापस जाने का विकल्प नहीं होगा.

यह तय करते समय कि आपको इस स्पेक्ट्रम में कहां जाना चाहिए, सबसे कम भरोसे वाले सुरक्षा मॉडल का इस्तेमाल करें. जैसे, प्रोग्रेसिव वेब ऐप्लिकेशन. इससे आपको सबसे ज़्यादा लोगों तक पहुंचने में मदद मिलेगी. साथ ही, आपको सुरक्षा से जुड़ी कम से कम समस्याओं को खुद मैनेज करना होगा. इसके अलावा, यह आपके डेवलपर और उपयोगकर्ताओं के लिए सबसे ज़्यादा फ़ायदेमंद होगा.

सुरक्षा को ध्यान में रखकर डिज़ाइन किया गया

आइसोलेटेड वेब ऐप्लिकेशन, वेब ऐप्लिकेशन के लिए भरोसेमंद सुरक्षा मॉडल उपलब्ध कराते हैं. हालांकि, इसे चालू करने के लिए, वेब पर ड्राइव करने के बारे में कुछ मान्यताओं पर फिर से विचार करना होगा. सर्वर और डीएनएस जैसे वेब बिल्डिंग ब्लॉक पर अब भरोसा नहीं किया जा सकता. हमले के ऐसे तरीके अचानक अहम हो जाते हैं जो नेटिव ऐप्लिकेशन के लिए ज़्यादा काम के लगते हैं. इसलिए, आईडब्ल्यूए की ओर से उपलब्ध कराए गए नए भरोसेमंद सुरक्षा मॉडल का ऐक्सेस पाने के लिए, वेब ऐप्लिकेशन को पैकेज, आइसोलेट, और लॉक डाउन करना होगा.

पैकेज किया गया

आइसोलेटेड वेब ऐप्लिकेशन के पेजों और ऐसेट को लाइव सर्वर से नहीं दिखाया जा सकता. साथ ही, इन्हें सामान्य वेब ऐप्लिकेशन की तरह नेटवर्क पर फ़ेच नहीं किया जा सकता. इसके बजाय, ज़्यादा भरोसेमंद सुरक्षा मॉडल का ऐक्सेस पाने के लिए, वेब ऐप्लिकेशन को उन सभी संसाधनों को Signed WebBundle में पैकेज करना होगा जिनकी उन्हें चलाने के लिए ज़रूरत होती है. हस्ताक्षर किए गए वेब बंडल में, किसी साइट को चलाने के लिए ज़रूरी सभी संसाधन शामिल होते हैं. इन संसाधनों को एक साथ .swbn फ़ाइल में पैकेज किया जाता है. साथ ही, इन्हें इंटीग्रिटी ब्लॉक के साथ जोड़ा जाता है. इससे वेब ऐप्लिकेशन को पूरी तरह से सुरक्षित तरीके से डाउनलोड किया जा सकता है. साथ ही, इसे ऑफ़लाइन होने पर भी शेयर या इंस्टॉल किया जा सकता है.

हालांकि, इससे किसी साइट के कोड की पुष्टि करने में समस्या आती है: TLS कुंजियों को काम करने के लिए इंटरनेट कनेक्शन की ज़रूरत होती है. आईडब्ल्यूए को टीएलएस कुंजियों के बजाय, ऐसी कुंजी से साइन किया जाता है जिसे सुरक्षित तरीके से ऑफ़लाइन रखा जा सकता है. अच्छी बात यह है कि अगर आपके पास अपनी सभी प्रोडक्शन फ़ाइलों को एक फ़ोल्डर में इकट्ठा करने का विकल्प है, तो उन्हें बिना ज़्यादा बदलाव किए IWA में बदला जा सकता है.

चेतावनी: डिज़ाइन के हिसाब से, आईडब्ल्यूए कुछ साइट आर्किटेक्चर को शामिल नहीं करते हैं. किसी साइट को ऑफ़लाइन होने पर भी, अपने हर पेज को ऐक्सेस करने की सुविधा देनी चाहिए. इसका मतलब है कि सर्वर पर रेंडर किए गए पेजों को शामिल नहीं किया जा सकता. आपको स्टैटिक जनरेटेड साइटों या क्लाइंट-रेंडर की गई साइटों को अपने मुख्य आर्किटेक्चर के तौर पर इस्तेमाल करना चाहिए.

साइनिंग कुंजियां जनरेट करना

साइनिंग पासकोड, Ed25519 या ECDSA P-256 पासकोड पेयर होते हैं. इनमें से निजी पासकोड का इस्तेमाल, बंडल पर साइन करने के लिए किया जाता है. वहीं, सार्वजनिक पासकोड का इस्तेमाल, बंडल की पुष्टि करने के लिए किया जाता है. Ed25519 या ECDSA P-256 कुंजी जनरेट करने और उसे एन्क्रिप्ट (सुरक्षित) करने के लिए, OpenSSL का इस्तेमाल किया जा सकता है:

# Generate an unencrypted Ed25519 key
openssl genpkey -algorithm Ed25519 -out private_key.pem

# or generate an unencrypted ECDSA P-256 key
openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem

# Encrypt the generated key. This will ask for a passphrase, make sure to use a strong one
openssl pkcs8 -in private_key.pem -topk8 -out encrypted_key.pem

# Delete the unencrypted key
rm private_key.pem

का इस्तेमाल करके लिंक करें

साइनिंग कुंजियों का एक और मकसद भी होता है. किसी डोमेन को सर्वर की तरह कंट्रोल किया जा सकता है. इसलिए, इसका इस्तेमाल इंस्टॉल किए गए आईडब्ल्यूए की पहचान करने के लिए नहीं किया जा सकता. इसके बजाय, आईडब्ल्यूए की पहचान बंडल के सार्वजनिक पासकोड से होती है. यह पासकोड, इसके हस्ताक्षर का हिस्सा होता है और निजी पासकोड से जुड़ा होता है. ड्राइव-बाय वेब के काम करने के तरीके में यह एक अहम बदलाव है. इसलिए, एचटीटीपीएस का इस्तेमाल करने के बजाय, आईडब्ल्यूए भी एक नई स्कीम का इस्तेमाल करते हैं: isolated-app://.

चेतावनी: आपके आईडब्ल्यूए की पहचान, उस निजी कुंजी से जुड़ी होती है जिसका इस्तेमाल उसे साइन करने के लिए किया जाता है. इसलिए, आपको बनाए गए हर आईडब्ल्यूए के लिए, साइन करने की अलग कुंजी की ज़रूरत होगी. इसका यह भी मतलब है कि अगर एक ही ऐप्लिकेशन को अलग-अलग साइनिंग पासकोड से साइन किया जाता है, तो उन्हें अलग-अलग ऐप्लिकेशन माना जाएगा. इससे, आपको अपडेट करने का बेहतर अनुभव देने में मुश्किल होगी.

अपने ऐप्लिकेशन को बंडल करना

साइनिंग कुंजी उपलब्ध होने के बाद, अब अपने वेब ऐप्लिकेशन को बंडल करने का समय है. इसके लिए, NodeJS के आधिकारिक पैकेज का इस्तेमाल करके, अपने आईडब्ल्यूए को बंडल किया जा सकता है. इसके बाद, उन्हें साइन किया जा सकता है. Go कमांड-लाइन टूल भी उपलब्ध हैं. सबसे पहले, wbn पैकेज का इस्तेमाल करें. यह पैकेज, IWA की सभी प्रोडक्शन फ़ाइलों (यहां dist) वाले फ़ोल्डर की ओर इशारा करता है. इससे इन फ़ाइलों को बिना हस्ताक्षर वाले बंडल में रैप किया जा सकता है:

npx wbn --dir dist

ध्यान दें: npx, NPM का एक कमांड है (NPM 7 के मुताबिक). इसका इस्तेमाल यहां पैकेज को ग्लोबल तौर पर इंस्टॉल किए बिना या अपने प्रोजेक्ट की डिपेंडेंसी के तौर पर चलाने के आसान तरीके के तौर पर किया जाता है. यह हमेशा पैकेज के नए वर्शन का इस्तेमाल करने की कोशिश करेगा. अगर आपको अपनी बिल्ड में एक जैसा कॉन्टेंट चाहिए, तो आपको इन पैकेज को अपने प्रोजेक्ट में डेवलपमेंट डिपेंडेंसी के तौर पर इंस्टॉल करना चाहिए. साथ ही, उन्हें npm स्क्रिप्ट से चलाना चाहिए.

इससे उस डायरेक्ट्री का बिना हस्ताक्षर किया हुआ वेब बंडल जनरेट होगा. out.wbn. जनरेट होने के बाद, एन्क्रिप्ट (सुरक्षित) किए गए Ed25519 या ECDSA P-256 कुंजी का इस्तेमाल करें. इस कुंजी को आपने पहले बनाया था. इसका इस्तेमाल करके, wbn-sign का इस्तेमाल करके हस्ताक्षर करें:

npx wbn-sign -i out.wbn -k encrypted_key.pem -o signed.swbn

इससे, बिना हस्ताक्षर वाले वेब बंडल signed.swbn से एक हस्ताक्षर किया हुआ वेब बंडल जनरेट होगा. हस्ताक्षर करने के बाद, टूल वेब बंडल आईडी और उसके आइसोलेटेड वेब ऐप्लिकेशन का ऑरिजिन भी दिखाएगा. आइसोलेटेड वेब ऐप्लिकेशन के ऑरिजिन से, ब्राउज़र में आपके आईडब्ल्यूए की पहचान होती है.

Web Bundle ID: ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic
Isolated Web App Origin: isolated-app://ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic/

अगर Webpack, Rollup या उनके प्लग इन के साथ काम करने वाले किसी टूल (जैसे कि Vite) का इस्तेमाल किया जा रहा है, तो बंडलर प्लग इन (Webpack, Rollup) में से किसी एक का इस्तेमाल किया जा सकता है. ये प्लग इन, इन पैकेज को सीधे तौर पर कॉल करने के बजाय रैप करते हैं. ऐसा करने से, आपके बिल्ड के आउटपुट के तौर पर हस्ताक्षर किया गया बंडल जनरेट होगा.

अपने ऐप्लिकेशन की जांच करना

आपके पास IWA को दो तरीकों से टेस्ट करने का विकल्प होता है: पहला, Chrome में मौजूद IWA डेवलपर प्रॉक्सी के ज़रिए डेवलपमेंट सर्वर को चलाकर. दूसरा, बंडल किए गए IWA को इंस्टॉल करके. इसके लिए, आपको Chrome या ChromeOS 120 या उसके बाद के वर्शन का इस्तेमाल करना होगा. साथ ही, IWA फ़्लैग चालू करने होंगे. इसके बाद, Chrome के वेब ऐप्लिकेशन इंटरनल के ज़रिए अपना ऐप्लिकेशन इंस्टॉल करना होगा:

chrome://flags/#enable-isolated-web-app-dev-mode फ़्लैग चालू करें
Chrome के Web App Internals पेज पर जाकर, अपने IWA की जांच करें. इसके लिए, chrome://web-app-internals पर जाएं

वेब ऐप्लिकेशन के इंटरनल पेज पर, आपके पास दो विकल्प होते हैं: Install IWA with Dev Mode Proxy या Install IWA from Signed Web Bundle.

अगर आपने Dev Mode Proxy के ज़रिए इंस्टॉल किया है, तो आपके पास किसी भी यूआरएल को IWA के तौर पर इंस्टॉल करने का विकल्प होता है. इसमें लोकल डेवलपमेंट सर्वर से चलने वाली साइटें भी शामिल हैं. इसके लिए, आपको उन्हें बंडल करने की ज़रूरत नहीं होती. हालांकि, यह तब ही किया जा सकता है, जब वे IWA इंस्टॉल करने की अन्य ज़रूरी शर्तों को पूरा करती हों. इंस्टॉल हो जाने के बाद, उस यूआरएल के लिए IWA को आपके सिस्टम में जोड़ दिया जाएगा. इसमें सुरक्षा से जुड़ी सही नीतियां और पाबंदियां लागू होंगी. साथ ही, इसमें सिर्फ़ IWA वाले एपीआई का ऐक्सेस होगा. इसे एक रैंडम आइडेंटिफ़ायर असाइन किया जाएगा. इस मोड में Chrome DevTools भी उपलब्ध है, ताकि आपको अपने ऐप्लिकेशन को डीबग करने में मदद मिल सके. अगर आपने Signed Web Bundle से इंस्टॉल किया है, तो आपको साइन किया गया, बंडल किया गया IWA अपलोड करना होगा. यह ऐसे इंस्टॉल होगा जैसे इसे किसी उपयोगकर्ता ने डाउनलोड किया हो.

वेब ऐप्लिकेशन की इंटरनल जानकारी वाले पेज पर, Dev Mode Proxy या Signed Web Bundle के ज़रिए इंस्टॉल किए गए किसी भी ऐप्लिकेशन के लिए, अपडेट की जांच को भी फ़ोर्स किया जा सकता है. इससे अपडेट की प्रोसेस को भी टेस्ट किया जा सकता है.

आइसोलेट किया गया

आइसोलेटेड वेब ऐप्लिकेशन के लिए, भरोसा सबसे ज़रूरी है. इसकी शुरुआत इस बात से होती है कि वे कैसे काम करते हैं. उपयोगकर्ताओं के पास इस बारे में अलग-अलग मेंटल मॉडल होते हैं कि कोई ऐप्लिकेशन क्या कर सकता है और उसे क्या करना चाहिए. यह इस बात पर निर्भर करता है कि वह ब्राउज़र में चल रहा है या स्टैंड-अलोन विंडो में. आम तौर पर, उनका मानना होता है कि स्टैंड-अलोन ऐप्लिकेशन के पास ज़्यादा ऐक्सेस होता है और वे ज़्यादा शक्तिशाली होते हैं. आईडब्ल्यूए को भरोसेमंद एपीआई का ऐक्सेस मिल सकता है. इसलिए, उन्हें इस मेंटल मॉडल के मुताबिक, स्टैंड-अलोन विंडो में चलाना ज़रूरी है. इससे वे ब्राउज़र से अलग दिखते हैं. हालांकि, यह सिर्फ़ विज़ुअल सेपरेशन से कहीं ज़्यादा है.

आइसोलेटेड वेब ऐप्लिकेशन, ब्राउज़र में चलने वाली वेबसाइटों के मुकाबले अलग प्रोटोकॉल पर काम करते हैं. जैसे, isolated-app बनाम http या https. इसका मतलब है कि हर आईडब्ल्यूए, ब्राउज़र में चलने वाली वेबसाइटों से पूरी तरह अलग होता है. भले ही, उन्हें एक ही कंपनी ने बनाया हो. ऐसा समान ऑरिजिन नीति की वजह से होता है. IWA स्टोरेज भी एक-दूसरे से अलग होता है. इन दोनों से यह पक्का होता है कि अलग-अलग आईडब्ल्यूए के बीच या आईडब्ल्यूए और उपयोगकर्ता के सामान्य ब्राउज़िंग कॉन्टेक्स्ट के बीच, क्रॉस-ऑरिजिन कॉन्टेंट लीक न हो.

हालांकि, अगर कोई आईडब्ल्यूए इंस्टॉल होने के बाद आर्बिट्रेरी कोड को डाउनलोड और चलाने की अनुमति देता है, तो न तो आइसोलेशन और न ही बंडलिंग और साइट के कोड पर हस्ताक्षर करने से भरोसा कायम करने में मदद मिलती है. कॉन्टेंट के लिए, आईडब्ल्यूए को अन्य साइटों से कनेक्ट करने की अनुमति देते हुए, यह पक्का करने के लिए कि ऐसा हो, आईडब्ल्यूए कॉन्टेंट की सुरक्षा के लिए नीतियां लागू करते हैं:

यह बंडल से सिर्फ़ JavaScript को अनुमति देता है. हालांकि, यह Wasm को उसके सोर्स के बावजूद चलाने की अनुमति देता है. (script-src)
इस डायरेक्टिव की मदद से, JavaScript को सुरक्षित, नॉन-लोकलहोस्ट क्रॉस-ऑरिजिन डोमेन से फ़ेच करने की अनुमति मिलती है. साथ ही, WebSocket और WebTransport एंडपॉइंट से कनेक्ट करने के साथ-साथ blob और data यूआरएल (connect-src) से कनेक्ट करने की अनुमति मिलती है
यह कुकी, डीओएम क्रॉस-साइट स्क्रिप्ट इंजेक्शन (XSS) हमलों से सुरक्षा करती है. इसके लिए, यह कंट्रोल करती है कि डीओएम मैनिपुलेशन फ़ंक्शन का इस्तेमाल कैसे किया जा सकता है (require-trusted-types-for)
किसी भी एचटीटीपीएस डोमेन से फ़्रेम, इमेज, ऑडियो, और वीडियो इस्तेमाल करने की अनुमति देता है (frame-src, img-src, media-src)
यह बंडल और ब्लोब से फ़ॉन्ट इस्तेमाल करने की अनुमति देता है (font-src)
बंडल से इनलाइन सीएसएस या सीएसएस की अनुमति दें (style-src)
<object>, <embed>, और <base> एलिमेंट का इस्तेमाल नहीं किया जा सकता (object-src और base-uri)
यह सिर्फ़ बंडल से मिले संसाधनों को, सीएसएपी के दायरे में आने वाले किसी भी अन्य अनुरोध के लिए अनुमति देता है (default-src)

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval';
  connect-src 'self' https: wss: blob: data:;
  require-trusted-types-for 'script';
  frame-src 'self' https: blob: data:;
  img-src 'self' https: blob: data:;
  media-src 'self' https: blob: data:;
  font-src 'self' blob: data:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  default-src 'self';

ये सीएसपी, तीसरे पक्ष के ऐसे कोड से पूरी तरह सुरक्षित नहीं रखते जो नुकसान पहुंचा सकते हैं. आईडब्ल्यूए भी क्रॉस-ऑरिजिन आइसोलेटेड होते हैं. ये हेडर सेट करते हैं, ताकि तीसरे पक्ष के संसाधनों का इन पर कम असर पड़े:

सिर्फ़ बंडल या क्रॉस-ऑरिजिन रिसॉर्स से मिले उन रिसोर्स को अनुमति दें जिन्हें साफ़ तौर पर CORS के साथ काम करने वाले के तौर पर मार्क किया गया है. इसके लिए, क्रॉस-ऑरिजिन रिसोर्स नीति (सीओआरपी) हेडर सेट किया गया हो या crossorigin एट्रिब्यूट का इस्तेमाल किया गया हो. (Cross-Origin-Embedder-Policy)
क्रॉस-ऑरिजिन के ऐसे अनुरोधों को अनुमति न दें जिनमें सीओआरएस का इस्तेमाल नहीं किया गया है (Cross-Origin-Resource-Policy)
ब्राउज़िंग कॉन्टेक्स्ट को क्रॉस-ऑरिजिन दस्तावेज़ों से अलग करें. इससे window.opener रेफ़रंस और ग्लोबल ऑब्जेक्ट ऐक्सेस को रोका जा सकता है (Cross-Origin-Opener-Policy)
साइट को किसी फ़्रेम या iframe में एम्बेड होने से रोकना (CSP, frame-ancestors)

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: frame-ancestors 'self'

इन पाबंदियों के बावजूद, एक और संभावित हमला है जिससे IWAs सुरक्षा करते हैं: क्रम तोड़ने वाले हमले. सीक्वेंस ब्रेकिंग अटैक तब होता है, जब तीसरे पक्ष का नुकसान पहुंचाने वाला कॉन्टेंट, उपयोगकर्ताओं को भ्रमित करने और उनका फ़ायदा उठाने की कोशिश करता है. ऐसा तब होता है, जब वह किसी पेज पर अनचाहे तरीके से नेविगेट करता है. जैसे, सीधे तौर पर इंटरनल सेटिंग वाले पेज पर नेविगेट करना. आईडब्ल्यूए, बाहरी साइटों से मनमाने तरीके से डीप लिंकिंग को अनुमति नहीं देते. इसलिए, वे इस समस्या को रोकते हैं. वे सिर्फ़ उन ऐप्लिकेशन को खोलने की अनुमति देते हैं जिन्हें अच्छी तरह से तय किए गए एंट्री पॉइंट पर जाकर खोला जा सकता है. जैसे, start_url, प्रोटोकॉल हैंडलर, शेयर टारगेट या लॉन्च हैंडलर.

लॉकडाउन

पैकेजिंग और आइसोलेशन से यह पक्का किया जाता है कि क्या चलाया जा सकता है और वह कहां से आया है. हालांकि, वेब पर अनुमतियों के डाइनैमिक होने का मतलब है कि सिर्फ़ इनसे यह पक्का नहीं किया जा सकता कि कोई वेब ऐप्लिकेशन सिर्फ़ उन सुविधाओं का इस्तेमाल कर रहा है जिनकी उसे ज़रूरत है. अलग-अलग सुविधाओं के लिए सुरक्षा से जुड़ी अलग-अलग बातों का ध्यान रखना होता है. इसलिए, कोई उपयोगकर्ता या एडमिन यह ऑडिट करना चाहेगा कि कोई आईडब्ल्यूए किन अनुमतियों का इस्तेमाल कर सकता है. ठीक उसी तरह जैसे वे किसी ऐप्लिकेशन को इंस्टॉल या अपडेट करने से पहले, Android और iOS जैसे अन्य नेटिव ऐप्लिकेशन के लिए कर सकते हैं.

इसे आसान बनाने के लिए, आइसोलेटेड वेब ऐप्लिकेशन डिफ़ॉल्ट रूप से अनुमति के सभी अनुरोधों को ब्लॉक कर देते हैं. इसके बाद, डेवलपर को जिस अनुमति की ज़रूरत होती है उसके लिए ऑप्ट-इन किया जा सकता है. इसके लिए, उन्हें अपने वेब ऐप्लिकेशन मेनिफ़ेस्ट में permissions_policy फ़ील्ड जोड़ना होगा. इस फ़ील्ड में, अनुमति नीति के निर्देशों और अनुमति नीति की अनुमति वाली सूचियों के मुख्य/वैल्यू पेयर होते हैं. ये पेयर, हर उस अनुमति के लिए होते हैं जिसका अनुरोध IWA, या कोई चाइल्ड फ़्रेम कर सकता है. जैसे, कंट्रोल किए गए फ़्रेम या iframe. यहां अनुमति जोड़ने से, वह अपने-आप नहीं मिल जाती. इसके बजाय, जब उस सुविधा के लिए अनुरोध किया जाता है, तब अनुमति का अनुरोध किया जा सकता है.

उदाहरण के लिए, मान लें कि आपको फ्लीट ट्रैकिंग वाला IWA बनाना है. उपयोगकर्ता की जगह की जानकारी का अनुरोध करने के लिए, आपको अपने आईडब्ल्यूए की ज़रूरत पड़ सकती है. साथ ही, एम्बेड किए गए मैप को भी जगह की जानकारी का अनुरोध करने के लिए इसकी ज़रूरत होती है. ऐसा भी हो सकता है कि आपको एम्बेड की गई किसी साइट को फ़ुलस्क्रीन मोड में देखने की सुविधा देनी हो, ताकि उपयोगकर्ता को बेहतर अनुभव मिल सके. इसके लिए, आपको अपने वेब ऐप्लिकेशन मेनिफ़ेस्ट में अनुमति से जुड़ी यह नीति सेट अप करनी होगी:

"permissions_policy": {
   "geolocation": [ "self", "https://map.example.com" ],
   "fullscreen": [ "*" ]
}

ऐसा इसलिए है, क्योंकि WebBundle में Permissions Policy हेडर भी शामिल किए जा सकते हैं. इसलिए, दोनों में बताई गई अनुमतियों को ही अनुमति दी जाएगी. इसके बाद, दोनों में शामिल अनुमति वाली सूचियों में मौजूद ऑरिजिन को ही अनुमति दी जाएगी.

नाम दिया गया और वर्शन किया गया

सामान्य वेब ऐप्लिकेशन, उपयोगकर्ताओं को अपनी पहचान बताने के लिए अपने डोमेन नेम पर निर्भर करते हैं. साथ ही, उस डोमेन पर दिखाए जाने वाले कोड में बदलाव करके उन्हें अपडेट किया जा सकता है. हालांकि, आइसोलेटेड वेब ऐप्लिकेशन के लिए सुरक्षा से जुड़ी पाबंदियों की वजह से, पहचान और अपडेट को अलग-अलग तरीके से मैनेज करना होगा. प्रोग्रेसिव वेब ऐप्लिकेशन की तरह ही, आइसोलेटेड वेब ऐप्लिकेशन को भी वेब ऐप्लिकेशन मेनिफ़ेस्ट फ़ाइल की ज़रूरत होती है, ताकि उपयोगकर्ताओं को उनकी पहचान बताई जा सके.

वेब ऐप्लिकेशन मेनिफ़ेस्ट

आइसोलेटेड वेब ऐप्लिकेशन, पीडब्ल्यूए की तरह ही अपने वेब ऐप्लिकेशन मेनिफ़ेस्ट के लिए मेनिफ़ेस्ट की मुख्य प्रॉपर्टी शेयर करते हैं. हालांकि, इनमें कुछ मामूली अंतर होते हैं. उदाहरण के लिए, display थोड़ा अलग तरीके से काम करता है. browser और minimal-ui, दोनों को minimal-ui डिसप्ले में दिखाया जाता है. साथ ही, fullscreen और standalone, दोनों को standalone डिसप्ले में दिखाया जाता है. हालांकि, display_override के अन्य विकल्प उम्मीद के मुताबिक काम करते हैं. इसके अलावा, दो और फ़ील्ड शामिल किए जाने चाहिए, version और update_manifest_url:

version: यह आइसोलेटेड वेब ऐप्लिकेशन के लिए ज़रूरी है. यह एक स्ट्रिंग होती है, जिसमें एक या उससे ज़्यादा पूर्णांक होते हैं. इन्हें डॉट (.) से अलग किया जाता है. आपका वर्शन 1, 2, 3 वगैरह जैसा आसान या SemVer (1.2.3) जैसा मुश्किल हो सकता है. वर्शन नंबर, रेगुलर एक्सप्रेशन ^(\d+.?)*\d$ से मेल खाना चाहिए.
update_manifest_url: ज़रूरी नहीं, लेकिन यह फ़ील्ड इस्तेमाल करने का सुझाव दिया जाता है. यह एचटीटीपीएस यूआरएल (या टेस्टिंग के लिए localhost) की ओर ले जाता है. यहां से वेब ऐप्लिकेशन अपडेट मेनिफ़ेस्ट को वापस पाया जा सकता है.

आइसोलेटेड वेब ऐप्लिकेशन के लिए, छोटा सा वेब ऐप्लिकेशन मेनिफ़ेस्ट कुछ ऐसा दिख सकता है:

{
  "name": "IWA Kitchen Sink",
  "version": "0.1.0",
  "update_manifest_url": "https://example.com/updates.json",
  "start_url": "/",
  "icons": [
    {
      "src": "/images/icon.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "any"
    },
    {
      "src": "/images/icon-mask.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "maskable"
    }
  ]
}

वेब ऐप्लिकेशन के अपडेट का मेनिफ़ेस्ट

वेब ऐप्लिकेशन अपडेट मेनिफ़ेस्ट, एक JSON फ़ाइल होती है. इसमें किसी वेब ऐप्लिकेशन के हर वर्शन के बारे में जानकारी होती है. JSON ऑब्जेक्ट में एक ज़रूरी फ़ील्ड, version शामिल होता है. यह version, src, और channels वाले ऑब्जेक्ट की सूची होती है:

version - ऐप्लिकेशन का वर्शन नंबर, जो वेब ऐप्लिकेशन के मेनिफ़ेस्ट के version फ़ील्ड में मौजूद वर्शन नंबर के जैसा ही होता है
src - उस वर्शन के लिए होस्ट किए गए बंडल (.swbn फ़ाइल) की ओर ले जाने वाला एचटीटीपीएस यूआरएल (या टेस्टिंग के लिए localhost). रिलेटिव यूआरएल, वेब ऐप्लिकेशन अपडेट मेनिफ़ेस्ट फ़ाइल के हिसाब से होते हैं.
channels - यह स्ट्रिंग की एक सूची है. इससे यह पता चलता है कि यह वर्शन किस अपडेट चैनल का हिस्सा है. default चैनल का इस्तेमाल, उस मुख्य चैनल के बारे में बताने के लिए किया जाता है जिसका इस्तेमाल तब किया जाएगा, जब कोई दूसरा चैनल नहीं चुना गया होगा.

आपके पास channels फ़ील्ड शामिल करने का विकल्प भी है. यह आपके चैनल आईडी का ऑब्जेक्ट होता है. इसमें हर आईडी के लिए, name प्रॉपर्टी शामिल करना ज़रूरी नहीं है. इससे, चैनल का ऐसा नाम दिया जा सकता है जिसे आसानी से पढ़ा जा सके. इसमें default चैनल का नाम भी शामिल है. जिस चैनल में name प्रॉपर्टी शामिल नहीं होती या जिसे channels ऑब्जेक्ट में शामिल नहीं किया जाता है वह अपने आईडी का इस्तेमाल नाम के तौर पर करता है.

कम से कम जानकारी वाला अपडेट मेनिफ़ेस्ट कुछ ऐसा दिख सकता है:

{
  "versions": [
    {
      "version": "5.2.17",
      "src": "https://cdn.example.com/app-package-5.2.17.swbn",
      "channels": ["next", "5-lts", "default"]
    },
    {
      "version": "5.3.0",
      "src": "v5.3.0/package.swbn",
      "channels": ["next", "default"]
    },
    {
      "version": "5.3.1",
      "src": "v5.3.1/package.swbn",
      "channels": ["next"]
    },
  ],
  "channels": {
    "default": {
      "name": "Stable"
    },
    "5-lts": {
      "name": "5.x Long-term Stable"
    }
  }
}

इस उदाहरण में, तीन चैनल हैं: default जिसे Stable के तौर पर लेबल किया जाएगा, 5-lts जिसे 5.x Long-term Stable के तौर पर लेबल किया जाएगा, और next जिसे next के तौर पर लेबल किया जाएगा. अगर कोई उपयोगकर्ता 5-lts चैनल पर है, तो उसे वर्शन 5.2.17 मिलेगा. अगर वह default चैनल पर है, तो उसे वर्शन 5.3.0 मिलेगा. अगर वह next चैनल पर है, तो उसे वर्शन 5.3.1 मिलेगा.

वेब ऐप्लिकेशन के अपडेट मेनिफ़ेस्ट को किसी भी सर्वर पर होस्ट किया जा सकता है. अपडेट की जांच हर 4 से 6 घंटे में की जाती है.

एडमिन की ओर से मैनेज किए जाने वाले

शुरुआत में, आइसोलेटेड वेब ऐप्लिकेशन सिर्फ़ Chrome Enterprise की मदद से मैनेज किए जाने वाले Chromebook पर इंस्टॉल किए जा सकेंगे. इन्हें एडमिन, एडमिन पैनल के ज़रिए इंस्टॉल कर सकेगा.

शुरू करने के लिए, अपने एडमिन पैनल में डिवाइस > Chrome > ऐप्लिकेशन और एक्सटेंशन > उपयोगकर्ता और ब्राउज़र पर जाएं. इस टैब की मदद से, Chrome Web Store, Google Play, और वेब से ऐप्लिकेशन और एक्सटेंशन जोड़े जा सकते हैं. ये ऐप्लिकेशन और एक्सटेंशन, आपकी पूरी संस्था के उपयोगकर्ताओं के लिए उपलब्ध होते हैं. आइटम जोड़ने के लिए, स्क्रीन के सबसे नीचे दाएं कोने में मौजूद, पीले रंग के फ़्लोटिंग जोड़ें (+) बटन को खोलें. इसके बाद, जोड़ने के लिए आइटम का टाइप चुनें.

इसे खोलने पर, आपको एक स्क्वेयर के अंदर स्क्वेयर वाला आइकॉन दिखेगा. इस पर कोई आइसोलेटेड वेब ऐप्लिकेशन जोड़ें लिखा होगा. इस पर क्लिक करने से, आपको अपने ओयू में कोई आईडब्ल्यूए जोड़ने का विकल्प मिलेगा. इसके लिए, आपको दो तरह की जानकारी देनी होगी: आईडब्ल्यूए का वेब बंडल आईडी (यह आपके ऐप्लिकेशन की सार्वजनिक कुंजी से जनरेट होता है और ऐप्लिकेशन को बंडल और साइन करने के बाद दिखता है) और आईडब्ल्यूए के लिए वेब ऐप्लिकेशन अपडेट मेनिफ़ेस्ट का यूआरएल. इंस्टॉल हो जाने के बाद, इसे मैनेज करने के लिए आपको एडमिन पैनल के स्टैंडर्ड विकल्पों का सेट मिलेगा:

इंस्टॉल करने की नीति: आपको IWA को कैसे इंस्टॉल करना है. जैसे, ज़बरदस्ती इंस्टॉल करना, ज़बरदस्ती इंस्टॉल करना और ChromeOS शेल्फ़ में पिन करना या इंस्टॉल करने से रोकना.
लॉग इन करने पर लॉन्च करें: आपको IWA को कैसे लॉन्च करना है. इसके लिए, उपयोगकर्ता को मैन्युअल तरीके से लॉन्च करने की अनुमति दें, उपयोगकर्ता के लॉग इन करने पर IWA को लॉन्च करने के लिए मजबूर करें, लेकिन उसे बंद करने की अनुमति दें या उपयोगकर्ता के लॉग इन करने पर IWA को लॉन्च करने के लिए मजबूर करें और उसे बंद करने से रोकें.

सेव करने के बाद, जब उस ओयू में मौजूद Chromebook पर नीति का अपडेट लागू होगा, तब ऐप्लिकेशन इंस्टॉल हो जाएगा. इंस्टॉल होने के बाद, उपयोगकर्ता का डिवाइस हर चार से छह घंटे में, वेब ऐप्लिकेशन अपडेट मेनिफ़ेस्ट से अपडेट की जांच करेगा.

आईडब्ल्यूए को हर हाल में इंस्टॉल करने के अलावा, उनके लिए कुछ अनुमतियां अपने-आप दी जा सकती हैं. ऐसा उसी तरह से किया जा सकता है जिस तरह से अन्य वेब ऐप्लिकेशन के लिए किया जाता है. इसके लिए, डिवाइस > Chrome > वेब की सुविधाएं पर जाएं और ऑरिजिन जोड़ें बटन पर क्लिक करें. Origin / site pattern field में, IWA का वेब बंडल आईडी चिपकाएं. isolated-app:// को प्रोटोकॉल के तौर पर इसमें अपने-आप जोड़ दिया जाएगा. यहां से, अलग-अलग एपीआई के लिए ऐक्सेस लेवल सेट किए जा सकते हैं (अनुमति दी गई/ब्लॉक किया गया/सेट नहीं किया गया). इनमें विंडो मैनेजमेंट, लोकल फ़ॉन्ट मैनेजमेंट, और स्क्रीन मॉनिटरिंग एपीआई शामिल हैं. कुछ एपीआई को चालू करने के लिए, एडमिन को ऑप्ट-इन करना पड़ सकता है. जैसे, स्क्रीन मॉनिटर करने वाले ज़रूरी एपीआई के लिए. ऐसे में, आपके चुने गए विकल्प की पुष्टि करने के लिए एक और डायलॉग बॉक्स दिखेगा. बदलाव करने के बाद, उन्हें सेव करें. इसके बाद, आपके उपयोगकर्ता आईडब्ल्यूए का इस्तेमाल शुरू कर पाएंगे!

एक्सटेंशन का इस्तेमाल करना

आइसोलेटेड वेब ऐप्लिकेशन, एक्सटेंशन के साथ तुरंत काम नहीं करते. हालांकि, आपके पास अपने एक्सटेंशन को उनसे कनेक्ट करने का विकल्प होता है. इसके लिए, आपको एक्सटेंशन की मेनिफ़ेस्ट फ़ाइल में बदलाव करना होगा. मेनिफ़ेस्ट के externally_connectable सेक्शन में यह तय किया जाता है कि आपका एक्सटेंशन, किन बाहरी वेब पेजों या अन्य Chrome एक्सटेंशन के साथ इंटरैक्ट कर सकता है. externally_connectable में मौजूद matches फ़ील्ड में, अपने IWA का ऑरिजिन जोड़ें. isolated-app:// स्कीम को शामिल करना न भूलें:

{
  "externally_connectable": {
    "matches": ["isolated-app://79990854-bc9f-4319-a6f3-47686e54ed29/*"]
  }
}

इससे आपका एक्सटेंशन, आइसोलेटेड वेब ऐप्लिकेशन में चल पाएगा. हालांकि, इससे एक्सटेंशन को IWA में कॉन्टेंट डालने की अनुमति नहीं मिलेगी. एक्सटेंशन और IWA के बीच सिर्फ़ मैसेज पास किए जा सकते हैं.