Web Packaging - Use cases and Loading

1. WebPackaging: Use Cases and Loading #webpackaging_study Feb 23, 2018 Kinuko Yasuda kinuko@chromium.org / @kinu

2. 自己紹介 ● kinuko@chromium.org (@kinu) ● Chrome engineer 割と長くやってます ● Service Worker などを作った (うちの一人) ● Web Packaging 歴： ○ 横目で見てる歴 1年＋α ○ 真面目に関わりだして3 ヶ月くらい

3. Disclaimer ● 資料的価値のありそうなスペックに関する解説は@flano_yuki さんのすばらしいスライドでカバーされてますのでそちらをご覧ください。 ● 内容に私個人の解釈を含みます。私の所属する団体や企業などのいかなる意見をも代表するものではありません ● 仕様も実装もこの先いろいろ変更が予想されています

4. 話すつもりの内容 ● ユースケース (とスペック) ● Loading とブラウザ実装 ● 雑談

5. “Packaging the Web” Use cases（と少しだけスペック）

6. “Packaging the Web” -- 遠くから眺める (1) ● 大まかかつ割と普遍的なMotivation ○ Web page をパッケージして保存したり渡したりできるといいよね ○ オフラインでも使えるといいね ○ CNAME 登録とかなくても速いキャッシュからサーブできるといいね ○ Web Publication にも使える？ ○ 複数のリソースを bundle してロードするのにも使えるといい？ ○ (その他もろもろのうずまく希望)

7. “Packaging the Web” -- 遠くから眺める (2) ● ふわっとした需要（希望）がいろいろあるようだ。 ● ということはもちろん既存手法もいくつかある。MHTML とか！ ● しかし過去の手法はいろいろ制限や問題があるようだ？ ● 新しい Packaging の仕様が求められている？

8. “Packaging the Web” -- 近寄ってみる ● Use cases とそれぞれに必要なRequirements を詳しく見てみる ● https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html

9. Use case (1) Offline installation A さんは Service Worker を含む PWA サイトをオリジン O からダウンロードしてB さんに送りたい。受け取った B さんはそれがオリジンO から来てるという証明とともにそれを安心してインストールできる。ギガは減らない！ Signed by origin “O” Install a PWA from origin “O” Origin “O”’s PWA installed from URL bar shows origin “O”

10. ● リソースは URL で識別されてなければならない。 ● Accept* ヘッダなどを含む Request headers がないと違う環境に対応できない。 ● リソースを正しく扱うためにResponse headers もやっぱり必要。 ● それがオリジン O から来たとわかるようにO としての署名がいる。 ● (署名は既存の TLS certificates を使いたい…けど変わるかも) ● 複数オリジンからのリソースをパッケージに入れたい。 ● リソースに関するメタデータもたぶん必要。 ● 証明は revoke できるべき。新しい暗号化方式や各種アタックへの対応も必要。 ● 完全オフラインを考えるならパッケージの正当性をオフラインでも検証したい。 Use case (1) Offline installation: requirements

11. Use case (2) Offline browsing A さんは大きな Web サイトをオリジン O からダウンロードしてSDカードなどに保存し、B さんに渡す。受け取った B さんはそれがオリジンO から来てるという証明とともにそれを安心してオフラインでも安心してサイトをブラウズしたい。 Signed by origin “O” Browse “O”’s site fromBrowse Origin “O”’s Web site URL bar shows origin “O”

12. すべての Offline installation に必要な要求に加えて、 ● リニアスキャンしなくても必要なリソースに高速にランダムアクセスしたい。 ● 大きな空き容量がなくてもいいようにパッケージの内容を圧縮して扱いたい。 Use case (2) Offline browsing: Requirements

13. C さんはあるページをセーブしてあとで見るか友達D さんに見せるためにとっておきたい。 D さんは違うブラウザを使っていて保存形式に互換性がないし、見ていたページのprivate key も持っていない。 Use case (3) Save and share a Web page NOT signed The page fromSave a page from Origin “O” ? URL bar does NOT show origin “O”

