日記
匿名性を保持したアクセス認証のニーズ 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