cocolog:91914050
「グローバル共有メモ」こと shared_memo.cgi を作り、このサイトにそのウィジェットを貼り付けた。 (JRF 2709)
JRF 2020年5月18日 (月)
……。
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
……。
……。
追記。
更新。バージョン 0.0.5。
削除をしたとき IP ハッシュが残るようにした。メモそれぞれに固有ページはないが固有リンクはできるようにした。
JRF2020/6/94027
……。
「削除」には YouTube などのプロバイダ側・著作者側の過剰な削除の問題がある。正当な理由のない削除を問題にするためには、もっとユーザーがカジュアルに削除をし、そのユーザーの削除が問題だと言えたほうがいいのかもしれない。
JRF2020/6/94110
過剰な削除は「知る権利」の侵害であり、本来の権利を破壊したという点で器物損壊罪に近いものだ。ただ、特に書いた本人や、書かれたことが当人に関わることなら、削除に求められる「正当な理由」もかなり軽いもので良いと私は思う。一方で、自分達の著作物でもないものについて情報を独占するため、自分が読んだあと削除するというのは、「正当」とは言いがたいのではないか。
JRF2020/6/96768
今回、削除のとき IP ハッシュが残るようにするかどうかは少し迷った。書き込んだ者は削除によって、IP ハッシュがメモに残らないようにできるのに、削除した者は削除を反省したとしても、自分が削除した証拠を消せないのはフェアではないのではないか…と考えたのだ。
JRF2020/6/92954
しかし、SESSION_ID を導入する過程で、サーバー側のログには IP が残るようになっており、それが見た目でわかりにくいのも問題があるかと思って、IP ハッシュだけは載せておこうと考えを改めた。
JRF2020/6/93946
……。
……。
追記。
更新。バージョン 0.0.6。
削除の際のハッシュを削除者の IP ハッシュ 4桁だけでなく、消したメッセージの確認ハッシュ 2桁も残し、6桁にした。18時間以内は、書いた本人しか削除できないようにした。@WRITABLE_IP を設定して、特定の IP からだけ書き込みを許せるようにした。
JRF2020/6/166926
……。
あるメモを削除した log.html ファイルを手に入れた人が、探して削除してないファイルを手に入れたとき、簡単にそれが本物であるかを確認できるようにした。もちろん、たいした偽造対策はしてないので、手の込んだ偽造をつかまされている可能性は排除できないが。
これで「ずさんな偽造」を排除した上で、管理人にそのファイルの確認を依頼すれば、かなり信頼できる結果が得られる。
JRF2020/6/167957
……。
削除者が、復元したファイルで儲けるようなことができるかもしれない。しかし、常に削除されるようなところだと、わざわざ復元したファイルを買うような者はいないだろう。ある程度残しながら削除するという戦略になるのではないか。そのような人気のあるところでは、削除される前に保存する者が何人か出てくることになるだろう。それは望むべきことだ。
JRF2020/6/168608
そのような状況を助けるために、他人による削除は、18時間以内禁止するようにした。ただ、もともと削除可だったこともあり、その禁止はセキュリティ的にそれほど強固ではない。
JRF2020/6/163014
……。
calc_hash.pl を cgi 化した calc_hash.cgi を作り 2時間ほど設置してしまった。
しかし、これにより、誰でも log.html の偽造ができるようになることに気付き、急遽取り下げた。危なかった。
calc_hash.pl はちっとも安全ではなく、その任意の結果を他の人に知らせてはならぬものだと気付いた。
一瞬、「ハッシュも入力してそのハッシュが合っているか確認する」だけにすれば OK ではないかとも考えたのだが、結局それもダメだと結論した。
JRF2020/6/162805
メッセージハッシュについては、実質4桁しかないため総当たりが不可能ではない。一回ずつ合っているかどうかを繰り返し聴いていくのが微妙に可能で、これが 10 桁とかだとまぁ、不可能と言って良かったんだろうけど。
また IP ハッシュについては、IP アドレスってユーザーに許されてるのって案外多くなかったりするから、これは桁がいくつでも総当たり的に、元の IP アドレスを発見されるかもしれないと考えた。
JRF2020/6/168943
そういう攻撃は XREA のほうで DOS 攻撃みたいなものとしてはじいてくれるかもしれないが、そういう試みがなされうるということ自体が、タダで使わせてもらってる立場からすると「悔い」るべきところかな…と思って控えることにしたのだった。
JRF2020/6/164132
……。
街角に設置するとしたら最低限何が必要か…と考えて、@WRITABLE_IP を設定して、特定の IP からだけ書き込みを許せるようにした。
ただ、実際に街角に設置するには、shared_memo.css をいじったり、制限付きブラウザを使ったりと他にやることが多いと思う。
JRF2020/6/164007
一般に、設定は、基本、shared_memo.cgi の変数を直接いじることになるが、本格的に他者も使うサービスにしようと思ったら、アカウントにログインして、それらの変数をいじれるようなものが必要だろう。そのとき、shared_memo.cgi はそのまま使い、変数部分だけ書き換えるようにするのか、それとも、shared_memo.cgi を取り込みアイデアだけ使ってサービスするかは、サービサーが考えれば良いことだと思う。
JRF2020/6/161001
特にそういう具体的な構想があるわけではなく、完成度も高くなって、まぁ、そういう妄想も膨らみました。…といったところ。
JRF2020/6/167570
……。
……。
追記。
更新。バージョン 0.0.7。
並び方をチェックできる Sum Hash を log.html に付した(非表示)。その上で、log.html が真正か偽造かをチェックする check_log.cgi を作って同梱した。Android 用に「ページの先頭に戻る」ボタンを付けておいた。
JRF2020/6/245990
……。
calc_hash.cgi の反省点を踏まえ check_log.cgi を作った。Sum Hash は 16 桁とかなり長くしたため、総当たりはほぼ無理だと思われる。メッセージについて個々にハッシュが合っているかどうかも内部ではチェックしているが、個々にはもらさないようになっている。その代わり、確認ハッシュのチェックは個々に表示されるようにした。
JRF2020/6/247659
ただ、HTML の形式などは詳しくチェックしていないため、HTML の構造の偽造などは見やぶれない。log.html をブラウザで見るとチェックしていない部分が表示されるような偽造は可能である。log.html 内に間違いなく真正なデータがあったとしても。
あと、細かいところだが、削除理由についてはハッシュを取っていないので、チェックできない。
JRF2020/6/245033
……。
「ページの先頭に戻る」ボタンとかモーションすらないって Android め…という感じ。
JRF2020/6/243072
……。
……。
追記。
更新。バージョン 0.0.8。
書き込んだ人間が、ログ署名をできるようにした。ログ署名者の(IP アドレスからの)書き込みであることを check_log.cgi で確認できる。
calc_hash.pl に -o オプションを作り、check_log.cgi でチェックできる証明書を発行しやすくした。
JRF2020/7/10490
XREA の共有 SSL など「プロキシ」経由の IP アドレスに対応した。
check_log.cgi で特定のメモを抽出できるようにした。
check_log.cgi で特定の日時のメモに対しログ署名が取られているか否かを調べられるようにした。
JRF2020/7/10037
……。
署名はメモを書き込むときに、ハッシュを書き込み者が勝手に付ければ良いのでは…とか思っていたのだが、先頭の「●」があるから、その「●」に関してハッシュを取れば、署名みたいなことができるということを思い付いた。で、思い立ったが吉日で、実装。
ただ、メモを書いてから、ログ署名を得るまでにタイムラグがどうしてもできるので、大量ポスト攻撃には弱かったりする。
JRF2020/7/13306
ログ署名したあとスクリーンショットでは意味がなく、「ページを保存」する必要があるのが初心者向けの注意。
JRF2020/7/19767
……。
calc_hash.pl の -o オプションは↓のようにして使う。
<pre>
perl calc_hash.pl -i 127.0.0.1 -t 2020-06-26T00:00:00Z input.txt -o output.html
</pre>
output.html に証明書ができる。input.txt を utf-8 の改行 lf にすることを忘れずに。
JRF2020/7/19048
……。
XREA の共有 SSL でも動くようにいくつか改変を行った。一つは上で書いた「プロキシ」経由の IP アドレスへの対応。
もう一つは、Google reCAPTCHA で、ss1.xrea.com のドメインを許可したこと。ただ、これはセキュリティ的には疑わしい変更で、こんなことやっていいかは自信がない。
JRF2020/7/10427
さらに一つは、shared_memo_widget.js で変数 CGI の設定を自動にし、共有 SSL 上の shared_memo_widget.js が呼ばれたら、共有 SSL 上の shared_memo.cgi を使うようにしたこと。ただ、これでサイト特有の設定がほとんど必要なくなったが、shared_memo_log.png の QR コードは共有 SSL でも変わらないのは注意。
JRF2020/7/16584
……。
「check_log.cgi で特定のメモを抽出できるようにした」のはログを売りやすくするため。同時に「※ログ署名で確証できるメモの著者は十分な補償のないメモの再配布を禁止できるとします。」という注意書きも付した。
JRF2020/7/18728
定期的にバックアップを取っている者がログを売れるようにしたいが、それだと(潜在的な)数が多過ぎて商売にならないものと想定した。そこで、メモの著者の許可がないと売れないようにしたらどうだろう…と考えての注意書き。せっかく「ログ署名」という仕組みがあるので、逆にログ署名をしてない者は著者としては認めないと暗に述べるのが、上の注意書きになる。
JRF2020/7/18891
ただ、その注意書きだけだと、雑他な著者が混じったメモは逆に売りにくくなる。そこで、特定のメモをあとからログから抽出できるようにした。
まぁ、このあたりも夢想・妄想のたぐいでしかないが…。
JRF2020/7/14620
……。
あと、書込ログ(shared_memo.log)に書く量が増えたことにともない $LOG_MAX = 10000000, $LOG_TRUNCATE = 7000000 にした。(ちなみに元々 $LOG_MAX = 30000000 だったが、意図したより桁一つ多く間違ってた。)
JRF2020/7/13686
……。
check_log.cgi に、特定の書き込みについて、ログ署名が取られているか否かを書込ログ(shared_memo.log)から調べられるようにした。(check_log.cgi は shared_memo.log がなくても確認できるのが「売り」だったので、ちょっと残念な感じはあるが…。)
ただ、調べられるようにしたことが、良いことなのかどうか、今も迷っている。メモが古いと確認できなくなるのは、大量ポスト攻撃を誘うかもしれないし、あとから来た人間が不利になるということでもある。
JRF2020/7/17083
注意書きとして、まず、「※識別子の切り替え期間を過ぎても管理人はログ署名できます。その場合には告知します。」とした。その上で cacl_hash.pl で、管理人がログ署名証明書を発行したとき、書込ログにその痕跡が残るようにした。
また、注意書きとして、「※メモが古過ぎる場合、正規の販売がないか十分確認しましょう。」とした。それは…
JRF2020/7/14187
再配布を受けた者が、後に正規の販売を知って購入した場合は、その者に再配布をした者の責任は追及しえないとしたいから。
再配布を行う前に、ある程度時間がたってから check_log.cgi で確認した者については、正規の販売がないと十分判断できた時点で、故意・過失はないとできる。
JRF2020/7/13029
なぜなら、公式に「十分」で良いと書いてるのは逆に隠す者がいることを許可しているとできる。「十分」探して見つからないことは、ある意味隠していると判断してよく、見つからなくても故意・過失はない。「十分」と書かれていることを知らなかったという場合は販売を知らなかったというのに対抗できない。
JRF2020/7/10966
再配布を受けた者が、正規の販売を見つけて買った場合、再び過失が問題となるが、本来損失となるべきものがそうならなかったので、この件については「損害の発生がない」となり、不法行為に問う追及をする責任が再配布を受けた者にはない。
…などと考える。
JRF2020/7/19106
逆に、書込ログが消えるよう大量ポスト攻撃をした者が「ログ署名が見つからなかった」し、正規の販売の可能性など「知らなかった」と居直れないようにも促す注意ともなっている。
JRF2020/7/18208
……。
なお、check_log.cgi は専門家が使う者で、あまり考慮する必要はないかもしれないが、ログ署名の名前こと NICKNAME が気に食わないことがありうる。安易に消去もできないので、方法を用意した。
ログ署名が取られてないか調べるとき、その表示を制限するには、check_log.cgi の our @DENY_NICKNAME = (); のところで、our @DENY_NICKNAME = ("気に食わない名前", qr/とっ+ても気に食わない名前/); などと指定できる。文字列でも正規表現でも良い。
相手は証拠を残しているのだから、変に熱くならないことが肝要である。
JRF2020/7/13996
……。
……。
追記。
更新。バージョン 0.0.9。
メモの行数を 100 以下に制限した。
JRF2020/8/186187
……。
……。
追記。
更新。バージョン 0.1.0。
バージョン 0.0.9 のときに混入した改行コードに関するバグを修正。
JRF2020/10/289058
……。
……。
追記。
更新。バージョン 0.1.1。
今回は、基本、ログページのリンクに a タグや ruby タグを付し、それを「ページを保存」したものでも check_log.cgi などが通る…というのを目標とした。本来はとても簡単な目標。
それを追う過程で、ハッシュ値を取る際のバグを発見し、このバグを取るのにエライ難儀した。メモ数の上限に関するバグだと気付くのに時間がかかった。そのバグは、書込のあとでは出るが削除のあとでは出ないため発見されていなかったのだ。
JRF2020/12/77404
やっとバグを取ったものの、「ページを保存」したものが check_log.cgi を通るためには、さらに、バージョン 0.0.9 のバグである \x0d が混入することの後遺症をなんとかする必要があった。
そこでお行儀が悪いが、\x0d が含まれるメモは、\x0d を除去した上でメモごとのハッシュを取り直すことにした。正常な動作ではメモごとのハッシュは一度決まれば変わらない。それが変わるわけだから問題があるが、今回のみの一回の対応でできるということでお許しいただきたい。
JRF2020/12/71961
ちなみに、更新しただけでは \x0d の除去は起きない。一度、メモを書くとそのときに一度だけ一気に全メモの \x0d の除去を行うことになる。(以前から普段の投稿において常に \x0d の除去が行われているのでそうなる以前のメモが対象。)
JRF2020/12/75928
……。
……。
追記。
更新。バージョン 0.1.2。
shared_memo_log.js で [ ] の中に URL がある場合の修正。shared_memo.js で TEXTAREA を変更すると「書込」の色が変わるように改良。
JRF2020/12/296001
……。
……。
追記。
更新。バージョン 0.1.3。
CSS をほんの少しいじっただけ。
JRF2021/2/138899
……。
……。
追記。
更新。バージョン 0.1.4。
Windows の改行コードの関係で、改行を含む2000文字近いメモを書き込むと最後のほうが切れる問題を修正した。めっちゃ安直な方法で。
JRF2021/8/182371
……。
……。
追記。
更新。バージョン 0.2.0。
フォントを Textar ではなく monospace を使うようにした。renew_key.pl を足した。
JRF2021/12/127349
……。
……。
追記。
更新。バージョン 0.2.1。
XREA がアップデートして Perl に JSON モジュールが入っておらず、 JSON::PP を使えということらしいのでそうしたのみ。
JRF2022/9/263226
……。
……。
追記。
更新。バージョン 0.2.2。
ログに表示される注意書きのみいじった。プログラムはそのまま。
注意書きには「※管理人によるネットでのアーカイブに同意しない場合、間に合うように削除してください。」を足した。
いろいろ考えてこの文にした。まず、管理人が私とは限らなくなっても良いようにしたが、誰でも良いわけでもなく、それは裁判などがあれば確定できるだろうと考えている。
JRF2023/1/281717
次に「ネットでのアーカイブ」であるが、これは今のところ、↓であるが、これは、３ヶ月ごとにアップロードする他に、一年に一度、年末に、私は Internet Archive に Save してもらうようにしてるのでそれを含む。
《JRF のココログのバックアップファイル置き場》
http://jrockford.s1010.xrea.com/jrf_cocolog_backup/index.html
JRF2023/1/287175
ただし、他の人が勝手に Internet Archive などに登録したものについては、メモの著者が削除申請できるよう、「管理人による」という限定を付けている。
「同意」とは、その上の注意書きで、「補償のないメモの再配布を禁止できる」としているが、補償のないメモの管理人によるアーカイブでの再配布に永続的に同意するということ。または、ログが流れ切る前に管理人が補償して、メモをアーカイブで永続的に再配布してもいいように同意が別に成立して残したということ。
JRF2023/1/288157
「間に合うように」というのは、一つには、ログが流れ切る少し前にチェックするので、その前に…ということ。そのチェックは私でない者による定期的なものも想定していて、「少し前」は直前とかではダメということになる。もう一つには、管理人によるアーカイブが３ヶ月ごとにあるが、そのときたまたま書かれたものはアーカイブされてしまうので、その前に、ということ。
なお、間違ってアーカイブされてしまったとき、言えばなんとかできる部分もあるので、言って欲しい。
JRF2023/1/286874
記事は↓。
《グローバル共有メモ - JRF のソフトウェア Tips》
http://jrf.cocolog-nifty.com/software/2020/05/post-dd6738.html
JRF2020/5/189881