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

Chris Thompson

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

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

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

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

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

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

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

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

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

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

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

पब्लिक नेटवर्क कोई दूसरा डेस्टिनेशन होता है.

लोकल नेटवर्क ऐक्सेस करने की अनुमति सिर्फ़ सुरक्षित कॉन्टेक्स्ट के लिए होती है. साथ ही, लोकल नेटवर्क डिवाइसों को एचटीटीपीएस पर माइग्रेट करना मुश्किल हो सकता है. इसलिए, अनुमति वाले लोकल नेटवर्क के अनुरोधों को अब मिक्स कॉन्टेंट की जांच से छूट दी जाएगी. अगर 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() API, सब-रिसोर्स लोडिंग, और सबफ़्रेम नेविगेशन का इस्तेमाल करके शुरू किए गए अनुरोधों के लिए, लोकल नेटवर्क ऐक्सेस करने की अनुमति मांगने वाले प्रॉम्प्ट को ट्रिगर करने में मदद मिलती है.

अलग-अलग तरह के लोकल नेटवर्क अनुरोध ट्रिगर करने के लिए, एक डेमो साइट उपलब्ध है.इसका यूआरएल यह है: https://lna-testing.notyetsecure.com/

आम तौर पर होने वाली समस्याएं और सीमाएं

• लोकल नेटवर्क से 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 Issue Tracker पर समस्या की जानकारी दें या LNA स्पेसिफ़िकेशन GitHub रिपॉज़िटरी पर जाएं. Chrome आपकी राय जानना चाहता है.