डिज़लगेट, लेकिन ट्रेनों के लिए – कुछ भारी-भरकम हार्डवेयर हैकिंग

कथित तोड़फोड़ के तंत्र

• फ़र्मवेयर में कई लॉकआउट योजनाएँ शामिल थीं:
  • GPS-आधारित लॉजिक, जो लगभग 10 दिनों के बाद उन विशिष्ट निर्देशांकों पर ट्रेनों को निष्क्रिय कर देता था जो तीसरे पक्ष के रखरखाव डिपो के अनुरूप थे।
  • समय-आधारित लॉजिक, जो रखरखाव की तारीखों के आसपास नकली कंप्रेसर विफलताएँ ट्रिगर करता था।
  • निर्माता को ही ज्ञात छिपी हुई रीसेट अनुक्रम।
• टिप्पणीकारों का ज़ोर है कि यह अस्पष्टता/DRM से आगे बढ़कर सक्रिय रूप से झूठी विफलताएँ और गतिहीनता इंजीनियर करने जैसा है।
• कुछ संशयवादी तर्क देते हैं कि संदर्भ गायब है (पूरा कोडबेस, 20 हज़ार पन्नों का पूरा मैनुअल सेट), लेकिन अन्य लोग फ़र्मवेयर में प्रतियोगी GPS निर्देशांकों की मौजूदगी को अपने-आप में दोषसिद्ध करने वाला मानते हैं।

विक्रेता-निर्भरता और वित्तीय प्रेरणाएँ

• मज़बूत सहमति है कि उद्देश्य सस्ते प्रतियोगी के रखरखाव अनुबंध को बाधित करना और काम को वापस OEM की ओर मोड़ना था।
• रोलिंग स्टॉक का रखरखाव एक दीर्घकालिक, उच्च-मार्जिन राजस्व स्रोत (“सब्सक्रिप्शन मनी”) के रूप में वर्णित है, जो कभी-कभी शुरुआती बिक्री मूल्य से भी अधिक हो जाता है।
• कुछ लोग बताते हैं कि निविदा नियमों में स्पष्ट रूप से यह माँग थी कि ट्रेनों का रखरखाव तीसरे पक्ष द्वारा किया जा सके, जिससे छिपे हुए लॉकआउट विशेष रूप से घोर हो जाते हैं।

कानूनी, नैतिक, और ज़िम्मेदारी पर बहस

• कई लोग इसे तोड़फोड़, धोखाधड़ी, या यहाँ तक कि महत्वपूर्ण अवसंरचना में हस्तक्षेप तक कहते हैं; पोलिश दंड संहिता के रेल संचालन में बाधा डालने वाले अनुच्छेद का उल्लेख किया गया है।
• संभावित परिणामों पर असहमति:
  • कुछ लोगों को गंभीर आपराधिक मामलों और संभवतः जेल की उम्मीद है।
  • अन्य मुख्यतः नागरिक अनुबंध-उल्लंघन दावे और जुर्माने की भविष्यवाणी करते हैं, यह कहते हुए कि कॉर्पोरेट पदानुक्रम में व्यक्तियों पर इरादा थोपना कठिन है।
• इस पर चर्चा कि “ज़िम्मेदार” कौन है: व्यक्तिगत इंजीनियर, प्रबंधक, या “कंपनी समग्र रूप से,” तथा रिपॉज़, बदलाव लॉग, और आंतरिक संचार की जाँच के सुझाव दिए गए हैं।

सॉफ़्टवेयर गुणवत्ता और सुरक्षा संबंधी चिंताएँ

• आधुनिक ट्रेन फ़र्मवेयर की व्यापक आलोचना: लंबे बूट समय, दिशा बदलने पर क्रैश, और पुराने, सरल रोलिंग स्टॉक की तुलना में सामान्य अविश्वसनीयता।
• सुझाए गए मूल कारण:
  • प्रबंधन संस्कृतियाँ जो सॉफ़्टवेयर को बाद की चीज़ मानती हैं।
  • कम वेतन, कम उपकरणों वाले एम्बेडेड/PLC प्रोग्रामिंग अभ्यास।
  • बढ़ती जटिलता और प्रणालियों व बेड़ों के बीच खराब इंटरऑपरेबिलिटी।
• कुछ का तर्क है कि पहले से यांत्रिक प्रणालियों में सॉफ़्टवेयर जोड़ने से अक्सर विश्वसनीयता और रखरखाव-योग्यता घट जाती है।

ओपन सोर्स, पारदर्शिता, और विनियमन

• कई लोग इसे “मरम्मत का अधिकार” और पारदर्शिता की विफलता के रूप में देखते हैं।
• प्रस्ताव:
  • सार्वजनिक-अवसंरचना प्रणालियों के लिए स्रोत या कम-से-कम बाइनरी एस्क्रो अनिवार्य करना।
  • सरकार या स्वतंत्र निकायों द्वारा पुनरुत्पादनीय बिल्ड्स के साथ फ़र्मवेयर संकलित करना और तैनात बाइनरीज़ का सत्यापन करना।
  • सार्वजनिक रोलिंग स्टॉक के अनुबंधों में पूर्ण कोड पहुँच और टूलिंग शामिल करना।
• प्रतिवाद: दुर्भावनापूर्ण OEM फिर भी सबमिट किए गए कोड से अलग कोड भेज सकते हैं, लेकिन पारदर्शिता को एक मज़बूत निवारक माना जाता है।

अन्य मामलों से तुलना

• तुलना की गई:
  • Dieselgate (छिपा हुआ, संदर्भ-निर्भर फ़र्मवेयर व्यवहार)।
  • John Deere/Apple DRM और मरम्मत लॉकआउट (लेकिन यहाँ नकली विफलताओं और सुरक्षा-महत्वपूर्ण अवसंरचना के साथ)।
  • Boeing 737 MAX (प्रबंधन-प्रेरित सॉफ़्टवेयर कदाचार)।
• कई लोग तर्क देते हैं कि Deere-शैली की विक्रेता-निर्भरता उत्सर्जन-धोखाधड़ी की तुलना में अधिक नज़दीकी समानता है।

पोलिश और प्रणालीगत संदर्भ

• यह निराशा कि पोलिश नियामक कार्रवाई करने में धीमे थे; कुछ लोग इसे स्थानीय भ्रष्टाचार या नियामकीय कब्ज़े का प्रमाण मानते हैं।
• अन्य इसे वैश्विक संदर्भ में रखते हैं: पश्चिम अभी भी तुलनात्मक रूप से कम भ्रष्ट है, लेकिन निजी-क्षेत्र के घोटाले अक्सर शास्त्रीय भ्रष्टाचार सूचकांकों से बाहर रह जाते हैं।