Internet Archive サイバー攻撃復旧とプラットフォーム説明責任

概況

Have I Been Pwned は2024年9月28日付の Internet Archive のデータ漏洩を確認し、31,081,179件のアカウント記録を掲載している。提供された認証データベースに関する報道では、メールアドレス、スクリーンネーム、パスワード変更タイムスタンプ、bcrypt ハッシュ化パスワードが記載されていた。本記録は、これらのハッシュを平文パスワードと表現したり、この件数をもってサービス利用者全員が影響を受けたとみなすことを支持しない。[7][8][10][15]
この公的危機にはいくつかの観察可能な側面があった。アカウントデータの窃取、サイト上の悪意のある JavaScript アラート、繰り返される DDoS 妨害、そしてその後発覚したサードパーティのサポート環境の不正利用である。同時代の記録では、これらすべてを単一の攻撃者が行ったとは立証されていないため、時系列を共通の属性に変換してはならない。[3][4][5][12][13][14]
復旧は段階的に行われた。Wayback Machine が最初に再開され、Archive-It が続き、archive.org は一時的な読み取り専用モードで復帰したが、アップロード、貸出、レビュー、図書館間貸出などの機能は利用不可のままとなった。[1][6][16]
読み取り専用での復旧は、単なる技術的なステータス表示以上のものであった。これは、保存された資料を取得するという公共的価値と、アップロード、アカウント操作、貸出など、状態変更やアイデンティティに依存する機能に必要とされるより大きな信頼とを分離するものだった。
Internet Archive はまた、サードパーティのヘルプデスクシステムの悪用を通じて、利用者にメールが送信されたことを認めた。その後の報道により、このアクセスが Zendesk トークンに関連し、過去のサポートチケットに関するより広範な疑惑が提起されたが、最も広範な主張は入手可能な記録では独立して確定されていない。[1][9][11]
したがって、プラットフォームの責任は、利用者の認証情報、Web 配信の完全性、開発シークレット、サードパーティのサポートアクセス、機能レベルの復旧判断、通知、そして復旧された機能が再発リスクを低減しているという証拠など、複数のコントロールサーフェスに及ぶ。
適切な結論は、動機、法的違反、過失の認定ではない。それは証拠基準である。文化的記憶を保存し提供するプラットフォームは、各サービスがなぜ復旧されたのか、どのアクセスが取り消されたのか、何が依然として利用不可なのか、そして復帰した機能の安全性をどのようにテストしたのかを示すことができるべきである。

1つのインシデントラベルが4つの異なる問題を隠していた

2024年9月から10月の出来事を「Internet Archive ハック」と呼ぶのは便利だが、分析的に弱い。異なるメカニズム、影響を受けた資産、対応義務をひとまとめにする。公的記録はむしろ、少なくとも4つの次元を区別して維持すべきであることを示している。

1つ目はアカウントデータ漏洩である。Have I Been Pwned は漏洩日を9月28日と記録し、31,081,179件のアカウント記録に関連するデータセットを確認した。BleepingComputer は、6.4GB の SQL ファイル「ia_users.sql」に関する情報を受け取ったと報じ、約3100万のユニークなメールアドレスとともに、スクリーンネーム、パスワード変更タイムスタンプ、bcrypt ハッシュ化パスワード、その他の内部フィールドが含まれていると説明した。Troy Hunt は、影響を受ける人物を通じてサンプルを検証し、Internet Archive と連絡を取ったと述べている。これらの事実は、認証記録を含む重大な機密性インシデントを裏付けている。しかし、すべての Internet Archive 利用者が含まれていること、すべてのフィールドがすべての記録に存在すること、または使用可能な平文パスワードが開示されたことを立証するものではない。[7][8][10]

2つ目の次元は、目に見えるサイトの改ざんであった。10月9日、訪問者はセキュリティ侵害を知らせる悪意のある JavaScript アラートに遭遇した。Brewster Kahle は、JavaScript ライブラリを通じた改ざんについて説明し、そのライブラリは無効化されたと述べた。これは公開 Web 体験の配信における完全性の問題であり、認証データベースの抽出とは異なる。アラートによってインシデントが公になったが、その出現は、誰が最初にアカウントシステムに侵入したか、あるいはその侵入がどのように行われたかを証明するものではない。[3][4][12][14]

3つ目の次元は可用性であった。Kahle と同時代の報道は、DDoS 攻撃と、復旧作業中に再び発生した混乱について説明している。Internet Archive と Open Library のサービスは再び利用不可となった。DDoS キャンペーンは、認証データベースの窃取に必要なアクセスを提供することなく、アクセスを拒否することができる。逆に、盗まれたデータを保持する者がボットネットを制御したり、混乱に対する責任を主張する必要はない。当時の報道では、異なる関係者が関与している可能性が明確に残されていた。[5][10][13][15]

4つ目の次元は、サポートシステムの境界を越えて現れた。Internet Archive は後に、サードパーティのヘルプデスクシステムの悪用を通じて利用者にメールが送信されたことを認めた。BleepingComputer は、露出または不十分にローテーションされたアクセストークンを通じて、組織の Zendesk 環境への不正アクセスがあったと報じた。これにより、サポートのやり取り、添付ファイル、削除依頼に関する疑問が生じたが、チケットアーカイブの全範囲と利用に関する主張は、攻撃者とされる人物の発言に大きく依存している。[1][9][11]

これらの次元は時間的に重なり、同じ組織に負荷をかけた。この重なりは運用上重要である。対応者は機密性、完全性、可用性、サードパーティアクセスを同時に管理しなければならなかった。しかし、単一の攻撃者によるストーリーを正当化するものではない。厳密な説明は、異なる人物が異なる脆弱性を異なる目的で利用した可能性を保持すべきである。完全なフォレンジックレポートなしに、証拠を超えた属性付与は、物語を単純化するが分析の信頼性を低下させる。

確認されたアカウント記録が立証すること

アカウントデータの証拠は、インシデントの中で最も数値的に具体的な部分であり、過大評価されやすい。Have I Been Pwned のエントリは、確認された漏洩日、正確な影響記録数、そしてデータクラス（メールアドレス、パスワード、ユーザー名）を提供している。インシデント固有の報道は、パスワードが bcrypt ハッシュであること、提供されたデータベースのフィールドにスクリーンネームやパスワード変更タイムスタンプが含まれていることを記述することで、有用な技術的詳細を追加している。[7][10][15]

