mozaic.fm v3 リリースと Podcast の PWA 化

Periodic Background Sync(PBS)

Podcast アプリの実態は、音声が再生できる RSS リーダーであり、定期的にフィードを取得し Podcast の更新を取得する。

Service Worker は background sync が従来からあるが、これは「オフライン中に発生したリクエストを、オンライン復帰時に再送する」といったユースケースをカバーしている。

サーバ側でフィードを更新したときに Push を送る方法もあるが、Push は届くとは限らない上に、Permission の問題もある。

そこで、Silent Push を待っていたのだが、先に Periodic Background Sync(PBS) が提案された。

• Periodic Background Sync 及び Web を Install するということ | blog.jxck.io

PBS の発火タイミングで Feed を取得し、更新があればメディアをダウンロードしておくように実装した。

before install prompt

PBS のために、性能をフルに発揮するにはインストールが必要になった。

これを、自動で出てくるインストールバナーにまかせては、ユーザに対して体験が良くない。

そこで、内容を理解した上で Opt-In でインストールできるような UI を用意し、クリックすると Install Prompt が出るように実装した。

Background Fetch

Service Worker の Cache は Cache API で行うのが基本だ。

しかし、mozaic.fm の音声ファイルはサイズも大きいため、Service Worker の Install 中に全て入れておくのは適切ではない。

また、音声は Range リクエストであるため、再生中に裏でキャッシュするのも適さない。

そこで提案されたのが Background Fetch であり、ユーザの操作とは非同期に裏でダウンロードが可能な API だ。

ユーザが明示的に Download を指定し、アプリをバックグラウンドに回してもキャッシュに入るようにした。

• Service Worker の Background Fetch によるメディアのキャッシュ | blog.jxck.io

本当は Periodic Background Sync で Background Fetch を実行する方向で考えていたが、今の Android Chrome では、それをしてもタスクが登録されるだけでダウンロードが実行されない。

ユーザが明示的にタスクを許可しないといけないため、ここは普通に Fetch して Cache に入れるようにした。

PBS + Bgfetch が鉄板の組み合わせだと思っていたので、ここは意外だった。詳細は詰めきれていないが理由などをもう少し調査しておきたい。

なお、Bgfetch は cors が必要だが、<audio> のリクエストが no-cors なこと、そして SW を経由したときに Cross-Origin-Resource-Policy の設定を求められたあたりがハマった。

Badging API

バックグラウンドで更新されたなら、更新を知らせる UI が必要となり、アプリの場合はバッジが代表格だろう。

これも Badging API として提案されているため、導入した。

具体的には PBS で更新があったときだけ、無印のバッジを表示し、DOMContentLoaded でクリアしている。

Content Indexing API

Badge のみでなく、更新されたコンテンツの概要をユーザに伝える UI があることが望ましい。

そこでコンテンツの概要を登録し、ユーザに更新を伝えるために提案されたのが Content Indexing API だ。

現状 Android Chrome の実装では Download タブの中という、およそ誰も見なさそうな場所でしか表示されない。

そして Install した PWA では、Download タブは現状見れないため、あまり意味がない。

しかし、これは標準化が進みユースケースが整理されれば、UI が改善されより意味のある場所に表示されるだろう。

先行して登録するようにしている。

Pure WebComponents

かつては生の <audio controls> を入れていたが、「早送り」「巻き戻し」「再生速度変更」など、自分が Podcast アプリに欲しいと思っていた UI が無いため独自実装した。

実装自体は <mozaic-player> という Custom Elements で実装し、template の内容を Shadow DOM に展開する完全に Pure な WebComponents にしている。

Audio の API も生で操作し、フレームワークなどは一切利用してない。

HTML Modules は実装されてないため、fetch で代用しているが、module は mjs を import している。

Player ではないが、Bgfetch を行うためのダウンロードアイコンも、アイコン自体に Download 機能をもたせた WebComponents にしている。

これまでは Template をレンダリングした静的ページだったが、今後もこのように UI に機能を統合した WebComponents 群の組み合わせによる実装に移行していきたい。

WAI-ARIA

Player のアプリとしての UI が、一般の HTML で実装されている部分については、不足するセマンティクスを WAI-ARIA で補っている。

ARIA 以前に、そもそもの audio の seek bar の role が progressbar か slider かを一番悩んだ。

progressbar は進捗を表すが、本来値は readonly で D&D で seek できる UI に利用するのは妥当ではないように思う。

slider としては <input type=range> があり、D&D やネイティブのショートカットなども使える、しかしリアルタイムに value の変わる input はどうなのだろうかという疑問も残る。

他の実装を参考にすると、<progress> を使っているところや、<div role=slider> で行っている実装が見つかったが、多くは <div> で実装しているようだ。<input> な実装はなかった。

折衷案として <progress role=slider> という実装に落ち着けて実装し終えたが、後から <progress> の role は仕様上変えられないことに気づいたため修正が必要な状態だ。

せっかくなので検証として <input type=range> で実装を試してみてから、だめなら最後は <div role=slider> に落ち着かせようかと考えている。

他にも、まだ UI の設計や付随するアノテーションも TODO があるため、継続して改善していきたい。

Media Session API

音声の再生をバックグラウンドにした場合、ロック画面などから共通の UI で操作ができるだろう。

Web の場合も、Media Session API を利用すると、再生や早送り巻き戻しなどを OS の UI から操作できる。

自前で実装した Player の API を繋ぎこみ OS からも操作できるようにしている。

Wake Lock API

Media Session とは逆に、ロックがかからないようにする API が Wake Lock API だ。

