Chrome के लगभग हर वर्शन में, हमें प्रॉडक्ट, उसकी परफ़ॉर्मेंस, और वेब प्लैटफ़ॉर्म की सुविधाओं में कई अपडेट और सुधार दिखते हैं. इस लेख में, Chrome 56 में बंद किए गए और हटाए गए फ़ंक्शन के बारे में बताया गया है. यह वर्शन 8 दिसंबर से बीटा वर्शन में उपलब्ध है. इस सूची में कभी भी बदलाव किया जा सकता है.
SHA-1 सर्टिफ़िकेट के लिए सहायता हटाना
SHA-1 क्रिप्टोग्राफ़िक हैश एल्गोरिदम के कमज़ोर होने के शुरुआती संकेत, ग्यारह साल पहले मिले थे. हाल ही की रिसर्च से पता चलता है कि हमले की संभावना बहुत ज़्यादा है. इनसे वेब के पब्लिक की इंफ़्रास्ट्रक्चर (पीकेआई) की पूरी सुरक्षा पर असर पड़ सकता है.
उपयोगकर्ताओं को इस तरह के हमलों से बचाने के लिए, Chrome 56 से Chrome में SHA-1 सर्टिफ़िकेट काम नहीं करते. Chrome 56 का स्टैबल वर्शन जनवरी 2017 में रिलीज़ हुआ था. इस तरह के सर्टिफ़िकेट का इस्तेमाल करने वाली साइट पर जाने पर, उपयोगकर्ता को इंटरस्टीशियल चेतावनी दिखती है. हम Chrome Security Blog पर ज़्यादा जानकारी देते हैं.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
TLS में CBC-mode ECDSA ciphers हटाना
TLS के CBC-mode में गड़बड़ियां हैं. इस वजह से, इसे सुरक्षित तरीके से लागू करना बहुत मुश्किल है. हालांकि, आरएसए के साथ सीबीसी-मोड वाले साइफ़र का अब भी ज़्यादातर इस्तेमाल किया जाता है, लेकिन ईसीडीएसए के साथ इनका इस्तेमाल नहीं किया जाता. अन्य ब्राउज़र अब भी इन एन्क्रिप्शन प्रोटोकॉल के साथ काम करते हैं. इसलिए, हमें लगता है कि इसकी वजह से कोई खतरा नहीं है. इसके अलावा, TLS में ECDSA का इस्तेमाल कुछ ही संगठन करते हैं और आम तौर पर, ज़्यादा जटिल सेटअप के साथ (कुछ पुराने क्लाइंट सिर्फ़ RSA के साथ काम करते हैं). इसलिए, हमें उम्मीद है कि ECDSA साइटों को बेहतर तरीके से मैनेज किया जाएगा और समस्याओं के मामले में वे ज़्यादा रिस्पॉन्सिव होंगी.
TLS 1.2 में, AEADs के आधार पर नए सिफर जोड़े गए हैं. इनसे इन समस्याओं से बचा जा सकता है. खास तौर पर, AES_128_GCM, AES_256_GCM या CHACHA20_POLY1305. फ़िलहाल, हम सिर्फ़ ईसीएसडीए पर आधारित साइटों के लिए ऐसा करने का सुझाव देते हैं. हालांकि, हमारा सुझाव है कि सभी एडमिन ऐसा करें. AEAD पर आधारित सिफर, न सिर्फ़ सुरक्षा को बेहतर बनाते हैं, बल्कि परफ़ॉर्मेंस को भी बेहतर बनाते हैं. AES-GCM, हाल ही के सीपीयू पर हार्डवेयर के साथ काम करता है. साथ ही, ChaCha20-Poly1305, सॉफ़्टवेयर को तेज़ी से लागू करने की सुविधा देता है. वहीं, सीबीसी एन्क्रिप्शन के लिए, धीमी और जटिल प्रक्रियाओं की ज़रूरत होती है. साथ ही, हर आउटगोइंग रिकॉर्ड के लिए पीआरएनजी का ऐक्सेस भी ज़रूरी होता है. एएईडी पर आधारित सिफर, एचटीटीपी/2 और फ़ॉल्स स्टार्ट ऑप्टिमाइज़ेशन के लिए भी ज़रूरी हैं.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
टच स्क्रोल से उपयोगकर्ता के जेस्चर हटाना
हमें खराब तरीके से लिखे गए या नुकसान पहुंचाने वाले विज्ञापनों के कई उदाहरण मिले हैं. ये विज्ञापन, touchstart
या सभी touchend
इवेंट पर, टच स्क्रोल के लिए नेविगेशन को ट्रिगर करते हैं. अगर 'व्हील' इवेंट से पॉप-अप नहीं खुलता है, तो टच स्क्रॉल से भी नहीं खुलना चाहिए. इससे कुछ स्थितियों में समस्या आ सकती है. उदाहरण के लिए, टच करने पर मीडिया न चलना या टच करने पर पॉप-अप न खुलना. Safari पहले से ही इन सभी स्थितियों में, पॉप-अप खोलने में चुपचाप विफल रहता है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
अमान्य टाइप/भाषा एट्रिब्यूट वाली स्क्रिप्ट के लिए, सभी फ़ेच को अनुमति न दें
फ़िलहाल, Chrome का प्रीलोड स्कैनर <scripts>
एलिमेंट में आइटम फ़ेच करता है. भले ही, type
या language
एट्रिब्यूट की वैल्यू कुछ भी हो. हालांकि, पार्स करने पर स्क्रिप्ट को लागू नहीं किया जाएगा. फ़ेच को बंद करने पर, प्रीलोड स्कैनर और पार्स करने वाले टूल के सेमेंटेक्स एक जैसे होंगे. साथ ही, हम उन स्क्रिप्ट के लिए फ़ेच शुरू नहीं करेंगे जिनका इस्तेमाल नहीं किया जाएगा. इसका मकसद उन उपयोगकर्ताओं का डेटा सेव करना है जो ऐसी साइटों पर जाते हैं जिनमें कई कस्टम स्क्रिप्ट टैग होते हैं. इन टैग को पोस्ट-प्रोसेस किया जाता है. उदाहरण के लिए, type="text/template"
.
सर्वर को पिंग करने के लिए अमान्य स्क्रिप्ट का इस्तेमाल करने के उदाहरण को sendBeacon API से पूरी तरह से कवर किया गया है.
इस बदलाव से, Chrome को Safari के साथ अलाइन किया जाता है. हालांकि, Firefox अब भी स्क्रिप्ट का अनुरोध करता है, फिर चाहे वह किसी भी तरह की हो या किसी भी भाषा में हो.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
MediaStreamTrack.getSources() को हटाएं
यह तरीका अब स्पेसिफ़िकेशन का हिस्सा नहीं है और किसी भी दूसरे मुख्य ब्राउज़र पर काम नहीं करता. इसे MediaDevices.enumerateDevices()
से बदल दिया गया है. Blink, 47 वर्शन से बिना किसी फ़्लैग के इस पर काम करता है. यह सुविधा, दूसरे ब्राउज़र पर भी काम करती है. इसका उदाहरण यहां दिया गया है. यह hipotética getCameras()
फ़ंक्शन, सबसे पहले enumerateDevices()
को ढूंढने और इस्तेमाल करने के लिए, सुविधा का पता लगाने की सुविधा का इस्तेमाल करता है. अगर सुविधा की पहचान नहीं हो पाती है, तो यह MediaStreamTrack
में getSources()
खोजता है. आखिर में, अगर किसी भी तरह का एपीआई काम नहीं करता है, तो खाली cameras
कलेक्शन दिखाएं.
function getCameras(camerasCallback) {
var cameras = [];
if('enumerateDevices' in navigator.mediaDevices) {
navigator.mediaDevices.enumerateDevices()
.then(function(sources) {
return sources.filter(function(source) {
return source.kind == 'videoinput'
});
})
.then(function(sources) {
sources.forEach(function(source) {
if(source.label.indexOf('facing back') >= 0) {
// move front facing to the front.
cameras.unshift(source);
}
else {
cameras.push(source);
}
});
camerasCallback(cameras);
});
}
else if('getSources' in MediaStreamTrack) {
MediaStreamTrack.getSources(function(sources) {
for(var i = 0; i < sources.length; i++) {
var source = sources[i];
if(source.kind === 'video') {
if(source.facing === 'environment') {
// cameras facing the environment are pushed to the front of the page
cameras.unshift(source);
}
else {
cameras.push(source);
}
}
}
camerasCallback(cameras);
});
}
else {
// We can't pick the correct camera because the API doesn't support it.
camerasCallback(cameras);
}
};
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
reflected-xss CSP डायरेक्टिव हटाना
कॉन्टेंट सिक्योरिटी नीति लेवल 2 के स्पेसिफ़िकेशन के शुरुआती ड्राफ़्ट में एक reflected-xss
डायरेक्टिव था, जो अलग सिंटैक्स के अलावा, X-XSS-Protection
हेडर से ज़्यादा कुछ नहीं देता था. इस निर्देश को 2015 में स्पेसिफ़िकेशन से हटा दिया गया था. हालांकि, इसे Chrome में लागू करने से पहले हटाया नहीं गया था.
इस डायरेक्टिव के लिए सहायता अब हटा दी जा रही है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
CSP 'रेफ़रल' डायरेक्टिव को बदलना
सीएसपी referrer
डायरेक्टिव की मदद से, साइट के मालिक एचटीटीपी हेडर से रेफ़रर नीति सेट कर सकते थे. इस सुविधा का काफ़ी कम इस्तेमाल होता है. साथ ही, यह अब W3C के किसी भी स्पेसिफ़िकेशन का हिस्सा नहीं है.
जिन साइटों को अब भी इस सुविधा की ज़रूरत है उन्हें <meta name="referrer">
या Referrer-Policy हेडर का इस्तेमाल करना चाहिए.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
PaymentAddress.careOf फ़ील्ड हटाएं
PaymentAddress
इंटरफ़ेस में एक careOf
फ़ील्ड है, जो स्टैंडर्ड नहीं है. इसका इस्तेमाल, पते के किसी भी जाने-पहचाने स्टैंडर्ड के साथ नहीं किया जा सकता. careOf
फ़ील्ड भी ज़रूरी नहीं है. पाने वाले और संगठन के फ़ील्ड, इस्तेमाल के सभी ज़रूरी उदाहरणों के लिए काफ़ी हैं. careOf
जोड़ने पर, डाक पते के मौजूदा स्कीमा और एपीआई के साथ इंटरऑपरेबिलिटी के मामले में गंभीर समस्याएं आती हैं. ज़्यादा जानकारी के लिए, GitHub पर स्पेसिफ़िकेशन हटाने का प्रस्ताव पढ़ें.
हटाने का इंटेंट | Chromium में मौजूद गड़बड़ी
SVGViewElement.viewTarget को हटाना
SVGViewElement.viewTarget
एट्रिब्यूट, SVG2.0 के स्पेसिफ़िकेशन का हिस्सा नहीं है. साथ ही, इसका इस्तेमाल कम या नहीं किया जाता. इस एट्रिब्यूट का इस्तेमाल, Chrome 54 में बंद कर दिया गया था और अब इसे हटा दिया गया है.