その区別は重要である。bcrypt ハッシュはパスワード回復を困難にするように設計された一方向表現であり、読み取り可能な元のパスワードではない。ハッシュ化が露出を無意味にするわけではない。弱いパスワードや再利用されたパスワードは依然として解読の試みに直面する可能性があり、認証データベースは攻撃者が説得力のあるメッセージで人々を標的にするのに役立つ可能性がある。したがって、責任ある表現は「パスワードは安全だった」でも「平文パスワードが公開された」でもない。証拠は、アカウント記録内の bcrypt ハッシュ化パスワードの露出を支持している。

31,081,179という数字にも安定した名詞が必要である。Have I Been Pwned は影響を受けたアカウントまたは記録と表現している。これは自動的に31,081,179人のユニークな生きた人間、アクティブな借り手、現在のアップローダー、またはすべての Internet Archive サービスの利用者と同じではない。個人は複数のアカウントを持つことができ、古い記録がデータベースに残っている可能性があり、公共の読み取り専用ページを使用した人物が登録したことがない可能性もある。データパケットは人口統計や活動の内訳を提供していない。「アカウント記録」は、「すべてのユーザー」がそうではない場合に正確である。

Troy Hunt による開示とサンプル検証の説明は、データセットが未知の関係者によって宣伝されただけでなく、本物として扱われた理由を説明する上で重要である。彼の公開アップデートは、記録を確認し組織に通知する作業を説明している。それは外部検証を Internet Archive システムの完全なフォレンジック検査に変換するものではない。検証は、データセットに本物の記録が含まれていることを立証できるが、初期アクセス、期間、正確な抽出方法、アクセスされたシステムの完全なセットについては未解決のままである。[8]

また、認証データベースを保存されたコレクションと混同してはならない。入手可能な情報源は、アカウントデータの露出とサービス中断を立証している。保存されたウェブページ、書籍、音声、ソフトウェア、その他のアーカイブ資料が持ち出されたり、改ざんされたり、破壊されたりしたことは立証していない。この境界は不可欠である。文化的記憶の可用性は、サービスへのアクセスが中断されたために影響を受けたが、この情報源セットの公的記録は、可用性の危機をコレクションの完全性に関する主張に変換することを支持しない。

説明責任のために、漏洩はいくつかの回答可能な質問を生み出す。古いアカウントと認証情報はどのように保持されていたのか？データセットが検証された後、どのパスワード変更とセッション制御がトリガーされたのか？組織は、認証情報のガイダンスを必要とする登録利用者と、アカウントなしで公開検索を使用するはるかに多くの対象者をどのように区別したのか？認証情報の詰め込み、標的型フィッシング、露出したメールアドレスの悪用をチェックするためにどのような検査が行われたのか？情報源は完全な回答を提供していないため、これらは失敗の認定ではなく証拠のテストである。

最も強力な公的対応は、インシデント記録と同じカテゴリを保持するものである。どのアカウントフィールドが露出したか、パスワード表現は何か、利用者はどのような措置を取るべきか、どの結論が不確かなままかを伝えるべきである。劇的な記録数を実際のリスクを説明する代わりに使用することは避けるべきである。ハッシュ、記録人口、サービス役割についての正確さは、技術的な衒学ではなく、人々が有用なガイダンスを受け取るかどうかを決定する。

悪意のあるアラートは配信完全性の失敗の証拠だった

10月9日に現れた JavaScript アラートは異常に目立つものだった。訪問者に Internet Archive がセキュリティ侵害を受けたことを伝え、Have I Been Pwned に言及していた。ニュース組織はこの出来事を捉え、Internet Archive と Brewster Kahle は組織が侵害と DDoS 妨害に対処していることを公に確認した。[3][4][12][14]

このアラートは、公的文化記憶プラットフォームが訪問者のブラウザに配信するものの完全性に依存しているため、特別な注意に値する。攻撃者によって制御されたスクリプトを配信するページは、ユーザーを誤解させたり、リダイレクトしたり、認証情報を要求したり、あるいは単に組織が体験の一部を制御できなくなったことを示したりする可能性がある。ここでの情報源記録は、悪意のあるアラートと、Kahle による侵害された JavaScript ライブラリの説明を立証している。観察された改ざん以外の追加のブラウザ側アクションは文書化されておらず、それらをでっち上げるべきではない。

Kahle は、組織が JavaScript ライブラリを無効にし、システムをクリーンアップし、セキュリティを強化したと述べた。これらは意味のある同時代の対応声明である。影響を受けたコンポーネントを削除し、システムを調査する即時の姿勢を示している。しかし、侵害されたすべての資産の監査済みインベントリではなく、「セキュリティの強化」というフレーズ自体は、どの制御が変更されたか、後のアクセス経路が排除されたかを示すものではない。[4]

プラットフォーム運用者にとって、デプロイメントの完全性はそれ自体がガバナンスサーフェスである。関連する証拠には、誰がコードやサードパーティライブラリを変更できるか、変更がどのようにレビューされるか、デプロイメント認証情報がどこに保存されるか、スクリプトの完全性が監視されているか、既知の悪質なコンポーネントをどれだけ迅速に無効化できるかが含まれる。これらの質問はいずれも、特定の制御がこのインシデントを引き起こしたと仮定する必要はない。悪意のあるスクリプトがなぜ出現し得たのか、そして置き換え後の状態がなぜ信頼されるべきかを説明するために必要な記録の種類を特定するものである。

改ざんはまた、復旧を単一のスイッチとして説明すべきでない理由を示している。サイトは到達可能でも、配信されるコードが信頼されない場合がある。アプリケーションレイヤーでは読み取り専用でも、ブラウザで実行されるものを変更できるデプロイメントシステムに依存している場合がある。逆に、明白な悪意のあるスクリプトが削除された後でも、アイデンティティ、データ、サポートの境界がまだレビューを必要とするため、サービスは意図的にオフラインにされることもある。可用性と完全性には異なる復旧基準がある。

公開コミュニケーションはその区別を反映すべきである。「ウェブサイトは戻った」はネットワークリクエストが成功するかどうかに答える。コードパスが制御されているか、ログインが有効か、ユーザーが安全に情報を送信できるか、特権的なデプロイメントアクセスがローテーションされたかには答えない。機能レベルの復旧ステートメントは二値のステータスメッセージよりも煩雑だが、何を安全に行えるかを判断する利用者にとってははるかに有用である。

繰り返される DDoS 妨害は漏洩を複雑化したが、説明はしなかった

