ट्रेनों वाला ‘Dieselgate’ मामला – हेवीवेट हार्डवेयर हैकिंग

 (badcyber.com)
4 पॉइंट द्वारा GN⁺ 2023-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पोलैंड की Newag की Impuls 45WE ट्रेनों ने स्वतंत्र maintenance के बाद diagnostics सामान्य होने के बावजूद चलना शुरू नहीं किया, और maintenance firm SPS ने Dragon Sector से onboard computer की reverse engineering करने को कहा
  • शोधकर्ताओं ने CAN bus analysis, TriCore-आधारित memory dump, और Ghidra में सुधार के बाद software के अंदर मौजूद lock flags और startup conditions खोजीं और ट्रेनों को फिर से चलाया
  • कुछ ट्रेन code में ऐसी conditions थीं जो किसी खास maintenance depot के GPS coordinates पर 10 दिन से अधिक रहने पर startup रोकती थीं, parts replacement lock, 10 लाख km के बाद failure condition, और date-based compressor failure report condition शामिल थीं
  • analysis का दायरा कुल 29 ट्रेनों तक था, और 5 को छोड़कर बाकी ट्रेनों में official operating instructions से बाहर की “surprises” मिलीं; समस्या Wrocław, Opole, Krakow, Szczecin, Warsaw समेत कई क्षेत्रों में फैल गई
  • मामला lawsuits और law enforcement जांच तक पहुंचा, लेकिन consumer/competition protection authority या railway transport authority की कोई ठोस कार्रवाई पुष्टि नहीं हुई

maintenance के बाद रुकी Newag Impuls ट्रेनें

  • मामला 2022 की वसंत में शुरू हुआ, जब Lower Silesian Railways द्वारा संचालित Newag निर्मित Impuls 45WE की 11 ट्रेनों में पहली ट्रेन 10 लाख km की mandatory maintenance पूरी करने के बाद चल नहीं पाई
  • maintenance स्वतंत्र maintenance firm Serwis Pojazdów Szynowych(SPS) ने संभाली
    • Newag ने भी tender में भाग लिया था, लेकिन manufacturer का proposal करीब 750,000 डॉलर महंगा था
    • SPS ने 11 ट्रेनों की maintenance करीब 5.5 मिलियन डॉलर में करने की शर्त पर tender जीता
  • SPS ने manufacturer द्वारा दिए गए लगभग 20,000 pages के maintenance manual के अनुसार ट्रेन को disassemble, inspect और assemble किया, लेकिन onboard computer के normal दिखाने के बावजूद ट्रेन चली नहीं
  • inverter motor को voltage supply नहीं कर रहा था, और maintenance technicians manual तथा electrical/mechanical checks से वजह नहीं खोज पाए

बार-बार रुकना और बढ़ता contract risk

  • दूसरी ट्रेन भी उसी maintenance के बाद उसी तरह रुक गई, और manufacturer Newag ने मदद से इनकार कर दिया
  • तीसरी ट्रेन battery problem की वजह से inspection से छूट गई, और चौथी ट्रेन की जगह maintenance shop में आई
    • जब चौथी, सामान्य रूप से चल रही ट्रेन को रुकी हुई ट्रेन से जोड़ा गया, तो सामान्य ट्रेन भी रुक गई
    • इसका कारण अभी तक confirm नहीं हुआ है
  • Szczecin की दूसरी maintenance shop में भी maintenance के बाद Impuls ट्रेन के startup न होने के मामले सामने आए
  • Lower Silesian Railway की 6 लंबी trainsets हटने से timetable कटौती, replacement trains की तैनाती, और छोटी trainsets में भीड़ बढ़ी
  • Newag ने बताया कि ट्रेन “safety system” से blocked थी, लेकिन 20,000-page manual में उस system का कोई उल्लेख नहीं था
  • maintenance shop में रुकी हर ट्रेन पर प्रति दिन 1,000 डॉलर से अधिक की contractual penalty लग रही थी, जिससे SPS पर बोझ बढ़ता गया

