ぼちぼち日記

おそらくプロトコルネタを書いていることが多いんじゃないかと思います。

なぜChromeはURLを殺そうとするのか？ (Chrome Dev Summit 2019)

Chrome Security

今年もChrome開発者の集まりChrome Dev Summit 2019 (CDS) がサンフランシスコで開催されました。 今回、私が Chrome Customer Advisory Board (CAB) に選出していただいたこともあり、CDSに初めて参加しました。

これは、CDS終了後のCAB meetingで頂いたChrome Dinosaurフィギュアです。ちなみにゲームはできません。 f:id:jovi0608:20191117195129j:plain タイトルの「なぜChromeはURLを殺そうとするのか？」は、2日目Chrome Leadsのパネルセッションで司会のGooglerが、Chrome UX担当のProduct Managerに対して一番最初に投げかけた問いです。

PMは直ちに「そんなことはしない」と即答しました。しかしChromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削除、といったセキュリティに関連するUI変更を立て続けに行ってきています。

Googleは、URLをどう考えていて、ChromeのUIを将来どうしていくのか？

その方向性は１日目のセッション「Protecting users on a thriving web (繁栄しているウェブの上でユーザを守る)」で話されています。


Protecting users on a thriving web (Chrome Dev Summit 2019)

世界的にHTTPS Everywhereが普及し、HTTPS化されたフィッシングサイトも増大している中、今後のChromeブラウザにおけるURL表示に対する考え方は、従来と大きく変わることになりそうです。 今回そのセッションの内容について紹介したいと思います。

このセッションは、2つに別れています。前半は、Chromeのセキュリテイ担当エンジニア Emily Stark さんによるChromeのURL表示に関するセッションです。以下は、おおよその講演内容を文字に起こしたものです。

1. あなたはウェブのどこにいるのか？ サイトのアイデンティティをわかりやすくする。

ウェブブラウザの上部に表示されるURLは、ウェブサイトのアイデンティティに対する曖昧な手がかりでしかありません。

ドメイン名からサイトのアイデンティティを特定することは、簡単なことではありません。セキュリティ専門家でも見分けがつかないこともあるし、非技術者のユーザとってなおさら無理な話です。

このことは憶測に基づくものではなく、多くの実験や調査で示されています。セキュリティに対してちゃんとした決定をしなければならない時に、多くのユーザはURLに気づかなかったり、URLを理解できていないのです。

Googleは、1000人以上を対象とした調査を行いました。対象ユーザにGoogleのログインページにみえるブラウザウィンドウを見せると、アドレスが明確に tinyurl.com になっていても、85%の人がそのウェブサイトをGoogleだと言うことがわかりました。 f:id:jovi0608:20191119050458p:plain これは本当に非常に難しい問題です。

多くの人々は、本当に便利なものとしてURLを利用しています。しかし、URLが人々を騙したり、害を及ぼすことに使われたりすることもよくあります。

そのためGoogleは、いくつかの方向からこの問題にアプローチしています。それは、

  • URLを悪用する巧妙なスプーフィング技術に対して、積極的に対策をします。
  • セキュリティを決定づける最も重要なURL情報に、人々の注意を向けるようにします。
  • 専門家をサポートする特別なツールを作っています。それをURLをより良くするセキュリテイツールとして役立たせます。

というアプローチです。 f:id:jovi0608:20191119050533p:plain

1.1. スプーフィング対策

IDNを使った spoofing は見分けがつかないです。example.comのaがキリル文字だったとしてもわかりません。 f:id:jovi0608:20191119050608p:plain Chrome75から「Look-alike Warning」という新しい警告を入れるようにしました。これはスプーフされたIDNを検知し、攻撃されていると思われる場合ユーザを正式なサイトに導くページを表示します。 f:id:jovi0608:20191119050639p:plain Chromeがナビゲーション中のドメインにIDNを見つけると、同じように見える文字種を一つにまとめるアルゴリズムを使い、ドメイン名をスケルトンに変換します。 そしてそれを有名なサイトや過去にユーザが訪れたサイトのスケルトンと比較します。もし合致すれば、ユーザを正しいサイトに導くよう、この警告を表示します。 f:id:jovi0608:20191119050711p:plain

1.2. セキュリティに関連したものを強調する

1.2.1. EV表示の廃止

Chrome77より、EV証明書の表示をPage Infoに移す変更をしました。これまでの調査・研究結果から、EV証明書が人々にサイトのアイデンティティを理解させるのに役立っていないことがわかったからです。

(以下省略: これについては直前のエントリー「Google Chrome EV表示の終焉」に詳しく書きましたので、そちらを参照してください。 )

1.2.2. OmniboxにおけるURL表示の簡略化

