Seattle शहर ने गलती से 40 डॉलर में 3.2 करोड़ ईमेल उपलब्ध करा दिए (2018)

 (mchap.io)
1 पॉइंट द्वारा GN⁺ 2023-10-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक public records requester ने 2017 के seattle.gov ईमेल के केवल metadata—जैसे sender, recipient, cc, time और date—की मांग की थी, लेकिन Seattle शहर ने लगभग 3.2 करोड़ ईमेल के पहले 256 अक्षरों तक शामिल करने वाली फाइलें दे दीं
  • Seattle IT ने शुरुआत में समीक्षा के लिए 320 कर्मचारी-वर्ष और वेतन में 3.3 करोड़ डॉलर लगने का अनुमान लगाया था, लेकिन बाद में कहा कि body के बिना metadata होने के कारण समीक्षा की जरूरत नहीं है, और पहली किस्त की लागत घटाकर 1.25 डॉलर कर दी
  • public records portal पर अपलोड की गई करीब 400 फाइलों में usernames/passwords, credit card numbers, Social Security numbers, driving licences, police/FBI investigation information, Zabbix alerts जैसी sensitive information मिली-जुली थी
  • requester ने समस्या बताई तो Seattle ने GovQA access अस्थायी रूप से रोक दिया और कहा कि वह corrected version को फिर से process करेगा; बाद में उसने file deletion, Kroll के जरिए hard disk scan, और legal release की शर्तें प्रस्तावित कीं
  • आखिरकार requester ने files delete कीं, affidavit और disk cleanup steps पूरे किए, और Seattle ने 26 जनवरी 2018 से मूल रूप से मांगा गया metadata किस्तों में देना शुरू किया; लिखे जाने के समय तक 2.7 करोड़ रिकॉर्ड दे दिए गए थे

public records request की शुरुआत

  • requester ने Chicago mayor’s office के phone और email metadata का अनुरोध करने के अनुभव के बाद, public records requests को आगे बढ़ाया ताकि देखा जा सके कि ऐसी ही समस्या अमेरिका के कई इलाकों में systematically दिखती है या नहीं, और communication structure को map किया जा सके
  • उसने पूरे अमेरिका में email metadata के लिए 100 से अधिक requests जमा कीं, और हर state में कम से कम 2 requests कीं
  • पहला बड़ा batch मनमाने ढंग से चुने गए 14 राज्यों के सबसे बड़े शहरों को भेजा गया था, और जिन जगहों पर उसने request को अंत तक आगे बढ़ाने की कोशिश की, वे सिर्फ Houston और Seattle थीं
    • Houston ने अपेक्षाकृत जल्दी response दिया और 60 लाख email metadata records डाक से भेजे
    • Seattle request आगे चलकर कहीं ज्यादा जटिल मामला बन गई

Seattle को भेजी गई मूल request

  • 2 अप्रैल 2017 को requester ने Seattle IT department से 2017 के दौरान Seattle-owned email addresses से आए-जाए सभी emails का metadata मांगा
    • From address
    • To address
    • bcc addresses
    • cc addresses
    • Time
    • Date
  • requester के हिसाब से तकनीकी रूप से यह request एक single-line PowerShell command से पूरी की जा सकती थी, लेकिन policy level पर आमतौर पर इससे तीखा विरोध होने की उम्मीद थी
  • Seattle का पहला response था कि पिछले 90 दिनों में seattle.gov addresses से भेजे गए 55 लाख emails और प्राप्त हुए 2.68 करोड़ emails हैं, इसलिए साझा करने से पहले समीक्षा के लिए records की संख्या बहुत अधिक है
  • requester ने कहा कि वह body नहीं, केवल metadata मांग रहा है, इसलिए review volume तुलनात्मक रूप से छोटा होना चाहिए, और लगभग 3.2 करोड़ records की पूरी request बनाए रखी

