read-deleted-pages

削除されたページを読む

アーカイブが機能するのは、公開後に削除が決定されるためです。初心者が陥りがちな間違いは、Wayback Machineを閲覧するウェブサイトとして扱うことです。カレンダーUIでは一度に1ページしか表示されませんが、CDX APIを使えば、アーカイブがホスト上で確認したことのあるすべてのURLを列挙できます。誰も覚えていないパスも含まれます。

まず確認するアーカイブ

状況	確認先	理由
現在404になるURL	Wayback、次にarchive.today	収集対象も削除圧力も異なります
「X以前、このサイトには何が書かれていたか」	collapse=digest を指定したWayback CDX	すべての取得記録ではなく、コンテンツが変更された日付がわかります
JSを多用するページやSNSの投稿	archive.today	レンダリング済みのDOMを保存します。Waybackでは空のシェルが再生されることがよくあります
WaybackでURLが除外されている	archive.today、次にCommon Crawl	どちらもWaybackの除外プロセスには従いません
知らないパスやサブドメイン	matchType=domain を指定したCDX	検索ツールではなく、列挙ツールです
Waybackが一度も取得していないURL	Common Crawl	独立したクローラーで、シードも異なります
地域向けまたは国別TLDのコンテンツ	Mementoアグリゲーター、次に国立アーカイブ	国立アーカイブの中には全文検索を提供するものもあります
失うわけにはいかない証拠	自分で保存し、2つのアーカイブに送信する	誰かが代わりに保存してくれるわけではありません

ソースごとの網羅範囲と削除ポリシー： reference/archive-comparison.md。

CDX APIこそが実際のツールです

CDXサーバーは取得記録をインデックス化します。1回の取得につき1行で、絞り込み、重複の集約、列挙ができます。クローラーがホスト上で確認したことのあるすべてのURLを重複排除して取得できます。

curl -s 'http://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&fl=original&collapse=urlkey' \
  | jq -r '.[1:][] | .[0]' | sort -u

デフォルトのテキスト形式ではなく、output=json を使ってください。テキスト形式では崩れてしまう、スペースや引用符を含むURLも扱えます。最初のJSON行は列名を示すヘッダーで、取得記録ではありません。そのため .[1:] を使います。

ほとんどの作業は、次の4つのパラメーターで行えます。

• matchType — exact、prefix、host、または domain。matchType=domain はホストとすべてのサブドメインを返すため、DNSからすでに消えて久しいステージング用、レガシー用、内部用のホストが見つかることもよくあります。それらを find-hidden-subdomains に渡してください。
• filter=<field>:<regex> は ! で反転でき、複数指定もできます。コンテンツを返した取得記録に絞るには statuscode:200 を、ドキュメント、アーカイブ、設定ファイルを抽出するには !mimetype:text/html を指定します。
• from/to は任意の精度のタイムスタンプ接頭辞を指定できます。from=2019、from=201903 のように指定し、既知の出来事の前後の期間を絞り込めます。
• collapse は、同じフィールドを持つ連続した行を省略します。collapse=urlkey は列挙の定番で、特に重要なのは collapse=digest です。

digest は取得したペイロードのハッシュ値です。そのため、collapse=digest を使うと、ページの履歴をコンテンツが実際に変更された取得記録に絞り込めます。400件の取得記録が6行になり、その6つの日付が変遷を示します。

curl -s 'http://web.archive.org/cdx/search/cdx?url=example.com/about/team&output=json&collapse=digest&fl=timestamp,digest,statuscode'

全パラメーター、ページ分割、すぐに使える列挙手順については、reference/cdx-cookbook.md を参照してください。

再生されたページは取得時の内容ではありません

web.archive.org/web/<timestamp>/<url> のページは再構成されたものです。アーカイブはツールバーを挿入し、リンクやリソース参照をアーカイブ内に書き換えます。そして、誤解を招きやすい点ですが、各リソースをそれぞれの最も近い取得記録から取得します。その取得記録は、指定したHTMLから数か月離れている場合もあります。スクリーンショットに写っているページが、実際には一度も存在しなかった可能性があります。

タイムスタンプに id_ を付けると、挿入や書き換えのない、アーカイブ済みの生のレスポンスを取得できます。

curl -s 'https://web.archive.org/web/20190412093000id_/http://example.com/pricing' > pricing-2019.html

解析、ハッシュ化、差分比較、引用を行うものには id_ を使ってください。再生すると空白に見えるページでも、正しく取得されている可能性があります。アーカイブに何もないと判断する前に、生のレスポンスを取得してください。ただし、表示時にAPIを呼び出すアーカイブ済みJavaScriptの場合、APIのレスポンスは取得されていないため、背後にデータはありません。こうしたページは失敗によるものではなく、もともとシェルなのです。

これで実際に分かること

collapse=digest リストから2つの日付の生のキャプチャを取得し、テキストとして比較します。削除された内容が証拠になります。2つの日付の間にチームページから削除された人物は、日付の範囲が特定できる離職者であり、もはや忠誠を保つ理由のない find-anyone の手がかりです。実際には、次のような情報が見つかります。