Dragon Sector की reverse engineering

  • SPS ने “Polish hackers” search करके CTF के लिए मशहूर Dragon Sector को खोजा, और दोनों पक्षों ने contract किया
  • project में Michał “Redford” Kowalczyk, Sergiusz “q3k” Bazański, और Kuba “PanKleszcz” Stępniewicz शामिल हुए
    • Redford और q3k Toshiba laptops hacking के लिए जाने जाते हैं
    • Kuba के पास industrial automation का अनुभव था
  • site पर researchers को न चलने वाली ट्रेन, 2 spare computers, और computer manufacturer की SDK files मिलीं
  • शुरुआती analysis CAN bus को tap करने के तरीके से शुरू हुआ, लेकिन protocol documentation न होने के कारण traffic interpret करना मुश्किल था
  • SDK सिर्फ नया software upload support करता था, existing software dump करने की सुविधा नहीं थी
    • मिली हुई पुरानी software version को पहले spare computer पर डालने पर वह computer respond करना बंद कर गया
    • researchers ने बचे हुए 1 spare computer के साथ काम जारी रखा
  • आखिरकार उन्होंने debugging interface खोजकर device memory को byte-by-byte download किया
  • onboard computer TriCore architecture पर आधारित था, जो automotive field में भी इस्तेमाल होता है; अच्छे disassembler की कमी के कारण उन्होंने code analyze करने के लिए Ghidra में कुछ improvements किए

deadline से ठीक पहले मिली startup condition

  • लगभग डेढ़ महीने बाद Lower Silesian Railway अब और इंतजार नहीं कर सकती थी, इसलिए उसने Newag के साथ खराब ट्रेन की repair और maintenance collaboration का फैसला किया
  • SPS के साथ contract termination 1 सप्ताह बाद expected था, और researchers को बचे समय में results दिखाने थे
  • researchers ने normal train और failed train के computer memory images की तुलना की
    • हर ट्रेन में feature set और software version अलग थे, इसलिए simple comparison कठिन था
    • उन्हें कुछ ट्रेनों में set value और दूसरी ट्रेनों में 0 value का फर्क मिला
  • computer को ट्रेन से अलग करने पर भी उसे कुछ देर run करके inverter readiness status check किया जा सकता था, इसलिए bench testing संभव थी
  • deadline से एक दिन से भी कम समय पहले उन्हें ऐसी flag configuration मिली जिससे ट्रेन चलने की संभावना थी, लेकिन experiment के दौरान आखिरी normal onboard computer का capacitor जल गया
  • damaged 2 computers को combine करने की कोशिशों के बाद उन्होंने जले हुए computer को repair किया और रात 2 बजे उसे train startup के लिए set किया
  • researcher वह computer लेकर maintenance shop गया, लेकिन train delay हो गई, और site पर पहुंचकर connect किए गए computer से भी शुरुआत में ट्रेन start नहीं हुई
  • आगे की चर्चा के बाद उन्होंने एक missing flag खोजा और सुबह 8:42 बजे train startup में सफलता पाई
  • सुबह 9:30 बजे Lower Silesian Railway delegation ने ट्रेन के फिर से चलने की संभावना confirm की, और SPS के साथ contract terminate नहीं किया

code में छिपी lock conditions

  • कई महीनों की analysis और reverse engineering से Newag द्वारा supplied कई train software में अचानक operation failure पैदा करने वाली conditions मिलीं
  • code में मौजूद 53.13845, 17.99011 जैसे numbers GPS coordinates थे, और Bydgoszcz Główny Railway Station के पास PESA site की ओर इशारा करते थे
  • बाद में पोलैंड के अन्य maintenance/repair-capable depots के coordinates भी मिले
  • code में condition थी कि अगर ट्रेन किसी खास maintenance depot zone में से एक में कम से कम 10 दिन रहे, तो उसकी startup capability disable कर दी जाए
    • coordinates में से एक Newag की अपनी maintenance shop का था
    • Newag maintenance shop coordinates के लिए अलग logical condition defined थी, और अनुमान है कि यह testing purpose के लिए रही होगी
  • दूसरी ट्रेनों में अलग lock conditions भी मिलीं
    • कोई खास part replace होने पर part serial number check के जरिए ट्रेन को block किया जाता था
    • driver cab और onboard computer screen पर specific button sequence दबाकर lock release करने का option था
    • Impuls startup success की खबर media में आने के बाद, ट्रेनों को इस “fix” option को हटाने वाला software update मिला
    • एक और ट्रेन में 10 लाख km के बाद “fail” होने का निर्देश देने वाला code मिला

