Braveと主要なブラウザの初回起動時のネットワークトラフィックの調査結果

初回起動時にブラウザはどのように動作しているのか？

皆さんがPCの前に座って最初にすることは、たいていWebブラウザを起動することでしょう。その場合、数時間前に使用していたブラウザを再起動することが多いと思います。つまり、以前に終了したところから起動していることになります。ブラウザには既に閲覧履歴、ブックマーク、開いていたタブなどの情報が残っています。また、もし同意済みであれば、パスワードや支払い設定などの機密性の高い情報も保存されている可能性があります。また、ポップアップブロック、フィンガープリント防止、トラッカーやトラッカーを使ったプライバシー侵害広告のブロックなどのユーザー構成が記録され適用されています。これら全ての情報が、ブラウザにユーザーの「プロファイル」の一部として保存されています。

本稿では、上記のようなユーザープロファイルがまだ存在しない初回起動時に、ブラウザが標準設定でどのような動作をするかを探っていきたいと思います。Braveは標準設定でサードパーティのトラッカー（またトラッカーを使用する広告）をブロックします。さらに、フィンガープリント、メディアの自動再生、クリプトマイニング、メディア入力デバイスへのアクセスも防ぎます。他のブラウザでは、このような機能を標準で提供していません。多くのユーザーは、好みのブラウザをダウンロードしてから、ユーザー体験強化のために、セキュリティとプライバシーの拡張機能をネットで探し始めるという、手間のかかるプロセスを行っています。しかし、皆さんがブラウザを開いた瞬間から、ブラウザを好みに合わせて構成・拡張をようやく終了するまでの間に何が起きているのでしょうか？

簡易な調査からの新事実 

数週間前に、私はこの疑問を徹底的に探求することにしました。いくつかのブラウザの初回起動時の動作を調査し、発見したことをTwitter上で解説したり説明したりしました。本日は、これらの結果をまとめてお伝えし、この調査を行う方法についても少し触れたいと思います。

調査対象ブラウザ

当初の調査は、２つのブラウザを対象にしていたのですが、すぐに他のブラウザも調査してほしいと依頼されました。結局、調査した主要ブラウザは、Brave 0.68.132、Chrome 76.0.3809.132、Chrome 78.0.3895.0、Edge（Chromiumベータ）77.0.235.25、Firefox 69、Opera 63.0.3368.71、Safari 12.1.2.28でした。Lynxも調査しましたが、予想通り、特筆すべきことはありませんでした😉。

調査結果

それぞれの調査を始める前に、Windows マシンから既存のプロファイルを削除しました。その後ブラウザを起動し、40分間一切操作せず放置します。この後ご説明していきますが、主要なウェブブラウザには共通する動きが沢山ありました。

Braveの結果​Brave Results

初回起動時のリクエスト数は、今回調べたブラウザの中でBraveが最も少なく、24リクエストでした。また、リクエストの送付先がたった一つの自社管理のTLD（トップレベルドメイン）だったブラウザは、Braveだけでした。つまり、Braveは最初からリクエストをbrave.comのみに送付することで、サードパーティーにつながらないようにし、ユーザーを保護しているということです。

まず、go-updater.brave.com/extensionsへの5つのリクエストをみてみましょう。それぞれが別々のブラウザコンポーネントを要求しています。各リクエストには、OSやブラウザのバージョン情報などの617バイトのJSONデータが含まれています。これにより、サーバー側は、拡張機能のデバイスに適したバリアントを理解します。

このリクエストへの応答は、拡張機能自体ではなく指示です。最初の4つのリクエストには、拡張機能を獲得する場所と真偽判定の方法が含まれている約465バイトのJSONデータが返されます。5 番目のリクエストへの応答は空です。ここでは、JSONデータではなくHTTP ヘッダーで、componentupdater.brave.comから CRLSet （証明書失効リスト） を要求する必要があることが通知されます。

