- 米司法省が公開したエプスタインのメールアーカイブは、誤ったエンコーディングと過剰な検閲により深刻な不備と批判を受けている
- 一部のメールには**
Content-Transfer-Encoding: base64**形式の添付ファイルがそのまま含まれており、このデータを復元すれば元のPDFを再構成できる
- しかし、OCR品質の低下、Courier Newフォントにおける1とlの判別問題、不適切なスキャン品質などにより、自動復元はほぼ不可能な状態
- 筆者はtesseract、Adobe Acrobat Pro、AWS Textractなどを使って復元を試みたが、いずれも不完全な結果に終わった
- この事例はデジタルフォレンジックと文書復元技術の限界を示しており、コミュニティが協力して解決すべき技術的課題として提示されている
司法省公開資料の問題点
- 最近公開されたエプスタインアーカイブは、共犯者の名前から無関係な女性の写真に至るまで、過剰に検閲された状態で配布された
- 一部ファイルはQuoted-Printableエンコーディングの不具合で破損し、閲覧不能な状態
- さらにはメール認証情報まで露出し、Redditユーザーがエプスタインのアカウントにアクセスできてしまった
- このような杜撰な処理により、Pam Bondiが率いる司法省の専門性不足が指摘されている
base64添付ファイルの発見
- メール
EFTA00400459で76ページ分のbase64エンコードデータが見つかった
- これは
DBC12 One Page Invite with Reply.pdfファイルをSMTP送信用にエンコードしたもの
- 本来なら単にコピーして
base64 -d > output.pdfコマンドで復元できるはずだが、実際にはOCRスキャン版しか存在せず、多数のエラーが発生した
- OCR結果には誤った文字の挿入、欠落、**不正なbase64文字(例: [, ,)**などが含まれ、デコードできない
OCRとフォントの問題
- Adobe Acrobat Proとtesseractを使ってOCRを再処理した結果、どちらも空白の挿入や文字認識エラーが発生
tesseractは文字集合をbase64の有効文字に制限しても、行長の不一致や部分認識の途中停止が起きた
- 最大の原因はCourier Newフォントで、
1とlの区別がほとんど不可能なこと
- 低解像度JPEGスキャンと圧縮アーティファクトにより、目視での識別すら難しい
- そのため手作業での校正が必須で、デコード時には
1とlを入れ替えながら試す必要がある
復元の試行とツール比較
imagemagickとghostscriptは大容量処理中にメモリ不足で失敗し、代替としてpdftoppmが使われた
AWS Textractは最も良い結果を示したが、それでも行長の誤差と非決定的な結果が残った
- 入力画像を2倍に拡大して認識率を上げたものの、完全な復元には失敗した
qpdfを使ったPDF構造の復元も、破損したcross-referenceテーブルのため失敗した
コミュニティの提案と後続の議論
- 記事の末尾で筆者は、ほかの添付ファイルの復元試行をコミュニティに呼びかけている
Content-Transfer-Encodingとbase64で検索すると、いくつか有用なデータが存在する
- 複数のユーザーがMLベースのOCR、フォント別CNN学習、クラウドソーシング型CAPTCHA方式など多様なアプローチを提案
- 一部はPDF復元成功例を共有し、
pdfimagesのほうがpdftoppmより鮮明な結果を得られると報告している
- 最終的には、1/l判別の自動化アルゴリズム、ストリーミングデコンプレッサーベースのエラー検出、ピクセル単位比較など高度な復元技法が議論された
技術的意義
- この事件は、デジタル文書のエンコーディング不具合とOCRの限界が実際の情報アクセスをどう妨げるかを示している
- 法的証拠物のデジタル処理における品質管理と文書フォレンジック自動化技術の重要性を浮き彫りにした
- コミュニティ協業による復元の試みは、公共データの透明性確保と技術的検証可能性の事例として評価されている
1件のコメント
Hacker News のコメント
Pam Bondi の 司法省チーム は、この件に最優秀の人材を投入していなかったように見える
Claude Opus が作ったスクリプトを共有
スクリプトのリンク / テキスト出力 / 整形版
最初のページくらいは読める PDF を生成している
Tesseract は特定のフォントで学習させられる。これは良い出発点になりそうだ
参考: Tesseract 学習データガイド
これは バイナリ PDF のデコード 問題だ。可能なエンコーディングの数は限られているので、次のアプローチを提案する
こうすれば途中の文字だけを高速にテストできるので、全探索を線形に進められる
これは nerd snipe のように見えるが、実際には 総当たり のほうが早く終わるかもしれない。76 人が 1 ページずつ打ち込めば、ブログ記事が出る前に終わる
PDF はあまりに 複雑なフォーマット なので、政府はまったく新しい 安全なオープンフォーマット を作って標準化したほうがいいと思う
DjVu はシンプルでオープンソースツールも良いが、機能が不足している
TIFF はむしろ PDF よりさらに複雑なので不適切だ
参考: XPS, DjVu, TIFF
justice.gov の検索欄で、同じメールの複数バージョンを見つけられた
原本: EFTA00400459.pdf
追加バージョン:
EFTA02153691.pdf
EFTA02154109.pdf
EFTA02154246.pdf
複数のバージョンを比較すれば、もっと簡単に解決できそうだ
「1」と「l」の問題はそのままだが、参考資料としては役立つかもしれない
(1, l) の組み合わせの すべての順列を試す のはどうかと思った。76 ページ × 69 行 × 各 1 回出現とすると、2^5244 通りの可能性になる。余っている CPU を持っている人いる?
圧縮が前提なら、チェックサムのおかげでさらに簡単になる。ただし既存ツールでは無理で、デコーダー内部に計測付きのテストハーネス を自作する必要がある
イベント詳細: Dubin Breast Center 2nd Annual Benefit (Archive)
Elisa Port と Ruttenberg 家を称える内容だと書かれている。
司会は Cynthia McFadden、パフォーマンスには複数のミュージシャンが参加している
pdftoppm と Ghostscript(ImageMagick 経由で呼び出し)は、ページ全体を再ラスタライズするため遅い
pdfimages や mutool でスキャン画像を直接抽出するほうがずっと速い
テストでは pdfimages が pdftoppm より 13 倍速かった