निजी नेटवर्क ऐक्सेस से जुड़ा अपडेट: पेश है इस्तेमाल पर रोक लगाने का ट्रायल

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo
GitHub

अपडेट

  • 23 मार्च, 2023: टाइमलाइन अपडेट कर दी गई है. Chrome 117 तक, इस सुविधा का इस्तेमाल किया जा सकेगा.

  • 19 जनवरी, 2023: टाइमलाइन अपडेट कर दी गई है. Chrome 114 तक, इस सुविधा का इस्तेमाल किया जा सकेगा.

  • 12 अगस्त, 2022: टाइमलाइन अपडेट कर दी गई है. Chrome 109 तक, इसे बंद नहीं किया जाएगा.

  • 10 फ़रवरी, 2022: निजी नेटवर्क का ऐक्सेस: प्रीफ़्लाइट की सुविधा का एलान पेज पर, अपडेट किया गया लेख पब्लिश किया गया है

  • 25 अगस्त, 2021: टाइमलाइन की जानकारी को अपडेट किया गया और बंद होने से पहले आज़माने की सुविधा को लॉन्च किया गया.

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

Chrome में ये बदलाव किए जाएंगे:

  • Chrome 94 से, असुरक्षित सार्वजनिक वेबसाइटों से निजी नेटवर्क के लिए अनुरोधों को ब्लॉक किया जा रहा है.
  • बंद होने से पहले आज़माने की सुविधा का एलान किया जा रहा है. यह सुविधा Chrome में बंद हो जाएगी
    1. इससे डेवलपर, चुने गए ऑरिजिन के लिए समयसीमा बढ़ाने का अनुरोध कर पाएंगे. इस पर, बंद किए जाने की प्रोसेस के दौरान कोई असर नहीं पड़ेगा.
  • हम Chrome की एक नई नीति पेश कर रहे हैं. इसकी मदद से, मैनेज किए जा रहे Chrome डिप्लॉयमेंट को, इस्तेमाल में नहीं होने की स्थिति से हमेशा के लिए बचने में मदद मिलेगी. यह सुविधा, Chrome 92 में उपलब्ध है.

अगर आपको बंद होने के असर को कम करने के लिए ज़्यादा समय चाहिए, तो बंद होने के ट्रायल के लिए रजिस्टर करें.

अगर आपके पास अपने उपयोगकर्ताओं को एडमिन के तौर पर कंट्रोल करने की अनुमति है, तो Chrome की नीतियों का इस्तेमाल करके इस सुविधा को फिर से चालू किया जा सकता है.

नई पाबंदियों के असर को कम करने के लिए, इनमें से किसी एक रणनीति का इस्तेमाल करें:

टाइमलाइन

  • नवंबर 2020: आने वाले समय में होने वाले बदलावों के बारे में सुझाव, शिकायत या राय देने के लिए कहा गया.
  • मार्च 2021: सुझाव/राय/शिकायतों की समीक्षा करने और लोगों से संपर्क करने के बाद, आने वाले समय में होने वाले बदलावों का एलान किया गया. इस स्पेसिफ़िकेशन का नाम बदलकर, CORS-RFC1918 से निजी नेटवर्क ऐक्सेस कर दिया गया है.
  • अप्रैल 2021: Chrome 90 को स्टेबल वर्शन के तौर पर लॉन्च किया गया. साथ ही, इसमें सुविधा बंद होने की चेतावनियां दिखने की सुविधा भी जोड़ी गई.
  • जून 2021: Chrome 92 बीटा वर्शन के तौर पर लॉन्च किया गया. इसमें असुरक्षित कॉन्टेक्स्ट से निजी नेटवर्क के अनुरोधों पर रोक लगाई गई है. डेवलपर ने इस बदलाव के लिए ज़्यादा समय देने का अनुरोध किया था. इसलिए, इस सुविधा को Chrome 93 में बंद किया जाएगा. साथ ही, इस सुविधा को बंद करने से पहले, इसे आज़माने की सुविधा भी उपलब्ध कराई जाएगी.
  • जुलाई 2021: डेवलपर से मिले सुझाव/राय/शिकायत के बाद, इस सुविधा को बंद करने और इसके साथ चलने वाले ट्रायल को Chrome 94 में स्थगित कर दिया गया है. इसके अलावा, निजी वेबसाइटों पर, इस सुविधा के बंद होने का अब कोई असर नहीं पड़ेगा.
  • अगस्त 2021: Chrome 94 बीटा वर्शन के तौर पर लॉन्च किया गया. वेब डेवलपर, बंद होने से पहले आज़माने की सुविधा के लिए साइन अप करना शुरू कर सकते हैं.
  • सितंबर 2021: Chrome 94, स्टेबल वर्शन के तौर पर लॉन्च हुआ. वेब डेवलपर को, बंद होने से पहले आज़माने की सुविधा के लिए साइन अप करना चाहिए. साथ ही, प्रोडक्शन में आज़माने के लिए टोकन डिप्लॉय करने चाहिए.
  • दिसंबर 2022: Origin के ट्रायल वर्शन का सर्वे भेजा गया और सुझाव, राय या शिकायतें मिलीं. इस सुविधा को बंद करने के लिए, Chrome 113 तक का ट्रायल दिया गया है.
  • मार्च 2023: इस सुविधा को बंद करने के ट्रायल को Chrome 116 तक बढ़ा दिया गया है. साथ ही, इसे Chrome 117 में बंद कर दिया जाएगा. अनुमति पर आधारित अन्य तरीका पर काम चल रहा है. इसे Chrome 114 में रिलीज़ किया जाएगा.
  • मई 2023 (संभावित): अनुमति पर आधारित सुविधा, Chrome 114 में लॉन्च की जाएगी. वेबसाइटें, इस एपीआई का इस्तेमाल करके, बंद होने के ट्रायल से बाहर निकल सकती हैं.
  • सितंबर 2023: Chrome 117, स्टेबल वर्शन के तौर पर रोल आउट हो गया. साथ ही, इस वर्शन के साथ, 'इस्तेमाल में नहीं है' ट्रायल की सुविधा भी बंद हो गई. Chrome, सार्वजनिक और असुरक्षित कॉन्टेक्स्ट से सभी निजी नेटवर्क अनुरोधों को ब्लॉक कर देता है.

