ブラウザのシェア

以下は、2006年11月(月間)での、とあるサイト(このブログじゃない)でのGoogleAnalyticsによるブラウザ統計である。許可をいただいたので掲載。

筆者の今後のつきあいもあるので「とあるサイト」以上のことは言えないが、日本語のサイトであり、「IT系の情報あるいは商品」に関するサイトではまったく無いことは付け加えておく。デルコンピュータみたいに肝心なところで「IEにしか対応してません」なんてこともなく、また、サイト管理者等のアクセスまでカウントされないようにIPアドレスその他でのフィルタリング設定はちゃんとされている。

ちなみにブラウザではなくプラットフォーム(OS)で見ると、97%がWindowsでMacは3%以下である。

「IEが9割超っていうのはもう古い話で、最近はFirefoxとその他をあわせて2割くらいはあるはずだ」とかいうまことしやかな話がここ1年ほどの間にちらほら散見される気がする。上の例にもあるとおり、残念ながらそれはほぼ間違いと言える。少なくとも日本国内では。

IT/Web業界の人にも二種類ある。一般ピープル向けのWebサイトの運営に実際にかかわっていて上のような本当にナマのデータを目にする機会がある人と、純粋にWebデザインやエンジニアリングだけをやっている人である。「Firefoxのシェアはもっとある!」という人はたいてい後者である。

ただ、「Webサイトの運営に実際かかわってる人」にもいろいろあって、例えば「日経IT Pro」の中の人は「Firefox?そうねえ、少なくとも1割は超えてるかな」とか言うかもしれない。そりゃそうだ。ITのプロ向けのサイトなんだもの。(笑)

特定のWebサイトのアクセス解析で得られるブラウザのシェアの数値は、そのWebサイトがどういう人向けであるかによって違ってしまう。特にIT/Web業界情報サイトだとかなり偏る。実際、このブログでのブラウザのシェアはIE7割、Firefox2割超である。

また、webalizerとかanalogとかそういうソフトの出す数値を何も考えずに信じてしまうのも危険だ。User-Agent情報にMSIE6.0と示して堂々とアクセスしてくるけど実は人間じゃなくてえたいの知れないクローラー(ロボット)だったりすることはまったく珍しくない。その点、GoogleAnalyticsのようなJavaScriptでビーコンを埋め込むタイプだと、ほとんどのロボットはJavaScriptまで理解しないのでアクセス統計から自然と除外される。ただしこの方式もまた、携帯電話のブラウザはJavaScript未対応がほとんどだったりしてうまく観測できないなどの弊害があるようだ。 ブラウザのシェアを観測したり資料を読んだりする際にはこうした点に注意したほうがいい。

ブラウザのシェアに関する資料はいっぱいありそうでいて実は意外と少ない。検索して見つかるのは古い資料だったり海外のデータだったりすることがほとんどだ。海外の調査会社による統計は日本国内ではあてはまらないケースが多い。

一番いいのはネットレイティングス社あたりにありそうな資料だが、有償だし。 Yahoo!Japanか楽天あたりが自社サイトでのデータをちょっとだけでも公開してくれればそれも信憑性が高いだろう。 今後のWeb業界の発展のためと思って少しは情報を出していただけないでしょうか?>各社様。

ホットペッパーAPIの仕様が微妙におしい件

最近公開されたホットペッパー.jp(hotpepper.jp)Webサービスについて、すでに似たようなことをリクルート(の関連会社)の中の人が言っているが

位置から引けないのは今後に期待。

唯一つ残念なのが、じゃらんや食べログのように、位置(緯度・経度)や駅名から検索できないこと。多分いろんな事情があるんでしょうけど、57万件のグルメ情報とあわせて今後に期待ですね!
ホットペッパーWEBサービス、リリース|blog|たたみラボ
かなり同意。

いまのホットペッパーAPIには、取得できる情報には位置情報(緯度、経度)が含まれておらず、また逆に位置情報で検索する機能もない。 正確な位置情報(緯度/経度)のデータがないと、Google Maps API とかYahoo地図情報Webサービスなんかとの連携が非常にやりづらいのだ。

正確な座標データがなくとも、住所は当然あるので、最近はじまったジオコーディング(住所の情報から緯度経度を割り出す)技術を使えばやってやれないこともないのだが、これがまた微妙なのだ。 たとえばホットペッパーAPIのリファレンスに例として載っている「東京都中央区銀座1-15-7 マック銀座ビル1F」という住所を、 ここで紹介されていたこのページでジオコーディング検索すると、

  • 「東京都中央区銀座1-15-7 マック銀座ビル1F」で検索→うまくひっかからない
  • 「東京都中央区銀座1-15-7」で検索→ひっかかるんだけど場所が少なくとも100メートルくらいずれている
というように、ビル名と階数まで明確なのがかえってアダになってしまったり、そもそも精度がよくなかったりする。 「この居酒屋の場所はこちら!」とか言って地図上に示したマークが実は100メートルほどずれてました、というのでは、車移動が基本の郊外ならともかく都心の繁華街ではかなり致命的じゃないだろうか。(精度求めすぎ?)

「なんとかAPI」が話題になるたびにバカの一つ覚えみたいに地図と組み合わせることばかり考えてないで、他の使い方を考えればいいじゃないかという話もある。 しかし、ほかの見せ方を考えるにしても、うまいのが思いつかない。 一覧でだーっと表示するだけというのでは通常の冊子のホットペッパーとの違いが出しにくい。 強いて言えば街しらべみたいな見せ方がいいのだろうか。

そもそも、ホットペッパーに載っているような種類の店に行こうと考えるユーザーの心理としては、 おいしい店とか雰囲気のいい店を知りたいというのが顕在化された欲求だが、実は特定の地点から徒歩or車で10分以内とかそういう「場所前提」で行ける店を知りたいという意外と強い潜在的な欲求があるんじゃないだろうか? 店の情報をパっと見せられたとき、「おっ?なんだそう遠くないじゃん」と思えてこそ「いっぺんいってみるか」と思えるのである。 逆にホットペッパーに広告を出す飲食店の人も、店の近くまで来ているのに店を知らない/来るきっかけをつかめないお客を呼びたいのだ。そうすれば駅前で声を張り上げてチラシを配る手間が省けるし。

そう考えると、実用的な精度での位置情報というものは、この手のサービスに必須のものなのではないだろうか。57万件もデータがあるのなら、なおさらだ。

追記。

もちろんAPIを提供する会社は使いやすいインタフェースのAPIを提供すべきです。そうしなければマッシュアップサイトの質が低下してしまうばかりか、いずれ人々の頭から忘れ去られ、APIを提供する意味がなくなってしまいます。

