« 前のひとこと | トップページ

cocolog:91914050

「グローバル共有メモ」こと shared_memo.cgi を作り、このサイトにそのウィジェットを貼り付けた。 (JRF 2709)

JRF 2020年5月18日 (月)

記事は↓。

《グローバル共有メモ - JRF のソフトウェア Tips》
http://jrf.cocolog-nifty.com/software/2020/05/post-dd6738.html

JRF2020/5/189881

……。

XREA にアカウントを取って、CGI が作れるのが大きな喜び。

今もそうなのかはわからないが、

JRF2020/5/183247

《「アカウント」の FAQ - はやわかり XREA & CORESERVER》
http://www.hayawakari.com/xrea/?FAQ%2F%A5%A2%A5%AB%A5%A6%A5%F3%A5%C8
> Q. サーバアカウントが削除されることはありますか?

(…)無料アカウントでは、規約違反でなくとも、次のような場合はアカウントが自動削除される場合があります。(…)

* 1 週間広告の表示が一度もなかった。

JRF2020/5/181685

…とあって、これが心配なために何かアクセスが稼げるものが欲しいと考えた。いろいろ考えて、このブログサイトのクロスリファレンスを表示するウィジェットを作ろうか…とか思ったが、結局、memo.cgi などを作ったあとの流れで、思い付いたのが、この「グローバル共有メモ」ウィジェットだった。

JRF2020/5/184978

そもそも有料アカウントにすればいいという話もあるのだが、私が死んだとき…XREA は有料が無料に変わるらしいが、そのときもちゃんと表示がされるか確認する方法が、複数アカウントで一方を無料にする以外にないが、それをしていいのか、どうすれば合法的にそれができるのかがよくわからず、結局、無料アカウントのまま、実装する方向を選んだ。

JRF2020/5/187172

……。

このウィジェットは自由に使われて欲しい。検索よけはしてあるが、QR コードを載せてスマホで見やすいような配慮もしてあり、ソーシャルな感じでも使えるはず。

街カドの黒板のようなものを目ざして、memo.cgi などの CGI アプリと違い、ブログウィジェットとすることにしたのだった。

JRF2020/5/186299

……。

……。

追記。

更新。バージョン 0.0.2。

その情報の前に、XREA に ID を取ったことと memo.cgi については [cocolog:91904342] で「感想」を述べている。

JRF2020/5/193467

で、0.0.2 のことだが、まず、凡ミスの修正、IE への部分的な対応があるが、大きなところは、「グローバル共有メモ:ログ」にメッセージのハッシュを載せるようにしたことがある。このことについて説明しよう。

掲示板ではログが残っている。このウェブアプリでは、メモの「ログ」こと「メッセージリスト」の他に、書換・削除の際の日時や IP アドレスなどが残る「書込ログ」が取られている。

JRF2020/5/197460

この両者のログには自動的に大きくなり過ぎるとカットする機能がある。そのため、情報が残ることを嫌う攻撃者によって、大量ポストによる「消去」が図られるおそれがある。

それに対応するため、バージョン 0.0.1 では「メッセージリスト」にメッセージがまったく残らない消去を用意したのだった。これでメッセージに文句をいう人が出てきたとしても、書込者はしらばっくれることができる。

JRF2020/5/195444

しかし、そうしていると、文句を言うがためにスクリーンショットを取る人が現れ、それが IP アドレス開示を迫ってきたときどうするかという問題が出てくる。もし書込者に本当に問題があるなら、開示してもいっこうにかまわないのだが、仮に逆にこの開示請求者が悪意を持っているとした場合、問題となる。

JRF2020/5/196111

そこで、「メッセージリスト」にハッシュを載せることにした。これで悪意のある開示請求者は相当排除できるだろう。しかし、こちらを強くすると、問題は、「書込ログ」に残る IP アドレスを消したい者がまた現れ、大量ポストする誘引ができることになる。

いっそのこと、IP アドレスも「メッセージリスト」に表示してしまうという手もあるのだが、そうすると、事情をよく知らないプロバイダが悪意のある開示請求者にだまされる誘引を作ることになりかねない。

JRF2020/5/192265

そこで IP アドレスのハッシュを「メッセージリスト」に表示することにした。「メッッージリスト」のハッシュは一つに見えるが、実は二つの部分、「メッセージハッシュ」と「IP ハッシュ」からなっている。

これにより二つのログが実質的に消去されても、開示請求者の側にメッセージリストが保存されており、怪しい IP アドレスの心あたりがあれば、その IP アドレスからの書込であったことを確認できるようになった。

JRF2020/5/197921

これにより大量ポスト攻撃の誘引も減るだろうし、悪意のある開示請求者への誘引も減ることと私は考えている。

JRF2020/5/193154

……。

その上で、保存されたメッセージリストが「真正」なものかどうかハッシュをチェックするスクリプト calc_hash.pl をアーカイブに同梱することにした。