निजी नेटवर्क का ऐक्सेस क्या है

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

निजी नेटवर्क के अनुरोध ऐसे अनुरोध होते हैं जिनके टारगेट सर्वर का आईपी पता, अनुरोध शुरू करने वाले डिवाइस के आईपी पते से ज़्यादा निजी होता है. उदाहरण के लिए, किसी सार्वजनिक वेबसाइट (https://example.com) से किसी निजी वेबसाइट (http://router.local) पर किया गया अनुरोध या किसी निजी वेबसाइट से localhost पर किया गया अनुरोध.

निजी नेटवर्क ऐक्सेस (सीओआरएस-आरएफ़सी 1918) में सार्वजनिक, निजी, और लोकल नेटवर्क के बीच का संबंध.
निजी नेटवर्क का ऐक्सेस (सीओआरएस-RFC1918) में, सार्वजनिक, निजी, और लोकल नेटवर्क के बीच का संबंध.

ज़्यादा जानने के लिए, सुझाव/राय चाहिए: निजी नेटवर्क के लिए सीओआरएस (RFC1918) पर जाएं.

बंद हो चुकी सुविधा को कुछ समय के लिए इस्तेमाल करने वाला ट्रायल क्या है

इस्तेमाल में नहीं होने वाली सुविधाओं के ट्रायल (पहले इन्हें रिवर्स ऑरिजिन ट्रायल कहा जाता था), ऑरिजिन ट्रायल का एक टाइप है. इसका इस्तेमाल, वेब की सुविधाओं को आसानी से बंद करने के लिए किया जाता है. बंद होने से जुड़े ट्रायल की मदद से, Chrome कुछ वेब सुविधाओं को बंद कर सकता है. साथ ही, वेबसाइटों को उन सुविधाओं पर नई डिपेंडेंसी बनाने से रोक सकता है. साथ ही, उन वेबसाइटों को उन सुविधाओं से माइग्रेट करने के लिए ज़्यादा समय भी दे सकता है जो उन सुविधाओं पर डिपेंड करती हैं.

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

ज़्यादा जानकारी के लिए, Chrome के ऑरिजिन ट्रायल का इस्तेमाल शुरू करना लेख पढ़ें. साथ ही, निर्देशों के लिए ऑरिजिन ट्रायल के बारे में वेब डेवलपर गाइड देखें.

Chrome में क्या बदलाव हो रहे हैं

Chrome 94

Chrome 94 से, असुरक्षित सार्वजनिक कॉन्टेक्स्ट (जैसे, एचटीटीपीएस या निजी आईपी पते से डिलीवर न की गई वेबसाइटें) को निजी नेटवर्क से अनुरोध करने की अनुमति नहीं है. पहले, इसे Chrome 92 के लिए प्लान किया गया था. इसलिए, हो सकता है कि बंद होने के मैसेज में अब भी पुराने माइलस्टोन का ज़िक्र किया गया हो.

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

Chrome की नीतियों का इस्तेमाल करके, पूरी तरह से या किसी खास ऑरिजिन के लिए, 'इस्तेमाल बंद होने की सूचना' को हमेशा के लिए बंद किया जा सकता है. इससे, मैनेज किए जा रहे Chrome इंस्टॉल को ब्रेक होने से बचाया जा सकता है. उदाहरण के लिए, कॉर्पोरेट सेटिंग में मौजूद इंस्टॉल.

Chrome 117

बंद होने से पहले आज़माने की सुविधा खत्म हो जाती है. सभी वेबसाइटों को बंद की गई सुविधा से माइग्रेट कर दिया जाना चाहिए या उनकी उपयोगकर्ता नीतियों को इस सुविधा को चालू रखने के लिए कॉन्फ़िगर किया जाना चाहिए.

जिन वेबसाइटों पर असर पड़ा है उनके लिए सबसे पहला कदम यह है कि वे बंद होने से पहले आज़माने की सुविधा के लिए रजिस्टर करें या नीतियों का इस्तेमाल करें. इससे, सही तरीके से ठीक करने के लिए कुछ समय मिल पाएगा. इसके बाद, सुझाई गई कार्रवाई, समस्या वाली हर वेबसाइट के हिसाब से अलग-अलग होती है.

बंद हो चुकी सुविधा को कुछ समय के लिए इस्तेमाल करने वाले ट्रायल के लिए रजिस्टर करना

  1. रजिस्टर करें पर क्लिक करके, सुरक्षित नहीं किए गए कॉन्टेक्स्ट के ऑरिजिन से निजी नेटवर्क ऐक्सेस की सुविधा को आज़माएं. इससे, आपको ऑरिजिन के लिए, मुफ़्त में आज़माने का टोकन मिलेगा.
  2. अपने रिस्पॉन्स हेडर में, ऑरिजिन के हिसाब से Origin-Trial: $token जोड़ें. इस रिस्पॉन्स हेडर को सिर्फ़ मुख्य संसाधन और नेविगेशन रिस्पॉन्स पर तब सेट करना होगा, जब नतीजे में मिलने वाले दस्तावेज़ में, बंद की गई सुविधा का इस्तेमाल किया गया हो. सब-रिसॉर्स के रिस्पॉन्स में इस हेडर को अटैच करना बेकार है. हालांकि, इससे कोई नुकसान नहीं होता.

किसी दस्तावेज़ को कोई अनुरोध करने की अनुमति देने से पहले, इस ट्रायल को चालू या बंद करना ज़रूरी है. इसलिए, इसे <meta> टैग की मदद से चालू नहीं किया जा सकता. ऐसे टैग, रिस्पॉन्स बॉडी से सिर्फ़ तब पार्स किए जाते हैं, जब सब-रिसॉर्स के अनुरोध किए गए हों. यह उन वेबसाइटों के लिए एक समस्या है जिनके पास रिस्पॉन्स हेडर को कंट्रोल करने की सुविधा नहीं होती. जैसे, तीसरे पक्ष की github.io स्टैटिक वेबसाइटें.

ज़्यादा जानकारी के लिए, ओरिजिन ट्रायल के लिए वेब डेवलपर गाइड देखें.

नीतियां चालू करना

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

अपने उपयोगकर्ताओं के लिए नीतियां मैनेज करने के बारे में ज़्यादा जानने के लिए, सहायता केंद्र का यह लेख पढ़ें.

localhost को ऐक्सेस करना

अगर आपकी वेबसाइट को localhost को अनुरोध भेजने हैं, तो आपको सिर्फ़ अपनी वेबसाइट को एचटीटीपीएस पर अपग्रेड करना होगा.

http://localhost (या http://127.*.*.*, http://[::1]) को टारगेट करने वाले अनुरोधों को, मिक्स्ड कॉन्टेंट की वजह से ब्लॉक नहीं किया जाता. भले ही, ये अनुरोध सुरक्षित कॉन्टेक्स्ट से किए गए हों.

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

निजी आईपी पते ऐक्सेस करना

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

  • दोनों तरफ़ से एचटीटीपीएस पर अपग्रेड करें.
  • टारगेट सर्वर से सुरक्षित तरीके से कनेक्ट करने के लिए, WebTransport का इस्तेमाल करें.
  • एम्बेड करने के संबंध को उलट दें.

दोनों एंडपॉइंट को एचटीटीपीएस पर अपग्रेड करना

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

एचटीटीपीएस पर निजी वेबसाइटें दिखाने में मुख्य समस्या यह है कि सार्वजनिक कुंजी इन्फ़्रास्ट्रक्चर सर्टिफ़िकेट देने वाली संस्थाएं (पीकेआई सीए) सिर्फ़ सार्वजनिक डोमेन नेम वाली वेबसाइटों को TLS सर्टिफ़िकेट देती हैं. इस समस्या को हल करने के लिए:

  1. कोई सार्वजनिक डोमेन नेम (उदाहरण के लिए, intranet.example) रजिस्टर करें और उस डोमेन नेम को अपनी पसंद के सार्वजनिक सर्वर पर ले जाने वाले डीएनएस रिकॉर्ड पब्लिश करें.
  2. intranet.example के लिए TLS सर्टिफ़िकेट पाएं.
  3. अपने निजी नेटवर्क में, intranet.example को टारगेट सर्वर के निजी आईपी पते पर रिज़ॉल्व करने के लिए डीएनएस को कॉन्फ़िगर करें.
  4. intranet.example के लिए TLS सर्टिफ़िकेट का इस्तेमाल करने के लिए, अपने निजी सर्वर को कॉन्फ़िगर करें. इससे आपके उपयोगकर्ता, https://intranet.example पर निजी सर्वर को ऐक्सेस कर सकते हैं.

इसके बाद, अनुरोध शुरू करने वाली वेबसाइट को एचटीटीपीएस पर अपग्रेड किया जा सकता है और पहले की तरह अनुरोध किए जा सकते हैं.

यह समाधान आने वाले समय में भी काम करेगा. साथ ही, इससे आपको अपने नेटवर्क पर कम भरोसा करना पड़ेगा. ऐसा इसलिए, क्योंकि आपके निजी नेटवर्क में एंड-टू-एंड एन्क्रिप्शन का इस्तेमाल बढ़ेगा.

WebTransport

इस समाधान के लिए, आपके उपयोगकर्ताओं के डीएनएस रिज़ॉल्यूशन को कंट्रोल करने की ज़रूरत नहीं होती. इसके लिए, टारगेट सर्वर पर कम से कम वेब ट्रांसपोर्ट सर्वर (कुछ बदलावों के साथ एचटीटीपी/3 सर्वर) होना ज़रूरी है.

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

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

हमें उम्मीद है कि एचटीटीपी/3 पर WebTransport, Chrome 96 में शिप होगा. इसकी ऑरिजिन ट्रायल शुरू हो गया है. इसमें, पासकोड शेयर करने और सुरक्षा से जुड़ी अन्य खराब प्रथाओं से बचाने के लिए, कम करने वाले उपाय शामिल हैं. इनमें ये शामिल हैं:

  • पिन किए गए सर्टिफ़िकेट के लिए, समयसीमा खत्म होने का ज़्यादा से ज़्यादा समय कम होना चाहिए.
  • ब्राउज़र के हिसाब से, कुछ ऐसी कुंजियों को रद्द करने का तरीका जिनका गलत इस्तेमाल किया गया है.

WebTransport के पूरी तरह से रोल आउट होने के बाद, हम सुरक्षित कॉन्टेक्स्ट से जुड़ी पाबंदी को तब तक शिप नहीं करेंगे, जब तक कि कम से कम दो माइलस्टोन पूरे नहीं हो जाते. ज़रूरत पड़ने पर, बंद होने से पहले मुफ़्त में आज़माने की अवधि को बढ़ाया जाएगा.

वीडियो को दूसरे प्लैटफ़ॉर्म पर एम्बेड करना

इस तरीके के लिए, नेटवर्क पर एडमिन के कंट्रोल की ज़रूरत नहीं होती. साथ ही, इसका इस्तेमाल तब किया जा सकता है, जब टारगेट सर्वर एचटीटीपीएस चलाने के लिए ज़रूरत के मुताबिक न हो.

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

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

आने वाले समय के लिए प्लान

निजी नेटवर्क ऐक्सेस को लॉन्च करने के लिए, निजी नेटवर्क के अनुरोधों को सुरक्षित कॉन्टेक्स्ट तक सीमित करना सिर्फ़ पहला कदम है. Chrome, आने वाले महीनों में बाकी स्पेसिफ़िकेशन को लागू करने पर काम कर रहा है. अपडेट पाने के लिए हमारे साथ बने रहें!

निजी वेबसाइटों से localhost के ऐक्सेस पर पाबंदी लगाना

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

सीओआरएस प्रीफ़्लाइट अनुरोध

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

कम शब्दों में, सीओआरएस प्रीफ़्लाइट रिक्वेस्ट एक एचटीटीपी OPTIONS रिक्वेस्ट होता है, जिसमें कुछ Access-Control-Request-* हेडर होते हैं. इन हेडर से पता चलता है कि अगले रिक्वेस्ट का टाइप क्या है. इसके बाद, सर्वर यह तय कर सकता है कि Access-Control-Allow-* हेडर के साथ 200 OK का जवाब देकर, ज़्यादा जानकारी वाला ऐक्सेस देना है या नहीं.

इस बारे में ज़्यादा जानकारी के लिए, स्पेसिफ़िकेशन देखें.

नेविगेशन फ़ेच पर पाबंदी लगाना

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

निजी नेटवर्क के ऐक्सेस की खास जानकारी में, फ़ेच करने के दो तरीकों के बीच कोई फ़र्क़ नहीं किया जाता. इन पर एक जैसी पाबंदियां लागू होंगी.

Unsplash पर, Markus Spiske की दी गई कवर फ़ोटो