goo blog サービス終了のお知らせ 

子供、いらない

はりょ。少子化問題とは関係ありません。
カウンタが345678やその付近の方はベースノートに書き込んでね。

障害:トラックバック一覧画面の不具合

2006-05-30 23:59:59 | Net.body

2006年05月31日19:20の時点で、本件の原因は修正済みです。

もしもスパムトラックバックが残っていて本件の現象のままの方は、(必要なら[+]ボタンで概要を展開して)スパムトラックバックを削除しちゃいましょう。


今月29日から「トラックバック承認制」の機能などが追加され、「コメント・トラックバック」の画面からコメントやトラックバックの状態変更(公開・保留・削除)が可能になったgooブログですが、早速不具合が(わは)。

回避策(処置方法)もあるので急ぐ必要はないと思いますが、原因の調査と不具合の修正をご検討ください。

【現象】
[+]ボタンでスパムトラックバックを展開しないと以前のトラックバックが表示されない
以前のトラックバックが
表示されない
受信したトラックバックの概要に不適切なテキストが含まれていると、「コメント・トラックバック」の画面では、[+]ボタンを押してトラックバックの概要を展開しないと「概要が不適切なトラックバック(スパムトラックバック)」以前のトラックバックが表示されない(畳まれてしまう)。
また「トラックバック一覧」の画面では、以前のトラックバックと一緒にトラックバックの[公開]、[保留]、[削除]ボタンも畳まれてしまう。

【現象確認日時】
2006年05月29日16:59

【対象画面】
gooブログ編集画面の「コメント・トラックバック」と「トラックバック一覧」

【発生条件】
トラックバックの概要(<description>)に、アンカータグと「不適切なテキスト」が含まれている場合。

【回避策】
[+]ボタンでスパムトラックバックを展開すれば以前のトラックバックやボタンが表示さる
[+]ボタンで展開すれば
TBやボタンが表示される
本現象が発生している画面で[+]ボタンを押すかJavaScriptを停止してトラックバックの概要を展開すれば、画面は多少崩れるが以前のトラックバックが表示(展開)される。
また、障害の原因となっている「概要が不適切なトラックバック(スパムトラックバック)」を削除すると、本現象は解消する。
なお、「トラックバック一覧」の画面でトラックバックの[公開]、[保留]、[削除]ボタンが表示されない(畳まれている)場合は、[+]ボタンで概要を展開すると、以前のトラックバックと一緒に[公開]、[保留]、[削除]ボタンが展開される(表示される)。

【現象確認端末】
現象を確認した端末は、以下の通り。

  • Windows XP + Firefox 1.5.0.3(インターネット)
  • Windows XP + Internet Explorer 6.0(インターネット)
  • Windows Mobile 5.0 for Pocket PC + Opera Mobile 8.50 for Willcom W-ZERO3(インターネット)

【問い合わせ】
問い合わせメールも出した。
[お問い合わせ: 060531-000065] 06/05/31 03:00


↑B『コメント・トラックバック事前承認機能』追加について - gooブログ スタッフブログ 2006年05月29日15:47
【gooブログ】さっそくスパムTBが(苦笑) - BLUE_SKY_BLOG 2006年05月30日08:58
コメントとトラックバック承認制の機能追加 2006年05月29日23:45


● 2006年05月31日追記
事務局から回答が来ました。

「現象を確認し、本日修正しました」って、はやっ。

確かに概要が不適切なトラックバックを受信しても、以前のトラックバックや[公開]、[保留]、[削除]ボタンが折り畳まれてしまうことは、なくなったようです。


スパムトラックバックが止みません、そこで提案です

2006-05-03 07:38:20 | Net.body

ここ数日、海外URLからのスパムトラックバックがまた激しくなってきました。スタッフに連絡に寄せられgooのスパムフィルタに追加されるスパムトラックバックの数も、尋常ではないことでしょう。

そこで提案があります。gooブログのスパムトラックバックの処理方法やスパムトラックバック通報数を削減するための改善案です。

-現在のスパムトラックバック処理の問題点

現在のgooブログは、gooのスパムフィルタに登録されているURLからのトラックバックPingのHTTP POST Requestを受信すると、生真面目にエラーのHTTP Responseを返してしまいます。

スパムトラックバックに対するレスポンスの例
<?xml version="1.0" encoding="EUC-JP"?>
<response>
  <error>1</error>  ←0以外はエラーという意味
  <message>要求されたURLはスパムフィルタに登録されているため、トラックバックを拒否しました。</message>
</response>

つまり、上記の例のようにトラックバック受信を拒否してしまうのです。

相手がまともな人間だけならこのレスポンスは「素直でよろしい」のですが、相手がスパマー(まともではない人間や機械)だと困りもんです。

「おっ、このURLも拒否されたか。じゃぁ、違うURLで送り直そう」となり、異なるURLのスパムを送ってくるためのヒントになってしまうのです。
# 当然ならが、エラー判定も再送信も自動的にできるのですから

これでは、いつまで経ってもスパムは減りません。

-スパムトラックバック処理の改善案

それでは、どうすればよいのでしょうか。

簡単なのは、スパムトラックバックであっても受信だけは許可するのです。つまり、スパムURLからのHTTP POST Requestであっても、受信成功のHTTP Responseを返すのです。

レスポンス改善案の例
<?xml version="1.0" encoding="EUC-JP"?>
<response>
  <error>0</error>  ←受信は成功という意味
  <message>トラックバックを受信しました。通知URLへのリンクは承認後に生成します。</message>
</response>

そして、通知されたURLがgooのスパムフィルタに引っかかった場合は、gooが承認しないため受信したトラックバックが記事のトラックバック欄には表示されず通知URLへのリンクも生成しません。

そして、「あなたのBLOGにスパムトラックバックが送られました!」というお知らせメールを、ブログオーナに送れば良いでしょう。
# 内容はトラックバックのお知らせメールとほぼ一緒で、ブログオーナが「スパムじゃない」申請(処理)ができればよい

そして通常のトラックバックも、後述のトラックバック承認制の場合は、同様の処理をすればいいのです。
# 承認制でも「あなたのBLOGにトラックバックが送られました!」のメールはくださいね

これで、スパムトラックバック対策はかなり改善されると思います。何故なら、スパム判定されたかどうかがスパマーには直ぐには分からないからです。

しかし、ちょっとだけ問題があります。それは、TrackbackPingURL?__mode=rssで受信トラックバックの一覧が表示されてしまうからです。

-__mode=rssのオプションを廃止して欲しい

トラックバックの__mode=rssのオプションはどういうものかというと、「スタッフに連絡」を活用しようの記事のTrackbackPingURL?__mode=rssを開いてもらうのが分かりやすいでしょうか。

何と__mode=rssのオプションがサポートされていると、トラックバックのURLさえ分かれば、記事のタイトル、記事のURL、受信したトラックバックの一覧などが表示(取得)できてしまうのです。

これも相手がまともな人間だけなら「素直でよろしい」のですが、相手がスパマーなら「ちっ、トラックバックが拒否されたよ」と思われたり、スパムであることを偽装するための揮発性リンク(すぐに消えるリンク)を生成するためのヒントになってしまうのです。

折角gooブログはトラックバックPing URLだけからは記事のURLが分からない実装になっているのに、何ともったいないことでしょうか。

そこで提案です。ここは思い切って、__mode=rssのオプションを廃止しましょう。別にこのオプションは、トラックバックの仕様上必須ではないのですから。
# 実際、__mode=rssのオプションをサポートしていないブログはあります

-記事毎にトラックバックの受信設定ができるといいかも

これは微妙なのですが、一応提案しておきます。
# これ以外の案が全て採用されれば、いらないかな

