- Chrome में XSLT सपोर्ट बंद करना Google का ऐसा कदम है जो ओपन वेब की एक मुख्य तकनीक को कमजोर करता है; सुरक्षा समस्याओं का हवाला दिया गया, लेकिन कोई वैकल्पिक तकनीक दिए बिना फीचर हटा दिया गया
- Google ने ब्राउज़र के अंदर मूल फीचर की जगह JavaScript-आधारित polyfill का सुझाव दिया, लेकिन उसे ब्राउज़र में बिल्ट-इन करने के बजाय इम्प्लीमेंटेशन का बोझ डेवलपर्स पर डाल दिया
- ऐसे फैसले RSS·XML-आधारित स्वतंत्र वेब इकोसिस्टम को कमजोर करते हैं, और Mozilla व Apple भी इसी तरह की दिशा में बढ़ रहे हैं
- लेख WHATWG की आलोचना करता है कि वह अब ओपन वेब का संरक्षक नहीं रहा, बल्कि बड़ी कंपनियों के हितों के आधार पर वेब standards को नियंत्रित कर रहा है
- ब्राउज़र extensibility में कटौती और DRM standardization के कारण यूज़र कंट्रोल कमजोर वाला वेब ढांचा स्थायी होता जा रहा है, और इसके खिलाफ RSS·XSLT·JPEG XL जैसी खुली तकनीकों के निरंतर उपयोग और प्रतिरोध का आह्वान किया गया है
XSLT सपोर्ट बंद करना और Google की दिशा
- Google ने Chrome में XSLT सपोर्ट समाप्त करने का निर्णय लिया और सुरक्षा कमजोरियों को कारण बताया, लेकिन कोई वैकल्पिक लाइब्रेरी या सुधार का रास्ता पेश नहीं किया
- आलोचना यह है कि मौजूदा FLOSS लाइब्रेरी की सुरक्षा समस्याओं को बहाना बनाया गया
- यह भी कहा गया कि अधिक सुरक्षित भाषा में लिखे गए आधुनिक XSLT implementation को अपनाने का अवसर भी नहीं लिया गया
- Google द्वारा सुझाया गया JavaScript polyfill ब्राउज़र में बिल्ट-इन नहीं है, बल्कि केवल बाहरी कॉल के रूप में दिया गया है, इसलिए इसे गैर-मानक और अक्षम विकल्प माना गया
- लेख का दावा है कि यह कदम RSS और XML-आधारित स्वतंत्र वेब की नींव को कमजोर करने की एक जानबूझकर की गई कार्रवाई है
- विश्लेषण यह है कि चाहे polyfill पर्याप्त न हो, या पर्याप्त होने पर भी Google उसे बिल्ट-इन न करे, उद्देश्य XSLT के उपयोग को ही हतोत्साहित करना है
“Do. Not. Comply.” — प्रतिरोध का आह्वान
- लेखक जोर देता है कि polyfill इंस्टॉल करने या XML में बदलाव करने के लिए राजी न हों, बल्कि ब्राउज़र में XSLT सपोर्ट बहाल करने की मांग करें
- XSLT, MathML, SVG, SMIL जैसी मानक तकनीकों का उपयोग जारी रखते हुए, ब्राउज़र के गैर-मानक व्यवहार के बारे में यूज़र्स को बताने वाले warning box (infobox) को बनाए रखने की योजना है
- Google का यह फैसला तकनीकी नहीं बल्कि राजनीतिक और व्यावसायिक प्रेरणाओं से जुड़ा बताया गया है, और इसे ओपन वेब पर नियंत्रण की कोशिश का हिस्सा कहा गया है
- Mozilla और Apple भी इसी दिशा में बढ़ रहे हैं, और उन पर आरोप है कि वे ब्राउज़र को User Agent के बजाय surveillance capitalism के औज़ार की तरह डिज़ाइन कर रहे हैं
WHATWG और वेब standards का विकृतिकरण
- कहा गया है कि WHATWG शुरुआत में ओपन वेब के लिए एक समन्वय मंच था, लेकिन अब वह बड़ी कंपनियों के केंद्र वाला बंद संगठन बन गया है
- यह समूह वेब को ज्ञान-संग्रह के बजाय ‘application distribution platform’ में बदल रहा है और यूज़र कंट्रोल से ज्यादा कंपनियों के मुनाफे को प्राथमिकता दे रहा है
- ब्राउज़र अब यूज़र के प्रतिनिधि User Agent नहीं रहे, बल्कि कंपनियों के हित में काम करने वाले नियंत्रण उपकरण बन गए हैं
- लेख के अनुसार यह बदलाव W3C की ओपन वेब दृष्टि से सीधे टकराता है
नए browser war की ज़रूरत
- मौजूदा ब्राउज़र बाज़ार Google·Apple·Mozilla-केंद्रित engine निर्भर संरचना में फंसा है, जहाँ स्वतंत्र विकल्प लगभग नहीं हैं
- Vivaldi, LibreWolf, WaterFox, Pale Moon जैसे विकल्पों का उल्लेख है, लेकिन अधिकांश Blink या Gecko engine पर निर्भर हैं
- Pale Moon को उन गिने-चुने ब्राउज़रों में बताया गया है जो RSS और JPEG XL सपोर्ट बनाए हुए हैं
- लेख का तर्क है कि यूज़र बनाम कंपनियों की लड़ाई, यानी वेब पर नियंत्रण वापस लेने के लिए एक नए browser war की ज़रूरत है
वेब की एक और संभावना — Gemini और खुले protocol
- HTTP·HTML-केंद्रित वेब के अलावा Gemini protocol जैसे नए इंटरनेट स्पेस भी मौजूद हैं
- Gemini एक हल्का protocol है, जिसमें सरल संरचना और बिल्ट-इन security व authentication जैसी खूबियाँ हैं, और यह Google के प्रभाव क्षेत्र से बाहर संचालित होता है
- लेकिन ज़ोर इस बात पर है कि समस्या तकनीक नहीं बल्कि सामाजिक संरचना है, और तकनीक स्वयं अब भी उपयोगी है
- सुझाव दिया गया है कि ब्राउज़र protocol या format के आधार पर भेदभाव न करें, और Markdown·AsciiDoc·Gemtext जैसे lightweight markup formats के लिए एकीकृत सपोर्ट होना चाहिए
प्लगइन हटाना और वेब पर नियंत्रण मज़बूत करना
- पहले NPAPI plugin interface विभिन्न formats और protocols को सपोर्ट करता था, लेकिन Google ने 2013 से इसे चरणबद्ध तरीके से हटाना शुरू किया
- इससे वेब की extensibility और प्रयोगात्मक तकनीकों को अपनाने का रास्ता बंद हो गया
- plugin हटाने के बाद आए Encrypted Media Extensions(EME) पर आरोप है कि उन्होंने DRM को standardize करके W3C के openness सिद्धांतों को नुकसान पहुँचाया
- ब्राउज़र extensions को सुरक्षा के नाम पर सीमित कार्यक्षमता वाले विकल्प बना दिया गया, और खासकर Manifest V3 ने ad blocking को कमजोर किया
- विश्लेषण यह है कि इन बदलावों ने यूज़र कंट्रोल घटाया और कॉर्पोरेट नियंत्रण बढ़ाया
“A mesh of building blocks” — आदर्श वेब संरचना
- आदर्श वेब plugin-आधारित modular संरचना वाला होना चाहिए, जहाँ नए protocols, formats और scripting languages को स्वतंत्र रूप से जोड़ा जा सके
- लेख कहता है कि ऐसी संरचना होती तो RSS·SMIL·XSLT·XQuery·XHTML2 जैसी तकनीकें लगातार विकसित होती रहतीं
- लेकिन वास्तविकता में संरचना ऐसी बन गई है जहाँ Google वेब के विकास की दिशा लगभग एकाधिकार के साथ तय करता है, और इसे बदलने के लिए यूज़र-नेतृत्व वाला प्रतिरोध ज़रूरी है
Resist — प्रतिरोध की घोषणा
- “Do not comply. Resist.” के नारे के तहत, लेख निम्न कार्रवाइयों का आह्वान करता है
- RSS का उपयोग जारी रखें
- XSLT का इस्तेमाल जारी रखें
- JPEG XL को डिफ़ॉल्ट image format के रूप में अपनाएँ
- ब्राउज़र के गैर-मानक व्यवहार को ‘site error’ नहीं बल्कि ‘browser defect’ मानें
- इसे सिर्फ तकनीकी चुनाव नहीं, बल्कि ओपन वेब की रक्षा के लिए व्यावहारिक प्रतिरोध के रूप में प्रस्तुत किया गया है
Post Scriptum और प्रतिक्रियाएँ
- XSLT से जुड़े प्रोजेक्ट xslt.rip और लेखक की व्यक्तिगत साइट का परिचय दिया गया है, साथ ही XSLT से SVG बनाने के प्रयास का उल्लेख है
- Hacker News और Lobste.rs जैसी साइटों पर चर्चा हुई, लेकिन कहा गया कि कई टिप्पणियों ने XSLT के महत्व को कम करके आंका
- लेखक का ज़ोर है कि XSLT server rendering से अधिक efficient हो सकता है, खासकर छोटे पैमाने और self-hosting environments में
- निष्कर्षतः, XSLT जैसी खुली तकनीकों का लगातार उपयोग ओपन वेब के अस्तित्व के लिए एक केंद्रीय रणनीति है
3 टिप्पणियां
लोग पूछते हैं कि इसे built-in क्यों नहीं किया जाता, लेकिन उल्टा देखें तो इसे ज़बरदस्ती built-in करने की कोई खास वजह भी नहीं दिखती..
Hacker News राय
ब्राउज़र से XSLT हटाना बहुत पहले से ज़रूरी था
मैं libxslt का पूर्व maintainer रह चुका हूँ, इसलिए मुझे कुछ हद तक पता है कि इस फ़ैसले के पीछे क्या वजहें थीं
इससे भी ज़्यादा दिलचस्प बात यह है कि Chromium Rust-आधारित XML parser पर जाने की योजना बना रहा है
अभी वे xml-rs को प्राथमिकता दे रहे हैं, जो XML का केवल एक हिस्सा implement करता है
यानी, ऐसा लगता है कि Google पूरी तरह standards-compliant न होने वाला XML support चुनना चाहता है
इससे Internet Explorer 5.1 के दौर की याद आती है, जब market share के दम पर standards की अनदेखी होती थी
XHTML के HTML5 से पीछे छूटने के बाद XML से जुड़ा जटिल code स्वाभाविक रूप से गायब होता जा रहा है
Rust में ले जाकर security attack surface को कम करना एक वाजिब चुनाव है
बची हुई XML parsing को JS में polyfill या wasm से बदला जा सकता है
मैं Chrome team में काम करता हूँ, लेकिन इस काम में सीधे शामिल नहीं हूँ
पहले वेब में site operator केंद्र में होता था, और browser उसकी tool (सेवक) की तरह काम करता था
मौजूदा दिशा उस दर्शन से दूर जा रही है
XML Billion Laughs attack जैसी data explosion vulnerabilities की अनुमति देता है
संबंधित विवरण
यह दावा कि ब्राउज़र में RSS feed देखने के लिए XSLT अनिवार्य है, बढ़ा-चढ़ाकर कहा गया है
JavaScript से भी यह काफ़ी हद तक संभव है, और Google का polyfill भी ऐसे ही काम करता है
मैंने हज़ारों lines की XSLT लिखी है, लेकिन मुझे JavaScript कहीं बेहतर लगती है
XSLT को अब security के लिहाज़ से हटाया जाना चाहिए
इस पर संबंधित प्रस्तुति OffensiveCon 2025 में दी गई थी
JS में इसका विकल्प जटिल है और entry barrier ऊँचा है
साधारण personal webpage बनाना मुश्किल होने से ‘open web’ की भावना कमज़ोर होती है
RSS का गायब होना और Facebook जैसे platforms पर निर्भरता उसी का नतीजा है
Web Components दस्तावेज़ देखें
याद है कि independent browsers तेज़ी से बदलते JS ecosystem का साथ नहीं दे पाए और गायब हो गए
पुराना Konqueror याद आता है
document()function की security समस्या समझ में आती हैइसे देखकर मुझे XSLT हटाना उचित लगा
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;जैसे रूप को support करना होगा
लेकिन मौजूदा implementation में XSLT-स्तर के अनुभव को JS से पूरी तरह बदलना मुश्किल है
मैं इस बात से सहमत हूँ कि Google open web को नुकसान पहुँचा रहा है, लेकिन XSLT इसका कमज़ोर उदाहरण है
यह बहुत कम इस्तेमाल होने वाला, जटिल feature है, इसलिए यह maintenance resources कम करने का फ़ैसला लगता है
RSS/Atom feeds दिखाने के लिए browser में सीधा support feature जोड़ना बेहतर होगा
केवल usage frequency के आधार पर फ़ैसला नहीं करना चाहिए
महत्त्वपूर्ण users के साथ मिलकर इसे धीरे-धीरे phase out करना चाहिए
“open web” और XSLT का आपस में बहुत संबंध नहीं है
open web का मतलब ऐसा माहौल है जहाँ कोई भी server चला सके, site बना सके, और browser विकसित कर सके
XSLT बहुत पहले ही मर चुकी तकनीक है, और इसे हटाने से टूटने वाली sites लगभग नहीं के बराबर हैं
उल्टा security vulnerabilities हटाने का फ़ायदा है
vulnerability XSLT में नहीं, libxslt implementation में थी
कोई वैकल्पिक implementation भी बनाई जा सकती थी, लेकिन समस्या यह है कि Google ने feature को ‘मारने’ का विकल्प चुना
बस अब लोग individual sites subscribe करने के बजाय social feed-आधारित consumption को ज़्यादा पसंद करते हैं
यह तकनीकी समस्या नहीं, बल्कि user behavior में बदलाव है
XSLT के ख़ात्मे पर शिकायत करने वालों में मैंने बहुत कम लोगों को देखा है जो साफ़-साफ़ बता सकें कि वे इसे वास्तव में क्यों इस्तेमाल करते हैं
ज़्यादातर लोग इसे सिर्फ़ प्रतिरोध के प्रतीक की तरह उठाते हैं
20 साल से ज़्यादा समय तक यह उम्मीद रही कि “वेबपेज हमेशा दिखते रहेंगे”
libxslt maintainer ने security reports के बोझ के कारण इस्तीफ़ा दे दिया,
और browser vendors ने पैसे देकर maintenance कराने के बजाय feature हटाने का रास्ता चुना
इसे विद्रोह के प्रतीक की तरह इस्तेमाल करना ख़ुद को परेशान करने जैसा है
ज़रूरत पड़े तो polyfill या server-side transformation से इसे पर्याप्त रूप से बदला जा सकता है
इसका इस्तेमाल RSS/Atom feeds को पढ़ने लायक बनाने में किया जाता था
मैंने जो rss.style site बनाई है, उसमें यह फ़र्क देखा जा सकता है
Mozilla ने RSS को Google के दबाव में नहीं हटाया,
बल्कि क्योंकि users RSS नहीं चाहते थे
Google तो open web के विकास में सबसे ज़्यादा निवेश करने वाली कंपनियों में से एक है
WHATWG वेब को application platform की ओर ले जा रहा है, और यह developers तथा users दोनों की माँग का नतीजा है
Blink open source है, इसलिए उसका fork maintain करना भी संभव है
RSS आम लोगों के लिए बहुत तकनीकी था, और Google ने Reader बंद कर दिया,
जिसके बाद social media ने उसकी जगह ले ली
लेकिन अंततः monopoly structure को मज़बूत किया
Blink का open source होना अकेले असली openness की गारंटी नहीं देता
अगर उसके होने भर से नुकसान नहीं है, तो उसे हटाने की ज़रूरत नहीं
लेखक की बातों से कुछ हद तक सहमति है,
लेकिन browser को Gopher तक support करना चाहिए कहना जटिलता की अति है
Chrome project के नज़रिए से यह simplification के लिए लिया गया फ़ैसला लगता है
इसे हटाना वाजिब है, और वेब उद्योग के ज़्यादातर लोग इससे सहमत होंगे
C language-आधारित XML parsing हमेशा security के लिहाज़ से डरावनी लगती है
extension के रूप में अलग करना बेहतर है
किसी भी तरफ़ कोई न कोई नुकसान उठाएगा
मैं अपना ब्लॉग XML/XSLT में बदलने की सोच रहा हूँ
कोई पढ़ता तो है नहीं, तो अब कम traffic का दोष Chrome पर मढ़ सकूँगा
मैं Google fan नहीं हूँ, लेकिन XSLT हटना web API complexity कम करने का मौका है
Ladybird जैसे independent browsers के लिए इससे बोझ कम हो सकता है
नतीजतन यह Google की monopoly power को भी कमज़ोर कर सकता है
इसे “बिना बड़े विरोध” के आगे बढ़ता हुआ कहना मुश्किल है
पिछले 10–15 सालों में web standards का रुझान browser में खास niche requirements जोड़ने का रहा है
XSLT हटाना और polyfill देना जटिलता को browser के बाहर धकेलने वाली दिशा जैसा लगता है
2025 में XSLT को सपोर्ट करना चाहिए—इस पर लिखा लेख काफ़ी ताज़गीभरा लगा... यह सच है कि RSS वगैरह की styling में इसका थोड़ी देर के लिए इस्तेमाल होता है, लेकिन क्या इसे वास्तव में एक general-purpose उपयोग में अच्छी तरह इस्तेमाल होता हुआ माना जा सकता है?