PDFメタデータと隠しデータ

ドキュメントのメタデータとは、ファイルがページの内容を超えて自身について持ち運ぶ情報です。そのフィールドが誰を作者と述べているか、どのアプリケーションが生成したか、いつ作成・変更されたと述べているか、そしてどの以前の素材がまだ中に残っているか。PDFは重なり合う二つのメタデータシステム、以前のリビジョンの連鎖、完全な埋め込みファイル、不可視に描画されるテキストを持つことができます。JPEG写真はカメラの日記を持ち、単純なPNGスクリーンショットでさえ、それを作ったソフトウェアを名指します。この記事では、それらの隠れ場所がどこにあるか、なぜそのデータが通常の編集を生き延びるか、そして実際の漏えいがどう起きたかをたどります。読みながら自分のファイルを調べるには、ドキュメント・フォレンジックツールを実行してください——ブラウザの中でローカルに動作します。同じファイルの読み取り構造の側面については、あなたのPDFはウェブサイトのアクセシビリティの一部をご覧ください。

すべてのPDFの中に二つのメタデータシステムが乗っている

古い方は情報辞書で、ファイルのトレーラーに保存される小さなキーと値の組です。Title、Author、Creator(元のドキュメントを作ったアプリケーション)、Producer(PDFを作ったアプリケーション)、CreationDate、ModDate。これらのフィールドは書き出し時に自動的に書かれ、ドキュメントの作者の多くは、それらを表示するプロパティダイアログを一度も開きません——それこそが漏れる理由です。個人のノートパソコンから書き出された報告書は、そのパソコンのアカウント名を作者として持ちます。昨年のテンプレートから始めたドキュメントは、昨年の作者をまだ名指します。印刷されたページでは何も見えませんが、ファイルのすべての受け手にとって、プロパティパネル一つ先にあります。

新しいシステムはXMPで、ドキュメントに埋め込まれたXMLパケットです。Adobeの拡張可能メタデータプラットフォームの上に構築され、PDF仕様そのものISO 32000-2と並んで記述されています。XMPは名前空間の中で同じ領域の多くを繰り返します。タイトルにはdc:title、pdf:Producer、xmp:CreateDateとxmp:ModifyDate、さらに古い辞書が決して持たなかった作成ツールといったフィールドです。二つのシステムがあること自体は、それらが歩調をそろえて保たれれば無害ですが、実際にはそうなっていません。一つのツールは情報辞書を更新してXMPを無視し、別のツールはXMPを書き直して辞書を古いままにし、第三のツールは一方を取り除いて他方を残します。結果として、一つのファイルが自身についてわずかに異なる二つの物語を語るのが日常であり、その食い違い自体が情報です。複数のツールが複数の時点でそのドキュメントに手を触れたことを記録しているからです。

増分更新:削除されたのに決して去らなかった段落

PDFは追記のみの編集のために設計されました。編集者が変更を増分的に保存するとき、ファイルは書き直されません。変更されたオブジェクト、新しい相互参照セクション、新しいトレーラーを末尾に追加し、/Prevポインタで前のトレーラーへ連鎖します。各リビジョンは独自の%%EOFマーカーで終わるため、それらのマーカーを数えることで、そのように保存された回数の下限が分かります——そして以前のすべてのリビジョンは物理的にバイトの中に残り、読むことができます。そのようなファイルを通常のビューアで開くと、最新のリビジョンだけが見えます。バイトを読むか、連鎖をさかのぼれば、ドキュメントの以前の状態がまだそこにあります。表の中の古い数字、条項の以前の文言、リリース前に削除された段落です。

