worms

第二章: 開発-2

2-1: αテスト-1

　黒田（くろだ） 歩（あゆむ）自身が所属する研究室、修士まで所属していた研究室、大学の教員となった先輩の研究室、そしてそこからさらにいくつかのつてで、wormが稼働を始めていた。ブラウザから抜き出したJavascriptのサンドボックス、機能を制限し、また部分的に機能を拡張したJavascriptの実行系、そしてそのJavascriptによって記述されたwormの実行系が動いていた。wormの実行系は、FORTH 83-standardの実装を参考にした独自の言語だった。

　反応はすぐに寄せられた。現状、wormが発見した、ユーザの要求に合うページは、wormが存在するサーバから、wormが送るメールに頼っていた。これについて、セキュリティに関する疑問が寄せられていた。だが、それはまだ多く寄せられた反応ではなかった。メールであるということから、結局URLをコピペして使うことに対しての改善の要望がなにより多かった。加えて、wormの生存確認、あるいはむしろTTL、つまり生存期間に関する要望が多かった。

　wormのTTLについてであれば、それはwormのコードに記述し、サーバを移動するごとにTTLの値を減算すればよかった。wormの生存確認はTTLとセットにして考えるよりも、wormから送られるURLの記録方法とセットにして考えるほうがいいように思えた。

　wormが今どこに存在するかは、不明と考える。wormからの生存報告あるいはURLが送られることで生存が確認でき、どこに存在するか、あるいは直近でどこに存在していたかが判明する。メールに頼らない方法とするには、ともかくwormからの報告を受信するデーモンないしサーバを用意するのがいいように思えた。一定時間、その報告がなければ、放流したwormはロストしたとすることがいいように思えた。

　ロストしたと考えられる報告は、そのデーモンないしサーバが、ユーザにメールを送ることとすればいい。問題は、wormから報告されたURLをどのように記録するかだった。キーワードとURLの羅列では、結局コピペに頼るしかなく、問題の解決にはならなかった。他に取れる方法としては、その記録をtext/html形式で保存するもののように思えた。その形式であるなら、ブラウザでそのファイルを開けば、そのままリンクとしてジャンプできる。

　ただそれだけならば簡単ではあった。

「だけどなぁ。その方法にするなら、URLは整理された形で記録と保存をしたい」

　歩は机の上の研究ノートに、その課題を書き込んだ。

　ここでの課題は、とりあえず一つ。そのデーモン、あるいはサーバを個々のユーザが持つのか、それとも研究室やサイトで一つのデーモン、あるいはサーバを動かし、それが個々のユーザの記録ファイルをパーズし、また書き込むのか。一つめの方法では、生存報告を受けるポート番号の問題があるかもしれなかった。二つめであれば、ファイルを書き込む権限の問題があるように思えた。

「なら、両方を使えばいい」

　wormがまず接続するデーモンがあり、そこからユーザ権限で動いているデーモンに接続を引き渡す。ごく普通の通信のモデルだった。

　すでに存在する、wormからの報告を記録するtext/html形式のファイルをパーズするのは、現在のHTMLの規格ではすこしばかり面倒かもしれなかった。というのも、タグを閉じる必要がない場合が認められており、あるいは閉じるタグが規格に存在しない場合もあったからだった。

　ただ、ブラウザにおけるHTMLのタグの扱いは緩やかなものであり、規格において存在しないタグは無視される。ならば、閉じるタグを書き込んでいけない理由はないし、それが書かれているほうが、パーズは確実であり、なおかつ容易であった。文字コードの問題を置いておけば、awkで充分に扱えるくらいに。

　問題があるとすれば、ユーザに属するデーモンが起動していることを確実にすることだった。とは言え、ユーザがログインするたびに、窓口になるサーバにリモートで起動あるいは存在の確認をすれば事足りる問題でもあった。

　現時点で寄せられている要望については、この方法で対処できるように思えた。

　歩は二週間ほど後に、wormからの報告を受け付けるデーモンを含めた次のバージョンを、テストに協力してもらっている研究室に配布した。