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

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

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

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

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

प्राइवेट नेटवर्क ऐक्सेस में सार्वजनिक, निजी, और लोकल नेटवर्क के बीच संबंध (सीओआरएस-आरएफ़सी1918).
प्राइवेट नेटवर्क ऐक्सेस (CORS-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

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

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

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

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

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

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

रिवर्स एम्बेडिंग

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

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

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

आगे की योजनाएं

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

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

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

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

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

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

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

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

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

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

Unsplash पर मार्कस स्पिस्क की कवर फ़ोटो