これが、ニュースになり続ける墨消し失敗の背後にある仕組みです。チームは名前や数字を秘匿した報告書を公開する必要があり、誰かが敏感な箇所の上に黒い矩形を描きます——ページの見た目を変え、その下には何も触れない描画操作です——あるいは、後に増分保存する編集者の中でテキストを削除し、削除されたオブジェクトを以前のリビジョンに残します。公開されたファイルはきれいに見えます。数日後、ある読者が「墨消し」された領域を選択し、コピーして、元の言葉をテキスト編集者に貼り付けます。あるいは研究者がリビジョンの連鎖を解析し、除去されたものを復元します。本当の墨消しは覆うこととは別の操作です。基礎となる内容をコンテンツストリームから除去し、ファイルを完全に書き直さなければならず、バイト自体が、ページがもう表示しないものを含まなくなる必要があります。公開しようとしているファイルが複数の%%EOFマーカーを持っているなら、その履歴はまだ中に入っています。やる気のある読者はその履歴を読むものと想定してください。

埋め込みファイルと隠しテキスト:誰も一覧にしない貨物

PDFは完全なファイルを自らの内部に持ち運ぶことができます。この形式は埋め込みファイルの名前ツリーを定義し、/EmbeddedFilesと/Filespecオブジェクトを通して到達します。作成ツールはそれを、ソースのスプレッドシート、データ付録、ポートフォリオ文書のために使います。それらを明かす添付ファイルパネルは、ほとんどの読み手が決して開かないパネルであるため、埋め込まれた貨物は静かに旅をします。磨き上げられたPDFの要約を公開すると、その背後にある作業用スプレッドシートも、独自のメタデータ、草稿シート、コメントとともに公開してしまうかもしれません。受け手についても逆が成り立ちます。受信したPDFの中の添付ファイルは、周囲のドキュメントの信頼を引き継ぐため、埋め込みファイルは偶然の発見ではなく、あらゆる検査チェックリストの一行に値します。

テキストは別のファイルでなくても隠れることができます。PDFは描画モードでテキストを描き、モード3——3 Tr演算子で設定されます——は塗りも線も描きません。文字はコンテンツストリームの中にあり、選択、検索、抽出ができ、ページ上では完全に見えません。不可視テキストの一部は正当で価値があります。スキャンされたページの背後にあるOCR層がまさにそれで、画像を検索可能にする隠しテキストです。問題は、モード3やその近縁に行き着くそれ以外のすべてです——白い背景の上の白いテキスト、可視ページの外に切り取られたテキスト、検索エンジン用に追加されたキーワード層——なぜならテキスト層を抽出する読み手は、ページが決して表示しなかった言葉を受け取るからです。隠れた層が見える層と食い違うとき、ファイルは同時に二つのことを言っており、そのうち校正されたのは一方だけです。

画像も日記を持つ:PNGチャンクとJPEG Exif

PNGファイルは名前付きのチャンクの列であり、いくつかのチャンク型はテキストを持ち運ぶためだけに存在します。tEXt、その圧縮された兄弟zTXt、国際化されたiTXtです。書き出しツールは習慣的にそれらを書きます——編集者を名指すSoftwareキーワード、作成ツールの文字列、時には埋め込まれたXMLプロファイル全体——そしてチャンクのリストを無傷に保つすべての切り抜きやサイズ変更を生き延びます。tIMEチャンクは最終変更のタイムスタンプを加え、eXIfチャンクは完全なカメラメタデータブロックを持つことができ、閉じチャンクIENDの後に追加されたバイトは、ファイルの中に残りながらすべてのビューアに無視されます。窓の中立的な絵に見えるスクリーンショットは、したがってそのマシンのソフトウェアを名指し、自らに日付を刻み、作者が決して見なかったデータを持ち運ぶことがあります。

JPEG写真はさらに進みます。ファイルはマーカーセグメントの連鎖です。APP0はJFIFヘッダーを持ち、APP1はExifブロックかXMPパケットのどちらか——時には両方——を持ちます。ExifのIFD0フィールドはカメラの日記のように読めます。デバイスのMakeとModel、写真が撮影されたか最後に変更されたDateTime、それを処理したSoftware、そして拡張ディレクトリの中のGPS座標。カメラロールから直接公開された携帯電話の写真は、写真自体が決して表示しなかった時刻と場所に、正確に、その持ち主を位置づけることで、組織と個人の双方を困らせてきました。コメント(COM)セグメントは、ファイルを最後に保存したツールからの自由テキストを加え、余分なバイトが画像終了マーカーの後に残ることがあり、これらすべてを読むツール——出典に挙げたPhil HarveyのExifTool——は無料でダウンロードできるため、受け手もそれを読むことができます。

