Arcan Explained – A Browser for Different Webs

Operationalizing Arcan: A Multi-Protocol Browser Architecture

Arcanはディスプレイサーバーかつブラウザフレームワークであり、レンダリングをプロトコルハンドリングから切り離すことで、HTTP/HTTPS、ローカルファイルシステム、カスタムアプリケーションプロトコル、そして新興の分散ネットワークを統一インターフェース内で同時にサポートする。この構造的分離は、実証済みの運用上の非効率性に対処している。すなわち、知識労働者は通常、企業イントラネット、ピアツーピアシステム、ローカルアプリケーション、公開インターネットアクセスのために個別のツールを保有しており、これがコンテキストスイッチのオーバーヘッドと断片化されたセキュリティポリシーを生み出しているという問題である。

設計の根拠は二つの前提に基づいている。(1) プロトコルの多様性は現代の組織において運用上必然的であり、(2) モノリシックなブラウザ設計はレンダリング関心とプロトコル固有のロジックを混在させるため、拡張が高くつく。ディスプレイレイヤーをプロトコルハンドラーから抽象化することで、Arcanはコアレンダリングコードを再コンパイルすることなくハンドラーの独立的な反復を許容する。これはUnixパイプセマンティクスに類似しており、各コンポーネントが単一の責任を担当する。

運用上の前提:* このアーキテクチャは、プロトコルハンドラーが真に相互交換可能であり、リソースが隔離されている場合にのみ摩擦を低減する。ハンドラーがメモリを共有するか、ブロッキングI/Oを行う場合、統合の利益は減少する。
具体的シナリオ:* ユーザーがHTTPSウェブサイトからローカルLuaスクリプトアプリケーションへ、さらに分散ハッシュテーブル(DHT)リソースへと移動する。すべて同じウィンドウ内で、一貫したキーバインディングを使用して行われる。ディスプレイサーバーはプロトコルの起源に関わらずコンテンツをレンダリングし、プロトコルハンドラーはネットワークリクエストを標準化された中間表現(通常はドキュメントツリーまたはピクセルバッファ)に変換する。
知識労働者への実行可能な含意:* 現在のツールエコシステムを監査せよ。チームが異なるネットワークタイプにアクセスするために三つ以上の個別アプリケーションを使用している場合(例えば、ウェブブラウザ + VPNクライアント + ファイルマネージャー + カスタムイントラネットツール)、Arcanの統合モデルは評価に値する。プロトコル依存関係をマッピングし、統一されたUIパターンからの認知負荷削減を推定せよ。

System Structure and Bottlenecks

Arcanのアーキテクチャは関心を異なるレイヤーに分離する。ディスプレイサーバー(ウィンドウ合成、入力ルーティング、リソース割り当てを管理)、プロトコルハンドラー(ネットワークリクエストを標準化された中間形式に変換)、そしてスクリプティングランタイム(通常はLua。コアコードを修正することなく動的な振る舞いを可能にする)である。

二つの主要なボトルネックが浮上する。第一に、ハンドラーの複雑性。堅牢なHTTPハンドラーの構築には、パース、キャッシング、クッキー管理、証明書検証、JavaScript実行が必要である。各プロトコルが同等の深さを要求する場合、採用摩擦は増加する。第二に、リソース競合。複数のプロトコルハンドラーがメモリとCPUを競い合う場合、隔離が厳密でなければ応答性は低下する。

例:* 企業環境がArcanをウェブアクセス、内部ウィキ(カスタムプロトコル)、ファイルブラウジングに実行している。ファイルハンドラーがメモリ割り当てを隔離しない場合、大規模なディレクトリスキャンはHTTPハンドラーの応答性をフリーズさせる可能性がある。

Arcanはこれらのボトルネックをハンドラーごとの明示的なリソースクォータと非同期I/Oパターンを通じて軽減する。ハンドラーは定義されたメモリ上限を持つ個別のプロセスまたはスレッドとして実行される。一つのハンドラーが停止しても、他のハンドラーは影響を受けない。

デプロイメント時の指針:* リソース予算を事前に確立せよ。予想負荷に基づいてプロトコルハンドラーごとにメモリを割り当てよ。ハンドラー応答性メトリクス(レイテンシーパーセンタイルとCPU時間)を本番環境ロールアウト前のステージング環境で監視せよ。ハンドラーが応答しなくなった場合のフォールバックメカニズムを作成せよ。ユーザーは一つのハンドラーの障害により他のプロトコルへのアクセスを失うべきではない。

Reference Architecture and Guardrails

本番環境のArcanデプロイメントは、ハンドラー侵害がシステム全体の侵害へとカスケードするのを防ぐため、明示的なアーキテクチャ境界を必要とする。参照アーキテクチャには以下が含まれる。

