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

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: ऑरिजिन ट्रायल सर्वे भेजा गया और सुझाव मिला. इस सुविधा को बंद करने के लिए, Chrome 113 तक का ट्रायल दिया गया है.
  • मार्च 2023: इस सुविधा को Chrome 116 पर बंद कर दिया गया है. साथ ही, इसे Chrome 117 में बंद कर दिया गया है. अनुमति पर आधारित अन्य तरीका पर काम चल रहा है. इसे Chrome 114 में रिलीज़ किया जाएगा.
  • मई 2023 (संभावित): अनुमति पर आधारित सुविधा, Chrome 114 में लॉन्च की जाएगी. वेबसाइटें, इस एपीआई का इस्तेमाल करके, बंद होने के ट्रायल से बाहर निकल सकती हैं.
  • सितंबर 2023: Chrome 117 को Stable के तौर पर रोल आउट किया गया. इससे, पुराना वर्शन इस्तेमाल करने की सुविधा को बंद कर दिया गया. 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 पर निजी सर्वर को ऐक्सेस कर सकते हैं.

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

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

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 बंद हो रहा है और आखिर में निजी नेटवर्क के लिए सबरिसॉर्स के अनुरोध ब्लॉक कर रहा है. इससे निजी नेटवर्क पर नेविगेट करने की प्रोसेस पर कोई असर नहीं पड़ेगा. हालांकि, सीएसआरएफ हमलों में भी इसका इस्तेमाल किया जा सकता है.

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

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