しかし、微妙な仕様が提供された場合でもなんとか解決策を模索するのがプログラミングの面白さではないでしょうか。
[F] APIが微妙なときでもなんとかする - F.Ko-Jiの「一秒後は未来」
お見事。完敗です・・・。

お名前.comでDNS情報管理サービスが開始

そう言われてみると、onamae.comはレジストラとしては大手なのに今までこのサービスはやってなかった。

お名前.comでDNSレコードを自由に設定できるサービスが開始 - CNET Japan
借りているレンタルサーバーとドメイン管理会社がまったく別、のような場合にDNS情報の取り扱いが難しいというか面倒だったのだが、これならそれほど知識が無い人でもなんとかなるのではないだろうか。

訂正ありご注意→セキュリティのセの字も考えてないライブドアの公衆無線LANサービス

=== 冒頭なのに追記ここから ===
いくつかのブロガーの方からツッコミ&追試を頼んだ個人的情報源からもタレコミをいただいた。 ライブドアワイヤレスのMACアドレス認証(ベータテスト開始)では、その「接続までのステップ」という解説を見るとMACアドレスだけで認証するかのように見えるのだが、実際のところは事前にWEPキー(申込み時に提示される10文字程度の英数字)を機器にあらかじめ設定しておくことが必要なので、以下に書いている「MACアドレスだけで認証うんぬん」という部分は間違いです。 WEPキー使うということは暗号化も一応されるということなので通信傍受に弱いという部分も間違いです。ただし、いまどきWEPじゃなくてWPA/WPA2使うべきだろとか言う話はもちろんあるものの、それを書き始めるとこの追記は恐ろしく長くなるうえにそのへんの話はもう何年も前からいろんなところで話題になっていることなので割愛させていただきます。

see also:
最速インターフェース研究会 :: livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事
情報処理推進機構:セキュリティセンター:無線LANのセキュリティに関する注意
=== 冒頭なのに追記ここまで ===

誰か止めるやつはいなかったのか。

livedoor Wireless MACアドレス認証 (注:2006/12現在はベータテスト扱い)

MACアドレスを元に機器の認証を行う仕組みです。お客様の端末のMACアドレスを事前にlivedoor Wirelessへ登録しておくだけで、従来必要であったWeb認証が不要になり、livedoor Wirelessのサービス提供範囲内に入れば自動的に高速無線LANが楽しめるようになります。

MACアドレス認証を新たにlivedoor Wirelessの認証方法として採用することで、今まで接続が困難であった、Webブラウザを搭載していない無線LAN搭載ゲーム機やPDA、携帯電話などからも簡単にlivedoor Wirelessに接続することができます。
どうやら、ライブドアの中の人は「正規利用者かどうかの確認=一言で言うと認証」がMACアドレスだけで可能であるというおそろしい勘違いをしているらしい。 わかりやすく言うと、「MACアドレスだけで認証する」ということは「その人が自分の電話番号を言えるかどうかだけで認証する」と言っているのに近い。クリーニング屋の受け取りじゃあるまいし!?

さらにおかしなことに、 MACアドレス認証(βテスト) Wireless Q&A livedoor ヘルプというヘルプページには、 Wireless 用語 m livedoor ヘルプという用語集へのリンクがあるのだが、そのMACアドレスフィルタリングの用語説明には次のようにある。

200612-livedoorwireless-02.png
MACアドレスフィルタリングとは

あらかじめ無線LANで利用する機器のMACアドレスを、アクセスポイントに登録をしておくことによって、登録されているMACアドレスを持つ機器以外からの通信を拒否できる機能のことです。

主に家庭用の無線LANに使われているセキュリティの一つです。 公衆無線LANの仕様上、livedoor Wirelessではこのセキュリティを利用していません。 (筆者注:「利用していません」というのは従来型の認証方式でのlivedoor wirelessの話であって、今回始まったMACアドレス認証というのはまさにこのMACアドレスフィルタリングのことである。)

登録されていない機器以外は接続できないため、新しいパソコンを購入した場合など、そのままでは無線LANを利用することができません。 必ずMACアドレスの登録作業が必要なため、運用が大変になるというデメリットがあります。 MACアドレスを偽装するツールなども存在するため、この機能だけでは、 完全に不正アクセスを防ぐことはできません 。
わかってるならなぜそれをやる!?!?

MACアドレスに関する誤解や、公衆無線LANサービスのセキュリティが今そうなっている理由についてまるで無理解であることが根底にあるのではないだろうか。

MACアドレスのよくある誤解その1: 「MACアドレスは無線機器毎に固定で完全に一意(他と重複が無い)なうえ、変更できないから、その機器が盗まれでもしない限り不正アクセスされる心配が無い」

そんなわけがない。確かに、NIC(ネットワークカード)ごとに一意になるようにMACアドレスが割り当てられているので、同じMACアドレスを持つNICはこの世にひとつしかない。しかしそれはタテマエ上の話である。実際にはMACアドレスを変更できるようになっているNIC(orそれを積んだ機器)はめずらしくない。こんなツールを使えばPCにささっているNICのMACアドレスをソフトウェア的に変更(つまり偽装)して使うことも可能だ。

MACアドレスのよくある誤解その2: 「MACアドレスはその機器(PC等)の持ち主しか知りえない」

そんなわけない。Windowsのコマンドプロンプトを開いて「arp -a」とたたいてみよう。
200612-livedoorwireless-01.png
このように、同じLANにいる隣近所のマシンのMACアドレスを見ることができる。IPメッセンジャーなど入れてる人は、その画面の「更新」ボタンを押した直後にarp -aすると非常によくわかるだろう。単純に隣近所のIPにpingを打ちまくってからarpをたたくという方法でもかまわない。ブロードキャストアドレスにping (ex. ping 192.168.xxx.255 とか)でもいいだろう。これは相手がPCであれネットワークスイッチ機器であれニンテンドーDSであれ区別は無い。 EthernetにおけるMACアドレスとはそういう仕様である。別におかしなことではない。

別にこんな技術的なテクニックを使わずとも、NICカード(orそれを搭載した機器)そのものにMACアドレスが書いてあったりすることもある。

こうしたことから、認証のための情報=第三者に簡単に知られるようなものではない情報=としてMACアドレスを代用することがふさわしくないことは明白である。

一般的な話、公衆無線LANサービスのセキュリティは次のような要素によって守られている。

  1. WEPキー
    通信内容の暗号化のためのキー。無線LAN電波が傍受されることによるセキュリティ侵害からユーザーを守るためのもの。
  2. 無線LANサービスのIDとパスワード
    利用権限の無い人(ex.契約してない人、お金払ってない人)がネットワークに接続してしまうことを防ぐためのもの。また、無線LANサービスを経由してなんらかの犯罪行為がされた場合に、犯人を特定するための手がかりにもなる。
  3. 無線LANサービスのIDとパスワードを打ち込む画面そのもの
    たとえばこのページの一番下の画像のような画面がブラウザに表示される。この画面は「これからあなたがつなごうとしているネットワークはライブドアワイヤレスですよ」というアピールでもある。 もしもライブドアとはっきり書かれていないorこの画面自体が存在しないと、ライブドアワイヤレスにつなごうとして、うっかり別の無線LANアクセスポイント(セキュリティ設定の甘いやつ)に接続してしまうかもしれない。
