2009/12/30(水)来年の暴露ウィルスのターゲットはTwitterか？
今年もWinny(Share)*1+暴露ウイルスが猛威をふるい、数々の情報漏洩が発生しました。
うっかりすると、この両者を混同して「Winnyは情報漏洩の原因である」と思い込みがちですが、この解釈は正しくないでしょう。
具体的な分析は高木先生が今まで十分にされているので、改めてここでは書きませんが、「Winnyというデータ流通プラットフォーム」はあくまでデータを流通させているだけで、それ自体に情報を漏洩させる機能はありません。「暴露ウイルス」はそのデータ流通プラットフォームを利用しているだけです。
高木先生の指摘には「Winnyは一度ネットワーク内に拡散した情報(ファイル)を削除、回収することがきわめて困難である」ことをして、「Winnyは欠陥ソフトウェアである」ことの根拠の一つとされています。(その他の指摘は割愛)
つまり、暴露ウイルスの作成者*2にとっては、Winnyの「一度情報が流通したら回収が困難」という特性がプラットフォームとしての価値になっていると言い換えることができるでしょう。
で、翻ってTwitterです。
すでにあちこちの識者が指摘していますが、Twitterは、一度投稿された発言を削除することがきわめて困難なプラットフォームです。これは、Twitterのシステム自身の問題だけでなく*3、Twitterと連携している検索エンジン、bot、各種ツールがばらばらの運用者の元で提供されていることに由来します。
原因は異なりますが、TwitterもWinnyと同じように「一度ネットワーク内に拡散した情報(ファイル)を削除、回収することがきわめて困難」という点は変わりありません。
であれば、Twitterもまた、暴露ウイルスが利用するプラットフォームとして十分に及第点なのではないだろうか……というのが今回の指摘の要点です。
実用性が今ひとつといわれると、その通りです。
そもそもTwitterでは一度に書き込める情報量が140文字程度に制限されているという点は、暴露ウイルスにとってはとても使いにくい特徴でしょう。ただ、画像や動画などのファイルにこだわらなければ、いろいろやり用はあるかもしれません。
まーそんなわけで。いつの日か「Twitterで情報漏洩ウイルス！」とかとか妙な話が出てきたときに「ほれみたことか」と言ってみたかったので、エントリ作っておきました、という程度の話だったりします。
でもまあ、この種のマッシュアップ手段が豊富なプラットフォームというのは、データ管理の一元性をちゃんと考えないと、碌なことになりませんね的な気持ちはありますね。たまたまTwitterは取り扱いが簡単な「140文字の文字列」と言うこともあって、ありえないぐらいに情報管理が拡散していますし。
うじゃうじゃ。
2009/11/24(火)【対策編】iモード専用サイトのhtmlソースの閲覧方法
という記事が出ていいました。
iモードブラウザ2.0のJavaScriptを調査･研究する過程で、iモード専用サイトのhtmlソースを閲覧する方法を発見しました。という話なんですが、なるほどねぇ。という感じです。
(中略)
今回発見した方法は、iモードブラウザ2.0のJavaScriptのクロスドメイン通信制限が、ホスト名ベースであることを利用して、クロスドメイン通信制限を突破しています。
なお、iモードアプリやiモードFlashでも同様なことが可能であると思います。
iモード専用サイトのhtmlソースの閲覧方法
ただ、この攻撃に対してであれば、それを防止することはそれほど難しくありません。
Apache httpdを使っている場合、.htaccessに以下の記述を追加しましょう。
もちろんhttpd.confに書いても良いです。(むしろそちら推奨)
※"www.example.jp"は自分の運用しているサーバ名
RewriteEngine On
RewriteCond %{HTTP_HOST} !="" [NC]
RewriteCond %{HTTP_HOST} !=www.example.jp [NC]
RewriteRule .* / [F]
(この設定の意味は「続きを読む」以降で)2009/11/06(金)本日発売「雲の世界の向こうをつかむ クラウドの技術」
| 雲の世界の向こうをつかむ クラウドの技術 丸山不二夫 (著), 首藤一幸 (著) アスキー |
ASCII書誌情報
首藤先生にお誘いいただいて、私も記事を書かせていただきました。
(追記)どこにも目次が掲載されていないようなので、勝手ながら掲載。元ネタはASCII.tehnologiesに掲載されていた広告。
(さらに追記)ASCIIのページが更新されたようです。目次も掲載されています。
もともとUNIX magazineに掲載されていた記事の再編集ということになっていますが、ご覧の通り相当書き下ろしが増えています。
■目次みなさんMapReduceとかDHTとかKVSとか分散DBとか書かれている中、一人「データセンター」の話を書いております。クラウド的なソフトウェアが乗ってくることを前提とすると、データセンターは何ができるのか、というのをつらつらと書かせてもらった次第です。
・クラウドの技術的特徴 (丸山不二夫/早稲田大学)
■最新・クラウドプレーヤーたちのサービス開設
・Windows Azureの世界 (丸山不二夫/早稲田大学)
・Windows Azureのデータベース (丸山不二夫/早稲田大学)
・Google App Engine (中田秀基/産業技術総合研究所)
・Amazon Web Service (浦本直彦/クラウド研究会)
・富士通のトラステッドサービスプラットフォーム (岸本光弘/富士通研究所)
・Hadoop/MapReduce (藤田昭人/大阪市立大学・IIJ-II)
コラム:Hadoopのハードウェアベンチマーク
・Force.comマルチテナントアーキテクチャ (岡本充洋/セールスフォース・ドットコム)
■クラウドを支える技術要素
・分散インメモリキャッシュとデータグリッド (佐藤直生/日本オラクル)
・スケールアウトの技術 (首藤一幸/東京工業大学)
コラム:key-valueストア
・グリーで活用されているkey-valueストア (藤本真樹/グリー)
コラム:kumofs (古橋貞之/筑波大学)
・データセンターの新しいカタチ (堂前清隆/IIJ)
■クラウド時代のアプリケーション開発
・クラウドの開発手法とデータモデル (荻原正義/マイクロソフト)
・クラウドモデリング (浅海智晴/edge2.cc)
プロフィールにも書いていますが、私は元々データセンター事業に携わっていたわけではなくて、以前はソフト屋だったはずなんですよね。(現在はデータセンター事業の部署におります)ということで、実は「ソフト屋から見たデータセンターの最新動向を、データセンター屋の立場から書く」みたいな一風変わった記事なっている気がします。
あと、この件とは直接関係ないのですが、来週広島でちょっとお話しさせて頂いたりとかそんなこともあったりします。資料まだ作ってるけどね!
まあ、IIJ GIOをよろしく、ということで :-)
2009/10/23(金)Google Analytics vs Yahoo!アクセス解析
すぐに本題を読みたい方は「続きを読む」からどうぞ。
某所で某サイトの運用をやっていたとき、非エンジニア系でY君という後輩がいました。
Y君は大変良い奴で物事に真面目に取り組む奴だったのですが……時々(しょっちゅう)妙なところで引っかかってワケワカンナクなる、という残念なところもあるやつでした。
そんなY君がある日「ウチのWebサイト(サイトP)と別のWebサイト(サイトQ)の訪問者数を比較すべし」という指令を受けた事から話が始まります。
サイトPとサイトQはどちらもそれなりにまっとう運営されているサイトで、両者ともアクセスログ解析ソフトを使って「PV」や「訪問数」を計測していました。そこでY君、特に気にせずにそれぞれのソフトが出力する「PV」「訪問数」をExcelにまとめて報告していたのですが、その報告を受けた人から「PとQのサイトの訪問数が釣り合わない」という指摘を受けたとか。
PとQは同じモノを扱っているサイトなので、訪問数も同じぐらいになるはずだ……と、いう理屈なのですが……とは言っても別サイトなので、訪問数が釣り合わなくてもおかしくないとは思うんですけどね。まあ、いろいろオトナの事情とかメンツとかあったようで……
で、Y君が困って相談にきたので、話を聞いたわけです。
話を聞くと、我々のサイトPはアクセス解析ソフトAを使っているのに、サイトQはアクセス解析ソフトBを使っているとか。
両方ともhttpdのlogを解析するタイプではあるものの、除外するリクエストの種類や訪問数の推定方法が異なっているので、集計後の数値が同じ基準かというと、そうではない。
ということで、「そもそもアクセス解析の数値は推計を含むもので、解析方法・解析ソフトによって値が異なる。どの方法で解析するのが正しいかという基準はない。*1別のソフトで解析された数値を単純に比較してもあまり意味がないよ」的な話をしたわけです。
しかし、数日後Y君がまた困った顔をしてやってきました。どうも上の人から絞られたようで、「サイトQの担当者は『自分たちの解析では正しい結果を出している』と主張している。サイトQが正しい結果を出せているというのに、サイトPで正しい結果が出せないというのは単なる怠慢だ。すぐに正しい数値を出してきなさい」という指示を受けたのだとか。で、「どうにかして『正しい数値』を出して下さい」と……。
技術的に誠実なことを正直に言ってはいけない局面もある、という教訓ですね。
ちなみにこの件は、サイトP側で解析除外するページとかUserAgentとかを諸々調整して、サイトPとサイトQの関係上相対的に「正しい」と思われる数値が出てきた辺りで何となく決着が付いた、と記憶しています。
さて、そんな壮大な前振りをしておきながら本題は別のところにあります。
2009/09/24(木)ASCII.technologies 背表紙の秘密
※追記ASCII.technologiesの背表紙には、巻数(月号)が二進数で刻まれてます。
速攻で突っ込みを頂きました。
月刊ASCII時代からの伝統だそうです。
偶然写真を掲載されている方がいらっしゃったので、リンク。
ななぼん日記略して「ななろぐ」 : さらば、ASCII
つーことで、にわか読者であることがばれてしまいました orz
トリビアでも何でもないけど。
先々月ぐらいに気づいたのかな。
緑で囲った部分。
これを指摘した人の話はまだ聞いたことがない。ちょっと嬉しい。
| 月号 | 二進数 |
|---|---|
| 2009/07 | □■■■ |
| 2009/08 | ■□□□ |
| 2009/09 | ■□□■ |
| 2009/10 | ■□■□ |
| 2009/11 | ■□■■ |
ASCII.technologies(アスキー・メディアワークス)