WebRTC を完全に無効にすることはできますか?

はい、Firefox の場合: about:config → media.peerconnection.enabled → false。 Chromium ブラウザは、拡張機能なしではトグルを公開しません (uBlock Origin には設定があります。Google の WebRTC Network Limiter は別の設定です)。無効にすると、通話に WebRTC を使用するサイトが中断されます。

VPN は WebRTC 漏洩を防ぎますか?

ブラウザによって異なります。最近のブラウザではメディアの許可がなければパブリック IP を JavaScript に公開しないため、デフォルト設定では VPN を介した受動的な WebRTC 漏洩はほとんどありません。ただし、ページが getUserMedia を呼び出し、ユーザーが受け入れる場合、収集された候補には VPN のパブリック IP (これは予想通り) が含まれる可能性があり、VPN 周りで IPv6 スタックが漏洩している場合は実際の IP が含まれる可能性があります。

STUN サーバーとは何ですか?誰がそれを実行していますか?

STUN サーバーは、表示されるソース IP とポートを反映するだけです。小規模でステートレスで、無料で実行できます。 Google は公開 STUN サーバーを stun.l.google.com:19302 で運営しています。 Twilio、Mozilla などが独自のサービスを実行しています。多くのアプリはデフォルトで Google を使用します。 STUN サーバーは、リクエストが発生したことだけを認識します。彼らはその後に流れるメディアを見ていません。

WebRTC は暗号化されていますか?

常に、仕様に従って。 DTLS ハンドシェイクは、メディアを暗号化する SRTP のキーを取得します。データチャネルは DTLS によって暗号化されます。暗号化を無効にすることはできません。エンドツーエンドの暗号化は別のプロパティです。SFU を介したグループ呼び出しは、アプリケーションが明示的に実装している場合にのみ E2EE になります (Zoom、Signal は実装します。多くの単純なアプリは実装しません)。

10 年前と比べて、ブラウザ間のビデオが今では非常に優れているのはなぜですか?

コーデックハードウェアアクセラレーション (GPU 上の AV1、VP9、H.264)、リアルタイムメディアに合わせた輻輳制御 (Google の輻輳制御アルゴリズム)、およびより頻繁にダイレクトパスを可能にする NAT トラバーサルの改善。これらはすべて WebRTC 内にあります。

WebRTC の説明: ビデオ通話を強化し、場合によっては IP を漏洩するブラウザプロトコル

Q: WebRTC は暗号化されていますか?

常に、仕様に従って。 DTLS ハンドシェイクは、メディアを暗号化する SRTP のキーを取得します。データ チャネルは DTLS によって暗号化されます。暗号化を無効にすることはできません。エンドツーエンドの暗号化は別のプロパティです。SFU を介したグループ呼び出しは、アプリケーションが明示的に実装している場合にのみ E2EE になります (Zoom、Signal は実装します。多くの単純なアプリは実装しません)。

Q: 10 年前と比べて、ブラウザ間のビデオが今では非常に優れているのはなぜですか?

コーデック ハードウェア アクセラレーション (GPU 上の AV1、VP9、H.264)、リアルタイム メディアに合わせた輻輳制御 (Google の輻輳制御アルゴリズム)、およびより頻繁にダイレクト パスを可能にする NAT トラバーサルの改善。これらはすべて WebRTC 内にあります。

WebRTC は、2 つのブラウザが音声、ビデオ、またはデータを使用して、ピアツーピア、低遅延で相互に直接通信できるようにするプロトコルです。これにより、ブラウザベースのビデオ通話が可能になりました。また、ブラウザーは、NAT を通じてお互いを見つけるために、JavaScript に公開される方法でパブリック IP を調査する必要があるため、まったく新しいカテゴリーのプライバシー漏洩も生み出しました。

記事全文は以下に英語で記載されています。

WebRTC (Web リアルタイム通信) は、Web ページが相互に、またはネイティブアプリケーションと直接ピアツーピア接続を確立できるようにする、最新のブラウザーに組み込まれた一連の API です。これは、Google Meet、ブラウザーの Zoom、Discord の音声チャット、当時の Twitter Spaces、そして無数の小規模なサービスを支えています。 WebRTC がなければ、リアルタイムブラウザビデオは依然として Flash-or-bust の提案になります。

仕様の内容

WebRTC には 3 つの主要 API がバンドルされています:

getUserMedia — カメラにアクセスし、マイク
RTCPeerConnection — 実際のピア接続を管理します: コーデックネゴシエーション、暗号化、NAT トラバーサル、輻輳制御
RTCDataChannel — 接続上で任意のバイナリデータまたはテキストデータを送信します。ピアツーピア

接続自体は、NAT トラバーサルに ICE (対話型接続確立)、ハンドシェイク暗号化に DTLS、メディア暗号化に SRTP を使用します。デフォルトでは、接続全体がエンドツーエンドで暗号化されます。

ピアがお互いを見つける方法

ピアツーピアの難しい部分は、通常、両方のピアが NAT の背後にあることです。 WebRTC は ICE を使用して、可能なネットワークパスを検出します。