このベータサービスにGOサインを出したライブドアの中の人は、こうした無線LANのセキュリティの基本をまるでわかっていらっしゃらないようだ。 「(MACアドレスだけで)いきなりつながる」ということは、間違ってそのへんの「野良無線LAN」につながってしまいしかもそれに気づかないという可能性は十分にありうる。それでMACアドレス情報が簡単に第三者にばれる。それはユーザー責任?ああそうですか。

ライブドアがやろうとしていることは、通信電波の傍受によるセキュリティ侵害にも、MACアドレスの偽装による成りすまし被害にも、とてつもなく弱い。 どうやらライブドアは自社サービスネットワークをコンピュータ犯罪の温床として育てるつもりのようだ。

see also:

すべてはこのための伏線だった

24日に投稿ってあたりがもうネタとしか思えない。すべてはこのための伏線だったのか・・・。

はてなアイデア - システムの廃止を希望します。望まないリンクを推奨すること自体間違っています。
メリークリスマス!

see also:
リンクはTOPに貼ってください。これからリンクを貼ろうとしている方へ。強制義務とします。
相変わらず痛い

学者が三人集まると何も決まらない(「塾は禁止」 教育再生会議で野依座長が強調の件)

なにやら asahi.com:「塾は禁止」 教育再生会議で野依座長が強調(朝日新聞2006/12/23) という、一見すると「誰だこんなバカを座長に祭り上げたやつは?」といいたくなるような記事が話題らしい。

問題となった会議の議事録によると、確かにそんなアホくさいやりとりが見られる。 しかしその一方で、塾禁止を叫んだ本人が

(品川委員)←教育ジャーナリスト
日本ももっとgifted の教育をやったらいい。
(筆者注:gifted教育=いわゆる英才教育のこと)

(小宮山委員)←東京大学総長
それは全体でやることではないでしょう。

(小野委員)←日本学術振興会理事長
伸びる子は伸ばす。時間のかかる子については丁寧にやる。悪平等をやめること。

(野依座長)←理化学研究所理事長、ノーベル化学賞
200 人に1 人、とてもよくできる子供がいる。それを伸ばさないといけない。 才能ある子は国の宝だ。
なんてな発言もしてたりする。塾は禁止だけど英才教育には賛成? なんだかよくわからん。「200人に1人の超天才だけが優れた教育を受ければいいのであって残りの199人は学習塾にすら行くことすら禁止」とでもいうのか?まさかね。

つまり、この議事録をざっと見てわかる、識者とか言う人たちのしゃべってることの一見統一感がありそうでいて実はあまりない感じからして「学者が三人集まると何も決まらない」ということわざは真理であり、 もっと簡単に言うと「船頭多くして船、山にのぼりまくり」という、 お偉方の集まりにありがちな光景なのである。

*.htmlを*.html.gzに圧縮しても*.htmlのままでアクセスできるようにしてディスク容量を節約する

Webサーバのコンテンツ(html)が増えすぎて、ディスク容量が心細くなってきたんだけど、なんかいい方法ない?という相談をもらったので。

例えばApache2なら、次のような方法がある。

  1. gzipコマンドでhtmlファイルを全て圧縮してしまう。ファイル名は自動的に*.html.gzになる。内容にもよるが、これでディスク使用量は5~8割くらい削減できる。
  2. httpd.confに細工する。
    • 該当のディレクトリ配下でMultiViewsをオンにする。具体的には「Options MultiViews」 デフォルトではたいていもうこうなってる。
    • <IfModule mime_module>で「AddEncoding x-gzip .gz .tgz」がコメントアウトになっていたらそれをはずす
    • <Files *.html.gz>
        ForceType text/html
      </Files>
      を追加して、apache再起動。
  3. ブラウザでふつうに http://example.com/hoge.html とアクセスする。hoge.html.gzの内容が展開されて普通に見れる。
MultiVeiwsの機能とブラウザの圧縮/展開機能の組み合わせ技。圧縮状態で転送されるのでネットワーク帯域も節約される(利用者側から見ると閲覧が若干「軽く」なる)といううれしい副作用もある。 DEFLATE使うという手ももちろんあるが、それだとディスク容量の節約までにはならない。

別にそう珍しい手法ではないと思うのだが、実は意外と知られていないのか?と思った。

もちろん、ディスク容量を圧迫するほどのhtmlファイル数ってどんな量だ(笑)という話もある。 管理作業用のサーバでanalogだかwebalizerだかのアクセスログ解析結果のhtmlが日毎に蓄積され続けていて、気がついたらすごい量になっていてさあ大変、ということらしい。 お客様向けのマシンであればディスク追加なりなんなりですぐさま対応するし、そもそもいまどきそんな小さなハードディスクじゃない、しかし、大したアクセス数もない社内管理用の古くてしょぼいサーバでの話なので、予算をかけずにセッティングだけでどうにか切り抜けたかった、と。なるほど。

公衆無線LANがようやく安くなってきた

公衆無線LANは月額500円くらいじゃなきゃダメだ!とホリエモンが叫んで鳴り物入りで始まったライブドア ワイヤレスも、山手線の内側すら出ることができないまま今に至る。サービスの大幅な拡充の見込みはもちろん無さそうだ。あんな状態だし。

他のサービスはといえば、例えばDIONの公衆無線LANサービスが月額1500円、NTT東日本のフレッツスポットが月額800円と、なんだか中途半端に高い金額のまま今まで来た。しかもDIONのサービスはYahooの無線アクセスポイントを借りているだけだったりするし、そもそもプロバイダサービスの付加サービスという位置づけなので別途プロバイダ料金が必要=800円や1500円だけではすまない。

YahooBBモバイルというサービスが2年ほど無料で試験サービスをしていた時期はお世話になったのだが、昨年夏に終了となって、それ以降はYahooBBに契約している人だけが月額290円という値段で継続使用できていて、ちょっとうらやましかったような覚えがある。

で、このたびめでたく、

Yahoo!、月額210円から使える公衆無線LAN「Yahoo!無線LANスポット」 (Internet Watch 2006/12)

Yahoo!無線LANスポットの利用には「Yahoo!ウォレット」への登録が必要だが、プロバイダー契約の必要なしにインターネット接続ができる。
とのこと。 要するにYahooプレミアム会員費月額294円プラス210円=月額約500円で利用可能。 これはうれしい。