現在は、トラックバックの設定(受信する・受信しない)がブログ全体でしかできません。これを、記事単位に設定できるようにするというものです。
# コメント設定のように、そして後述の承認制を含めて

というのも、スパムトラックバックが送られてくる記事が、結構限定されているからなのです。

スパムトラックバックをよく受信する記事は、「(1)現在時刻で投稿し更新Pingを送信した記事」と、「(2)特定の過去の記事」だからです。

(1)の新着記事狙いスパムに関しては、記事の投稿時刻をわざと5分程度過去にしてから投稿(更新Pingを送信)することで自衛できます。
# 新着記事狙いスパムに対するこのブログの防御率はほぼ100%です

(2)に関しては、特定少数の記事にしかスパムが来ないのですから、その記事だけトラックバックを受信しない設定にできれば、ブログオーナがスパムトラックバック通報する数が減るのではないでしょうか?

-トラックバックの承認制をサポートして欲しい

トラックバックステータスを改造することになり影響範囲が大きいのですが、非常に切実なので敢えて提案しておきます。

現在のブログ情報では、トラックバックの設定が、「受け取る」と「受け取らない」のどちらかしか選択できません。これに「承認制(受け取り承認後表示する)」を追加してほしいのです。

つまり、トラックバックに「承認(表示)」と「未承認(非表示)」のステータスを追加して、トラックバック設定が「承認後表示」となっている場合は、gooブログが受信した時点ではそのトラックバックのステータスを「未承認(非表示)」にします。

そして記事のトラックバック一覧で、ブログオーナがトラックバック毎に「承認(表示)⇔未承認(非表示)」のステータスを変更できるようにしておくのです。
# 「未承認(非表示)」が「削除」ではないところがミソ

これなら、ブログオーナが「これはスパムじゃないな」と判断したものだけが表示されますし、グレーゾーンのトラックバックは何時でもステータスを変更できます。
# 非表示→表示でも、表示→非表示でも

勿論、そんなに手間をかけたくないというブログオーナのために、トラックバック設定が「受け取る」の場合は今まで通りトラックバック受信時に「承認(表示)」としてしまえばいいのですし、既存の受信済みトラックバック(ステータスなし)も「承認(表示)」扱いすれば互換性留意事項もない訳です。

-結局なに?

そして、ここまで読んでいただければ明らかですが、「トラックバックの承認制」は先の「スパムトラックバック処理の改善」と同時にサポートするのがよい思います。何故なら「gooが未承認」としたトラックバックは、トラックバック設定が「受け取る」であってもステータスを「未承認(非表示)」にすればよいのですから。

まぁ、gooブログのスパムフィルタの威力が分かってしまうのでまずい(わは)とか、goo未承認トラックバックの数が莫大で「未承認(非表示)」で登録するとgooブログの負荷が高くなるとか、同じく数が多すぎてブログオーナに迷惑が掛かるとか、もしも好ましくない状況になるのが予測できる場合は、「gooが未承認」の場合は一旦受信したスパムトラックバックを今まで通り「gooが削除」してもよいのですけどね。
# gooメールのスパムフィルタは、威力が凄いのを実感します

現状では、ブログオーナにスパムを防ぐ手段は殆どないのです。gooブログの中の人も大変だとは思いますが、我々もスパム対策には協力いたしますので是非ご検討ください。

なお、この連休中はトラックバック受信を一時的に停止して、暫く様子見ます


↑Bスタッフに連絡 - goo ブログ
トラックバックスパム・pingスパム制限強化について - gooブログ スタッフブログ 2005年09月16日11:30
「スタッフに連絡」を活用しよう 2006年01月15日00:54
Trackback Ping-URLと記事のURL 2006年01月07日00:12
暫く様子見ます 2006年03月24日23:35


-その後

ここからは、提案後のフォローです。詳細はリンク先の記事をご覧ください。

  1. 2006年05月29日
    トラックバックに「公開」と「保留」のステータスを追加する形で、トラックバック承認制のサポートが採用されました。
    同時に、コメント承認制も追加導入されました。

コメントとトラックバック承認制の機能追加 2006年05月29日23:45


ネットはいつからリアルの仲間外れになったのだろうか

2006-02-09 23:55:08 | Net.body

ネットはリアルなのかヴァーチャルなのか。答えは簡単で、ネットはリアルでもありヴァーチャルでもある。でもそれは、いわゆる「現実社会」での会合、電話、手紙といったものがリアルであるということではない。「現実社会」もまたネットと同様にリアルでありヴァーチャルでもあるのだから。

ということで、ちょっと考えてみました。

なお、この記事では「」が非常に重要なので、その点だけは見落として欲しくない。例えば、現実リアル仮想現実ヴァーチャルリアリティというように「」がない語句は本意です。しかし、「現実」「リアル」「仮想現実」「ヴァーチャルリアリティ」というように「」で括った語句は本意ではないのです。誰かが「現実社会」とか「リアル」という言い方をしている場合には、そのまま書かざるを得ないので、そのようにしているだけです。

-現実と仮想現実

先ず、現実と仮想現実の違いを明らかにしておきます。勿論これは筆者の解釈でしかなく、残念ながら世界人類の共通の認識には至っていませんが。また、その他の用語についてもいくつか説明しておきます。

  1. 現実
    本来はこの世の中の全てのことなので仮想現実の実装も現実に含まれるのですが、この記事では敢えて「仮想現実の実装を含まない現実」が現実である、つまり仮想現実の反意語(対義語)であるものとする。
    また、リアル (real) もまた現実の言い換えでしかない同意語とする。

  2. 仮想現実
    人間の五感(視覚、聴覚、触覚、嗅覚、味覚)を利用して(錯覚させて)、様々な疑似体験をすること。
    現在の仮想現実の実装の主流は、コンピュータやネットワークを利用したものだが、それだけではない。
    また、ヴァーチャルリアリティ (VR: virtual reality) や単にヴァーチャル (virtual) という語句も仮想現実の同意語とする。更にこの記事では、仮想現実の実装(実現手段)も敢えて「仮想現実に含む」ものとする。
    なお、著名なSF『スタートレック』に登場するホロデッキが究極の仮想現実とも考えられるが、患者を治療する緊急医療用ホログラム(EMH:ドクター)が存在したり安全装置を外したホロデッキでは殺人もできるので、ホロデッキは行き過ぎた仮想現実なのかも知れない。

  3. 複合現実
    現実と仮想現実を組合せて様々な疑似体験をすること。
    また、ミックスドリアリティ (MR: mixed reality) という語句も同意語とします。
    更に、この記事では複合現実は仮想現実の一種であるとし、現実ではないものとする。

  4. ネット
    インターネット (Internet) の技術を利用して実現されている社会のこととし、魚網や虫取り網、各種スポーツで使う領域仕切り網などは、ネットに含まれないこととする。
    ネットには、ワールドワイドウェブ (WorldWideWeb) またはウェブ (web)、電子メール (e-mail)、携帯電話メール、チャット、インスタントメッセージ、ファイル転送、電子掲示板などが含まれるものとする。
    # ネットの基本は、誰もが参加することができるものです

  5. 「現実社会」
    「現実社会」は、現実社会のうちのネット以外の部分のこと。
    国会、組織における会合、井戸端会議、テレビ、ラジオ、電報、電話、携帯電話の通話サービス、ファクシミリ、レタックス、日本郵政公社メール(旧郵政省メール)、宅配便、駅や学校の掲示板、古文書、新聞、書籍、机の中に隠してある日記、今は彼女が書く番の交換日記などを含む。
    ただし、携帯電話メールや電子掲示板などは除く。また、IP電話やIPファクシミリなどIPが必須な機器であっても、利用者がインターネットを意識していない場合は、例外的に含むものとする。
    # 例えば一台の電話機が、利用者によってネットに含まれる場合と「現実社会」に含まれる場合がある

  6. SNS
    ソーシャルネットワーキングサービス (Social Networking Service) のことで、何をするにもIDが必須な会員制システム。また、SNSなウェブサイトのことをSocial Networking Siteと呼ぶ限定的用法もある。
    その実装にはIP(インターネットプロトコル)が不可欠であるため、インターネットの一部と考えられがちだが、その多くはインターネットには含まれない。その理由は、参加には何らかの条件付会員登録が必須で(誰もが参加可能ではなく)、会員や非会員のアクセスをサービス提供者がIDにより自由に制御できるため。
    # 読み出しが無条件に許可されている例外的なSNSもある
    なお、この記事では「現実社会」の反意語としてネットを定義しているため、SNSもネットに含まれるものとする。

  7. イントラネット
    イントラネット (intranet) は、企業・団体などの組織に閉じたネットワークで、その多くはIPで実装されている。
    これもまたインターネットではないが、「現実社会」の反意語としてのネットに含まれるものとする。

  8. その他会員向けサービス
    goo掲示板gooブログのように、メッセージや記事の投稿や管理は権限のある会員しかできないサービス。
    メッセージの投稿画面や記事の管理画面は権限のある会員にしか表示されないが、サービスの本意であるメッセージや記事の閲覧は誰でもできる。
    # アクセス制御している場合もあるけど
    これらも、「現実社会」の反意語としてのネットに含まれるものとする。