保存されたメッセージリストを log.html とし、怪しい IP アドレスを XXX.XXX.XXX.XXX とすると、shared_memo.cgi が生成したキーファイル shared_memo_key.xml がカレントディレクトリにあるところで、次のように実行すればよい。

JRF2020/5/198499

<pre>
$ perl calc_hash.pl -H -i XXX.XXX.XXX.XXX log.html
</pre>

JRF2020/5/193030

そうすると、メモごとに計算されたハッシュとその横にメッセージハッシュがあっていれば ok と、IP ハッシュがあっていれば ip と表示される。

もし、すべてに ok が表示されていれば log.html は真正であると考えてまず間違いない。ok のところでさらに ip が書かれていれば、その書込は「怪しい IP アドレス」からによるものと言ってまず間違いがない。(ただし、ハッシュを取るアルゴリズムやキーファイルに変更があった場合はこの限りではない。)

JRF2020/5/191466

ok が出ていないのに ip が合っているというのには注意を要する。それは本来ありえないからだ。もしそうなっていれば、キーが盗まれたことを脅迫的にほのめかされていると考えるべきなのかもしれない。

JRF2020/5/193694

……。

log.html はないが画像のスクリーンショットがあり、日時と怪しい IP アドレスがわかっているという場合、次のようにコマンドを実行する。

<pre>
$ echo "" | perl calc_hash.pl -t 2020-05-18T14:3647Z -i XXX.XXX.XXX.XXX
XXXXXXYYYY
</pre>

JRF2020/5/191118

このとき表示されるハッシュ XXXXXXYYYY のうち、XXXXXX の部分はメッセージハッシュで、今回は関係ない。後ろ4文字の YYYY が IP ハッシュで、ここがスクリーンショットのハッシュと一致していれば、その IP から書かれたものであることは確認できる。

しかし、スクリーンショットのメッセージの部分のみ不正に書き換えることはできるので、そのメッセージそのものを書いたことは確認できないことには注意が必要である。

JRF2020/5/196689

もちろん、スクリーンショットからメッセージを復元できればいいのだが、スペースや細かな文字の違いでハッシュが合わなくなるため、あまりあてにはできない。が、復元したメッセージのハッシュも合うようなら、それはメッセージの確認も取れたことになる。

JRF2020/5/199451

……。

なお、メッセージハッシュ、IP ハッシュともにハッシュを取るときは、日時と連結して取っている。

メッセージハッシュに日時を連結するのは、日時の偽装がなされないためである。

JRF2020/5/192180

IPハッシュに日時を連結するのは、少し考えてこうした。日時を連結せず IP アドレスそのものはわからないが同じ IP アドレスの投稿かはわかるようにするという方向はありうるとは思う。しかし、IP アドレスというものはしばしば変わるもので、突然ハッシュが変わって別人が書いたことにされたり、IP ハッシュの変化の傾向によって使っているプロバイダを予想できたりしたりしたら、あまり穏やかではないな…と考えて、同じ IP アドレスかどうかがユーザーからはわからないように日時連結をすることにしたのだった。

JRF2020/5/198304

……。

もちろん、こういうトラブルが実際の起こることを「想定している」ということではない。こういうトラブルにも容易に対処できることを示すことで、攻撃者が現れにくくするということである。

JRF2020/5/193632

……。

……。

追記。

更新。バージョン 0.0.3。

凡ミスの修正。削除の際、削除理由を聞くようにした。w3m でもいちおう動くようにした。ハッシュの取り方を変更し、ハッシュの説明は README.md に書いておいた。(だから上の 0.0.2 のハッシュに書いている部分はもう参考にすべきでない。)また、メモを保存するとき crlf を lf に変換しておくようにした。

JRF2020/5/246674

……。

w3m は button タグが使えない。eww は select とかが使えない。eww には対応せず、w3m にのみ対応した。

JRF2020/5/240136

……。

あと、ちょっと迷ったのが、Crypt::OpenSSL::RSA を使って、各メモに電子署名を付けようか…ということ。XREA には Crypt::OpenSSL::RSA は入っているんでやろうと思えば難しくはない。…が、結局、付けなかった。

JRF2020/5/247301

管理者以外の弁護士とかがメモの真正性を管理者に問い合わせずに判断できるというのはいいことではあるだろうけど、そんな段階になったらむしろ管理者に連絡して欲しい気もするし…。そもそも、そこまでするか?…って感じ。

JRF2020/5/243433

ブロックチェーンの昨今、私、RSA っていまいち信用できないんだよね。それをいうなら、今使っている HMAC_SHA1 もそろそろ信用できないんだけど…。ビット長を増やせばいいという話ではあるんだけど…。

JRF2020/5/242711

その代わりに、メッセージハッシュを少し変えて、キーがなくてもハッシュの確認が取れる部分を設けた。もちろん、誰でもハッシュが確認できるということは、その部分の偽造も誰でもできるということだけど、そこの偽造をちゃんとするぐらいの技術力があれば、そう簡単にすべてのハッシュの偽造ができないということも気付くだろうから、意味があると判断した。

JRF2020/5/244571

……。