可用性への圧力は、インシデントの最も顕著な運用上の背景を形成した。Kahle は、組織がサービスの復旧に取り組んでいる間に DDoS 攻撃が再発したと報告した。Recorded Future News は Internet Archive と Open Library に影響を与える再発の利用不可について説明し、SecurityWeek や他の同時代の報道は、侵害、改ざん、DDoS を公的なタイムライン上の関連イベントとして扱いながら、攻撃者の身元については慎重な姿勢を保った。[5][13][15]

その慎重さは重要である。なぜなら、可用性攻撃は対応の優先順位を歪める可能性があるからである。公開サイトが繰り返し到達不能になると、外部の注目は自然に稼働時間に集中する。エンジニアはトラフィックをフィルタリングし、インフラを保護し、復帰したサービスが次の波に耐えられるかどうかを判断しなければならない。これらの要求は、アカウントデータへのアクセスや侵害された認証情報に関するより遅い調査と並行して発生する可能性がある。最も目に見える症状は、最も持続的なリスクとは異なる場合がある。

DDoS キャンペーンは、認証データベースがどのように取得されたかを説明しない。また、アカウント記録の保有は、DDoS キャンペーンに使用されるトラフィックの制御を説明しない。TechCrunch と BleepingComputer はともに、妨害と侵害の間の関係について不確実性を報じている。WIRED もまた、決定的な共通属性の所見を提供することなく、混沌とした出来事の組み合わせを説明している。[10][12][14]

説明責任のあるアプローチは、証拠を交換できても1つの仮説に統合されない、別々のインシデントトラックを維持することである。可用性トラックは、攻撃トラフィック、キャパシティ、フィルタリング、フェイルオーバー、サービス依存関係について問う。漏洩トラックは、初期アクセス、認証情報の使用、データクエリ、抽出について問う。デプロイメント完全性トラックは、悪意のあるスクリプトがどのように訪問者に届いたかを問う。サードパーティアクセストラックは、どのトークンやセッションがコア環境外で有効であり続けたかを問う。1つの指揮構造がそれらを調整することもできるが、それぞれが独自の事実と終結基準を必要とする。

この分離はまた、公的通知を改善する。利用者は、現在の停止が防御的か、敵対的トラフィックによるものか、計画メンテナンスの一部かを知る必要がある。アカウント保有者は、認証情報の露出について異なる情報を必要とする。アーカイブページに依存する研究者は、どの検索サービスが利用可能かを知る必要がある。サポートケースを持つ人々は、サードパーティのヘルプデスクの問題を理解する必要がある。単一の「サイバーインシデント」バナーでは、これら4つすべてを伝えることはできない。

停止期間だけが注意の信頼できる尺度ではない。より短い停止は、書き込み可能な機能がアイデンティティとデプロイメントのリスクが理解される前に戻る場合、無謀であり得る。より長い停止は、意図的な封じ込めを反映することもできるが、弱い復旧能力を明らかにすることもある。公的な時系列は、すべての間隔についてこれらの説明の間で選択するのに十分な内部証拠を開示していない。公正なテストは、組織がその順序、基準、検証を説明できるかどうかであり、観察者が特定のオフライン時間数を好むかどうかではない。

復旧はサービスの連続として戻ってきた

10月21日の公式サービスアップデートは、最も明確な復旧の時系列を提供している。それによると、Wayback Machine は10月13日、Archive-It は10月17日、archive.org は10月21日に一時的な読み取り専用モードで再開された。また、アップロード、貸出、アイテムのレビュー、図書館間貸出など、依然として利用不可の重要な機能を列挙し、メンテナンス中は可用性が制限される可能性があると警告していた。[1]

Brewster Kahle の10月13日の声明は、Wayback Machine の一時的な読み取り専用復帰を説明し、Axios はそのチェックポイントを完全な正常復帰ではなく部分的な復旧として報じた。これらの記述は、後の archive.org のマイルストーン以前の復旧態勢を捉えているため重要である。[6][16]

その順序は恣意的ではなかった。Wayback Machine の主な公共的価値は検索である。ユーザーは URL と日付を指定し、キャプチャされたページを表示するよう要求する。Archive-It は、独自の運用関係を持つ機関のウェブアーカイブプログラムを提供する。Archive.org は、より広範なコレクション体験、アカウント、さまざまな貢献および貸出機能を包含する。異なる日付でこれらのサービスを復旧することで、組織はすべての経路が同等に準備できていると示すことなく、いくつかの公開アクセスを戻すことができた。

10月28日の公式アップデートは、その継続的な復旧における後のチェックポイントである。これは、暫定段階後にサービス復旧が継続した証拠として読まれるべきであり、フォレンジック終了報告書の代わりとして読まれるべきではない。ステータスアップデートは、復帰する機能と運用上の進捗を特定できる。それ自体で、完全な初期アクセス経路、すべての認証情報ローテーションの有効性、または接続されたすべてのシステムの長期的なセキュリティを立証することはできない。[2]

この時系列は、より有用な復旧の定義を支持する。復旧とは、ホームページが最初に読み込まれる瞬間ではない。それは、異なるリスクプロファイルを持つ機能の制御された復元である。公開検索、認証付き検索、アップロード、レビュー、貸出、図書館間ワークフロー、管理機能、サードパーティサポートはすべて、読み取りアクセス、状態変更、アイデンティティ証明、データ取り扱いの異なる組み合わせを生み出す。

したがって、責任ある復旧マップは、プラットフォームの1行ではなく、機能ごとに行を持つべきである。各行は、サービス状態、依存関係、ユーザー人口、接触するデータ、認証要件、復旧日、既知の制限、ロールバック基準を特定する。公式アップデートは、サービスと利用不可機能を名前で挙げることにより、そのマップの一部を公開形式で提供した。その具体性は、アーカイブが「オンライン」であるという広範な主張よりも説明責任があった。

同じマップは、暫定運用と通常運用を区別すべきである。「読み取り専用」と「限定的な可用性」は、機能が制限付きで戻ったことを伝える。これらのラベルはまた、制限の意味を説明する義務を生み出す。ユーザーは検索できるか？ファイルを取得できるか？ログインできるか？アカウント詳細を変更できるか？スタッフはメタデータを変更できるか？プラットフォームがより正確に答えれば答えるほど、利用者が到達可能性を完全な復旧と誤解する可能性は低くなる。

読み取り専用復旧はガバナンス上の決定だった

読み取り専用モードはしばしば技術的なフォールバックとして扱われる。本インシデントでは、ガバナンス上の選択も表していた。Internet Archive は、アクセスの社会的価値の一部を復元する一方で、状態を変更したり、アイデンティティに依存したり、新しいデータを導入したりする可能性のあるアクションを保留し続けることを可能にした。

