Chrome 95 का बीटा वर्शन 23 सितंबर, 2021 को रिलीज़ किया गया था. उम्मीद है कि अक्टूबर 2021 के आखिर तक यह स्टेबल वर्शन बन जाएगा.
फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) का इस्तेमाल नहीं किया जा सकता
Chrome, फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) यूआरएल के लिए सहायता हटा रहा है. ब्राउज़र में एफ़टीपी का इस्तेमाल काफ़ी कम है. इसलिए, मौजूदा एफ़टीपी क्लाइंट को बेहतर बनाने के लिए अब इसका इस्तेमाल नहीं किया जा सकता. इसके अलावा, जिन प्लैटफ़ॉर्म पर असर हुआ है उन सभी पर ज़्यादा काम के एफ़टीपी क्लाइंट उपलब्ध हैं.
Google Chrome 72 और इसके बाद के वर्शन ने फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) पर दस्तावेज़ के सबरिसॉर्स को फ़ेच करने और टॉप लेवल के एफ़टीपी संसाधनों को रेंडर करने की सुविधा हटा दी है. फ़िलहाल, फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) यूआरएल पर जाने पर, संसाधन के टाइप के मुताबिक डायरेक्ट्री लिस्टिंग या डाउनलोड दिखता है. Google Chrome 74 और उसके बाद के वर्शन में एक गड़बड़ी की वजह से, एचटीटीपी प्रॉक्सी पर एफ़टीपी यूआरएल ऐक्सेस करने की सुविधा बंद हो गई थी. Google Chrome 76 में एफ़टीपी के लिए प्रॉक्सी सहायता पूरी तरह से हटा दी गई है. Chrome 86 में, रिलीज़ से पहले वाले चैनलों (कैनरी और बीटा) के लिए, फ़ाइल ट्रांसफ़र प्रोटोकॉल (एफ़टीपी) सपोर्ट बंद कर दिया गया था. साथ ही, यह सुविधा प्रयोग के तौर पर एक प्रतिशत स्टेबल उपयोगकर्ताओं के लिए बंद कर दी गई थी. हालांकि, इसे कमांड लाइन के ज़रिए फिर से चालू किया जा सकता था. Chrome 87 में, यह 50 प्रतिशत उपयोगकर्ताओं के लिए बंद किया गया था. हालांकि, इसे कमांड लाइन के ज़रिए भी चालू किया जा सकता है. Chrome 88 के बाद से, यह सिर्फ़ बंद करने के ट्रायल के दौरान ही उपलब्ध था और अब बंद कर दिया गया है.
ऐसे यूआरएल के लिए सहायता जिनके आखिर में नंबरों के साथ, बिना IPv4 होस्टनेम हैं
ऐसे ज़्यादातर होस्टनेम जो मान्य IPv4 पते नहीं होते, लेकिन संख्याओं पर खत्म होते हैं, उन्हें मान्य माना जाता है और डीएनएस के ज़रिए खोजा जाता है (उदाहरण के लिए, http://foo.127.1/). सार्वजनिक सफ़िक्स सूची की खास जानकारी के मुताबिक, उस यूआरएल में होस्टनेम का eTLD+1 127.1 होना चाहिए. अगर
ऐसे शब्दों को किसी यूआरएल में फिर से डाला जाता है, तो यूआरएल स्पेसिफ़िकेशन में
http://127.1/ को http://127.0.0.1/ पर मैप किया जाता है. यह जानकारी काफ़ी खतरनाक हो सकती है.
127.0.0.0.1 का इस्तेमाल, उपयोगकर्ताओं को भ्रम में डालने के लिए भी किया जा सकता है.
इन होस्टनेम वाले यूआरएल अब अस्वीकार कर दिए गए हैं.
WebAssembly का क्रॉस-ऑरिजिन मॉड्यूल शेयर करना
Chrome, अब क्रॉस-ऑरिजिन के बीच WebAssembly मॉड्यूल शेयर करने को बंद कर देता है. हालांकि, एक जैसी साइट के लिए, एजेंट क्लस्टर को लंबे समय तक ऑरिजिन के दायरे में रखने की अनुमति दी जा सकेगी.
U2F API (क्रिप्टोटोकन) का इस्तेमाल बंद करें
सुरक्षा कुंजियों के साथ इंटरैक्ट करने के लिए, Chrome का लेगसी U2F एपीआई अब सेवा में नहीं है. यह Chrome 98 में डिफ़ॉल्ट रूप से बंद रहेगी.
जिन साइटों पर इस समस्या का असर हुआ है उन्हें वेब की पुष्टि करने वाले एपीआई पर माइग्रेट करना चाहिए. मूल रूप से U2F API के ज़रिए रजिस्टर किए गए क्रेडेंशियल को वेब की पुष्टि करके चुनौती दी जा सकती है. U2F API के साथ काम करने वाली यूएसबी सुरक्षा कुंजियां, Web Authentication API के साथ काम करती हैं. U2F सुरक्षा कुंजियां अब काम नहीं करतीं और ये काम करती रहेंगी.
U2F, Chrome की मूल सुरक्षा कुंजी एपीआई है. इससे साइटों को यूएसबी सुरक्षा कुंजियों पर सार्वजनिक कुंजी के क्रेडेंशियल रजिस्टर करने मिलते हैं. साथ ही, उन्हें फ़िशिंग से बचने वाले, दो तरीकों से पुष्टि करने वाले सिस्टम बनाने के लिए चुनौती दी जाती है. U2F कभी भी ओपन वेब स्टैंडर्ड नहीं बना और इसे Web Authentication API (Chrome67 में लॉन्च किया गया) में शामिल कर लिया गया. Chrome ने सीधे तौर पर FIDO U2F JavaScript API के साथ काम नहीं किया. इसके बजाय, Chrome ने क्रिप्टो टोकन नाम का एक कॉम्पोनेंट एक्सटेंशन भेजा. यह एक्सटेंशन, chrome.runtime.sendMessage() के जैसा ही एक तरीका दिखाता है. U2F और Realtimetoken लगातार रखरखाव मोड में हैं और हम पिछले दो सालों से साइटों को Web
Authentication API पर माइग्रेट करने के लिए बढ़ावा दे रहे हैं.
फ़िलहाल, इसे हटाने और बंद करने की यह टाइमलाइन तय की गई है:
Chrome 95
यह डेटा 23 सितंबर, 2021 तक का है. ये बदलाव किए गए हैं:
- हर अनुरोध के लिए, DevTools कंसोल में बंद होने की सूचना लॉग की गई.
Chrome 96
अक्टूबर 2021 के आखिर में बीटा वर्शन का इस्तेमाल किया जा सकता है और नवंबर में इसमें बदलाव आता रहेगा. ये बदलाव किए गए हैं:
- उपयोगकर्ता की अनुमति के अनुरोध के पीछे, Gated U2F API का अनुरोध.
अनुमति के प्रॉम्प्ट को, U2FSecurityKeyAPI के बंद होने के ट्रायल में रजिस्टर करके या U2fSecurityKeyApiEnabled एंटरप्राइज़ नीति को चालू करके हटाया जा सकता है.
Chrome 98
जनवरी 2022 की शुरुआत में बीटा वर्शन का इस्तेमाल किया जा सकता है और फ़रवरी में स्थिर. U2F API को डिफ़ॉल्ट रूप से बंद कर दिया जाएगा. इस स्थिति में सिर्फ़ ऐसी साइटें ही U2F का इस्तेमाल कर सकेंगी जिन्होंने रोक लगाने वाले ट्रायल में रजिस्टर की गई साइटें या U2fSecurityKeyApiEnabled नीति को चालू किया है.
Chrome 103
मई 2022 के आखिर में बीटा वर्शन का इस्तेमाल किया जा सकता है, लेकिन जून के आखिर तक इसमें बदलाव आता रहेगा. इस सुविधा को बंद करने की सुविधा 26 जुलाई, 2022 को खत्म हो जाएगी.
Chrome 104
जून 2022 के आखिर में बीटा वर्शन का इस्तेमाल किया जा सकता है, लेकिन अगस्त की शुरुआत में इसमें बदलाव आता रहेगा. U2F एपीआई को पूरी तरह से हटा दिया जाएगा.
रोकने की नीति
प्लैटफ़ॉर्म को बेहतर बनाए रखने के लिए, हम कभी-कभी उस वेब प्लैटफ़ॉर्म से एपीआई हटा देते हैं जो अपना कोर्स चला चुका है. किसी एपीआई को हटाने की कई वजहें हो सकती हैं, जैसे:
- इन्हें नए एपीआई ने हटा दिया है.
- उन्हें खास जानकारी में बदलाव दिखाने के लिए अपडेट किया जाता है, ताकि वे दूसरे ब्राउज़र के साथ अलाइन हो सकें और एक तरह से बने रहें.
- ये ऐसे शुरुआती प्रयोग हैं जो अन्य ब्राउज़र पर कभी काम नहीं आए. इससे वेब डेवलपर पर सहायता का बोझ बढ़ सकता है.
इनमें से कुछ बदलावों का असर कुछ ही साइटों पर पड़ेगा. समस्याओं को पहले ही कम करने के लिए, हम डेवलपर को पहले से सूचना देने की कोशिश करते हैं, ताकि वे अपनी साइटों को चालू रखने के लिए ज़रूरी बदलाव कर सकें.
फ़िलहाल, Chrome में एपीआई को बंद करने और उन्हें हटाने की प्रोसेस चल रही है. यह प्रोसेस ज़रूरी है:
- blink-dev मेलिंग सूची में सूचना दें.
- पेज पर इस्तेमाल का पता चलने पर, Chrome DevTools कंसोल में चेतावनियां सेट करें और टाइम स्केल दें.
- इंतज़ार करें, निगरानी करें और फिर इस्तेमाल में गिरावट आने पर इसे हटा दें.
हटाए गए फ़िल्टर को लागू करके, अब काम न करने वाले फ़िल्टर और हटाई गई सुविधाओं का इस्तेमाल करके, chromestatus.com पर काम न करने वाली सभी सुविधाओं की सूची देखी जा सकती है. हम इन पोस्ट में कुछ बदलावों, तर्क, और माइग्रेशन पाथ के बारे में खास जानकारी देने की कोशिश भी करेंगे.