-「現実社会」に仮想現実はないのか?

いわゆる「現実社会」にも現実があることは、多くの方が納得されると思いますので、そこら辺は書きません。では、「現実社会」に仮想現実があるのかというと、勿論あります。

仮想現実を思い出してください。五感に訴えて疑似体験できれば何でもよく、その実装(実現手段)はネットやコンピュータだけではありません。景勝地の写真を眺めて旅行した気分になったり、H.G.ウェルズのラジオドラマ『宇宙戦争』を聴いて宇宙人が攻めてきたと思ったり、精進料理の「鰻」の蒲焼を食べて鰻を食べた気になったり、DVD再生機と眼鏡型画面で映画を観てその場にいる気になったり。まぁ色々あるわけです。

良い仮想現実だけではありません。妄想癖が非常に強い人との会合、電話、手紙のやり取りなどは、殆んど全てが「仮想現実」ですね。きっと、その人の存在さえ信じられなくなってきますよ。

「現実社会」には仮想現実がないと仰る方は、想像力が欠如しているのか、妄想とは縁のない人生を送ってきたのか、どちらかなのかも知れませんね。

-ネットに現実はないのか?

ネットにも仮想現実があることは、多くの方が納得されているようなので、これも書きません。というか、個人的にはネットに仮想現実は少ないと感じていますので、例を挙げろといわれると実は困るのです。

そんなことは置いといて、ネットに現実があるのかというと勿論あります。何故なら、疑似体験でなければそれは全て現実なのです。例えば今あなたが読んでいるこのブログの記事は、仮想現実でしょうか?そんなことはない筈です。この記事の実体はインターネットを通して送られてくるバイト列ではありますが、あなたの閲覧環境では日本語の文章として表示され、あなたは読んでいることでしょう。

ブログだけではありません。ニュースサイトに掲載されている記事、電子掲示板に書き込まれたメッセージ、家族や恋人とやり取りしている電子メール、友だちとお話しているインスタントメッセージ。どれをとっても全て現実です。

確かにその媒体は、新聞、書籍、テレビやラジオではありません。手紙でもなければ、電話でもファクシミリでもありません。それでもあなたは、ニュースを知ることができ、会話相手の考えが分かったり、文章だけではなく声を聞いたり顔をみることもできます。
# 触覚、味覚、嗅覚に訴えるものは少ないかも知れませんが

いわゆる「現実社会」との大きな差は、そのコスト(手間や費用)が大幅に軽減され、今まで困難だったことが容易になっただけなのです。

地球の裏側の人々とほぼリアルタイムに会話したり、手紙のやり取りをすることは、ネットがなければ高価で手間がかりますが、今は非常に安価にできます。自伝を書籍として誰もが読めるくらいの部数を出版することは、著名な作家でもなければ容易ではありません。しかし、毎日記事を書き、相手が望めば誰でも読むことができるようにしておくことは、ブログなら非常に容易です。

-ネットは全て真実なのか?

ここでちょっと問題になるのが、現実と真実の違いです。

ネットで現実に情報を得たり人間関係を築くことは、容易です。コストが低いので、容易過ぎるくらいです。しかし、それが全て真実とは限りません。現実に得た情報や人間関係が真実とは限らない点は、ネットも「現実社会」も一緒なのです。ただし、情報発信コストや会話のコストが「現実社会」よりもネットの方が格段に低く、騙ることも容易であるため、「現実社会」よりもネットの方が真実ではない現実が多いことも事実でしょう。

例えば、男性が女性を名乗ることは容易ですし、女性としての写真を掲載したり、女性としての声を流すこともできます。逆に、女性が男性を名乗ることも容易ですし、名乗らないことも容易です。その気になれば、相手を騙すことも「現実社会」よりは容易でしょう。

-ネットで感覚はたらくのか?

ネットと「現実社会」との大きな差は、はたらく感覚の差が大きいということです。現在のインターネット技術では、視覚と聴覚くらいしか活用できません。また、情報量にも大きな差があります。

例えばどこかでチャットをするとします。チャットの主力はテキスト(文章)ですから、使える感覚は視覚だけです。一部のチャットでは「音声」が使えますが、それでも視覚と聴覚くらいしか使えないのです。つまり「現実社会」でいうなら、電報と電話を同時に使うくらいの情報量しかないのです。

「現実社会」でチャットに相当する井戸端会議では、どうでしょうか。口談するのも筆談するのも、自由です。この時点で情報量はチャットと同じだけあります。更に顔色を知ることもできますし、場合よっては触覚や嗅覚や味覚も活用できます。
# 活用方法は、自由にご想像ください

これだけ情報量が違うのですから、ネットで誤解とか錯覚してしまうことは、多いかもしれません。しかしそれは、現実を誤解したり錯覚したりしているだけで、仮想現実とは違うのです。つまり、仮想現実は被験者が積極的(故意)に感覚を錯覚させて疑似体験するのですが、ネットでの誤解・錯覚は被害者の過失であったり、加害者の故意・過失によるものなのです。

-気になった記事

ここで気になった記事をいくつか。

先ずは、ネットはいつ「リアル」の仲間入りするのだろうかという記事で、勝手に要約すると以下のようになるのか。

  • ネット上の人格は「現実社会」の人格と異なっているので、鵜呑みにするな
  • ネットのコミュニケーションでは心は伝わりにくい
  • だからといって、ネット≠リアルというわけではない

まぁその通りだと思う。だけど、ちょっと記事のタイトルが好きじゃない。ネットはいつ「リアル」の仲間入りするのだろうかと聞かれても困るのだ。ネットは登場した時点からリアルだったし、メールにしてもニュースグループにしても、参加者名が名前@組織ということで、「現実社会」よりもむしろ匿名性が低くかったと考えられるし。

個人的には、ネットがいつからリアルの仲間外れになったのかを知りたいところだ。

次に、別の記事と気になった部分を。

ウエブと、手紙や電話などの明らかな違いは「見知っている相手」とのみのコミュニケーションであるか否かという事があげられると思います。

手紙も電話も基本的には知り合いから受け取るものです。

ダイレクトメールや勧誘の電話もありますが、ウエブのように見知らぬ人の書き込みを読んだり聞いたりする事はあまりないと思います。


ウエブはリアルかバーチャルか - 煩悩是道場
太字は、引用者による。

