Home

日記
ゲストブック認証+閲覧者数制限によるアクセス制御 (13:51)Edit

微妙に補足説明を追加してます。


で、「リンクの拒否権」(http://mylog.ishinao.net/id/1129)の最後に出てきた、「パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラ」に関する考察を進めてきた結果、「ゲストブックとRURIコードによるアクセス制御」(http://mylog.ishinao.net/id/1096)と「記事ごとに読める人の人数を制限できる仕組み」(すみません。どこで読んだのか忘れてしまいました)を組み合わせた、現在の私が考えつく、もっともバランスのいい匿名のままに認証&アクセス制御する仕組みについてまとめてみる。

まず、アクセスしてきた閲覧者(ブラウザ)にランダムなIDを振り、Cookieに登録する。次回アクセス以降、CookieにランダムIDが存在した場合はそのIDを利用し、存在しない場合にのみ新しいIDを割り振る。IDは重複することが(論理的に実用時間内には)なく、閲覧者(ブラウザ)を一意に認識するためのIDとして利用できる。+[また十分に複雑なランダム性を持つIDなので、他人のIDを類推することは不可能である。]+そのIDのことを、この考えの元ネタであるHNS(Hyper Nikki System)での呼び方に準じて、ここではRURIコードと呼ぶ。

RURIコードを使うことによって、閲覧者を匿名のままに区別して扱うことが可能になる。閲覧者にID、パスワードの管理や入力という手間をかけさせることがない。ただし、Cookie盗難には十分注意する必要がある。

続いてゲストブック(記名帳)を用意する。ゲストブックとは、閲覧者がサイト管理者に対して、自分が読者であることを表明するための投稿フォームである。ゲストブックへの登録の際には自動的にその閲覧者のRURIコードも記録される。ゲストブックに登録した人(RURIコード)は、「GUESTグループ」に加えられることになる。

またこのゲストブック登録の段階で、メールによる自動認証(登録されたメールアドレスにシステムがワンタイムパスワード付きメールを送信し、そのパスワードによって正当なメールアドレスかを自動確認する)などをシステムに組み込むことができる。そのシステムを適用する場合は、ゲストブックに登録しただけの閲覧者を「弱いGUESTグループ」、その中でメールによる自動認証をすませた閲覧者を「強いGUESTグループ」に加えるなど、2段階のグルーピングを適用することもできる。ただしここではできるだけ話をシンプルにするため、1段階のGUESTグループを適用することにして話を進める。

ゲストブックは原則として管理者にのみ公開される。そこで、そこには管理者以外には知られたくない情報を記述することもできる。たとえば「○○高校で同級生だった○○だよ」みたいに個人情報を含んだ内容も登録でき、それによって管理者はあるRURIコードの持ち主が誰なのかをより正確に判別することができる。当人同士しか知らないはずの情報を含ませるほど、本人確認の厳密さが高まるだろう。

管理者は、ゲストブックに登録した人の中から自分が選んだ人を、「FRIENDグループ」に昇格させることができる。単純にゲストブックの書き込み1件ごとに対して、グループ昇格ボタンなどをクリックするような形だろう。

ここでも実際には、ごくごく親しい知り合い用の「強いFRIENDグループ」、それ以外の知り合い用の「弱いFRIENDグループ」のような複数の段階のグルーピングを行うこともできるが、ここでは話を単純化するために1段階のFRIENDグループを適用することにして話を進める。

以上のグループに含まれていない閲覧者は、「ANONYMOUSグループ」に含まれることとすると、閲覧者は「ANONYMOUS(見知らぬ読者)」、「GUEST(登録読者)」、「FRIEND(知り合い)」という三つのグループに分けられることになる。

ANONYMOUSに関しては完全な自動登録となるし、GUESTに関しては閲覧者のちょっとした作業のみで登録が行われる。FRIENDに関してはさらに管理者のちょっとした作業が必要になるが、規模がよほど大きくない限りはそれほどの手間ではないだろう。といった程度のコストで、閲覧者をそれなりに妥当な権限グループに振り分けることができる。また、この程度ならばそれほど技術に詳しい人でなくても、仕組みを理解することができるだろう。

続いて、このようにグルーピングした閲覧者に対して、どのように認証および制限を加えていくか。

システム自体の設定としては、まず閲覧者からのリアクション機能に関する設定がある。具体的にはコメント機能やメールフォーム機能を、どのグループのユーザーに対して公開するか。ゲストブックにURLも登録されているのならば、そのURLとのマッチングによってTrackBackに対する認証を行うことも可能になる。

比較的内輪向けのサイトならば、コメント機能はFRIENDのみ、メールフォーム機能はGUESTとFRIENDのみ、といった感じになるだろうか。オープンなサイトならば、すべての機能をANONYMOUSにも使わせればいい。

あるいは、許可したグループにのみリアクション機能を使わせるのではなく、他のグループにも投稿だけは許可するが、その内容をサイト上に掲載するかどうかは、管理者が決定できるようにすることもできるだろう。+[いわゆる、管理者がチェックしない限りはWeb上に投稿が掲載されない掲示板システムと同様の仕組みだ。]+

続いて公開範囲および規模の設定を、記事単位で行うことができる。基本的には、どのグループに対して何アクセスまで公開するかを設定することになる。

たとえば内輪向けの記事ならば、FRIENDに対してのみ無制限アクセスを許可(許可アクセス数=-1)し、GUESTやANONYMOUSに対してはアクセスを拒否(許可アクセス数=0)すればいい。その記事は知り合いのみが閲覧することができるようになる。

また、ある程度は一般に公開してもいいが、あまりリアクションが多くなることを恐れるのならば、たとえばGUESTには「許可アクセス数=100」、ANONYMOUSには「許可アクセス数=10」などと設定しておく。すると、GUESTグループに所属する人が100回アクセスすると、それ以降訪れたGUESTグループの人には「現在公開が停止されています」などのアナウンスが表示されるようになる。同じくANONYMOUSグループの人は10アクセスまでしか閲覧することはできない。

ちなみに、このような制限を施している場合は、(システム的に)その説明を明示しておいた方がいいだろう。

「この記事は友達登録を行った人にのみ公開しており、それ以外の方は閲覧できないようになっています。友達登録を行いたい方はゲストブックからご登録ください」

あるいは、

「この記事は100人にまで閲覧を許可しています。それ以上の閲覧者が訪れた場合は自動的に公開が停止されます」

などと提示しておく。それによって、その記事の公開範囲・規模が閲覧者に伝わり、その結果背景にある管理者の意図が、ある程度閲覧者(あるいは閲覧できない人)に伝わることになる。

もちろんこのように閲覧者を制限したところで、誰かがその記事の内容を引用したり転載したりすることによって、ネット上に広まっていってしまうことはある程度はさけられない。しかし、現状の管理者の公開意図がほとんど伝わらないシステムと比べると、ずいぶんとましな状況になるのではないだろうか。

以上の仕様では、特に難度・コストが高い技術は使っていないので、一般的なWeb技術者ならば比較的簡単に実装が可能だろう。また、細部に関しては様々なカスタマイズの余地もあるので、利用するサービスに応じて適切に応用してもいい。

Published At2004-02-07 00:00Updated At2004-02-07 00:00

日記
InterWikiPoweredByGoogle (13:51)Edit

2004/2/9 その2

ちょっとだけ試してみたら、「WikiName site:登録WikiサイトURL」だとドメインを持っているWikiサイトしか対応できないんで、「WikiName site:登録Wikiサイトドメイン 登録WikiサイトURL(共通部分)」にしないとだめっぽいな。

たとえばうちのpukiwikiでblogmapを探す場合は、「blogmap site:ishinao.net http://ishinao.net/pukiwiki/」(http://www.google.com/search?q=blogmap%20site:ishinao.net%20http://ishinao.net/pukiwiki/)なんて感じ。


2004/2/9

>>Wiki同士の連係がもっと容易になったら便利だとは思いますが。 とかその前の日のコメント(http://sheepman.parfait.ne.jp/20040207.html#c)あたりがネタもと。

あるWikiNameがある。そのWikiNameに対して、Google Web APIを使って、「WikiName site:登録WikiサイトURL」というQueryを投げる。登録WikiサイトURLってのは、InterWikiの設定みたいに連携したいWikiサイトを登録しておいたもの。

Google Web APIの検索結果として返ってきたリストから、ページタイトルにパターンマッチして、それぞれのWikiサイトに該当WikiNameが存在するかどうかを確認する。存在したら、接続用の適切なインターフェース(表示、編集)を用意するなり、強引にGETでページ内容を取得して使っちゃうなり(著作権的に微妙だけど、Wikiならばまあいいか)。RSSauto-discoveryできたらそのdescriptionを取り込んじゃう程度が一番無難かな?

とかやると、GoogleのDBを使ってInterWikiより濃い目のWikiサイト間連携が実現できるかも。InterWikiPoweredByGoogleと名付けてみよう。

Published At2004-02-09 00:00Updated At2004-02-09 00:00

日記
匿名性を保持したアクセス認証のニーズ from kera-ma-go (13:51)Edit

ゲストブック認証+閲覧者数制限によるアクセス制御http://mylog.ishinao.net/id/1130)」への反応。

>>「メールアドレスが分かっているだけの常連さん」に対してそのようなトピックを公開しようとは思いません。身元の分からない相手を非公開情報の公開ターゲットにしたいというニーズがどのくらいあるだろうということには正直疑問を感じます。

「メールアドレスが分かっているだけの常連さん」は「(強い)GUEST」グループ扱いになります。さらに身内度の高い「FRIEND」グループというものを用意しており、その認証の仕組みとしては「ゲストブック登録時に当人同士しかわからない情報を含める」という提案をしていますので、上記に関しては「FRIEND」グループを利用すればいいのではないかと思います。

「FRIENDとGUESTを使い分けるニーズがどれだけあるかわからない」というのでしたら、私にもそれはわかりません。もしかしたら、FRIENDとANONYMOUSだけでいいのかもしれませんし(DI:DOと同じ分類になりますね)、その場合は仕組みをもう一段シンプルにすることができます。

ただ私個人としては、Webにおいては「FRIEND」と「ANONYMOUS」の間に広がる空間(人間関係)を表現することに、大きな可能性を感じています。その部分に、ネットワークにおける人間関係に関する大きな可能性が隠されているのではないか。まあ、そんなものはないのかもしれませんが。

ちなみに「匿名のままに」というのは必ずしもアクセス制御の対象全員が「匿名である」ことを意識しているのではありません。「知り合いも見知らぬ読者も、匿名認証という共通の枠組みの中で取り扱えるようにする」ということです。

たとえばDI:DOでは、アクセス制御対象となる閲覧者には必ず最低限の登録作業(読者登録)およびDI:DOサービス用のID・パスワードの取得を必須としていますが、その作業に伴って、

  1. 閲覧者(読者)登録を行う(ある程度の個人情報をインターネットに流す)
  2. DI:DO向けのID・パスワードを用意する(ID・パスワードを用意すること自体がセキュリティリスクになる。人はたくさんのID・パスワードを覚えられないので、他のID・パスワードと同じもしくは類推可能なものを使いがち)
  3. 認証時に入力する(上記2の論点より、そのID・パスワードの重要度・危険性は、そのサービス内のみならず、その人が管理するID・パスワード一般にまで広がる可能性がある。そのようなID・パスワードを使う機会が増えるほど、その漏洩リスクが高まる)

といったような(括弧内で書かれたような)リスクを思いつくことができます。

そのリスクが実際にどの程度の大きさなのかは、サービスの内容やユーザーの意識によって違ってきますが、もしもリスク自体をなくしてしまうことができるのならば、それに越したことはないでしょう。

というところが、ユーザーを匿名のままに(ID・パスワード登録およびそれを使った認証なしで)アクセス制御を行うシステムの有用性(上記における2と3をなくす)だと思います。ID・パスワードのようなものは、使わなくてすむのならばできる限り使わない方がいい、という提案です。

もちろんそれによって新たに生じるリスクも存在するでしょうから、(すぐに思いつくのはCookieへの依存性が高すぎることから生じるリスク)もしかしたらここで提案しているシステムの方が、一般的なユーザー登録+ID・パスワード認証よりもトータルでのリスクが高くなる可能性がありますが。

>>ただ、この「匿名のままにアクセス認証する」というシステムは、逆に匿名のままアクセスを弾くという用途では有用なのかもしれないとふと思いました。

「アクセス制御」なんで、もちろん許可する方にも拒否する方にも使うことを想定しています。前回は触れませんでしたが、もちろん特定のRURIコードを「BAN(アクセス拒否)」グループに追加するなどといった運用もあると思います。

ただしアクセス拒否に関しては、くりすさんの言われるような偽装行為で容易に回避できるため、単にBANグループに入れるというだけでは実効性が低いだろうとも思っています。単に「拒否されています」ではなく、何らかの穏当な表現によって相手にメッセージを伝えることができれば、それなりに有効な対処方法になるかもしれません。

ちなみにRURIコードを使えば、匿名の相手に対してRURIコードを指定してメッセージを送ることができます(いわゆる私書箱系か。今はなきIch(仮)でも採用していた)。アクセスログなどから何らかの不審な行動(アクセス)を行ったと思われる人に対して、直接メッセージを送ったり1対1で会話をしたりすることも可能でしょう(相手が再度アクセスしてくれば、ですが)。

結局のところ相手は人間ですから、人間を相手にどれだけきちんと(発信者の)意図を伝えることができるか、そしてそれに納得してもらうことができるか、というのがもっとも重要な点となるでしょう。

ゲストブック認証+閲覧者数制限によるアクセス制御」で提案しているシステムは、Webで情報を公開する人間の意図をうまく表現(コントロール)するためにはどのようなインフラが必要なのか、について考えた結果の一提案であり、あくまでも「インフラ」レベルの提案(具体的な実装はサービスによる)にすぎません。

Published At2004-02-09 00:00Updated At2004-02-09 00:00

日記
blogmapのゴミ掃除プロセス (13:51)Edit

そろそろまたblogmapのURLリスト巨大化が始まったんで、ゴミURL掃除プロセスを作成。DB初回登録時から30日以上経っても、そのURLを利用するサイトが現れない場合(要するに一つのサイトしか使わなかったURL)は、削除するようにした。そういうURLがDBの約1/3を占めていた模様。ただ、そのついでに各プロセスのバランスを調整したら失敗してしまい、デッドロック地獄にはまってしまったんでサーバーを強引に再起動。依存関係がややこしいプロセスをパラレルに動かしているんで、ロジカルにデッドロックが起こらないようにはできないんだよなー。MySQLって、temporary tableをファイルに作成するプロセス(ちょっと複雑なjoinをしているもの)が異常に遅くなるんで、そのタイミングで関連tableに触るとlockがかかってしまい、そこにlow priorityな命令が混ざるとデッドロック地獄に落ちてしまう。だいたいindexをちゃんと見てくれれば、全行くっつけるような巨大なtemporary tableなんて作らなくてもいけるように作ってあるはずなのに、なんでindexで絞ったjoinのたびに巨大なtemporary tableを作っちゃうんだろう。

Published At2004-02-10 00:00Updated At2004-02-10 00:00

日記
eBayに「中傷投稿削除の義務なし」 from ITmedia (13:51)Edit

>>米カリフォルニアの控訴裁判所が、「eBayは、自社のオークションサイト上に虚偽あるいは名誉棄損の疑いのある情報が掲載されても、それを削除する義務はない」との判断を示した。

>>同裁判所は2月5日、1996年の米通信品位法(CDA)に合わせて、eBayや同様の「双方向コンピュータサービス」企業を保護する目的で制定された連邦法を引き合いに出し、フィードバックのコーナーに掲載された情報が中傷的だからだと訴えられても、eBayはその情報を無理に削除する必要はないと判断した。

アメリカの話だけど、こういう判決がでたんだそうな。インタラクティブなサービス上でのユーザー同士の争いにおけるプロバイダの責任範囲をかなり明確化する判決だな。

それにしても、“「双方向コンピュータサービス」企業を保護する目的で制定された連邦法”があるなんて、さすが日本よりも法整備が進んでいるなー。

ちなみに該当の条文は、以下だそうな。

インターネットを利用したインタラクティブなメディアの技術的な進歩、および、それらをユーザーが自らの手によってコントロールできる可能性を阻害しないための法整備ってのは、日本でも考えられていいんじゃないか。危険からユーザーを保護するための法律(不正アクセス禁止法とか個人情報保護法とか)ばかりだと、考え方がなんだか後ろ向きになりすぎる気がする。

Published At2004-02-11 00:00Updated At2004-02-11 00:00

日記
mysqldumpが固まる (13:51)Edit

2004/2/12 その2

念のため冗長に持っていたデータをすべて削除するように変更&過去のデータはすべて削除。これで何か異常が起きても手元のデータで復帰することは不可能になったけど、もう一回収集プロセスからやり直すなり、失敗したデータは「なかったことにする」なりで対処すればいいか。クリティカルなデータってわけじゃないし。ともかくこれでDBのデータサイズが半分以下まで削れたんで、DB周りの不具合(時間がかかるプロセスが原因となってロックしたり落ちたりする)が減ることでしょう。あとhttpdのプロセス数も減らしてしまった。メンテナンス性を高める&仕様変更を柔軟に実現するために、httpd主導でリスト生成・更新(というかキャッシュコントロール)を行っているんだけど、このくらいデータ量がでかくなってきたら、負荷コントロール重視で、重い処理はバックグラウンドプロセス主導で行った方がいいんだろうなー。でもblogmapなんてしょせん俺の遊びの道具を一般開放しているにすぎないから、一般開放を安定して行うために俺の遊べる余地を減らすってのは、俺にとっては本末転倒なんだよなー。


2004/2/12

今朝、毎朝行っているDBバックアッププロセスが途中で死んで、そのままサーバーの主な機能がほとんどお亡くなりになっていた。手動でmysqldumpしても死ぬってことは、DBのファイルのどこかが死んでいるのか。ちょっとまずそうな予感。

Published At2004-02-12 00:00Updated At2004-02-12 00:00

日記
オンドゥル語のこつがわかった (13:51)Edit

オンドゥル語系リンク集

なんかGoogleで「オンドゥル語」のトップになっちゃっているんで、もっと楽しいサイトへアクセスを流してみる。


2004/2/13

オンドゥル語がなんなのかは、わかる人だけわかればいいので説明は略。

日々オンドゥル語の練習をしているうちにこつがわかってきた。発音するときに「ダ」行の音を同時に発音するとかなりいい感じになる。たとえば「ほんとにうらぎったんですかー」には「どんどでぃどぅだでぃっだんでどぅだー」を、「うそだそんなことー」には「どぅどだどんだどどー」を重ね合わせてる感じで。

ただ二つの音を同時に発音するのは、オンドゥル語の達人にならないとうまくできない。日々精進(するな)。

Published At2004-02-13 00:00Updated At2004-02-13 00:00

日記
車のバッテリーがあがった (13:51)Edit

2004/2/17

昨日の夜に、新しいバッテリーをつないで10分ほど充電したら、8Vくらいから11Vくらいまで復活したんでそこでエンジン始動。その後30分くらいドライブしてなんとか12Vくらいまで復活させた。一応今朝も12V程度で維持できていた模様。でもしばらくは気を遣ってまめにのるようにしないと危険だな。まあ充電用バッテリーをいつもキープしておくようにしたから、ある程度気は楽なんだけど。

ちなみにブースターケーブルのつなぎ方は、給電元プラス、給電先プラス、給電先マイナス(バッテリーではなく車自体のグランド。エンジンの金属部分とか)、給電元マイナスって順番でいいんだっけ?


2004/2/16

今朝ムスコを保育園に送っていこうと車に乗ったら、バッテリーがあがっていた。うが。もともと電装品をつけすぎていて放っておくとバッテリーがあがりがちな車なんだけど、埼玉に引っ越してからは比較的まめに車を使っていたんで、ここ1、2年はずっと大丈夫だったのになー。バイクのバッテリーはあがりっぱなしで絶賛放置中だけど。

そういや、先週はムスコの体調がいまいちだったんで一週間まるまる保育園を休ませた(=送り迎えに車を使わなかった)し、週末の買い物も近所で済ませてしまったんで、ほぼ2週間全然車を動かしていなかったのか。あと最近寒いから、朝方はさらにバッテリーのパワーがでにくいってのもあるかも。

そろそろ車検だし、いったんあがってしまったバッテリーをそのままにしておくのもあれだから、新しいバッテリーでも買って交換するか。でもくそ寒い外で作業するのも面倒だなー。予備バッテリーを買ってきて充電してから、近所のパーツ屋で交換してもらおうかなー。

Published At2004-02-16 00:00Updated At2004-02-16 00:00

日記
タカラ、IPv6対応“糸電話”を年内発売 from ITmedia (13:51)Edit

なるほど単機能に絞って、設定はそれぞれのハードウェアに埋め込みでもっておいて、使う人のレベルではとってもお手軽に、って感じか。

このアプローチってソフトウェアでもできないかな。プライベートキーとパブリックキーを二組生成して、それぞれ互いのキーを使わないと暗号化・復号化できない二つのソフトウェアバイナリを用意して、通信レイヤーがそのキーに依存していて、そのバイナリ同士じゃないときちんと通信できないよ、って感じのもの。

ただまあソフトウェアの場合はコピーが簡単だから、この糸電話みたいな感じにはいかないだろうな。とか考え出すと、さらにハードウェアキーと連動させて、特定のマシン上でしか動かないような仕組みにして、とかありきたりのネタになってしまうな。うーん、もう一ネタ欲しいところ。

Published At2004-02-18 00:00Updated At2004-02-18 00:00

日記
ついにきましたね (13:51)Edit

こいつは確定ですかね。まだひどくはないんですが、鼻の奥が常時むずむずしてますよ。朝起きたときに目やにがついてますよ。ときどき思いがけないくしゃみがでますよ。

今年はちゃんと病院に行こうかな。病院って内科でいいの? 耳鼻科?

Published At2004-02-18 00:00Updated At2004-02-18 00:00