लोकल नेटवर्क का ऐक्सेस पाने के लिए, अनुमति का नया अनुरोध

Chris Thompson

पब्लिश होने की तारीख: 9 जून, 2025

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

इस बदलाव का वेब नेटवर्क पर क्या असर पड़ेगा, यह समझने के लिए Chrome टीम, उन डेवलपर से सुझाव, शिकायत या राय मांग रही है जो उपयोगकर्ता के लोकल नेटवर्क या उपयोगकर्ता की मशीन पर स्थानीय तौर पर चलने वाले सॉफ़्टवेयर से कनेक्ट करने वाले वेब ऐप्लिकेशन बनाते हैं. Chrome 138 में, इन नई पाबंदियों के लिए ऑप्ट-इन किया जा सकता है. इसके लिए, chrome://flags/#local-network-access-check पर जाएं और फ़्लैग को "चालू है (ब्लॉक किया जा रहा है)" पर सेट करें.

लोकल नेटवर्क का ऐक्सेस क्या है?

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

Android, iOS, और MacOS जैसे कई अन्य प्लैटफ़ॉर्म के पास, लोकल नेटवर्क का ऐक्सेस करने की अनुमति होती है. उदाहरण के लिए, हो सकता है कि आपने Google TV और Chromecast के नए डिवाइसों को सेट अप करते समय, Google Home ऐप्लिकेशन को लोकल नेटवर्क ऐक्सेस करने की अनुमति दी हो.

किस तरह के अनुरोधों पर असर पड़ता है?

लोकल नेटवर्क ऐक्सेस के पहले माइलस्टोन के लिए, हम "लोकल नेटवर्क के अनुरोध" को पब्लिक नेटवर्क से लोकल नेटवर्क या लूपबैक डेस्टिनेशन पर किए गए किसी भी अनुरोध के तौर पर देखते हैं.

लोकल नेटवर्क, ऐसा कोई भी डेस्टिनेशन होता है जो आईपीवी4 में RFC1918 के सेक्शन 3 में बताए गए निजी पते के स्पेस पर रीज़ॉल्व होता है. उदाहरण के लिए, 192.168.0.0/16), IPv4 से मैप किया गया ऐसा IPv6 पता जहां मैप किया गया IPv4 पता खुद निजी हो या ::1/128, 2000::/3, और ff00::/8 सबनेट से बाहर का IPv6 पता हो.

लूपबैक, ऐसा कोई भी डेस्टिनेशन है जो आईपीवी4 के RFC1122 के सेक्शन 3.2.1.3 में बताए गए "लूपबैक" स्पेस (127.0.0.0/8), आईपीवी4 के RFC3927 में बताए गए "लिंक-लोकल" स्पेस (169.254.0.0/16), आईपीवी6 के RFC4193 के सेक्शन 3 में बताए गए "यूनीक लोकल पता" प्रीफ़िक्स (fcc00::/7) या आईपीवी6 के RFC4291 के सेक्शन 2.5.6 में बताए गए "लिंक-लोकल" प्रीफ़िक्स (fe80::/10) पर रिज़ॉल्व होता है.

सार्वजनिक नेटवर्क कोई भी अन्य डेस्टिनेशन होता है.

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

• अनुरोध का होस्टनेम, निजी आईपी लिटरल है (उदाहरण के लिए, 192.168.0.1).
• अनुरोध का होस्टनेम, .local डोमेन है.
• fetch() कॉल को targetAddressSpace: "local". विकल्प के साथ एनोटेट किया गया है

// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
  targetAddressSpace: "local",
});

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

Chrome 138

लोकल नेटवर्क ऐक्सेस की सुविधा का हमारा शुरुआती वर्शन, Chrome 138 में ऑप्ट-इन टेस्टिंग के लिए तैयार है. उपयोगकर्ता, अनुमति का नया प्रॉम्प्ट चालू कर सकते हैं. इसके लिए, chrome://flags#local-network-access-check को "चालू है (ब्लॉक किया जा रहा है)" पर सेट करें. यह, JavaScript fetch() एपीआई, सब-रिसॉर्स लोड करने, और सबफ़्रेम नेविगेशन का इस्तेमाल करके शुरू किए गए अनुरोधों के लिए, लोकल नेटवर्क ऐक्सेस की अनुमति का अनुरोध ट्रिगर करने की सुविधा देता है.