componentupdater.brave.comを呼び出すと、CRLSetのダウンロード場所を知らせる1.8KBのJSONが返されます。このURLは全てGoogleのものですが、BraveはこれらのURLを直接呼び出しません。ここでも、Braveはすべてのリクエストがbrave.comドメインを経由するようにしており、Googleサーバーからユーザーのデバイスを保護します。次の5つのリクエスト（brave-core-ext.s3.brave.comとcrlsets.brave.comへのもの）が、実際に行われたダウンロードです。

ダウンロードが完了すると、Braveはすべての拡張機能が最新であることを確認するルーチンプロセスを開始します。今回は拡張機能を更新する必要がないという確認が返されます。継続的にユーザーのプライバシーとセキュリティを守るために、この後にも確認は実施されます。

次は/promo/custom-headersへのリクエストです。このリクエストは、271 バイトの JSON を返しますが、これは、一意のユーザーエージェント（UA）文字列を置換するものです。このファイルは、特定のパートナーからのリクエストにカスタムHTTPヘッダーを追加する指示です。つまり、ユーザーが匿名でcheddar.comのプレミアムコンテンツやその他のサイトコンテンツなどに自由にアクセスできるようにします。

その後、かなり特殊なリクエストが３つ、無効なホスト名に送信されます。このホスト名は、kgcemqlxlymf、jrejbuhy、skxrkyaibqです。ドメイン名ハイジャックを検出するためのもので、他のChromiumベースのブラウザでも同様のリクエストがあります。2つ以上のリクエストが同じホストにたどりついた場合、ISPまたはネットワークがユーザーのセッションに都合のいいコンテンツを配信している可能性がある、ということになります（多くの場合、ISPが広告を表示している可能性があります）。

もう一つ、今後も出てくる一般的なリクエストがあります。GoogleのSafeBrowsingサービスに関するものです。SafeBrowsingサービスには安全ではないウェブサイトのURLの膨大なリストがあります。連携方法は参照 APIと 更新 APIの２つあります。Brave は、更新 APIを使って、安全ではないウェブサイトのURLリストをダウンロードします。これにより、サードパーティへ何度も呼び出しを行う必要がなく、ローカルリソースの参照ですむことになります。後でも触れますが、このリクエストも、safebrowsing.brave.comを経由したものになっています。

以上が、Braveの初回起動時の動作のほぼ全てです。実はもう一つ、updater.brave.com/extensionsへ呼び出しが行われます。これはインストール済みの拡張機能が全て最新であるかどうかを確認するためのもので、1.7 KBの確認応答が返されます。

もう一つ、皆さんが調査するときにここで紹介したリクエスト以外のものがみつかるとすると、それはリファラルpingです。リファラルリンクからBraveがダウンロードされた場合、リファラーにその旨を通知することになります。それには、２つのリクエストが追加されます。このリファラルシステムがどのように実行されるかは、GitHub上のBraveのUse of Referral Codesでご確認いただけます。

Chromeの結果

Chromeは、合計40のリクエストを15のホストに対して送信しましたが、ホストは全てGoogleのものでした。最初のリクエストには、ブラウザーのフラグ設定とカスタム構成に関する32KBのデータが含まれています。次のリクエストで、拡張機能のダウンロード URL が入った XMLドキュメントを取得します。Braveにも似たような動作がありましたが、他のブラウザでも同様でした。

3つ目のリクエストは、accounts.google.comにあるGoogleアカウントとID管理（GAIA）に対して行われます。これは、今回の新しいインスタンスを、クラウド上のユーザープロファイルに結び付けようとするものだと思われます。幸いにも既存のアカウントと私をリンクすることはできませんでした。 

その後、Chrome は翻訳テーブルと拡張機能を２，３ダウンロードします。この拡張機能は、Google ドキュメント、YouTube、その他の一般的なGoogle プロパティに関するものです。その後、一部の拡張機能は、accounts.google.comへ呼び出しを開始します。

Google Chromeの調査の詳細は、Twitterでご確認いただけます。

Chromium (バニラビルド)の結果

