For #webpackaging_study Feb 23, 2018 https://web-study.connpass.com/event/78978/

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 としてナビゲート