その区別は、10月21日のアップデートが依然として利用不可と述べた機能において最も明確である。アップロードは新しいコンテンツとメタデータを生成する。貸出はアカウント、資格、トランザクション状態に依存する。レビューはユーザー生成コンテンツをアイテムに添付する。図書館間貸出はリクエストと機関間関係を調整する。各機能は、単に公開キャプチャを取得することとは異なる信頼経路を使用する。[1]

これらの機能をオフラインに保つことで、いくつかの形態の不確実性を低減できる。公開運用に必要な認証情報や特権ワークフローの数を制限できる。まだ調査中のシステムに新しいユーザー提出物が入るのを防ぐことができる。ロールバック後に調整が必要となる状態変更の可能性を減らすことができる。対応者はより狭い本番サーフェスを観察できる。情報源は組織の完全な内部論理を明らかにしていないため、これらは読み取り専用の順序付けが原則として説明責任を果たす理由であり、実際に行われたすべての決定に関する主張ではない。

読み取り専用はリスクがないことを意味しない。検索サービスは依然としてコードを実行し、インデックスをクエリし、ストレージを読み取り、ネットワークとデプロイメントインフラに依存する。依然としてユーザーを侵害されたページ配信経路にさらす可能性がある。依然として DDoS プレッシャーの下で障害が発生する可能性がある。内部サービス ID を使用する場合もある。ラベルは機能を狭めるが、システム全体を保証するものではない。

また、読み取り専用ステータスはそれ自体でコレクションの完全性に関する質問に答えるものではない。特定の公開書き込みアクションを防ぐが、管理者、自動プロセス、バックエンドシステムは他の機能を持つ可能性がある。公的記録は保存されたコレクションの改ざんを立証せず、また完全な完全性検証設計を公開もしていない。説明責任のある運用者は、機密の防御詳細を公開することなく、復旧したサービスに必要なコンテンツとメタデータをどのようにチェックしたかを説明できるべきである。

段階的復旧のガバナンス上の価値は、明示的な基準に依存する。なぜアカウント機能の前に検索機能が許可されたのか？どの依存関係が再構築またはレビューされたのか？どの監視がアクティブだったのか？何がオフラインステータスへの復帰をトリガーするのか？次の機能を承認する権限は誰にあったのか？これらの決定が文書化されていれば、段階的復旧は制御されたリスク低減の証拠となる。文書化されていなければ、同じ順序は即席の可用性管理のように見える可能性がある。

文化的記憶にとって、部分的なアクセスの利点は大きい。研究者、ジャーナリスト、図書館、一般市民は、貢献機能や貸出機能が利用不可であっても、過去のページやデジタル化された作品を必要とする場合がある。読み取り専用サービスは、その公共的価値の一部を維持できる。責任は、制限された機能や未解決のセキュリティ問題が消えたと示唆することなく、それを提供することである。

サービスマトリックスは緑のステータスライトよりも正直である

Internet Archive のインシデントは、プラットフォーム全体のステータスラベルの限界を示している。単一の緑色のインジケータは、あるサービスが公開で読み取り専用、別のサービスが機関認証情報を必要とし、3つ目がオフラインのままで、4つ目が到達可能だが劣化していることを隠す可能性がある。セキュリティ復旧中、これらの区別は実用的な有用性とユーザーリスクの両方を決定する。

公開サービスマトリックスは、少なくとも5つの質問に答えるべきである。第一に、認証されていない訪問者は何ができるか？第二に、アカウント保有者は何ができるか？第三に、どのアクションがデータを書き込んだり変更したりするか？第四に、どのスタッフまたはパートナーワークフローが稼働しているか？第五に、ユーザーはどのような制限や断続的な障害を予期すべきか？公式の10月アップデートは、Wayback Machine、Archive-It、archive.org および特定の利用不可機能を名前で挙げることにより、この方向に進んだ。[1][2]

マトリックスはまた、証拠の境界を述べるべきである。サービスは、成功したリクエストに基づいて「利用可能」とマークされる一方で、セキュリティステータスはさらなるレビューが保留される「暫定」のままである可能性がある。ユーザーインターフェースでは「読み取り専用」とマークされながら、バックエンドメンテナンスが継続する場合がある。防御的な分離のために「利用不可」であって、損傷のためではない場合もある。これらは矛盾する状態ではなく、異なる質問に答えるものである。

ユーザーにとって、違いは行動に影響する。研究者は、アカウント変更を延期しながら、安全に検索を再開できるかもしれない。機関は、予定されたキャプチャの前に Archive-It ワークフローが稼働しているか確認する必要があるかもしれない。借り手は、貸出に関連するアイテムアクセスが依然として利用不可であることを知る必要がある。サポートケースを待っている利用者は、ヘルプデスクチャネルが影響を受けている場合、別の警告を必要とする。明確な機能レベルのコミュニケーションは、各グループが比例した選択を行うことを可能にする。

運用者にとって、マトリックスは説明責任を生み出す。すべてのステータスには所有者とテストが必要だからである。誰かが「利用可能」の意味を定義し、チェックを再現し、後退を説明しなければならない。誰かが機能に必要な認証情報と依存関係を知っていなければならない。誰かが状態変更を承認しなければならない。これにより、リーダーが生の技術ログを解釈する必要なく、復旧をリーダーシップに理解可能にする。

このモデルはまた、一般的な物語の誤りを防ぐ。1つのサービスが戻ると、観察者はプラットフォーム全体が復旧したと説明するかもしれない。別のサービスが障害を起こすと、プラットフォーム全体がダウンしていると説明するかもしれない。サービスマトリックスは、復旧が部分的に進行したり後退したりする現実を保持する。これは、DDoS 活動が再発しメンテナンスが継続する場合に特に重要である。

認証情報は1つの問題ではなく、1つのリセットでもなかった

公的記録は、いくつかの種類の認証情報を指し示している。認証データベース内の利用者パスワードハッシュ、ウェブおよび開発システムに関連するアクセス、サードパーティのサポート環境に接続されたトークンである。これらすべてを1つの「パスワード問題」として扱うことは、それらの異なる所有者、ライフサイクル、および失効方法を隠すことになる。

利用者認証情報はアカウントレイヤーに属する。メールアドレス、ユーザー名、bcrypt ハッシュ化パスワードの露出は、パスワードの強度、再利用、および後の攻撃者の労力に応じて異なるリスクを生み出す。適切な対策には、通知、パスワード変更、セッション無効化、悪用の監視などが含まれる。情報源は露出したデータクラスを立証するが、すべてのアカウント制御措置とそのタイミングの完全な記録は提供しない。[4][7][10]

