_ /.J「日本政府，絵を含む国連の児童ポルノ禁止議定書に署名」−「歓迎する職種もあるということで。」

これは全然仕事の話なんですけど、うちの社では、他社でウケのいい漫画家が
出てくると、短編集なんかで単行本が出たときに、下着はもとより、Ｔシャツ
デザインで破けているＧパンなんかをキャラが着ていたりするシーンを
なんとか探し出して、
　「セックスをした後をイメージする」
　「強姦をイメージさせる」
と、東京都に意見書を出して、成年マークを付けさせる指導を要求します。
少年漫画や少女漫画なんかでも、漫画家や編集部がじたばたする事はありますが、
３通くらい出せば、ほとんどの場合、その本を発禁処分にでき、漫画家本人を
つぶすことが出来ます。

なんかすごくありそう（そういうことをやる出版社も、そういう意見書を無批判に受け取って対応する行政も）でイヤな話だな。でも行政がチェックをまじめにやっているとも（やる能力があるとも）思えないし、そういう意見書を出す出版社を止めることもできないよなー。いや、そういう意見書をすべて公開制にすれば、乱発の抑止力になるかな。

_ アップロードにのみ認証があるWinny (13:51)

すでにどこかででているかもしれないけど、アップロードにのみ認証があるWinnyライクなP2Pシステムってのはどうだろう。

認証サーバーで登録しないと、アップロードできない。また、認証サーバーに登録することによって、認証サーバー上で各ファイルごとの正式なハッシュコードが管理・検索可能になる。その認証サーバー上に登録された情報を使って、性善説的な課金システムを構築することも可能だろう。

性善説的な課金システムというのは、具体的には機能制限がないシェアウェアのたぐいをイメージしてほしい。P2Pシステム上からコンテンツを自由にダウンロードできる。利用者は好きなものを好きなように利用できる。コンテンツにはユニークなハッシュコードが付与されている。そのコンテンツがとても気に入った場合、利用者は認証サーバーにアクセスし、そのコンテンツ（ハッシュコード）に課金を支払うことができる。

P2Pでの自由な流通システムと、認証サーバーに登録された正規のコンテンツ以外を流通させない制限とを、ほどよく両立させるのは難しそうだけど、チェックをある程度緩くしてやれば、認証サーバーへの負荷集中をそれなりに抑えつつ、それなりに何とか回らないかな。あるいはチェック用のデータ自体もP2Pシステム上に流すか。

もちろん、本格的にコンテンツホルダーが参入してきた場合は、著作権保護機能付きのコンテンツを流す足回りとして上記P2Pシステムを使ってもいいだろう。同じくハッシュコードを使った課金システム上で、そのコンテンツの利用料金の支払い＆認証を行えばいい。

ただ、前述したような利用制限がないコンテンツと、利用制限付きのコンテンツとは、P2Pシステム上で区別した方がいいかも。たぶんP2Pシステム上での流通パターンが違うだろうから。

と思いつきを垂れ流しておこう。

_ だいぶ軽くなったかな (13:42)

• Apacheのモジュール一覧を見直し、だいぶいらないモジュールを削減した（静的組み込みにはしてないけど）→気休め程度
• 重い検索（テーブルロックがかかるやつ）専用MySQLプロセスを別に立てていたのをやめ、MySQLプロセスを1個にした→やっぱこれが重かったよね
• その代わり、slow_logから抜き出した重い検索処理は、実行前にexplainでその重さを（簡単に言うと各検索条件ごとのrowsの多さ）をチェックし、ある程度以上重い検索と予想される場合は、実行をキャンセルするようにした→これで1プロセスですべての検索を処理しても、テーブルロックされる時間が短くなった
• httpdのログをweeklyでローテートしていたんだけど、その日本語検索キーワード解析処理とかがめちゃめちゃ重かったんで、httpdのログはdailyでローテートするようにした→これは定期的にスラッシング気味になる原因だったっぽい
• MySQL、Apacheのパラメータを状況に合わせて微調整→そんなに意味はない

って感じ。

_ 追加質問に対する答え (17:54)

追加で質問したメールに対する答えが来た（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、具体的な攻撃手段の有無による脆弱性判断については、個々の事例毎に判断しております。

また、脆弱性関連情報の届出に関するお問い合わせは、以下のメールアドレスで承りますので、今後は、こちらまでお願いいたします。

脆弱性関連情報の届出に関するお問い合わせ窓口

vuln-inq@ipa.go.jp

以上、よろしくお願いいたします。

ということで、要は場合によっては「具体的な攻撃手段」が存在しない場合も「脆弱性」と判断する場合がある、ってことですね。そのポリシー自体はまっとうだ。具体的な攻撃手段が存在しなくても、総合的な危険度が高い危険性ってのは存在しうるし。で、今回のMTの件は、「具体的な攻撃手段」が存在しなくても「脆弱性」と判断するレベルだと、総合的に判断されたってことになるんだろう。

さらに粘着質問するならば、

• IDとパスワードのハッシュを長期間（10年間）有効な認証Cookieとして保存する

だけでも「脆弱性」となってしまうのか、それとも

• そのIDとパスワード（のハッシュ）が他の認証付きインターフェース（Atom APIなど）でそのまま利用できる

との組み合わせが同時に成立した場合のみ「脆弱性」と認定されるのか、とか聞いてみたい気もするけど、単なる技術上の仮定条件だけでは、また「個々の事例ごとに判断している」という答えになっちゃうんだろう。

というわけで、今回のMTの件が「脆弱性」と判断された具体的なポイントはよくわからなかったけれども、ひとまず自分が関係するWebアプリケーションが「脆弱性」認定されてしまわないように、思い当たるふしがある方々は早めに対処しておいた方がいいでしょう。

もしさらにつっこんで聞いてみたい人がいた場合は、上記引用部にあるメールアドレスがその手の受付窓口らしいんで、そちらに問い合わせてみるといいんじゃないでしょうか。結構レスポンスがいいんで、聞いてみる価値はありそうです。