1 ポイント 投稿者 GN⁺ 2023-10-02 | 1件のコメント | WhatsAppで共有
  • 英国のPost Office Horizon 起訴スキャンダルは、現代英国における大規模な冤罪事例であり、個人・組織の失敗だけでなく、法律と裁判手続きがどのような役割を果たしたかを示している
  • 裁判所は反対証拠がなければ、機械装置は正常に作動していたと推定し、この出発点はコンピュータ記録にも適用される
  • このような証拠上の推定の下では、コンピュータ記録だけで会計上の不足額のような事実が立証され得るため、被告人がエラーを立証しなければならない構造になる
  • 1984年の Police and Criminal Evidence Act のSection 69は、検察側がコンピュータの正常な動作を示さなければならないという逆のルールを置いていたが、1999年に廃止された
  • Section 69 が残っていれば Post Office による起訴の進め方は変わっていた可能性があり、廃止後は負担が再び被告人側に移った

Post Office Horizon スキャンダルと法的手続きの責任

  • Post Office prosecutions scandalは、現代英国で最大級の大規模な冤罪事例とされている
  • この事件は個人的・制度的な失敗が重なっており、法的文書や証拠も膨大なため、全体像を把握するのは難しい
  • 多くの分析は、Post Office 経営陣、弁護士、ソフトウェア提供会社であるFujitsuの失敗に焦点を当てている
  • しかし、適用された法律と手続きも事件の一部であり、それが被告人に過酷に作用し得ることを意思決定者たちが知っていた、または知っているべきだったという点で、責任は軽くならない

「コンピュータは正常に動作する」という証拠上の推定

  • 法律家のいう**推定(presumption)**とは、反対証拠がないときに裁判所が特定の状態をデフォルトとして受け入れる仕組みである
  • 古典的な表現では、「反対証拠がなければ、裁判所は機械装置が関連する時点で正常な状態にあったと推定する」というものだ
  • ここでいう機械装置にはコンピュータも含まれる
  • この推定は、裁判所があらゆる状況で必ずコンピュータを信じるという意味ではなく、証拠によって反証できる出発点である
  • 反対の状態が立証されない限り、裁判所はその状態を事実として受け入れることができる

推定が必要な理由と危険性

  • 裁判所が推定を用いること自体が問題なのではなく、推定がなければ多くの事件を実務上処理するのが難しくなる
  • 推定は事件の争点を管理可能な範囲に絞り込む
    • 契約は偽物だと立証されない限り、詐欺的な文書ではないと見ることができる
    • 被告人は心神喪失だと立証されない限り、心神喪失ではないものとして扱われ得る
  • 核心は、どの状態がデフォルトになるのか、そしてどちらの側がそのデフォルトを覆さなければならないのかである
  • 推定の内容が非現実的であったり、反証の条件が過度に難しかったりすれば、推定は司法を助ける仕組みではなく、冤罪を生む仕組みになる

コンピュータ記録が有罪の前提となる構造

  • コンピュータが正常に動作していると見るルールは、証拠上の推定に当たる
  • 裁判所は、コンピュータが適切に動作していなかったという証拠がなければ、コンピュータ記録だけで関連する事実が立証されたと見ることができる
  • たとえば、コンピュータ記録が郵便局長または女性郵便局員の財務上の不足額を示していれば、裁判所はそれを実際の不足額の証拠として受け入れることができる
  • この前提を揺るがすには、被告人がコンピュータが正常に動作していなかったことを示さなければならない
  • 起訴の中核的証拠がコンピュータ記録である場合、その構造は結局「computer says guilty」になる