多くの人がChromiumに関心を持ち、Google Chromeとの違いがあるかどうか、あるなら何か、を知りたがっていました。結果は、Chromiumのほうが、リクエスト数が少なく、送信先のホスト数も少なく、初回起動時にダウンロードするデータ量も大幅に少ないというものでした。ただし、ダウンロード量の違いは、ChromiumではSafeBrowsingの 更新API が使用できないことが大きな理由です （リクエストの結果はHTTP 400になります）。標準設定では、Chromiumには API キーがありません。そのため、Chromiumユーザーは、最新の安全でないウェブサイトのURLリストを取得できないのです。

Google Chromeとそっくりの動作が1つありました。最初の数分間に、GAIAにリクエストを出し、このユーザーのプロファイルが取得できるかを確認することです。

Chromiumの調査の詳細は、Twitterでご覧いただけます。

Edgeベータ版（Chromium version）の結果

Microsoft EdgeのChromiumベータ版のリクエスト数は2番目に多く、リクエスト先のホスト数は最も多いという結果でした。後程、Firefoxも似たような傾向がある事をご説明しますが、どちらも起動時に、デフォルトの新しいタブページだけでなく、外部リソースにつながる別タブを開けていることが原因です。

最初のリクエストは、clients2.google.comホストに送られ、ChromeCastの利用に必要なChromeのメディアルーター拡張機能をリクエストします。これまでのブラウザと同様に、拡張機能リクエストには呼び出し用のURLが返されます。

Edgeのログには、speech.platform.bing.com、config.edge.skype.com、web.vortex.data.microsoft.com、dc.services.visualstudio.com、activity.windows.comなどのMicrosoftの他の ドメインへの呼び出しがあり驚きました、これらの呼び出しは必ずしも有害ではありませんが、少し混乱を招きます。

Microsoft Edgeがデフォルトで読み込む 2 番目のタブはmicrosoftedgeinsider.comです （Edgeベータ版 はまだプレビュー段階であり、InsiderProgramで公開されているため）。しかし、このページには、sb.scorecardresearch.comなどの一般的なトラッカーが読み込まれ、トラッカーに初回起動がされた事を伝えます。この結果、2 つの Cookie （UID と UIDR） がデバイスに保存されます。

Microsoft EdgeのChromiumベータ版の調査の詳細は、Twitterでご覧いただけます。

Firefoxの結果​Firefox Results

Firefox は、引き続き初回起動時の通信が最も多いブラウザで、個別リクエスト数は117と圧倒的な数です。ただし、ブラウザが全ての呼び出しを行っているわけでなく、起動時に立ち上がるもう一つのページが呼び出している、という点に注意が必要です。
Microsoft Edgeと同じで、Firefox は別タブを開きます。この新しいタブページが表示されている間、Firefox はバックグラウンドでmozilla.org/privacy/firefoxとそのリソースに対してリクエストを送っています。
Firefox はこの初回起動時にほぼすべてのデータをダウンロードするようです。データの大部分は、SafeBrowsingとWidevineです。奇妙なことに、FirefoxはWidevineビットを10分間隔をあけて2回ダウンロードしたようです。
Firefox について特徴的だったことは、初期のテレメトリフィードバックです。この新しいデバイスに関するデータを頻繁に送信しているようでした。他のブラウザではなかったことです。実際、この40分の調査中に、4回以上incoming.telemetry.mozilla.orgに通信していました。なお、テレメトリの呼び出しはFirefoxによるプロセスだけでなく、Mozilla の pingsender プロセスによっても実施されます。

Firefoxの調査の詳細は、Twitterでご覧いただけます。

Operaの結果​Opera Results

Opera は、20 を超えるホストに対して 51リクエストを行いました。本稿作成時にもう一回Operaの調査を行い、Twitterに載せた最初の調査から変化があったかどうかを確認しました。yandex.ruへの20近いリクエストの送信がなくなった点は改善でした。しかし、依然としてamazon.com、walmart.com、kayak.com、aliexpress.com、overstock.com、ebay.com、booking.comに送信しています。

