いしなお! - 個人サイトの分類と定義

2002|01|02|03|04|05|06|07|08|11|12|

2003|01|02|03|04|05|06|07|08|09|10|11|12|

2004|01|02|03|04|05|06|07|08|09|10|11|12|

2005|01|02|03|04|05|06|07|08|09|10|11|12|

2006|01|02|03|04|05|06|07|08|09|10|11|12|

2007|01|02|03|04|05|06|07|08|09|10|11|12|

2008|02|03|04|07|

2003-12-19 [長年日記]

_ 個人サイトの分類と定義

「ウェブログ・ハンドブック」と「儀礼的無関心」ネタあたりにインスパイアされたのか、今までにも何度かやった記憶のあるメタ定義ネタを久しぶりにやってみたくなった。過去ログ（http://ishinao.net/ruins/）を漁るとかつて行った同様のネタは見つかるかと思うが、下手に読むとそちらに引きずられそうなんで、現時点の脳みそのみを使って新規に書いてみよう。思いつきをだらだら並べていくんで、この記事は時間とともに編集されていきます。

想定する読者層

少数の（オフラインでの）知り合い
- 家族
- 友達
- グループ（趣味、仕事）
少数の（オンラインでの）読者
- 常連
  - ※比較的好意的な少数の読者を暗黙のうちに想定している
- 主に内輪（所属するコミュニティなど）向け
  - ※第三者が読んでも分かりにくい内容や、個人サイト管理者同士のサイトを使った会話など、表現方法による敷居
- 何となく
  - ※不特定の多くの第三者に読まれることをあまり考えていない
- 特定の相手向け公開私信（たまたまWebというメディアを使っているので、第三者も読めるもの）
- 基本的に私信なのだが、第三者に見られることも目的とする
多くない人数の読者
- ※まったくの第三者読者の存在も想定している
非常に多くの読者
- ※まったくの第三者が読むことを主として意識している

Webサイトというメディアを使う利点

情報伝達手段としての利点
- 不特定少数あてのメッセージを伝えやすい
- 不特定多数あてのメッセージを伝えやすい
- 特定多数あてのメッセージを伝えやすい
- ※特定少数あてのメッセージならば、他に有用な手段がある
閲覧する側に情報受信の選択権がある
公開相手を限定しない
- 新しい相手に同じ情報伝える際の手間が省ける
- ※メールなどだと再送しなければならなかったり
ログの蓄積がしやすい
- 固定URLを使ったログ保存スタイルによって、蓄積された話題の個別記事の特定が可能
- 検索機能や日付によるインデックスによって、過去の記事を見つけだすことが容易

アクセスコントロールについて

基本的には、コントロールなし
- サイトにアップロードしたら無制限の公開
- サイトから削除したら非公開
  - ただし、一度公開された情報は第三者（ロボット含む）によって公開されうる
  - 著作権によって法的に非公開権を制御可能なはずだが、現実的には個人で非公開権を徹底するのは難しいだろう
システム的な問題
- 大量アクセスによるサーバー過負荷
- データ転送量制限によるアクセス拒否
- その他、システム（サーバー、プロバイダー）管理者による制御
サーバー設定（主にBasic認証）による制御
- 制御キー
  - IPアドレス
  - ホスト名
  - 独自のID、パスワード認証
  - ※がんばればDB連携を使って複数サイトをまたがった認証も可能かも。個人サイトレベルでは現実的ではないが。
- その機能が利用できるサーバーである必要がある
- 設定方法を理解できる（調べることが出来る）技術的な能力が必要
- 設定のメンテナンス性が良くない
アクセスコントロールを持つ専用システムを利用する
- はてなダイアリー（http://d.hatena.ne.jp/）
  - はてな登録ユーザーIDを利用したアクセス制御
  - 設定はWeb上から比較的簡単に行うことが出来る
  - 比較的細かい要望が通りやすいので、具体的な提案があれば言ってみるとさらに柔軟性が増すかも
- DI:DO（http://www.di-do.net/）
  - DI:DO登録ユーザーを利用したアクセス制御が可能
  - 設定はWeb上から比較的簡単に行うことが出来る
  - 記事ごとにアクセスレベル（一般公開記事と特定ユーザー向け）を変更することが出来る
  - シンプルなCookie認証なのでセキュリティ的には厳密ではない（アクセス制御の部分は悪意のある攻撃に弱いが、管理系の重要な機能はきちんと保護されている）
  - 関連する話題
    - http://www.di-do.net/cgi-bin/kera_ma_go/index.cgi?200312a#1071421955000
    - http://www.di-do.net/cgi-bin/di_do/index.cgi?200312a#1070975871000
- ほかに特筆すべき認証機能を持ったシステムは？
HNS（http://www.h14m.org/）
- RURIコードとグループ設定を使ったアクセス制御
  - RURIコードとは、ユーザー（ブラウザ）ごとに永続Cookieとして記録されるランダムユニークID。
  - ユーザーID（＋パスワード）ではなく、あるアクセスを行ったブラウザに割り振られたユニークIDを利用することによって、匿名のユーザーを特定することが可能
  - 実際には、アクセス履歴などから特定のユーザー（たとえば自分自身や知り合い）の持つRURIコードを特定し、そのRURIコードに対してアクセス権限（グループ設定、管理者設定）を付与する
  - 管理者設定されたRURIコードを持つユーザー（ブラウザ）は、各種管理者機能にアクセスすることが出来る（ログインが不要）
  - 記事ごとに対象グループを設定することができ、その記事は対象グループに含まれるRURIコードを持つユーザー（ブラウザ）がアクセスしたときのみ表示される
  - セキュリティ的にはかなり厳密に作られている（XSS関連の洗い出しが行われ済み）
  - 設定は面倒（必要スキルはかなり高めに設定されているし、上記のような仕様の理解にも技術的な素養が必要）