上の記事においては、ウェブと「現実社会」の前提条件が違いすぎると思う。つまり、「現実社会」で電話番号や住所(手紙の送り先)を公開しているのかどうかということだ。どう考えてもこの方は、自分の電話番号や手紙の送り先を知り合いにしか公開していないとしか思えない。

例えば著名な書籍を出版していて、そこにファンレターの送り先が明記されていたり、ましてや携帯電話の番号でも書いてあったら、見知らぬ人から大量のファンレターが送られてきて、電話もひっきりなしだと思いますよ。

しかし、ウェブ上では立派にブログを「出版」なさっている。それなら、見知らぬ人から大量のコメントが投稿されたりソーシャルブックマークが付いても、不思議じゃない。ウェブと「現実社会」を比較するには、ちょっと前提条件が違いすぎはしませんかね。

-結局なに?

ネットと「現実社会」のどちらにも、現実(リアル)もあれば仮想現実(ヴァーチャルリアリティ)もある。それに、ネット社会/非ネット社会と現実/仮想現実は、そもそも別次元のことだと思うのです。

つまり、ネットはリアルなのか?とか、非ネット社会にヴァーチャルはないのか?とかいうのは、右と左に対して、右は北なのか?とか、左は南になりえないのか?という質問だと思うのです。

ただし、そういう誤解をしている人は多いかも知れません。もしくは、ネットはオンライン/非ネットはオフラインと、ヴァーチャル/リアルがごっちゃになっているだけなのかも。


↑Bネットはいつ「リアル」の仲間入りするのだろうか - H-Yamaguchi.net 2006年02月06日01:01
ウエブはリアルかバーチャルか - 煩悩是道場 2006年02月09日


駅探から乗換え

2006-01-29 23:58:28 | Net.body

駅探(駅前探検倶楽部)は、言わずと知れた乗換え案内サービスです。

最近は色んなところで色んな乗換え案内サービスがあるのですが、使っている期間が長い(前世紀から使っている)ので、列車の乗換え検索するときにはPCでも携帯でも駅探と決まっていました。

でも、ちょっと乗換えてみようかなと思って、他のところも試してみました。

-駅探

先ずは、駅前探検倶楽部です。ここある自分が使う機能がない(または容易ではない)場合は、乗換える意欲が湧きにくいですからね。

  1. エンジン
    自前。

  2. 駅名
    乗車駅・降車駅のテキスト入力が基本で、路線・駅名リストや入力履歴からの選択も可能。

  3. 日付
    年月、10日、1日のプルダウンリスト。

  4. 時刻
    時、10分、1分のプルダウンリスト。

  5. その他入力項目
    出発/到着の時刻モード指定、時間/料金/乗換え回数の指定、表示件数の選択など。

  6. 主な結果出力
    広告が多めだが、見易さはそこそこ。
    検索結果がURLに反映される。これは、誰かに教える機能として必須。
    印刷用画面、テキスト画面、定期代画面もある。特にテキスト画面やそれに準ずるものは、二次加工用に必須。
    結果をメールで送信できる。
    出発駅・途中駅の時刻表が表示できる。
    出発駅・到着駅の周辺地図が表示できる。

  7. 再検索
    終電検索・復路検索あり、駅名以外の条件変更後再検索はできる。
    ただし、駅名を変更するためには全条件の再設定が必要なため、近隣の他駅利用を検討する場合には、時刻その他の条件を全て入力しなおさないといけない。

  8. その他
    まぁ、使い続けていたものなのですから、際立って悪い訳はないですよね。

-Yahoo!路線情報

まぁここは一応チェックしておきます。

  1. エンジン
    駅すぱあと。

  2. 駅名
    乗車駅・降車駅のテキスト入力。

  3. 日付
    年月、日のプルダウンリスト。

  4. 時刻
    時、10分、1分のプルダウンリスト。

  5. その他入力項目
    出発/到着/終電/指定なしの時刻モード指定、など。

  6. 主な結果出力
    広告はあるが、見易さはそこそこ。
    検索結果がURLに反映される。
    定期代も同時表示、印刷用画面なし、テキスト画面なし
    結果をメールで送信できる。
    途中駅の時刻表なし。
    出発駅・途中駅・到着駅の出口案内、地図、宿泊施設などが表示できる。

  7. 再検索
    乗車駅、降車駅、年月、日、時、10分、1分、出発・到着・終電・指定なしの変更後の再検索ができる。

  8. その他
    二次加工がしにくいので、経路の比較検討が難しい。

-ジョルダン

自前エンジンなので、チェック。

  1. エンジン
    自前。

  2. 駅名
    乗車駅・降車駅のテキスト入力が基本で、駅名リストからの選択も可能。

  3. 日付
    年月、日のプルダウンリスト。

  4. 時刻
    時、分のプルダウンリスト。

  5. その他入力項目
    出発/到着の時刻モード指定。

  6. 主な結果出力
    広告あり、ちょと見難い。
    検索結果がURLに反映されないため、致命的。
    印刷用画面あり、テキスト画面あり。
    途中駅の時刻表なし。
    出発駅・到着駅の駅情報(出口、構内、周辺地図)、宿泊施設などが表示できる。

  7. 再検索
    前の画面(条件設定)に戻ることで可能。

  8. その他
    ちょっと重い気がした。
    分のプルダウンリストは、値が00~59まであって嫌いです。
    駅情報とかテキスト画面へのリンク方法が、JavaScriptで小窓を開いてくれるんですが、それだけなんです。右クリックして別タブ表示できない時点で、評価が非常に下がります。

-goo路線

当然ここもチェックしておきます。

  1. エンジン
    駅前探検倶楽部。

  2. 駅名
    乗車駅・降車駅・経由駅のテキスト入力が基本で、乗車駅・降車駅は入力履歴から選択したり、乗車駅と降車駅のどちらか一方を駅名リストから選択することも可能。
    優先エリアあり。

  3. 日付
    年、月、日のテキスト入力。

  4. 時刻
    時、分のテキスト入力。

  5. その他入力項目
    出発/到着/終電の時刻モード指定、オプション画面で時間/料金/乗換え回数の指定、表示件数の選択など(駅探互換)。

  6. 主な結果出力
    広告はあるが、見易さはそこそこ。
    検索結果がURLに反映される。
    定期代も同時表示、印刷用画面あり、テキスト画面あり
    結果をメールで送信できる。
    出発駅・途中駅の時刻表が表示できる。
    出発駅・途中駅・到着駅の地図、周辺情報などが表示できる。

  7. 再検索
    前後60分/30分/10分/5分の検索時刻が1クリックでできる。
    終電検索・復路検索や、乗車駅、降車駅、経由駅、年、月、日、時、分、出発・到着・終電、その他オプションの変更後再検索ができる。

  8. その他
    エンジンが駅探なので、非常に移行しやすい。
    日付や時刻のテキスト入力は、慣れるとプルダウンリストよりも楽です。
    地図や周辺情報が、駅探(アルプス)からgoo地図・goo地域(ゼンリン)に変更されていて、これの使い勝手が結構いい。

-えきから時刻表

駅探エンジンじゃないところです。

  1. エンジン
    自前。

  2. 駅名
    乗車駅・降車駅のテキスト入力。

  3. 日付
    年月、日のプルダウンリスト。

  4. 時刻
    時、10分、1分のプルダウンリスト。

  5. その他入力項目
    出発/到着/始発/終電の時刻モード指定、発着時間/所要時間/料金/距離/乗換え回数の指定、表示件数の選択など。

  6. 主な結果出力
    広告はあるが、見易さはそこそこ。
    検索結果がURLに反映される。
    印刷用画面もある。印刷用画面が二次加工用に利用できなくもないが、ちょっとだけ使いにくい。
    途中駅の時刻表や乗車路線の時刻表が表示できる。
    レストランや宿の表示ができる(ぐるなび連携)
    地図はない。

  7. 再検索
    乗車駅、降車駅、年月、日、時、10分、1分、出発・到着の変更か、オプション画面への遷移で再検索ができる。

  8. その他
    悪くはない。