3.3 करोड़ डॉलर की लागत का अनुमान

  • Seattle ने request को दोबारा लिखते समय ऐसे शब्द इस्तेमाल किए जिनसे लगता था कि मूल scope बदल गया है
    • मूल request metadata तक सीमित थी, लेकिन rewritten wording ईमेल के contents तक शामिल करने वाले scope जैसी दिखती थी
    • requester ने कहा कि उसे नहीं पता कि यह बदलाव क्यों हुआ
  • Seattle IT ने अनुमान लगाया कि हर email की समीक्षा में 30 seconds से 2 minutes लगेंगे, और पूरे काम में लगभग 320 कर्मचारी-वर्ष और salary में 3.3 करोड़ डॉलर लग सकते हैं
  • requester ने आकलन किया कि बड़ी public records requests को आमतौर पर “unduly burdensome” बताकर reject किया जाता है, लेकिन इस scale का cost estimate बहुत दुर्लभ है
  • storage cost भी अलग से बताई गई
    • Seattle का मानना था कि requested data 8–10TB हो सकता है, और वे FTP server बनाकर download उपलब्ध करा सकते हैं
    • internal cost model के अनुसार वे सालाना 2,480 डॉलर और प्रति GB 2.11 डॉलर charge कर सकते थे; 10TB होने पर सालाना 21,606.40 डॉलर लगेंगे, ऐसा calculate किया गया
    • requester ने इसकी तुलना इस बात से की कि Houston का email metadata dump 1.2GB था, और उस समय Seattle public records request data storage के लिए Amazon S3 इस्तेमाल कर रहा था
    • उस समय S3 pricing 0.023 डॉलर प्रति GB थी
  • Seattle ने request तुरंत close नहीं की और पूछा कि क्या इसे जारी रखना है; requester ने 29 मई को पूछा कि उसे कितने records मिलेंगे, लेकिन कोई जवाब नहीं मिला

cost estimate वापस लेना और 1.25 डॉलर की पहली किस्त

  • 5 जून को Seattle ने माना कि शुरुआती cost estimate गलत था, और 3 महीनों में से 1 और 2 जनवरी—दो दिनों—के records की पहली किस्त के लिए 1.25 डॉलर मांगे
  • बताया गया कि supplied file में email body के बिना केवल मांगा गया metadata होगा, एक Excel spreadsheet के रूप में, इसलिए review की जरूरत नहीं है और इसे पहले बताए 320 वर्षों से जल्दी उपलब्ध कराया जा सकता है
  • requester ने हर दो दिन की किस्त के लिए अलग cheque मांगने के तरीके को request को जानबूझकर मुश्किल बनाने के रूप में देखा, और पहले ही 14 cheques भेज दिए
    • पहले 13 cheques प्रत्येक लगभग 1.25 डॉलर के थे
    • बाद में Seattle ने कोई अतिरिक्त single payment नहीं मांगा
  • दो महीने तक कोई बड़ी खबर नहीं आई, और Seattle ने सभी cheques encash करने के बाद public records portal account बनाया

GovQA portal में सामने आया बड़ा leak

  • 22 अगस्त को requester ने उस email account को फिर से अपने phone में add किया और देखा कि request पूरी हो चुकी है
  • Seattle के public records request portal पर लगभग 400 files download के लिए उपलब्ध थीं, और कुल मिलाकर उनमें लगभग 3.2 करोड़ emails का metadata था
  • सबसे बड़ी समस्या यह थी कि हर email के पहले 256 characters भी साथ में शामिल थे
  • files में निम्न जानकारी मिली-जुली थी
    • usernames और passwords
    • credit card numbers
    • Social Security numbers और driving licences
    • ongoing police investigations और arrest reports
    • affair से जुड़े text messages की content
    • FBI investigation
    • Zabbix alerts
  • requester ने माना कि यह dataset बेहद निजी जानकारी से भरा बड़ा dataset है, और Privacy Act of 1974 तथा Washington state के public records कानूनों सहित कई laws का उल्लंघन होने की काफी संभावना है
  • सही कारण जानना मुश्किल है, लेकिन उसने संभावना जताई कि request wording के rewrite और मूल public records officer की छुट्टी के overlap से communication breakdown हुआ होगा

समस्या उठाना और Seattle की शुरुआती प्रतिक्रिया

  • requester चाहता था कि Seattle खुद अपनी गलती समझे, इसलिए उसने जवाब दिया कि दिए गए records मूल request से मेल नहीं खाते और request से कहीं ज्यादा information शामिल करते हैं, इसलिए उन्हें फिर से review किया जाए
  • Seattle ने जवाब दिया कि requested information report के specific columns में है, और records system report से generated हैं, इसलिए उन्हें सिर्फ requested fields तक सीमित नहीं किया जा सकता
    • From address J column में है
    • To address K column में है
    • bcc address M column में है
    • cc address L column में है
    • Time and date R column में हैं
  • Seattle ने माना कि उसका कोई दायित्व नहीं है कि वह नए records बनाए जो exist नहीं करते, और request का जवाब देने वाले सभी records उपलब्ध करा दिए गए हैं, इसलिए request close है
  • जब requester ने leak हुई information के बारे में specifically बताया और कहा कि वह Washington Office of Privacy and Data Protection के सामने मुद्दा उठाएगा, तो Seattle ने इसे inadvertent error माना
  • Seattle ने cause investigation के लिए GovQA access temporarily suspend कर दिया, और बताया कि corrected records अगले हफ्ते GovQA के जरिए उपलब्ध कराए जाएंगे
  • साथ ही requester से कहा गया कि वह उन records की review, sharing, copying या use न करे

