WebPackagingの「検証済みバイナリ」の応用に期待するもの。主にゲームクライアントの作成経験者としての意見です。
- 改造クライアント / DevTools からの副作用を止めたい
- 検証に違反していたら fetch / ストレージへのアクセスさせたくない
- 署名されたアセット以外(js の XHR, css の import, html の img.src など)からの fetch を止めたい
- そもそも DevTools 開いたらその時点からの fetch を信用したくない
- IndexedDb などへの副作用も検知したい
- 要は署名されたJSに署名外/署名違反からの副作用が入り込んでいないか検知したい
- なんらかの設定でブラウザ拡張の実行も止めたい
- 事前条件を破壊されるので
クライアントコードは安易に解析されるという前提で、JSはいろんなものがダイナミック過ぎ、挙動が上書きされる経路が多すぎて、「基本的に信頼しない」以外の選択肢がなかった。 たとえばクッキークリッカーは内部ステートを localStorage で持ってて、簡単に書き換えることができてしまう。 署名済みのバイナリという前提によって、コントロールできるのではないか。
DevTools がどうとか言いだしたら別の仕様にすべきだとは思うが…
kyo_agoさんにこの話を昔したのだが、「それは民主的なWebではない」という旨の意見をもらった記憶がある。 現時点の解決策として、 WebAssembly のLLVMの最適化による複雑さによって攻撃者を諦めさせる、という手もある。 が、例えば有料アプリであるような、シリアルキーの検証をすっ飛ばす、ぐらいのコードなら可能、という話もある。