date condition से हुई compressor failure report

  • एक और ट्रेन ने 21 November 2022 को, maintenance में न होने के बावजूद, operate करने से इनकार कर दिया
  • computer ने compressor failure report किया, लेकिन mechanics को compressor में कोई समस्या नहीं लगी
  • code analysis में यह condition मिली
    • day 21 या उससे अधिक हो
    • month 11 या उससे अधिक हो
    • year 2021 या उससे अधिक हो
    • तो compressor failure report करें
  • यह ट्रेन मूल रूप से November 2021 में maintenance के लिए scheduled थी, लेकिन असल में उससे पहले ही maintenance में गई और January 2022 में ही वापस आई
  • November 2021 में condition संयोग से trigger नहीं हुई, और 21 November 2022 आने पर ही scheduled failure condition पूरी हुई

hardware में मिला GSM-connected device

  • सिर्फ software में नहीं, hardware में भी एक असामान्य device मिला
  • एक trainset में researchers को “UDP<->CAN converter” लिखा हुआ device मिला
    • यह ऐसा device लगता था जो remote तरीके से ट्रेन के साथ communication कर सकता था
    • device हटाने पर कोई function बंद नहीं हुआ
  • onboard computer lock state information इस device को भेज रहा था, और device खुद GSM modem से connected था

कई क्षेत्रों में फैली समस्या और analysis scale

  • SPS द्वारा Newag की “failed” trains ठीक करने की खबर दूसरी companies तक भी पहुंची, और पता चला कि ऐसी problems आम थीं
  • Wrocław में 13 Impuls trains analyze की गईं
  • अन्य क्षेत्रों में भी problem वाली trains confirm हुईं
    • Kolej Mazowieckie 1
    • Opole 2
    • Krakow 4
    • Zielona Góra 1
    • Szczecin 4
    • Warsaw 1
  • researchers द्वारा बनाया गया tool onboard computer का software lock हटाता था, और हर ट्रेन repair की जा सकी
  • कुल 29 trains के software analyze किए गए, और उनमें से 5 को छोड़कर बाकी में official operating instructions से बाहर के elements मिले

follow-up actions और public disclosure का दायरा

  • इस मामले में lawsuit चल रहा है
  • Poland के Office of Consumer and Competition Protection या Railway Transport Office ने कोई ठोस कार्रवाई की या नहीं, यह ज्ञात नहीं है
  • researchers ने findings की जानकारी CERT Polska को दी
    • CERT Polska ने “relevant authorities” को notify किया
    • मामला law enforcement agencies संभाल रही हैं
  • यह सामग्री 5 December 2023 को Oh My H@ck conference में Jakub Stępniewicz, Sergiusz Bazański, और Michał Kowalczyk द्वारा present की गई बातों का संक्षिप्त summary है
  • original text ने पूरे technical analysis का बड़ा हिस्सा छोड़ दिया, और कहा कि उम्मीद है researchers एक अलग technical document लिखकर publish करेंगे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-09