CTO और Chief Privacy Officer के साथ call

  • इसके बाद requester Seattle Open Data Slack से जुड़े लोगों के जरिए Seattle के CTO और Chief Privacy Officer वाली conference call में शामिल हुआ
  • call में चर्चा हुई कि क्या हुआ था और records को कैसे handle किया जाना चाहिए
  • requester के अनुसार, जब वह पूछ रहा था कि क्या वह emails रख सकता है, तभी उसका internet connection टूट गया; करीब 10 minutes बाद वापस जुड़ने पर call का माहौल बदल चुका था
  • Seattle ने ये शर्तें रखीं
    • सभी files delete करना
    • Kroll को hire कर hard disk scan कराना और deletion prove करना
    • 1 और 2 से सहमत होने पर पूर्ण legal release देना
  • requester ने इससे सहमति नहीं दी, और बाद में lawyers के बीच बात करने का फैसला हुआ

कानूनी दबाव और deletion confirmation

  • call के बाद requester के lawyer ने Seattle के lawyer से संपर्क किया, और requester के अनुसार Seattle Computer Fraud and Abuse Act से जुड़े charges consider करने जैसे approach पर था
  • requester ने इसे problematic माना कि Seattle द्वारा भेजी गई information के बावजूद मामला इस तरह treat किया जा रहा था, और आखिरकार files delete कर दीं
  • इसके बाद लगभग एक महीने तक ज्यादातर discussions दोनों पक्षों के lawyers के बीच हुईं
  • requester ने affidavit प्रस्तावित किया जिसमें बताया गया कि घटना कैसे हुई, files कैसे delete की गईं, और deletion verification कैसे होगा
  • Seattle ने affidavit से मोटे तौर पर सहमति जताई, लेकिन unused disk space को random bits से overwrite करने वाली bash script चलाने जैसे अतिरिक्त assurance steps मांगे
  • requester ने अंततः zerofree और fstrim चलाए, और Seattle ने affidavit स्वीकार कर लिया
  • उसके बाद legal threats आगे जारी नहीं रहीं

बाहरी रिपोर्टिंग और Seattle की notification

  • call के लगभग एक हफ्ते बाद, Seattle city employee ने इस घटना की जानकारी Seattle के KIRO7 को दी
  • KIRO7 की investigation में सामने आया कि Seattle ने leak के बारे में अभी notification नहीं दी थी, जबकि Washington state public records request law के तहत यह जरूरी कदम था
  • KIRO7 investigation के बाद ही Seattle ने employees को email leak के बारे में notify किया
  • संबंधित रिपोर्ट KIRO7 article में प्रकाशित हुई
  • एक हफ्ते बाद Crosscut article ने Seattle IT department के इतिहास सहित अधिक विस्तार से मामला कवर किया
  • 19 जनवरी को Seattle CTO Michael Mattmiller ने resign कर दिया; requester ने कहा कि resignation email leak से related था या नहीं, कहना मुश्किल है, लेकिन timing की वजह से इसका उल्लेख करना उचित है

अंतिम metadata delivery

  • 26 जनवरी 2018 से Seattle ने मूल रूप से मांगा गया email metadata installments में देना शुरू किया
  • लिखे जाने के समय तक 2.7 करोड़ email metadata records उपलब्ध कराए जा चुके थे
  • जिन departments ने अभी तक metadata नहीं दिया था, वे दो थे: Police Department और Human Services
  • raw data Kaggle dataset से लिया जा सकता है
  • dataset में processing और analysis को मुश्किल बनाने वाली चीजें अभी भी मौजूद हैं
    • triple quotes, semicolons, commas आदि मिले-जुले हैं, इसलिए data बहुत messy है
    • लाखों system alerts शामिल हैं
    • seattle.gov के भीतर communication के लिए दो अलग-अलग metadata records हैं
  • requester इस data को public records law के context में इस्तेमाल करने के proof-of-concept पर काम कर रहा है, और उसने एक दिन के metadata को Gephi में visualize किया
    • layout Yifan Hu है
    • k-core minimum 5 और minimum degree 5 से filter किया गया
  • उसने network modeling में मदद कर सकने वाले लोगों से contact करने को कहा

