CrispGuard のマスクはローカルで行われるのか。スクリーンショットや録画で、拡張自身が内容を漏らすことはあるか

CrispGuard のマスクはブラウザの中で描かれます。キーワードはバーに、画像はプレースホルダーに、範囲はオーバーレイになり、そのどれもサーバーを必要としません。ただし働くのはページ層であり、OS 層ではありません。ブラウザの描画を経由しないキャプチャでは、マスクが写らないことがあります。本製品はセキュリティ製品ではなく、画面を暗号化するものでもありません。

CrispGuard が実際に何を覆えるのかは製品ページに三種類のオーバーレイとしてまとめてあります。このページの範囲はもっと狭く、「マスクがどこで起きるのか」「その位置が何を守り、何を守らないのか」だけを扱います。

CrispGuard のデータ経路 — ブラウザに残るもの、外に出るもの

マスク処理は拡張機能のコンテンツスクリプト、つまりすでに開いているページの中で動きます。テキストの照合、画像の差し替え、オーバーレイの描画はいずれもローカルな描画時に行われ、この経路のどこにもページをサーバーへ送る工程はありません。

CrispGuard は Chrome 拡張で、実際に処理をするのはコンテンツスクリプトです。ブラウザが、いま見ているページに注入するコードです。ドキュメントにすでにあるテキストと画像を読み、設定したキーワード一覧と照合し、ブラウザがこれから描く内容を書き換えます。一致したキーワードは塗りつぶしのバー、単色ブロック、または絵文字になります。一致した画像はプレースホルダーのブロックになります。選択した範囲にはオーバーレイが重ねられます。下のページはそのまま使えます。リンクは遷移し、フォームは送信でき、スクロールも変わりません。

これらの工程はいずれも、すでにダウンロード済みのドキュメントに対するローカルな操作です。照合の相手は拡張機能と一緒に保存された一覧であり、サーバー上のモデルではありません。この経路のどこにも、マスクのためにページをどこかへ送る段階はありません。

ただしこれはマスク経路についての話であり、何を覆っていないかを正確に述べておきます。「ローカルでマスクする」と「ネットワーク要求が一切ない」は別の主張です。後者のほうが強く、検証もできます。このページは前者を後者に格上げしません。ストアの機能説明によれば、マスクの判定と描画はお使いの端末で行われます。拡張がネットワーク上で何と通信するか（ライセンス確認など）はプライバシーポリシーが定めることであり、判断の前に読むべきはそちらの文書です。設計目標はできるだけ多くのデータをブラウザ内に留めることで、実際の通信内容はマーケティングページではなくプライバシーポリシーに書かれている事柄です。

比べる価値があるのは、より強い主張を明示している製品です。ContextBlur のプライバシーポリシーは 100% ローカル処理とネットワーク要求ゼロを明記し、自動ぼかしはユーザーが「Run auto-blur now」を押したときだけ実行され、保存するのは CSS セレクタだけでページ内容は保存しないと述べています。そこから何を読み取るにせよ、一つ有用なことが分かります。この分野では「ローカルで処理する」はベンダーが公開して問い詰められる主張であり、CrispGuard 固有の売り文句ではありません。どのベンダーについても、この製品自身についても、自社の説明だけで信じるべきものではありません。

ここでもう一つ、境界を挙げておきます。マスクが変えるのはページの表示です。ページを暗号化するわけでも、ブラウザ自身のプロセスから隠すわけでも、ロック解除済みの端末に触れられる人が開発者ツールを開いて DOM を直接読むのを止めるわけでもありません。CrispGuard は共有スペースのためのプライバシー上の便宜であり、セキュリティ製品ではなく、そう説明されるべきでもありません。

スクリーンショットや画面録画のとき、マスクはどうなるか — 覆えるもの、覆えないもの

決めるのはキャプチャ経路だけです。ブラウザが描画したページを読むツールなら、マスクはたいていその画像に含まれます。OS のフレームバッファを読む場合や、カメラで画面を撮る場合は、拡張機能がマスクをそこへ置くことはできません。

仕組みが結果を説明します。ブラウザ拡張はページの描画パイプラインの内側にいて、DOM とそれに適用されるスタイルを書き換え、ブラウザが結果を描きます。キャプチャツールは二系統あります。一方はブラウザに「いま何を表示しているか」を尋ね、拡張がすでに変更した描画結果を読みます。もう一方は OS のフレームバッファ、つまり画面全体を合成した画像を読み、ページには一切問い合わせません。

プラットフォームが協力すれば二系統目が何をできるかは、モバイルが示しています。Android の FLAG_SECURE はプラットフォームのセキュリティ層でスクリーンショットを遮断し、OS がキャプチャ自体を拒否します。Chrome 拡張にはそれに相当する層がありません。Windows、macOS、あるいはキャプチャ機器に「このフレームを拒否せよ」と指示できる API は存在しません。

CrispGuard のマスクはページ層の可視性制御であり、スクリーンショットの阻止ではありません。ハードウェア水準でキャプチャを止める必要があるなら、OS やプラットフォームが提供する安全な表示の仕組みを使ってください。ブラウザ拡張ではありません。

実務的な帰結は二つです。一つ目は、試していないキャプチャではマスクは写らないものとして扱うこと。二つ目は、試すのは安いということです。実際に使っているツールで、実際にマスクしたページを一度撮って、結果を見てください。

サイトロックの PIN はどう保存されるか — 検証できる信頼の材料

サイトロックの PIN はソルト付きハッシュとして保存され、平文では保存されません。拡張のローカルストレージを読んでも、解除欄に打ち込める値は得られません。設定画面は通常のままで、PIN を尋ねるのは解除のときだけです。

サイトロックは PRO 機能で、ロックしたサイトの保護を外す前に PIN を求めます。拡張が保存するのはその PIN のソルト付きハッシュ — PIN をランダム値とともに一方向関数へ通したもの — であり、PIN そのものではありません。したがってローカルストレージを読んでも、そのまま使える秘密は手に入りません。ソルトも効いています。同じ PIN を使う二つの導入環境でも保存値は異なり、保存データから「PIN が同じ」であることは分かりません。

この小さな判断は、検証できるという理由で吟味する価値があります。PIN を平文で保存する製品は、保存についてどう考えているかを語っています。ハッシュを保存する製品は、その保存領域がいつか誰かに読まれると想定していたことを語っています。どちらか一方だけで製品が信頼できるようになるわけではありませんが、開くすべてのページに居座る道具なら、後者を見たいはずです。

ハッシュができないことも同じくらい重要です。守るのは保存された値であって、解除済みの状態ではありません。サイトがすでに解除されていて背後に人がいれば、その人が読んでいるのはページであり、ハッシュではありません。短い数字の PIN は試行回数が十分あれば当てられますし、ハッシュは何回まで試せるかを何も語りません。ハッシュが答える問いは一つだけ — このファイルを読んだ攻撃者は何を得るか — で、それにはきちんと答えます。

画面プライバシー拡張を信頼すべきか判断するとき、何を確認すればいいか

五つの確認で大半が決まります。プライバシーポリシーがページ内容の送信について何と言っているか、マスクが実際どの層で行われるか、どんな権限を要求したか、自動検出がクリックを待つか、そして製品が自らの限界を認めているかです。

どれも技術的な予備知識は要りません。ポリシーと権限一覧を読むだけです。開くすべてのページを読む能力を道具に渡す前に、それだけの手間は妥当でしょう。

1. プライバシーポリシーに、ページ内容・スクリーンショット・閲覧履歴を送信しないと明記されているか。この三つを名指ししたポリシーは反証可能な約束であり、「プライバシーを尊重します」だけのものはそうではありません。反証できない言葉は、後から検証もできません。
2. マスクはコンテンツスクリプト／ページ層で行われるか、それとも内容が先にサーバーへ届く必要があるか。答えは「ローカル」が設計の性質なのか、説明文の一語にすぎないのかを決めます。そしてネットワークが切れても成り立つのは前者だけです。
3. マスクと無関係な権限 — クリップボード、リクエストの傍受、機能に不相応なサイトアクセス — を要求していないか。権限はどれも、現行版が使うかどうかとは別に存在する能力です。つまり一覧が語るのは「起こりうること」であり、「いま起きていること」だけではありません。
4. 自動検出は、あなたが明示的に起動したときだけ動くか。既定で全ページを走査する機能は、クリックを待つ機能とはプライバシー上の姿勢が異なります。画面に出る結果が同じでも、同じではありません。
5. 製品が限界を明示しているか（「セキュリティ製品ではない」「OS 水準のスクリーンショットは止められない」）。それともキャプチャを阻止すると謳っているか。境界を言葉にできるベンダーは、たいてい境界がどこかを考えています。何でもできると謳うベンダーは、誤っているか、別のものを売っています。

これは採点表ではなく、このページが CrispGuard に代わって埋めるものでもありません。公開文書で確認できない項目は未確認として扱い、プライバシーポリシーを読んでください。それがこの問いへの正直な答えであり、次のリリースの後でも正しいままでいられる唯一の答えです。

よくある質問

CrispGuard はページの内容をサーバーへ送りますか。

マスクの経路では必要ありません。照合はコンテンツスクリプト内で、拡張と一緒に保存されたキーワード一覧に対して行われ、置き換えはページ自体に描かれます。したがってこの経路のどこでもページをアップロードしません。ライセンス確認など他の通信があるかはプライバシーポリシーが定めており、確認すべきはそちらの文書です。

OS のスクリーンショット機能で撮りました。マスクは写っていますか。

保証されません。OS のスクリーンショットは OS のフレームバッファを読むのに対し、拡張が変えるのはブラウザが描画した内容だけなので、写るかどうかはマスクが有効かではなくキャプチャ経路で決まります。ブラウザの描画結果を経由するキャプチャなら、通常はマスクも含まれます。

画面録画ツールで録るとマスクは残りますか。

録画ツールのキャプチャ方式によります。描画済みのページやブラウザのコンポジタを読むツールは通常オーバーレイを含みますが、OS レベルで画面を取得するツールは完全に迂回できます。CrispGuard 側の設定で変えられるものではありません。制約は拡張ではなくキャプチャ経路にあるからです。

サイトロックの PIN を忘れたら、拡張は平文で見せますか。

いいえ。保存されているのは PIN のソルト付きハッシュだけなので、拡張のローカルストレージを読んでも PIN は分かりません。これは保存されているものを守る話であり、見えるものを守る話ではありません。すでに解除済みで誰かが画面を見ていれば、PIN は無関係です。

画面プライバシー拡張はのぞき見防止フィルターの代わりになりますか。

いいえ。のぞき見防止フィルターは物理的な画面の視野角を狭めるので、隣の人はそもそも読めませんが、拡張機能が変えるのはブラウザ内の画素だけです。フィルターは画面に映るすべて — 他のアプリ、通知、ビデオ通話 — を覆いますが、ブラウザ拡張はそこまで届きません。上の境界声明が言っているのはそういうことです。ページ層の制御はスクリーンショットの阻止ではありません。

どうしてもスクリーンショットを防ぎたいときは何を使うべきですか。

プラットフォームの仕組みであり、ブラウザ拡張ではありません。Android の FLAG_SECURE、DRM で保護された再生経路、キャプチャを無効化する管理端末のポリシーはいずれも OS またはプラットフォーム層で働きます。スクリーンショットが実際に通るのはその層です。共有スペースのほとんどの場面では、のぞき見防止フィルターと画面を向こうへ向けるのが実務的な答えです。

← 記事一覧へ