Section 69 の導入と廃止

  • この証拠上の推定が常に同じ方向に作用していたわけではない
  • 1984年に制定された Police and Criminal Evidence Act 1984 Section 69 は、推定の方向を逆にした
  • Section 69 の下では、被告人がコンピュータのエラーを示すのではなく、検察側がコンピュータの正常な動作を示さなければならなかった
  • この条項は、「反対証拠がなければ機械装置は正常な状態にあったと推定する」という従来のコモンロー上の立場に取って代わるものだった
  • Post Office が郵便局長や女性郵便局員たちを起訴した当時に Section 69 が残っていれば、事件の進行は変わっていた可能性がある
  • Section 69 は1999年に廃止され、従来のコモンロー上の推定が戻ってきた
  • その後は、検察官がまずコンピュータの正常な動作を示さなければならないのではなく、被告人がコンピュータが正常に動作していなかったことを示さなければならない構造になった
  • Section 69 がどのように廃止され、その理由が妥当だったのかは、続く記事のテーマとして残る

1件のコメント

 
GN⁺ 2023-10-02
Hacker News の意見
  • Post Office スキャンダルを最後に調べたときに受けた印象は、「私たちは IT システムを信頼しすぎた」という言い方は、都合のよい言い訳に近いというものだった
    上層部は問題をよく把握しており、無実の人々を起訴していることも知りながら、自分たちの失敗を隠すために押し通したように見えた。だとすれば、相当な実刑が必要だ。司法妨害は軽い犯罪ではないし、Paula Vennells が議会で意図的に虚偽を述べたという疑惑まである

    • Post Office の取締役会で権力を持つ人々が、副郵便局長たちの証拠を無視した背景には、彼らがインド系・バングラデシュ系・パキスタン系などのアジア系であることが多かった点が大きく影響した、という相当な証拠がある
      そのため Post Office の取締役会には、人種差別のせいで手がかりを結び付けられない心理的障壁があり、数百件の冤罪判決という圧倒的な証拠に直面した後も、道徳心がなかったため、むしろさらに抵抗した。悲しい技術的失敗の話でもあるが、英国の取締役会文化に対する告発でもある。この惨事は Private Eye 誌が10年以上にわたって取り上げてきた
    • なぜ処罰ルール、結局は人を刑務所に入れたり、許可された行動に税を課したりする方法で、この問題を解決できると考えるのか疑問だ
      その権力を構造的に取り除くべきだと主張するほうが正しいのではないか
    • 幹部たちが予想する処罰がもっと重くなっていたなら、副郵便局長たちの問題はもっと早く解決しただろうか、それとももっと遅くなっただろうか?
  • 一生バグを直して生きてきた身からすると、コンピュータシステムが überhaupt 動いているという事実そのものに、しばしば驚かされる
    Post Office の失敗したシステムと似たことが個人的にもあったが、証拠を示しても、誰もがコンピュータシステムが間違っている可能性を拒んだ。理解しようと掘り下げるのがあまりに面倒だったからだ

    • 「コンピュータシステムが überhaupt 動いていること自体が驚きだ」という言葉に同感する
      ソフトウェアがどう作られるのかを見てきたので、いったいどうやって全部が動きうるのか理解できない。この逆説に対する私の答えは、実は全部が動いているわけではない、というものだ。私たちは、動いていないものを別の何かとして受け入れるよう、自分たちで訓練されてきた。人々はコンピュータシステムを全知全能で無謬の存在と見るか、逆にスケープゴートとして扱う
    • もう少しニュアンスを加えると、多くの人気ソフトウェアは、核心機能、つまりそのソフトウェアが存在する理由そのものが動かないほど壊れている
      例えば TAP、Vueling、KLM のような航空会社のウェブサイトは、この2年間使ってみると、チケットを予約したりアカウントにログインしたりできなくするバグが頻繁にあり、動かないときのほうが多かったと思う。Instagram と Google は特に理由なくアカウントを自動で無効化してきたし、Instagram では2カ月で3回経験した後、もう諦めて使わなくなった。Skype は使っている人なら説明不要で、Teams はいくら「アップデート」してもミュートボタンが実際にはミュートしなかったり、チャット入力中に文の文字順が逆になったり、通話中に突然終了して応答しなくなったりと、驚くような形で失敗する。こうした生産性の損失は世界的に相当なものだろうし、企業が無駄にした人件費は Microsoft に支払うライセンス費用より大きい可能性がある。Telegram は外部モニターをうまく扱えず倍率が崩れて再起動が必要になり、iCloud はすべてのデバイスの接続状態が良くてもファイル同期に数秒から1時間ほどかかる
    • ほとんどの人は、すべてが「だいたい」動くという事実を受け入れるより、完璧だと考える楽な道を選びがちだ
      反対の証拠を見続けていてもそうだが、エンジニアとしては、これは自然で効率的だと思う。優先順位を決めなければならず、あるバグは別のバグほど重要ではない。あらゆるソフトウェアのあらゆるバグを直すより、教育、保健、基礎研究にもっと多くの努力を注ぐほうがよいと思う
    • こういうことが頻繁に起きる理由は、機械がたいてい99%の時間はうまく動くからだ
      だから1%のケースで失敗し始めても、人々はそれ以前の99%で動いていたという理由で無視する。結果を信頼するよう訓練されているので、疑うこと自体が思い浮かばない。Systemantics という本を思い出す: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
      その本の中心命題の一つは、「システムは自分がすると言っていることを実際にはしない」という運用上の誤謬だ。人だけでなくエンジニアもよく忘れる。システムが X をする、と言っているからといって、実際に X をするわけではない。複雑な IT システムには健全な懐疑心を育てるべきだ。ほとんどの時間は失敗しないかもしれないが、結局いつかは失敗する
    • ソフトウェア産業の急成長は、収拾のつかない混乱の原因でもあり、企業がばかげた金額を使って何とか動かし続ける理由でもある
      少なくともそう感じる
  • これらの起訴における大きな問題の一つは、起訴権者が Post Office 自身だったという点だ
    この事件の前まで、Post Office にそのような権限があるとは知らなかった。事実上、Post Office が告訴人と起訴機関を同時に務めていたことになる。「Post Office Investigation Branch (IB) は、世界で最も古い公認犯罪捜査組織である。335年以上にわたり、郵便関連犯罪を摘発し、その犯罪者を起訴してきた。」
    https://www.postalmuseum.org/blog/the-post-office-investigat...

    • イングランドでは誰でも起訴を提起できる
      理論上は権力者に責任を取らせる手段だが、費用が非常に高いため、ほぼすべての私人起訴は実際には企業が提起している
  • このスキャンダルは初めて聞いた
    不一致を引き起こしたソフトウェアの主な問題が何だったのか気になる。接続切れのようなものなのか? Wikipedia には詳しく載っていなかった。ここで見つけた: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...

    • これは現代におけるソフトウェア関連の最大級のスキャンダルの一つ
      もっと調べることを勧めたいが、相当な覚悟が必要。この件を掘り下げた多くの人が、近くのバケツを探す羽目になる。本当に読むのがつらい内容
    • 問題はバグそのものよりも無関心だったのではないかと思う
      大規模なシステムでは開発中にほぼ必ずバグが入るが、普通は発見され修正される。ここではバグが見つかっていたのに修正されなかった
    • 要約すると、第三者が提供した分散台帳が監査不能なアクセス権を持ったまま同期ずれを起こし、「コンピューターがそう言っているから」という理由で支店管理者たちが架空の詐欺容疑のスケープゴートにされた
  • 自分の基本前提は、コンピューターは正しく動作しないというもの
    実際に正しく動作しない例をあまりにも多く見てきたから。運転するときも Google Maps をそのまま信じず、経路が妥当か確認し、曲がれと言われた地点の道路名と出口番号を見直す。何度もひどい目に遭っている

  • プログラマーとしての経験では、コンピューターそのものはたいてい正しく動作する
    ハードウェアのバグであることはほとんどない。しかしソフトウェアは常に間違っており、コンピューターのハードウェアはソフトウェアに命じられたことを盲目的に実行しているだけ

    • ドライバーを扱うプログラマーとしての経験では、ハードウェアはほとんど正しく動作しない
      「ソフトウェアで直せばいい」がハードウェア業界の公式スローガンでもよいくらい
    • その区別はこの記事とは関係ない
      ここでいう「コンピューター」とはハードウェアとソフトウェアから成るシステムを指し、「コンピューター」という言葉はほぼ常にそう使われる。問題は、反対証拠がなければコンピューターが正常に動作していると裁判所が推定すること。つまり裁判所はコンピューター記録だけで関連事実が証明されたと満足でき、被告がコンピューターが正しく動作していなかったことを示せなければ、郵便局長に資金不足があったと受け入れてしまう。要するに起訴事件の核心がコンピューター記録なら、コンピューターが有罪だと言ったことになる
    • ハードウェアには、正しく動作させるための小さな特異な挙動やハックが非常に多く、実際によく正しく動作しない
      かなり低いレベルでハードウェアを直接扱うソフトウェアが、こうした凹凸を補正することを期待される場合が多い
    • ハードウェアでも起きる
      古い例として、Intel Pentium CPU には発売後に発見された有名なバグが二つあった。1994年にリコールにつながった浮動小数点除算の FDIV バグと、1997年に発見され、再起動するまでプロセッサを停止させる F00F バグである。
      https://en.m.wikipedia.org/wiki/Hardware_bug
    • プログラマーでない人たちがソフトウェアを見て経験することとまったく同じ経験を説明している
      たいてい動くので、ほぼ常にユーザー側の問題だと見なすということ。何を探すべきか分からなければ、知っているエラー例だけを除外していき、上の記事のようなひどい誤判に至る
  • この推定は、主にコンピューターの運用者が迫害される側と同じ当事者である場合に問題になる

    1. 外部の人間がコンピューターの動作を検査するのが難しい、または不可能で、2) 運用者にはコンピューターの出力を操作したりエラーを隠したりする強い動機がある。反対の観点の関連例として、数年前、著作権トロールが BitTorrent のスウォームで自分たちが作成したログを法廷証拠として使っていたことを思い出す。こうしたデータは偽造が非常に容易で、外部の人間が検出するのはほぼ不可能であり、そうする金銭的インセンティブも大きかった。こんな「証拠」が法廷で考慮されたという事実がばかげているように感じた
    • ああ、Prenda Law 事件とは懐かしい
  • 裁判所が何を推定すべきかという問題ではあるが、ソフトウェア開発者が何を推定し、何を推定しないのかも問う価値がある
    ソフトウェア開発者は、広く使われているソフトウェアなら正しく動作すると推定するだろう。GitHub の issue に pandas のバグが 3,500 件あっても、JavaSDK や pandas ライブラリは正しく動作すると見なす。しかし、あまり知られていないライブラリを統合したり、あまり知られていないソフトウェアを使ったりするなら、その動作への確信は弱くなる

    • 目の数が十分にあれば、すべてのバグは浅い
      つまり、何千人もの人が何年にもわたって文句を言うことになる、という意味で。もう少し皮肉を抑えて言えば、広く使われているソフトウェアの広く使われている機能は現実の条件でテストされていると期待できるので、バグがあったとしても少なくとも知られている可能性が高い。しかし、中程度に複雑なソフトウェアの状態空間だけでも、すべてをカバーするには膨大なテストが必要になる。SQLite のテストスイートがどれほど大きいかを見ればよい。バグの少ないソフトウェアを作るためにうまく機能する唯一のアプローチは、小さく、自己完結していて、隔離され、よく理解された部品を組み合わせ、全体をより推論しやすくすることのように思える。これはもともとの Unix 哲学であり、関数型プログラミングの哲学であり、非同期相互作用の推論はより難しいとはいえ、アクターシステムの哲学の一部でもある。実際の現場でこうしたアプローチがますます多く見られることを期待している
  • タイトルはむしろクリックベイトの反対に近いかもしれない
    記事は Post Office スキャンダルを扱っており、本当に大きなテーマを取り上げている

  • 保存用リンク: https://archive.ph/wip/AJl8i