Washington state legislative controversy और आगे की योजना

  • 23 फरवरी को, metadata की पहली और दूसरी किस्त के बीच, Washington state legislature ने SB6617 पास करने की कोशिश की
  • SB6617 एक bill था जो email exchanges सहित कई records को Washington state public records law की disclosure obligations से बाहर करता था
  • यह bill पहली reading के 24 घंटे से भी कम समय में House और Senate से pass होकर governor’s office भेज दिया गया
  • Seattle Times ने संबंधित विषय को article में cover किया
  • Washington governor’s office को 6,300 से अधिक phone calls, 100 letters और 12,500 से अधिक emails मिले, और governor ने आखिरकार bill को veto कर दिया
  • जब requester ने पूछा कि क्या यह controversy metadata installments में delay से related है, तो Seattle ने जवाब दिया कि इसका संबंध नहीं है; उन्होंने progress रोक रहे bug को fix कर दिया है और उस week additional records भेजेंगे
  • एक महीने बाद Seattle ने बाकी installments भेजना शुरू किया
  • requester कई शहरों का email metadata और हासिल कर रहा है, और आगे public records requests की basics तथा digital records requests के बारे में और लिखने की योजना रखता है
  • अगला लेख January 2017 email metadata को लेकर White House OMB के खिलाफ चल रहे lawsuit पर होगा, और बताया गया कि पहली court date पर defendant side का counsel उपस्थित नहीं हुआ

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

