यह मान लेना कि कंप्यूटर सही तरीके से काम करता है

• ब्रिटेन का Post Office Horizon अभियोजन घोटाला आधुनिक ब्रिटेन में बड़े पैमाने पर न्यायिक भूल के मामलों में से एक है, जो यह दिखाता है कि व्यक्तिगत और संस्थागत विफलताओं के साथ-साथ कानून और अदालत की प्रक्रियाओं ने कैसी भूमिका निभाई
• अदालतें, विरोधी साक्ष्य न होने पर, यह मान लेती हैं कि मशीन सामान्य रूप से काम कर रही थी, और यह शुरुआती धारणा कंप्यूटर रिकॉर्ड्स पर भी लागू होती है
• ऐसी साक्ष्यगत धारणा के तहत, सिर्फ कंप्यूटर रिकॉर्ड्स के आधार पर लेखा कमी जैसी बातों को सिद्ध माना जा सकता है, और त्रुटि साबित करने का बोझ प्रतिवादी पर आ जाता है
• 1984 के Police and Criminal Evidence Act की Section 69 में इसका उल्टा नियम था, जिसमें अभियोजन पक्ष को कंप्यूटर के सही काम करने को दिखाना पड़ता था, लेकिन इसे 1999 में हटा दिया गया
• अगर Section 69 बनी रहती, तो Post Office अभियोजन अलग तरह से आगे बढ़ सकते थे, लेकिन इसके हटने के बाद बोझ फिर से प्रतिवादी पक्ष पर लौट आया

---

Post Office Horizon घोटाला और कानूनी प्रक्रिया की जिम्मेदारी

• Post Office prosecutions scandal को आधुनिक ब्रिटेन के सबसे बड़े सामूहिक न्यायिक भूल मामलों में गिना जाता है
• इस मामले में व्यक्तिगत और संस्थागत विफलताएँ एक-दूसरे पर चढ़ी हुई हैं, और कानूनी दस्तावेज़ व साक्ष्य इतने विशाल हैं कि पूरे मामले को समझना कठिन है
  • 2019 में Mr Justice Fraser का प्रमुख फ़ैसला परिशिष्टों को छोड़कर भी 1,000 से अधिक पैराग्राफ़ का है
  • Nick Wallis की संबंधित किताब और न्यायिक जांच इस मामले की प्रगति और दोबारा ऐसा न हो, इसके उपायों को ट्रैक करती हैं
• कई विश्लेषण Post Office प्रबंधन, वकीलों और सॉफ़्टवेयर प्रदाता Fujitsu की विफलताओं पर केंद्रित हैं
• लेकिन लागू कानून और प्रक्रियाएँ भी इस मामले का हिस्सा थीं, और इस अर्थ में उनकी जिम्मेदारी कम नहीं होती कि निर्णय लेने वालों को पता था या होना चाहिए था कि वे प्रतिवादियों के खिलाफ कठोर तरीके से काम कर सकती हैं

“कंप्यूटर सामान्य रूप से काम करता है” वाली साक्ष्यगत धारणा

• कानून के जानकार जिस धारणा (presumption) की बात करते हैं, वह ऐसा तंत्र है जिसमें विरोधी साक्ष्य न होने पर अदालत किसी विशेष स्थिति को डिफ़ॉल्ट रूप में स्वीकार करती है
• इसका पारंपरिक रूप यह है: “विरोधी साक्ष्य न होने पर अदालत यह मान लेती है कि संबंधित समय पर मशीन सामान्य स्थिति में थी”
• यहाँ मशीन में कंप्यूटर भी शामिल हैं
• इसका मतलब यह नहीं कि अदालत हर स्थिति में कंप्यूटर पर भरोसा ही करती है, बल्कि यह एक शुरुआती बिंदु है जिसे साक्ष्य से चुनौती दी जा सकती है
• जब तक विपरीत स्थिति सिद्ध न हो, अदालत उस स्थिति को तथ्य के रूप में स्वीकार कर सकती है

धारणा की जरूरत और उसका जोखिम

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

जब कंप्यूटर रिकॉर्ड ही दोषसिद्धि का आधार बन जाए

