2004.05.25

携帯での認証の特化処理

はてなアンテナをプライベートモードでご利用の方で、携帯端末からアンテナをご覧頂く場合に、閲覧用のパスワードを設定頂いておりますが、このパスワードが「リンク元」として送信されるために、はてなダイアリーのリンク元表示でアンテナ用パスワードが閲覧可能となる問題がございました。
現在この問題は修正されておりますが(以降略)

あぁ、ありがち。

やってしまっていたのですね、GET でのパスワード送信。
携帯の場合、cookie が使えるとは限らないので、認証済み状態を維持した bookmark を可能にしようと思うと、このような設計になりがちです。この方式なら機種を選ばずうまくいきますもんねぇ。

でもやっぱり URL にパスワードをくっつけちゃだめ~。漏れ漏れです。
携帯だから一見 URL が見えにくいように思えるかもしれませんが、漏れ漏れです。

かといって機種を見て方式を変えるのもなんだかなぁ、ではあります。

今回の場合はアンテナというページ構成の特徴からして、リンクを全部リダイレクタ経由にするという手が考えられますが、プライベートモードの時だけそうするのもやっぱりなんだかなぁという気もします。
あぁ、でもプライベートモードのアンテナ URL が referrer で飛んでも嬉しくないからやっぱりプライベートモードの時だけリダイレクタ経由という方法でもいいか…。どうやって対処されたのかはしらないですけど^^;。

cookie の使えない機種は見捨てるという手もあり。端末IDが見れるやつとかはそれも可だけど…それって結局機種を見て方式を変えてるってことやん^^;。

まぁ、何にせよ URL に秘密情報を含ませてはいけませんってことで~。

| | Comments (9) | TrackBack (0)

2004.05.22

Winny はレアな電子コンテンツの保存に役立ったのか?

あぁ、あんまり考えてない…ただ数日前に書きかけたしちょっとだけ言いたかったので無責任に出してみるだけです_o_。あんまりにもピント外れだったら叩くなり無視するなりしてくださいってことで。

切込隊長BLOG ~俺様キングダム: パブリックP2P

にて、レアな(たとえば廃版になった)コンテンツを入手する手段となった、という Winny その他の P2P ものの功が主張されています。当初から P2P に期待されていた点の一つであり、その効果はなかったわけではないと思う、あるいは再販制度などが整備されていない現状においては少なくない効果があったと言えると思うのですが、しかしそれでも事実としてはそんなことは(あまり)無いのではないかと思ったりします。少なくとも Winny がその視点における最適解ではなかった、と。
こう思う根拠としては、既に指摘されている、Winny などの P2P ものの検索性の悪さです。

レアな情報がほしいと言ってもレアなら何でもいいわけではないので、ここでは隊長が例に挙げているように欲しいものが既に分かっているケースで、且つ一度でも public な状態にあったコンテンツに限定してみます。というか、そうでないものは P2P 以外の手段の方が見つかるように思いますし。Winny だとそのタイトルなりを入力して待っていれば、どこかのノードで公開されていることが分かればそれが入手できるんでしょう。実は昔一度試しに起動してみただけなので詳しくは知らないんだけど-_-。

さて、本当に欲しかったものが見つかるでしょうか?隊長は見つかったそうです。よかった。でも、隊長の例にあるくらいのレア度になると、実は放流されている可能性はかなり低いのではないかと推測します。そもそも放流されていない可能性もある上に、たとえどこかに存在したとしても、query がそこに到達しない可能性も高いのではないかと思います。query は winny ネットワーク上のすべてのノードに届くようになっているのでしょうか?おそらく数10ホップで query は消滅するはずです。というあたりの実態について、実はだれか教えてくれたら嬉しい^^;。


ここまでは数日前に書いたんですが、この後、
切込隊長BLOG ~俺様キングダム: 拙文が批判された件ついて
という記事のコメント中に(111さんによる)興味深いご意見が出てきています。
さっとしか読めてないので全体の要約が難しいのですが、「どんなにレアであろうとも著作物はもともと著作者のものなんだから、著作者の意向を無視してユーザ同士だけでやりとりしてんなよ」ってなことです。要約しちゃうと当たり前に見えるな^^;。隊長の「賞味期限が終わったコンテンツは、書籍同様パブリックになるべき」と共に(一見相反するように見えるかもしれないが)共感できるわけです。

念のために書くと、前者はユーザに著作者の意向を無視するなと言っていて、後者は著作者にできるだけ著作をパブリックに、と言っています。