動画があるわけではないため、ロックしたいモチベーションは音声にはあまりなさそうだが、一応再生時は Lock するようにした。

とはいえ、ロックされても音声が止まるわけではなく、Media Session でも操作できるため、あまりいらない気はしている。

邪魔だったら消すつもりだ。

Portal Preview

エピソードごとに付与している Show Note には、Podcast 内で言及した URL が多く載っている。

あまりに多いため、マウスオーバーによる Preview を Portal により実装している。

実は Portal が出てすぐに入れた機能で、完全に忘れていたが今回の修正でみつかったものだ。

UI が、特にモバイル対応周りが詰めきれてないが、Portal もまだまだ過渡期なので、そのうちまた修正する。

機能としては別になくてもいいため、Portal がデフォルトになってきたら、無効化する UI を入れるか、消す。

CSP v3

Origin ベースの CSP をやめ、nonce と integrity ベースの CSP v3 に移行することにした。

本来 nonce は毎回違う値が必要だが、これを実現するには静的な配信をやめてサーバ側で毎回生成する必要がある。

しかし、アプリサーバをあまり持ちたくなかったため、integrity ベースだけにしようと考えた。

ところが、integrity ベースだと CSP のレポート収集を検証する点であまりうれしくない。

そこで、CSPv3 のアンチパターンである固定 nonce でとりあえず導入することにした、値は integrity と同じである。

このサイト自体が CSP で防御するほど機能がないため、特に問題はないが、もし本番環境で導入する際は、必ず nonce を毎回ランダムに生成するようにするべきだ。

Report については、User Script や拡張などもあるかもしれないが、Report-Only もそろそろ飽きたので外すことにした。

何かあれば実際にブロックするため、レポートもより慎重に見ていきたい。

Trusted Types

これも CSP の機能であり、特定の DOM API の操作を型によって保護する仕組みである。

• 安全な文字列であると型で検証する Trusted Types について | blog.jxck.io

サイトの中では、保護に該当する DOM API を使ってないが、これを入れることで XSS による DOM の改変を防ぐことが可能になる。

ヘッダから有効にしている。

Cross Origin * Policy

Site Isolation を固めることで、サイトをより強固に Origin に閉じるための提案が最近色々となされている。

• Cross-Origin Resource Policy
• Cross-Origin Embedder Policy
• Cross-Origin Opener Policy

これら全てを有効にしている。

加えて CSP/Trusted Types を有効にした環境を Securer Context と定義し、そこではさらに強力な機能を有効にできるのではないかという提案がなされている。

• mikewest/securer-contexts

全て行っておくことで、今後より高い権限が必要になる強力な機能が入っても、有効にしていける土台になるだろう。

Referrer Policy

Referrer Policy は no-referrer-when-downgrade が default とされており、Cross Origin でも URL 全体が送られる。

本来 Show Note から参照している外部のページには、Referer を送っても良いため、この値でも問題はない。

しかし、認証を行いパーソナライズされたページなどでは、サイトの外に URL が漏れることを防ぐために、strict-origin-when-cross-origin がより理想とされている。

そこで、本サイトもパーソナライズは一切してないが、strict-origin-when-cross-origin に変更してみることにした。

• Referrer-Policy によるリファラ制御 | blog.jxck.io

Scroll To Text Fragment Search

blog にも入れた機能だが、よりインタラクティブな Form で実装した。

• Scroll to Text Fragment を用いたサイト内検索の実装 | blog.jxck.io

transpile less

近年の Web 開発につきものなコードのトランスパイルを一切行っていない。

ビルドは gz/br の生成ので、WebPack や Babal のような変換が無く SSR もない。

型の整合性チェックはテストと位置づけているため、TypeScript ではなく Pure JS だが、JSDoc に型を書きテストで tsc を叩いてる。

Dev Server も不要でリロードすれば反映され、package.json, babelrc, webpack.config といったファイルのメンテという不毛なタスクが無いのは、開発体験が良い。

Spotify

Spotify も Podcast のサポートを始めたため、登録した。

• mozaic.fm | Spotify でポッドキャスト

Template Instantiation

もう少し作業が進むかと思ったが、ちょっと停滞気味なので様子見。

HTML Modules

話が進んだので入れられるかと思ったら、Security Issue で止まってしまったのでペンディング。

Document Policy

入れたいものもあるが、実装がまだ無いっぽいのでペンディング。

Silent Push

ただし条件は厳しいが、User Visible ではない Push が使える場面があるように思う。

ブラウザ依存かつ、Unstable と思われるため調査が面倒で実施しなかった。

今後 Permission が Install に依存するようになると、ある程度現実味が出てきそうだ。

Periodic Sync よりもリアルタイムな feed 更新に使えるかもしれないため、今後もう少し調査したい。

WASM ID3

mp3 には ID3 というメタデータを付与でき、その情報を WASM で取得し表示するようにしようと計画していた。

Rust で ID3 のパース自体は目処がたっていたのだが、そもそも <audio> から生のバイナリを取得する方法が無いことに気づいた。

もしそれをやりたければ、先に自分で fetch してそれを <audio> に食わせる必要がある。

しかし、お作法として fetch 自体は <audio> に任せるべきだろうと考える。

なのでこれを実現するためには、<audio> が取得したバイナリを取得する API を標準化するとこからやないといけない。

ところが、<audio> は Range なので取得と定義すのも難しい onmetadataloaded でも良さそうだが、それだけでは済まない。

ということで諦めた。

SXG

HTML + JS + MP3 で固めた WebPackaging をやろうと考えていたが、SXG Extension に対応した証明書が一箇所しか提供して無く地味に高い。

そのうち Let's Encrypt が提供してくれることを期待して保留している。