• कंप्यूटर के सामान्य रूप से काम करने का नियम एक साक्ष्यगत धारणा है
• अगर कंप्यूटर के सही से काम न करने का कोई साक्ष्य न हो, तो अदालत सिर्फ कंप्यूटर रिकॉर्ड्स के आधार पर संबंधित तथ्य को सिद्ध मान सकती है
• उदाहरण के लिए, यदि कंप्यूटर रिकॉर्ड किसी पोस्टमास्टर या डाकघर की महिला कर्मचारी के वित्तीय घाटे को दिखाते हैं, तो अदालत इसे वास्तविक घाटे के साक्ष्य के रूप में स्वीकार कर सकती है
• इस आधार को हिलाने के लिए प्रतिवादी को दिखाना पड़ता है कि कंप्यूटर सामान्य रूप से काम नहीं कर रहा था
• जब अभियोजन का मुख्य साक्ष्य कंप्यूटर रिकॉर्ड ही हो, तो संरचना अंततः “computer says guilty” बन जाती है

Section 69 की शुरुआत और समाप्ति

• यह साक्ष्यगत धारणा हमेशा एक ही दिशा में काम नहीं करती थी
• 1984 में बने Police and Criminal Evidence Act 1984 Section 69 ने इस धारणा की दिशा उलट दी थी
• Section 69 के तहत, प्रतिवादी को कंप्यूटर त्रुटि दिखाने की जरूरत नहीं थी; बल्कि अभियोजन पक्ष को कंप्यूटर के सही काम करने को दिखाना पड़ता था
• इस प्रावधान ने उस पुराने common law रुख की जगह ली थी, जिसमें “विरोधी साक्ष्य न होने पर मशीन सामान्य स्थिति में थी” माना जाता था
• अगर Post Office जब पोस्टमास्टर्स और डाकघर की महिला कर्मचारियों पर मुकदमे चला रहा था, तब Section 69 लागू रहती, तो मामले अलग तरह से आगे बढ़ सकते थे
• Section 69 को 1999 में निरस्त कर दिया गया, और पुरानी common law धारणा वापस आ गई
• उसके बाद फिर ऐसी संरचना बन गई जिसमें अभियोजक को पहले कंप्यूटर के सही काम करने को दिखाने की जरूरत नहीं रही, बल्कि प्रतिवादी को यह दिखाना पड़ता है कि कंप्यूटर सामान्य रूप से काम नहीं कर रहा था
• Section 69 कैसे हटाई गई और इसके कारण कितने उचित थे, यह आगे की चर्चा का विषय है

[GN⁺]

Hacker News टिप्पणियां

• Post Office घोटाले को आख़िरी बार देखने पर मेरी धारणा यह थी कि “हमने IT system पर बहुत ज़्यादा भरोसा किया” कहना एक सुविधाजनक बहाने जैसा था
  ऊपर बैठे लोगों को समस्या की अच्छी जानकारी थी, और वे जानते थे कि वे बेगुनाह लोगों पर मुकदमा चला रहे हैं, फिर भी अपनी नाकामी छिपाने के लिए इसे आगे बढ़ाते दिखे। अगर ऐसा है, तो काफ़ी जेल की सज़ा ज़रूरी है। न्याय में बाधा डालना कोई छोटा अपराध नहीं है, और Paula Vennells पर संसद में जानबूझकर झूठ बोलने का आरोप भी है

  • इस बात के पर्याप्त सबूत हैं कि Post Office बोर्ड के शक्तिशाली लोगों ने sub-postmasters के सबूतों को इसलिए भी नज़रअंदाज़ किया क्योंकि उनमें से कई एशियाई मूल के थे, जैसे भारतीय, बांग्लादेशी और पाकिस्तानी मूल के लोग
    इसलिए Post Office बोर्ड के सामने नस्लवाद के कारण सुरागों को जोड़कर देखने में एक मानसिक बाधा थी, और सैकड़ों झूठी दोषसिद्धियों के भारी सबूत सामने आने के बाद भी नैतिकता की कमी के चलते वे उल्टा और अड़े रहे। यह दुखद तकनीकी विफलता की कहानी भी है, लेकिन ब्रिटिश बोर्डरूम संस्कृति पर आरोप-पत्र भी है। इस आपदा को Private Eye पत्रिका 10 साल से ज़्यादा समय से कवर करती रही है
  • समझ नहीं आता कि सज़ा के नियमों, यानी अंततः लोगों को जेल में डालने या अनुमत व्यवहार पर tax लगाने के तरीक़े से इस समस्या को कैसे हल किया जा सकता है
    क्या यह कहना ज़्यादा सही नहीं होगा कि उस शक्ति को संरचनात्मक रूप से हटाया जाए
  • अगर executives को मिलने वाली अपेक्षित सज़ा अधिक होती, तो क्या sub-postmasters की समस्याएं जल्दी हल होतीं, या और देर से?