開発およびデプロイメントシークレットは別のレイヤーを占める。BleepingComputer は、露出した GitLab 設定トークンがソースコードや追加の認証情報へのアクセスを可能にしたという主張を報じている。その説明は、攻撃者とされる人物とのやり取りと、出版物によって行われたチェックに実質的に基づいている。それは最終的な独立監査による根本原因の調査結果ではない。これは、もっともらしい認証情報インベントリ問題を特定するために関連するが、属性付与され条件付きのままでなければならない。[11]

サードパーティのサポートトークンはさらに別のレイヤーを形成する。トークンはユーザーパスワードが変更された後も有効であり続ける可能性がある。アプリケーションプログラミングインターフェースアクセス、管理範囲、または通常のインタラクティブログインとは異なる永続的なアクセスを許可する場合がある。トークンが中央でインベントリされていない場合、対応者は明白なアカウント経路を閉鎖しても、接続されたサービスに到達可能なまま残す可能性がある。

したがって、説明責任の質問は、組織が信頼ドメインごとに認証情報を列挙し失効できたかどうかである。有用なインベントリには、人間のアカウント、サービスアカウント、API キー、OAuth 許可、デプロイメント認証情報、サポートトークン、緊急アクセス、コードや設定に保存されたシークレットが含まれる。各項目には、所有者、範囲、作成日、ローテーションルール、最終使用の証拠、失効方法が必要である。

ローテーションには検証も必要である。新しいトークンを発行しても、古いトークンが機能しなくなったことは証明されない。1つの認証情報を削除しても、コピーされた認証情報、アクティブなセッション、派生アクセスが無効化されたことは示されない。終了記録は、どの認証情報が失効され、どの認証情報が置き換えられ、依存システムがどのように更新され、チームが置き換えられたアクセスが失敗したことをどのように確認したかを特定すべきである。

これは組織境界を越える場合に特に重要である。サードパーティプロバイダーはアプリケーションを制御し、Internet Archive はどのスタッフ、統合、データがそれを使用するかを制御する。効果的な失効には両者が行動する必要がある場合がある。関連する質問は、抽象的にトークンの責任を誰が負うかではなく、それを発見し、無効化し、証拠を保存し、再作成を防ぐ実質的な権限を誰が持っていたかである。

このインシデントは、すべてのクラスの認証情報が不適切に管理されていたことを証明するものではない。しかし、アカウントパスワードのガイダンスだけでは不完全な対応になる理由を示している。利用者、開発者、管理者、サポートシステムは異なる信頼サーフェスを占めていた。復旧には、それらすべてをカバーするのに十分な広さの認証情報モデルが必要であった。

ヘルプデスクイベントはサードパーティの死角のコストを露呈した

10月21日の Internet Archive アップデートは、サードパーティのヘルプデスクシステムの悪用を通じて利用者にメールが送信されたことを認めた。この承認は、脅威アクターの証明されない自慢を超えて問題を進めるため重要である。最初の公的インシデントの後、利用者向けサポートチャネルが悪用されたことを立証している。[1]

Troy Hunt の後のアップデートは、Zendesk チケットアクセスと、セキュリティ自体がストーリーの一部となったチャネルを通じて漏洩通知が届くという厄介な経験について議論した。BleepingComputer は、Internet Archive の Zendesk 環境に関連するトークンを通じて不正アクセスが持続したと報じた。同誌はまた、大量の過去チケット（潜在的に機密性の高い削除依頼や添付ファイルを含む）に関する主張を伝えた。[9][11]

これらのより広範な主張には、規律ある属性付与が必要である。入手可能なパケットは、すべてのチケットがダウンロードされたこと、すべての添付ファイルが取得されたこと、または機密リクエストのすべてのカテゴリがアクセスされたことを独立して立証していない。サポート環境は、すべてのオブジェクトが抽出されなくても到達可能であり得る。防御可能な調査結果は、サードパーティのヘルプデスクが利用者へのメール送信に悪用され、報道がそのアクセスの範囲について深刻ではあるが完全には検証されていない疑問を提起したことである。

その境界のあるレベルであっても、ガバナンスへの影響は大きい。サポートシステムは、まさに人々が混乱し、脆弱で、例外を求めているときに情報を収集する。チケットには、アカウント詳細、トラブルシューティング履歴、連絡先情報、添付ファイルが含まれる場合がある。アーカイブにとって、削除およびアクセスリクエストは、機密性の高い個人または法的懸念を明らかにする可能性もある。したがって、ヘルプデスクは低リスクのコミュニケーションアクセサリとして扱われるべきではない。

サードパーティガバナンスは、データ最小化から始まる。サポートエージェントはケースを解決するために何を見なければならないか？どの添付ファイルが許可されるか？クローズされたチケットはどのくらい保持されるか？特に機密性の高いリクエストは、より制御されたチャネルに移動できるか？エクスポートや一括検索は制限されているか？これらの質問は、Internet Archive の正確な Zendesk 設定に関する調査結果ではない。情報源はその設定を提供していない。これらは、チャネルの認められた悪用によって提起された証拠テストである。

アイデンティティと通知はここで絡み合っている。本物のサポートアドレスから届いたメッセージは通常、信頼性を帯びる。攻撃者がその環境から送信できれば、利用者は悪意のあるコンテンツを信頼する可能性が高くなる。したがって、復旧にはアクセスの閉鎖だけでは不十分である。どのチャネルが信頼できるか、組織がどのような種類のメッセージを送信するか、利用者が潜在的に影響を受けたチャネルに依存せずにリクエストを検証する方法についての明確なコミュニケーションが必要である。

プロバイダー境界もインシデント計画に可視化されるべきである。誰がアクセスログを照会できるか？誰がすべてのアクティブトークンを無効化できるか？誰が過去のチケット証拠を保存できるか？誰がヘルプデスクを隔離すべきかを決定するか？誰がメッセージが不正であったことを利用者に伝えるか？契約文言は、時間的プレッシャーの下で実行可能な責任に変換される場合にのみ有用である。

コミュニケーションは露出、可用性、完全性を分離しなければならなかった

セキュリティ通知は、すべての質問に1段落で答えようとするために失敗することが多い。Internet Archive インシデントは、少なくとも3つの異なる公的説明を必要とした。すなわち、どの利用者情報が露出したか、どのサービスが利用可能か、そしてプラットフォーム配信と保存資料の完全性について何が知られているかである。