• スタッフとチームのページ。 現在のサイトには今いる人が掲載されていますが、アーカイブには、組織が問い合わせフォームに移行する前の役職、略歴、場合によっては直接のメールアドレスとともに、過去に在籍した全員が掲載されています。
• 過去の価格と契約条件 — 請求額、約束された内容、紛争が始まった日に返金ポリシーに記載されていた内容です。また、削除された投稿やプレスリリースから、提携、資金調達、顧客など、双方が言及しなくなった事柄も分かります。
• 古い連絡先情報。 後にフォームへ置き換えられた電話番号、住所、個人名の記載された連絡先です。whose-number-is-this に直接つながります。
• 編集前の文面。 全文が公開されていたページと、その後に編集されたページを差分比較すると、誰かが弁護士に費用を払って削除した語句が正確に分かります。何が重要なのかを示す非常に強い手がかりです。
• 忘れられたファイル — 一度インデックスに登録され、その後も整理されずに残ったドキュメントのパス、バックアップのファイル名、管理用の画面です。secrets-in-git-history を参照してください。
• 以前のドメイン所有者。 所有者が変わったドメインでは、アーカイブの履歴に別の事業者が現れます。評判を洗浄するための買収を見つける最も手早い方法です。

さらに調べる前に保存する

見つけたものは削除される可能性があり、調査が削除のきっかけになることもあります。まず保存し、その後に分析してください。

公開中の URL を Internet Archive の Save Page Now（https://web.archive.org/save/）と archive.today に送信し、独立した2つの組織に、自分が作成したものではないタイムスタンプ付きのコピーを保存してもらいます。次に、自分でも記録を取ります。WARC はヘッダーを含む HTTP 通信全体を保存しますが、スクリーンショットにはそれがありません。

wget --warc-file=evidence-001 --page-requisites --no-parent https://example.com/pricing
sha256sum evidence-001.warc.gz | tee evidence-001.sha256

キャプチャ時刻を UTC で記録し、要求した URL を正確に記録して、ハッシュも残してください。スクリーンショットだけでは証拠として弱いものです。簡単に偽造でき、ヘッダーもありません。第三者のアーカイブ URL と自分でハッシュを計算した WARC を組み合わせれば、互いに裏付け合い、片方は自分の管理外にあるため、強力な証拠になります。これが write-the-intel-brief が期待するものです。

キャプチャが本物か確認する

誰でもアーカイブにコンテンツを登録できます。Save Page Now と archive.today はどちらも、匿名の送信者から任意の URL を受け付けます。キャプチャによって証明されるのは、その URL が、その時点で、そのクローラーにそのコンテンツを配信したことだけであり、誰がその URL を管理していたかは分かりません。現実的な偽装方法は次のとおりです。

• アーカイブページの偽造スクリーンショット。 簡単にできます。アーカイブのスクリーンショットは決して証拠として受け入れず、アーカイブ URL 自体を使って再取得してください。
• URL 経由で注入されたコンテンツ。 クエリパラメーターの反射、ユーザー生成コンテンツのパス、またはオープンリダイレクトを使うと、攻撃者が選んだテキストを、正規のドメインに見えるサイトでアーカイブできます。original フィールドを一文字ずつ確認してください。? や # 以降、不審なパスのセグメント、よく似た別のホストに注意してください。
• ドメインの所有者変更後のキャプチャ。 そのドメインは元の事業者ではなく、買い手のものでした。who-owns-this-domain を使って、所有権移転の日付とキャプチャのタイムスタンプを照合してください。
• 選択的なキャプチャ — 実際のページが11分間だけ公開され、それを公開した人物がアーカイブしたものです。

裏付けの強さは、次の順に高くなります。statuscode が 200 で digest があることを確認し、CDX インデックスにその記録が独立して存在することを確かめます。オンデマンド送信ではなく、アーカイブ自身のクローラーによる隣接するキャプチャを探します。クローラーによるキャプチャは、仕込むのがはるかに困難だからです。同じ日付付近に、別の独立したアーカイブがあるかを確認します。サイトのほかの履歴との整合性を確認します。隣接する記録のない単独のオンデマンドキャプチャは、送信者による主張にすぎません。

ここで誤りが起きる理由