• पूरी ज़िंदगी bug ठीक करते हुए गुज़ारने के बाद, मुझे अक्सर यह बात ही हैरान करती है कि computer systems überhaupt काम करते हैं
  Post Office की विफल system जैसी एक घटना मेरे साथ व्यक्तिगत रूप से भी हुई थी, जहां सबूत देने के बावजूद सभी ने computer system के गलत होने की संभावना को मानने से इनकार कर दिया। वजह यह थी कि समझने के लिए गहराई में जाना बहुत झंझट भरा था

  • “यह हैरानी की बात है कि computer systems überhaupt काम करते हैं” वाली बात से सहमत हूं
    मैंने देखा है कि software कैसे बनाया जाता है, इसलिए समझ नहीं आता कि आख़िर यह सब कैसे काम कर पाता है। इस paradox का मेरा जवाब है कि असल में सब कुछ काम नहीं करता। हमने खुद को उन चीज़ों को कुछ और मान लेने के लिए प्रशिक्षित कर लिया है जो काम नहीं करतीं। लोग computer systems को या तो सर्वशक्तिमान और त्रुटिरहित अस्तित्व की तरह देखते हैं, या उल्टा उन्हें बलि का बकरा बना देते हैं
  • थोड़ा और nuance जोड़ें तो, कई लोकप्रिय software इतने टूटे हुए हैं कि उनका core feature, यानी उनके होने की वजह ही काम नहीं करती
    उदाहरण के लिए TAP, Vueling, KLM जैसी airline websites को पिछले 2 साल में इस्तेमाल करने पर अक्सर ऐसे bugs मिले जिनसे ticket book करना या account में login करना संभव नहीं था, और मेरे हिसाब से वे काम करने से ज़्यादा बार नहीं चलती थीं। Instagram और Google बिना किसी खास वजह के accounts को अपने-आप disable करते रहे हैं, और Instagram पर दो महीने में 3 बार ऐसा झेलने के बाद मैंने हार मान ली और उसे इस्तेमाल करना छोड़ दिया। Skype इस्तेमाल करने वालों को किसी explanation की ज़रूरत नहीं, और Teams “updates” कितनी भी कर ले, फिर भी अजीब तरीक़ों से fail होता है: mute button सच में mute नहीं करता, chat लिखते समय वाक्य के अक्षरों का क्रम उलट जाता है, या call के दौरान अचानक बंद होकर respond करना छोड़ देता है। ऐसी productivity loss दुनिया भर में काफ़ी बड़ी होगी, और कंपनियों द्वारा बर्बाद की गई manpower cost शायद Microsoft को दी जाने वाली license fees से अधिक हो। Telegram external monitor को ठीक से handle नहीं कर पाता, scaling बिगड़ जाती है और restart करना पड़ता है, और iCloud में सभी devices का connection अच्छा होने पर भी file sync होने में कुछ seconds से लेकर लगभग एक घंटे तक लग जाते हैं
  • ज़्यादातर लोग यह स्वीकार करने के बजाय कि सब कुछ “लगभग” काम करता है, यह मानने का आसान रास्ता चुनते हैं कि सब कुछ perfect है
    वे लगातार विपरीत सबूत देखते हुए भी ऐसा करते हैं, लेकिन एक engineer के तौर पर मुझे यह स्वाभाविक और efficient लगता है। Priorities तय करनी होती हैं और कुछ bugs दूसरे bugs से कम महत्वपूर्ण होते हैं। मुझे लगता है कि हर software के हर bug को ठीक करने के बजाय शिक्षा, स्वास्थ्य और basic research पर ज़्यादा प्रयास लगाना बेहतर है
  • ऐसी चीज़ें अक्सर इसलिए होती हैं क्योंकि मशीनें आम तौर पर 99% समय ठीक काम करती हैं
    इसलिए जब वे 1% मामलों में fail होने लगती हैं, तब भी लोग पहले के 99% में काम करने की वजह से उसे नज़रअंदाज़ कर देते हैं। वे परिणामों पर भरोसा करने के लिए trained होते हैं, इसलिए संदेह का ख़याल ही नहीं आता। Systemantics नाम की किताब याद आती है: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
    उस किताब के मुख्य प्रस्तावों में से एक operational fallacy है कि “systems वास्तव में वह काम नहीं करते जो वे करने का दावा करते हैं।” इंसान ही नहीं, engineers भी इसे अक्सर भूल जाते हैं। कोई system कहता है कि वह X करता है, इसका मतलब यह नहीं कि वह वास्तव में X करता है। जटिल IT systems को लेकर स्वस्थ संदेह विकसित करना चाहिए। वे ज़्यादातर समय fail नहीं हो सकते, लेकिन अंततः किसी दिन fail ज़रूर होंगे
  • software industry की तेज़ बढ़ोतरी ऐसी अव्यवस्था का कारण भी है जिसे संभालना मुश्किल है, और यह भी वजह है कि कंपनियां बेतुका पैसा खर्च करके किसी तरह चीज़ों को चलाए रखती हैं
    कम-से-कम ऐसा महसूस होता है