アカウント露出通知は、影響を受けたデータクラスを正確に名指しし、パスワード表現を正確に説明する必要があった。メールアドレス、ユーザー名、bcrypt ハッシュ化パスワードは、支払いデータ、身分証明書、読み取り可能なパスワードとは異なるリスクを生み出す。記録数は、すべての訪問者の数として提示するのではなく、アカウント記録に関連付ける必要があった。Have I Been Pwned とインシデント報道は、その境界のある説明の強力な基盤を提供した。[7][8][10]

可用性通知はサービス固有である必要があった。公式アップデートは、復帰日と利用不可機能を名前で挙げることでこれを行った。利用者は、Wayback Machine が archive.org のより広範な読み取り専用復帰よりも前に利用可能であり、アップロードや貸出がまだ再開されていないことを理解できた。[1][2][6]

完全性通知には抑制が必要だった。悪意のある JavaScript アラートは、10月9日に訪問者が攻撃者制御のコンテンツを受け取ったことを立証した。Kahle の応答は、影響を受けたライブラリが無効化され、システムがクリーンアップされていると述べた。これは封じ込め措置に関する声明を支持する。すべてのウェブ、ソース管理、接続サービス経路がその時点で独立して検証されたという包括的な保証を支持するものではない。[3][4]

コレクションの完全性は、その完全性アカウント内の4番目の質問を形成した。Internet Archive の使命が保存されたデジタル資料に中心を置くため、ユーザーはコンテンツ自体が変更されたかどうかを合理的に尋ねることができる。このパケットの情報源記録は、そのような改ざんを立証していない。責任ある通知は、どのチェックが現在の理解を支持し、どこで調査が不完全なままかを述べるべきであり、読者にサービスのダウンタイムから大惨事または確実性のいずれかを推測させるべきではない。

これらのコミュニケーションには日付も必要だった。保証は発行時には正確でも、新しいアクセスが発見されると後に不完全になる可能性がある。サービス状態は、DDoS 活動の再発後に変化する可能性がある。トークンインベントリは、別のプロバイダーが調査されると拡大する可能性がある。タイムスタンプ付きの声明は、組織が以前の不確実性が存在しなかったふりをすることなく記録を更新することを可能にする。

10月のアップデートは、制限を名前で挙げる価値を示している。「暫定」、「読み取り専用」、「限定的な可用性」などの言葉は、誤った終了のリスクを減らす。これらは、次のチェックポイントまたは明確な改訂メカニズムと組み合わせるべきである。利用者は調査が終了したという約束を必要としない。今、どの声明が自分の行動を支配するかを知る必要がある。

良いコミュニケーションはそれ自体が制御である。ユーザーを安全でない行動から遠ざけ、偽造されたサポートメッセージへの感受性を減らし、依存機関に継続計画の基礎を提供する。また、チームがアクティブな依存関係と権限を知らなければ機能状態を正確に説明できないため、内部の意思決定を訓練する。

復旧の証拠は稼働時間の証拠よりも強力であるべき

中心的な説明責任の問いは、Internet Archive が最終的にサービスを到達可能にしたかどうかではない。それは、各復旧決定を正当化した証拠と、再発のリスクが低減されたことを示す証拠は何かである。

稼働時間はリクエストと応答で実証できる。より安全な復旧には、より広範な記録が必要である。これには、日付入りの資産インベントリ、特定された信頼ドメイン、失効された認証情報、再構築されたシステム、レビューされたデプロイメント経路、復元された監視、テストされたロールバック手順、機能固有の承認が含まれる場合がある。公的情報源はこれらの成果物の完全なセットを開示しておらず、したがって報告にそれらが存在しないことを、作業が行われなかった証拠として提示すべきではない。重要なのは、信頼できる終了がこの種の証拠に依存することである。

証拠は観察された次元に直接関連すべきである。アカウント漏洩については、影響を受けた認証ストアがどのように範囲設定され、どのアカウント保護が続いたかを説明すべきである。改ざんについては、コードと依存関係の完全性がどのように再確立されたかを説明すべきである。DDoS 妨害については、新たなトラフィック圧力の下でサービスをどのように復旧できるかを説明すべきである。ヘルプデスクアクセスについては、サードパーティのトークンとセッションがどのようにインベントリされ、無効化されたかを説明すべきである。

復旧された各機能には、保証ケースも必要である。Wayback 検索経路には、ページ配信、インデックス、ストレージアクセス、それらを接続するサービスアイデンティティに対する信頼が必要な場合がある。アップロードには、認証、入力処理、メタデータ書き込み、モデレーション、ストレージ変更に対する信頼が必要である。貸出は権利とトランザクション状態を追加する。レビューはユーザー生成コンテンツを追加する。図書館間貸出は機関ワークフローと通信を追加する。同じプラットフォーム名がこれらの保証ニーズを同一にするわけではない。

保証ケースは悪用可能な詳細を明らかにする必要はない。レビューされたシステムの範囲、失効された認証情報のカテゴリ、テスト方法、強化監視の期間、残余リスクを受け入れた権限を述べることができる。秘密を公開することなく制限を特定できる。これにより、利用者と監視機関は「セキュリティが強化された」よりも実質的なものを得ることができる。

独立した証拠はケースを強化できるが、「独立」にも定義が必要である。第三者評価、外部侵入テスト、影響を受けたサービス外の内部チーム、プロバイダーの証明、公開研究者の検証は、異なる質問に答える。Troy Hunt の検証は、アカウントデータセットの信頼性を支持した。復旧されたプラットフォームを認証したわけではない。[8] ヘルプデスクプロバイダーのログは、トークンアクセスの範囲設定を支持するかもしれない。コレクションの完全性を立証するわけではない。証拠は、それが答えるように設計された質問を超えて拡張されるべきではない。

10月28日のサービスアップデートは、この枠組みで最もよく理解される。それは復旧のチェックポイントである。進捗と復帰する能力を文書化できる。最初の停止より後であるという理由だけで完全な修復を証明することはできない。[2] 長期的な信頼には、失効されたアクセスの再利用の試みの監視や新たに復旧された機能のテストなど、関連する制御が効果的であり続けたというその後の証拠が必要である。

基準は不確実性も認めるべきである。プラットフォームは、すべての質問に回答する前に、不可欠な読み取りサービスを復旧する必要があるかもしれない。説明責任のある応答は、残存する不確実性を述べ、機能を制限し、監視し、ロールバック経路を保持することである。不確実性が消えたふりをすることは、それを認めるよりも多くのリスクを生み出す。

文化的記憶は可用性の結果を変える

