Hidehisa Watch

最近、ひょんなことからとあるネット系広告代理店の広告主プレゼンに付き合うことがあった。

もちろんこうしたケースは初めてではないわけで、なんとなくは感じていたけれでも、言葉として「腑に落ちた」。

ネット系広告代理店というのは（僕から見れば）若者が多く、正直広告業界の“すごいプレゼン”を見て学ぶことが少ないどころか、ほとんどない。

で、そんな彼らが広告主との間での「共通言語」にできるのは、“数字”だけ、なのだ。

インプレッション数、クリック数、CTR、コンバージョン率etc……… そんなキーワードを元に、さも「広告主は広告に対してＲＯＩに厳しく、そして数字でないと企画が通らない」と信じている。誤解の無いようにいっておけば、もちろんこれらの数字は広告がマーケティングの一部である以上、重要なものである。しかし、広告主が今求めているもの、そして“代理店の力量”が試されているものは、そうした算出式ではなく、むしろ、自分たちの商品・サービスがより人々に認知され、買ってもらえ、そして使い続けてもらうための「ストーリー」なのである。

以前にもこのブログで書いたのだが、ネット系広告代理店の中で自らの付加価値をあげることに成功しているところはほとんどなく、その分、「値下げ」という手段でしか勝負に出れない＝企画で勝負できない、ところが多い。これらは、「数字こそ全て」な提案がもたらす、悪しき道程だろう。

さて、話を戻そう。

上記したようにとある代理店のプレゼンに同席した際に、若干ながら口をはさまさせていただいた。その際、僕自身はいわゆる「数字」の話はしていない。彼らが提案した企画の内容について「こうなってこうなってこうなる」というようなストーリーと今の世の中の背景、期待されるユーザーの行動について説明しただけ。しかし、先方にはこの内容について納得いただいたようだった。

「具体的に説明する」ということはプレゼン・提案時に非常に大事なことだと僕は思っている。しかしながら、ネット系広告代理店の中では、それが「数字で説明する」ということに変換されがちなようだ。「数字で説明する」というのは、「具体的であること」のサブセットに過ぎないのであって、消費者の期待すべき行動を図示する、企画の意図を説明する、など「具体的」な話の仕方はいくつもある。だが、どうもネット系広告代理店はこの点でトラディショナルな代理店に劣る。つまり、「広告キャンペーンというストーリー」を語ることにおいては、まだまだ未成熟だ。その「ストーリー」がちゃんとしてあって、それを構成する「数字」がついてくるのが理想形なのだが。。。

そのためには、「ネット広告は（あるキャンペーンにおいて）何をミッションとするのか？」を企画の上で練ることが非常に重要。

「ＡＩＳＡＳのＳＡＳの部分です！」ということではない。

広告主のキャンペーンにおいて、理解促進を促すのか、購買を促すのか、それとも他の何かなのか？　そしてそれを広告主の商品・サービスに関連する言葉に変換する（たとえば、「理解促進を促す」⇒「＊＊＊の商品の＊＊＊という効能について理解してもらう」、「＊＊＊というサービスの＊＊＊な部分について理解させる」）ということをすれば、おのずと、ネットの特性を生かした「ネットがやるべきミッション」が見えてくるはず。

そう、この「ミッション」の部分が欠けてる企画が多いこと多いこと。

今のネットの企画が面白くなくなっているとしたら、「ネットになにをやらせたいのか？」について広告主と“握ってない”ことが大きいのじゃないだろうか。

ぜひこの「ミッション」（＝ネット広告がキャンペーンに果たす役割）についてちゃんと、広告主サイドの言葉に“練った”企画を入れていって欲しい。

そして「ミッション」がちゃんと入った「ストーリー」ある企画というものはきっと広告主に「共感」をもって受け入れられる。

そこからその実行可能性について「数字」で“検証”していく、そんなプロセスでできればベストだ。

I have managed to do this