• इन मुकदमों की एक बड़ी समस्या यह थी कि prosecutor खुद Post Office था
  इस मामले से पहले मुझे नहीं पता था कि Post Office के पास ऐसी शक्ति है। असल में Post Office शिकायतकर्ता और prosecution agency दोनों की भूमिका निभा रहा था। “Post Office Investigation Branch(IB) दुनिया का सबसे पुराना मान्यता प्राप्त criminal investigation संगठन है। 335 साल से अधिक समय से यह डाक-संबंधी अपराधों का पता लगाता और अपराधियों पर मुकदमा चलाता रहा है।”
  https://www.postalmuseum.org/blog/the-post-office-investigat...

  • England में कोई भी prosecution ला सकता है
    सैद्धांतिक रूप से यह शक्तिशाली लोगों को जवाबदेह ठहराने का साधन है, लेकिन यह बहुत महंगा होता है, इसलिए लगभग सभी private prosecutions वास्तव में कंपनियां ही लाती हैं

• यह स्कैंडल मैंने पहली बार सुना
  सोच रहा हूँ कि उस software की मुख्य समस्या क्या थी जिसने mismatch पैदा किया। क्या connection टूटने जैसी कोई चीज़ थी? Wikipedia में ज़्यादा detail नहीं थी। यहाँ मिला: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...

  • यह हमारे दौर के software से जुड़े सबसे बड़े स्कैंडल में से एक है
    इसके बारे में और जानने की सलाह दूँगा, लेकिन दिल मज़बूत होना चाहिए। इस मामले में गहराई तक गए कई लोगों को पास में बाल्टी ढूँढनी पड़ी। सच में देखना बहुत मुश्किल है
  • मुझे लगता है समस्या bug से ज़्यादा उदासीनता थी
    बड़े systems में development के दौरान लगभग हमेशा bugs आते हैं, लेकिन आम तौर पर वे मिल जाते हैं और ठीक कर दिए जाते हैं। यहाँ bugs मिले, फिर भी ठीक नहीं किए गए
  • संक्षेप में, किसी third party द्वारा उपलब्ध कराया गया distributed ledger audit न हो सकने वाली access permissions के साथ sync से बाहर हो गया, और “computer ऐसा कह रहा है” के आधार पर branch managers को काल्पनिक fraud के आरोपों में बलि का बकरा बना दिया गया

• मेरा default assumption यह है कि computers ठीक से काम नहीं करते
  क्योंकि मैंने असल में बहुत बार उन्हें ठीक से काम न करते देखा है। गाड़ी चलाते समय भी मैं Google Maps पर आँख मूँदकर भरोसा नहीं करता; देखता हूँ कि route समझ में आता है या नहीं, और जहाँ turn लेना है वहाँ road name और exit number फिर से check करता हूँ। बहुत बार धोखा खा चुका हूँ

