社内PCのブラウザ拡張を権限ベースで棚卸しする

「この AI 拡張、危なくないですか？」と聞かれた時に、1本を主観で判定して終わらせず、全社の拡張を権限ベースで棚卸しして事実で判断するための指示書。1台ずつ手で調べるのは不可能なので、各PCが自分の拡張を自己申告して集計先へ集約する仕組みまで作る。

想定読者は AI コーディングエージェント。この MD をそのまま読ませれば、調査 → 判定基準 → 収集ツール → 集約 → 検証まで通せる。

0. 前提と原則

• 読み取り専用で始める。削除・ポリシー配布・レジストリ変更のコードは最初のリリースに入れない。棚卸しの結果を人が見てから決める。
• 秘匿値を読まない・出さない。Cookie の値、拡張のローカルストレージの中身、認証トークンは対象外。扱うのは「権限とメタ情報」だけ。
• ブラウザを閉じさせない。ユーザーに作業させずに読める場所だけを見る。

1. 単体調査（まず1本を事実で評価する）

対象拡張について次の5点を、推測でなく一次情報で埋める。

項目	取得元
実際に付与されている権限	<User Data>/<Profile>/Secure Preferences の extensions.settings.<id>.active_permissions
どのアカウントのプロファイルか	<User Data>/Local State の profile.info_cache.<プロファイルディレクトリ名>.user_name
導入時期・稼働有無	Local Extension Settings/<id>/ のファイル更新時刻、History（sqlite。コピーしてから開く）
ログインしているか	上記ストレージ内の accessToken / メールアドレス等のマーカーの存在有無だけを数える（値は読まない）
提供元と規約	公式のプライバシーポリシー本文を取得して、学習利用・保持期間・再委託先の記述を検索する

ポリシーは「書いてあること」より「書いていないこと」を見る。 AI 系拡張の評価で効いた実例: ポリシー全文に model の語がゼロ、train は社員教育の文脈のみ = プロンプトやページ内容を学習に使うかどうかについて何も約束していない。これは「使わない」ではない。

第三者のリスク評価（拡張のリスクスコアを公開しているサービス、プライバシー調査レポート）も併せて引く。

2. 判定基準（主観を排して機械的に）

広域ホスト権限 broadHost =
  explicit_host または scriptable_host に
  <all_urls> / *://*/* / http://*/* / https://*/* のいずれかを含む

機密API SENSITIVE =
  cookies, userScripts, debugger, desktopCapture, tabCapture,
  nativeMessaging, proxy, webRequest, webRequestBlocking,
  history, management, privacy, clipboardRead

high   = broadHost かつ SENSITIVE を1つ以上持つ
medium = broadHost のみ、または SENSITIVE のみ
low    = それ以外

ブラウザ標準同梱を「除外」せず builtin フラグで区別する。 was_installed_by_default が真、または location が component / external_policy 系。除外して隠すと後から検証できないが、混ぜたままだと PDF ビューアの類が上位に並んで本物の high が埋もれる。

権限が用途に見合っているかは機械では決まらない。 パスワード管理が nativeMessaging を持つのは正当、音声入力ツールが debugger を持つのは過大。high の一覧は「削除リスト」ではなく「人が判断すべきリスト」として出す。

3. 収集ツール（各PCで動く読み取り専用スキャナ）

Chromium 系（Chrome / Edge / Brave / Vivaldi）は同じ構造なので1本でまかなえる。

• ルート: Windows は %LOCALAPPDATA%\<ベンダ>\<ブラウザ>\User Data、macOS は ~/Library/Application Support/<ベンダ>/<ブラウザ>。環境変数でルートを差し替え可能にする（テストで実ディスクを使わないため）。
• プロファイル: Default と Profile N を列挙し、Local State からアカウント名を引く。
• 拡張: Secure Preferences（無ければ Preferences）の extensions.settings。
• 有効/無効: disable_reasons が空配列なら有効、state === 0 なら無効、どちらも判断材料が無ければ「判定不能」。データが無いことを「無効」や「安全」と断定しない。

落とし穴1: 表示名が __MSG_appName__ になる

多くの拡張は manifest の name がプレースホルダなので、_locales/<ロケール>/messages.json を引かないと人が読めない表になる。

そのディレクトリ名は <version> ではなく <version>_0 のようなサフィックス付き。 バージョン文字列をそのままディレクトリ名として組み立てると名前解決が常に失敗する。実ディレクトリを列挙して当てること。