コアディスプレイサーバー: レンダリング、入力イベントルーティング、ウィンドウ合成、リソース割り当てを管理する。昇格された権限で実行されるのはハードウェアアクセス(GPU、入力デバイス)のみである。
隔離されたプロトコルハンドラープロセス: 各ハンドラーは定義されたリソース制限(メモリ、CPU、ファイルディスクリプタ数)を持つ個別プロセスで実行される。ハンドラーはコアサーバーと共有メモリではなくメッセージパッシングを通じて通信する。
ポリシーエンジン: アクセス制御を強制する。ハンドラーがリソース(ファイル、ネットワークソケット、認証情報ストア)へのアクセスをリクエストする場合、ポリシーエンジンはリクエストを宣言的ポリシーに対して評価し、許可または拒否する。
監査およびロギングレイヤー: すべてのハンドラーアクション、ポリシー決定、エラーの一元化されたロギング。インシデント後の分析とコンプライアンス監査を可能にする。

ガードレール(強制メカニズム):*
直接的なファイルシステムアクセスなし: ハンドラーはコアサーバーを通じてファイルアクセスをリクエストする。サーバーはスコープ付きファイルディスクリプタ(例えば、特定のディレクトリへの読み取り専用アクセス)を付与する。ハンドラーはファイルシステムを列挙したり、スコープ外のファイルにアクセスしたりできない。
共有メモリなし: プロセス間通信は明確に定義されたメッセージ形式(例えば、Protocol Buffers、JSON)を使用する。共有メモリはデータレースを導入し、隔離境界を曖昧にする。
サンドボックス化されたスクリプティング: Luaランタイムは任意のシステムコールを防ぐサンドボックスで実行される。LuaコードはホワイトリストされたAPIのみを呼び出すことができる(例えば、文字列操作、テーブル操作、ハンドラーを通じたHTTPリクエスト)。
能力ベースのアクセス制御: ハンドラーは特定のアクセスを付与する能力(偽造不可能なトークン)を受け取る。ハンドラーはその能力なしにリソースにアクセスできない。これは、ハンドラーが攻撃者に代わってリソースにアクセスするよう騙されるconfused deputy攻撃を防ぐ。
具体的な例:* ユーザーがファイルアクセスをリクエストするウェブサイトを訪問する(例えば、ファイルアップロードフォーム)。HTTPハンドラーはポリシーエンジンに能力リクエストを送信する。「/Downloads内のファイルへの読み取りアクセスを付与せよ」と指定する。ポリシーエンジンは以下を確認する。(1) ドメインはファイルアクセスのためにホワイトリストされているか。(2) ユーザーは明示的に権限を付与しているか。(3) リクエストされたパスは許可されたディレクトリ内にあるか。すべてのチェックが合格した場合、エンジンはスコープ付きファイルディスクリプタを付与する。ハンドラーは/Downloads内のファイルのみを読み取ることができ、ファイルシステム全体ではない。ハンドラーが後に悪用された場合、攻撃者は~/Downloadsへのアクセスのみを得られ、~/.sshや/etc/passwdのような機密ディレクトリへのアクセスは得られない。
根拠:* この設計は最小権限の原則を実装する。各ハンドラーはその機能を実行するために必要な最小限の権限のみを受け取る。ハンドラーが侵害された場合、被害範囲はその割り当てられた権限に限定される。
実行可能な含意:* ポリシーエンジンルールを宣言的形式(YAMLまたはJSON)のコードとして文書化せよ。例:

handlers:
  http:
    memory_limit_mb: 512
    file_access:
      - path: /home/user/Downloads
        mode: read
      - path: /tmp
        mode: read_write
    network_access:
      - protocol: https
        ports: [443]
  custom_wiki:
    memory_limit_mb: 256
    file_access:
      - path: /opt/wiki/data
        mode: read
    network_access:
      - protocol: tcp
        ports: [8080]

このポリシーファイルをバージョン管理下に置き、変更をコードレビュープロセスを通じて行う。ポリシー変更を本番環境に適用する前にステージング環境でテストする。ポリシー違反(ハンドラーが許可されていないリソースへのアクセスを試みる)を監視し、アラートを発する。これらの違反はセキュリティインシデントまたは設定ミスを示す。

Arcanシステムアーキテクチャの4層構成を示す図。ユーザ/アプリケーションからのリクエストがプロトコルハンドラー層（HTTP/HTTPS、P2P、DHT、ローカルファイルシステム）を経由し、中間表現（IR）に変換される。その後、Luaスクリプティングランタイム層で処理され、レンダリングエンジンを通じてディスプレイサーバー層で画面表示される。各層間のデータフロー（ネットワークリクエスト→中間表現→レンダリング）が上から下へ一方向に流れる構造を表現。

図2：Arcanシステムアーキテクチャ層と依存関係*

Arcanの2つの主要ボトルネックを可視化した図。左側のハンドラー複雑性では、パース、キャッシング、Cookie管理、証明書検証、JavaScript実行が順序立てて示されている。右側のリソース競合では、複数ハンドラーがメモリとCPUをめぐって競争し、リソース枯渇に至る流れが示されている。両者のボトルネックが処理遅延を引き起こし、最終的にArcan全体の性能低下につながることを示している。

図3：Arcanの主要ボトルネック：ハンドラー複雑性とリソース競合*

Autognosis

Arcan Explained – A Browser for Different Webs

Arcan Explained – A Browser for Different Webs

Operationalizing Arcan: A Multi-Protocol Browser Architecture

System Structure and Bottlenecks

Reference Architecture and Guardrails

この記事は役に立ちましたか？