SQL injection की अदालती यात्रा

 (sockpuppet.org)
1 पॉइंट द्वारा GN⁺ 2025-02-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Illinois FOIA के व्यापक disclosure सिद्धांत की public agency database schema के सामने परीक्षा हुई, और Chicago के CANVAS parking ticket database के अनुरोध ने मुकदमे और विधायी बहस को जन्म दिया
  • FOIA मौजूदा जानकारी के disclosure की मज़बूती से गारंटी देता है, लेकिन नया record तैयार करने के लिए बाध्य नहीं कर सकता; इसलिए जैसे-जैसे डेटा application के भीतर रहता है, यह बताने वाला schema कि कौन-सी query मांगी जाए, अधिक महत्वपूर्ण हो जाता है
  • Chicago ने तर्क दिया कि CANVAS schema सुरक्षा के लिए खतरा है, और मुकदमे का मुख्य सवाल यह था कि schema का खुलासा SQL Injection हमलों को वास्तव में संभव बनाता है या आसान करता है
  • निचली अदालत और appellate court में disclosure पक्ष जीता, लेकिन Illinois Supreme Court ने file layout को अपने-आप में exempt माना और तय किया कि SQL schema भी इसी में आता है
  • फिलहाल Illinois की public agencies database schema के disclosure से इनकार कर सकती हैं, और SB0226 का उद्देश्य यह अनिवार्य करना है कि database structure का विवरण दिया जाए ताकि requester ठोस database queries मांग सकें

Illinois FOIA का databases से टकराव

  • Illinois FOIA सिद्धांततः public agencies द्वारा एकत्र की गई जानकारी को सार्वजनिक संपत्ति मानता है, और अपवाद सीमित हैं
    • requesters से आम तौर पर शुल्क नहीं लिया जाता
    • public agencies आसानी से requests की संख्या सीमित नहीं कर सकतीं
    • जवाब की मूल समयसीमा 5 दिन है, और लिखित extension request होने पर 5 दिन और जोड़े जा सकते हैं
    • अनुचित इनकार के खिलाफ मुकदमा जीतने पर attorney fees वसूलना संभव है
  • बड़ी सीमा यह है कि FOIA के तहत public agencies को नया record बनाने के लिए मजबूर नहीं किया जा सकता
    • अगर मनचाही report पहले से मौजूद है, तो उसे मांगा जा सकता है
    • अगर वह मौजूद नहीं है, तो raw data मांगकर उसे खुद जोड़ना पड़ता है
  • जैसे-जैसे public agency की जानकारी file cabinet, shared drive या Word documents के बजाय विशेषीकृत applications और databases में ज्यादा रहने लगी, schema का महत्व बढ़ गया
  • database schema वह संरचना है जिसमें अलग-अलग tables के नाम और हर table के columns के नाम होते हैं
    • लेख में इसकी तुलना कई tabs वाली Excel file से की गई है
    • हर tab का नाम और हर tab की header row schema के बराबर है

Matt Chapman का CANVAS schema अनुरोध

  • Matt Chapman को बड़े पैमाने के FOIA requests के जरिए data journalism करने वाले civic hacker के रूप में पेश किया गया है
  • Chicago parking tickets के data पर काम करते हुए CANVAS नाम का system सामने आया
    • CANVAS Chicago के सभी parking ticket data का केंद्रीय repository है
    • Matt Chapman ने यह समझने के लिए FOIA के तहत schema मांगा कि CANVAS database में क्या है
  • Chicago ने Illinois FOIA में automated data processing से जुड़े exception clause का हवाला देकर request ठुकरा दी
    • उस clause में software, operating protocols, program abstracts, file layouts, source listings, modules, user guides, logical और physical design documents, employee manuals आदि शामिल हैं
    • ऐसी जानकारी भी exception में गिनी गई है जिसका खुलासा system या data security को खतरे में डाल सकता है
  • Chicago ने Matt Chapman को “hacker” कहा और दावा किया कि CANVAS schema गलत हाथों में गया तो शहर के लिए खतरा बन सकता है