The only way i have managed to do it, set the panel view parameters as “input on pane config”
and leave it empty in the panel pane config

view setting :
set the arguments to the view (i have set 3 : termid, date, rss feed)
check the arguments send in the url and set the view argument

this small code helped me debug the view arguments , set the header to

hope this will help someone

アメーバブログ-DBチーム
MySQL Enterprise の紹介
MySQL/Ruby

新ストレージエンジンSpiderの紹介

* これまでの高負荷に対応する更新系DBの分割は現実的にはアプリ側でのパーティショニングしかない
* Spiderストレージエンジンはこれまでより簡単な更新系DBサーバの分割方式とさらに足りないものをまとめあげた
* リモートDBに対してテーブルリンクを作成
* 更新系DBのクラスタリングができる

Spider使うと

o 複数代の更新DBをあたかも一台のように
o 書き込みを分散
* DB異なっていてもJOIN OK
* 複数のDB更新はDBで担保
* 導入時アプリケーションの修正が少ない
o パーティショニングを考慮していないアプリもOK
* Proxyの様に動作する?
o App - DB(Spider) x 1- DB(MyISAM) x 10

GoogleがGFE/1.3のサーバーですでに入れてる（feedproxyで確認）

Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.

Send us feedback at <span class=”notranslate”>sales at example dot com</span>.

<meta name=”google” value=”notranslate” />

実にお恥ずかしい。自分で管理しているサーバーをスパム送信の踏み台にされてしまいました。みだりに公開するようなことではないというご意見の方もいらっしゃるかもしれませんが、以て他山の石、同じ轍を踏む人が少しでも減るように、また、踏んでしまった人の問題解決の糸口になるように、でもお子供たちが安易にいたずらで真似できないように気をつけながら差し障りのない範囲で恥をさらします。

今回のインシデントのポイントは、Web サーバーに普通に置いていたオープンソースの PHP スクリプトの脆弱性をついて、サーバーをスパム送信につかわれてしまったという点。「自分は Web サーバーを借りているだけでメールサーバーは管理していないから関係ないや」と思っている人も、同じ手口でやられるかもしれないというところがミソ。

発覚のきっかけは、ある日突然 “Return to sender” なエラーメールが頻繁に送られてきたことでした。FROM フィールドを偽装して、私のアドレスから送られたように見えるスパムを送信されると、未達などのエラーメールだけが偽装された FROM のアドレス宛に返ってくる、いわゆるバックスキャッター現象が起こるのはよくあるので今回もそれかと思ったのです。念のためエラーメールの中身を覗いてみると、エラーになっているのは案の定どこかのスパマーがブラジルのドメイン宛に一斉送信していると思われるポルトガル語のスパム。ところが、ばらまかれているスパムの FROM は私のメールアドレスにはなっていない様子。返送された元メールのヘッダが記述されているエラーメールをよく見ると、スパムは私がメールサーバーに使っているサーバーの IP アドレスから発信されているように見えます。

さあ、大変。

まず tail -f /var/log/maillog で sendmail のログを確認。まだものすごい勢いでスパムを送信中のようです。
sendmail の設定をなにかのはずみで間違えてしまって、外のスパム送信サーバーからリレーされているのかと思ったのですが、ログには inbound のセッションがない。入ってきているのはエラーメールの戻りだけ。netstat を見てもスパムを送り込む内向きの SMTP のセッションはないように思えます。不正リレーじゃないようです。
エラーメールになった元のメールのヘッダをよく見ると、このサーバーの nobody ユーザーが sendmail を直接動かしているようです。top と ps -Unobody で見ると、なにやら怪しげな perl のプロセスががんがん動いているので、それを kill するとメールの送信が止まりました。ここで一息。宛先不明や Deferred でキューにたまっている送信待ちのメールを /var/spool/mqueue から削除して、誰がどうやって勝手に nobody さんにスパムを送信させていたのかを探った結果、わかったこと。