14. ● 署名されていないパッケージとして保存でき、かつクライアントが署名されていない（信頼できない）パッケージとしてブラウズできる必要がある。 Use case (3) Save and share a Web page: Requirements

15. Why new format? - なんで新しいフォーマット？既存のフォーマットは概ね互換性がなかったり制限があったりする ● MHTML: ○ Request headers を含めるには拡張が必要(Accept-* などの情報が落ちる) ○ 複数 page を bundle できない ○ origin 署名の仕組みがない ○ Bundle 内のリソースに高速にアクセスするためのindex がない ● Zip: ○ Request headers を含めるには拡張が必要(Accept-* などの情報が落ちる) ○ Response headers を含めるには JAR の META-INF のような拡張がいる ○ origin 署名のためには JAR の signature のような拡張がいる

16. More sketchy / interesting use cases? ● オフライン、共有などはわかりやすいけど、シナリオが限定的。 ● 普通のブラウザ体験をよりよくするために通常のページローディングの一部として取り入れる使い方はあるか？ ● いろいろアイディアはある…？（みなさんの意見も聞きたいです）

17. Pre-warm cache using . Subsequent navigation will be instant. Use case (5) Faster Contents (Re-)Distribution, with Prefetching 速いキャッシュなどを持つContent Distributors が他のオリジンのコンテンツをより速く読めるように re-publish したい。そのページを出すのに必要なリソースもまとめて(元のオリジンにいかなくても) Prefetch できるとより良い。 Signed by origin “O” Served from fast cache Prefetch URL bar shows origin “O”

18. Use case (6) Subresource bundling 複数リソースの bundle は圧縮率が良くなったりローディングが効率よくなったりとよいこともある。一方で、JS や CSS を 1 つの JS にまとめる手法は欠点もある： ● リソースを使うにはまず全部script をダウンロードして実行しないとダメ ● 中にあるリソースが１つでも変更されたら全部再ダウンロードがいる ● それぞれが独立して依存性を記述できるModules のセマンティクスが損なわれるブラウザが中にあるリソースについて知ることができればより正しいことができる？ Cache-digest などと組み合わせる? でもそれに本当に WebPackaging いる？ Manifest 部分だけあれば実はよい？

19. Use case (7) Your ideas?

20. スペックの話 (少しだけ) 昔は Bundled resource の話がメインでフォーマットとしては1 つのスペックだった → IETF 99 の DISPATCH WG で２つに分けることが推奨されて分割 ● Signed-exchange → 署名された HTTP request/response の組 ● Bundled-exchange → Signed exchage を bundle したものしかしまだまだ動きがありそう…。

21. Web Packaging Loading （とブラウザの実装の話）

22. Web Packaging Loading 2 つの方法が提示されている： ● HTTP/2 Cross-origin Push ● application/http-exchange+cbor for HTTP/1 Compatibility

23. HTTP/2 Cross-Origin Push Client a.com b.com b.com/foo “sign” b.com/foo ENABLE_CROSS_ ORIGIN_PUSH PUSH!

24. application/http-exchange+cbor Client a.com b.com b.com/foo “sign” GET “a.com/b-com-foo.htxg” b.com/foo a.com/b-com-foo.htxg (CBOR envelope) b.com/foo ● Client and extract and verify the b-com-foo.htxg ● Once verified, treat it as coming from b.com

25. Chrome での実際状況 ● もともとは 12 月に東京チームでデモを作った(でもスペックは当時は違った) ● 1月から新しいスペックで本実装開始 ● とりあえず application/http-exchange+cbor のみを実装 ● Payload body は MI integrity のみをサポート ● 一緒に prefetch なども対応できるよう実装中

26. 現在の実装で想定している使い方 ● Embedder page <link rel=prefetch href=”b-com-foo.htxg”> <a href=”b-com-foo.htxg”>Foo</a> ● ブラウザの挙動 ○ “foo.htxg” を prefetch して verification などをする ○ Foo がクリックされたら b.com/foo.html としてナビゲート