-MSN路線

使ったことなかったんで、チェックしてみました。

  1. エンジン
    日立情報システムズ。

  2. 駅名
    乗車駅・降車駅・経由駅1・経由駅2のテキスト入力が基本で、東京駅・名古屋駅・大阪駅の近辺だけ路線図から選択することも可能。

  3. 日付
    年、月、日のプルダウンリスト。

  4. 時刻
    時、分のプルダウンリスト。

  5. その他入力項目
    出発/到着/終電/平均の時刻モード指定、表示件数の選択など。

  6. 主な結果出力
    広告あり、左メニューあり。左メニューが邪魔で小さいウィンドウでは非常に見難い。
    検索結果がURLに反映される。
    定期代も同時表示、印刷用画面あり、テキスト画面あり
    出発駅・途中駅の時刻表が表示できる。
    出発駅・途中駅・到着駅の地図、駅などが表示できる。

  7. 再検索
    前の画面に戻れば、再検索ができる。

  8. その他
    どうにもこうにも、左メニューが邪魔。

-livedoor路線案内

別の話題で沸騰していたところですが、チェックしておきます。

  1. エンジン
    駅前探検倶楽部。

  2. 駅名
    乗車駅・降車駅のテキスト入力が基本で、乗車駅・降車駅を駅名リストから選択することも可能。

  3. 日付
    年月のプルダウンリスト、日のテキスト入力。

  4. 時刻
    時、分のテキスト入力。

  5. その他入力項目
    出発/到着/終電の時刻モード指定、詳細条件画面で時間/料金/乗換え回数の指定、表示件数の選択など(駅探互換)。
    ただし、入力済み基本項目が詳細条件画面に反映されないので注意が必要

  6. 主な結果出力
    広告はあるが、見易さはそこそこ。
    検索結果がURLに反映される。
    定期代画面あり、印刷用画面なし、テキスト画面なし
    結果を携帯にはメール送信できるが、それ以外はメール送信できない。
    出発駅・途中駅・到着駅の時刻表が表示できる。
    出発駅・途中駅・到着駅の地図、宿泊施設などが表示できる。

  7. 再検索
    前後60分/30分/10分/5分の検索時刻が1クリックでできる。
    終電検索・復路検索や、乗車駅、降車駅、年月、日、時、分、出発・到着・終電の変更後再検索ができる。

  8. その他
    同じ駅探エンジンのgoo経路と比較すると、全体的に見劣りする。

-Infoseek乗換案内

まぁ、ここもついでにチェックしておきます。
# もう結構どうでも良くなってきた…

  1. エンジン
    駅前探検倶楽部。

  2. 駅名
    乗車駅・降車駅・経由駅のテキスト入力が基本で、乗車駅・降車駅・経由駅が入力履歴から選択することも可能。

  3. 日付
    年月、日のプルダウンリスト。

  4. 時刻
    時、10分、1分のプルダウンリスト。

  5. その他入力項目
    出発/到着の時刻モード指定、オプション画面で時間/料金/乗換え回数の指定、表示件数の選択など(駅探互換)。

  6. 主な結果出力
    広告はあるが、見易さはそこそこ。
    検索結果がURLに反映される。
    定期代も同時表示、印刷用画面なし、テキスト画面なし
    駅探の結果をメールで送信できる。
    出発駅・到着駅の時刻表が表示できる。
    出発駅・到着駅の地図が表示できる。

  7. 再検索
    前後180分/120分/60分/30分/10分/5分の検索時刻が1クリックでできる。
    終電検索・復路検索や、乗車駅、降車駅、経由駅、年、月、日、時、分、出発・到着・終電、その他オプションの変更後再検索ができる。

  8. その他
    同じ駅探エンジンのgoo経路と比較すると、ちょっと見劣りする。

-Google

番外編です。Googleの検索エディットボックスに「乗車駅から降車駅」(例えば新宿から元町・中華街)と正確に入力すれば、駅前探険倶楽部えきから時刻表のリンクが表示されます。
でも、「しんじゅくから元町・中華街」とか「新宿から元町中華街」ではだめです(わは)。

-えきねっと時刻・乗換案内

これも番外編です。会員登録すれば、新幹線やJR特急列車の座席指定もできるので、旅にはいいかも。

-結局なに?

現時点では、駅探エンジンのサービスがやっぱり使いやすい。ということで、その中でgoo地図・goo地域連携がちょっとお勧めなgoo路線乗換えてみます。


↑Bインターネットを使った情報提供サービスの開始について - 東芝 1997年04月02日
列車乗り換え案内サービス「駅前探険倶楽部」事業の分社による新会社設立について - 駅探 2003年01月09日
Yahoo! JAPANで「駅すぱあと」を使用したYahoo!路線情報サービスを開始 - Yahoo! JAPANプレスリリース 1998年12月10日
goo路線からgoo地図を使ってみよう 2006年01月30日01:20


はてブのアイコンは問題ない

2006-01-27 01:51:06 | Net.body

昨日(1/26)より、はてなの一部のサービスで、ユーザが設定した画像(プロファイルアイコン)も一緒に表示されるようになり、「はてなブックマーク」では、ユーザ識別補助になるかなと思いました。

この「はてなのプロファイルアイコン」は、はてなのサービス内ならid:user_name:detailとかid:user_name:imageとかいった「はてな記法」も使えるようです。例えば、user_namemid_knightの場合は以下のようになります。

  1. id:mid_knight:detail
    id:mid_knightid:mid_knight
    (縦横サイズ:16x16)

  2. id:mid_knight:image
    id:mid_knight
    (縦横サイズ:60x60)

でもって、このアイコンの影響ではてなブックマークが重くなってしまいそうという懸念を見かけたので、ちょっと考えてみました。

はてなブックマークでは、16x16のスモールアイコンが表示されるようになりました。デフォルトアイコンは166バイト、ユーザアイコンなら1KB程とはいえ、今までなかった画像が表示され、そのためのタグも追加されてますから、確実に重くはなります。実際、とあるブックマークのページは、以前の約2倍のページサイズになっていました。

しかし、元が軽いのであまり重さを感じません。それにこのアイコンはただのGIF画像(profile_s.gif)ですから、どうしても重い場合はブラウザの設定で画像を読み込まないようにしたり、Firefox + Adblock Plusプロファイルアイコンだけブロックすれば、ページサイズは2割増し(120%)程度ですし。

なお、測定に使ったサイトや測定対象のブックマークなどは、以下の通りです。

  1. 測定サイト
    http://www.kaipara.com/cgi-bin/size_check.cgi

  2. 対象ブックマーク
    はてなブックマーク日記 - タグ個数、コメント文字数制限の変更について
    ブックマークしているユーザ数(U):98
    デフォルトアイコン数:62
    ユーザアイコン数:36
    ユーザアイコン率:36.7%

  3. チェック結果
    予想表示時間:16.99秒程度(56Kモデム単純換算)、評価D
    合計サイズ(A):118947バイト
    アイコン以外のサイズ(B):77663バイト
    アイコンを表示するためのタグ(C):150バイト程度
    以前のサイズ(≒D:B-U×C):約62963バイト
    肥大率(≒A÷D):約189%
    全て1KBのアイコンの場合の肥大率(≒(B+U×1024)÷D):約283%

ということで、ページサイズは約2倍(約189%)になっていました。またこのブックマークのアイコンが全て1KBのユーザアイコンの場合は、約3倍(約283%)のページサイズになります。