「不正アクセス禁止法違反のほう助」が怖くて心ある技術者もWebサイトの脆弱性をまともに指摘しなくなるかも?

さて、ちょっとタイムリーさを逃し気味ではあるが、Winnyの開発者が「著作権法違反のほう助」の罪で有罪になった件。とりあえず記事をいくつか。

ちょっと昔、週刊誌かなにかで「裁判官がおかしい」という見出しがさかんに踊っていた時期があった。いやほんと、この判決もおかしい。
  1. Winny自体は価値中立だ
  2. Winnyによって著作権侵害の蔓延を積極的に企図したとまでは認められない
  3. でも有罪。罰金刑が相当である。
禅問答にすらならないような意味不明の三段論法。

ちなみに、perl言語界隈の技術屋として有名な小飼氏はかなりご立腹。→ 404 Blog Not Found:極めて不当かつ想定の範囲内の判決

ちょっと話が飛ぶが、「こういう白とも黒ともつかないわけわからん結論を出さないようにするために裁判員制度をやるんだ!」という話もある。でも実はそうでもない。 たしかに、今後予定されている裁判員制度では有罪無罪の決定や量刑の判断については裁判官と裁判員の権限が同等ということになっている(へぇ)。しかし、裁判員が動員されるのは殺人などの重大犯罪の場合のみであり、今回のWinny裁判のような軽犯罪(っていうのか?)ではこれまでどおり裁判官のみで判断される。結局のところ、諸外国と比べると無罪判決を極端に嫌う日本の裁判官の体質と組織構造の問題は今後もずっと尾を引き続けるだろう。

とにかくしばらくの間、日本のIT技術はこのむちゃくちゃな判決にしばられっぱなしとなる。進歩の早い業界でそんな状況が長く続くことは致命傷になりかねない。

さてさらに話は変わる。

Winnyというソフトウェアが中心の話であるがゆえ、「ソフトウェアを作る自由が云々」といったような議論になりがちだが、筆者としては別な恐怖感を覚えた。著作権法違反という、どちらかいうと軽微なほうの刑罰に、「ほう助」の罪が簡単に適用されてしまうということは、他の法律違反でも「ほう助」で有罪にされてしまう可能性が飛躍的に高まってしまったのではないだろうか。

三井住友VISAカードのWebサイトには、「クレジットカード番号とその暗証番号を入力することでその会員の個人情報や取引履歴を表示する」という機能がある。もちろん、他人のクレジットカードの番号やその暗証番号を使ってここにログインすることを試みればそれは間違いなく「不正アクセス禁止法違反」で100%有罪である。

ところが、ここでいうクレジットカードの暗証番号はご存知のとおりたった4桁の数字。アルファベットも記号も使えない。インターネットから直接操作できてしかもお金にからむシステムにおいてこんな脆弱なパスワードシステムなどありえないことは言うまでもない。まったくもって言うまでもないことなんだが、あえてこんな資料を引用しておく。