Hacker News की राय

  • इससे जुड़ी एक ताज़ा पोस्ट भी है: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - दिसंबर 2023, 347 टिप्पणियां

  • इतना बेशर्म होना समझ से बाहर है। ऐसा code जो GPS coordinates को किसी प्रतिस्पर्धी maintenance company के इलाके में 10 दिन से ज़्यादा ठहरे देखे तो locomotive को brick बना दे
    यह undocumented interfaces या cryptographically signed firmware जैसे repair को मुश्किल बनाने के स्तर से बहुत आगे है; मुझे यह दुर्भावनापूर्ण संपत्ति-नष्ट करने जैसा लगता है। पोलैंड की कानूनी व्यवस्था मुझे नहीं पता, लेकिन कल्पना नहीं कर सकता कि यह कैसे बच सकता है

    • हितों के टकराव की वजह से कानूनी नरक में फंसने की काफ़ी संभावना है
      trains पहले से मौजूद हैं और चलनी चाहिए, लेकिन maintenance/repair company copyright की वजह से software को कानूनी तौर पर modify नहीं कर सकती। पूरी तरह Catch-22 है। उम्मीद है उस company पर भारी fines लगेंगे और criminal punishment भी होगा, लेकिन सच में ऐसा होगा या नहीं, इस पर शक है
    • अगर कोई व्यक्ति ऐसा करता तो जेल चला जाता
    • यह संपत्ति-नष्ट करने से ज़्यादा, पैसे कमाने के लिए किसी malicious actor द्वारा किया गया denial-of-service attack लगता है
      कोई motivated legal team शायद लागू होने वाले गंभीर आरोप ढूंढ सकेगी। खासकर अगर वह train या locomotive critical infrastructure में आती हो, हालांकि यह guaranteed नहीं है

  • कोई secret handshake डालना और procedure documents को खराब बनाकर competitor को अक्षम दिखाना एक बात है, और competitor के workshop में जाने पर अपने product को जानबूझकर खराब कर देना बिल्कुल अलग स्तर की बात है

  • title थोड़ा misleading है। इस मामले का “gate” Dieselgate की तरह artificial conditions में certification पास करने के लिए eco-friendliness के बारे में धोखा देना नहीं था, बल्कि fake fault simulate करना था
    company ने location information के आधार पर अगर यह माना कि किसी दूसरी company ने train repair की है, तो compressor जैसे ठीक से काम कर रहे parts में fault आया है ऐसा report करके train operation रोक देने वाला algorithm hardcode किया था

    • industrial logic controller को decompile करके सामने आया fraudulent और malicious conduct है, और illegality को support करने वाला ऐसा evidence है जिसे rebut करना मुश्किल है
      बेशक दोनों cases पूरी तरह समान नहीं हो सकते, लेकिन यह analogy क्यों आई, यह साफ़ दिखता है
    • मेरी समझ में वह explanation सही नहीं है। यहां वास्तव में दो अलग-अलग actions हैं
      एक, GPS के आधार पर competitor maintenance site पर 10 दिन रहने के बाद train को काम न करने लायक बना देना। दूसरा, किसी खास firmware में अगले scheduled maintenance के कुछ दिनों बाद compressor fault होने जैसा दिखाने के लिए hardcode करना

  • “पोलैंड में इस मामले पर शिष्ट रुचि जताने से आगे बढ़ी कोई agency ढूंढना मुश्किल है। यह भी पता नहीं कि consumer and competition protection office या railway transport office ने कोई कदम उठाया है या नहीं” वाला हिस्सा सबसे खराब है

    • अब government anti-corruption agency ने official investigation शुरू कर दी है, इसलिए लगभग पक्का लगता है कि कोई न कोई जेल जाएगा
      consumer protection agencies के पास इन agencies जितनी शक्ति नहीं होती
    • अगर companies देखती हैं कि ऐसे conduct पर सज़ा नहीं मिलती, तो competitiveness बनाए रखने के लिए आखिरकार हर company को अपना-अपना version implement करना पड़ेगा

  • related article की पिछली post की चर्चा भी देखने लायक है: https://news.ycombinator.com/item?id=38530885

  • emissions test में manipulation, third-party repairs को रोकने जैसी अजीब engine control समस्याओं का हल शायद ऐसे systems की interface standardization हो सकता है
    अगर sensor outputs standardized हों, तो अलग-अलग components बदलकर यह जांचा जा सकता है कि system regulators को धोखा तो नहीं दे रहा

    • F1 ऐसा करता है। सभी teams को वही approved ECU[1] इस्तेमाल करना होता है। कुछ mapping tables आदि बदली जा सकती हैं, लेकिन device sealed होता है और firmware replace नहीं किया जा सकता
      [1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
    • cars में ऐसे devices होते हैं जो sensor data intercept करके fake data ECU को वापस भेजते हैं और emissions control को bypass कर देते हैं। यह काफ़ी सरलता से किया जा सकता है
      मेरा एक दोस्त WRX चलाता है; उसमें catalytic converter भी नहीं है, बड़ा turbo और tuning भी है, इसलिए उसे emissions test कभी पास नहीं करना चाहिए। लेकिन sensor data synthetic है और relevant parts को control करता है, इसलिए कोई error code नहीं आता और हर बार बिना समस्या के पास हो जाती है
    • manufacturers को customers को पूरा source code और software update/replace करने के tools देने के लिए बाध्य करना ही अच्छा होगा
      firmware के black hole को खत्म करके auditing possible बनानी चाहिए
    • standardization से थोड़ा ज़्यादा चाहिए। क्योंकि software changes की barriers भी हटानी होंगी
      पूरी standardization ज़रूरी नहीं, openness ही काफी हो सकती है। फिर भी बुनियादी तौर पर दिशा यही सही है

  • ऐसा लगता है कि manufacturer service की जगह सस्ती third-party service इस्तेमाल करने से रोकने के लिए software से जानबूझकर बाधा डाली गई
    court का फैसला देखने में दिलचस्पी है

    • इसमें कोई शक नहीं कि यह obstruction है। बाकी बस culprit साबित करना है, और motive, means, opportunity देखें तो 99% manufacturer लगता है, लेकिन किसे responsible ठहराकर criminal liability देनी है, यह स्वाभाविक रूप से court में तय होना चाहिए
      lawmakers, courts और public का technical issues के सामने भटक जाना समस्या है, लेकिन यह crime existing obstruction-related criminal law में पर्याप्त रूप से fit हो सकता है। तरीका “नया” है, लेकिन crime खुद classic है

  • ट्रेन firmware की quality कुल मिलाकर बहुत अच्छी नहीं लगती, और उम्मीद है कि इस scandal के बाद ज्यादा सख्त review होगा
    3 साल पहले Deutsche Bahn ने नए deliver हुए Bombardier ट्रेनों की “अजीब” software समस्याओं पर सार्वजनिक रूप से शिकायत की थी। उदाहरण के लिए, जब driver ने चलने की दिशा बदली, तो train software crash हो गया, और दोबारा boot होने में 1 घंटा लगा [0]। Switzerland में भी 2018 में ऐसी ही समस्या आई थी [1]
    एक computer scientist के तौर पर यह शर्मनाक है। इसकी तुलना उन पुराने trains [2] से कर लें, जो 1980s में East Germany में बने थे और हाल तक यहां 1950s के West German coaches [3] खींचते थे। Digital electronics बहुत कम या बिल्कुल नहीं थे, और boot time भी नहीं था। वे बस काम करते थे। अगर नहीं करते, तो driver को आम तौर पर यह भी पता होता था कि engine में कहां हथौड़ा मारने से ठीक हो जाएगा। किसी driver से यह उम्मीद नहीं की जा सकती कि वह train firmware hack करे और gdb चलाकर पता लगाए कि ट्रेन क्यों नहीं चल रही
    [0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
    [1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
    [2] https://de.wikipedia.org/wiki/DR-Baureihe_243
    [3] https://de.wikipedia.org/wiki/N-Wagen

    • मुझे लगता है कि जो कंपनियां software को product मानती हैं, उनके developers को मिलने वाले compensation ने बहुत से skilled developers को अपनी ओर खींच लिया। पहले जो लोग मजे के लिए ऐसी jobs चुनते, वे अब कहीं और चले जाते हैं
      जिन कंपनियों के products में software होता है, वे ऐसे market में नहीं हैं जहां वे software talent को पहले से 2–3 गुना pay करने को तैयार हों। बचते हैं वे लोग जो उस मजे को total compensation के फर्क के रूप में स्वीकार करते हैं, और वे लोग जिन्हें ज्यादा pay वाली job नहीं मिली। हमारे इस्तेमाल में आने वाले ज्यादातर safety-critical systems ऐसे ही लोग बना रहे हैं। X और SpaceX के developer compensation की तुलना करें तो दिखता है कि market कैसे काम करता है। मजा भी total compensation में आता है, लेकिन इसका नतीजा यह भी होता है कि अच्छे developer न होने वाले लोग इस क्षेत्र में नए processes और tools design करने की ओर मुड़ जाते हैं। वे outdated हो चुकी full-stack trend को पकड़े रहकर उसे train firmware पर लागू करने की कोशिश कर सकते हैं। अगर Jira में Git से 10 गुना ज्यादा text हो, scrum-waterfall development चल रहा हो, और safety-critical embedded systems में REST API या service-oriented architecture डाली जा रही हो, तो हैरानी नहीं होगी
    • यह software software engineers ने नहीं बनाया, बल्कि PLC programmers, electrical circuit designers और संयोग से इस field में आ गए लोगों ने बनाया है
      Beckhoff के Tc3 जैसी कुछ चीजों को छोड़ दें, तो यह अभी object-oriented तक भी नहीं पहुंचा है, और पूरा field पुराने bluescreen mine में फंसा हुआ है। पतले standards documents से complexity manage की जाती है, version control भी नहीं है, जबकि machines sensors और actuators के लिहाज से लगातार ज्यादा complex होती जा रही हैं। Modern machines को किसी छोटे hobby embedded device की तरह treat नहीं किया जा सकता, लेकिन industry ऐसा ही करती है। बाहरी programmers आकर proper software architecture और C development practices से कल की समस्याएं हल करते हुए अच्छा पैसा भी कमा लेते हैं। लेकिन industry उससे सीखती नहीं। उनके लिए software बनाना हमेशा professional discipline नहीं रहेगा
    • कभी-कभी low-tech बेहतर होता है। Finland में 1970s में Soviet Union से लाई गई Sr1 electric locomotives हैं, और कई refurbishments के बाद उनके कम से कम 2030 तक इस्तेमाल में बने रहने की संभावना है
    • मैं भी कुछ ऐसा ही देखता हूं। trains का software-ization बुनियादी reliability और interoperability, दोनों में बड़ा regression लेकर आया है
      कई modern trains को basic driving software की समस्याएं [0] और software approval delays [1] झेलनी पड़ती हैं। लेकिन मेरे हिसाब से सबसे खराब regression compatibility का loss है। Modern EMUs असल में उसी batch की EMUs के साथ ही काम करती हैं। same model भी अगर दो कंपनियों ने अलग-अलग order किया हो, तो अक्सर आपस में compatible नहीं होते; और अलग कंपनी या 10 साल से ज्यादा के अंतर से order की गई EMUs को साथ इस्तेमाल करना लगभग छोड़ ही देना पड़ता है। इसके उलट, digital era से पहले अलग-अलग generations के trams को साथ चलाना और wiring बदलकर उन्हें match करना आम बात थी। पुराने coaches बिना समस्या साथ काम करते हैं, लेकिन IC2 और Railjet, या RailJet और ICE-L को साथ इस्तेमाल करना आसान नहीं है। कई बार तो केवल खास locomotives और coaches ही एक-दूसरे के साथ काम करते थे
      Computerized systems में complexity ज्यादा और opacity अधिक होने के कारण उन्हें साथ काम कराने में कहीं ज्यादा मुश्किल होती है। Traditional logic circuit boards को आम तौर पर आसानी से reverse-engineer किया जा सकता है, लेकिन software reverse engineering बहुत specialized काम है। Proprietary digital protocols की ओर जाने से interoperability बहुत खराब हुई है, और यही pattern दूसरे क्षेत्रों में भी साफ दिखता है
      इसकी वजह partly यह है कि software opaque होता है, इसलिए पिछली technologies की तुलना में approval पाना कठिन है; लेकिन actual quality की कमी भी बड़ी वजह है। Bombardier के बड़ी मुसीबत में पड़ने के कारणों में से एक खराब software भी था, और 40 से ज्यादा units का order वाला contract तक cancel हो गया था ([2])
      मेरे हिसाब से reliable और understandable software बनाना logic circuits या mechanical systems बनाने से कहीं ज्यादा मुश्किल है। समाधान नहीं पता, लेकिन यह बहुत समय से चला आ रहा issue है
      [0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn...
      [1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf...
      [2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
    • यही बात ज्यादातर software पर भी कही जा सकती है, जहां framework जितना नया होता है, खामियां उतनी ही साफ दिखती हैं। हाल का एक लेख है “Software disenchantment”: https://tonsky.me/blog/disenchantment/

  • मैं सिर्फ़ English content ही consume कर रहा/रही हूँ। दूसरे देशों का content वही देखने को मिलता है जो बड़े media के ज़रिए छनकर बाहर आता है
    सोचने लगा/लगी कि translate किए जा सकने वाले अच्छे content की कितनी भरमार होगी

    • अगर मतलब यह है कि सिर्फ़ English पढ़ने की वजह से हम कितना दूसरा अच्छा content miss कर रहे हैं, तो यह अच्छी बात है
      हालांकि English अब, विडंबना यह है कि, कम से कम दुनिया के ज़्यादा शिक्षित हिस्से में common language बन चुकी है, और जिन लोगों को अपनी मातृभाषा ज़्यादा सहज लगती है वे भी अपना बेहतरीन काम ज़्यादा व्यापक रूप से पढ़वाने के लिए अक्सर उसे English में translate कराते हैं। Scientific papers इसका प्रमुख उदाहरण हैं। शायद Britain ने दुनिया को जो सबसे बड़ा तोहफ़ा दिया, वह English ही हो
    • मैं Poland से हूँ, और संभव है कि उन्हीं खास रुकी हुई trains में सफ़र किया हो। मैं Wrocław में रहता/रहती था/थी और Koleje Dolnośląskie, यानी Lower Silesia Railways से आसपास घूमने जाया करता/करती था/थी। Wrocław के आसपास बहुत खूबसूरत जगहें हैं
      लेकिन इस पूरे train supplier lock-in के बारे में मुझे पहली बार HN पर पता चला। वरना शायद मुझे कभी पता ही नहीं चलता, या फिर कई हफ्तों या महीनों बाद पता चलता