スクリーンショットからメッセージを復元しやすいように、全角スペースに色を付けようかと考えたが、やめた。アスキーアートのシンプルな美しさが損われるため。

JRF2020/5/244727

……。

……。

追記。

更新。バージョン 0.0.4。

Google reCAPTCHA v2 checkbox をすぐ導入できるようにした。自分が書いたものとそうでないものを区別できるように SESSION_ID を導入した。

JRF2020/6/13300

……。

私自身は、実験のため reCAPTCHA を導入して試したあと、reCAPTCHA を使わないように戻した。reCAPTCHA があるほうが、今の時点では安心感があるけど、将来的にはどうかな…と思う。

Google は、結構、薄情で技術進歩に遅れたところは見捨てることがある。reCAPTCHA v2 もいつ、対応がなくなるかわからない。対応が消えたとき残ったコードがどうなるかは見知数。

JRF2020/6/15570

私の shared_memo.cgi の他の掲示板システムと違う唯一の良さと言える部分は、ログもしっかり limit を設けて切っていて、私が死んだ後も管理者のいない掲示板として、容量を食いつぶすことなく存続しうる点。

そこに存在意義があるのかな…とか考えているから、Google の都合で使えなくなるのは、あまりよろしくない。まぁ、Google がやめるより前に XREA の都合でダメになる可能性のほうが高いのだろうけど、でも、いちおう可能性は開いておきたい。

JRF2020/6/16756

だから、できることなら reCAPTCHA は使わない方向で。もし、ロボット等に攻撃されたとしても、やがてそれ自身により攻撃する価値がなくなって攻撃がやみ、また機能が復活する…というほうが、この「メモ」のあるべき姿かな…とか思う。

JRF2020/6/12939

……。

自分が書いたものとそうでないものを区別したい。最初は、IP アドレスだけで自分かどうか判断するようコードを書いたのだが、それだと、たまたま IP アドレスが同じになった別人に IP アドレスを知られてしまう問題が出てくることに気づいた。そこで、SESSION_ID を導入し、その問題を避けるようにした。

JRF2020/6/17021

自分かどうかの判断を SESSION_ID と IP アドレスの組でするか、IP アドレスなしで SESSION_ID だけにするかで迷った。前者のほうがセキュリティが強く、後者のほうが、スマホで IP アドレスが頻繁に変わる場合に便利。結局、セキュリティに目をつぶって後者を選択した。

JRF2020/6/11515

セキュリティの問題とは、無視できる小さな確率だが、偶然、SESSION_ID を当てた者に「自分」として書いた履歴を引き出されうること。もちろん、セキュアな通信ではないので、プロバイダが SESSION_ID を知ることができるという問題もある。が、10日前後で SESSION_ID を更新し、メモは200個までしか保存しないので、その問題は大きくないと考えることにした。

JRF2020/6/15564

自分が書いたものには先頭に「●」が、そうでないものには先頭に「○」が表示される。さらに、削除についても、自分が書いたか否かが残っている以外に、誰が消したかも残っていて、自分が消した場合は、先頭の丸が 青緑(teal) に、他人が消したときは赤になるようにした。赤い「●」のとき、自分が書いたのに他人が消したもので、要注意となる。

JRF2020/6/18094

……。

また、IP アドレスをログページの末尾に表示するようにした。これは私以外の誰かが著作権を主張したくなったとき便利だろうというので付した。

「この掲示板に書き込まれたものの著作権は放棄したものとみなす」…としたところで、どこかから「無断引用」だったりすることもあるわけで、管理人が自由に使えるようにはならない。完全に私が書いたもの以外は、結局、裁定制度みたいなものに頼らないといけないだろう。

JRF2020/6/11636

「完全に私が書いた」ということはある程度証明できるとして、他の人の「影響がある」ぐらいでは裁判には勝てるだろう。人の掲示板に書いておいて、普通強い主張はできないというのは期待してよいと思われる。

JRF2020/6/19404

問題は、他の人が自分が書いたと主張したい場合。ここではじめて書いたものを自分のところに書きなおしたとき、ここではじめて書いたことの証明が問題になったとすると、それに何の手当てもないのは申し訳ない。

そこで、保存されたログページに日時と IP アドレスが残るようにし、本当に問題があれば管理人に頼れば書いたことを証明できるようにした。

ただし、管理人たる私は、自分に不利な証言は基本しないものと、こころ得て欲しい。

JRF2020/6/15983

……。

あと、「※ ここの対話にはたくさんのフィクション・自作自演が含まれてます。」という注意書きを付しておいた。

JRF2020/6/17118

……。

あと、このメモ、いちおうログを私の PC に保存するようにした。…といっても、「グローバル共有メモ: ログ」のページを開いて、そこでマウスをドラッグして選択して、コピペしてテキストファイルに保存するだけの原始的な方法。

ある程度期間をおいて、気が向いたら保存するという方針。私が見る前などにすぐに削除されたら残らない。私以外誰も書かない現状を考えるとそれで十分なように思う。

JRF2020/6/11702

« 前のひとこと | トップページ