अदालत का मुख्य तकनीकी मुद्दा: SQL Injection

  • मुकदमे का केंद्रीय प्रश्न यह था कि CANVAS schema का खुलासा SQL Injection हमलों को संभव बनाता है या नहीं
  • SQL वह भाषा है जिसका उपयोग कई programs databases से बात करने के लिए करते हैं, और SQL Injection SQL इस्तेमाल करने वाले programs में होने वाली एक security vulnerability है
  • SQL Injection तब होता है जब application code के भीतर मौजूद SQL query template में user input को गलत तरीके से जोड़ दिया जाता है
    • उदाहरण के तौर पर, किसी नाम को quotes में रखने वाली query में Bob O’Connor जैसा input, जिसमें quote शामिल हो, database की parsing को भ्रमित कर सकता है
    • attacker ऐसे input points का इस्तेमाल कर बाकी input को code की तरह execute कराने की कोशिश कर सकता है
  • Chicago के CISO Bruce Coffing ने तर्क दिया कि schema disclosure attackers को तीन तरह से मदद देता है
    • vulnerabilities खोजने में
    • vulnerability probing को अधिक stealthy बनाने में
    • उन applications को चुनने में जिन पर हमला करना ज्यादा लाभकारी हो
  • इसके उलट तर्क का फोकस इस बात पर था कि schema SQL Injection vulnerability खोजने की जगह नहीं है
    • SQL Injection vulnerabilities database schema में नहीं बल्कि application source code के SQL query templates में मिलती हैं
    • मांगी गई चीज source code नहीं बल्कि tables की header row जैसी schema थी
    • attacker SQL Injection के जरिए schema निकाल सकता है; इस अर्थ में schema हमले की पूर्वशर्त कम और हमले का परिणाम अधिक है

निचली अदालत और appellate court का फैसला

  • निचली अदालत में Matt Chapman की ओर जीत हुई
    • Chicago ने तुरंत appeal की, और Matt Chapman को CANVAS schema नहीं मिला
  • appellate court ने इस आधार पर कानूनी प्रश्नों पर विचार किया कि तथ्यों का मुख्य निर्धारण निचली अदालत का काम है
  • disclosure से होने वाले जोखिम में “would jeopardize” का मानक मुख्य मुद्दा बना
    • “could” का मतलब है ऐसा स्तर जहां किसी घटना की कल्पना की जा सकती है
    • “would” के कानूनी मानक को ऐसे स्पष्ट हानि-प्रमाण के रूप में समझाया गया जो judge के मन में उचित संदेह न छोड़े
    • appellate court ने माना कि हानि की संभावना बहुत ऊंची होनी चाहिए
  • appellate court ने यह भी देखा कि exception clause की limiting language सिर्फ “any other information” पर लागू होती है या पूरे exception के “Administrative or technical information” हिस्से पर
    • अगर वह सिर्फ “any other information” पर लागू होती, तो file layouts जैसी चीजें अपने-आप exempt होतीं
    • अगर वह पूरे exception पर लागू होती, तो केवल इस factual finding के आधार पर कि disclosure सुरक्षा को खतरे में नहीं डालता, Matt Chapman पक्ष जीत सकता था
  • appellate court ने माना कि limiting language पूरे exception पर लागू होती है और Matt Chapman के पक्ष में फैसला दिया

Illinois Supreme Court में पलटा निष्कर्ष

  • Chicago ने फिर appeal की और मामला Illinois Supreme Court पहुंचा
  • Illinois Supreme Court ने FOIA exception clause की व्याख्या appellate court से अलग की
    • limiting language सिर्फ “any other information” पर लागू होती है
    • बाकी items अपने-आप exempt हैं
  • इस निष्कर्ष के बाद क्या SQL schema file layout है यह निर्णायक सवाल बन गया
  • schema और file layout तकनीकी रूप से अलग हैं, ऐसा प्रतिवाद सामने आया
    • एक ही SQL schema कई database engines में इस्तेमाल हो सकता है
    • हर database engine result data को अलग-अलग underlying file layout में संभालता है
    • McGraw-Hill Dictionary of Scientific & Technical Terms, 6E file layout को “किसी file के भीतर data arrangement का विवरण” के रूप में परिभाषित करता है
    • SQL schema उस abstraction के अधिक करीब है जो data की वास्तविक arrangement के बारे में सोचना ही न पड़े
  • Illinois Supreme Court ने Merriam-Webster Online Dictionary में schema की परिभाषा “structured framework or plan: outline” का भी उपयोग किया
    • अदालत ने माना कि अंतर सिर्फ नाम का है
    • नतीजतन schema को file layout माना गया और Matt Chapman पक्ष हार गया