HTTPS以外では警告を出すようにしたため、Onmiboxで scheme (https://) を非表示にしました。

大多数の人にとって、wwwサブドメインの表示をしてもしなくても違いはありません。多くのユーザには、それは visual noise となるし、セキュリティに関連した部分をURLで見つけるのが難しくなります。ユーザに対しては、多くの情報を与えないようにします。

UIをより簡単にして、ユーザの注意をURLのセキュリティに関連した部分(ドメイン名)にフォーカスさせます。そのため、これらのURLコンポーネントを隠しました。これを「steady state Omnibox」と呼んでいます。 f:id:jovi0608:20191119050740p:plain

1.2.3. 将来的な変更について (鍵アイコンの削除など)

将来的には、もっとドメイン名に注意を引きつけるUI変更も考えています。

  • OmniboxでURLを編集しようとクリックするまでパスを隠すべきか？
  • ドメイン名を太字にしたり大きく見せて、もっと際立たせるべきか？
  • ユーザーが自分でドメインを検査することになった時に、パスをアニメーション化すべきか？

まだどれが良いのかわかっていません。

この考えに沿って、最終的にHTTPS接続を示す鍵アイコンも削除する予定です。

HTTPS接続を中立な状態として、デフォルトにします。そしてセキュリティがなくなった場合にのみ、警告を出すようにします。

鍵アイコンのような positive なインディケータは、かえってユーザを混乱させ、誤ったメッセージを送ることもあります。 (これはHTTPSのメンタルモデルを調査した論文を引用し、「鍵アイコンは、自分の認証が必要なことを指していると思っている」というユーザがいたことを指しています。） f:id:jovi0608:20191119050808p:plain 何も出なかったら安全なHTTPS接続である、と思ってもらえるようにしたいです。 Chromeは安全でなかったら、警告を出すようにします。

調査・準備にもっと時間が必要なので、鍵アイコンをいつ削除するのかは未定です。

1.3. 専門家向けのユーザケース

全員がURLを簡略化してほしいと望んでいません。ここへの最初の取り組みは、Suspicious Site Reporter というChrome拡張です。

この拡張を使うとOmniboxのURLが編集されず、常に完全に見えます。デフォルトで有効になっている非技術ユーザを助ける目的のURL簡略化を回避します。 f:id:jovi0608:20191119050844p:plain この拡張を使うと、悪意のあるサイトをGoogle Safe Browsing サービスに簡単に報告できます。Google Safe Browsingサービスは、 malicious活動をスキャンしているサービスです。

Safe Browsingサービスが、報告されたサイトがフィッシングやマルウェア配布・ソーシャルエンジニアリングなど、Googleポリシー違反をしていると判定すれば、全てのChromeユーザに対してそのサイトの訪問をブロックします。

2. ウェブはあなたの何を知るのか？ 反映するウェブエコシステムのためのプライバシー確保API

後半は、Michael Kleberさんによる最近のウェブプライバシー関連の状況とChromeの取り組みについてです。本エントリーの内容から少し外れてしまうので解説は省略しますが、１つ重要なことだけ挙げておきます。

2020年2月リリース予定の Chrome 80 から、クッキーのデフォルト挙動が変わります。3rd party cookieは、今のままでは動作しなくなる可能性があります。影響を受けそうなサイトは、Googleからのアナウンス「新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう」をよく読んで準備しましょう。 f:id:jovi0608:20191119051248p:plain

3. まとめ

以上セッションの内容から、Googleがスプーフィング対策・非技術者向けにURLの簡略化と効果的なUIの模索・専門家向けにURLを生で見せるChrome拡張の提供、の３つの柱でChromeのセキュリティ対策を進めているのがわかりました。

「これは実質的にURLを殺しにきているのではないか？」と言われれば、まぁそうなのかもしれません。

URL表示の簡略化は、Omniboxを使うとカーソルが微妙にずれてしまったりして個人的にも違和感があります。慣れの問題かなと半分諦めていました。今回 Suspicious Site Reporter を知って速攻で入れました。まぁホント快適です(フィッシングサイトの報告はまだしたことないです)。簡略URL表示に違和感のある方は、慣れる前に試してみることをお勧めします。これを使えば、今のところURLが殺されていない世界をGoogleから提供してもらえそうです。

ただHTTPS接続が当たり前となり、フィッシングが巧妙になり、非技術者ユーザが圧倒的多数を占める状況では、URLを確認しろ・証明書を確認しろ・リンクやサイトの記述に注意せよ、といった対応はそろそろ限界に来ているのかなとも思ったりします。

今回のセッションで紹介されたHTTPSメンタルモデルの論文「“If HTTPS Were Secure, I Wouldn’t Need 2FA”- End User and Administrator Mental Models of HTTPS」で報告されているユーザ調査には、少しショックを受けました。

“I think the lock symbol means that I have to authenticate myself. 
As I frequently forget my passwords, I usually try to click around to get rid of this symbol.”
「鍵アイコンは、自分の認証が必要なことを指していると思っている。
私はよくパスワードを忘れるので、この鍵アイコンを消すためにいつもいろんなところをクリックしてます。」
“HTTPS is a bad protocol. If HTTPS were secure, I wouldn’t need 2FA.”
「HTTPSは悪いプロトコルだ。もしHTTPSが安全なら私に2FAは必要ないだろう。」

まぁこういう状況なら、ChromeのURL表示が簡略化され、セキュリティアクション選択の多くがGoogleのお任せになるのも仕方ないかもしれません。

ところで、もらった Chrome Dinosaurフィギュアの箱を見てみると見慣れないURLが、 f:id:jovi0608:20191118015129j:plain 試してみると、 f:id:jovi0608:20191119050945p:plain おぉ、 ERR_INTERNET_DISCONNECTED (-106) だったのか！