タイムスタンプを突き合わせ、公開前に除去する

一つのタイムスタンプは主張です。複数のタイムスタンプは、それ自身と突き合わせることのできる物語です。変更日より後に来る作成日は、一つのツールが一回の処理で生み出したドキュメントを記述することはできません。同じ出来事についての情報辞書の日付とXMPの日付の食い違いは、二つの時計を持つ二つのツールを記録します。未来の日付は、誤って設定された時計、手で編集されたフィールド、あるいは断片から組み立てられたファイルを記録します。PDFの日付形式自体も曖昧さを招きます——D:文字列はタイムゾーンを省略でき、数字がどの時計から来たのかを読み手に推測させます。各不一致を、監査人が元帳の相違を扱うように扱ってください。通常は罪のない説明があります——テンプレートの再利用、ノートパソコンの時計、アップロード時にファイルを書き直した最適化ツール——そしてそれは量るべき証拠であり、それだけで判定には決してなりません。メタデータフィールドは無料ツールを持つ誰もが編集できるため、物語を裏付けたり矛盾させたりはできますが、証明することはできません。

したがって除去はボタンではなくワークフローです。第一に検査すること:ファイルをドキュメント・フォレンジックツールに通し、それが見知らぬ人に何を伝えるかを書き留めます——作者とツールの名前、リビジョン数、埋め込みファイル、隠しテキスト、互いに言い争うタイムスタンプ。第二に、できるところではソースで修正すること:その出力に継ぎ当てをするのではなく、作成アプリケーションの中でドキュメントプロパティを正します。第三に、新鮮で完全な書き直しを書き出すこと——PDFへの印刷、専用の除去ツール、画像についてはExifTool——なぜなら完全な書き直しは、増分保存では決してできない方法で、以前のリビジョン、孤児オブジェクト、余分なデータを捨てるからです。最後に、送ろうと思っていたコピーではなく、実際に送るコピーを再確認すること。そして記事全体が依拠する区別を保ってください。内部の原本はそのメタデータを保つべきです。来歴、保存価値、そしてアクセシビリティさえ——ドキュメントのタイトルもメタデータです——それに依存しているからです。公開するコピーを除去し、記録は自宅で無傷に保ってください。

出典とさらに読むもの

よくある質問

メタデータはドキュメントの作成者を証明できますか?

できません。メタデータフィールドはプログラムが書いたテキストであり、無料ツールで編集でき、テンプレートから継承でき、別のファイルからコピーできるため、証明ではなく証言です。それらにできるのは、主張を裏付けることです——あるいは、タイムスタンプ同士が矛盾するときや、名指されたツールではそのファイルを生成できなかったときに、主張と矛盾することです。複数の証拠の一つとして扱い、作者判定として決して扱わないでください。

何か月も前に削除したテキストが、なぜ私のPDFからまだ復元できるのですか?

増分更新のためです。編集者がリビジョンを追加して保存する場合、削除されたテキストは同じファイル内の以前のリビジョンに残り、/Prevでリンクされたトレーラーの連鎖の背後にあります。ビューアは最新のリビジョンだけを表示しますが、バイトはすべてまだそこにあります。修正は完全な書き直し——再書き出しかPDFへの印刷——であり、現在の状態だけを含む新しいファイルを書き、その後、新しいファイルの%%EOFの数が1であることを確認します。

公開前にメタデータは常に取り除くべきですか?

記録ではなく、公開するコピーを取り除いてください。外部のコピーは、作者のアカウント名、内部のツール連鎖、埋め込まれた作業ファイル、リビジョン履歴を持ち運ぶべきではありません。しかしメタデータは正当な仕事もします。ドキュメントのタイトルは支援技術が読み上げるものであり、ブラウザのタブが表示するものであり、アーカイブは来歴フィールドに依存します。内部の原本は無傷に保ち、公開用に除去されたコピーを作ってください——そしてそのコピーを確認してください。除去ツールは主張するほど取り除かないことが時にあるからです。