लोकल नेटवर्क के अनुरोधों के अलग-अलग फ़ॉर्म को ट्रिगर करने के लिए, एक डेमो साइट उपलब्ध है. यह साइट https://local-network-access-testing.glitch.me/ पर उपलब्ध है.

पहले से मालूम समस्याएं और सीमाएं

• फ़िलहाल, अनुमति का नया अनुरोध सिर्फ़ Chrome के डेस्कटॉप वर्शन पर लागू किया गया है. हम इसे Android Chrome पर पोर्ट करने के लिए लगातार काम कर रहे हैं. (इस समस्या को crbug.com/400455013 पर ट्रैक किया जा रहा है.)
• स्थानीय नेटवर्क से WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834), और WebRTC (crbug.com/421223919) कनेक्शन के लिए, अब तक एलएनए की अनुमति की ज़रूरत नहीं है.
• फ़िलहाल, सेवा वर्कर से लोकल नेटवर्क के अनुरोध करने के लिए ज़रूरी है कि सेवा वर्कर के ऑरिजिन को पहले ही लोकल नेटवर्क का ऐक्सेस दिया गया हो.
  • अगर आपका ऐप्लिकेशन, किसी सेवा वर्कर से लोकल नेटवर्क का अनुरोध करता है, तो अनुमति का अनुरोध ट्रिगर करने के लिए, आपको अपने ऐप्लिकेशन से अलग से लोकल नेटवर्क का अनुरोध ट्रिगर करना होगा. (हम ऐसे तरीके पर काम कर रहे हैं जिससे वर्कर्स, अनुमति का अनुरोध ट्रिगर कर सकें. ऐसा तब किया जा सकेगा, जब कोई चालू दस्तावेज़ उपलब्ध हो. ज़्यादा जानकारी के लिए, crbug.com/404887282 पर जाएं.)

Chrome 139 और उसके बाद के वर्शन

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

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

हम लोकल नेटवर्क ऐक्सेस करने की अनुमति को, उन अलग-अलग सुविधाओं के साथ इंटिग्रेट करना जारी रखेंगे जो लोकल नेटवर्क पर अनुरोध भेज सकती हैं. उदाहरण के लिए, हम जल्द ही WebSockets, WebTransport, और WebRTC कनेक्शन के लिए, लोकल नेटवर्क ऐक्सेस की सुविधा लॉन्च करने वाले हैं.

Chrome में लोकल नेटवर्क ऐक्सेस की सुविधा पूरी तरह से लॉन्च होने के करीब आने पर, हम इस बारे में ज़्यादा जानकारी शेयर करेंगे.

सुझाव, राय या शिकायत करना

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

अगर आपने ऐसी वेबसाइट बनाई है या उसका इस्तेमाल किया है जो उपयोगकर्ता के लोकल नेटवर्क या उपयोगकर्ता के मशीन पर स्थानीय तौर पर चलने वाले सॉफ़्टवेयर से कनेक्शन बनाने पर निर्भर करती है, तो Chrome टीम को आपके सुझाव/राय और इस्तेमाल के उदाहरणों में दिलचस्पी है. इस समस्या को हल करने के लिए, आपके पास ये दो विकल्प हैं:

• chrome://flags#local-network-access-check पर जाएं और फ़्लैग को "चालू है (ब्लॉक कर रही है)" पर सेट करें. साथ ही, देखें कि आपकी वेबसाइट, अनुमति के लिए नया अनुरोध सही तरीके से ट्रिगर करती है या नहीं. साथ ही, अनुमति मिलने के बाद सही तरीके से काम करती है या नहीं.
• अगर आपको कोई समस्या आती है या सुझाव/राय देनी है या शिकायत करनी है, तो Chromium के समस्या ट्रैकर पर या LNA के बारे में जानकारी देने वाले GitHub रिपॉज़िटरी पर समस्या दर्ज करें. Chrome आपकी राय जानना चाहता है.