このメールサーバーは、私のブログなどの Web サーバーとは別のサーバーを借りているのですが、そこに友人などの別ドメインの小さな Web サーバーを又貸しで同居させて使ってもらっています。
その Web サーバーのうちの一つに Nucleus がインストールされていたのですが、それが古くて、組み込まれている XML-RPC for PHP のライブラリが脆弱性のあるバージョンだったのです（Aさん、ごめん。root 権限使って無断でディレクトリの中と Apeche のログをチェックさせてもらいました。緊急だったし、使ってないサイトのようだったから、許しなさい）。
このブラジルのスパマー（IPアドレスがブラジルのものでした）は、XML-RPCの脆弱性をついて、ブログの画像などを保存するために Web サーバーから書き込み可能になっているディレクトリに、“c99 shell” と言われているスクリプトを書き込んだようです。このスクリプトはリモートから nobody 権限でシェル操作できるバックドア（裏口）。そのシェルを使って /tmp に perl で書かれた “Data Cha0s Connect Back Backdoor” という名前の別のバックドアのスクリプトをほかのクラックされたサーバーからダウンロード。ダウンロードしたものを nohup で実行。そのバックドアを使ってこれまた /tmp に、 perl で書かれたメール一斉送信のスクリプトと、スパムの文面と、ブラジルのメールアドレスが大量に詰まった送信先リストをダウンロードしてから、メール一斉送信スクリプトを実行したものと思われます。

侵入の途中でメールのキューが大きくなりすぎてディスクのクォータを超えたために、バックドアがファイル書き込みエラーを起こし、シェルの吐いたエラーのかけらが Apache のエラーログに残っていました。おかげでスクリプトなどをダウンロードした形跡の一部が手に取るようにわかりました。相当数のほかのサイトがバックドアスクリプトやスパム送信リストのファイル置き場にされているようです。侵入からファイル送信までの手順は手慣れていて、その手順の間の HTTP のセッションは User-Agent が libperl-www になっているところを見ると、その手続きも perl で自動化して動かしている模様。たぶん、穴のありそうなサイトを手当たり次第に機械的につついているんでしょう。

というわけで、Nucleus に限らず XML-RPC を使ったプログラムを動かしている Web サーバーの管理者のみなさん。もしまだ脆弱性のある古いバージョンを使っているのなら、すぐにバージョンアップを。

また、まだ古いバージョンを使っている場合はすでに踏み台にされている可能性もあります。Nucleus サイトを攻撃する場合は media ディレクトリに最初のとっかかりのスクリプトをダウンロードする手口を自動化してこなしているようです。media ディレクトリに不審なスクリプトファイルがないかどうかをチェック。もしあった場合は /tmp など、ほかのディレクトリに不審なスクリプト（拡張子は txt かもしれません）や、メールの文面らしきファイルや、メールアドレスのリストになっている巨大なテキストファイルが置かれていないか、確認してくださいませ。

いやはや。ご迷惑をおかけしました。お恥ずかしい。

[url=http://www.nytimes.com/2008/10/19/business/19ping.html?_r=1&oref=slogin]Yahoo, Slowly Changes Home Page:[/url] Lessons For All
Yahoo began what may be its biggest overhaul of its home page. But if you are among the roughly 100 million Americans who stop by Yahoo.com every month, the odds are that you haven’t noticed any changes. That’s because the job of revamping the Web’s most visited portal page is fraught with risk. If even a small fraction of Yahoo’s audience doesn’t like the changes, the company could lose millions of users and millions of dollars in advertising. So Yahoo is introducing changes in small stages and to small segments of its audience at a time, all while soliciting feedback from its users.

You could call it stealth innovation. The company’s goal is to end up several months from now with a completely different, and presumably better, front page — with its audience intact. The effort is as much art as science and seeks to balance the company’s desire to innovate with its fear of alienating users. And it offers an example of how online services are designed and improved in a world where a rival’s offering is just a click away.