• programmer के रूप में मेरे अनुभव में computer खुद आम तौर पर सही काम करता है
  hardware bug होना बहुत दुर्लभ है। लेकिन software हमेशा गलत होता है, और computer hardware बस software ने जो कहा उसे अंधाधुंध execute करता है

  • drivers पर काम करने वाले programmer के रूप में मेरे अनुभव में, hardware लगभग कभी ठीक से काम नहीं करता
    “software में ठीक कर लो” hardware industry का official motto हो सकता है
  • यह अंतर इस लेख से relevant नहीं है
    यहाँ “computer” का मतलब hardware और software से बने system से है, और “computer” शब्द लगभग हमेशा इसी तरह इस्तेमाल होता है। समस्या यह है कि अदालत, उलटे evidence के अभाव में, मान लेती है कि computer सामान्य रूप से काम कर रहा था। यानी अदालत केवल computer records के आधार पर संबंधित facts साबित मान सकती है, और अगर defendant यह नहीं दिखा पाता कि computer ठीक से काम नहीं कर रहा था, तो subpostmaster के account में financial shortfall था—यह मान लिया जाता है। संक्षेप में, अगर prosecution case का केंद्र computer records हैं, तो यह computer ने उसे guilty कहा जैसी बात हो जाती है
  • hardware में उसे ठीक से चलाने के लिए बहुत सारे छोटे-छोटे अजीब behaviors या hacks होते हैं, और वह वाकई अक्सर ठीक से काम नहीं करता
    बहुत low level पर hardware को सीधे छूने वाले software से अक्सर उम्मीद की जाती है कि वह इन ऊबड़-खाबड़ हिस्सों की भरपाई करे
  • hardware में भी ऐसा होता है
    पुराने उदाहरण के तौर पर Intel Pentium CPU में release के बाद दो मशहूर bugs मिले थे। 1994 में recall तक पहुँचा floating-point division FDIV bug, और 1997 में मिला F00F bug, जो reboot होने तक processor को freeze कर देता था।
    https://en.m.wikipedia.org/wiki/Hardware_bug
  • आप वही experience बता रहे हैं जो non-programmers software के साथ महसूस करते हैं
    आम तौर पर वह काम करता है, इसलिए लगभग हमेशा user की गलती मान ली जाती है। अगर पता न हो कि क्या ढूँढना है, तो आप सिर्फ अपने जाने-पहचाने error cases को exclude करते रहेंगे और ऊपर के लेख जैसी भयावह miscarriage of justice तक पहुँच सकते हैं

• यह presumption मुख्य रूप से तब समस्या बनता है जब computer operator वही party हो जो persecuting side पर है

  1. बाहरी लोगों के लिए computer के operation को inspect करना मुश्किल या असंभव होता है, और 2) operator के पास computer output में हेरफेर करने या errors छिपाने की मजबूत motivation होती है। उलटे perspective के relevant example के तौर पर, कुछ साल पहले copyright trolls BitTorrent swarms से अपने बनाए logs को court evidence के रूप में इस्तेमाल कर रहे थे। ऐसा data forge करना बहुत आसान था और outsiders के लिए detect करना लगभग असंभव, और ऐसा करने का financial incentive भी बड़ा था। यह बात बेतुकी लगी कि ऐसे “evidence” को court में consider किया गया
  • आह, Prenda Law case—पुरानी यादें ताज़ा हो गईं

• सवाल यह तो है ही कि अदालत को क्या presume करना चाहिए, लेकिन यह भी पूछने लायक है कि software developers क्या presume करते हैं या नहीं करते
  software developers व्यापक रूप से इस्तेमाल होने वाले software को सही काम करता हुआ presume करेंगे। GitHub issues में pandas bugs के 3,500 entries हों, तब भी JavaSDK या pandas library को सही काम करता माना जाता है। लेकिन अगर कोई कम-ज्ञात library integrate कर रहे हों या कम-ज्ञात software इस्तेमाल कर रहे हों, तो उसके operation को लेकर भरोसा कम हो जाता है

  • पर्याप्त eyes हों तो सभी bugs shallow होते हैं
    इस मायने में कि हजारों लोग वर्षों तक शिकायत करते रहते हैं। कम cynical तरीके से कहें तो, व्यापक रूप से इस्तेमाल होने वाले software के व्यापक रूप से इस्तेमाल होने वाले features के real-world conditions में test होने की उम्मीद की जा सकती है, इसलिए अगर bugs हों भी तो कम से कम उनके known होने की संभावना ज़्यादा है। लेकिन मध्यम complexity वाले software का state space भी पूरी तरह cover करने के लिए भारी testing मांगता है। SQLite का test suite कितना बड़ा है, यह देख लें। कम bugs वाला software बनाने का एकमात्र सच में काम करने वाला तरीका शायद यह है कि छोटे, self-contained, isolated और अच्छी तरह समझे गए parts को जोड़कर whole system के बारे में reasoning आसान बनाई जाए। यही original Unix philosophy है, functional programming की philosophy है, और asynchronous interactions पर reasoning कठिन होने के बावजूद actor systems की philosophy का भी हिस्सा है। उम्मीद है कि real-world practice में यह approach और ज़्यादा दिखेगी

• title शायद clickbait के उलट जैसा है
  लेख Post Office scandal पर है, और यह सच में एक बड़ा विषय पकड़ता है

• preservation link: https://archive.ph/wip/AJl8i