111さんは主張の中で「中間詐取者」にあたる人たちの役割についても説明されています。中間詐取者を単に擁護できるわけでもありませんが単に叩くこともできないことが解ると思いますので、長いですけど一読の価値ありと思います。

あと、関連して興味深いと思ったのは前者記事の296さんの「そもそも創作ってのは基本的に作ったら赤字になるのは世の常だろう。その赤字から物事が始まる。」という節。そうですね…。

47氏逮捕事件がきっかけとなって、なんだかんだ言って話題がいい方向に向かって行っていることを感じます。私も話題がうやむやに収束しないようにするために、とりあえずたまに話題にしようかなって気になってるし。

ところで後者記事本体を読んで、隊長って実は議論が得意というわけではないのかもなぁ、とか思ったり^^;。ここでの「議論」は相手の言わんとすることを正確に把握するという面倒な作業という意味だけど。今回のおいらの記事は単なる表面上の感想~_o_。

| | Comments (3) | TrackBack (0)

2004.05.17

今後は P2P より分散キャッシュサーバでしょ、そして低額課金+寄付

高木さんも Winny と産業音楽に関して言及。特に音楽は文化というより洗脳/中毒である、というご意見に目から鱗です^^;。

Winny のようなソフトウェアを作成すれば逮捕されます
で、ちらっと触れた内容ですが、違法性のあるファイルが多数存在したからこそ普及した、つまり人々が Winny に強い魅力を感じたわけで、合法なファイルしか流れないようにしていた場合、そもそも普及しなかったんじゃないか?と思っているわけですが、高木さんはその点について、P2P はネットワーク負荷を増大するわりには検索性が悪く不安定で、目的のものを入手するのに時間がかかるといった面も同時に指摘されています。

コンテンツ管理の面から言っても頒布の面から言っても、結局安定した一ヶ所からの供給の方がよいだろう、と今は思っています。先の記事ではコンテンツは P2P で配布し、試聴のために必要なキーに相当するものを特定サーバから得れば?と深く考えずに書いたりもしましたが、配布元の証明には使えても(これ特許ネタ^^;)違法コピーを防いだり流通革命を起こせるような策とはならないなぁと思いつつでした。今回が深く考えてるかというと、やはり書きなぐりではありますが^^;。

流通に関しては、欲しいものが解っている場合、Winny で検索して一晩待って入手するよりも、明確な供給元から高速な回線を経由してダウンロードするほうが圧倒的に速いですから。

そのようなわけで、今後は Akamai の様な分散キャッシュサーバこそ最も利用者の利便に合致し、推進されるのではないかと思います。分散したキャッシュサーバ同士のミラーリングにこそ Winny のような P2P 技術が使われればよいと。これはファイル配布に限定しています。私的ファイル交換やメッセージングのようなローカルなものは別と考えています。

実際、ベンダーのサイトから合法に楽曲などをダウンロードする場合は、現状でもそうなっていますもんね。

なぜそれを全員が利用せず、違法な方法に固執するのかと言えば、人によって違いますが(そしてそれが問題なのですが)、大まかには「楽曲がそれ自身の価値と比較して高過ぎる」「とにかくただで手に入る手段があるならそっち」の二つであろうと思います。そして後者が前者の意図を掻き消すわけです。

そうすると、直感的には正当な入手方法の障壁をめいいっぱい下げれば、皆が正当な入手方法を利用するようになりそうです。違法利用が掻き消されるほどに正当な利用、別の言い方をすればコンテンツ提供者側への感謝が示されるようになれば、47氏の思惑も達成されるでしょうし。そのためにはどうすればいいか。

無料にして寄付(感謝料/投げ銭)を募ればいいんじゃないか?というのが 47氏の考え方であり、幾人かがいろいろな分野で実践している方式です。純粋なシェアウェア(支払を強制しないもの)ですね。

しかし、こちらでも言われているような MovableType 3.0 への動きなども見て解るように、結局感謝料はコンテンツの価値に見合うほども集まらないケースがほとんどです。これは利用者のモラル次第であり、コンテンツの種類によってはこのモデルで成功しているものももちろんありますが、払おうという気にさせるのが難しいことを感じさせます。小額課金のシステム自体がまだ本当に簡便な方法が認知されていないことも大きいとは思いますが。@Pay や PayPal など決済の手間が少ないシステムはいろいろありますが、これらのサービスを利用することとのコスト対効果でコンテンツ提供者側としてはいまだ導入に躊躇している段階ではないかと思います。

だからといって、MovableType 3.0 のように急に1万円以上というのも微妙な所ですよね。

