Trackback のなりすましやスパム、あるいは無差別発信について最近考えています。メールの Sender Policy Framework のように、送信する側と受信する側の Trackback に対するポリシーを Auto-Discovery などのメタデータに記述して、Blog ツールやホスティングツールで協調していけるとよいのではないかなーと。
事例としては、CNET Japan の Trackback は、送信元IP とURLのマッチングを見ているし、はてなダイアリーキーワードの Trackback は、キーワードへのリンクがないと受け付けない、といったものがありますね。これをメタデータやAPIなどで、Trackback の規格に組み込んでいけないかな、という流れになります。もちろん、フィードバックウェルカムです。
以下、MODULE.JP の oyama さんと IM したメモ。（編集メンドウなのでほぼママ。途中までがメタデータの話、後半は Typekey が使えないかという技術的な考察でちょっと脱線気味）
miyagawa_edge: なんかTrackbackの
miyagawa_edge: ポリシーみたいのをAuto-DiscoveryのRDFに記述できないかな
miyagawa_edge: と、最近考えてるのですが
hiroyuki_oyama: ほほぅ？どんなポリシー？
miyagawa_edge: 目的は、なりすましTBの防止と
miyagawa_edge: リンクなしTBの防止というか許可というか
hiroyuki_oyama: おお、なるほど。
miyagawa_edge: trackbacking_origin_host="app.cocolog-nifty.com"
miyagawa_edge: trackback:accept_ping_without_link="no"
miyagawa_edge: とかなんとか
hiroyuki_oyama: 後者は良いとして、前者が困るね。
miyagawa_edge: 後者はBlogの設定であるべきなのかもしれないけど
hiroyuki_oyama: うん(w
miyagawa_edge: ツール側で、相手先のRDFチェックして、
miyagawa_edge: 送らないようにするのはあってもよいのかなあとか
hiroyuki_oyama: なるほろ
miyagawa_edge: とくに
hiroyuki_oyama: mod_proxyで(何故！
miyagawa_edge: ホスティングに関しては。
miyagawa_edge: Bulkfeedsで検索して、TB URLコピーして
miyagawa_edge: ホスティングツールから送ってる人とかいるとおもうんだけど
miyagawa_edge: Blog のISPで協調してそういうの不許可にするのはいいかもしんない
miyagawa_edge: 不許可っていうか、allow してるBlogだけに送るようにするってかんじか
hiroyuki_oyama: ふむ、そもそも「TBはオンラインのWeblogツール自身が発するべきである」という思想はアリにも思える。
hiroyuki_oyama: TB発射台絶滅。
miyagawa_edge: うむ
miyagawa_edge: origin_hostは問題あるけど
miyagawa_edge: 詐称防ぐのこれしかないぽ
hiroyuki_oyama: そうだよねぇ。
hiroyuki_oyama: でも、キャンペーンというか、「〜等SPAM問題の背景から、トラックバック発信元とリンク先が一致しない場合は拒絶しましょう」をブームにできたらちょっと幸せかもなぁ。
miyagawa_edge: ただ、その場合
miyagawa_edge: blosxomとかectoとかでクライアントから送ってるひとと
miyagawa_edge: app.cocolog-nifty.com みたいに
miyagawa_edge: コンテンツサーバとアプサーバがわかれてる場合に問題になるんで
miyagawa_edge: それをんーとリンク先のRDFに書いておくの
miyagawa_edge: 受信したときの動作が緩慢になっちゃうけど。。。
hiroyuki_oyama: 後者はドメイン名までのマッチで対応可能だよね。ectoは辛いナァア。
miyagawa_edge: 受信側のBlogで Trackback Policy をチェックするオプションがあればいいかな
miyagawa_edge: そうすね、ectoとかでクライアントIPをどうみるか、か
miyagawa_edge: 動的だと死ねるな
hiroyuki_oyama: X-Trackback-Policy: xxxxxxxxxx
hiroyuki_oyama: HTTPで(嫌
miyagawa_edge: ectoとかでポストするときに、
miyagawa_edge: クライアントマシンのIP取得して、コンテンツにRDFで埋め込む？
miyagawa_edge: やかもしんないなぁ。
miyagawa_edge: プロバイダのIPアドレスのレンジでもいいんだろうけど敷居たかいか
hiroyuki_oyama: アーソレ効かない。
hiroyuki_oyama: かも。
hiroyuki_oyama: むしろTypeKey利用を促す理由にしちゃうのは？
miyagawa_edge: TrackbackのパラメータにTypeKey認証をかます？
hiroyuki_oyama: ectoとかの場合は、typekeyで認証したらTB許可とか。
miyagawa_edge: ふむふむ
miyagawa_edge: TypeKey側からとばしてやるAPIみたいのがいるかな
hiroyuki_oyama: 基本はホスト名のマッチング。それに失敗したらTypeKey。
hiroyuki_oyama: うむむ
hiroyuki_oyama: TBだよね。どういううごきになるんだろ。
miyagawa_edge: TBのパラメータにTypeKeyのシグニチャをくっつける感じですよね？
hiroyuki_oyama: そだね。
hiroyuki_oyama: あぁ、じゃ簡単だ。
miyagawa_edge: ってことは Trackback Auto-Discovery の RDFに
miyagawa_edge: Typekey token をいれないとだめかな
hiroyuki_oyama: んー
miyagawa_edge: それか、TypeKey側で Trackback URLからマッチングするか、か
miyagawa_edge: typepad とかだとそれできないんじゃないかな
miyagawa_edge: あれっすよね、TrackbackのメタデータにTypekey token がついている場合は
hiroyuki_oyama: あと、TypeKeyがそもそもget methodってのが問題か。
miyagawa_edge: TB送信元は、そのURLとTBの内容、tokenをTypekeyの TBゲートウェイに送信すると
miyagawa_edge: 自分のTypeKeyのUID,Passも設定しておいて。
hiroyuki_oyama: あ、送信元の仕事にしちゃうのか。
miyagawa_edge: そうするとTypekeyのゲートウェイ側でauthenticateして、シグニチャをオリジンのTB URLに送信してあげるって感じかしら
hiroyuki_oyama: あ
hiroyuki_oyama: ectoのTBのUser I/Fってどんなんだっけ。。。
miyagawa_edge: なぞｗ
hiroyuki_oyama: TBもさ、エラーか成功かしか判んないよね。。。。
miyagawa_edge: MTとかと一緒でURL列挙方だったような
miyagawa_edge: そうすね
hiroyuki_oyama: いやね、TBウケ側がさ、HTMLで結果を返してくれるんなら、とりあえずTB受信しておいて「さぁ、オマエはTypeKeyで認証通ってこい。そしたらメッセージを掲載してやる」という風な動きにできるなーと思ったんだ。
hiroyuki_oyama: でもXMLだったね。。。
miyagawa_edge: あーステータスに追加するという手はありますね
miyagawa_edge: 認証とおすの手動はつらいかなあ
hiroyuki_oyama: うん、それを解釈してくれれば先に進めるけど、解釈しないclientは単純に拒絶される。なんかそれでイイような気がしてきた(w
miyagawa_edge: えーとTypeKeyのAPIで、ユーザ名＋パスワード＋tokenで、シグニチャを
miyagawa_edge: ユーザ側で取得できるのか
miyagawa_edge: Location: からとるとかそんな感じになるような。。
hiroyuki_oyama: ユーザ側ってTB投げる側？
miyagawa_edge: はい
hiroyuki_oyama: うん、Tokenはわかるけど。
hiroyuki_oyama: 1. 戻りURL + TokenでTypeKeyに認証しに行く
2. 認証後、id, email. signatureが戻りURLにGETで来る。
hiroyuki_oyama: 1の戻りURLが「仮受信したTBを受け入れるぜURL」ならOKなようなきがするよ。
miyagawa_edge: なるほど
miyagawa_edge: GETで来るのは、302 Redirectですよね
miyagawa_edge: TBだとそうはいかないのでは
hiroyuki_oyama: なので、TBウケ側のレスポンスとしては
<status>$error</status>
<message>http://typekey.com/t/login?xxxxxx&http://my.weblog/tb/enabler/id</message>
hiroyuki_oyama: みたくTBのレスポンスで帰ってくればイイような気がした。
miyagawa_edge: あーなるほどね
hiroyuki_oyama: そそ
hiroyuki_oyama: > 302
miyagawa_edge: 1回先におくって、その後TypeKeyでUIDとひもづけてあげるんだ
hiroyuki_oyama: で、clientがそれを解釈してブラウザ立ち上げるナリしてTypeKey認証してもらうと。
miyagawa_edge: 僕のは、クライアント側で Typkeyのユーザ、パス、送り先のtoken でシグニチャ取得して、それを Trackback パラメータにくっつけて送る
miyagawa_edge: あるいは、Typekeyにゲートウェイつくってそこにユーザ、パス、送り先のtoken、その他TBパラメータをおくると、
hiroyuki_oyama: あー、なるほどね。
miyagawa_edge: ゲートウェイがシグニチャつくってTB先に中継してくれる
miyagawa_edge: のどちらかを考えてました
hiroyuki_oyama: それはそれでスマートなのかも。
miyagawa_edge: あー allow_ping_without_link 意味ないかも
miyagawa_edge: Trackback URL と、Auto-Discovery できるURL
miyagawa_edge: は別だった。。
hiroyuki_oyama: それもそうだ。。。