査読者 1
総合点
8
確信度
3
コメント
イベントドリブンなアプリケーション開発において、時刻に関するイベントリスナを容易に書けるようなDomain-Specific Languageおよびそれを実現するフレームワークの提案である。既存の字幕用テキストフォーマットを拡張してプログラミング言語を埋め込み可能にしており、自然なアプローチだと思う。
プロトタイプ的とはいえ実デバイスの操作を含む多くの魅力的なアプリケーションが示されており、ロング採択してよいと考える。
2章の関連研究では、ニコニコ動画のニコスクリプト[a]やYouTubeの指定時刻にメッセージやボタンを追加できる「アノテーション」「カード」[b]に触れるべきである。それぞれ限定されたインタラクションしか可能にしないものではあるが、先行事例として参考になる。
[a] http://info.nicovideo.jp/help/player/script/list.html
[b] https://support.google.com/youtube/answer/6140493
細かいが、2ページ目の「flashのもつ1および2の問題」「また,3については」は 「Adobe Flash」と正式名称で紹介し、数字を半角にしたほうがよいと思う。
「Javascript」となっているところが何か所かあるが、「JavaScript」である。
3章でsrt.jsファイルと書いてあるが、「.js」を見ると反射的にJavaScriptのソースコードだと思われるので、「.srtjs」のような独自の拡張子にしたほうがよいだろう。
5章の議論で任意のJavaScriptコードを実行可能であることが脆弱性と捉えられているが、これはJavaScriptの実行環境に大きく依存する問題であり、それ自体がすぐに脆弱性になるわけではない。例えば権限やネットワークアクセスの制限されたVM上でブラウザを動かし、そこで任意のコードが実行可能となっていたとしても脆弱性とは呼べない。JavaScriptインタプリタを自作した場合も同様である。
evel()については寡聞にして知らない。Google検索してもすぐには出てこないようなので、参考文献に挙げてほしかった。
採録判定時のコメント
「時刻Xになったら処理Yを実行する」という、時系列メディアの再生時刻をトリガにしたイベントドリブンなアプリケーション開発を容易にする提案です。字幕用テキストフォーマットの拡張によるJavaScript記述方式、QRコードを用いたデバイス認証を含むサーバ・クライアント型実行環境に加え、ユースケースシナリオ等が評価され、ロング採録となりました。一方で、ターゲットユーザが不明確なことや、セキュリティ面での議論が表層的である点などに改善の余地があります。
レビューサマリ
全体の構成:
時刻に関するイベントリスナを容易に書けるようなDomain-Specific Languageおよびそれを実現するフレームワークの提案である。既存の字幕用テキストフォーマットを拡張してプログラミング言語を埋め込み可能とした。さらに、そのための実行環境を実装し、さまざまなユースケースシナリオを示した。
評価すべき点:
着眼点、ユースケースシナリオが面白く、説得的である。プロトタイプレベルとはいえ、QRコードを利用した認証や実デバイスを操作するためのシステム構成などよく練られている。
改良に向けたコメント等:
1) ターゲットユーザがはっきり示されていない
誰がsrt.jsを使ったコンテンツを制作できるのかがはっきり書かれていない。関連研究の章で「エンドユーザ・プログラマが気軽に開発できるフレームワーク」と書かれているが、エンドユーザの定義があいまいである。
JavaScriptのプログラミングさえできれば、srt.js形式を学ぶのは難しくはなさそうだが、それだけでよいのか? 4章のユースケースシナリオは、JavaScript初心者の映像作家でも作れるものなのか? そうでないなら、どう設計してどう構築するのか? 支援の方法はあるのか? このような議論が深まっていれば、同様のシステムを構築する際の参考になるだろう。
2) セキュリティに関する議論が表層的である
eval()が危険であるからevel()を使う、と書いてあるが、そもそもなぜ危険なのかを示すべきである。それによってはじめて、どう回避できるのかが議論できる。
なお、査読者からは、JavaScriptのインタプリタをサンドボックスに入れる、JavaScriptではない簡易スクリプト言語を利用する、といった回避策が指摘されている。
その他コメント
査読者 2
総合点
6
確信度
2
コメント
システムそのものの有用性は、とても理解できた。
ただし、このシステムを誰が使うのかが、いまいちはっきりしなかった。
関連研究の
「我々はこのような映像連 動コンテンツをエンドユーザ・プログラマが
気軽に開発できるフレームワークを提供する.」
と書いてあるが、映像作家がこのフレームワークを使うメリットが、詰め切れてないと考える。
特に、
4.1 ユーザの入力に基づく映像の再生制御
の例が挙げられているが、この例をコンテンツ作成者が、どう設計して、とう構築するかが
記述され、その部分の評価が明らかではないと、srt.jsの意義が明らかにならないと考える。
査読者 3
総合点
7
確信度
2
コメント
字幕ファイルに着目した点は、Youtube等の一般的な動画投稿プラットフォームで使えかつ容易に配布するという面で有用性がある。
しかし、実装面では、eval()を使ったスクリプトの実行は本質的に危険である。evel()による対策も触れられているが、その場合制約が大きく、提案されている例の多くは動かないと考えられる(仮に動作するのであればevelを前提とした提案にすべきである)。
自由度は下がるが、JavaScriptをそのまま記述するのではなく、機能を制限した(たとえば、アクセスできるプロパティを制限する、信頼されたサーバとの通信のみとする、など)簡易スクリプト言語を用意するという選択肢もあるのではないかと思われる。