• 見つからないことは、存在しなかった証拠にはなりません。 キャプチャがない理由は、リンクされていない、robots にブロックされている、ログインが必要、クロールするほど目立たない、削除された、などです。そのページが存在しなかったという意味ではありません。「記録なし」と書く前に、2つのアーカイブを確認してください。
• 除外は、存在しないように見えることがあります。 明示的な除外通知は、誰かが対応したことを意味します。単なる 404 には何の意味もありません。異なる事実なので、どちらを確認したのか記録してください。
• 事後的な削除。 Wayback は歴史的に、サイトの現在の robots.txt をアーカイブ全体に適用してきたため、新たな Disallow によって何年分ものキャプチャが一度に取得できなくなることがありました。つまり、期限切れドメインの購入と制限的な robots.txt の組み合わせは、サイトの過去を安価に隠す方法になり得ます。この慣行は縮小されましたが、履歴があまりにきれいに見える場合は、archive.today と Common Crawl も確認してください。
• 複数の時点が混在したレンダリング。 リソースの日付が混在している場合、レンダリングされたページは再構成されたものです。「どう見えたか」ではなく、HTML キャプチャのタイムスタンプを引用してください。
• キャプチャ時刻は公開時刻ではありません。 3月に初めてキャプチャされたページが、1月に公開されていた可能性もあります。キャプチャによって上限の日付しか定まりません。
• 動的コンテンツとパーソナライズされたコンテンツ。 クローラーが確認したのは、ある地域、ある A/B テストのグループ、ログアウト状態など、特定のバリエーションです。特に価格や在庫状況に注意してください。
• サンプリングがまばらだと、あらゆる変化が見えなくなります。 年に2回キャプチャされたページは、変化して元に戻っても痕跡が残らないことがあります。collapse=digest でわかるのは観測された変化であり、すべての変化ではありません。タイムスタンプは UTC です。これを忘れると、時系列が1日ずれてしまいます。

信頼度の評価

• 確認済み — クローラーが開始したキャプチャで、statuscode:200 であり、id_ を使って生データを取得済みで、対象の URL であることを確認でき、さらに別のアーカイブ、または同じクロール系列における前後のキャプチャで裏付けられているもの。
• 可能性が高い — 2つ目のソースがない、形式の整った単一の Wayback キャプチャ、またはサイトのほかの履歴と整合する archive.today のキャプチャ。
• 未確認 — 前後のキャプチャがないオンデマンドキャプチャ、クエリパラメーターやユーザー生成コンテンツのパスを含む URL、スクリーンショット、生の応答ではなく複合リプレイから読み取ったコンテンツ。
• 否定 — その日付時点で対象者の管理下になかった URL のキャプチャ、またはドメイン移管後に取得され、前の所有者のものとして提示されたキャプチャ。

アーカイブの完全な URL とタイムスタンプ、元の URL、UTC でのキャプチャ時刻、および取得方法を記載してください。タイムスタンプのないアーカイブの引用は、引用とは言えません。

具体例

あるサプライヤーのサイトでは、業界認証を取得していると主張しています。クライアントは契約締結前に、それを検証したいと考えています。

認証ページに対する collapse=digest では、6年間に9回のコンテンツ変更が返されます。直近の変更の前後にある生のキャプチャを見ると、告知もないまま、認証機関の名称が、認知された認定機関から、よく似た名称の別組織に変わっていることがわかります。

行き止まり：認定機関の公式登録簿には、どちらの名称も現在の掲載がなく、アーカイブされた会員リストも空の殻として再生されます。id_ を使って取得すると、その理由がわかります。リストは API 呼び出しからクライアント側でレンダリングされていたため、クローラーがキャプチャしたページにはデータが含まれていませんでした。そこから復元できるものはありません。

次に、matchType=domain で CDX を列挙すると、元の証明書のアーカイブ PDF を保管しているステージングホストが見つかります。そのメタデータには、現在のサイトが適用対象期間として主張する日付より2年前の有効期限が記載されており、secrets-in-file-metadata で同じファイルから作成者名も取得できます。

評価：文言の変更は確認済み — クローラーによるキャプチャが2件あり、どちらも生データを確認済みです。認証の失効は可能性が高い — 文書は1件ありますが、認定機関からの確認はありません。

ピボット

新しいセレクター	移動先
元スタッフの氏名、肩書き、経歴	find-anyone, pattern-of-life-from-socials
以前の連絡先ページに掲載されていたメールアドレス	what-an-email-reveals
電話番号と住所	whose-number-is-this
CDX 列挙で見つかったサブドメインとホスト	find-hidden-subdomains, who-owns-this-domain
アーカイブされた文書と PDF	secrets-in-file-metadata
アーカイブされた画像	find-the-original-image, geolocate-from-pixels
忘れられたパスと公開されたファイル名	google-like-a-spy, secrets-in-git-history
ドメインの以前の企業アイデンティティ	x-ray-a-company, who-really-owns-it
編集と削除のタイムライン	write-the-intel-brief, graph-the-network

法的事項と取り扱い上の注意

アーカイブの閲覧は受動的な行為です。アクセスするのはアーカイブのサーバーであり、 対象のサーバーではありません。復元したパスを稼働中のサイトに対して取得する行為は 受動的ではなく、対象のログに記録されます。どちらを行っているのか、意識して判断してください。

アーカイブされた個人データも、依然として個人データです。消去権の請求に基づいて 削除されたコンテンツがアーカイブに残っている場合があり、それを再公開すると、 削除の目的となった責任が生じる可能性があります。調査上の必要性と削除の理由を 比較検討し、../../ETHICS.md に従って取り扱いを最小限にしてください。 アーカイブされたコンテンツの相当部分を公開レポートに転載することは、それを証拠として 利用する場合とは別個の著作権上の問題です。

一括取得は非営利団体のインフラに負荷をかけます。列挙と生データの取得には レート制限を設け、インデックスは繰り返しではなく一度だけ取得してください。