Extensions/<id>/ の中身を readdir し、
  <version> で始まるものを優先 → 見つからなければ全ディレクトリを新しい順に試す

落とし穴2: テストのフィクスチャを「理想の形」で作ると本番だけ壊れる

上のディレクトリ名を、テストでは素の <version> で作るとテストは緑のまま実環境だけ名前解決が全滅する。フィクスチャは実際のディスク構造をそのまま真似る。

落とし穴3: 「拡張0本」と「読めなかった」を混ぜない

両方を同じカウンタに入れると、警告が常時点灯して意味を失う。別々に数える。

出力は、リスク降順の決定的な順序（同点は名前 → ブラウザ → プロファイル → ID）で人が読む表と、機械用の JSON の両方。

4. 集約（既存の点検経路に相乗りする）

新しい認証情報を配らないのが最重要。各PCに書き込み権限を配ると、そのPCが乗っ取られた時に集計先ごと壊せる。既に「各PCが日次で状態を1箇所へ送っている」経路があるなら、そこに種別フィールドを足して相乗りする。

• 送信側: 既存ペイロードは一切変えず、種別付きの第2ペイロードを追加する。種別なし = 従来動作、で後方互換を保つ（旧版のまま動いているPCを壊さない）。
• 受信側: 種別で分岐し、別のシート/テーブルへ書く。既存の集計先には触らない。
• 冪等性: そのPCの行を全削除してから追記する。連投しても行が増えない形にする。
• PC識別子が空のペイロードは受け付けず 400 で拒否する。 空文字は「全行一致」になり、他のPCの行を巻き込んで消す。
• 送信量を絞る: low かつ builtin の行は送らない（1台100本超 × 台数で数千行になる）。

デプロイ順序（間違えると既存データが壊れる）

受信側を先にデプロイしてから、送信側を配布する。 逆にすると、種別を知らない旧受信側が新ペイロードを従来種別として解釈し、そのPCの既存行を空で上書きする。

進捗確認用の読み取り専用API

「何台から届いたか」を確認する手段を最初から用意する。セルの中身は返さず、PC別の件数と最終報告時刻だけ返す。これが無いと「配ったが誰からも届いていない」に気付けない。

5. 検証（ここを飛ばさない）

ユニットテストの緑は「実環境で動く」証明ではない。次を実際に実行して確認する。

1. 実機でスキャナを走らせ、名前が解決されているか（プレースホルダの残数がゼロか）を数える
2. --dry-run で送信内容を出し、秘匿値が伏字か、件数と除外ルールが効いているかを目視
3. 本番の受信エンドポイントへ実際に2回POSTし、1回目: 追加N → 2回目: 削除N・追加N になること（＝行が増えない）を確認
4. 識別子が空のペイロードが拒否されること
5. 検証で入れた行は後片付けする
6. 読み取り専用APIを叩き、届いている台数を確認

送信の失敗を無言にしない

送信を2本に増やしたとき、直列に await して外側で例外を握り潰すと、1本目が落ちた時に2本目が送られず、しかも誰も気付かない。各送信を独立させ、失敗は1行ログに出す（終了コードは 0 のままでよい。日次処理を止めない）。

6. 対処（棚卸しが終わってから）

Chromium はポリシーでブロックリストを指定でき、指定した拡張は全プロファイルから自動アンインストールされ、再インストールもできなくなる。ユーザー領域のポリシーなら管理者権限なしで設定でき、設定を消せば元に戻る。

ただしこれは棚卸しの結果を人が見て決めてから。依頼された1本だけを消すのは、たいてい的を外す。実例: 発端になった AI 拡張は1アカウントだけだったが、同格の権限（Cookie + 画面録画）を持つスクリーンショット拡張が4アカウントに入っていた。

チェックリスト

• 対象1本を一次情報（実際の付与権限・ポリシー本文・第三者評価）で評価した
• 判定基準をコードに落とし、標準同梱を除外せずフラグで区別した
• 名前解決を実ディレクトリ名に合わせ、フィクスチャも実構造を真似た
• 集約は既存経路に相乗りし、新しい認証情報を配っていない
• 冪等（連投で行が増えない）＋ 識別子が空のペイロードを拒否する
• 受信側を先にデプロイしてから送信側を配った
• 実POSTで冪等性と拒否を確認し、検証データを後片付けした
• 進捗確認用の読み取り専用APIがある
• 削除・ブロックは棚卸しの結果を人が見てから