ここはなんとか簡便な小額課金システムが普及して、コンテンツ購入は100-1000円程度でできるようにし、それに加えて寄付金を募る形態が落とし所にならないだろうか?と妄想したりします。

これらのシステムができた所で違法コピーが無くなるわけではないのですが、違法コピーの取り締まりはきっちり継続することで、数百円払うか逮捕されるか、という価値判断を問うこととなり、おそらく充分な抑止力として働くように思います。やはり問題は小額課金システムが年齢を問わずに簡便に利用できるようになるかどうか、現金での決済と同様に匿名で支払うことができるか?といったところにありそうです。

| | Comments (6) | TrackBack (1)

2004.05.12

Winny のようなソフトウェアを作成すれば逮捕されます

と、煽りタイトルで行きましょう。ただし、「Winny のような」とは、「悪用が容易に想像できるのにそれを抑止する何らかの対応を考えなかった」ということです。P2P だからというわけではありません。普及したかしなかったかは実際の被害に直結するので、作者にそれが予測できるかはともかくとして、影響してしまいます。SoftEther あたりもそこをきちんと考えないと危険です。いろんな観点から何度も言っていますが、道具は使う人しだいだからといって何を作ってもいいわけじゃないんです。

なお、私は Winny 作者の理念には賛同しています。SoftEther に関しては微妙^^;。ここここに書いたように。

この話題、スルーしようと思っていたのですが、essa さんの文章に共感&興味を惹かれたので記事にしてみました(IT関係だし当然もともと興味は持っている)。あ、でも今記事書いても既に何も新しい視点はないか?^^;

理念とは、良いコンテンツを作成した人が、そのコンテンツを評価する人からその評価に見合った報酬を受け取るべきだということです。良いコンテンツを創造した人がむくわれるシステムがあれば、それにはげむ人が増えて、社会全体として創造されるコンテンツはより豊かなものになる。このことは、技術の進歩と関係なく、常に尊重されるべき立派な理念です。
:
彼が提案する代替案とは、P2Pネットワークによるコンテンツの流通と、デジタル証券システムによる対価の支払いです。彼は前者については、プログラムのレベルまで具体化して提案し、後者について概念モデルを提示しています。どちらも現行の技術で充分実現可能な提案です。

ほとんど essa さんと立ち位置が同じなんですが、幇助(厳密な幇助の定義にあたるかは微妙だけど故意に犯罪を助長した)の罪を問うのは妥当とする立場です。法律上の罪かどうかは私には判断が付きませんが直感的には逮捕に相当する罪ではないかと思っています。
携帯電話のカメラの場合、悪用が容易に想像できるため、シャッター音などの防衛策が盛り込まれましたが、Winny は悪用の可能性どころか、悪用が主体になりそうであることすら容易に想像可能なのに、作者側がそれを抑止する手立てをなんら講じていませんでしたから。そのあたりで「意思」について問われると思います。
ただ、もちろん真意は理解できまして、「毒を放たないと分からない」ってやつですね。47氏は完全に確信犯です。鳥と卵の選択をした(※)。そして、罪を被ることも辞さずに行動を起こしたんです。たとえ逮捕されてもそれによって多くの人がこの問題を考えるきっかけになるなら、くらいの気概だったのではないでしょうか。

※悪いとされることを悪いことでなくすためにまだ悪いことじゃなくなっていないのに悪いことをした。

何らかの実効性のある悪用防止策が入っていれば、罪にはならないと思いますが…そこまで詳しくは知らないです_o_。あるいは、「デジタル証券システムによる対価の支払い」のほうをもっと前面に出すことができていれば、犯罪助長の面は軽視されていたでしょう。しかしそれを認知/普及させるためには…というわけで、鳥と卵です。

罪は罪として何らかの形で償い、そして早く次の研究フェーズに移られることをお祈りします。
上記の気概から行くと、逮捕によって P2P 流通が萎縮したら 47氏の本意じゃないでしょうね。まさしく革命を起こしたかったわけだから。コンテンツキー配布/更新サービスみたいなのが構築されて、コンテンツそのものは P2P 流通とかすればいいような気がするけど。あるいは 47氏の希望は投げ銭システムか…。どうなんでしょうね…投げ銭。ビジネスまで行くかどうか…。

参考:
arai blog: 金子勇氏を支援しよう
muse-A-muse:Winny事件を受けて  ヴィント・サーフの銀河系は縮減する...のか? 他のご意見へのリンクも挙げてくださっています。