プロフィール画像設定機能の追加について - はてなダイアリー日記 2006年01月26日17:15
はてなブックマークが重くなってしまいそうな件について - BLOG STATION 2006年01月26日22:45
Firefox 1.5日本語版リリース 2005年11月30日19:15


「トラックバック≠リンク通知」なのか?

2006-01-22 23:57:31 | Net.body

このところ気になっている話題があります。それは、トラックバックする記事のあり方で、特に「関連性」と「リンクの有無」に関する考え方です。

トラックバックのプロトコル(実装上の取り決め)的には、確かに「トラックバック≠リンク通知」です。でもやっぱり、関連している記事の「明確なリンクの通知」が、トラックバックの基本的な使い方じゃないのかなと思っています。そして、「検索トラックバック」というスパムの正当化のためにMovable Typeの「Developer Documentation : TrackBack Technical Specification」(邦訳は「トラックバック技術仕様書」)の概要が、時として言い訳として利用されていることがあることが気になります。

-気になった記事

実は気になる記事はいくらでもあるのですが、取り敢えずTrackBack Technical Specificationやその邦訳ページを参考にしている記事の紹介から。

  1. トラックバック≠リンク通知 - hxxk.jp 2005年05月20日00:47
  2. TrackBackは罪な技術なんかね? - Days of SpeakEasy 2006年01月16日23:07

どちらも、トラックバックの技術的仕様書を読んで「トラックバック≠リンク通知」という認識?をされているようです。ただし、ちょっと問題があるかなと思いました。

  1. 技術的な仕様書
    TrackBack Technical Specificationは、Movable Typeでトラックバックを実装した際の技術的な仕様書であり、実装面の説明が主です。
    残念ながらトラックバックの使い方の解説書ではないし、ましてや作法が書いてある訳ではないようです。概要も非常に曖昧なので、トラックバックの使用目的を仕様書だけから導き出すのは、非常に困難ではないかと思います。

  2. 引用を誤ると改竄となりかねない
    参考文献の引用を故意や過失により誤ると、原文の意図を容易に改竄できます。
    例えば、「~です。例えば、もしもAさんが~トラックバックを送ります。すると~となるのです」とあるところを単に「Aさんが~トラックバックを送ります。」と書いてしまうと、そこだけで完結した内容であるかのように誤解されかねません。
    つまり、単なる使用例の中の一フレーズでしかないのに、それだけを目的として開発された技術であるかのように改竄できますので、非常に短い引用は節やページ全体の主旨に沿っているのかどうかを見極める必要があります。
-でもやっぱりTrackBack Technical Specification

技術的仕様書のTrackBack Technical Specificationとはいえ、Movable Typeの仕様であればやっぱり参考にしちゃうんですよね。だから、概要部分だけ引用しておきます。

This document describes TrackBack, a framework for peer-to-peer communication and notifications between web sites. The central idea behind TrackBack is the idea of a TrackBack ping, a request saying, essentially, "resource A is related/linked to resource B." A TrackBack "resource" is represented by a TrackBack Ping URL, which is just a standard URI.

Using TrackBack, sites can communicate about related resources. For example, if Weblogger A wishes to notify Weblogger B that he has written something interesting/related/shocking, A sends a TrackBack ping to B. This accomplishes two things:

  1. Weblogger B can automatically list all sites that have referenced a particular post on his site, allowing visitors to his site to read all related posts around the web, including Weblogger A's.

  2. The ping provides a firm, explicit link between his entry and yours, as opposed to an implicit link (like a referrer log) that depends upon outside action (someone clicking on the link).

Developer Documentation : TrackBack Technical Specification - Six Apart
太字は、引用者による。
-related/linkedの意味

どうも、「related/linked」の単語だけで「リンク通知が目的ではない」という主張をしている方が多いように思います。確かに単語だけでは、「関連している または リンクしている」となるため、「検索トラックバック」の正当化に使われ易いのですが、この節を全て読むと、「関連している派生記事には、参考にした記事へのリンクが必ず存在する」という著者の前提が隠されているように思えます。むしろ「related/linked」が、「(リンク及び)関連している または (単純に)リンクしている」という意味で書いてあるのでは?とさえ、思えてきます。

何故かというと、使用例の「得られる結果 1.」にある「参照されているエントリの一覧が作られる」が気になるのです。勿論、参照していないエントリが含まれないとは書いてはいないのですが、この著者の「related」の意味として、「referenced:参照している(出典へのリンクの類がある)」後発の記事(派生記事)という前提があるように思えるのです。

更に「得られる結果 2.」においては、「an implicit link (like a referrer log):(リファラログのような)暗黙のリンク」という言葉まで出しています。つまり、Aの記事内のリンクをクリックしてBにAの存在が分かるのではなくて、AからBへのTrackback Ping送信により「明確な双方向リンクを築く:リンク済み記事Aに対して記事Bから逆方向のリンクを張る」ことを目的としているようにさえ思えるのです。

-記事が書かれた順序

実は、記事を書いたらキーワードがマッチするだけのトラックバック先を無理やり探して「検索トラックバック」する方から、過去に「キーワードがマッチしたんだから、関連している」とコメントを貰ったことがありました(「検索トラックバック」もね)。また、その方ではありませんが、「related:関連している」という言葉を盾に「検索トラックバック」を「関連記事のトラックバック」だとおっしゃる方もいるようです。

しかし、「関連記事のトラックバック」と「検索トラックバック」の大きな違いとして、記事の書かれた順序があります。

例えば、Aさんが過去に書いた記事の中には、Bさんにとって、興味があったり、衝撃を受ける内容の記事があるかも知れません。何故なら、Bさんが最近書いた記事の疑問点を解消する内容であったり、Bさんの記事の前提を覆す(Bさんが知らなかった)事実であったりするかも知れないのですから。

もしも、AさんがBさんの記事を見かけたなら、新たな記事をわざわざ書かず、過去の記事をそのまま:都合よく修正しないで「関連記事をトラックバック」することには、非常に意義を感じます。

しかし、TrackBack Technical Specificationの説明では、残念ながらAさんの記事の方がBさんの記事よりも新しいときしか書いてありません。つまり、リンクが必ず存在する派生記事のトラックバックの説明しかなく、「過去の関連記事をトラックバックする」ことなど考慮していないとさえ思えます。
# 勿論「検索トラックバック」など登場しません

-技術的ではない参考文献

トラックバックの技術的な仕様書ではなく、初心者向けの解説ページもありますので、そちらも紹介しておきます。

  1. A Beginner's Guide to TrackBack: What Is TrackBack? - TrackBack Explanation(原文)
  2. トラックバック初心者ガイド:トラックバックって何ですか? - はじめてのウェブログ(邦訳)

こちらの説明にも「トラックバック=リンク通知」とは書いてありません。ですが、ちょっと読んでみてください。自分が記事を書いてからキーワードが一致する記事を探してトラックバックをしよう!と読み取れるような部分があるでしょうか?

主なトラックバックの使い方(Bさんが興味をもつ理由)として、2種類が提示してあります。一つは「遠隔コメント:派生記事のトラックバック」ですから、「リンクがあるのは当然」です。もう一つの使い方は、既存の中心記事(トラックバックセンタとなる記事?)に対して、後発記事がトラックバックを集中することによって、誰もが関連記事を読むことができるというもの。注意しなくてはならないのは、中心記事は多数のトラックバックを受け取る記事であり、多数のトラックバックを送信する記事ではないのです。

どちらにしても、非常に希薄な関連性を盾に多数のトラックバック送信をする使用例などないのです。

-結局なに?