上記の商業的なリクエスト以外に、android.clients.google.comへの呼び出しがありました。今回の調査はWindowsデバイス上で実施していたので、驚きでした。

Operaの調査の詳細は、Twitterでご覧いただけます。

Safariの結果​Safari Results

Safariは比較的リクエスト数が多かったブラウザです。16 のホストに対して 37 のリクエストがされました。

新しいプロファイルでSafari を初回起動すると、主要な Web サイトのサムネイル （ファビコン） を獲得するリクエストが発行されます。まず、apple.com、bing.com、yahoo.com、wikipedia.orgなどとの接続を確認し始めます。facebook.com、linkedin.com、twitter.comなどのSNSにも接続します。yelp.comとtripadvisor.comに対してもリクエストが送信されます。

Safari は、独特の方法でアイコンやサムネイルを検索します。まず、各サイトのランディング ページをリクエストします。これで、かなりの量のデータがダウンロードされます。ページのHTML の取得が終了すると、Apple 固有のディレクティブタグを探します。見つからない場合は、あきらめて個別のファイル名をリクエストし始めます。

Safariが探す最初のファイルは、apple-touch-icon-precomposed.png.です。たいてい、どのドメインにもこのファイルがないので、リクエストは成功しません。次にSafari は、各ドメインのapple-touch-icon.png にアクセスしようとします。これもまた、ほとんど成功しません。

なお、全てのリクエストでCookieが保存される可能性があり、実際、時々保存されます。しかし、Safari ではこういったリクエストに特別なセッションを使用しており、あとから全ての Cookieを削除していると理解しています。

Safariの調査の詳細は、Twitterでご覧いただけます。

Vivaldiの結果

最後にご紹介するのは、たまたま私がTwitterで最初に報告したブラウザです。Vivaldiは、初回起動時に13のホストに42のリクエストをしました。私が最初に調査した時は31リクエストだったのでリクエスト数は増えています。42 のリクエストの多くは、vivaldi.comにされ、最新のビルドで追加された新機能を確認するリソースの読み込みです。Vivaldiはその後、Googleドメインから多数のリソース（SafeBrowsingリストや拡張機能など）をダウンロードします。この後は、もはや皆さんにもなじみ深い、他のChromiumベースのブラウザに非常に近いリクエストが続きます。

Vivaldiの調査の詳細は、Twitterでご覧いただけます。

Braveの特徴

調査を始めたとき、どのような結果になるかは完全には理解していませんでした。Braveには大きな期待をしていて、実際期待通りでした。ただ、他の主要ブラウザがユーザー体験をどれほどしっかり管理しているかが不明でした。Braveが、リクエスト送信先を100%Braveの公式プロパティにしていることは、大変素晴らしいことだと思います。一方で、Braveがしているような送信先の管理が、他のブラウザではほとんどされていないことには驚きました。プライバシーを重視し安全な標準設定をしている、ということを謳っている有名なブラウザでさえ、驚くほど多くの呼び出しをサードパーティのホストにしていたのです。

調査の実施方法

この調査の結果をシェアしたところ、多くのユーザーから、どのようなツールをつかったのか、どうやれば自分で同様の調査を行うことができるのか、といった問い合わせを受けました。この調査には必要なセットアップはほとんどありません。Windowsユーザーは、Telerik Fiddlerを使えばネットワークアクティビティなどをモニターできます。macOS ユーザーは、 Charles Proxyをご確認ください（なお、Fiddler は macOSのMonoでも使用できるという話もあります）。なお、注意点を少し。Fiddlerをダウンロードする前に個人情報の入力が必要です。Charles Proxyを登録しないで使う場合は、1回30分までになります。FiddlerとCharlesに関するチュートリアルやガイドはネット上にたくさんありますが、もし手助けが必要でしたら、いつでもTwitterの@BraveSampsonあてにご連絡ください。喜んでお力になります。