要約

  • W3Cは2014年3月18日、取得したリソースを暗号学的ハッシュで確かめるSubresource Integrityの最初の公開草案を出した。当初検討した要素の範囲は、2016年の勧告に残った範囲より広かった。
  • 2016年6月23日のW3C勧告は、scriptとスタイルシートを指すlinkにintegrity属性を定めた。ブラウザーは照合できる応答のハッシュを計算し、期待値と違えば実行や表示を拒む。

配達員はいつもの住所を知っていた。ページも同じURLを指定している。けれども今日の荷物の中身は、昨日のものとは限らない。JavaScriptが変われば画面の振る舞いが変わり、スタイルシートが変われば読者の見る形が変わる。住所は取りに行く場所を告げる。指紋に当たるハッシュは、ページが受け取るつもりだった版を示す。

2014年3月18日に公表されたW3C最初の作業草案は、取得したファイルを暗号学的ハッシュで確かめる構想を示した。対象候補の一覧は幅広く、スクリプトやスタイルだけでなく画像やフレームにも触れていた。初期の作業台には道具がいくつも並んだ。完成した仕様では、扱う場所を絞って仕組みを整えていく。

2015年11月12日の候補勧告スナップショットでは、integrity属性の対象がscriptとスタイルシート用のlinkに集中した。2016年6月23日の勧告もその構成を採った。作者はHTMLでURLのそばに期待するハッシュを記す。ブラウザーはリソースを取得し、照合できる応答の内容からハッシュを計算して比べる。配達先の確認に加え、箱の中身の確認が始まった。

メタデータには使うハッシュ関数と期待値が入る。2016年の勧告は、ユーザーエージェントがSHA-256、SHA-384、SHA-512をサポートするよう定めた。同じリソースに複数の値を与える場合も想定し、サポートされる中で最も強い関数を優先する。外部のファイルがページで実行されたり見た目を変えたりする直前に、ページ自身が「この版を待っている」と言えるようになった。

検査には中身を読める応答が要る。同一オリジンの応答は対象になる。他のオリジンからの応答も、CORSによって読み取りが認められていれば照合できる。不透明な応答では比較に必要な内容が見えない。作者は期待値を書くとともに、ブラウザーが実物を検査できる配送方法も整える必要があった。

ハッシュが一致しないとき、2016年の勧告はブラウザーに実行や表示を拒むよう求め、ネットワークエラーとして扱う。エラーイベントを受け取れば、作者は手元に用意した既知のファイルなどへ切り替えられる。顔なじみの配達員でも、注文と違う箱ならいったん玄関で止まる。読者へのサービスをどう続けるかは、ページ側の設計だ。

W3Cの公開履歴には2014年の最初の草案、2015年の候補段階、2016年の勧告が並ぶ。2016年6月23日のW3C発表は、届いたリソースが予期しない改変を受けていないか確認する仕組みだと説明した。この道のりを見ると、初期案の広い候補からスクリプトとスタイルシートへの焦点の絞り込みも分かる。

運用にはもう一つ約束がある。作者が意図してファイルを更新するなら、期待するハッシュも一緒に更新する。古い値のままなら、正規の新版まで玄関で止められる。作者は招く版を決め、ブラウザーは実物を量る。URLが配達員を連れてくる。指紋は、その箱が注文したものかを答える。