मौजूदा स्थिति और SB0226

  • अभी Illinois की public agencies database schema disclosure से इनकार कर सकती हैं
  • जैसे-जैसे डेटा specialized applications में जाता है, मूल डेटा तक पहुंच पाने के लिए FOIA के तहत database queries मांगने की जरूरत बढ़ती जाती है
  • यह सवाल बना हुआ है कि databases स्थानीय सरकारों के लिए public information disclosure से बचने का सुरक्षित क्षेत्र नहीं बन जाने चाहिए
  • SB0226 का उद्देश्य FOIA कानून में ऐसा wording जोड़ना है जो public agencies को उनके नियंत्रण में मौजूद सभी database structures का पर्याप्त विवरण देने के लिए बाध्य करे
    • मकसद यह है कि requester public agency से विशिष्ट database queries चलाने का अनुरोध कर सकें
  • यह bill काफी हद तक उस दिशा से मेल खाता है जिसमें Matt Chapman लंबे समय से यह मुद्दा उठाते रहे हैं

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

1 टिप्पणियां

 
GN⁺ 2025-02-26
Hacker News टिप्पणियां

  • मैं इस मुकदमे का वादी हूं। tptacek की पोस्ट के साथ जाने वाली companion पोस्ट भी अभी लिख रहा हूं और जल्द ही तैयार हो जाएगी, तब तक यहां सवाल पूछ सकते हैं
    इंतजार करते समय मेरी पुरानी पोस्ट भी देख सकते हैं: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

    • Matt सच में जरूरी काम कर रहे हैं
      लेकिन यह याद रखना चाहिए कि देश के शीर्ष स्तर के civil rights वकीलों, Loevy and Loevy, का समर्थन होने के बावजूद Matt तकनीकी रूप से हार गए। यह दिखाता है कि सिटी हॉल से लड़ना कितना बेतुका कठिन है, और बिना वकील के तो और भी ज्यादा
      हमारे पक्ष में जो चीज है, वह है पोस्ट में सुझाए अनुसार कानून बदलना। अगर राज्य का Supreme Court फैसला दे दे, तो संशोधन के बिना मामला खत्म है, और Illinois का FOIA कानून बार-बार बदलने का इतिहास रहा है। हालांकि उनमें से कुछ बदलाव खुलापन बढ़ाने के बजाय जानकारी को गोपनीय रखने को और मजबूत करने की दिशा में भी रहे हैं
      एक और जरूरी बदलाव यह है कि ऐसी लड़ाइयों में हारने वाली एजेंसियों पर कड़े दंड लगाए जाएं। Illinois में यह एजेंसी पर लगभग 5000 डॉलर के civil penalty तक सीमित है। civil penalty क्या है, यह भी अस्पष्ट रूप से परिभाषित है; पहले यह वादी को दिया जाता था, लेकिन बाद में जिन मामलों में मैंने लड़ाई लड़ी, उनमें बस काउंटी को पैसा देने को कहा गया। एक state’s attorney के शब्दों में, “हार भी जाऊं तो फर्क नहीं पड़ता, बस खुद को ही एक चेक लिख दूंगा” जैसी स्थिति हो जाती है
      अंत में, मुकदमे में आप क्या मांगते हैं, इसे लेकर सावधान रहना चाहिए। इस तरह appellate court का फैसला आ सकता है और जिस चीज के खिलाफ मैं लड़ रहा था, उसी को कानून के रूप में पक्का कर सकता है। यह किसी की गलती नहीं, लेकिन सच में होता है। मुझे भी एक ऐसा हास्यास्पद फैसला मिला था जिसने कैदियों के अधिकार मजबूत करने के बजाय उन्हें हटा ही दिया
    • यह तर्क समझना मुश्किल है कि column names जानना हमलावर के लिए मददगार नहीं होता। अगर database wildcard की अनुमति नहीं देता, तो क्या column names का अंदाजा लगाने की तुलना में यह जानना कहीं आसान नहीं होगा कि '); SELECT col FROM logins किया जा सकता है?
      schema और file layout पर अदालत के निष्कर्ष से भी खास असहमति करना मुश्किल है। schema file layout खुद नहीं है, लेकिन समान है: यह बताता है कि “files” (records) को “file system” (database tables) में कैसे रखा गया है। उदाहरण के लिए denormalization, file record के अंदर data inline रखने से बहुत मिलता-जुलता है। यह नजरिया भी जाना-पहचाना है कि file system असल में एक database है। मुझे समझ नहीं आता कि कैसे कहा जा सकता है कि दोनों समान नहीं हैं
    • मुझे आश्चर्य है कि “CANVAS database की हर table से एक-एक row” जैसा request संभव है या नहीं
    • इस लड़ाई को झेलना सराहनीय है। पारदर्शिता तभी मिलती है जब लोग complacent नहीं होते
      आपके हिसाब से अगला कदम क्या है?
    • CANVAS administrators आखिर क्या छिपा रहे हैं?

  • मुझे लगता है कि शहर को schema share करना चाहिए, और वह असल में security through obscurity का तर्क दे रहा है, लेकिन पोस्ट की मुख्य premise — “SQL schema जानने से हमलावर को मदद नहीं मिलती” — से मैं सहमत नहीं हूं
    मैंने पोस्ट का तर्क इस तरह समझा: “हमलावर SQL injection हमले से SQL schema reconstruct करते हैं। schema हमले की prerequisite नहीं, बल्कि हमले का product है।” इसका मतलब ऐसा लगता है कि अगर vulnerability मिल जाए, तो schema वैसे भी recover किया जा सकता है, लेकिन यह हमेशा सही नहीं है। कुछ SQL injections सिर्फ currently queried table का कुछ data ला सकते हैं, और information_schema जैसी दूसरी tables नहीं ला सकते। अगर vulnerability से मिलने वाला signal सिर्फ “query failed” या “query succeeded, data returned” हो, तो schema जानना exploitation को बहुत आसान बना देता है
    अगर failed database queries को अलग से log किया जाता है, तो 24x7 चलने वाले attacks जो injections ढूंढ सकते हैं, उन्हें शायद पहले ही patch कर दिया गया होगा। तब actual injection point — जैसे कोई vulnerability जो सिर्फ logged-in users के लिए मौजूद हो और bots उसे न ढूंढ पाएं — मिलने तक logs noisy नहीं होंगे, और उस समय attacker के असल में exploitation का तरीका खोजने से पहले उसे देखकर ठीक करने का समय मिल सकता है
    schema जानने से vulnerability exploit करने की speed ही नहीं बढ़ती, बल्कि शुरुआत से ही query failures पैदा किए बिना injection explore करने की संभावना भी बढ़ती है

    • “SQL schema जानना हमलावर के लिए मददगार नहीं है” अगर यही standard हो, तो service name जानना भी हमलावर की मदद करता है, city hall officials के नाम जानना भी मदद करता है, और parking ticket कानूनी रूप से क्या है यह जानना भी मदद करता है। अगर कोई मुकदमे के बाद सरकार को hack करना चाहता है, तो अपने मुकदमे की details जानना भी attack में मदद करता है
      standard यह नहीं होना चाहिए कि “मददगार सारी जानकारी censor करो”, बल्कि यह होना चाहिए कि “passwords या backdoors उजागर करने वाला code publish मत करो।” schema उस category में नहीं आ सकता
    • मैं attacker नहीं, एक साधारण software developer हूं, लेकिन अगर SQL injection है, तो schema के मामले में मुझे लगता है कि असल में सब कुछ खत्म है
      फिर भी मैंने वास्तविक applications पर काम किया है जहां full injection न होने पर भी schema जानना data leak में मददगार था। सबसे स्पष्ट उदाहरण वह है जहां queries URL parameters के आधार पर बनाई जाती हैं, लेकिन उन parameters को allowlist से सीमित नहीं किया जाता
      इसलिए मैं मानता हूं कि schema attacker को थोड़ा फायदा दे सकता है
    • हाल ही में मिली “YouTube के जरिए email leak” vulnerability याद आती है, जिसकी शुरुआत भी मूल रूप से ऐसी चीज पढ़ने से हुई थी जिसे schema कहा जा सकता है
      https://brutecat.com/articles/leaking-youtube-emails
    • अगर failed database queries को अलग से log किया जाता है, और वह “failure” “SQL injection का संकेत” है, तो schema से की जा सकने वाली कोई भी चीज उस signal को कम नहीं करेगी। SQL syntax error का एक भी instance trace करने लायक है
      इसलिए मुझे नहीं लगता कि वह logic टिकता है
    • blind SQL injection वह प्रकार है जिसमें error नहीं आता, लेकिन subtle signals से success और failure अलग किए जाते हैं। मेरे जानने में सबसे दिलचस्प cases में से एक में successful injection का normal दिखने वाला response failed injection से 1 byte लंबा था, और इससे न सिर्फ schema पता चला बल्कि पूरा database पूरी तरह exfiltrate कर लिया गया
      server logs में error दिखाने वाली कोई चीज नहीं थी
      मैंने जो relatively beginner-level SQL injection exercises पढ़ाए थे, उनमें भी ज्यादातर schema जाने बिना ही किए गए थे। इसलिए SQL injection इतना tricky और खतरनाक होता है

  • Kurt ने मुझे फँसाने के लिए यह पोस्ट किया था। यह जान लेना अच्छा होगा कि असली लक्षित पाठक ज़्यादातर मेरे इलाके Chicagoland की नगरपालिका राजनीति में शामिल गैर-तकनीकी लोग थे
    स्थानीय राजनीति पर एक सार्वजनिक हित संदेश देना हो तो, राष्ट्रीय राजनीति में शामिल होना किसी गगनचुंबी इमारत की काँच की खिड़की से टकराते कीड़े जैसा निराशाजनक और थका देने वाला है। इसके उलट स्थानीय राजनीति बहुत अधिक responsive होती है। मैंने अपने खाली समय और लगभग बिना खर्च के वास्तविक नतीजे हासिल किए, और एक कानून पास कराने में भी मदद की। यह राष्ट्रीय राजनीति से नाटकीय रूप से अलग है
    कई इलाकों में हैरानी की बात यह है कि स्थानीय राजनीति message boards के इर्द-गिर्द चलती है। हो सकता है वे boards ऐसी जगह न हों जहाँ आप रहना चाहें, और खासकर Facebook Groups बहुत होते हैं, लेकिन बस इसे स्वीकार करना पड़ता है। अगर आप HN जैसी communities में भाग लेना पसंद करते हैं, तो आप राजनीति में भी भाग ले सकते हैं, और सिर्फ board activity से भी काम करा सकते हैं

    • यह भी बड़ी बात है कि आप ऐसे देश में रहते हैं जहाँ local governments को कानून बनाने का अधिकार है। कई अन्य देशों में ऐसा नहीं है, या अधिक सटीक कहें तो उनकी legislative power बेहद सीमित होती है
      दरअसल अमेरिका के अंदर भी कई जगह ऐसा ही है। केवल home rule powers वाली local governments ही, जब तक state और federal law से टकराव न हो, किसी भी विषय पर ordinances बना सकती हैं; जिनके पास यह power नहीं होती वे केवल उन खास विषयों पर ordinances बना सकती हैं जिनकी अनुमति state legislature ने दी हो। कुछ states सभी counties और municipalities को home rule देती हैं, कुछ बिल्कुल नहीं देतीं, और कुछ सिर्फ कुछ को देती हैं। उदाहरण के लिए Texas में, कोई municipality 5000 की आबादी तक पहुँचने के बाद voters की मंज़ूरी लेकर home rule powers हासिल कर सकती है
    • मैं जानना चाहता हूँ कि आपने जिस कानून को पास कराने में मदद की, उसके बारे में और बता सकते हैं या नहीं
      साथ ही, जो व्यक्ति Chicago politics में और शामिल होना चाहता हो, उसके लिए Facebook या कहीं और के अच्छे resources के links दे सकते हैं या नहीं। मैंने पहले search किया था, लेकिन नतीजे बहुत सीमित रहे
    • “कभी संदेह मत करो कि विचारशील और प्रतिबद्ध नागरिकों का एक छोटा समूह दुनिया बदल सकता है। वास्तव में, दुनिया को हमेशा इसी ने बदला है।” - Margaret Mead
    • मैं जानना चाहता हूँ कि ऐसे boards तक कैसे पहुँचा जाए
    • मुझे वह समय याद आता है जब आप और Maciej election campaign staffers तक FIDO keys पहुँचाने की कोशिश कर रहे थे, और वह वाकई depriming था

  • क्या यह बेतुका नहीं है कि Supreme Court और appellate court sentence structure के सवाल पर बँट गए? यह छोड़ भी दें कि ऐसा आम बात है, “सभी file placements और अन्य items भी cover होते हैं, लेकिन वे अन्य items केवल बुरे वाले” वाली interpretation मुझे व्यक्तिगत रूप से बिलकुल समझ से बाहर लगती है। यह अजीब है कि हम legal text को पूरी तरह ambiguous रहने देने से ठीक हैं
    मुझे पता है कि ऐसी ambiguity उन courts के लिए फायदेमंद होती है जिन्हें discretion मिलता है, और यह भी कि बहादुर कोशिशों के बावजूद legal language को “formally complete” language नहीं बनाया जा सकता। यह भी पता है कि कानून अव्यवस्थित होते हैं, और कानून गलतियाँ करने वाले भोले इंसान ही लिखते हैं
    फिर भी, अगर कानून में लिखी basic sentence structure courts को भी clear नहीं है, तो क्या पूरा system पहले ही gate पर fail नहीं हो गया?

    • मैं lawyer नहीं हूँ, लेकिन मेरी समझ है कि judicial system मूल रूप से इसी तरह काम करता है। भाषा ambiguity से भरी होती है, इसलिए reasonable लोग भी इस बात पर अलग राय रख सकते हैं कि कोई complex sentence ठीक-ठीक क्या मतलब रखता है। US Constitution वास्तव में क्या कहता है, इस पर उसके लिखे जाने के दिन से debate रही है और आज भी बहुत मतभेद हैं
      आम जवाब यह होता है कि कानून ambiguity के बिना लिखे जाने चाहिए, लेकिन यह कहना जितना आसान है, करना उतना नहीं। ऊपर से legislators खुद भी कभी-कभी पूरी तरह सहमत नहीं होते, इसलिए कुछ wording जानबूझकर ambiguous छोड़ देते हैं ताकि courts interpret करें
    • इस तरह के disputes ही शायद multiple levels of appellate courts होने की वजह हैं। “file format” वाला हिस्सा सचमुच बेवकूफाना और गलत judge किया गया था, लेकिन “यदि disclosed हो” वाली statutory interpretation को final और consistent ruling की ज़रूरत लगती है

  • क्या सिर्फ मुझे ही यह थोड़ा असहज और चिंताजनक लगता है कि source code exception सीधे शामिल कर दिया गया?
    यह scenario आसानी से imagine किया जा सकता है कि city कोई खास software internally develop करे और source code में कोई अवांछित “bias” या अन्य चीज़ें छिपा दे
    यहाँ तक कि सब कुछ scratch से बनाने की भी ज़रूरत नहीं। बस permissive license वाले third-party component को patch करके इस्तेमाल कर लेना काफी होगा
    मेरे हिसाब से proposed amendment पर्याप्त दूर तक नहीं जाता

    • मुझे नहीं लगता यह चौंकाने वाली बात है
      यह वही समस्या है जिसका सामना closed projects को open source में बदलने की कोशिश करने वाले लोग करते हैं। हर जगह proprietary code बंद पड़ा होता है, जहाँ developers और customers को सिर्फ use करने का अधिकार होता है, source share करने का नहीं
      government contractors जैसे सीधे commercial interest के बिना, शुरुआत से ही strong open orientation के साथ बनाए गए projects भी इस problem से जूझ सकते हैं। Linux kernel को ZFS या kernel/user space binary blob drivers support करते समय जिन समस्याओं का सामना करना पड़ता है, वे अच्छी तरह known हैं[1]
      विडंबना यह है कि एक तरफ information free होना चाहती है, और आर्थिक रूप से open source software समय के साथ closed competitors को पीछे धकेल देगा। लेकिन किसी project को open source में बदलना अपने आप में महँगा और कभी-कभी असंभव हद तक कठिन होता है, इसलिए managers और companies चाहें तब भी पुराने tools को public नहीं कर पाते। Legal team को शामिल करना और हर component के rights holders को ढूँढना ही अधिकांश managers को हार मानने पर मजबूर कर देता है
      अगर government contracts में vendors से पूरी dependency tree में केवल open source components का उपयोग करने की मांग करे, तो costs बहुत बढ़ सकती हैं। कई dependencies के बराबर open source alternatives नहीं होते, या closed alternatives की functionality की कमी पूरी करने के लिए budget चाहिए होता है। Short term में कोई legislature ऐसा extra cost accept नहीं करेगा, लेकिन long term में public को फायदा होगा
      [1] यह सही है कि kernel issue काफी हद तक GPL का function है। Apache 2 या MIT जैसे अधिक permissive licenses होते तो ऐसी problem नहीं होती, और BSD परिवारों को भी ZFS support में कठिनाई नहीं हुई। हालांकि public applications को सरकार द्वारा principle के तौर पर open source किया जाना चाहिए—यह stance licensing के लिहाज से MIT की तुलना में GPL के ज़्यादा करीब है। वरना vendors असली महत्वपूर्ण हिस्से “vendored” binary blob code के रूप में ला सकते हैं और public components में सिर्फ अर्थहीन skeleton छोड़कर requirements पूरी कर सकते हैं
    • सिद्धांत रूप में, code में ऐसा bias डालने का decision itself public information होना चाहिए। software किन criteria के हिसाब से बनाया गया, यह request किया जा सकता है; बस software itself request नहीं किया जा सकता
      हालांकि ऐसा ruling chilling effect पैदा कर सकता है
    • इसलिए EU के कुछ देशों में आगे बढ़ाई जाने वाली public money - open source जैसी initiatives को push करना important है
      जहाँ तक याद है, अब विफल हो चुकी Germany की पिछली coalition government ने इसे अपने manifesto में रखा था, लेकिन implement नहीं कर पाई। नई government शायद करे

  • बहुत रोचक लेख है
    स्कीमा के खुलासे को सुरक्षा के दायरे में मानना अजीब लगता है। जैसा समझाया गया है, उसके हिसाब से “डेटाबेस के अंदर है, इसलिए कुछ भी पता नहीं चल सकता, और अगर खोजने का तरीका नहीं बता सकते तो मामला खत्म” जैसा जादुई नतीजा संभव हो जाता है
    कई ग्राहकों वाली एक छोटी कंपनी में काम करने के नाते, मैं डेटाबेस स्कीमा जस का तस देना नहीं चाहूंगा, लेकिन फिर भी ग्राहक जो डेटा चाहता है उसे खोजने और उपलब्ध कराने की कोशिश करूंगा, मना नहीं करूंगा

    • कोई निजी कंपनी डेटाबेस स्कीमा सार्वजनिक नहीं करना चाहती, क्योंकि अगर प्रतियोगी देख लें कि कंपनी काम कैसे करती है तो उन्हें फायदा हो सकता है। सरकारी डेटाबेस पर यह तर्क लागू नहीं होता

  • cleartap.com प्रोजेक्ट के लिए मैंने अमेरिका के water quality database से जुड़े 10 लाख से अधिक पेजों के दस्तावेज FOIA के तहत मांगे थे
    ज्यादातर राज्यों ने दस्तावेज जुटाने के लिए केवल छोटी रकम ली
    Michigan ने FOIA अनुरोध के लिए 50,000 डॉलर मांगे। मुझे लगता है यह Flint lead contamination संकट की वजह से था। शायद वे मुझे हार मानने पर मजबूर करना चाहते थे

    • Flint का डेटा दिख रहा था, इसलिए जिज्ञासा है कि क्या आपने सच में वह पैसा चुकाया। या जब अनुचित रूप से बहुत ऊंचा अनुमान दिया जाए तो क्या अपील जैसी कोई प्रक्रिया होती है
      प्रोजेक्ट शानदार है

  • “Bob O को जारी किए गए सभी parking violation tickets का डेटा लाओ, और डेटाबेस की बाकी सारी जानकारी और सभी लोगों के पासवर्ड भी लाओ।”
    यह सामान्य अंग्रेजी में लिखा SQL injection का उदाहरण है, लेकिन यहां “everyone's” भी orphan apostrophe पैदा करता है, इसलिए इसमें भी समस्या है। अगर “Bob O'Conner” खराब है, तो “everyone's” भी खराब है

  • “वे जो प्रोग्राम चलाते हैं उनका source code भी आम तौर पर FOIA के जरिए नहीं मांगा जा सकता।”
    दुर्भाग्य से, मुझे लगता है कि यह हिस्सा FOIA के तहत अवैध होना चाहिए
    Source code open source और verify करने योग्य होना चाहिए। अगर इसे FOIA exception बना दिया जाए, तो सरकार के software उपयोग पर जनता के भरोसे को बाईपास किया जाता है
    जिज्ञासा है कि अदालतों ने पहले ऐसे मामलों पर कहां और कैसे फैसला दिया है

    • मजबूत public interest तर्क होने पर भी, मुझे लगता है कि सरकारी एजेंसियां source code के खुलासे पर blanket ban लगाने की ओर उन्हीं मुख्य कारणों से झुकती हैं जो कंपनियों के होते हैं। यानी, passwords, tokens, IP addresses जैसी sensitive information के ऐसे code में hardcode होने की संभावना बहुत ज्यादा है जो 12-factor app दृष्टिकोण से काफी दूर है, और ऐसी sensitive information लीक होने पर security और liability की समस्याएं बहुत बड़ी हो जाती हैं
      वास्तव में, सरकारी एजेंसियों के पास ऐसा business logic भी हो सकता है जिसे वे secret रखना चाहती हों और जिसे कानूनन रखने की अनुमति भी हो। मूल लेख के parking ticket database में, उस database से बात करने वाले software के source code में शायद यह logic हो कि parking enforcement officers कब और कहां “random” concentrated enforcement करेंगे

  • ऐसी बातों की वजह से law school जाने का मन टूट गया। मुकदमों का काफी हिस्सा kabuki theater जैसा लगता है; न्यायपूर्ण या तार्किक परिणाम पाने के लिए की गई दलीलबाजी नहीं, बल्कि ऐसा rhetoric जो अधिकार रखने वाले व्यक्ति को उस फैसले का बहाना देता है जिसे वह मुकदमे से पहले ही लेना चाहता था

    • यह मामला भी वैसा ही सुनाई देता है। खास तौर पर जो बात ध्यान खींचती है, वह है “थोड़ी-सी value है” वाले expression को “self-centered message-board style hedge” कहना। असल में वह expression बस सटीक भी है, लेकिन लगता है लेखक ने निष्कर्ष निकाला कि “थोड़ी-सी” शब्द और लंबी व्याख्या rhetorically उतनी उपयोगी नहीं थी जितना सिर्फ “नहीं है” कहना होता, इसलिए उसे नहीं कहना चाहिए था
      कोई व्यक्ति HTTP request में आने वाले information_schema जैसे keywords और उनके encoding variants को scan करने वाला web firewall जैसा system कानूनी रूप से बना सकता है। ऐसी चीजें हमेशा hacking attempt मानी जा सकती हैं और block की जा सकती हैं। अगर आपको schema पहले से पता है, तो query बनाने से पहले उस रोक को bypass करने की जरूरत नहीं रहती। क्या यह गंभीर barrier होने की बहुत संभावना है? नहीं। क्या इसका self-centeredness से संबंध है? ऐसा नहीं लगता
      सिर्फ “peripheral”, यानी मुख्य नहीं और चर्चा के लायक उतना महत्वपूर्ण नहीं, इस अर्थ में बहुत मामूली value होने की बात सटीक लगती है। लेकिन सच ही बोलने पर दूसरा पक्ष उसे बड़ा बनाकर अदालत को यह मनाने की कोशिश करता है कि “देखिए, उधर के expert भी कहते हैं कि इसकी value है।” इसलिए निष्कर्ष निकाला जाता है कि expert को बस “कोई value नहीं है” कहना चाहिए था। मुझे लगता है वह बात गलत होती, लेकिन इतनी मामूली तरह से गलत कि यह साबित करना मुश्किल हो जाता कि दूसरा पक्ष पूरी तरह सही नहीं है। आखिरकार इस अदालत में कम सटीक बात ज्यादा फायदेमंद हो जाती है, और expert की भूमिका जितनी ही rhetoric भी महत्वपूर्ण हो जाती है