トラックバックPing送信のプロトコル上の定義は、「通知するURL」のみが必要なHTTP POSTリクエストです。つまり、単なる「URLの通知」であって、関連性やリンクの有無は全く関係ありませんし、逆方向リンクを生成するものでもありません。

とはいえ、ブログサイト間でコミュニケーションするのが目的なのであれば、閲覧者が互いのサイトを容易に閲覧できるように、トラックバックする記事やその付近にトラックバック先へのリンクがあるべき(トラックバック送信側の問題)ですし、トラックバック受信記事の付近に「通知されたURL」へのリンクを生成した方がよい(トラックバック受信側の問題)訳です。

つまり、トラックバックの第一目的が「明確なリンクの通知」であり、「通知されたURL」へのリンクが生成される限り、記事の関連性はともかく、サイト間コミュニケーションは生まれるのではないかと考えます。
# 関連性のシステム化やマニュアル化は非常に難しいので、ちと保留

ということで、「派生記事」を書くのであれば参照文献(出典)へのリンクを入れるようにしたり、過去の記事を関連記事としてトラックバックする場合は、(本文でなくてもよいので)何処かにトラックバック先(と必要なら目的や背景)を追加した方がよいと思います。

また、記事を書いてからトラックバック先を検索して探すような「検索トラックバック」は、「関連記事」でもなければ「派生記事」でもないので、単なるスパムトラックバックと考えますし、「リンクが列挙されただけの記事のトラックバック」というのも、できるだけ遠慮したいところです。

でも、このブログは「関連記事のトラックバック」を拒絶している訳ではないのです。このブログの記事に対してあなたの過去の記事を「関連記事」としてトラックバックする場合は、当方が理解できれば問題ないんじゃないでしょうか?
# 理解できるケースは多くないみたいですけど…


↑Bトラックバック≠リンク通知 - hxxk.jp 2005年05月20日00:47
TrackBackは罪な技術なんかね? - Days of SpeakEasy 2006年01月16日23:07
Developer Documentation : TrackBack Technical Specification
トラックバック技術仕様書
A Beginner's Guide to TrackBack: What Is TrackBack? - TrackBack Explanation
トラックバック初心者ガイド:トラックバックって何ですか? - はじめてのウェブログ [weblog for beginners] 2003年10月28日17:09
有用なトラックバックとは - hxxk.jp 2004年12月03日00:28
コメントとトラックバック 2006年01月08日23:03
関連記事と検索トラックバック 2005年09月20日22:25
意図した隠蔽:改竄 2005年10月27日23:07


N3524CMプレゼントの応募

2006-01-16 23:39:43 | Net.body

折角gooブログをやっているので、ブログパソコン(N3524CM)のプレゼントキャンペーンに参加(応募)します。

  1. あなたの大切な人とあなたの関係
    両親。

  2. ブログパソコンを送りたい人へのメッセージ
    これでパソコンを覚えてくださいな。

  3. ブログパソコンってどーよ?
    コンセプトが、「外出先」とか「いつでも・どこでも」手軽にブログを楽しめるということなのであれば、無線LANやAIR-EDGEの類を内蔵/同梱していないのは、ちょっとどうかと思います。

  4. gooブログに対してのご意見・感想
    最近は安定稼動しているし、軽くて使いやすいと思いますよ。過剰なアフィリエイタも少ないようだし、いいんじゃないでしょうか。
    あとは、ちょっとした内容であっても、不具合発生のアナウンス(あくまで不具合解消の報告ではない)や、仕様変更のスケジュールの告知をしていただければ、もっと良いかと思います。


それから、当選発表って、いったい何日なんでしょうか?

■当選発表
2006年2月23日(月)までに「gooメール」のアドレス宛に当選者の方のみ当選メールをお送りいたします。
(中略)
当選者の方には、2006年2月16日(金)までにgooメールより連絡します!
(以下略)

こちらよりご応募ください - 『ブログパソコン』プレゼント応募用ブログ
太字赤字は、引用者による。
・発表:2006年1月23日までに当社が提供するメールサービス「gooメール」のアドレスあてに電子メールにより当選の旨を通知いたします。
(以下略)

応募規約 - 『ブログパソコン』プレゼント応募用ブログ
太字は、引用者による。

ということで、2006年1月23日(月)、2006年2月16日(木)、2006年2月23日(木)、のどれが正解なのでしょうか?因みに、2006年2月16日(金)と2006年2月23日(月)は、存在しません。


こちらよりご応募ください - 『ブログパソコン』プレゼント応募用ブログ 2005年12月08日23:27


livedoorが検索トラックバックの受信対策

2006-01-11 22:56:33 | Net.body

昨日から仕様が変更されたlivedoor Blogのトラックバックですが、スタッフブログ(livedoor Blog 開発日誌)の告知内容や管理画面は、例によってでした。

(中略)
この仕組みの導入により不特定多数のブログに無関係のトラックバックを送信することができなくなります。(以下略)

年末年始を写そう!livedoor ピクスリニューアル、トラックバックスパム防止につきまして - livedoor Blog 開発日誌
赤太字は、引用者による。
(中略)
現在利用されているブログの管理ページ内「ブログの設定/管理」タブ内に「参照リンクの無いトラックバックを許可する」という項目が加わります。(以下略)

トラックバックスパム防止機能の導入につきまして - livedoor Blog 開発日誌
赤太字は、引用者による。

こんな事前アナウンスがあったのですが、「送信できない」と「リンクが必要」の、どちらもでした。

(中略)
※注意
基本的には投稿内にトラックバック先ブログのURLがあるかないかで判断します。ただし、サイドバーなどにリンクとして設定されているブログからのトラックバックは、スパム防止の対象になりません。(以下略)

トラックバック防止機能を本日公開しました! - livedoor Blog 開発日誌
太字は、原文のまま。

更に、リリース後の深夜に出されたアナウンスも、何だかさっぱり分かりません。結論としては、以下の通りのようです。

  1. 制限はトラックバック受信のみ
    livedoorのアナウンスには、「送信を制限する」と読み取れるものがあるのですが、結局送信側には何の制限もないようです。

  2. 必要なのはリンクではなく単純テキスト
    ブログ管理画面には、「リンクの無いトラックバックを許可する」オプション(既定値:オフ)があるため、リンクがない無差別トラックバックを拒否できるかと思いきや、関係ありませんでした。単純にテキストで十分でした。

  3. 必要なのは記事のURLではなくブログのURL
    トラックバックが送られてくる記事(エントリ)に関するURLは、必要ありません。カテゴリ別アーカイブのURLでも、月別アーカイブのURLでも、ブログのURLでも「リンクがある」とみなされます。また、トラックバック元ページ内にあれば良いので、URLは特に記事内に書く必要もありません。

  4. リンクの偽装は容易
    リンクの偽装は見破られませんでした。例えば、http://blog.livedoor.jp/UserName/../へのリンクは、URLとして解釈するとhttp://blog.livedoor.jp/ですが、href属性に指定されている文字列としてはhttp://blog.livedoor.jp/UserName/を含んでいるため、トラックバックを許可してしまいます。

  5. URLなしトラックバック拒否がばれる
    ブログのURLがどこにも含まれていないページのトラックバックを送信すると、トラックバック送信の結果としてエラーが返ってきます。これは、仕様上仕方ないのかも知れませんが、「ブログURLを含まないトラックバックを拒否する」設定であることがばれてしまいます。
    Seesaaブログの「トラックバック承認制」のように取り敢えずトラックバックを受理しておいて、その後自動的に削除する方がスパム対策としては強力なのですが、ちょっと残念です。

取り敢えず、気が付いたのは、こんなところ。結論としては、livedoor Blogのサーバが相変わらずスパム送信元であるということのようです。