Internet Archive は、人々が保存されたウェブページやデジタル資料を取得するためのプラットフォームである。研究者は過去のキャプチャを使用して変化する主張を再構築する。ジャーナリストは公的声明や消えたページを調査するためにそれらを使用する。図書館やアーキビストは自身の保存作業をサービスに接続する。一般市民は元の場所に存在しなくなった資料を回収するためにそれを使用する。

これらのサービスが利用不可になると、結果は失われたブラウジング時間に限定されない。証拠へのアクセスが遅れる可能性がある。研究者は過去のページを検証できないかもしれない。図書館のワークフローが一時停止するかもしれない。引用が一時的に到達不能になるかもしれない。これらは、基礎となる保存コレクションが破壊または変更されたと報告されていない場合でも、文化的および証拠的記憶に対する可用性の害である。

その区別は、2つの反対の誤りを防ぐ。1つは、このパケットの情報源がコレクションの破壊を立証していないため、停止を軽視することである。プラットフォームが公的記録と保存文化への実用的なゲートウェイである場合、可用性は依然として重要である。もう1つは、ダウンタイムがアーカイブ自体の損失を証明すると暗示することである。そうではない。サービスアクセス、アカウントの機密性、配信の完全性、コレクションの完全性は別個の状態である。

プラットフォームの責任はこの組み合わせから生じる。Internet Archive は、リポジトリだけでなく、インターフェース、アカウント、貸出機能、機関サービス、サポートチャネルを運用していた。したがって、その義務には、人々が資料を取得できる条件を維持すること、利用者情報を保護すること、貢献機能やアイデンティティ依存機能を再開しても安全な時期を決定することが含まれていた。

これは、ランサムウェアから回復する古い公的機関に関する一般的な話ではなく、プラットフォームのケースである。関連するコントロールサーフェスは、運用されるサービスである。公開読み取り経路、利用者アカウント、JavaScript 配信、開発およびデプロイメントアクセス、ヘルプデストークン、アップロード、レビュー、貸出、プログラム固有のサービスである。この焦点は、別の文化組織からレガシーシステムの物語を借用するのではなく、2024年の Internet Archive イベントの証拠に分析を維持する。

組織の非営利ステータスは基準を解決しない。それはリソースとトレードオフを形成するかもしれないが、ここで検討された公的記録は、完全な予算、人員、復旧制約を立証していない。非営利ステータスは、不十分なケアの証明でも、利用者に対する義務を放棄する理由でもない。比例した問いは、運用者が実際のプラットフォームによって生み出されたリスクを特定し、その選択について信頼できる証拠を生み出したかどうかである。

プラットフォームの公共的価値は、段階的な復帰を正当化できる。また、明確さの負担を高めることもできる。下流のユーザーが検索に依存する場合、漠然とした停止メッセージは不確実性を彼らに移す。アカウント保有者が露出に直面する場合、一般的な使命声明は彼らに取るべき行動を伝えない。したがって、文化的重要性はスピードの言い訳ではなく、復旧決定を理解可能にする理由である。

説明責任は実質的な制御に従うべきである

複雑なインシデントは、「本当に責任があるのは誰か」という議論を招く。プラットフォームか、攻撃者か、ソフトウェアプロバイダーか、ヘルプデスクベンダーか、トークンのローテーションに失敗した個人か。より有用な説明責任モデルは、予防、検出、封じ込め、コミュニケーション、修復に対する実質的な制御に従う。

Internet Archive は、どのサービスを運用するか、どのデータを収集するか、どのプロバイダーに接続するか、どの機能を復旧するか、何を利用者に伝えるかについての決定を制御していた。サードパーティのヘルプデスクプロバイダーは、自身のプラットフォーム、ログ、トークンメカニズムの一部を制御していた。個々のユーザーは自身のパスワード選択を制御していたが、認証データベースの保存やプラットフォーム全体のセッションポリシーを制御していなかった。DDoS 攻撃者は敵対的トラフィックを制御していたが、組織の復旧決定を行っていなかった。

これらの責任は同一になることなく重複する可能性がある。プロバイダーはトークンを無効化する技術的能力を持ち、顧客はそれを無効化すべき知識を持つ。プラットフォームは他で維持されているライブラリに依存しながら、訪問者にデプロイするものに対する責任を保持する。利用者は再利用されたパスワードを変更する必要がある一方で、プラットフォームは正確な通知と封じ込めに対する責任を保持する。

このモデルは、影響だけで過失を推測することを避ける。重大な侵害は実質的な制御にもかかわらず発生する可能性があり、短い停止は弱い調査を隠す可能性があり、長い復旧は慎重さか脆弱性のいずれかを反映する。公的記録は、最終的な責任配分に必要な内部証拠を提供しない。しかし、必要な各アクションを誰が実行できるか、そしてアクションが発生したことをどの証拠が示すべきかを問うには十分である。

実質的な制御は、復旧責任テーブルで文書化できる。1つの列は資産または機能に名前を付ける。他の列は、運用者、認証情報所有者、証拠保有者、失効権限、復旧承認者、コミュニケーション所有者に名前を付ける。サードパーティサービスの場合、テーブルはエスカレーションがどのように境界を越えるかを示すべきである。公開読み取りサービスの場合、監視が新たな侵害を示した場合に誰がそれをオフラインにできるかを示すべきである。

目的は、インシデント後に官僚主義を生み出すことではない。時間が重要なときに曖昧さを排除することである。サポートトークンを無効化できる人や読み取り専用復帰を承認できる人が誰もいない場合、調査者が攻撃者がどのように侵入したかを判断する前から、プラットフォームには制御問題がある。

未知のものは可視化されたままにすべきである

公的記録は実質的だが不完全である。このセットの情報源は包括的なフォレンジックレポートではない。その制限は、記事の結論と後の終了主張の両方を形成すべきである。

認証データベースへの正確な初期アクセス経路は、裁定された技術的調査結果ではなく、報告された問題のままである。GitLab 設定トークンとより広範な認証情報露出に関する BleepingComputer の説明は関連する報道だが、経路の多くは攻撃者とされる人物との接触を通じて説明された。独立した証拠なしに決定的な根本原因に昇格されるべきではない。[11]

漏洩、改ざん、DDoS 活動、ヘルプデスクアクセス間の関係も未解決のままである。イベントは重複、日和見、または別々の関係者を含んでいた可能性がある。タイミングと公的申し立てはその問題を解決しない。最も正確な説明は、観察可能な行為を説明し続け、より狭い声明をそれを作った情報源に帰するものである。