ブラウザは、STUN サーバー に「私のパブリック IP とポートはどのようになっていますか?」と尋ねます。 STUN サーバーは、確認した送信元アドレス (NAT の外部マッピング) で応答します。
ブラウザは、すべての候補アドレスを収集します。LAN 上のローカル IP、STUN で検出されたパブリック IP、NAT を通過できない場合は、オプションで TURN リレー。
ピアは、シグナリングチャネルを介して候補リストを交換します。 (通常はアプリケーションのサーバーへの WebSocket)。
成功するまですべての組み合わせで接続を試行します。

IP リークの問題

候補収集ステップが WebRTC IP リークの原因です。 JavaScript はブラウザーに ICE 候補の収集を開始するように要求できます。すると、ブラウザーは結果として得られるパブリック IP とローカル IP をページに表示します。あなたを追跡したいページは、new RTCPeerConnection().createDataChannel(...) を呼び出して候補を収集し、HTTP 層の難読化に関係なく実際の IP を認識できるようになります。

これは 2015 年に発見され、すぐに標準的なプライバシーフットガンになりました。 WebRTC リークは、VPN 上のユーザーが正しい方法を求める Web サイトに実際の IP が依然として表示される理由です。

これに対する対策

ブラウザベンダーは、ページに表示できる候補を段階的に制限することで対応しています。

最新の Chrome/Firefox/Safari のデフォルト動作は、明示的な許可なしに、ローカル IP (LAN 上の IP、通常は 192.168.x または 10.x) を公開します。
mDNS ホスト名は、接続用のローカル IP を置き換えます。192.168.1.42 を公開する代わりに、ブラウザはランダム化された .local ホスト名を使用します。
ページが呼び出す場合getUserMedia (実際のビデオ通話など)、ブラウザはパブリック IP を含む完全な候補を収集します。その時点でメディア許可を付与したことになります。

その結果: パッシブ WebRTC IP リークはデフォルト設定でほとんど解決されました。積極的に候補者を集めるサイトは今も存在しており、古いブラウザや緩い設定を使用しているユーザーは依然として脆弱です。 WebRTC リークガイドでは検証について説明しています。

ピアツーピアが重要な理由

2 人通話の場合、WebRTC はピア間でメディアを直接送信し、シグナリングサーバーは接続のセットアップにのみ使用されます。ビデオはアプリケーションのサーバーを通過しません。これにより、運用コストが大幅に安くなり (メディアの帯域幅コストが不要)、遅延が大幅に短縮されます (追加のホップが不要)。グループ通話には通常、メディアを中継するサーバーである選択転送ユニット (SFU) が必要ですが、正しく構成されていれば暗号化は依然としてエンドツーエンドです。

WebRTC の行方

次の主要なステップは、WebTransport (非リアルタイム双方向ストリーム用の低レベル QUIC ベース API) です。 WebCodecs (エンコーダ/デコーダハードウェアへの生のアクセス)。これらを組み合わせることで、クラウドゲーム、ブラウザーでの低遅延ビデオコード変換、RTCDataChannel.

よりも優れた輻輳制御による大量のピアツーピアファイル転送などの新しいユースケースが可能になります。p>WebRTC 自体も最新化されています。元のプラン B の SDP セマンティクスは統合プランを支持して段階的に廃止され、API サーフェスは開発者にとってよりクリーンになっています。

よくある質問

WebRTC を完全に無効にすることはできますか?: はい、Firefox の場合: about:config → <code>media.peerconnection.enabled</code> → false。 Chromium ブラウザは、拡張機能なしではトグルを公開しません (uBlock Origin には設定があります。Google の WebRTC Network Limiter は別の設定です)。無効にすると、通話に WebRTC を使用するサイトが中断されます。
VPN は WebRTC 漏洩を防ぎますか?: ブラウザによって異なります。最近のブラウザではメディアの許可がなければパブリック IP を JavaScript に公開しないため、デフォルト設定では VPN を介した受動的な WebRTC 漏洩はほとんどありません。ただし、ページが getUserMedia を呼び出し、ユーザーが受け入れる場合、収集された候補には VPN のパブリック IP (これは予想通り) が含まれる可能性があり、VPN 周りで IPv6 スタックが漏洩している場合は実際の IP が含まれる可能性があります。
STUN サーバーとは何ですか?誰がそれを実行していますか?: STUN サーバーは、表示されるソース IP とポートを反映するだけです。小規模でステートレスで、無料で実行できます。 Google は公開 STUN サーバーを stun.l.google.com:19302 で運営しています。 Twilio、Mozilla などが独自のサービスを実行しています。多くのアプリはデフォルトで Google を使用します。 STUN サーバーは、リクエストが発生したことだけを認識します。彼らはその後に流れるメディアを見ていません。
WebRTC は暗号化されていますか?: 常に、仕様に従って。 DTLS ハンドシェイクは、メディアを暗号化する SRTP のキーを取得します。データチャネルは DTLS によって暗号化されます。暗号化を無効にすることはできません。エンドツーエンドの暗号化は別のプロパティです。SFU を介したグループ呼び出しは、アプリケーションが明示的に実装している場合にのみ E2EE になります (Zoom、Signal は実装します。多くの単純なアプリは実装しません)。
10 年前と比べて、ブラウザ間のビデオが今では非常に優れているのはなぜですか?: コーデックハードウェアアクセラレーション (GPU 上の AV1、VP9、H.264)、リアルタイムメディアに合わせた輻輳制御 (Google の輻輳制御アルゴリズム)、およびより頻繁にダイレクトパスを可能にする NAT トラバーサルの改善。これらはすべて WebRTC 内にあります。