似て非なるものとして、office さんの事件がありました。私は氏の大義名分はかなり怪しいと思ってます(追記)うわっリンク間違ってました。こっちです_o_。別に人柄が嫌いとかいうわけではないけれど。本当に慎重に脆弱性調査や報告をしている方にとって、かなり害となる行動でしたから…。でも、office さんも愉快犯的側面の行きすぎはあれど、貴重な人材であるとも思いますが。

おっと、当然ながら、某雑誌なんかは当然のごとく罪を問われてしかるべきと思いますけどね。
そして、例によって、報道の論調はあほなんでしょうけどね。見てないけど。

| | Comments (6) | TrackBack (0)

2004.03.28

バッドラッパー

バッドノウハウからバッドラッパーへ - www.textfile.org より。

このようなバッドノウハウを必要とするシステムをバッドシステムと呼ぶことにします。ここではバッドシステムに対するもう一つの解決法としてグッドラッパーの反対のバッドラッパーを提案します。

共感しました。
sendmail に対する postfix なんかも(中身は知らないですが^^;)そういう感覚ではないでしょうか。

互換性は wrapper で確保。いいですねぇ。
まぁ、実際のところは、WindowsNT のようなケースはともかく、オープンソースソフトウェアの場合、新機能/内部的な信頼性などで相当にアピールできる部分がなければ、wrapper により表面のインターフェイスの互換性を保っていますと言っても、「それなら今までのでいいじゃん」となってしまう可能性があるわけですが^^;。バッドノウハウの駆逐にはかくも労力が必要であることよ…。

ちなみに、私ならレガシーな振る舞いと新しい振る舞いの両方が必要になったらさくさくとモジュール化しますね。
とにかく交換可能性を保つために、依存性の限定化が重要ですねぇ。ってそれは wrapper というアプローチとはまた違うか^^;。そう考えれば、インターフェイス部分すら(wrap ではなく)pluggable-module にするというアプローチもありますね。

| | Comments (0) | TrackBack (0)

2004.03.03

SE/コンサルタントって何だろう

要求分析」の続きです。
今回カテゴリ分けも出来ないくらいまとまりありません^^;。一応続き記事ということで「格言・思想」に入れますけど。
もうね、こんな方向までネタを持っていくと対象読者がどういう人なんだかわけわかめ状態だな^^;;。それでも一応他業種にも通じる話に持っていこうと努力はしてるつもりですが…。

現在は、ある程度の規模の開発になると分析を行った人がプロジェクトが終るまで在籍していることが少ないですが、これは相当に(それこそ日本中探しても何十人もいない程度に)「仕事」ができる人でなければプロジェクトにとって大きなマイナスであると常々思っています。

顧客から得た要求(そしてその目的)の全てに加え、分析者の知識と経験に基づく判断まで含めてすべてドキュメントとしてまとめるのは不可能です。そして、たとえそれが出来たとしてもその膨大なドキュメントを後の担当者に読ませ、理解させている時間は通常ありません。

ソフトウェア開発においても工業生産と同じような分業&作業の単純化が推進されていた時代がありましたが、もうそろそろそのやり方ではだめだと気付かれつつある…はずなんですが。

未だにソフトウェア技術者を交換可能と考えている組織は多いようです。

プログラマ一人という単位で見ても、職人変われば思想も変わるので、いなくなると元のプログラムの意図はなかなか読み取れないでしょうけれど、もっとひどい場合は、最初に顧客と接して要求を聞き出した人が実装フェーズ(実際にプログラムを書く段階)には誰一人残っていないなんていうプロジェクトもあるようです。

顧客との折衝や質問を行う担当者は前担当者の意思と知識を引き継ぐことはできず、顧客に対して既に何度もされた質問をまた行います。前担当者が残したドキュメントは新担当者のドキュメントと重複が多くなり、且つ微妙に異なっているため、それを読まされる設計/実装担当者は混乱するだけでなく、幾度となく繰り返される徒労に飽き飽きしてますますドキュメントを読まなくなります。

規約で縛ろうとしても無理でしょう。

どうすればよいか?

各自の責任感を最大限に引き出せるプロジェクト体制にすることです
要求を聞いた人は顧客に変わって、或いは顧客も引っ張り出して設計のレビューに参加すべきです。
設計を行った人は(実装担当のスキルによっては)ソースレビューまで参加すべきです。
もっともよいのは、分析/設計/実装を同一人物が行うことです:p。
人数が多いプロジェクトであれば、最高の分析技術者を据えて、その人に最後まで面倒を見てもらうことです。
知識/ノウハウの伝達ができればよいですが、それすら難しいし、なにより能力は伝達できないからです