取得された非アカウントデータの総量は確定していない。パケットは、すべてのサポートチケットまたは添付ファイルがダウンロードされたことを証明していない。特定の削除依頼がアクセスされたかどうかを確定していない。到達したソースコード、シークレット、接続システムの完全なインベントリを提供していない。

同様に、記録は動機、国家スポンサー、定量化された財務損失、または最終的な規制違反を確定しない。これらの欠落は、プラットフォームの規模や文化的重要性から答えを推測する招待状ではない。それらは、責任を持って言えることの限界である。

是正は依然として証拠の問題である。Kahle の同時代の声明と公式サービスアップデートは、クリーンアップ、セキュリティ強化、段階的復帰を説明している。それらは、すべての是正措置の独立したテストや長期的なセキュリティの証明を提供しない。[2][4] 後の日付は、より強力な証拠と同じではない。

未知のものを可視化し続けることは、説明責任を弱めない。それは説明責任をより正確にする。意思決定者は、未解決の各質問に所有者を割り当て、必要な証拠を特定し、質問が未解決のままどのサービスが運用できるかを決定できる。利用者は、既知の露出と可能性のある露出の違いを理解できる。公的信頼は、後に撤回しなければならない時期尚早な確実性よりも、境界のある不確実性によってよりよく支えられる。

文化記憶プラットフォームのための復旧証拠基準

Internet Archive インシデントは、他の文化記憶プラットフォームが使用できる実用的な基準を示している。それは法的テストではなく、Internet Archive がすべての要素に失敗したという調査結果に依存しない。それは、そのようなプラットフォームが運用することを選択した機能によって生み出された一連の証拠質問である。

第一に、プラットフォームは機密性、完全性、可用性、サードパーティイベントを分離するインシデント時系列を維持すべきである。すべてのエントリは、その情報源と信頼性を特定すべきである。これにより、DDoS の再発がデータベースアクセスに関する証拠と誤認されることや、攻撃者の声明が公式調査結果として扱われることを防ぐ。

第二に、認証情報終了記録を維持すべきである。記録は、利用者アカウント、特権ユーザー、サービスアカウント、デプロイメントシークレット、API キー、サードパーティトークン、アクティブセッションをカバーすべきである。ローテーションが開始されただけでなく、失効がどのように検証されたか、まだ除外できない残余アクセスについても述べるべきである。

第三に、機能レベルの復旧マップを公開すべきである。公開検索、認証アクセス、アップロード、レビュー、貸出、機関プログラム、サポートチャネルは、それぞれ状態、制限、承認日、次のチェックポイントを持つべきである。Internet Archive の10月アップデートは、サービスと保留された機能を名前で挙げることにより、このアプローチの公的基盤を提供した。[1][2]

第四に、サービス可用性に関する証拠とコレクション完全性に関する証拠を分離すべきである。検索の成功はオブジェクトへのアクセスを実証するが、すべてのオブジェクトとメタデータアイテムが変更されていないことを必ずしも証明しない。完全性の主張は、実際に実行されたチェックとそれらのチェックのカバレッジに関連付けるべきである。

第五に、サードパーティの境界を文書化すべきである。接続されたプロバイダーごとに、プラットフォームはどのデータが存在するか、どのアイデンティティとトークンがそれに到達できるか、誰がログを保持するか、どの程度迅速にアクセスを停止できるか、コミュニケーションチャネル自体が侵害された場合にどのように利用者に通知するかを知るべきである。

第六に、安定した定義を使用する利用者向け通知を提供すべきである。アカウント記録は黙って「すべてのユーザー」になるべきではない。パスワードハッシュは読み取り可能なパスワードとして説明されるべきではない。可能性のあるチケットアクセスは確認された一括抽出になるべきではない。範囲の変更は日付を付けて説明されるべきである。

第七に、復旧保証ケースを保存すべきである。ケースは、観察された各インシデント次元を是正措置、テスト、監視に関連付けるべきである。残存する不確実性とロールバック権限を特定すべきである。リーダーシップがサービス状態を承認するのに十分強力で、防御秘密を公開しないのに十分制限されるべきである。

最後に、プラットフォームはサービス復帰後に証拠を再検討すべきである。プレッシャーの下で行われた復旧決定は合理的であり得るが、後の検証を必要とする。古い認証情報の使用試行、異常なサポート活動、完全性アラート、サービス低下は、修復が維持されたかどうかをテストできる。終了の問いは、インシデントがステータスページから消えるかどうかではない。再発の条件が低減されたことをプラットフォームが示せるかどうかである。

復旧は証明を必要とする主張である

Internet Archive の2024年の危機は、困難なバランスを可視化した。サービスをオフラインに保つことは文化記憶へのアクセスを制限した。広範に戻しすぎると、これらのサーフェスが理解される前に、アイデンティティ、書き込み経路、またはサードパーティリスクを再導入する可能性があった。読み取りアクセスの段階的復帰は、それらの義務を一緒に保持する1つの方法を示した。

その順序は、自動的な賞賛も自動的な非難も受けるべきではない。その説明責任の価値は、その背後にある証拠に依存する。なぜあるサービスが他のサービスより先に戻ったのか、どの認証情報と依存関係がレビューされたのか、何が利用不可のままであったのか、利用者に何が伝えられたのか、どの監視がロールバックを強制できるのか。

インシデントはまた、プラットフォームが復旧を稼働時間の言葉だけで説明できない理由を示した。ページが読み込まれた後も、アカウント記録は露出の問題であり続けた。コアサイトの状態が変わった後も、ヘルプデスクトークンはサードパーティの問題であり続けた。JavaScript の改ざんは、DDoS 容量とは異なる配信完全性の問題を提起した。文化記憶へのアクセスは、分割できない1つのサービスとしてではなく、部分的に戻った。

したがって、適切な公的基準は要求が厳しいが境界がある。Internet Archive は、でっち上げられたフォレンジック事実、想定された動機、またはすべての破壊的行為に1つの作者がいたという主張に基づいて判断されるべきではない。それは、実質的に行使できる制御と、通知、失効、順序付け、より安全な復旧のために生産できる証拠に基づいて判断されるべきである。

公開ウェブの痕跡を保存するプラットフォームにとって、復旧自体が歴史的記録の一部である。信頼できる記録は、何が起こったか、何が不明のままか、どの機能が戻ったか、そしてなぜユーザーが今それらの機能を信頼すべきかを述べる。それ以下のものは、復旧を主張に変える。その主張がテスト可能になったとき、プラットフォームの責任が始まる。

Internet Archive は文化的記憶の復旧をプラットフォーム責任の試金石にした

概況