시애틀 시, 40달러에 3,200만 건 이메일을 실수로 제공 (2018)

 (mchap.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 한 공개기록 요청자가 2017년 seattle.gov 이메일의 발신자·수신자·참조·시간·날짜 같은 메타데이터만 요구했지만, 시애틀 시는 약 3,200만 건 이메일의 앞 256자까지 포함한 파일을 제공함
  • Seattle IT는 처음에 검토에 직원 320년과 급여 3,300만 달러가 든다고 추산했으나, 이후 본문 없는 메타데이터라 검토가 필요 없다며 첫 분량 비용을 1.25달러로 낮춤
  • 공개기록 포털에 올라온 약 400개 파일에는 사용자명·비밀번호, 신용카드 번호, 사회보장번호, 운전면허, 경찰·FBI 수사 정보, Zabbix 알림 등 민감 정보가 섞여 있었음
  • 요청자가 문제를 알리자 Seattle은 GovQA 접근을 임시 중단하고 수정본을 다시 처리하겠다고 했으며, 이후 파일 삭제와 Kroll을 통한 하드디스크 스캔, 법적 면책 조건을 제시함
  • 결국 요청자는 파일을 삭제하고 진술서와 디스크 정리 조치를 거쳤고, Seattle은 2018년 1월 26일부터 원래 요청한 메타데이터를 분할 제공해 작성 시점 기준 2,700만 건을 전달함

공개기록 요청의 출발점

  • 요청자는 Chicago 시장실의 전화와 이메일 메타데이터를 요청한 경험 이후, 비슷한 문제가 미국 여러 지역에서 시스템적으로 나타나는지 확인하고 커뮤니케이션 구조를 매핑하려고 공개기록 요청을 확대함
  • 미국 전역에 이메일 메타데이터 요청을 100건 넘게 제출했고, 주마다 최소 2건씩 요청함
  • 첫 대규모 배치는 임의로 고른 14개 주의 최대 도시에 보냈으며, 끝까지 요청을 진행하려 한 곳은 Houston과 Seattle뿐이었음
    • Houston은 비교적 빠르게 응답해 600만 건 이메일 메타데이터를 우편으로 보냄
    • Seattle 요청은 이후 훨씬 복잡한 사건으로 번짐

Seattle에 보낸 원래 요청

  • 2017년 4월 2일, 요청자는 Seattle IT 부서에 2017년 중 Seattle 소유 이메일 주소로 오간 모든 이메일의 메타데이터를 요청함
    • From address
    • To address
    • bcc addresses
    • cc addresses
    • Time
    • Date
  • 요청자는 기술적으로는 한 줄짜리 PowerShell 명령으로 처리 가능한 요청이라고 봤지만, 정책 차원에서는 보통 강한 반발을 부르는 요청이라고 판단함
  • Seattle의 첫 응답은 최근 90일 동안 seattle.gov 주소가 보낸 이메일 550만 건, 받은 이메일 2,680만 건이 있어 공유 전 검토할 기록이 매우 많다고 안내함
  • 요청자는 본문이 아닌 메타데이터만 요구하므로 검토량이 상대적으로 작아야 한다며 약 3,200만 건 전체 요청을 유지함

3,300만 달러 비용 추산

  • Seattle은 요청 내용을 다시 적는 과정에서 원래 범위를 바꾼 듯한 문구를 사용함
    • 원래 요청은 메타데이터에 한정됐지만, 재작성된 문구는 이메일 내용까지 포함하는 범위처럼 보였음
    • 요청자는 왜 그렇게 바뀌었는지 알 수 없다고 밝힘
  • Seattle IT는 이메일 1건당 30초에서 2분 검토가 필요하며, 전체 작업에 약 직원 320년과 급여 3,300만 달러가 들 수 있다고 추산함
  • 요청자는 대형 공개기록 요청이 보통 “과도하게 부담스럽다”는 이유로 거절되지만, 이런 규모의 비용 추산은 매우 드물다고 평가함
  • 저장 비용도 별도로 제시됨
    • Seattle은 요청 데이터가 8~10TB일 수 있으며, FTP 서버를 세워 내려받게 할 수 있다고 봄
    • 내부 비용 모델에 따라 연 2,480달러와 GB당 2.11달러를 청구할 수 있고, 10TB라면 연 2만 1,606.40달러가 필요하다고 계산함
    • 요청자는 Houston의 이메일 메타데이터 덤프가 1.2GB였고, 당시 Seattle이 공개기록 요청 데이터 저장에 Amazon S3를 사용했다는 점을 대비시킴
    • 당시 S3 가격은 GB당 0.023달러였음
  • Seattle은 요청을 바로 닫지 않고 계속 진행할지 확인했으며, 요청자는 5월 29일 받을 기록 수를 물었지만 답을 받지 못함

비용 추산 철회와 1.25달러 첫 분량

  • 6월 5일, Seattle은 초기 비용 추산이 틀렸다고 인정하고, 3개월 중 1월 1일과 2일 이틀치 기록의 첫 분량 비용으로 1.25달러를 요구함
  • 제공 파일은 이메일 본문 없이 요청한 메타데이터만 담은 Excel 스프레드시트라 검토가 필요 없고, 앞서 말한 320년보다 빠르게 제공할 수 있다고 안내함
  • 요청자는 이틀치마다 단일 수표를 요구하는 방식이 요청을 일부러 어렵게 만드는 것으로 해석하고, 미리 14장의 수표를 보냄
    • 첫 13장은 각각 약 1.25달러였음
    • 이후 Seattle은 추가 단일 결제를 요구하지 않음
  • 두 달 동안 큰 소식이 없었고, Seattle은 수표를 모두 현금화한 뒤 공개기록 포털 계정을 생성함

GovQA 포털에서 드러난 대규모 유출

  • 8월 22일, 요청자가 해당 이메일 계정을 휴대폰에 다시 추가하면서 요청이 완료된 사실을 확인함
  • Seattle의 공개기록 요청 포털에는 약 400개 파일이 내려받기 가능했고, 전체적으로 약 3,200만 건 이메일의 메타데이터가 들어 있었음
  • 가장 큰 문제는 모든 이메일의 앞 256자가 함께 포함됐다는 점임
  • 파일에는 다음 정보가 섞여 있었음
    • 사용자명과 비밀번호
    • 신용카드 번호
    • 사회보장번호와 운전면허
    • 진행 중인 경찰 수사와 체포 보고서
    • 불륜 관련 문자 내용
    • FBI 수사
    • Zabbix 알림
  • 요청자는 이 데이터가 매우 사적인 정보로 채워진 대규모 데이터셋이며, Privacy Act of 1974와 Washington 주 공개기록 관련 법을 포함해 여러 법을 어겼을 가능성이 크다고 봄
  • 정확한 원인은 알기 어렵지만, 요청 문구 재작성과 원래 공개기록 담당자의 휴가가 겹치며 커뮤니케이션이 깨졌을 가능성을 제시함

문제 제기와 Seattle의 초기 대응

  • 요청자는 Seattle이 스스로 실수를 알아차리길 바라며, 제공 기록이 원래 요청과 일치하지 않고 요청보다 훨씬 많은 정보를 포함하니 다시 검토해 달라고 답함
  • Seattle은 요청한 정보가 보고서의 특정 열에 있으며, 시스템 보고서를 통해 생성된 기록이라 요청 필드만으로 제한할 수 없다고 답함
    • From address는 J열
    • To address는 K열
    • bcc address는 M열
    • cc address는 L열
    • Time and date는 R열
  • Seattle은 존재하지 않는 기록을 새로 만들 의무가 없고, 요청에 응답하는 모든 기록을 제공했으므로 요청을 종료한다고 봄
  • 요청자가 유출 정보를 구체적으로 알리고 Washington Office of Privacy and Data Protection에 문제를 제기하겠다고 하자, Seattle은 이를 부주의한 오류로 인정함
  • Seattle은 원인 조사를 위해 GovQA 접근을 임시 중단하고, 수정된 기록을 다음 주 GovQA를 통해 제공하겠다고 알림
  • 동시에 요청자에게 해당 기록을 검토, 공유, 복사, 사용하지 말라고 요청함

CTO·Chief Privacy Officer와의 통화

  • 이후 요청자는 Seattle Open Data Slack 관련자들을 통해 Seattle의 CTO와 Chief Privacy Officer가 참여한 컨퍼런스콜에 들어감
  • 통화에서는 무슨 일이 있었고 기록을 어떻게 처리해야 하는지 논의함
  • 요청자가 이메일을 보관해도 되는지 묻던 중 인터넷 연결이 끊겼고, 약 10분 뒤 다시 연결했을 때 통화 분위기가 바뀌었다고 함
  • Seattle은 다음 조건을 제시함
    • 모든 파일 삭제
    • Kroll을 고용해 하드디스크를 스캔하고 삭제를 증명
    • 1번과 2번에 동의하면 완전한 법적 면책 제공
  • 요청자는 이에 동의하지 않았고, 이후 변호사끼리 이야기하기로 함

법적 압박과 삭제 확인

  • 통화 후 요청자의 변호사가 Seattle 측 변호사와 접촉했고, Seattle은 Computer Fraud and Abuse Act 관련 혐의를 검토하는 방식으로 접근하는 듯했다고 함
  • 요청자는 Seattle이 보낸 정보인데도 그런 식으로 다뤄진 상황을 문제로 봤고, 결국 파일을 삭제함
  • 이후 약 한 달 동안 대부분의 논의는 양측 변호사 사이에서 진행됨
  • 요청자는 발생 경위, 파일 삭제 방식, 삭제 검증을 설명하는 진술서를 제안함
  • Seattle은 진술서에는 대체로 동의했지만, 사용하지 않는 디스크 공간을 임의 비트로 덮어쓰는 bash script 실행 등 추가 보증 조치를 요구함
  • 요청자는 최종적으로 zerofree와 fstrim을 실행했고, Seattle은 진술서를 수락함
  • 그 뒤 법적 위협은 더 이어지지 않음

외부 보도와 Seattle의 통지

  • 통화 약 일주일 뒤, 한 Seattle 시 직원이 이 사건을 Seattle의 KIRO7에 제보함
  • KIRO7 조사에서 Seattle이 유출 사실을 아직 통지하지 않았다는 점이 드러났고, 이는 Washington 주 공개기록 요청법상 필요한 조치였음
  • KIRO7 조사 이후에야 Seattle은 직원들에게 이메일 유출을 통지함
  • 관련 보도는 KIRO7 기사에 실림
  • 일주일 뒤 Crosscut 기사가 Seattle IT 부서의 역사까지 포함해 더 자세히 다룸
  • 1월 19일 Seattle CTO Michael Mattmiller가 사임했으며, 요청자는 사임이 이메일 유출과 관련 있는지는 알기 어렵지만 시점상 언급할 가치가 있다고 봄

최종 메타데이터 제공

  • 2018년 1월 26일부터 Seattle은 원래 요청한 이메일 메타데이터를 분할 제공하기 시작함
  • 작성 시점 기준으로 2,700만 건의 이메일 메타데이터가 제공됨
  • 아직 메타데이터를 제공하지 않은 부서는 Police Department와 Human Services 두 곳임
  • 원시 데이터는 Kaggle 데이터셋에서 받을 수 있음
  • 데이터셋에는 처리와 분석을 어렵게 만드는 요소가 남아 있음
    • triple quotes, 세미콜론, 쉼표 등이 섞여 매우 지저분함
    • 시스템 알림이 수백만 건 포함됨
    • seattle.gov 간 통신에는 서로 다른 두 개의 메타데이터 기록이 있음
  • 요청자는 이 데이터를 공개기록법 맥락에서 활용하는 개념증명 작업을 하고 있으며, 하루치 메타데이터를 Gephi로 시각화함
    • 레이아웃은 Yifan Hu
    • k-core 최소값 5, 최소 degree 5로 필터링함
  • 네트워크 모델링을 도울 사람은 연락해 달라고 요청함

Washington 주 입법 논란과 이후 계획

  • 2월 23일, 첫 메타데이터 분량과 두 번째 분량 사이에 Washington 주 의회는 SB6617을 통과시키려 함
  • SB6617은 이메일 교환을 포함한 여러 기록에 대해 공개 의무를 Washington 주 공개기록법에서 제외하는 법안이었음
  • 이 법안은 처음 읽힌 뒤 24시간도 안 되어 하원과 상원을 통과해 주지사실로 보내짐
  • Seattle Times는 관련 내용을 기사로 다룸
  • Washington 주지사실에는 6,300건 넘는 전화, 100통의 편지, 1만 2,500건 넘는 이메일이 접수됐고, 주지사는 결국 법안을 거부함
  • 요청자가 이 논란이 메타데이터 분량 지연과 관련 있는지 묻자, Seattle은 관련 없으며 진행을 막던 버그를 고쳤고 그 주에 추가 기록을 보내겠다고 답함
  • 한 달 뒤 Seattle은 나머지 분량을 보내기 시작함
  • 요청자는 여러 도시의 이메일 메타데이터를 더 확보하고 있으며, 앞으로 공개기록 요청의 기본과 디지털 기록 요청에 대해 더 쓸 계획임
  • 다음 글은 2017년 1월 이메일 메타데이터를 두고 White House OMB를 상대로 진행 중인 소송을 다룰 예정이며, 첫 법정기일에는 피고 측 변호인이 출석하지 않았다고 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 이야기에서 가장 흥미로운 부분은 잘못 공개된 기록을 계속 보유하는 법적 위험임
    작성자가 시에 “생각보다 훨씬 민감한 정보를 공개했다”고 알리지 않았다면, 시는 아마 오류를 영영 몰랐을 것이고 작성자는 그 데이터로 원하는 일을 할 수 있었을지도 모름
    하지만 알린 순간, 시는 접근 권한이 없어야 할 사람 손에 데이터가 들어갔다는 사실을 알게 됐고, 그가 데이터를 보유할 권리가 있는지라는 법적 질문이 생김
    물리적 재산이나 돈이라면 명백한 실수로 받은 물건을 어떻게 처리해야 하는지에 대한 판례가 많음. 자동차 딜러가 새 차를 잘못된 주소에 내려놓고 나중에 원래 다른 주소였다고 알게 되면 그 차를 가질 수 없고, 은행 계좌에 10만 달러가 잘못 입금돼도 회수됨
    하지만 데이터, 즉 정보는 어떨까? 영업비밀처럼 특정 데이터 범주는 보유하지 말라는 명령을 받을 수 있다는 법적 논거가 꽤 있다고 봄
    그래서 이 상황을 만든 것이 시의 엄청난 실수였더라도, 작성자가 시의 요청에 협조하기로 한 건 올바른 판단으로 보임. 다만 시가 문제를 알려준 데 대해 보상하기는커녕, 자기들 실수를 수습하는 데 협조하지 않으면 위협하려 한 건 아쉬움

    • 상인이 주문하지 않은 물건을 우편으로 보내면, 그 물건은 가져도 됨
      https://about.usps.com/publications/pub300a/pub300a_v04_revi...
      https://faq.usps.com/s/article/What-Options-Do-I-Have-Regard...
      잘못 배송된 물건을 받을 경우에 대한 추가 논의도 있음
      https://law.stackexchange.com/questions/17533/if-a-retailer-...
    • 시에 알리지 않는 건 엄청 위험했을 것임. 나중에 시가 오류를 알아차렸다면, 알리지 않은 OP에게 악의가 있었다고 봤을 가능성이 큼
      알린 뒤의 대우도 좋지 않았다고 생각한다면, 알리지 않았을 때 얼마나 더 나빴을지 상상해보면 됨
      그리고 그가 데이터로 원하는 일을 마음대로 할 수 있었다는 결론도 꼭 따라오지는 않음. 추가 데이터를 공개했다면 큰 곤란을 겪었을 가능성이 높음
    • 인용된 통화 내용만 보면, 시는 꽤 선의로 대응하고 있었는데 OP가 그들을 건드리듯 행동했고 제3자 감사인과 협조하기를 거부한 것으로 보임
      지금도 결국 데이터가 삭제됐다는 건 그가 서명한 진술서를 어느 정도 믿어야 하는 상태임
    • 미국에는 내가 알기로 개인 데이터에 대한 명문화된 권리가 없음. 게다가 미국의 저작권은 기록 목록 같은 데이터베이스에는 적용되지 않음
      그래서 잘못 받은 기록을 계속 보유했다는 이유로 기소할 명확한 법 체계가 있는지는 애매함. 물리적 재산이나 저작권이 인정되는 일부 데이터라면 다른 문제임
    • “그 데이터로 원하는 일을 마음대로 할 수 있었다”는 건 꽤 강한 단정으로 보임

  • 정부 IT는 비싸기로 유명하고, 재앙인 경우도 많음. 최근 지역 기관에 계정을 만들어야 했는데, 웹 양식의 날짜 입력칸 두 개가 서로 다른 형식을 요구한다는 걸 시행착오로 알아냈음
    결국 로그인 정보를 받았지만 동작하지 않았고, 비밀번호 문제일 거라 생각해 재설정을 눌렀더니 404 오류가 나옴
    담당자는 매우 정중했지만, 기관 쪽에서 세 번이나 재설정한 뒤에야 로그인할 수 있었음
    민간 기업이 이런 문제를 갖고 있었다면 망했을 것임. 정부는 아마 또 다른 무능한 사람을 고용하고, 그 사람은 평생 직장을 얻을 것 같음

    • 정부는 아마 “부패 방지”나 “공정 거래” 같은 규칙 때문에 입찰한 유일한 회사에 이 일을 외주로 줬을 가능성이 큼
      물론 그 외주 회사를 제대로 책임지게 만들 방법은 없을 것임
    • 그 급여를 받고 정부에서 일하고 싶어 하는 유능한 IT 전문가를 아는가? 없음
      그래서 정부 IT가 별로 좋지 않은 것임. 일하기 끔찍한 환경이고, 보수도 민간 부문에 비해 좋지 않음
    • 예전에 Experian 웹사이트에서 가입하려고 양식을 직접 수정한 적이 있음. 멍청한 UI가 올바른 형식의 날짜를 입력하지 못하게 막고 있었기 때문임
    • 올해 새 직장에 들어갔을 때 I-9 양식이 거절됐는데, 알고 보니 날짜 입력칸 두 개가 서로 다른 형식을 쓰고 있었음. 원인을 알아내느라 직접 디버깅해야 했음

  • 예전에 공개 데이터 분야에서 많이 일했고, 대도시 정부의 공개 데이터 부서에서도 일한 적이 있음
    이런 행동은 그 명분에 전혀 도움이 안 됨. 공개 데이터와 정보공개청구가 시간과 자원의 엄청난 낭비이고, 별 이유 없이 법적 위험만 여는 일이라는 믿음만 강화함
    정부 이메일 메타데이터가 정당한 공개 데이터라고 생각하는 것도 꽤 놀라움. 본인이 정부에 몇 번 이메일을 보냈고 답장을 받았는지, 어느 부서와 주고받았는지가 공개돼야 한다고 생각하는가? 나는 그렇게 생각하지 않음

    • 표면적으로는 동의함. 하지만 더 깊이 보면, 다른 정부 기관들은 이미 이메일과 전화의 모든 메타데이터를 갖고 있음
      그들이 당신의 메타데이터를 갖는 건 괜찮지만, 당신이 그들의 메타데이터를 갖는 건 안 된다고 하면 이상한 비대칭이 됨
      완벽한 거울상은 아니지만, OP가 이 메타데이터가 강력하다는 걸 보여주고 양쪽 모두 이런 종류의 메타데이터를 수집하지 말아야 한다고 밀어붙인다면, 이런 정보공개청구의 정당한 활용 한 가지는 떠올릴 수 있음
    • 이건 공개 데이터가 아님. 공개 데이터는 재량에 따라 공개되는 데이터이고, 같은 데이터라도 FOIA 요청으로 받으면 법적으로 편집·가림 처리가 필요한 경우가 많음
      이런 일은 늘 발생함. 더 나쁜 건 고위층, 예를 들면 최고 데이터 책임자들이 법무팀 때문에 언론이나 인접 조직과 접촉하지 못하는 경우도 많다는 점임. 실제로 CDO에게 “당신과 말할 수 없다”는 말을 들은 적이 있음
      공개 데이터에 대해 내가 자주 쓰는 표현은 “공개 데이터는 거짓말”임. 결국 공개 데이터셋으로 제공된 것이 열과 행 양쪽에서 완전한지 검증할 법적 수단이 전혀 없기 때문임
      정보가 빠졌는지, 왜 빠졌는지조차 설명되는 경우는 매우 드묾. 그 결과 대중은 실제 상황을 깊이 오해하게 되고, 상당수는 대중이 데이터를 오해할까 봐 의도적으로 그렇게 함
      그래서 결국 FOIA로 가고 법적 싸움까지 하게 됨. 내가 FOIA 소송을 약 10건이나 해야 했던 이유가 있음
      요약하면 공개 데이터는 좋지만, 엄밀성과 책임성이 부족해 깊이가 필요한 일에는 사실상 쓸모가 없음
    • 스웨덴에서는 웹 양식이나 우편으로 정부에 연락할 때, 모든 소통이 법에 따라 공개 기록의 일부가 된다고 경고함
      메타데이터와 내용이 모두 포함되며, 공개되길 원하지 않는 민감한 내용은 넣지 말라고 안내함

  • 재미있게 읽었음
    반대편에서 시스템 관리자로 일해본 입장에서, 그의 초기 요청이 어떻게 받아들여졌을지 거의 짐작됨
    많은 경우처럼 요청의 일부만 읽고 규모에 당황했을 것임. 그래서 머릿속으로는 그가 지나치게 많은 정보를 요구한다고 생각했고, 잘못된 전제 아래 며칠 동안 정수기 앞에서 그 사람을 비웃었을 가능성이 큼
    결국 누군가 오해를 깨닫고, 이메일 헤더를 파싱하는 대신 하드코딩된 값에서 잘라낸 헤더를 내보내는 치명적 실수를 했을 것이라 짐작함
    그리고 그가 이 문제를 지적하고 나서야 그를 진지하게 받아들이기 시작했을 것임

    • 나도 시스템 관리자이고, 안타깝게도 그런 태도가 익숙하게 느껴짐. 어떤 IT 조직은 자기들이 지원해야 할 사람들을 비웃는 게 흔한 유해한 환경을 정말로 만듦
      모든 요청에 IT 조직이 무조건 굽혀야 한다거나, 실제 학대 앞에서도 예의를 지켜야 한다고 기대하는 건 아님
      하지만 정수기 앞에서 나오는 유해한 험담은 그런 게 아님. 말 그대로 사람들의 지능을 모욕하거나, 특히 사용자에게 권력을 행사하는 상황에서 사람들의 고통을 즐기는 것임

  • 우리 카운티의 Assessor가 공공 데이터를 원한다고 했다는 이유로 경찰을 부르겠다고 위협했던 일이 떠오름
    기록 복제 비용만 받아야 할 자료에 대해 수천 달러를 더 청구하려고도 했고, 그 밖에도 여러 일이 있었음
    공공기관을 상대하는 건 참 즐거운 일임

  • 유럽에서는 이런 요청이 사람 관련 정보, 즉 누가 누구와 어느 날짜와 시간에 연락했는지를 연결함

    1. 보낸 사람 주소
    2. 받는 사람 주소
    3. 숨은 참조 주소
    4. 참조 주소
    5. 시간
    6. 날짜
      이를 저장하는 것, 하물며 처리하는 것은 알 필요가 있는 경우에만 허용됨
      Seattle을 대신해 행동하는 공무원은 더 이상 개인이 아니라고 우겨도 이미 무리한 해석인데, 그 경우에도 Seattle 정부 도메인 밖의 모든 이메일 주소는 법원 명령과 사유, 그리고 범죄 수사관이라는 조건 없이는 완전히 금지 영역임
      아, 개인정보 보호여
    • 미국에서는 정부 직원이 주고받는 이메일이 대체로 공개 기록으로 간주됨. 투명성을 위해 중요함
    • 이메일 주소는 사회보장번호와 비슷한 문제를 겪음. 애초에 비공개 정보로 설계되지 않았는데 그런 역할을 떠안게 됐음
      그리고 도시는 개인 정보를 늘 아무렇지 않게 공개함. 개인 주소나 도시 내 부동산 소유자는 공개 기록의 대상이고, 도시는 요청하는 누구에게나 이름과 주소를 넘겨주는 데 별 문제가 없음
      이메일 주소는 그보다 훨씬 위험도가 낮음
    • 공개 기록은 대중을 위한 것임. 이 점을 좋아하면서도 싫어함
      시민이 정부가 무엇을 하는지 확인할 수 있어야 한다는 건 말이 됨. 안타깝게도 정부는 너무 많은 것을 기록하고, 차라리 기록하지 않았으면 좋겠고, 그 기록들이 공개 대상이 아니었으면 더 좋겠다는 생각도 듦
      이 요청이 나쁘다고 생각한다면 LexisNexis의 역사를 찾아보는 게 좋음. 그들의 핵심 사업은 데이터를 요청해 한 데이터베이스로 모으고, 미국 정부가 어렴풋이 아는 누구든 배경조사할 수 있게 만드는 것임
      예전에 masscorruption이라는 사이트도 있었는데, Massachusetts의 한 카운티 정부에 집착한 사람이 운영했던 것으로 기억함. 그는 정부 데스크톱에 있는 모든 이미지 파일에 대해 FOIA 요청을 냈고, 실제로 받았으며, 정부 컴퓨터에 저장돼서는 안 됐을 직원들의 개인 이미지를 공개했음
      내 직장에서는 받는 사람 칸에 정부 직원을 넣을 때마다, 작성 중인 메시지가 FOIA 대상이 될 수 있다는 배너가 Outlook에 나타남. 특히 지방정부에서는 어떤 계기로 사람들이 움직이고 무엇에 관심을 가질지 정말 알 수 없음
    • 대체로 동의함
      작성자는 “메타데이터”를 완전히 다르게 보는 것 같음
      내 관점에서 메타데이터라면 “이메일의 대략적인 수”, 가능하다면 “주소 블록”, “넓게 평균 낸 시간대”, 어쩌면 “매우 모호한 범주” 정도임
      누가 보냈고, 누구에게 갔고, 숨은 참조와 참조가 누구였는지는 내 기준의 메타데이터와 다름
    • 맞는 말이지만, 이들은 정부 직원이라는 점을 기억해야 함. 그들이 수행하는 모든 업무는 정의상 공공 기록임
      법에 따라 모든 행동과 소통의 기록을 유지해야 하고, 누구나 이를 열람할 수 있음
      엄밀히 말하면 정부 자원을 사적 소통에 쓰면 안 되고, 법적으로도 사적 소통 수단을 공적 업무에 쓰면 안 됨

  • 글의 핵심과는 별개로 진짜 궁금한데, “내 변호사”를 바로 부를 수 있는 사람이 그렇게 많은가?
    글에서는 Seattle이 자기들이 보낸 정보에 대해 Computer Fraud And Abuse Act(CFAA) 혐의를 추진하는 것처럼 접근했다고 하니, 작성자가 변호사에게 상대 변호사와 연락하게 했다고 되어 있음

    • 일반적으로 흔하다고 보기는 어려움. 하지만 공공 기록 요청을 많이 하는 사람이 변호사를 두고 있는 건 놀랍지 않음
      내가 아는 관할권에서는 요청을 거부하거나 부당하다고 생각하는 수수료를 요구할 때, 소송이 사실상 주요 구제수단이기 때문임
    • 꽤 흔하다고 생각함. 꼭 “대기 중”이라는 뜻은 아니지만, 하는 일에 따라 여러 분야의 변호사와 접점이 생김
      의심스러울 때는 내 상황을 아는 사람과 계속 가는 편이 낫고
      예를 들어 예전 임대 주택에서 몇 가지 문제가 있었고, 그 과정에서 세입자 보호 협회인 Mieterschutzbund에 가입했음. 이를 통해 협회 전문가에게 1시간 상담을 받고, 세입자 법 전문 변호사에게도 1~2시간 상담을 받을 수 있음
      이 과정은 보통 1~2일밖에 걸리지 않으니, 나는 사실상 임대차 변호사를 대기시켜 둔 셈임
    • 꽤 흔함. 아내와 나는 작은 일을 처리해주는 변호사 친구가 있는데, 다음에 같이 외식할 때 밥을 사주는 매우 낮은 비용으로 도와줌
      대신 나는 그 친구 집의 알루미늄 배선 전기를 고쳐줌

  • 보관본: https://web.archive.org/web/20231024164822/https://mchap.io/...

  • 2017년에 Seattle 소유 이메일 주소로 오간 모든 이메일에 대해 다음 정보를 제공하라는 요청이 정말 정부가 응답해야 할 합리적인 요청인가?

    1. 보낸 사람 주소
    2. 받는 사람 주소
    3. 숨은 참조 주소
    4. 참조 주소
    5. 시간
    6. 날짜
      이건 정부 직원과 그들이 소통하는 사람들의 사적인 정보를 많이 노출하지 않나? 글과 법은 이걸 완전히 정상적인 일로 받아들이는 것 같지만, 내게는 매우 이상하게 보임
      예를 들면 사람들이 사무실에 들어오고 나가는 정확한 시간, 모든 직원의 휴가 정보, 조직도나 팀 구분으로 설명되지 않는 친분이나 관계, 범죄 수사 관련 단서까지 드러날 수 있음
      이렇게 많은 것을 유추할 수 있다면, 이걸 정말 메타데이터라고 불러도 되는지 의문임
    • 이 모든 것은 정부를 운영하는 정부 직원이 수행한 일인데, 왜 공개되면 안 되는가?
    • 예시들은 메타데이터에서 직접 도출되는 것이 아니라, 잘해봐야 추론되는 것임

  • 방해만 하는 서류 담당자? 있음. 컴퓨터 문맹? 있음. 자기 실수를 요청자 탓으로 돌림? 있음. 이 모든 것이 합쳐지면? 값을 매길 수 없음

답변달기