また、プロジェクトメンバー全員の目的がプロジェクトの終了(完成、もっと言えば成功)であることを実感させることです
「ここに書かれた通りにプログラムを書けばいいんだよ」なんて事をやっていたら手抜きされます。あるいは「そこに書かれたこと」の不備に業を煮やしたプログラマは逃げだします。

ところで、世の中には SE なる職種が存在するそうです。System Engineer だそうで。
私の名刺にも System Engineer って書いてるような気もしますが、うちの場合肩書きに何書いてもいいので「育児担当」でもよかったのです。

世の中的には要求分析から設計あたりまでを担当する人、らしいです。
プログラムを組めないのに SE という職種を目指す人がいたりするそうです。不思議なことに。
本質的にプログラミングというのは一人で最初から最後までできる人間がやることです。

まぁ、逆にプログラマーという職種を作業員と勘違いしている上役(或いはプログラマー本人)もいるようですが-_-。

追伸
コンサルタントという職種も SE と同じ怪しさがありますが、こちらはより「提案」や「人(の配備など)」に重きを置いていたりするので、さすがに要求されるセンスが違います。でも、自分でやってみたら大変かもしれないことを平気で提案してしまうなんちゃってコンサルが多いですね。

| | Comments (6) | TrackBack (0)

2004.03.02

人気ページ一覧/リンク元一覧表示機能 Version0.2

というわけで、改修いたしました。

version 0.2 のダウンロード(新しいバージョンがある場合はトラックバックにて辿れます)

概要は
人気ページ一覧/リンク元一覧表示機能公開
なんですが、今回は README を真面目に書いたのでここでは変更点のみ。

2004-03-03 version 0.2

* オーナーによるアクセスをカウントしない設定を可能にした
* リンク元リストの出力形態を選択可能にした
* フィルタリング設定を変えた場合に、古いログに現在のフィルタを適用できるようにした
* マイナーバグ修正


ふぅ。これでしばらく弄ることも無いかなっと。後はフィルタ調整程度だからリリースするまでもないし。

(追記)
おっとそういえばログが肥大化した時に備えて差分集計はできるようにしとかないとだった。
ま、しばらくは大丈夫だな^^;。

(追記)
結局この後結構いじくった…。くそぅ perl めっ変数関連の仕様が気持ち悪過ぎなんだよっ…-_-。

| | Comments (2) | TrackBack (2)

2004.03.01

人気ページ一覧/リンク元一覧表示機能公開

改名しました^^;
現在このサイトに設置しているような、「人気ページ一覧/リンク元一覧」を任意のサイトに適用できるソフトウェアの version 0.1 を公開します。

Version 0.1 のダウンロード(新しいバージョンがある場合はトラックバックにて辿れます)
注意:ココログ以外に CGI を設置できる web スペースが必要です。

特徴

現状の特徴は、以下です。

  1. ページ側への埋めこみが楽。
  2. カウントから除外するコードを簡単に追加可能。
  3. 同一視するページを指定可能。
    • 例えば、http://shin.txt-nifty.com/ と http://shin.txt-nifty.com/philosophical/ を同一視。
    • URL への "index.html" の有無などについても同一視が可能。
  4. リンク元ランキングについては一つのスクリプトでリアルタイム反映。
  5. リンク元ランキングを任意の箇所に埋めこみ可能。記事に埋めこめば、トップページの各記事毎に「この記事へのリンク元」を設置可能。
  6. サイト内アクセスランキングについては記録/集計を分けている。ランキング表示は軽い。
  7. リスティングする最大件数の指定が可能。
  8. 集計は密かに web からキック可能^^;。


まぁ、自分の欲しい機能が優先されているので、検索キーワードの表示などは対応していませんが(リンク元にリスティングされた検索エンジンからの URL をクリックすれば見れるし)、逆に、検索以外からの訪問者、つまり「読者」や、他のサイトからのご紹介などのカウントが見えるようになっています。


アーカイブ内容

ダウンロードして展開すると、以下の構造になります。

ディレクトリ属性用途
cgi
+-data777ログ置き場(ディレクトリ)
+-ref.pl644設定と実処理
+-refer_s.cgi755記録処理(兼リンク元一覧の表示)
+-show_referrer.cgi755このページへのリンク元一覧の表示(テスト/iframe 用)
+-show_referrer_s.cgi755このページへのリンク元一覧の表示(JavaScript 版)
+-show_statistics.cgi755人気ページ一覧の表示(テスト/iframe 用)
+-show_statistics_s.cgi755人気ページ一覧の表示(JavaScript 版)
+-update_statistics.cgi755人気ページ一覧の更新
README_sjis.txtたいしたことは書いてません:p
refer.js記録処理呼び出し用ヘルパー