金融庁の金融研究研修センターの「金融機関と情報セキュリティ」というフォーラムの概要報告書より抜粋 (コピーこちら

 インターネットバンキングについては、当初、SETなどの技術を利用して安全性を追及した形で導入が図られたが、使い方が難しかったことから利用者は増えなかった。ところが2000 年ごろにSSLを使って、単にパスワードを入れて認証するという方式を導入したところ、一気に普及した。そうしたシステムでは、「128bitSSLでお客様の情報を保護しています」という説明がよく使われるが、SSLはインターネットの中を電文が送受信される際に、インターネットにつながっている他のPCやサーバーからその内容が見えないようにしているだけであって、特別な認証技術ではなく、現実には認証はパスワードだけで行っているので、4 桁の暗証番号について1 万通りの総当り攻撃を行ったり、特定の文字列を当てはめたランダムな辞書攻撃により破られる可能性がある。そういう攻撃に対する防御は、ある程度は講じられているが、あらゆる手口に対してきちんと防御できているのか、という点については安心できない。
この資料はクレジットカード会社ではなく銀行のインターネットバンキングの話題なのだが、金融機関における4桁数字の暗証番号の脆弱性という点においては同じことだ。

いつごろからかは知らないが、三井住友カードは、ログイン方法にワンクッション入れるように変えた。

会員番号・暗証番号でのログイン方法が変わりました。

(1)従来の会員番号・暗証番号に加えて、画面に表示された4桁の数字を入力していただきます。
場合によってはあわせて生年月日を入力していただきます。

Vpassのログイン方法:三井住友VISAカードより抜粋
画面に表示された4桁の数字というのは、いわゆるcaptchaで、「ボット(bot)が種々のコンピュータのサービスを使うのを防ぐために使われる」ものである(Captchaとはより引用)。なぜ、ボットつまりソフトウェアが会員がログインするページに対して自動的にアクセスしてくるのを排除する必要が出てきたかって、それは先述の金融庁の資料にもあるとおり、「4 桁の暗証番号について1 万通りの総当り攻撃される」ことを少しでも阻止する目的なのだろう。

しかしおそろしいことに、三井住友VISAカードのサイトのcaptchaは、captchaとしての意味をまったくなしていない。笑っちゃうくらいお粗末な仕様なのだ。それについては次の解説が詳しい。

さらにその後、captchaもどきの数字をいれさせる画面に、その会員の生年月日をいれさせる欄もついた。だからなんだというのだろう? 振り込め詐欺みたいな高度なソーシャルエンジニアリングを駆使するまでもなく他人の生年月日くらい簡単に調べられるだろう。 上にも引用したが、Vpassのログイン方法:三井住友VISAカードのページには、「※場合によってはあわせて生年月日を入力していただきます。」という一文が付け加えられている。しかし筆者が試した限りでは「常に」生年月日の入力を求められた。どんな「場合によっては」なのだろう?苦し紛れすぎる。

認証のためのパスワードとは言えないもの=captchaになってないcaptchaとか生年月日とか=をあたかもパスワードのように扱うにはクレジットカードの会員用Webサイトというものはクリティカルすぎる。いまのお飾りのようなcaptchaがまともなcaptchaになるとしても本来のcaptchaの概念や目的にはまるでそぐわない。

そもそも、クレジットカード番号とその暗証番号でWebサイトにログインできてしまうような仕組みを提供しているカード会社が他にあるだろうか?とりあえずDCカード、ライフカード、ニコスカード、JCBカード、アメリカンエキスプレスをあたってみた。各社とも三井住友VISAと同様にWeb上で取引履歴などを閲覧できるサービスをやっていたが、その認証にはクレジットカード番号とその暗証番号ではなくまったく別のIDとパスワードを別途登録させてそれを使うようにしていた。 マスターカードはWeb上でのそういうサービス自体が見当たらなかった。

なるほど、三井住友VISA以外のカード会社は、まともなセキュリティ意識をもってサービスを構築しているようだ。

ちなみに、クレジットカードの不正使用による金銭被害はクレジットカード会社が補償してくれる、と思っている人が多いが、それはカード番号だけが漏れた場合の話であって、暗証番号がばれて被害にあった場合の補償はしてくれないのが一般的である。 三井住友VISAカードの会員規約にもその旨かかれているが、マスターカードの解説のほうが簡潔でわかりやすかったので紹介しておく。

ゼロライアビリティーの適用除外は以下のとおりです。
* (省略)
* 不正使用に際し、カードホルダーの確認手段として暗証番号(PIN)が使用された場合

MasterCard - ゼロライアビリティー より

さて、ここまで書いてしまった筆者には一抹の不安が残る。

なにしろ、クレジットカードという、犯罪の標的として非常にポピュラーな情報を取り扱うWebサイトを、技術的に見てこれほどお粗末な仕組みで運用してしまうようなおかしな人たちである。しかもセキュリティ意識の高い同業他社は手を出しもしないことで。こんなお粗末な仕様のWebサイトの脆弱さについて誰かがどこかに書くなりしゃべるなりしたら、おかしな人たちはその人を「不正アクセス禁止法違反のほう助」で告発してしまうかもしれない。そしてまるで技術知識のない警察の捜査員は真に受けて起訴に持ち込み、おかしな裁判官はおかしな禅問答を唱えておかしな有罪判決文を押し付けるのだ。くわばら、くわばら。

しょうがないので、「暗証番号の総当り攻撃」なんていう小学生でも思いつきそうな事柄についてさえ、金融庁とかそういったところの資料をひもときながら話をすることでいちいち予防線を張らなければならない。

話をちょっと極端にふってしまったけど、そういうことだ。 きゅうくつな世の中になったものである。

追記:↑は小飼氏の記事と思い切りかぶっていたので(気づけよ自分)それもなんなのでこっちも紹介↓

百式の中の人、RFC違反はもちろんWebサーバ運営者の迷惑をまるで考えない設定を推奨するの巻

ブラウザやOSの設定で最大同時接続数を増やせば快適ネットサーフィン!という方法の話はここ数年の間に出ては消えを繰り返している。だが、百式のようなある程度のネームバリューをひっさげたサイト(注:100shiki.comそのものじゃないが同じことだ)がこのような紹介の仕方をするばかりでなく、コトの大きさを理解していない様子すらうかがえるのは、はっきりいってよろしくない。あまりこのようなタイトルのつけ方をしたくはないが、残念だ。

問題なのは、百式ではなくてその姉妹サイトとして最近始まったp o p * p o p - 世界のニュースをクオリティ重視で -というサイトの、次の記事である

これは必見!FirefoxとIEを高速化するための動画チュートリアル
windowsのレジストリをいじってIEの同時接続数を増やす手法が紹介されているが、
  1. 要するにこれはひとつのWebサーバにたくさんの接続を張ろうとする手法であり、当然ながらWebサーバ側の負荷は増大する。
  2. RFC2616には「同時接続数はhttp/1.1では2まで」と明確に定められている推奨されている。(追記!正確には「MUST=しなければならない」じゃなくて「SHOULD(NOT)=すべきでない」となっている。失礼しました)紹介されている手法はこれに明確に違反している。
マイクロソフト社のサポート情報にも次のような記述がある。
WinInet は、HTTP 1.0 サーバーあたりの同時接続数を 4 に制限します。HTTP 1.1 サーバーあたりの同時接続数は 2 に制限します。HTTP 1.1 の仕様 (RFC2616) で接続数 2 が上限と定められているためです。HTTP 1.0 の接続数 4 は自主的な制限ですが、代表的な多くの Web ブラウザで使用されている標準に適合します。
(中略)
注 : これらの設定を変更すると、WinInet は HTTP プロトコルの勧告に準拠しなくなります。この変更はどうしても必要な場合以外は行わないでください。また、これらの設定が有効な間は、通常の Web ブラウジングは避ける必要があります。
[INFO] サーバーあたりの接続数を制限する WinInet(Microsoft 2005.9)
WEBサーバの管理者たちは、たくさんのアクセスをさばくために常日頃から涙ぐましい努力をしている。こういうイレギュラーなことをしないようにしようねというためのRFCなのに、何だと思っているのだろう?

Webサーバ管理者たちの涙ぐましい努力も届かない場合には仕方がない、下のような機材を購入してなんとかすることになる。

このように、アクセラレータやその機能を含むロードバランサなどの機器は、TCPコネクション(接続)の集約という機能を目玉のひとつにおいてあるケースが多い。それはWebサーバにとってTCPコネクションの確立と維持に食われるパワーはバカにならないということの裏返しでもある。 だが、こんな高価な機材を導入できるWebサイトなど、世の中のほんの一握りでしかない。

ちょっと話が飛ぶが、格安レンタルサーバーで有名なさくらインターネットでは、Webサーバの負荷が一定を超えるとステータス503(一時的な接続不能)を出して機能しなくなるようになっている。

503についての回答
さくらインターネット 共用サーバは、アカウント当たりの負荷が一定を 超えると「503 Service Unavailable」が出ると聞きました。
それが仕様ならば、アカウント当たり どれくらいの負荷がかかると 503 Service Unavailable が出てしまうのでしょうか?
そのあたりが明示されていないので質問しました。 よろしくお願いします。

申し訳ございませんが、制限の詳細な値は社外秘とさせて頂いております。ご了承くださいますようお願いいたします。
お客様の申されますように、さくらのレンタルサーバは共用サーバとなりますため、1台のサーバを複数のお客様にて使用いただくこととなります。
そのため、1人のお客様がサーバの性能を使い果たし、他のお客様へご迷惑をおかけするということが無いよう、1人のお客様が使用できる性能に上限を設けております。
同サーバに登録されている他のお客様へご迷惑をお掛けすることの無いよう運営下さい。
以上よろしくお願いいたします。
503についての回答(さくらのレンタルサーバ非公式FAQより抜粋)
そして、www.100shiki.comはさくらインターネットの共用レンタルサーバー上で運営されている。
$host www.100shiki.com
www.100shiki.com is a nickname for 100shiki.com
100shiki.com has address 219.94.128.141(←さくらインターネット所有のIPアドレス)
繰り返すが、WEBサーバの管理者たちは、たくさんのアクセスをさばくために常日頃から涙ぐましい努力をしている。このFAQはその現れの一つだ。 しかし、百式の中の人が「これは必見!」と推奨する設定は、こうした努力を無にするばかりでなく、百式のサイト自体の首すら絞めるかもしれない。

筆者はRFC原理主義を気取る気は無い。実際のところ、RFC2616が発行されたのは1999年であり、そのころに比べれば現在の各種ネットワーク、サーバー機器のハード/ソフトの性能は格段に向上している。ならば、2とか4といった同時接続数の規定推奨値はもう少し大きくてもいいのかもしれない。

だがしかし、Webサイトの数もネットワーク利用者数も同様に爆発的に増えていることも忘れてはならない。そういったことを加味すると、ブラウザの同時接続数を素人判断で増やすこともそれを推奨することも危険すぎる。 少なくとも百式のようなWeb業界で高い見識アリとみなされているサイト(の姉妹サイト)で「これは必見!」などと自慢げに話すようなことではまったくない。「問題があるようです、コメントをご覧ください云々・・・」と追記されているが、問題の大きさに比べるとこの一文は不十分すぎる。大変残念だ。

迷惑メールのレピュテーション(スコアリング)サービスも実はRBL上の誤ったデータに大きく左右されてしまう

結論:

  • spamhaus.orgを始めとする各種のRBLの情報をいわゆる「レピュテーション(スコアリング)」を通じて間接的に利用しているだけでも、実は、弊害=正常なメールをスパムであると誤判定=が発生するケースが大いにありうる。
  • にもかかわらず、そうしたレピュテーション(スコアリング)サービスを過信しすぎてしまっている人が意外と多い。RBLだけでなく他の複数の情報も加味しての総合判定(スコアリング)であっても、信頼性の低い情報を基準に含めてしまった判断はやはり信頼性が低くならざるをえない、という当たり前の理屈に帰着するはずなのだが、「レピュテーション」といった聞きなれないカタカナによる催眠術(ITベンダーの常套手段)に惑わされて妄信してしまうのだろうか。

さて、この「Web屋のネタ帳」はあくまでWebがらみのビジネス、デザイン、エンジニアリングに関する話題が主なのだが、ここんところ迷惑メールがらみの話が多くなっていて食傷気味の読者もいらっしゃるかもしれない。どうもすみません。もうこのネタも尽きるのでおつきあいいただきたく。 それに、spamhaus.orgに個人的な恨みがあるわけではまったくなく(笑)、いろいろ調査してみたら客観的に見てこれはまずいだろうと思うことが多々見つかったため取り上げているだけである。

また、この記事ではこれまでと違い、「推定」の部分がやや多くなることをお断りしておきたい。

というのは、これから説明する「レピュテーション(スコアリング)=迷惑メールの評判による判定」というサービスは、その技術仕様が完全にオープンであるものがほとんどなく、肝心かなめの部分はそれぞれ企業秘密となっているため、確信に迫ろうとするとどうしても推定にならざるを得ないのだ。 また、実例として出すとあるECサイトでの事件についても、筆者の今後のつきあいもあるので「とあるECサイト」とまでしか書けないこともご了承いただきたく。

さて、先日も紹介したInternetWatchの下記の記事は、最近日本で開催されたEメールセキュリティカンファレンス2006での話が元である。カンファレンスの席上で、NTTPCコミュニケーションズの中の人が次のように発言している。

また、RBLを利用する側に対しては、「RBLだけを参照して接続拒否せずに、あくまでRBLをスコアリングの材料として使い、ホワイトリストを併用して欲しい」「利用するRBLがどのようなポリシーで運用されているのかを理解し、導入することのリスクを理解した上でRBLを利用して欲しい」との希望を述べた。さらに、RBLを組み込んだ製品のベンダーに対しては、RBLを利用していること、どのRBLを利用しているのかを明記し、RBL利用のオン・オフを可能にすること(デフォルトはオフ) 、RBLだけを参照して接続拒否せずにスコアリングの材料にしてホワイトリストを併用できるようにして欲しいといった提案をした。
迷惑メール対策ブラックリストの功罪について「Spamhaus」と国内ISPが議論 (Internet Watch 2006/11)
これは本当にそのとおりだ。ただし、その「スコアリング(レピュテーション)」の仕様によっては大きな落とし穴が待ち構えていることは知っておいたほうがいいだろう。とあるECサイトで実際に起きたメール送信不調の多発事故をからめながら、話を進めたい。

実在するあるECサイトでは、注文があるたびに注文者と担当者にそれぞれ確認のメールが自動的に送信される。さらに週に一度メールマガジンを発行する。一度にメルマガを配信する数は1万通には満たない程度。オープンソースのECサイト構築ツールを入れたLinuxサーバを自社内に設置し、プロバイダの固定IPアドレスサービスとドメイン提供サービスを使ってサイトを運営している。Webサーバもメールサーバも全て1台のLinuxマシン、1個の固定IPアドレス上にあり、そのECサイト以外のサービスは稼動していない。

ある日、発信したメールマガジンが大量にエラーで戻ってきた。いくつかのプロバイダあるいは無料メールサービスのアドレス宛てのものだけが。原因をさぐると、spamhaus.orgにIPアドレスが登録されていることが判明した。ただし、ECサイトのIPアドレスが狙い打ちされたのではない。スパムの発信元は別のIPアドレスであり、例によって/24といった形で広範囲のIPアドレスブロックが丸ごとブラックリスト登録され、たまたまそれにあたったECサイトが巻き添えになったのである。

さらに調査を進めると、spamhaus.orgの情報だけでスパム判定しているプロバイダだけではなく、 統合的なスコアリングサービスを使っているメールサービスのアドレスにおいても、メルマガが不達になっていることが判明した。 RBLの情報のほかの判断基準も含めた上でスパム判定をしているがゆえに誤判定率の低いはずのスコアリングシステムにおいて、いともあっさりと誤判定が発生してしまった。いったい何故?

さて、そもそもスコアリング(レピュテーション)とは何なのか? ここではひとつの例として、IronPort社が提供するsenderbaseというデータベースを利用したスコアリングについて、次の説明を借りることにする。

プロファイリングで悪質メールを見抜くIronPort (ITmedia エンタープライズ 2005/12)より抜粋

SenderBaseでは、メール送信サーバのIPアドレスをはじめ、メール送信の量、ドメイン名やそれを取得してからの期間、国籍、そのドメインでメールを送信し始めた時期など、約100種類に及ぶ属性を収集し、推移を記録している。RBL(Real-time Blackhole List)も併用できるが、単純に送信元アドレスだけで判断するのではなく、さまざまな要素を加味してスパム/フィッシングなどの悪質なメールかどうかを判断する仕組みだ。

 例えば「トヨタ自動車を名乗るメールが手元に届いたとして、そのIPアドレスは果たしてトヨタ自動車が所有しているものか、所有期間はどのくらいか、送信元の国はどこか、はたまたそのアドレスから1日にどのくらいのメールが送信されているかといった複数の要素を勘案してメールのスコアリングを行う」(バティア氏)。単純にブラックリストと付き合わせる場合に比べ、正確で公平な仕組みだという。
こういった仕組みのことを「迷惑メールのスコアリング」という。これはレピュテーション(評判、世評)とも呼ばれている。この記事ではIronPort社のSenderbaseの話を事例の中心にすえるので、以降はIronPort製品の説明で使われている「レピュテーション」という単語を使って話を進めることにする。

次に、IronPort社の運営するsenderbase.orgについてだが、例えばつい最近(12月16日の夕方)に筆者の手元に届いた出会い系詐欺=主人がオオアリクイに殺されました、みたいな(笑)=の迷惑メールの発信元IPアドレスが、送信されてからざっと24時間たったいま現在でsenderbase.orgではどのように把握されているのか?

http://www.senderbase.org/search?searchString=210.85.64.183
(12月17日現在の画像こちら
※データは時々刻々と変わってしまうので、できれば画像のほうをご覧ください。
背景がピンク色になっている箇所を見てのとおり、メール送信量の急激な増加傾向と、RBLの登録が数件あることがわかる。他にも、IPアドレスで引いたwhois情報などのデータも見れるようになっているが、ここではunkown(不明)のままのようだ。ここで勘違いしやすいのが「メールの送信量」だ。これは「スパムの送信量」ではない。あくまで「メール」であって、それが正常なメールかスパムかどうかの区別はないということに注意していただきたい。

このように、senderbase.orgではスコアリングの状況がある程度公開されている。 ただし明確な数値=スパム判定度=は公開されていない。つまりそれぞれのパラメータにどの程度の重み付けがなされ、どのような計算式を持ってスパム判定度が数値化されるのか?は非公開であり、ここではIronPort社が提供するハードウェアなりサービスなりを有償で買って初めて明確な数値を得ることができる。

それでも公開されている情報をもとにしてどのような判定がなされるかはある程度の予想が可能だ。 ここで、上に書いたとあるECサイトと、それに巻き添えを食わせるきっかけとなったスパム送信サイトについて、senderbase.org上のパラメータを書き出して、比べてみることにする。

  スパム送信サイト とあるECサイト
IPアドレス 192.168.1.50 192.168.100
メールの送信量の規模(マグニチュード) 3.5 3.7
メールの送信量の前日からの増加率 800%超(大量にスパムを出しているのだから当然) 600%超(普段は注文確認のメールが主なのに今日は数千通の単位でメルマガを出しているのだから当然)
spamhaus.orgでの登録有無 192.168.1.0/24 でのブラックリスト登録にマッチ (本来は192.168.1.50だけで登録すればいいものを/24でその周辺のアドレスブロック全てをブラックリストにいれてしまっている)
whois情報 unknown(詳細は不明だが逆引き設定してないせい?)
その他 senderscoreやTRUSTeの登録:なし
この数値やIPアドレスは実際のものではない。しかし、もしもこのようなパラメータであれば、とあるECサイトが発信するメールとスパム送信サイトが発信するメールのスパム判定度の数値は似たような感じになるだろう、という点はわかっていただけると思う。つまり、「判定基準が複数あっても、それらの数値が似たようなものなら、計算されるスパム判定度には大差ないのではないか?」ということである。

もちろん判定基準となるパラメータはこれだけでは少ない。IronPortのsenderbaseであれ他のサービスであれ、パラメータはもっとたくさんあるだろう。しかしそれらの測定方法や統合計算式は明確ではないなのでなんとも言えない。ただ、現実としてレピュテーションサービスによるスパム判定に誤判定は発生した。その原因をさぐると、このような疑惑を感じざるを得ないというのが筆者の素直な感想である。

ここでもしも、spamhaus.orgによる/24という広範囲なブラックリスト化を基準に含めなければ、あるいはspamhaus.orgが/24のような無茶な設定をせずに的を絞ったIPアドレスのブラックリスト化をすれば、最終的なスパム判定数値はかなり違うものになったのではないだろうか。やはり、信頼性の低い情報を基準に含めてしまった判断はやはり信頼性が低くならざるをえない、という当たり前の理屈に帰着するのである。

「うちはレピュテーションサービスだから大丈夫だ」という人は少なくない。しかし、実際のところどういう方法で基準となる値を測定して、それをどういう重み付けでスコアリングして、どういう計算式で最終的な判定数値にしているの?と聞かれて明確に答えられる人はまずいない。

何もかも疑ってかかるのは疲れるし効率的ではない。しかし、有償であっても肝心な部分がよくわからないサービスに頼るということは、こういう落とし穴にはまり、かつそれに気づかないというリスクをはらむことでもある。だからこそ、紹介したInternetWatchの記事でも「ホワイトリストを併用して欲しい」ということをプロバイダの中の人がしきりに言っているのだ。

see also:

相変わらず痛い

相変わらず痛い。

はてなの方針は万引きを推奨するのと同じ。
そんだけ。

see also:
リンクはTOPに貼ってください。これからリンクを貼ろうとしている方へ。強制義務とします。

追記:

さらに痛い。

リンクフリーの正しい意味は、サイトの入り口のページのみなんです。

GoogleMaps APIのジオコーディングが日本でも開始

これはすごい。待ち望まれていたこと。

Google Maps APIでも、日本の住所や駅名によるジオコーディングがご利用いただけるようになりました。Maps APIを利用したサイトでは、Google マップと同様、ユーザーが入力した住所の緯度経度を割り出し、表示される地図の場所させることができようになりました。
Google Maps API Official Blog: Japanese Address and Placename Support Added to the Geocoding API
実は今年の6月に一瞬使えるようになっていたのだが、 なぜかすぐに日本だけ使えないようにされていた。
Update: Removed Japan from the list of countries for which we offer street-level geocoding, as it is not available there. たいへん申し訳ございません。 m(_ _)m
Google Maps API Official Blog: Geocoding at last!
地図提供会社との権利関係の問題かなあと個人的にかんぐっていたのだが、解決したかな?

spamhaus.orgの「明確な悪意」とそれを知らずに使ってしまうスパム対策ベンダーと利用者

結論:

  • spamhaus.orgはスパムそのものの発信源とはまったく無関係なIPアドレスを誤ってではなく確信犯的にブラックリストに登録してしまうことがよくある。これはいわばテロ行為といわざるを得ない。
  • しかし利用者の多くは「spamhaus.orgに載ってるIPは多かれ少なかれ迷惑メールの発信元となったIPアドレスなのだ」と思って利用している(そりゃそうだ)。spamhaus.orgの運営チームとその利用者の間にはこの点で大きな認識のズレがあり、利用者の多くはそれに気づいていない。

さて、「またspamhausの話か」と飽きてる読者もいるかも知れないが、こういう報道↓があったので。

迷惑メール対策ブラックリストの功罪について「Spamhaus」と国内ISPが議論(InternetWatch 2006/11)
- ISPがRBLの弊害を報告、無実の顧客がとばっちりを受ける事例も -
筆者が「spamhaus.orgをはじめとするIPアドレスベースのブラックリスト(RBL)を使ってはいけない」という11月始めに書いた記事にも大いに通じるところがある。この件の続編をそのうち書こうと思っていたのだが、ちょうどいいので書くことにする。

上で紹介したinternet watchの記事には、次のような内容がある。

また、KDDIの対応に対してSpamhaus側が「KDDIはスパマーを支持している」と判断し、「報復」(Spamhausは「エスカレーション」と表現)処置として全く関係のないアドレスを含むブロック単位でRBLに登録したものもあったとしている。
KDDIのケースではないが、いままさに起きている「報復」の実例をここに紹介しよう。

SBL47194(12月4日現在の画像こちら)では、日本のGMOインターネットグループという企業が管轄するIPアドレスが、スパム送信元としてブラックリストされている。

しかし、本文をよーく見てみよう。そもそも、どのIPアドレスから、どんなスパムが送信されたというのか?

20060708 A prime example of how GMO is a spammer paradise:

1 - whois hiding
2 - fast NS changing

aerujan is a deaiscam, currently being spammed from OCN
Received: from host (p5046-ipad64marunouchi.tokyo.ocn.ne.jp [219.165.12.46])
http://5596.jp/?onanie
HTTP request sent, awaiting response... 302 Found
Location: http://aerujan.com/? [following]
Connecting to aerujan.com[222.12.154.219]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /pc/? [following]

(以下は筆者による日本語訳)

2006年7月8日。GMOがいかに迷惑メール業者にとってパラダイスであるかの主な一例。
1 - whois情報を隠している
2 - NS(ネームサーバの登録)をちょこまか変更している

aerujanというのは出会い系詐欺(のサイト)だ。最近ではOCNから発信している。
Received: from host (p5046-ipad64marunouchi.tokyo.ocn.ne.jp [219.165.12.46])
http://5596.jp/?onanie
HTTP request sent, awaiting response... 302 Found(HTTPリクエストを送るとHTTPステータスコード302で別サイトにリダイレクトされる)
Location: http://aerujan.com/? [following](リダイレクト先)
Connecting to aerujan.com[222.12.154.219]:80... connected.(リダイレクト先であるaerujan.comに接続中。。。接続!)
HTTP request sent, awaiting response... 302 Found(またリダイレクト)
Location: /pc/? [following](転送先。http://aerujan.com/pc/? にリダイレクト
ここでおさらい。そもそもSBL47194で登録されているのは 210.157.4.96/27 つまり 210.157.4.96 から 210.157.4.127 までの32個のIPアドレスである。しかし、上で引用した文章にあるIPアドレスにはどれも該当しない。

実はこのSBL47194は、

  • 210.157.4.96/27 から出会い系サイトの迷惑メールが発信されたという事実はどこにもない(そのことが記されていない)。
にもかかわらず、
  • GMOインターネット(の中核事業のひとつであるお名前.com)が提供するWhois情報代行サービスによって、aerujan.comというドメイン名のWhois情報が見えなくなっている。これはスパマーの正体を暴くうえで障害だ。
ということが問題であるとして、
  • ***@gmp.jp または ***@gmo.co.jp つまりGMOの従業員が使っていそうなメールアドレスのメールサーバ=mx.gmo.jp=210.157.4.112 を狙って、それを含む 210.157.4.96/27 というIPブロックすべてをブラックリストに登録しましたよ
ということなのである。「えっ?つまりそれって意図的な業務妨害じゃないの?」と思ったあなた、そのとおりです。

なお、筆者はGMOインターネットの回し者ではなく、縁もゆかりもビジネス上のご縁もいまのところ一切ないことを宣言しておく。また、前提として知っておいていただきたいのだが、 whois情報の代行はお名前.comの独特のサービスでもなんでもない。世界で始めてレジストリサービス(ドメイン名登録サービス)を始め、現在もレジストリ業者として大手といえるNetwork Solutions社(現在はベリサイン社傘下)においてもやっていることであり、他の大手レジストリ業者も同様のサービスをやっている。

whois情報の代行サービスそのものについても、何の前提もなく思いつきで実行されたものではない。 やってもいいかどうか、かなり議論されたうえで実際にサービス化されているのである。その件に関する資料はいろいろあるのだが、とりあえず2003年モントリオール会議のときのワークショップのメモがJPNICにあったので紹介。

まとまってはいないが、少なくとも、whois情報のあり方についてはいろんな人がよってたかって議論をしたという経緯があったということはわかっていただけると思う。

にもかかわらず、SBL47194では、2001年という非常に古い段階でのICANNの合意書を引用しつつwhois情報代行サービスの存在を悪者扱いしようとしている。2001年の後にも議論がいろいろあって、今があるんだというのに。

もちろん、意見を言うのは自由だ。本当にwhois代行サービスを問題と考えるなら、それ相応の議論の場において意見を言って状況を変化させることを試みるべきだろう。にもかかわらず、今の状況が自分達にとって不満だからブラックリストという武器を取ろう!という考えは、我こそは正義と叫んで爆弾抱えて突入する人とどっこいどっこいであり、要するにテロである。

いや、それどころか 「spmahaus.orgの提供するIPアドレスのブラックリストは、スパムの発信源となったIPアドレスだ」、と信じて利用しているユーザーに対する裏切り行為とも言える。 しかし、smaphaus.orgは「それは誤解だ」と強弁するだろう。SBLのトップページには次のようにあるからだ。

The SBL is a realtime database of IP addresses of verified spam sources and spam operations (including spammers, spam gangs and spam support services), maintained by the Spamhaus Project team and supplied as a free service to help email administrators better manage incoming email streams.

(以下筆者訳)
SBLは、スパムの発信源またはスパム活動の場である(つまり、スパマー、スパムギャング、スパムサポートサービス)と確認されたIPアドレスのリアルタイムなデータベースです。データベースはスパムハウスプロジェクトチームによってメンテナンスされており、電子メール管理者にとって流入するメールをコントロールする手助けとなるサービスを無償で提供しています。
GMOインターネット社は、上で言うところの「スパムサポートサービス」だ、だからわれわれのブラックリストに入ってていいんだ、という理屈。

くりかえすが、多くのユーザーは「spamhaus.orgのSBLに登録されているIPアドレスは迷惑メールの発信源である」という認識でそれを利用している。がしかし、実際にspamhaus.orgのメンバーがブラックリスト登録する判断基準からすると、そこには無視してしまうには大きすぎる認識のズレがあるということは知っておくべきだ。特にspamhaus.orgの情報を使用するように設定した製品やサービスを提供している企業の中の人!それでもあなたは、spamhaus.orgをデフォルトで使うようにしたままでリリース/出荷/提供しますか?

see also: