Android のアプリ別 VPN と Chrome のシークレット: ルールが対象とする範囲

シークレットタブが現れたら VPN をオンにする自動化を誰かが作りましたが、それは確実には動作しません。それには構造的な理由があり、自動化を調整する前に理解しておく価値があります。Android のアプリ別 VPN ルールはアプリケーションのパッケージを選択し、シークレットは一つのパッケージ内の状態であるため、ルールは両者を区別できません。通知はブラウザがすでに動作を始めた後に発火するため、正しいトリガーでも遅れて届きます。以下のチェックを順番に進めてください。四番目のチェックで失敗するなら、変更すべきは設定ではなくアプローチです。

チェック一: アプリ別ルールが何を選べるかを確認する

Android の VPN アプリは許可または除外するアプリのリストでトンネルを構築し、そのリストはパッケージ名を取ります。通常モードの Chrome とシークレットモードの Chrome は同じパッケージであり、ユーザー ID もネットワーク権限も同じなので、Chrome を含める、または除外するルールはどちらにも同じように適用されます。プラットフォームにはタブ単位の ID がなく、照合できません。

これは回避すべき欠陥ではなく、API が提供する粒度です。要件が Chrome の通信をトンネル経由にし、それ以外を外に出すことなら、アプリ別ルールはそれを正確に表現します。要件がプライベートタブだけをトンネル経由にし、通常のタブは直接通信させることなら、どのアプリ別ルールでも表現できず、通知ロジックをどれだけ足してもプラットフォームにないセレクターは追加されません。

チェックの際はパッケージ ID の罠に注意してください。ベータ版やベンダーのビルドは安定版ブラウザとは別のパッケージなので、片方をカバーするルールはもう片方を静かに見落とします:

adb shell pm list packages | grep -i chrome

チェック二: トリガーが十分に早くなり得るかを試す

通知リスナーは、見ることを許可された通知を観察します。観察は傍受ではありません。通知が存在する時点で、ブラウザはすでに名前を解決し接続を開いており、その経路のどこも自動化の完了を待ちません。その後に VPN クライアントを起動するタスクは、クライアントの UI、同意プロンプト、トンネルのハンドシェイクを待つ必要があり、これらは秒単位で測られる一方、最初のリクエストはミリ秒単位で測られます。

検出そのものが二つ目の理由で脆いものです。通知のテキストはバージョンやローカライズによって変わるため、あるリリースに一致したパターンは更新後に一致しなくなり、その失敗は静かなものです。通知がないことはプライベートブラウジングがない証拠ではありません。文字列が変わったか、チャネルがミュートされただけかもしれません。

このワークフローには正規の版があり、それは反応的ではなく順序立てられています。まず承認済みの VPN に接続し、トンネルが通信を運んでいることを実際に証明する準備完了シグナルを確認し、その後にサポートされたブラウザ操作でシークレットセッションを開き、準備完了チェックが失敗したら停止します。これは、すでに実行中のセッションを守るふりをせずに、これから始めるセッションを守ります。

チェック三: 付与しようとしている権限を監査する

通知へのアクセスは、ブラウザだけでなくすべてのアプリの通知をサービスが読めるようにする機微な許可です。一つのブラウザ状態を監視するために未知の自動化ツールへ与えるのは悪い取引であり、実験が終わってもアクセスは残ります。ユーザー補助によるタップはさらに悪く、UI 上のスクリプトレイヤーであってサポートされた VPN 制御インターフェースではなく、レイアウトが変わるたびに壊れます。

何かを付与する前に、同じ結果をサポートされた仕組みで達成できないか尋ねてください。答えがポリシー要件である場合は、たいてい達成できます。プラットフォームは監視サービスなしでアプリやプロファイルにトンネルを強制できます。

チェック四: 要件が強制である場合は常時接続とブロックを使う

ブラウザがトンネルの外と決して通信してはならないなら、強制はマクロではなくプラットフォーム設定に属します。Android はトンネルが確立されていないときに通信を防ぐブロックモード付きの常時接続 VPN をサポートし、管理対象デバイスはポリシーで適用できます。仮定せずに、デバイスが現在何を持っているかを確認してください:

adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

アプリの値が null でないことはパッケージが常時接続として設定されていることを意味し、ブロックの値が 1 であることはトンネル外の接続がブロックされていることを意味します。この組み合わせが最善努力の習慣を保証に変え、競合を完全に取り除きます。アプリの通信が許可される前にトンネルが確立されるからです。

ここで二つの境界を述べておく価値があります。仕事用プロファイルは独自の VPN 設定を持つため、個人プロファイルで検証したルールは仕事用について何も語りません。また、別にインストールしたブラウザ、別のアプリが開くカスタムタブ、アプリ内の webview は独自のルーティングを持つ別のパッケージやコンテキストなので、見た目の違うウィンドウを別ドメインとみなさず、実際のパッケージを確認してください。

チェック五: ワークフローを書き留め、失敗経路をテストする

何を選ぶにしても、順序と中断条件を文書化してください。利便性のワークフローなら、トンネルを上げ、準備完了を証明し、シークレットを開き、準備完了が失敗したら確実に停止します。強制の経路なら、常時接続アプリを設定し、ブロックを有効にし、トンネルがまったく上がらない場合の期待動作、つまり保護されない通信ではなく通信なしを定義します。

そして成功だけでなく失敗をテストしてください。セッション中にトンネルを切断してブラウザの動作を観察し、VPN アプリのプロセスをブロックして漏えいがないことを確認します。最後に、ユーザー向け文書では二つのプライバシーモデルを分けてください。シークレットは一時的なブラウザ状態を制御し、ネットワークから通信を隠しません。一方 VPN は通信を運びますが、ログインやプライベートセッション内で送信したものを消去しません。