因みに、はてなダイアリーはトラックバックにブログURLが必須なのですが、はてなの場合は、title属性の値にブログURLが含まれていたり、<!-- http://d.hatena.ne.jp/UserName/ -->のようにブログURLがコメントアウトされている場合でも、トラックバックが通っちゃいました(わは)。


トラックバック防止機能を本日公開しました! - livedoor Blog 開発日誌 2001年01月10日22:26
新たなTrackBackスパム台頭の予感 - ただのにっき 2006年01月04日
livedoorがスパムトラックバック送信対策? 2006年01月05日00:09
gooブログに「リンクなしTB」の受信拒否機能を、強く要望します - むだづかいにっき♂ 2006年01月05日14:33
トラックバックスパム防止機能の導入につきまして - livedoor Blog 開発日誌 2001年01月06日11:56
年末年始を写そう!livedoor ピクスリニューアル、トラックバックスパム防止につきまして - livedoor Blog 開発日誌 2005年12月28日17:52


livedoorがスパムトラックバック送信対策?

2006-01-05 00:09:13 | Net.body

今月10日から、livedoorブログのトラックバック送信?の仕組みが変更されるようです。

(中略)
■トラックバックスパム防止策導入につきまして
今まで、トラックバックによるスパムを防ぐためにいくつかの施策を行ってまいりましたが、2006年1月10日より、トラックバック元の記事にトラックバック先のブログURLが含まれていない場合、受付を拒否する仕組みを導入します。

この仕組みの導入により不特定多数のブログに無関係のトラックバックを送信することができなくなります。(以下略)

年末年始を写そう!livedoor ピクスリニューアル、トラックバックスパム防止につきまして - livedoor Blog 開発日誌
太字は、原文のまま。
赤太字は、引用者による。

一見「リンクを含む受信トラックバックのみ許可する」というよくあるオプションの導入かと思いきや、読みすすめていくと「リンクを含まないトラックバック送信を許可しない」とも書いてある。実際は、どちらなのだろうか。
# リンクなしトラックバック送信の受付拒否なのか?

できれば、両者または後者のみの導入であることを望む。何故なら、前者のみの導入の場合には、livedoorブログユーザは守られるが、livedoorサーバがスパム発信元であることに変わりはないからだ。livedoorブログがスパムトラックバック送信元の温床となっている現状で、livedoorがスパムを排除する方向に動いていることを実証するためには、livedoorがスパム発信サーバではなくなることに注力しなければならない。
# スパム排除の観点では、livedoorブログユーザの保護はどうでもよい

ただし、この施策で減少するのは、あくまで「livedoorがスパム発信サーバではなくなる」ことだけだ。残念ながら、livedoorブログに作られたスパムブログ(フェイクブログ)の記事から送られたことになっているスパムトラックバックが減少する訳ではないのだ。ということで、gooブログユーザ保護のために「リンクを含む受信トラックバックのみ許可する」というよくあるオプションの早期導入を、gooブログでも検討していただきたい。

それにしても、スタッフブログの類で複数のトピック(この場合ならピクスとトラックバック仕様変更)をまとめて書くのって、止めて欲しいなぁ。どうしても複数トピックをまとめて書きたかったら、告知のまとめ記事、告知詳細記事1、告知詳細記事2などに分けるとか、ID属性を使うとか、焦点がぶれないように工夫して欲しい。
# 今回のlivedoorの改善措置自体には賛成ですよ

どちらにしても、アナウンスを読むだけではよく分からない。仕方がないので、10日以降にlivedoorのトラックバック送受信がどう変更されたかを確認する必要がありそうだ。


年末年始を写そう!livedoor ピクスリニューアル、トラックバックスパム防止につきまして - livedoor Blog 開発日誌 2005年12月28日17:52
gooブログに「リンクなしTB」の受信拒否機能を要望します - むだづかいにっき♂ 2006年01月02日20:15:56
 (のコメント欄にある2006-01-04 16:50:45のコメント)
トラックバックスパム・pingスパム制限強化について - gooブログ スタッフブログ 2005年09月16日11:30
新たなTrackBackスパム台頭の予感 - ただのにっき 2006年01月04日

リンクを含む受信トラックバックのみ許可する
スパムトラックバックは、トラックバック送信先記事へのリンクが含まれていないことが多い。
よって、トラックバック受信側でリンクを含まないトラックバックを受け付けないだけでも、多くのスパムトラックバックを弾くことができる。
たとえ派生記事(トラックバック送信元記事の方が新しい場合)ではなく、関連記事(トラックバック送信元記事の方が古い場合)であっても、トラックバック送信先を本文や同じページのコメント欄に追記しておけば、真っ当な関連記事のトラックバックが弾かれることはない。
しかし、こんなよくあるオプションがgooブログにはないのよね…。
以下のブログシステム/サービスには、そういった自衛手段があるようです。

Movable Type トラックバック プラグイン リンク の検索結果
トラックバックのリンクチェック機能を追加しました - エキサイトブログ向上委員会 2005年12月08日12:00
トラックバックってなに? - はてなダイアリーのヘルプ

また、「トラックバック承認制」として、トラックバックは受け付けるがブログオーナが承認(許可)しない限り受信したトラックバック一覧に公開されないというオプションを導入しているところもあるようです。


2006年01月06日追記
やられました…。livedoorブログスタッフの日本語の不自由さに、負けたようです。

どう読んでも「送信に制約が(も)加わる」んだと思ったのですが、結局「リンクを含む受信トラックバックのみ許可する」というよくあるオプションの導入と既定値化だけのようです。
ブログの設定/管理画面のトラックバック受信設定に「参照リンクの無いトラックバックを許可する」という項目が追加されるだけ

念のため10日以降に「リンクなしトラックバック送信」ができるかどうかを確認はしますけど、アナウンスを信じるのであればlivedoorブログがスパムトラックバック送信の温床であることに変わりはなさそうです。

トラックバックスパム防止機能の導入につきまして - livedoor Blog 開発日誌 2001年01月06日11:56


サブドメインとサブディレクトリの使い分け

2006-01-03 00:06:26 | Net.body

『絵文録ことのは』に、「サブディレクトリとサブドメインの使い分けについての実験」という記事があった。サブドメインを乱立させない方が、SEO的には良くなるということだが、どうしてもひっかかる点があった。

もともとなぜサブドメインを使ったのか

 理由はあまりたいしたことではない。微妙にURLが短い。それだけのことである。


サブディレクトリとサブドメインの使い分けについての実験 - 絵文録ことのは

サブドメインを使っていた理由は「URLが短いから」ということなのだが、これがどうにも解せない。

例えば資料集のページは、以下のように変更したという。

【旧】 http://archives.twelve-girls-band.info/
【新】 http://www.twelve-girls-band.info/archives/

確かに旧URLと新URLだけを見比べれば、「URLが多少長くなるデメリットはあるが、SEO的に有利なサブディレクトリの方のURLに変更した」と読み取れる。しかしよく考えれば、サブドメインを使った旧URLと同じ長さのURLは、サブディレクトリでも実現できる。

【他】 http://twelve-girls-band.info/archives/

これなら、URLが長くなるというデメリットはない。そして、もっと解せないのは、現在http://twelve-girls-band.info/archives/にアクセスしても、旧URLや新URLと同じ内容が表示されることだ。
# トップページも、www.なしのhttp://twelve-girls-band.infoでアクセスできる

これは一体どういうことだ。SEO的な意図でURLを変更(というか新URLでもアクセスできるように)したことのお知らせは必要だと思うが、どうせならデメリットのないwww.なしの短い方のURLでお知らせすれば良いと思うのだが。

URLにwww.twelve-girls-band.infoを含める点に、何か理由でもあるのだろうか(とかいう)。


サブディレクトリとサブドメインの使い分けについての実験 - 絵文録ことのは 2006年01月02日17:58