新春特別企画

2020年のWeb標準

あけましておめでとうございます、@1000chこと泉水翔吾です。2019年に続いて、2020年のWeb標準技術について寄稿します。今年は、Webコンテンツの配信の形を拡張するWeb PackagingとWebにおける認証の形を変えるWeb Authenticationについて取り上げます。

Web Packagingを使った新たなコンテンツ配信の形

現在Web Packagingという仕様の策定が進んでいます。Web Packagingは、Webのコンテンツの可搬性を高める技術仕様で、コンテンツを配布元が署名して改ざんされていないことを保証したり、複数のリソースを一つにまとめたりすることを実現します。Web Packagingは以下の3つに分類されます。

  • Signed HTTP Exchanges:単一のHTTPリクエストとレスポンスに対して署名する
  • Web Bundles(旧Bundled HTTP Exchanges⁠⁠:複数のHTTPリクエストとレスポンスをまとめる
  • Loading Signed Exchanges:署名されたHTTP Exchangesをロードする

これらのうちLoading Signed Exchangesは、Signed HTTP ExchangesやWeb Bundlesによって署名されてまとめられたコンテンツを、どのようにロードするのかを決める仕様であり、基本的にブラウザの挙動に関わる部分です。この記事では、Web PackagingのユースケースやWeb開発者が関わってくるSigned HTTP ExchangesとWeb Bundlesについて説明していきます。

Signed HTTP Exchanges が解決してくれること

皆さんがWebページを閲覧している時に、HTTPリクエストとレスポンス(すなわちHTTP Exchanges)が繰り返し行われていることは想像できると思います。このHTTPリクエストとレスポンスに対して署名した(Signed)結果が、Signed HTTP Exchanges(SXG)です。この署名において、配布元となるドメインの秘密鍵を用いることで、SXGを再配布した時にその中身が改ざんされていないことを保証できます。また、SXGにはHTTPリクエストとレスポンスの情報が含まれるため、配信されるURLに関わらず、このURLからの配信されたという論理的な情報を持ちます。

例として、この記事をSXGにすることを考えてみましょう。この記事に対するHTTPリクエストおよびレスポンスを、gihyo.jpが保有する秘密鍵を用いて署名した結果、2020-web-standards-prospect.sxgというファイルが生成されたとします。このSXGファイルは改ざんに対して耐性があり、gihyo.jpが作成したコンテンツということが保証されるため、ブラウザにアドレスバーに表示されるURLは、どのドメインから配信されてもhttps://gihyo.jp/design/column/newyear/2020/web-standards-prospectになります。

Signed HTTP Exchangesが活躍するシーンとしてイメージしやすいのはAMP(Accelerated Mobile Pages)です。AMPはページロードの高速化を目的とした技術で、AMP HTMLと呼ばれるHTMLのサブセットを定義してWebページを構築する技術に一定の成約を設けることで、ページロードの最適化をしやすくしています。また、Googleをはじめとした検索エンジンがWebページをクロールする際に、ページがAMP HTMLで構築されていると認識されると、Webページのリソースがキャッシュされます。これによって、検索結果から遷移する時にキャッシュされたリソースをロードするため、高速にWebページを表示できるようになっています。しかし、このAMPの仕組みには、キャッシュの保存先がそれぞれのキャッシュサーバー(ここではGoogleのCDNとします)であるため、URLがGoogleオリジンのURLになってしまうという欠点があります。Googleの検索結果からアクセスしたページのURLをシェアしようとした時に、URLがhttps://google.com/amp/s/…となっていた経験は、皆さんにもあることでしょう。

この問題を解決してくれるのがSigned HTTP Exchangesです。このキャッシュ対象になるリソースを.sxgにできれば、どのサーバーにキャッシュとして保存されて配信されても、ブラウザは論理的なオリジンのURLをアドレスバーに表示してくれます。

Signed HTTP Exchangesは新しい技術ですが、既に実際のプロダクトに導入され始めています。Yahoo! Japanでは、もともとAMP実装のコンテンツが用意されていたYahoo! トラベルをSXGに対応させることで、AMPによる高速なページロードを維持しつつ、前述のURLの課題を解消しています。

Web BundlesによるWebコンテンツのバンドル

Web Bundlesは複数のHTTPリクエストとレスポンスをまとめる仕様です。Signed HTTP Exchangesは単一のHTTPリクエストとレスポンスに対する署名であるため、Webページを構成するたくさんのリソースを考えると、それらをまとめた結果を署名したほうが効率的であるのは想像に難くありません。

このWebページをWeb Bundlesでまとめることを考えてみましょう。このWebページのHTMLはhttps://gihyo.jp/design/column/newyear/2020/web-standards-prospectへのレスポンスに含まれており、そのHTMLから参照するCSS・JavaScript・画像といったサブリソースがブラウザからリクエストされます。これらを表現するために必要なレスポンスヘッダ・ボディ・バイト長などの情報に加え、マジックナンバーを含めたCBOR(Concise Binary Object Representation)のバイナリフォーマットがWeb Bundlesの仕様として定義されています。ただ、まとめるためのツールは既にGo製のwebpackage/go/bundleやNode.js製のwbnとして提供されており、実際に使う場合にフォーマットそのものを気にするケースはそこまで多くないでしょう。理解しておくべきなのは、Webページをバンドルした結果どのように利用していけるかといったユースケースです。

生成されたWeb Bundlesのファイルに署名すれば、それに含まれるWebページのアセットすべてをSigned HTTP Exchangesと同じように論理的なオリジンを保った形で扱えます。これで、いかなる場所でホストされても署名元のコンテンツであることを保証された状態でWebページをパッケージ化できました。

パッケージ化されたWeb Bundlesの.wbnファイルは、そのファイルに含まれるHTTPリクエストとレスポンスでコンテンツネゴシエーションを行うため、ローカル環境でも動作します。そのため、一度ローカル環境にダウンロードしてしまえばネットワークを介さずに動作する他、リソースのロードが発生しないため高速に動作します。

また、ファイルとして扱えるのでBluetoothやUSBメモリなどを介して配布することも可能です。実際にChrome Dev Summit 2019では、このWeb Bundlesのデモンストレーションとして、PROXXSquooshweb.dev.wbnファイルが保存されたオフラインダイナソー[1]の形をしたUSBメモリが配られました。このようにWeb Packagingは既存技術が持つ課題を解消するだけでなく、Webページを配布・共有する新しい手段として進化し、Webページの持つ可能性を広げています。

Web Authenticationが実現するパスワード不要な認証

最近のデジタルデバイスには、指紋や顔といった人間の生体を検出するインターフェースを持ったものが数多く登場しています。iPhoneやPixelなどのモバイルデバイスには指紋認証や顔認証が利用されていますし、macOSでもTouch ID(Appleが開発する生体認証機能)を利用できるデバイスがあります。

しかし昨今のWebにおいて、我々が認証する時に使っているのはパスワードや秘密の質問といった、認証において本人性を検証できる要素のうち「知識」のみを要求するものがほとんどです。最近では、アカウント情報に登録されている電話番号やメールアドレスにワンタイムトークンを送信して安全性を高める手法も増えてきました。しかし、パスワードやワンタイムトークンは流出してしまった時に第三者にも使えてしまうという弱点があります。パスワードについては、高性能のマシンによるパスワードクラッキング攻撃によって脆弱なものになりつつありますし、そもそもパスワードを保存しているシステムから流出してしまうリスクに対してユーザーは為す術がありません。またワンタイムトークンについては、精巧に作られたフィッシングサイトから抜き取られて悪用される、という事例も増えています。

Web Authenticationは、前述のような認証器をブラウザから使うためのJavaScriptのインターフェースです。認証器には、前述したようなデバイスに含まれる生体認証だけでなく、接続方法によって分類が違うなど様々な仕様があり、これらはFIDO (Fast IDentity Online) Allianceが標準化を進めているFIDO 2の一部として定義されています。認証器の中には生体認証機能を持たず多要素認証の2要素目として利用されるものもありますが、macOSのTouch IDのように生体認証に加えてユーザーの所有性も含んでいる認証器をWebで利用できれば、認証要素のうち「所有」「生体」を使って認証できることになります。これが実現することによって、パスワードを入力することなく指紋や顔などで認証が可能になり、大きな利便性をもたらしてくれます。

Web Authenticationについても、既に実際のプロダクトへの導入事例がいくつも存在します。GoogleやFacebookでも多要素認証のひとつとして採用されていますし、Yahoo! JAPANではサービスへのログイン機能にWeb Authenticationを導入することで、生体認証を使ったパスワードが不要なログイン体験を実現しています。

認証器については、iPhoneやPixel、MacBookのようにデバイスに生体認証のセンサーが同梱されているケースも多く、意識しないうちに普及が進んでいます。また、ビジネスシーンにおいてもセキュリティ強化の動きに伴い企業としてセキュリティキーを導入する事例も聞くようになりました。Googleでは社員全員にセキュリティキーを配布し、各種ログインにセキュリティキーの使用を義務付けることでフィッシング被害をゼロにしたそうです。みなさんも、認証の選択肢としてWeb Authenticationを検討して、より安全で便利なWebの未来を模索してみてはいかがでしょうか。

関連記事

おすすめ記事

記事・ニュース一覧