設置方法

1. 設定の編集

ref.pl を編集します。テキストエディッタで開いて、以下の部分をご自身のサイトに合わせて修正してください。
以下はこのサイト用の修正例です。

# 集計対象とする URL
# この URL 配下から送られたデータしか処理しません。
my $my_url = "http://shin.txt-nifty.com/";

# 同一視する URL のリスト
# 左の URL へのリクエストは右の URL へのものとみなします。
# 完全マッチなので補正しそこねることもあるかもしれません。
my %equals = (
'http://shin.txt-nifty.com/', 'http://shin.txt-nifty.com/philosophical/',
);


2. CGI のアップロード

cgi ディレクトリ配下を丸ごと Web サーバの CGI 実行可能なディレクトリにアップロードしてください。
そして、各ファイルの属性を上記に示したように変更してください。

refer.js は、ココログ上でも別の Web サーバ上でも構いませんので、URL で参照可能な場所にアップロードしてください。
アップロードせずに、ここに設置したものの URL(=http://shin.txt-nifty.com/philosophical/refer.js) をそのまま参照しても構わないかと思います。


3. サイト側の設定

3-1. Web ページへ記録処理の設置

ココログの方は 3-4 へ進んでください。
以下のような行を任意の箇所に追加します。

<script type="text/javascript" src="http://shin.txt-nifty.com/philosophical/refer.js"></script>
<script type="text/javascript">refer("{CGIを設置したサイト}/cgi-bin/refer_s.cgi");</script>

サイト内のあらゆるページで表示される箇所(サイドバーなど)、あるいは、集計対象としたい各ページ上に記述を追加します。
リンク元ランキングを表示しますが、記録を兼ねているので同一ページ上に複数回この記述が現れないようにご注意ください。


3-2. 人気ページ一覧の表示処理

とりあえずは、飛ばしても構いません。
「人気ページ一覧」を表示するなら、サイト内のあらゆるページで表示される箇所(サイドバーなど)、あるいは、表示対象としたい各ページ上に以下の記述を追加します。

<script type="text/javascript" src="{CGIを設置したサイト}/cgi-bin/show_statistics_s.cgi"></script>

注意:UTF-8 以外の Web サイトへの設置に関して
上記の script による人気ページ一覧表示では、Web サイトが UTF-8 なページでなければ正常に動作しません。
UTF-8 以外のページに「人気ページ一覧」を表示したい場合は代わりに以下のような iframe の指定を追加してください。

<iframe frameborder="no" width="100%" height="120" src="{CGIを設置したサイト}/cgi-bin/show_statistics.cgi"></iframe>


3-3. リンク元一覧の表示処理の追加

飛ばしても構いません。
もし、一ページ中に複数のリンク元一覧を表示したい場合(blog 記事本文に埋めこみたい場合など)は、blog 記事中に以下の記述を追加してください。

<script type="text/javascript" src="{CGIを設置したサイト}/cgi-bin/show_referrer_s.cgi?リンク元を表示したいページのURL"></script>

blog の場合、記録処理をサイドバーに記述して、記事中にここに書いた記述を行うことで、トップページやバックナンバー表示時に記事毎にリンク元一覧を表示することができます。この記事でも実験的に埋めこんでいます。


3-4. ココログの場合の設置方法

上記の記録処理/一覧表示処理をココログに設置する場合の具体例です。

まず、タイプが「リンク」であるマイリストの作成を行います。
マイリストの設定で、「メモの表示」を「テキスト表示」に設定します。
ダミーの URL を記述して新しいリンクを作成し、「メモ」欄に以下のような記述を追加します。

<h2>人気ページ一覧</h2>
<script type="text/javascript" src="{CGIを設置したサイト}/cgi-bin/show_statistics_s.cgi"></script>
<h2>このページへのリンク元</h2>
<script type="text/javascript" src="http://shin.txt-nifty.com/philosophical/refer.js"></script>
<script type="text/javascript">refer("{CGIを設置したサイト}/cgi-bin/refer_s.cgi");</script>

マイリストをサイドバーに表示するように設定します。


4. 「人気ページ一覧」の更新

「人気ページ一覧」を表示しない人には無関係です。
「人気ページ一覧」はアクセスログを定期的に集計して生成しています。
「人気ページ一覧」の更新は、update_statistics.cgi を起動することで実行できます。
cron を設定するのがよいです。

私は以下のような crontab ファイルを作成して、

1,31 * * * * cd /path/to/cgi/dir;./update_statistics.cgi

crontab ファイル名

で登録しています。上記は30分おきに実行という意味です。

また、ブラウザから http://サーバ/cgi-bin/update_statistics.cgi?dummy
のようにダミーパラメタを付加した URL を叩くと手動更新ができます。


以上で設置は完了です。以下はおまけです。


スタイルの調整

リンク元一覧には class="referrer-list" が指定されています。
人気ページ一覧には id="statistics" が指定されています。
内部の A 要素のスタイルの方が優先されてしまいますが、これを元に多少の調整が可能です。
この辺は後のバージョンで改修するかもしれませんけど。


除外するアクセスなどのカスタマイズ

ref.pl の最後の方に、
need_recording_access
need_recording_ref
normalize
といった関数があります。これらを修正すると、人気ページ一覧/リンク元一覧にリスティングする URL を調整できます。
今はかなり説明不足な気もしますが、わかりにくい点がありましたらご質問くださいませ_o_。


注意点/問題点

JavaScript がオフになっているクライアントのアクセスは集計されません。
そのクライアントには表示もされません。
SSI などが利用できない環境に導入できることを優先しているため、SSI 版は今のところ対応予定はありません。


将来

とりあえず、集計から除外すべき物をブラッシュアップします。自分によるアクセスを完全に除外するようにしようかと。
その後は一つのシステムで複数サイトの面倒を見れるようにしようかな…。


謝辞

JavaScript での UTF-8 エンコードには、JavaScriptにおけるURLエンコードの処理のコードを使わせていただきました_o_。


その他

perl なんて嫌いなんですが、配布(特にココログユーザ)を念頭に置くと perl で書くしかなかったので perl です。
perl なコードは怪しい所があるかもしれませんです。変数のスコープもよく知らないで書いてるし^^;。
というわけで perl 慣れしていないコードです。ツッコミありましたらよろしくお願いいたします_o_。
設定を一ヶ所にまとめたかったから、ref.pl にほぼ全ての処理を突っ込むことになってしまった…。require した先の変数も取り込めるんでしょうか?>識者
はっ!!…設定取得関数化すれば間違いなくうまくいくか…でも無駄に長くなるな…。

| | Comments (0) | TrackBack (3)

サイト内アクセスランキング/ページ毎のリンク元ランキング

前から付けたいなぁ作ろうかなぁとか思っていた機能を作りました。
で、さっそく公開しようと思ってましたが、もう少し様子を見てからの方がよさそうなので、とりあえずご報告のみ_o_。
たまにいじくってて表示が出ないとかあるかもしれません。

現状の特徴は、以下です。

  • 日記に限らずあらゆるサイトに設置できる。
    ココログを始めとする CGI が使えないサイトのランキングも表示可能。
  • カウントから除外するアクセスを簡単に追加可能。
  • 同一視するページを指定可能。
    • 例えば、http://shin.txt-nifty.com/ と http://shin.txt-nifty.com/philosophical/ を同一視。
    • URL への "index.html" の有無などについても同一視が可能。
  • リンク元ランキングについては一つのスクリプトでリアルタイム反映。
  • リンク元ランキングを任意の箇所に埋めこみ可能。記事に埋めこめば、トップページの各記事毎に「この記事へのリンク元」を設置可能」(自分はやる気無いからテストしてないけど)。
  • サイト内アクセスランキングについては記録/集計を分けている。ランキング表示は軽い。
  • リスティングする最大件数の指定が可能。
  • 定期的な集計は、密かに web からキック可能^^;。

まぁ、自分の欲しい機能が優先されているので、検索キーワードの表示などは対応していませんが(リンク元にリスティングされた検索エンジンからの URL をクリックすれば見れるし)、逆に、検索以外からの訪問者、つまり「読者」や、他のサイトからのご紹介などのカウントが見えるようになっています。ついでにもともと「リンク元ランキング機能」で言われていた副作用である「リンク元サイトの人気ランキング」にもなってしまう可能性はあります。

制限は以下です。

JavaScript がオフになっているクライアントのアクセスは集計されません。
そのクライアントには表示もされません。


今後は、とりあえず、集計から除外すべき物をブラッシュアップします。
自分によるアクセスを完全に除外する、とか。
で、他所のページでも使えることを確認したら公開しようかと。


同様の機能は観測気球さんが実現していらっしゃいます。
もちろんココログ以外では他にもたくさんいらっしゃいます。

私はとにかく統計を取る際のカスタマイズ性が欲しかったので自作した、という所です。
検索経由のカウントは(おそらくは読者にとっても)見ても嬉しくない、ということで^^;。

公開前にバグや要望などコメントいただけますと、皆が嬉しい可能性があります^^;。

| | Comments (6) | TrackBack (2)

2004.02.25

名寄せを利用したプライバシー侵害の手法:個人Webサイトからの追跡

今回も長くなったことと、新たな視点だと思ったので書き起こします。
技術系サラリーマンの交差点: メールからIPアドレスがわかることも多いらしい

元記事で、POP と言われているのは SMTP のことですね。
メイル送信時の IP アドレスですが、SMTP サーバというものが受信した時点で送信元のアドレスを Received として付与します。
このアドレスは基本的に詐称できません。

ブラウザから送信するタイプのメイラでも端末の IP アドレスは大抵(独自)メッセージヘッダに記載されます。Hotmail も Yahoo も送信元 IP はわかります。

過去はダイヤルアップ接続がメインであり、接続のたびに IP アドレスが変化していたため、せいぜいプロバイダと地域までしか解りませんでしたが、現在の ADSL などの固定IPアドレスの世の中になると IPアドレスと個人の結びつきが強くなる、という件は実際に危惧されてもいます。
IPv6 に関しても真っ先にこの点が議論されていますし。

でも、ダイヤルアップであってもプロバイダが調査すれば送信*者*の特定は可能です。そうでなければ犯罪天国になってしまいます。完全匿名を許したらインターネット社会が成り立たなくなります。2ch が後になってログを記録するように変えさせられた通り。

一般的には端末のIPアドレスが一定以下の間隔で変化すれば充分とされており、ADSL などは怪しいですが、逆に企業内からなどの場合は、並列化された中継(HTTP/SMTP)サーバが利用されたりするので、どの企業かは分かってもその中の誰かは外部からは突き止めるのが困難です。

メイルを送信した端末のIPと HTTP アクセス時の proxy サーバが付与する端末の IP を突き合わせれば、企業内からであってもメイル送信者と Web アクセス者が同一であるかを推定することができます。でも、企業の proxy サーバでは内部の端末のIPは送出しないことが多いと思いますが。
(追記)この段落、若干編集しています。

でもまぁ、これを気にする方は、もう Web で見つけた人とのやりとりはやめるしかないでしょうね。


ところで、Web バグ(参考1)というものが存在します。電子メイル送信相手に気付かれないようにWebにアクセスさせる事で、送信先メイルアドレスとIPアドレス、およびクライアントパソコンを識別するID(cookie による)を紐付けすることができます。HTML メイルから参照される画像が自動的に表示される環境では、プレビューするだけで実行されます。

Web バグでは、それが生きているメイルアドレスか?そこから辿って商品を購入したか?ある消費活動を行った人のメイルアドレスは?といった事が収集されます。

今回の話はマーケティングという側面ではなく、個人間のやりとりに関する話ですが、上記から言えることは、メイルアドレスを知っている人間の自サイトでの活動を追跡しようと思えば、その相手からのアクションを待たずとも可能である、ということです。しかも IP アドレスよりも確実な cookie に設置した ID によって。
cookie をオフにしていてもクライアント IP アドレスは採取されます。
さらにこれに「名寄せ」を加えれば、住所氏名などの個人情報まで結びつく可能性もあります。これは業者の協力が必要でしょうけれど。

こちらも回避しようと思うならば、そういう事をする可能性のある Web サイトを見てはいけません、ということになるでしょう。
HTML メイル、あるいはそこからリンクされる画像などを表示する設定をやめる事で、無意識のうちに追跡される可能性は減らすことができますが。

結局、好奇心とリスクのトレードオフで、各自が判断するしかないわけですが。
念のためですが、私は Web 閲覧行動に関してリスクはあまり感じていません^^;。
でも、人によっては(特に女性)リアルワールドにも影響を及ぼすようなリスクも考えられないわけではありません。
やはり、好奇心、というよりサイト管理者への信用でしょうかね。

参考1:はてなダイアリー - 高木浩光@茨城県つくば市 の日記:Webバグについて復習する
参考2:EarlGrey Tearoom: HTMLメールは、IPアドレスを通知する

| | Comments (6) | TrackBack (1)