1 टिप्पणियां

 
GN⁺ 2023-10-26
Hacker News राय

  • इस कहानी का सबसे दिलचस्प हिस्सा गलती से सार्वजनिक हुए रिकॉर्ड्स को अपने पास बनाए रखने का कानूनी जोखिम है
    अगर लेखक ने शहर को यह न बताया होता कि “आपने अपेक्षा से कहीं ज़्यादा संवेदनशील जानकारी सार्वजनिक कर दी है”, तो शहर को शायद कभी गलती का पता नहीं चलता और लेखक उस डेटा के साथ जो चाहता कर सकता था
    लेकिन जैसे ही उसने बताया, शहर को पता चल गया कि डेटा ऐसे व्यक्ति के हाथ में पहुंच गया है जिसके पास access permission नहीं होनी चाहिए थी, और यह कानूनी सवाल खड़ा हो गया कि क्या उसे वह डेटा रखने का अधिकार है
    भौतिक संपत्ति या पैसे के मामले में, स्पष्ट गलती से मिली चीज़ का क्या करना चाहिए, इस पर काफी case law है। अगर कोई car dealer नई कार गलत पते पर छोड़ दे और बाद में पता चले कि असल में पता कोई और था, तो आप वह कार नहीं रख सकते; और अगर bank account में गलती से 100,000 डॉलर जमा हो जाएं, तो वे वापस ले लिए जाते हैं
    लेकिन डेटा, यानी जानकारी, के बारे में क्या? मुझे लगता है कि trade secrets जैसी कुछ डेटा categories के लिए यह कानूनी दलील काफी मजबूत है कि आपको उन्हें अपने पास न रखने का आदेश दिया जा सकता है
    इसलिए भले ही यह स्थिति शहर की भारी गलती से बनी थी, लेखक का शहर के अनुरोध में सहयोग करने का फैसला सही लगता है। बस अफसोस यह है कि शहर ने समस्या बताने के लिए उसे reward देने के बजाय, अपनी गलती संभालने में सहयोग न करने पर उसे धमकाने की कोशिश की

    • अगर कोई व्यापारी बिना order किया सामान डाक से भेजता है, तो आप वह सामान रख सकते हैं
      https://about.usps.com/publications/pub300a/pub300a_v04_revi...
      https://faq.usps.com/s/article/What-Options-Do-I-Have-Regard...
      गलत delivery से मिले सामान के मामले पर अतिरिक्त चर्चा भी है
      https://law.stackexchange.com/questions/17533/if-a-retailer-...
    • शहर को न बताना बेहद जोखिम भरा होता। अगर शहर को बाद में गलती का पता चलता, तो उन्होंने शायद माना होता कि OP ने न बताकर दुर्भावना से काम किया
      अगर आपको लगता है कि बताने के बाद उसके साथ अच्छा व्यवहार नहीं हुआ, तो कल्पना कीजिए कि न बताने पर कितना ज़्यादा बुरा हो सकता था
      और यह निष्कर्ष भी ज़रूरी नहीं कि वह डेटा के साथ अपनी मर्जी से कुछ भी कर सकता था। अगर उसने अतिरिक्त डेटा सार्वजनिक किया होता, तो उसके बड़ी मुश्किल में पड़ने की संभावना ज्यादा थी
    • उद्धृत call की बातों को ही देखें तो शहर काफी good faith में प्रतिक्रिया दे रहा था, जबकि OP उन्हें उकसाता-सा दिखा और third-party auditor के साथ सहयोग करने से इनकार करता नजर आया
      अब भी अंततः डेटा delete हुआ है, यह मानने के लिए उसके signed affidavit पर कुछ हद तक भरोसा करना पड़ रहा है
    • अमेरिका में, मेरी जानकारी में, personal data पर कोई codified rights नहीं हैं। ऊपर से अमेरिकी copyright रिकॉर्ड की सूचियों जैसे databases पर लागू नहीं होता
      इसलिए गलती से मिले रिकॉर्ड्स अपने पास रखने के लिए मुकदमा चलाने का कोई स्पष्ट कानूनी ढांचा है या नहीं, यह अस्पष्ट है। भौतिक संपत्ति या copyright-योग्य कुछ डेटा की बात अलग होगी
    • “वह उस डेटा के साथ जो चाहे कर सकता था” — यह काफी मजबूत दावा लगता है

  • सरकारी IT महंगा होने के लिए मशहूर है, और कई बार आपदा जैसा भी होता है। हाल ही में मुझे एक local agency में account बनाना पड़ा, और trial-and-error से पता चला कि web form के दो date input fields अलग-अलग formats मांगते हैं
    अंततः मुझे login details मिल गईं, लेकिन वे काम नहीं कर रही थीं; मैंने सोचा password issue होगा और reset दबाया, तो 404 error आया
    प्रभारी व्यक्ति बहुत विनम्र थे, लेकिन agency की ओर से तीन बार reset करने के बाद ही मैं login कर पाया
    अगर किसी private company में ऐसी समस्याएं होतीं, तो वह बंद हो जाती। सरकार शायद फिर किसी और अक्षम व्यक्ति को hire करेगी, और उसे जीवन भर की नौकरी मिल जाएगी

    • सरकार ने शायद “anti-corruption” या “fair dealing” जैसे नियमों के कारण यह काम bid करने वाली अकेली company को outsource कर दिया होगा
      बेशक उस outsourcing company को सच में accountable बनाने का कोई तरीका नहीं होगा
    • क्या आप किसी सक्षम IT professional को जानते हैं जो उस salary पर सरकार में काम करना चाहता हो? कोई नहीं
      इसलिए government IT बहुत अच्छा नहीं होता। काम करने का माहौल खराब है, और compensation भी private sector के मुकाबले अच्छा नहीं है
    • मैंने पहले Experian website पर signup करने के लिए form को खुद modify किया था, क्योंकि बेवकूफ UI सही format की date डालने ही नहीं दे रहा था
    • इस साल नई नौकरी में आने पर मेरा I-9 form reject हो गया, और पता चला कि दो date input fields अलग-अलग formats इस्तेमाल कर रहे थे। वजह पता लगाने के लिए मुझे खुद debugging करनी पड़ी

  • पहले मैंने open data के क्षेत्र में काफी काम किया है, और एक बड़े शहर की सरकार के open data विभाग में भी काम किया है
    इस तरह का व्यवहार उस उद्देश्य में बिल्कुल मदद नहीं करता। यह बस इस धारणा को और मजबूत करता है कि open data और सूचना-प्रकटीकरण के अनुरोध समय और संसाधनों की भारी बर्बादी हैं, और बिना खास वजह कानूनी जोखिम खोल देते हैं
    यह सोचना भी काफी हैरान करने वाला है कि सरकारी ईमेल metadata वैध open data है। क्या आपको लगता है कि आपने सरकार को कितनी बार ईमेल भेजे और जवाब पाए, और किन विभागों से आपका संवाद हुआ—यह सब सार्वजनिक होना चाहिए? मुझे ऐसा नहीं लगता

    • सतह पर तो मैं सहमत हूं। लेकिन गहराई से देखें तो दूसरी सरकारी एजेंसियों के पास पहले से ही ईमेल और फोन का सारा metadata है
      अगर उनके पास आपका metadata होना ठीक है, लेकिन आपके पास उनका metadata होना ठीक नहीं है, तो यह एक अजीब असमानता बन जाती है
      यह पूरी तरह दर्पण-छवि जैसा मामला नहीं है, लेकिन अगर OP यह दिखाए कि यह metadata कितना शक्तिशाली है और दोनों पक्षों को इस तरह का metadata इकट्ठा नहीं करना चाहिए—इस बात को आगे बढ़ाए—तो मुझे ऐसे सूचना-प्रकटीकरण अनुरोध का एक वैध उपयोग दिखता है
    • यह open data नहीं है। open data वह data है जिसे विवेकाधिकार से प्रकाशित किया जाता है, और वही data अगर FOIA request के जरिए मिले तो अक्सर कानूनी रूप से redaction/छिपाने की जरूरत होती है
      ऐसी चीजें हमेशा होती रहती हैं। इससे भी बुरी बात यह है कि ऊंचे पदों पर बैठे लोग—जैसे Chief Data Officers—अक्सर legal team की वजह से प्रेस या पास की संस्थाओं से संपर्क नहीं कर पाते। सच में, एक CDO ने मुझसे कहा था, “मैं आपसे बात नहीं कर सकता”
      open data के बारे में मैं अक्सर जो वाक्य इस्तेमाल करता हूं वह है: “open data एक झूठ है।” आखिरकार, open dataset के रूप में जो दिया गया है, वह columns और rows दोनों में पूरा है या नहीं, इसे सत्यापित करने का कोई कानूनी तरीका नहीं होता
      जानकारी छूटी है या नहीं, और अगर छूटी है तो क्यों—यह तक बहुत कम मामलों में समझाया जाता है। नतीजतन जनता वास्तविक स्थिति को गहराई से गलत समझती है, और कई बार ऐसा जानबूझकर किया जाता है क्योंकि लोगों को डर होता है कि जनता data को गलत समझेगी
      इसलिए अंत में FOIA तक जाना पड़ता है और कानूनी लड़ाई तक करनी पड़ती है। मेरे करीब 10 FOIA मुकदमे करने की एक वजह है
      सार यह है कि open data अच्छा है, लेकिन उसमें कठोरता और जवाबदेही की कमी है, इसलिए जिस काम में गहराई चाहिए, उसके लिए वह असल में बेकार है
    • स्वीडन में जब आप web form या डाक के जरिए सरकार से संपर्क करते हैं, तो चेतावनी दी जाती है कि कानून के तहत सारी बातचीत public record का हिस्सा बन जाती है
      इसमें metadata और content दोनों शामिल होते हैं, और बताया जाता है कि ऐसी संवेदनशील बातें न डालें जिन्हें आप सार्वजनिक नहीं करना चाहते

  • पढ़कर मजा आया
    दूसरी तरफ से system administrator के रूप में काम कर चुके व्यक्ति के तौर पर, मैं लगभग अंदाजा लगा सकता हूं कि उसके शुरुआती अनुरोध को कैसे लिया गया होगा
    कई मामलों की तरह, उन्होंने शायद अनुरोध का केवल एक हिस्सा पढ़ा होगा और पैमाने से घबरा गए होंगे। इसलिए उनके दिमाग में यह बात बैठ गई होगी कि वह बहुत ज्यादा जानकारी मांग रहा है, और गलत धारणा के आधार पर कई दिनों तक water cooler के पास उस व्यक्ति का मजाक उड़ाया होगा
    आखिर में शायद किसी ने गलतफहमी समझी होगी, और email headers parse करने के बजाय hardcoded values से काटे गए headers export करने की घातक गलती कर दी होगी
    और जब उसने इस समस्या की ओर इशारा किया, तभी उन्होंने उसे गंभीरता से लेना शुरू किया होगा

    • मैं भी system administrator हूं, और दुर्भाग्य से ऐसा रवैया परिचित लगता है। कुछ IT संगठन सच में ऐसा toxic environment बना देते हैं जहां जिन लोगों को उन्हें support करना चाहिए, उनका मजाक उड़ाना आम हो जाता है
      मेरा मतलब यह नहीं है कि हर अनुरोध पर IT संगठन को बिना शर्त झुक जाना चाहिए, या वास्तविक दुर्व्यवहार के सामने भी शिष्ट बने रहने की उम्मीद करनी चाहिए
      लेकिन water cooler के पास होने वाली toxic चुगली वैसी चीज नहीं है। वह सीधे-सीधे लोगों की बुद्धि का अपमान करना है, या खासकर जब उपयोगकर्ताओं पर शक्ति का इस्तेमाल हो रहा हो, तब लोगों की परेशानी का आनंद लेना है

  • मुझे याद आता है कि हमारे county के Assessor ने केवल इसलिए पुलिस बुलाने की धमकी दी थी क्योंकि मैंने कहा था कि मुझे public data चाहिए
    जिन records के लिए सिर्फ replication cost लेनी चाहिए थी, उनके लिए वे कई हजार डॉलर ज्यादा वसूलने की कोशिश भी कर रहे थे, और इसके अलावा भी कई चीजें हुई थीं
    सार्वजनिक संस्थाओं से निपटना सचमुच बड़ा मजेदार काम है

  • यूरोप में इस तरह की request को लोगों से जुड़ी जानकारी माना जाता है—यानी किसने किससे किस तारीख और समय पर संपर्क किया—

    1. भेजने वाले का address
    2. पाने वाले का address
    3. BCC address
    4. CC address
    5. समय
    6. तारीख
      इसे store करना, processing करना तो दूर, केवल तभी अनुमति है जब इसे जानने की ज़रूरत हो
      भले ही कोई यह तर्क दे कि Seattle की ओर से काम करने वाले सरकारी कर्मचारी अब private individuals नहीं हैं, यह पहले ही बहुत खींची हुई व्याख्या होगी; और उस स्थिति में भी Seattle government domain के बाहर के सभी email address, court order, कारण, और criminal investigator होने की शर्त के बिना पूरी तरह निषिद्ध क्षेत्र हैं
      आह, privacy protection
    • अमेरिका में सरकारी कर्मचारियों द्वारा भेजे और प्राप्त किए गए email आम तौर पर public records माने जाते हैं। transparency के लिए यह महत्वपूर्ण है
    • email address भी social security number जैसी समस्या से जूझते हैं। उन्हें शुरू से private information के रूप में design नहीं किया गया था, लेकिन उन पर वही भूमिका लाद दी गई
      और शहर हमेशा निजी जानकारी को बेफिक्र होकर सार्वजनिक कर देते हैं। private address या शहर के भीतर property owners public records के दायरे में आते हैं, और शहर को मांगने वाले किसी भी व्यक्ति को नाम और address देने में खास दिक्कत नहीं होती
      email address उससे कहीं कम जोखिम वाले हैं
    • public records जनता के लिए होते हैं। मुझे यह बात पसंद भी है और नापसंद भी
      यह बात समझ में आती है कि नागरिकों को यह जांचने में सक्षम होना चाहिए कि सरकार क्या कर रही है। दुर्भाग्य से सरकार बहुत ज़्यादा चीज़ें record करती है; कभी लगता है कि काश वे record ही न करतीं, और बेहतर तो यह होता कि वे records public disclosure के दायरे में न आते
      अगर आपको यह request खराब लगती है, तो LexisNexis का इतिहास देखना चाहिए। उनका core business data request करके उसे एक database में इकट्ठा करना है, ताकि अमेरिकी सरकार जिस किसी के बारे में धुंधली-सी जानकारी रखती हो, उस पर background check किया जा सके
      पहले masscorruption नाम की एक site भी थी, जिसे, मेरी याद में, Massachusetts की एक county government पर अटके हुए किसी व्यक्ति ने चलाया था। उसने government desktops पर मौजूद हर image file के लिए FOIA request डाली, सचमुच वे files पा भी लीं, और उन कर्मचारियों की private images publish कर दीं जिन्हें government computers पर stored नहीं होना चाहिए था
      मेरे workplace में, जब भी मैं recipients field में किसी government employee को डालता हूं, Outlook में एक banner दिखता है कि लिखा जा रहा message FOIA के दायरे में आ सकता है। खासकर local government में, सच में पता नहीं होता कि कौन-सी बात लोगों को सक्रिय कर देगी और वे किस चीज़ में रुचि लेने लगेंगे
    • कुल मिलाकर सहमत हूं
      लेखक “metadata” को शायद बिल्कुल अलग तरह से देखता है
      मेरे हिसाब से metadata का मतलब “emails की मोटे तौर पर संख्या”, हो सके तो “address blocks”, “बहुत broadly averaged time ranges”, और शायद “बहुत vague categories” तक है
      किसने भेजा, किसे गया, BCC और CC में कौन था—यह मेरे मानक के metadata से अलग है
    • बात सही है, लेकिन याद रखना चाहिए कि ये government employees हैं। वे जो भी काम करते हैं, वह definition के हिसाब से public record है
      कानून के तहत हर action और communication का record रखना होता है, और कोई भी उसे देख सकता है
      सख्ती से कहें तो government resources का इस्तेमाल private communication के लिए नहीं होना चाहिए, और कानूनी तौर पर private communication channels का इस्तेमाल public work के लिए भी नहीं होना चाहिए

  • लेख के मुख्य point से अलग, सच में जिज्ञासा है: क्या इतने सारे लोग तुरंत “मेरे lawyer” को बुला सकते हैं?
    लेख में कहा गया है कि Seattle ने खुद भेजी हुई जानकारी को लेकर Computer Fraud And Abuse Act(CFAA) charges आगे बढ़ाने जैसा रुख अपनाया, इसलिए लेखक ने अपने lawyer से opposing lawyer से संपर्क करवाया

    • आम तौर पर इसे common कहना मुश्किल है। लेकिन जो व्यक्ति public records requests बहुत करता है, उसके पास lawyer होना चौंकाने वाला नहीं है
      जिन jurisdictions को मैं जानता हूं, वहां request को reject करने या अनुचित लगने वाली fees मांगने पर lawsuit ही practical तौर पर मुख्य remedy होता है
    • मुझे लगता है यह काफी common है। इसका मतलब जरूरी नहीं कि lawyer “on standby” हो, लेकिन आपके काम के हिसाब से अलग-अलग क्षेत्रों के lawyers से संपर्क बन जाता है
      संदेह हो तो अपनी situation जानने वाले व्यक्ति के साथ ही आगे बढ़ना बेहतर होता है
      उदाहरण के लिए, मेरे पुराने rented घर में कुछ issues थे, और उस process में मैं tenants protection association Mieterschutzbund में शामिल हुआ। इसके जरिए मुझे association expert से 1 घंटे की consultation और tenant law specialist lawyer से भी 1–2 घंटे की consultation मिल सकती है
      यह process आम तौर पर सिर्फ 1–2 दिन लेता है, इसलिए कह सकते हैं कि मेरे पास effectively rental lawyer standby पर है
    • काफी common है। मेरी पत्नी और मेरा एक lawyer दोस्त है जो छोटे-मोटे काम संभाल देता है, और अगली बार साथ में बाहर खाने पर उसका खाना खिलाने जैसी बहुत कम cost में मदद कर देता है
      बदले में मैं उसके घर की aluminium wiring वाली electricity ठीक कर देता हूं

  • archived copy: https://web.archive.org/web/20231024164822/https://mchap.io/...

  • 2017 में Seattle-owned email addresses से आए-जाए सभी emails के लिए नीचे दी गई जानकारी मांगना—क्या यह सच में ऐसी reasonable request है जिसका government को जवाब देना चाहिए?

    1. भेजने वाले का address
    2. पाने वाले का address
    3. BCC address
    4. CC address
    5. समय
    6. तारीख
      क्या यह government employees और जिन लोगों से वे communicate करते हैं, उनकी बहुत सारी private information उजागर नहीं करता? लेख और कानून इसे पूरी तरह normal मानते दिखते हैं, लेकिन मुझे यह बहुत अजीब लगता है
      उदाहरण के लिए, लोगों के office में आने-जाने के exact times, सभी employees की vacation information, org chart या team divisions से explain न होने वाली friendships या relationships, यहां तक कि criminal investigations से जुड़े clues भी सामने आ सकते हैं
      अगर इससे इतना कुछ infer किया जा सकता है, तो मुझे संदेह है कि इसे सच में metadata कहा भी जा सकता है या नहीं
    • यह सब government चलाने वाले government employees द्वारा किया गया काम है, तो इसे public क्यों नहीं होना चाहिए?
    • examples metadata से directly derive नहीं होते; ज्यादा से ज्यादा वे inferences हैं

  • सिर्फ अड़ंगा लगाने वाला paperwork clerk? है। computer illiterate? है। अपनी गलती requester पर डालना? है। ये सब मिल जाएं तो? priceless