天然水で健康生活！

健康生活をおくるのに必要不可欠！　 天然水の販売一覧。ゆっくりとお楽しみ下さい。

このページはハイパーコンテンツビルダーが 2008年 07月 15日 23時32分07秒 にクロールしたキャッシュ情報です。

自宅とは？

[ 58] 自宅サーバーで行こう - Windows XP & ADSL編
[引用サイト]　 http://www.y-kit.jp/saba/

ADSL回線とWindowsパソコンで自宅サーバーを作る方法を解説しています。
全部フリーソフトを使い、０円で作る欲張りインターネットサーバーのノウハウ全公開！
家のパソコンをサーバー化すれば、ウェブやメールの拠点を自宅に持てて超便利、方法は簡単！レッツ、自宅（マイ）サーバー！
まずはルーターのIPアドレスを調べ、そのサブネットマスク内でサーバーのプライベートアドレスを決め、サーバーにするパソコンのIPアドレスを固定します。
ADSL接続のLAN環境では通常、DHCPが有効のため、このままでは外からのアクセスが受けられません。そこでルーターのNAT/IPマスカレードの機能を使い、外からのアクセスをサーバーで受けるようにNATテーブルを定義し、静的IPマスカレードにします。サーバーで提供するサービスごとにポートを開いてやる必要があります。
3月4日14時〜 収容サーバー移設につき、最長72時間のあいだ、当ドメインのメールおよび一部コンテンツが停止いたします。
長らく更新できませんでしたが、またページ制作を再開しようと思います。とうとうレンタルサーバー会社まで作ってしまい、相変わらず忙しいのですが…。（2006/08/22）
ダイナミックDNSに関する知識のあるSEまたはプログラマの方を募集しています。DNS関連のWEBサービスのスポット開発業務、プラットホームはRed Hat Linuxです。
あまりにたくさんメールが来るのと、文中で「トライ＆エラーの記述が無い」「本名を名乗らない」「製造元やプロバイダに訊くべき質問」など、非常識なメールが止まないので、すみませんがご諒解ください。（2005/06/14）
メールでお寄せいただく質問については、現在多忙を極めているため、全部に回答をできない状況です。名前や自己紹介の無いメール、PC環境やトライ＆エラーについて記載の無いもの、既出の質問およびFTPとMTAに関するご質問への回答は遠慮させていただいております。
ドメインをはじめネットワーク関連の質問と、お仕事の依頼およびサンキュメールには、順次返信いたします。掲示板もあわせてご利用ください。
自分のパソコンにWWWサーバーソフトをインストールすれば、自宅から直接ホームページを発信できます。また、CGIやPHPで作ったプログラムを自分のパソコンですぐに動かすことができます。
圧倒的なシェアを誇るアパッチでWebサーバーを立てます。アパッチはUNIX系のサーバーですが、ここではWindows XP にインストールします。
無料で使える日本語FTPサーバーソフト、TinyFTPDでFTPサーバーを立てます。外からホームページを更新したり、ファイルの共有や交換ができるようになります。
自宅サーバーなら、好きなアドレスを作って自由にメールを送受信することができます。Windowsにメールサーバーをインストールします。
ドメイン購入された場合、最後のページでユーザー名とパスワードが表示されます。忘れずに必ず控えておいてください。（2006年08月22日）
ドメインの申請や設定の変更は、この間も下のフォームから可能です。 -->
サーバーサイドスクリプトの実行環境をインストールします。自分のパソコンや自宅のサーバーマシン上で、PHP や CGI などのスクリプト（プログラム）が動くようになります。掲示板を置いたり、Webアプリを作ったりできます。
ブログ（Blog）を使うと、簡単にダイナミックなサイトを作れます。今流行のBlogを始めよう！ 連載中！2004年3月
私の自宅では、普通のパソコン（SONY VAIO）で２台のサーバーを立てており、内１台は03年04月27日からADSLで常時（きまぐれ？）公開しています。
新サーバーの共有ユーザー25名ほどを募集しています。自宅マシンではなく、ｉDC収容の商業サーバーをまるごと使ったホスティングサービスです。（2005/08/01）
世界で最も使われているサーバーソフト。無料だが高度な知識が必要。元はUNIX系。
簡易SMTPサーバー。パソコンから直接メール発信できるようになります。
無料のダイナミックDNSサービスを紹介します。数字は選べるドメインの数です。
初めまして、googleで発見いたしました。OSもXPだし、ADSLモデムも同じ富士通のもので、読む上でもすごく分かりやすかったのですが、うまくいきません。以下の設定でアドバイスをいただけないでしょうか？
LANには全部で3台のマシンがあり、プライベートアドレスの最後の数値は、サーバが99、他は3と4になっています。 （虎之助さん、03/08/04）
一度、ルーターからＰＣまで全てを再起動、そしてもう一度、ルーターのポート（WWWサーバーなら80番）をスタティックIPマスカレードに設定しているか確認してください。次に、サーバーＰＣのIPアドレスが固定（この例だと 192.168.0.99）されているか確認します。
ポート監視系のソフト（Nortonなどのセキュリティソフト）を切ってください。サーバーＰＣでWWWサーバーソフト（AN HTTPD）を起ち上げ、そのＰＣ上でブラウザを起動し、http://localhost/ へ接続。自宅ホームページが見えますか？見えなければ、WWWサーバーソフトの設定ミスです。
次に、LAN上の他のＰＣから、プライベートIPアドレスでサーバーへつないで見ます。この例だと、他のＰＣのブラウザで http://192.168.0.99/ と入れます。同様にウェブが表示されれば、LAN内は問題なさそうです。
次に外部からの接続です。まずはダイナミックDNSを使わずにテストします。現在のグローバルIPアドレス（ルーターのWAN側IP）を調べ、近くのネットカフェへ走り、そこのＰＣでブラウザに http://xxx.xxx.xxx.xxx/ と調べたIPを打ち込んでみます。これで見えていれば、サーバーがインターネットへ公開されています。
必ず“自宅外”のＰＣでチェックすることがミソです。いかがでしょうか。
よくある質問欄で「WebではなくRouterの画面が表示される」の項目がありますが、元の質問は「LANからドメイン名でアクセスするとルーターの設定画面が表示される」ということだと思います。LANの中から公開サーバーにアクセスするときはIPアドレスを直接入力する、というのはそれはそれでいいと思います。
でもおそらく質問者が求めてるのは「ではどうすればLANの中からドメイン名でサーバーにアクセスできるのか」ということで、ドメインシステムに詳しくない自宅サーバーユーザーはたいていの人が躓いているポイントだと思います。
ということでもう一歩踏み込んで「それはDNSの解決が正しくできていないからだ」というとこまで示したらどうでしょう。でもって解決策にはHOSTSファイルを編集して…、と。これだけのページを作成しておられるので詳しい話は省きますが、いかがでしょう？
あと、どうも気恥ずかしいので匿名にさせていただいています。その点はご容赦ください。 （匿名さん、03/11/26）
というご意見の他、同様の質問をいただいていますので、解決策をまとめておきます。 自宅内からもドメイン名でサーバーマシンにアクセスしたい！という場合は、参考にしてください。
そもそもルーターというのは「LAN（自宅内）」と「WAN（インターネット側）」を明確に区分しており、しかも入ってきたポートへパケットを戻すことはありません。したがって、自宅内からドメイン名でサーバーマシンにアクセスしようとすると、「ページが見つからない」や「ルーターの設定画面が開く」のは正しい結果であり、自宅内（LAN上）ではプライベートIPアドレスを使えば（見かけ以上の）問題はありません。
では、自宅内から同じLAN上のサーバーへドメイン名を使ってアクセスする方法ですが、「hostsファイルを書き換える」「外部のプロキシサーバーを利用する」「内向きDNSを立てる」の３つが有力です。
このファイルに、サーバーのプライベートIPアドレスとドメイン名を追記します。
という感じです。ダイナミックDNSのドメイン名でももちろんOkです。
簡単ですね。同様に自宅内のすべてのパソコンに設定してください。
この方法は、ドメイン名の解決（IPアドレスへの変換）に DNSサーバーを使わず、PC内のhostsファイルを使うことで、ルーターを回避しています。
自分のPCではアドレス入れてもルーターの設定画面に飛びます。それをどうにかできないでしょうか？（Genchanさん、03/07/30）
入れているIPアドレスが、ルーターのプライベートIPアドレスだと、ルーターの設定画面が開きます。正しくＰＣのIPアドレスを打てば、問題ないはずです。
その準備として、まずはＰＣのIPアドレスをLAN内で固定しなければなりません。詳しくは こちら をご覧ください。
自宅サーバーの設置に取り組んでおります。しかし、外から見ることが出来ません。ルーターは富士通、ＩＰは手動で固定、ルーターのスタティックＩＰマスカレード設定も行いました。
ＤＨＣＰ設定は有効のままではダメですか？ぶしつけな質問で申し訳ないのですが、教えて頂けると幸いです。（野崎さん、03/07/02）
(1) サーバーソフトが起動しているか確認。サーバー上からlocalhost に接続できますか？ (2) ルーターのポート設定が有効か？富士通のルーターは設定のあと、登録ボタン押下、再起動が必要です。 (3) セキュリティソフトやポート監視設定をすべて止める。 (4) ダイナミックDNSを使わず、今現在のグローバルIPを調べる。 (5)
完全に外部の回線からアクセスしてみる。仕様上、自宅LAN内からはグローバルIPでサーバーに接続できないケースが多々あります。別のPCでダイヤルアップ回線で見るなどしてみてください。
友人にFFFTPで接続してもらったところ、以下のようなエラーがでました。
ダイナミックDNSサービスへの登録は済んでいるようですので、再度ログインして現在のグローバルIPアドレスに更新してください。
ドメイン名を打って、現在のグローバルIPアドレスに変換できていますか？
はじめまして、「自宅サーバーで行こう」が無かったら自分のサーバーを持つ事なんて夢でした。本当に有難うございます！
ダイナミックDNSサービスを利用すると数字のアドレスが自分の好きな名前になり、是非使ってみたいのです。
プロバイダーより与えられたものではなく、ダイナミックDNSサービスのものを使用するのでしょうか？ （誠治さん、03/12/19）
ダイナミックDNSサービスは、自宅のパソコンの“一意でない”（固定ではなく接続毎に変動する）グローバルIPアドレスに、“固定した”名前を与えてくれるサービスで、外部からドメイン名で自宅サーバーに接続できるようにするために使われます。
一方、パソコンに設定する「優先DNSサーバー」というのは、自分がインターネットを楽しむ場合に（例えばメールやWebを見る場合に）ドメイン名をIPアドレスに変換するために使うもので、（したがって普段意識する必要の無いものですが、必ず必要です） ここにはご利用のプロバイダーのDNSサーバーのアドレスを設定します。これはネットのセットアップの際に設定するもので、プロバイダーの申込書に記入されています。
両者は似ていますが、アクセスの方向が逆向きであり、ちょっと紛らわしいのですが無関係です。
なお、自分のパソコンのグローバルIPアドレスは、ダイナミックDNSサービスのホームページにおいて登録/更新することになります。
パソコンとルーターの設定の中でIPアドレスの設定という項目があると思います。「DNSサーバー」のIPアドレスが一つしか表示されない場合はどうしたらよいのでしょうか？（児玉さん、03/06/28）
しかし、最も手っ取り早い方法は、お使いのプロバイダーの加入時の資料を見ることです。児玉さんがお使いのニフティは、Webでも公開してるようですよ。
昨日突然メールの受信が出来なくなってしまいました。（送信は出来ます。）
サーバーへ発信しての受信だと出来ますが、外部からの受信が一切ダメの状態です。ネットで色々調べて、ポートを変えてみるとかやりましたが、解消出来ません。
「今まで正常にできていて、突然使えなくなった。」「ローカル（LAN内での使用）では、問題ない。」ということから考えると、どうもダイナミックDNSサービスで名前解決（ドメイン名からIPアドレスへ変換）ができていないように思います。
ドメイン名ではなく、グローバルIPアドレスにメールして届きますか？届くなら、DNSの問題ですので、ダイナミックDNSサービスの MX（メールエクスチェンジャ）レコードの設定を確認してみてください。
また、ArGoMailServer のウインドウ左下は「Delivery On」となっていますか？それと、動作モードが「停止」になっていないでしょうか？ うっかり配送停止にしていると、当然のことながらメールはリレーされません。
受信不具合なのでルーターのPOP3ポート（110）の設定をやり直してみました。その後いったん復旧（解消）されたのですが、今朝再度確認をしたところ、また受信出来ません。送信についてはいつでも問題無く行えてます。
利用しているダイナミックDNSサービス、ZIVE 特有の問題の様です。私の環境はダイナミックDNS更新ツールで有名なDICEを使用しており、サーバー起動毎にIPアドレスを更新する設定にしています。ZIVEではIPアドレスの更新が行なわれると
MX（メールエクスチェンジャ）レコードの設定が解除されてしまうらしいのです。
DICEでMXレコードの設定に関する詳細設定が出来ると言う事で、早速実施してみたところ、受信の不具合が解消されました。：参考サイト（小沢さん、04/01/29）
ここのサイトを見て、Tiny FTPでFTPサーバーを立てたんですけど、先程FFFTPで自分でアクセスして、成功したので友人に試してもらったら接続できませんでした。どうしてでしょうか？
ファイアウォールは切ってあるのか、ダイナミックDNSの名前解決はできているのか、Webサーバーについては接続はうまくいくのか、ご自身で試した内容についてもお知らせいただきたいと思います。プロバイダもWindowsのバージョンもわからないとなると、こちらもコメントしかねます。
こちらを参考に自宅サーバーを立てました。有益な情報がわかりやすく解説してありとても参考になりました。
うまくいっていたのですが、TinyFTPDが強制終了してしまうという事態が発生するようになってしまいました。DDNSの更新をサーバー起動時にDICEで行ってるのですが、FTPDに問題が起こるのは時々です。なぜこのような問題が起こるのでしょうか？（hirotoさん、03/08/03）
別のFTPサーバーを使ってみるか、TinyFTPDの関連サイトをあたってみてはいかがでしょう。回答になっていなくてすみません。
やはりソフトの相性もありますので、不調なソフトは諦めて、きっぱり他のデーモンに乗り換えるのも良い方法です。
回答いただきありがとうございます。結局、調べてみましたが手がかりはなく、WAR-FTPDに乗り変えたところ順調に動いております。（hirotoさん、03/08/06）
貴サイトを参考にさせて頂き、自宅マシンでHPを立ち上げたいと思い、いろいろと勉強しているところです。
独自ドメインを取得したいと思うのですが、この場合DDNSのようにプロバイダ側のDHCPで振られたIPでは登録できないのでしょうか？
固定IPが必要なのか、それともDiCE等で独自ドメインでもIP再取得時にIP登録の更新が可能なのかが、いろいろ探したのですがわかりません。
しかしお悩みのように、非固定IPでサーバーを立てるには、ドメイン・DNS・ダイナミックDNS・IP更新の連携が必要で、ハードル高めです。
基本的には、ドメイン（Domain Name）から自宅マシン（IP Address）へたどり着く（これを名前の解決という）には、NICのDNS情報→自サーバーの管轄DNSサーバー→自サーバーのIPアドレス という手順となり、これに従います。
NICのDNS情報は、ドメインを取ったレジストラにて書換えが可能で、固定IPならサーバーのグローバルIPを直接指定します（DNSサーバーも自分で立てた場合）。
一方、非固定IPなら、これを書き換えればよさそうですが、DNSデータベースは変更の反映に24〜72時間かかり現実的ではありません。DNSサーバーを自前で立てるのは非常に大変です。
そこで 非固定IP（ADSLの自宅サーバー）の場合は、ネームサーバーにダイナミックDNSサービス（以下DDNS）を指定してやり、変動するIPの解決をDDNSサービスに任せます。DDNSサービスを使ってワンクッション置き、対外的にはネームサーバーを固定するわけです。
あとは通常のDDNSサービスと同様、IPが変わる度に更新すればいいわけです。
なお、DDNSサービスについては独自ドメインからの名前解決に対応したサービスを利用しなくてはなりません。うちでドメインを取得していただいた場合、成功はお約束できませんが、ご紹介させていただきます。
もちろん、サーバーを立て、DDNSサービスも使いこなせて、その次のステップということになります。
HPを参考にサーバーを作りました。非常に役立ちました、どうもありがとうございました。
物凄いアクセスのあるサイトの場合サーバーに負荷が掛かって中々ページが表示されないとかファイルがダウンロードできないとかいう症状がでます。
現在ADSLなのですが、光ファイバーにすれば問題は解消されるのでしょうか？それと光にした場合帯域制限などをすればユーザーのストレスはなくなるものなのでしょうか？ （中田さん、03/09/21）
実はADSLというのは、下りは早くて上りは遅い（上りとはアップロード、ユーザーから見るとダウンロード）ものなのです。ですからADSL：“非対称”デジタル加入者線といいます。
光にすれば、相当解決されると思います。ただご自宅の立地やマシン能力など他のファクターも噛んできますし、まったく変わらないということもありえます。（ADSLの上りは下りと違ってほとんどフルスピードが出てるんです）

 

[ 59] DiCE DynamicDNS Client (自宅でインターネットサーバー)
[引用サイト]　 http://www.hi-ho.ne.jp/yoshihiro_e/dice/

”DynamicDNSサービス”を利用して自宅にインターネットサーバーを構築するためのページです。
DynamicDNSサービスとは．．．インターネット上のDNSサーバーに、ホスト名（ドメイン名）を登録してくれるサービスです。
そして従来のDNSと違うところは、ホスト名に対するIPアドレスをいつでも自由に変更することが出来ることです。 現在では、DtDNS、DynDNS、HAMMERNODE、などの無料で登録してくれるサイトが数多くありますので、是非利用してみましょう。
DynamicDNSサービスを利用すると．．．ダイヤルアップ接続ユーザーのように固定のIPアドレスを持っていなくても
"xxx.dyndns.org" のような自分だけのグローバルなホスト名（ドメイン名）を持つことをが出来ます。
などを利用しているなら、ご自分でインターネットサーバーを運営してみてはいかがでしょうか？ フリーDynamicDNSサービスサイト一覧
インターネットサーバーを持ちたいけど、「固定IPアドレスを１つしか持っていないからDNSを立てるほどじゃない」、「DNSの立て方がよく判らない」 というような場合でもDynamicDNSサイトを利用すれば面倒な手間はいりません。
DiCE とは．．．”DynamicDNSサービス”利用者のためのクライアントツール（フリーウェア）です。
DynamicDNSサービスはとても便利でありがたいサービスなのですが、ＩＰアドレスが変わるたびにわざわざ登録サイトに行って更新作業をしなくてはなりません。
サービスのWebサイトへ行かなくても更新作業を行うことが出来ます。指定日時、または定期的にＩＰアドレスなどの情報を更新することが出来ます。ＩＰアドレスの変化を検知して自動で更新することが出来ます。設定が簡単です。(だと思います)
著作権・サポート・免責・その他．．． このソフトウェア（DiCE）の著作権は私(sarad)が保有しています。
なお、このソフトに関する苦情はうけつけていません。(^^; 自己の責任でお使いください。 また、バージョンアップの義務もありませんのでご了承ください。
はその名の通りフリーウェアですので自由に使って頂いてかまいません。。。が、カンパは大歓迎です。(^^;
カンパしていただいた方にはお礼として機能を少しだけ拡張した "ProfessionalVersion"をご用意しております。
転載についてはご一報いただけると幸いです。ソフトに関する質問、感想、お問い合わせなどはこちらへお願いいたします。
をご利用ください。サポートして欲しいDynamicDNSサイトがありましたらこちらまでご連絡ください。
ProfessionalVersion について．．．フリーウェアバージョンに対して主に次のような違いがあります。
WindowsNT, Windows2000などのWin32環境において、サービスアプリケーション（デーモン）として動作可能です。
システムとしてバックグラウンドで動作しますのでログオフ状態などでもDiCEの機能を提供することができます。エラー発生時に指定のE-Mailアドレス宛に通知することが出来ます。プロパティにてサーバーから受信したメッセージを見ることが出来ます。
※ フリーとはいっても、寄付金を受け付けていたり今後有料化を予定しているサイトもあります。 空欄部もサポートしている可能性があります。詳細は各サイトのドキュメントを参照してください。
ルーターなどでNATを利用している場合、ルーターに「ポート転送(Portforwarding)」の設定をする必要があります。
（ポート転送とは、インターネット側からのパケットをLAN側の特定のIPアドレスに転送する機能です。）
ダイヤルアップルーターを使用しているのですが、同じLAN上のパソコンからDynamicDNSのホスト名でアクセスできません。外（WAN）からはちゃんとアクセスできるのですが。
ルーターなどでNATを利用している場合、ローカルエリア内のパソコンにWAN側のグローバルIPアドレスでアクセスすることは出来ません。
同じLAN環境からアクセスする場合はLAN上のIPアドレスまたはホスト名を使ってください。
この場合、外からはちゃんとアクセス出来るので問題ないわけですが、どうしても自分でDynamicDNSのホスト名で試して見たいという場合は、WEBでしたらブラウザにプロキシの設定をすれば見ることが可能です。これは、WAN上のプロキシサーバーを中継することで外部からのアクセスとなるためです。
現在利用しているCATVインターネットサービスはプライベートＩＰアドレスが割り振られるのですが、DynamicDNSの利用はできますか？
・サーバーを立てる用途。（WWWだけなのか、メールサーバーなども立てるのか。。。など）
最後の”安定性”や”永続性”については、実際に利用してみないとわかりませんが、ここのページで利用者からの投票集計が見れますので参考になるかもしれません。
いずれにせよ、どこのサイトも利用者のマナーさえよければ長くサービスを続けていけるでしょう。
DynamicDNSで取得したホスト名でアクセスしようとすると、ルーターの設定ページ、又はユーザー認証ダイアログが表示されてしまいます。
基本的なDNS機能です。 NSレコード登録 - ネームサーバーとして登録できます。DNSサーバーが必修です。
ワイルドカード機能 - *.dice.mydom.comといったように*部にどんな名前を入れても登録したIPアドレスが参照されます。
MailExchangerホスト登録 - 登録したドメイン名に来たメールを指定のメールサーバーへ中継します。（MXレコード）
インターネットなどのTCP/IPネットワークでは、それぞれのホストに「ＩＰアドレス」というユニークな数字の列（192.168.0.100など）が付けられており、その数字の列を使ってホストを識別します。
しかし、数字の列では覚えづらいので、もっと判り易い名前に置き換えられないか。。。という問題を解決してくれるのが「ＤＮＳ」と呼ばれるドメインネームシステムです。
一般的にインターネットなどを利用する場合、判り易く置き換えた名前（ホスト名と、その親に当たるドメイン名）を使うのがほとんどだと思いますが、実際には名前（www.hogehoge.co.jpなど）でアクセスするとDNSサーバーに問い合わせを行い、ホスト名からIPアドレスを割り出してもらってからアクセスしています。
文字通り、動的なDNSです。何が”動的”かというと。。。 従来のDNSでは予め用意された IPアドレスとホスト名の対比表を持っており、その情報は固定されています。
それが、DynamicDNSとなると、対比表の内容を動的に書き替える事ができるため、たとえば、ホストのIPアドレスがDHCPにより変わってしまったとしても逐次更新することによりグローバルな固定のホスト名を維持することができるのです。
つまり、固定のホスト名を持てるということは、自分で構築したインターネットサーバーを世に公開できるということです。 そして、ダイヤルアップ接続だろうとなんだろうと、DynamicDNSの情報を更新さえすればよいのです。
インターネットなどのTCP/IPネットワークに接続するマシンは必ず固有のＩＰアドレスを持っていなければなりません。 しかし、一般のユーザーで固有のＩＰアドレスを所有しているケースは少なく、殆どの人が接続するたび「DHCPサーバー」から自動でIPアドレスを貸し出してもらっているはずです。
閉ざされたローカルエリアネットワーク(LAN)などで自由に使ってよいIPアドレスです。 10.0.0.0〜10.255.255.255
IPアドレスを違うIPアドレスに変換する技術です。 ダイヤルアップルーターなどは、このNAT技術や「IPマスカレード」という１つのIPアドレスを複数の端末で利用可能にする技術を使用することにより、インターネット側の１つグローバルIPアドレスをLAN側の複数のプライベートIP端末から利用可能にしています。

 

[ 60] 自宅サーバーを構築しよう
[引用サイト]　 http://win.kororo.jp/

「全部フリーソフトで作るシリーズ」のWindowsXP版。初心者でもわかりやすい解説で人気のある1冊です。これから初めてサーバー構築する方には特にオススメ！
Apache2の逆引きリファレンス。知りたいと思ったディレクティブが簡単に引けて大変重宝しています。内容も非常に濃いのでこんな機能があったのか〜と思わず感動してしまう事も。お勧め。
筆者も3年購読している日経NETWORKです。なぜ、3年購読かというと、3年なのに2年分の料金しかかからないから（笑）。最新技術は勿論の事、ネットワーク初心者向けの内容も多いので時代の波に乗り遅れないためにも是非ともお勧めします。
「自宅サーバーを構築しよう」へようこそ！サイト内の更新情報をお知らせします。
当サイトは、「自宅でサーバーを構築する（windows)」という事に焦点をおいて自宅サーバー構築の手順を説明していきます。サーバーを構築するなると一見、難しそうに思えるかもしれませんが、実はそんなに難しいことではありません。ちょっと気になる維持費なども電気代を除けば一切かからず、サーバーウェアも全てフリーで利用できるので個人でも比較的、容易にサーバーを構築することができます。もはや、今となってはサーバー構築の敷居は格段に低くなってきたのです。とは言っても、サーバーを構築をするためには、「サーバーの仕組み」、「セキュリティ対策」、「ネットワーク（TCP/IP）」についての最低限の知識が不可欠です。また、インターネット犯罪に巻き込まれないためにも、セキュリティ対策にも真剣に取り組まなくてはなりません。特にネットワークの基礎がしっかりできていれば、トラブルシューティングにも断然強くなります。当サイトでは、サーバー構築に必要な知識を「サーバー構築」「セキュリティ」「TCP/IP基礎」と大きく３つに分類して解説しています。「サーバー構築」項だけを読んでも、サーバーを構築できたとはお世辞にも言えません。「サーバー構築」「セキュリティ」「TCP/IP基礎」の3つは、サーバー構築するためのフルセットであると言うことを覚えておいてください。
それでは、さっそく自宅サーバーの構築に入る前に「自宅サーバー構築前の準備」項でサーバーを構築するにあたって必要な環境を予め整えておきましょう。
相互リンクも大歓迎です。相互リンク希望の方は、相互リンク自動受付フォームをご利用ください。自動受付フォームでの登録が面倒だという方は、メールにてご連絡ください。その際、(1)「貴サイト名」(2)「貴サイトのURL」(3)「貴サイトの紹介文（40字〜80字程度）」(4)「当サイトをリンクしたURL」(5)
Windowsによる自宅サーバー構築図説、セキュリティ対策、TCP/IPの解説。Movable Typeのカスタマイズも掲載。
当サイトの説明は、間違った記述のないよう万全を期しているつもりですが、それでも間違って記述されている可能性を含んでいることをご了承ください。尚、当サイトの説明を読んで発生したいかなる損害も管理人コロは一切、責任を負わないものとします。あくまで、管理人の趣味レベルで制作されたサイトであることをご理解ください。
当サイトで説明された用語、説明などにはもしかしたら、管理人の勘違いなとぼけた知識も混じっている恐れがあります。「ちょっとこの説明は違うんじゃないかな」とか「言い回しがわかりにくい」、あるいは誤字脱字などがあり、意味が通らない文章がある等の、疑問・苦情のメールは下記メールアドレス宛て、もしくは掲示板へとご連絡ください。また、下記メールアドレス宛てには、技術的な質問はしないようお願いします。仮に技術的な質問メールが送られてきたとしても一切、返信致しませんのでご了承のほどよろしくお願いします。

 

[ 61] WAGOの小部屋 Windows2000とApache2で初めての自宅サーバー｜TOP
[引用サイト]　 http://wago.nobody.jp/

ここでご紹介する事は、私が初めて非固定IPアドレス(動的IPアドレス)で自宅サーバーなるものを個人で構築し、その覚書としてド素人が作成したページです。 基本的にOSはWindows2000としての解説をしていますが、WindowsXPでも同様に設定が出来ると思いますので、適所読み替えて頂くことで構築が出来ると思います。 私自身は、ここに掲載されている方法で問題なく作動していますが、勉強不足のため「誤った」事を掲載しているかも知れません。 その場合、私自身の設定も間違っていると言うことになりますが・・・。 突っ込みいれて頂ければ、私も勉強になりますので気付いた点があれば、ご連絡頂ければ幸いです。
非固定IPアドレス(動的IPアドレス)の問題を解決するには、DDNSを利用します。 メニューの上から順に設定することで、初めてでもサーバー構築ができるように掲載しています。 私が自宅サーバーを構築した理由は、
しかし出来るならば、お金の掛からない方法でと思い、今回ここで掲載している内容は、現在常時接続環境であれば費用は0円で構築することが出来ます。 私自身の覚書サイトなので、他の方が同じ作業を行われても問題なくサーバーは構築できると思いますが、ここで掲載されている内容を行い、トラブルが発生した場合に関しては当方では一切、責任は負いませんので、作業される方自身の責任で行うようにお願い致します。 下記作業手順を行なう事で、Serverを構築する事が出来ます。
PC1台に「WWW Server」・「FTP Server」・「Mail Server」をインストールする事で話を進めます。 ここからの説明は、PCのハードディスクドライブが「Cドライブ」、「Dドライブ」、「NTFSフォーマット」である事を前提に話を進めます。
理想は物理的なドライブが2つある事ですが、1つのドライブにパテーションをきり、2つに分けて使用しても構いません。 これからサーバーを構築しようとしている方が、こちらを見ていると思いますので、OSのクリーンインストールは出来るものとして、方法・説明などは割愛いたします。
ここで掲載されていることを行うと、ごくごく一般的なサイト構築になると思います。 モジュールなどを利用して特殊な事は行っていません。 その他、私自身、追加作業を行った場合は、随時このサイトにて公開していきたいと思っています。 なんと言っても覚書サイトなので。(笑)
初めて構築される場合は、左メニュー「サブドメインの取得」からお入りください。 突っ込み頂いた事は、こちらのサイト内で「突っ込み事項」として掲載させて頂くことと、ご連絡を頂きました件については、こちらから折り返しメール等で返信は致しませんので、予めご了承ください。 また、技術的なご質問がある場合など、メールでご連絡を頂きましても、こちらからの返信は致しませんので併せてご了承下さい。

 

[ 62] 高木浩光＠自宅の日記
[引用サイト]　 http://takagi-hiromitsu.jp/diary/

（注記：この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基本的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。）
今年3月31日、NTTドコモのiモードが、契約者固有ID（個体識別番号）を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。
ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』（以下、iモードID）機能を提供いたします。
・iモードID通知設定は、お客様の利便性を考慮し初期設定については「通知する」設定となっております。通知を希望されないお客様は「通知しない」に変更していただく必要があります。
これに気付いたのは予告が公表された翌週のこと。私は大きなショックを受けた。これまで、auのサブスクライバーID（現在の呼称は「EZ番号」）について問題があることを各方面に伝えてきたが、その拠り所の1つが「NTTドコモはやっていない」であったからだ。いろいろ考えてみたものの、もう何を言っても無駄であると悟った。
NTTドコモがそれまでそれをやらないできたのは、ちゃんと理由があってのことで、それは2001年の総務省の研究会「次世代移動体通信システム上のビジネスモデルに関する研究会」の議事録と報告書、パブリックコメントに記録が残っている。このことについては昨年の6月30日の日記でまとめている。
当時は、IDを送信しているのはKDDIのauだけで、NTTドコモとJ-PHONE（現在のソフトバンクモバイル）は、公式サイトにしか送信しない策を講じていた。ジェイフォン東日本株式会社から提出されたパブリックコメントには、
ユーザID に関しては報告書（案）にも述べられているとおり、ユーザのプライバシーと密接な繋がりがあるため、その取り扱いについては十分慎重であるべき。現在、ドコモやJ-フォンが公式サイトに限ってユーザID を提供しているのもそのためである。（略）
コンテンツ提供者自身はユーザID を直接不当に利用するものではなくても、獲得したユーザID を他者に転売するなどして利益を稼ごうとするものは存在しうるし、社員管理の徹底がなされていない企業では不心得な社員による情報の流失も十分想定される。
ユーザＩＤそれ単体では個人を特定することはできないものの、ユーザ情報との紐付けを行うことで、悪意ある者がユーザの意向に反して個人情報を利用してプライバシーを侵害することも技術的には難しくないようで、ユーザＩＤを無差別に提供することの危険性も指摘されている。
このような機能と特性を持つユーザＩＤに関しては、ＮＴＴドコモやＪ−フォンが自らが採択した「公式」サイトのみにユーザＩＤを提供しているのに対し、ＫＤＤＩでは全てのコンテンツプロバイダに対して提供するなど、通信キャリア間で取扱いに差異があるのが現状である。また、最近では、ユーザの個別の同意確認をシステムに組み込み、端末製造番号をコンテンツプロバイダに送信する端末も出現している。
ユーザＩＤの取扱いについては、近年のモバイルインターネットの普及やIMT-2000 で期待されるビジネスモデルの高度化、多様化といった現状を踏まえる一方で、ユーザの利益を保護する観点から、個人情報保護のみならず「通信の秘密」確保という法益にも配慮し、ユーザＩＤの特性とユーザに及ぶリスクの可能性を十分に検討しなければならない。ユーザの同意のあり方を含めた、ユーザＩＤに係る取扱いルールを早急に確立する必要がある。
それが、2007年になって転機が訪れた。総務省の「モバイルビジネス研究会」が、「ユーザIDの利活用の推進」を掲げたのである。
（略）現在、通信事業者の公式サイトにおいては、携帯端末の端末認識番号をユーザーＩＤとして利用して利用者の認証を行い、課金等を行っている場合が多い。この仕組みは利用者側からみればＩＤの入力を省略でき、利便性が高いものである。しかし、端末認識番号は各事業者が携帯端末の利用者を認識するために割り当てている番号であり、利用者が事業者を変更すると、番号ポータビリティが実現している電気通信番号（電話番号）とは異なり、端末認証番号は変更される状況にある。また、各事業者ごとに端末認識番号を利用できるサイトの運用基準が異なっている。
このため、コンテンツプロバイダは、利用者が通信事業者を変更するとＩＤが変更されて認証ができなくなる等、必ずしもオープンな環境が実現していない。また、一般に利用者が公式サイト上のコンテンツプロバイダから有料コンテンツの提供を受ける場合、利用者、コンテンツプロバイダ、通信事業者の３者間の契約となる旨が各通信事業者の契約約款で規定されている。このため、利用者が通信事業者の変更を行うと、利用者とコンテンツプロバイダとの間の契約も自動的に解約され、新たに契約を締結することが必要となっている。
したがって、ＩＤポータビリティを実現するため、研究開発や標準化を含む技術的な観点からの検討に加え、ＩＤポータビリティを利用した様々なサービスが創出されることから, 費用面・制度面からの検討を同時並行的に進め、２０１０年の時点で実現する方向で結論を得ることが望ましい。その際、ＳＩＭカードを携帯端末に限らず広くネットワークに接続される多様な端末において、ユーザーＩＤを認証するためのツールとして活用することについても具体的な検討を進めていくことが適当である。
この研究会報告書案には、IDを勝手サイトにまで送信するようにするとは書かれていない。あくまでも、ナンバーポータビリティの延長として、IDもポータブルにする（携帯電話会社を変更しても、IDがそのまま使えるようにする）ということを提言しているだけになっている。
2001年の研究会のときは、「NTTドコモがIDを公式サイトにしか送信しないのは、囲い込みがしたいだけではないか」という声もあったらしい。それに対して、2007年のモバイルビジネス研究会は、今度こそ囲い込みを排して競争を促そうという狙いになっていると聞く。たしかに、2001年のときには、NTTドコモがプライバシーを盾に囲い込みを維持するという面もあったのかもしれない。しかし、上記のようにジェイフォン東日本もそのプライバシー上の問題を指摘していたわけであり、問題の所在は現在においても同じである。
この研究会報告書案のパブリックコメント募集に対して、産業技術総合研究所情報セキュリティ研究センターが次の意見を提出した。この意見は、報告書案の方針に反するものではなく、むしろその方針を補強するための提案になっている。
(1) ユーザIDの利活用の推進にあたっては、平成13年6月に総務省から公表された「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書で指摘されているプライバシー上の懸念に配慮する必要があることを明記するべきである。
(2) そのプライバシー懸念を払拭しながら同時にユーザID の利活用を実現するために、（運用方針による回避ではなく）技術的手段による抜本的な解決策を模索するべきである。
(3) その技術的解決手段を実現可能とするために、各通信事業者は、WebのHTTP通信においてcookie機能に対応するべきである。
しかし、総務省の「報告書案に対する意見招請の結果及びこれに対する考え方」を見ると、この意見に対しては「☆（今後の検討に当たって参考又は留意すべきご意見 ）」とマークされただけで説明はなく、最終報告書に何ら反映されないという結果になった。
このとき嫌な予感がした。(3)の意見はすぐに受け入れられないにしても、(1)の意見は、総務省自身による過去の報告書を踏まえるようにというものなのだから、これに応じることは本来自然なことであるはずであり、それに応じないということは、それをやりたくないという意思が隠れているように感じられた。
これはまずいと思っていたところ、日経デジタルコアの11月の勉強会で、モバイルビジネス研究会の担当課長である谷脇康彦氏の講演があるというので、これに出席して、私が懸念することを直接述べた。
その時点では、さすがにIDを勝手サイトにまで送信するようにするわけではないだろうと、あまり心配してはいなかった。IDの統一化は長期的な話であり、そのときまでに考慮してもらえばいいと思っていた。
それが、3月になって突如、NTTドコモが契約者固有IDを全サイトにデフォルトで送信することに決定したというのを知り、呆然としたのであった。
4月になって、もうひとつ驚いたことがあった。3月28日から、イー・モバイルが音声通話サービスを開始したのだが、それと同時に「EMnet」というサービスが開始された。ケータイWatchの記事では、「携帯向けインターネットサービス」、「iモードやEZweb、Yahoo!ケータイにあたるもの」と形容されている。このEMnetを契約して（接続先をEMnetに設定して）いると、Windows MobileのInternet Explorerでアクセスした際に、全てのWebサイトに対して、契約者固有IDをHTTPのリクエストに独自ヘッダ「x-em-uid」として送信するようになっていたのである。
このことは、イー・モバイルの技術情報のページに書かれているし、実際に、EMONSTERを買って試してみたところ、送信されていることを確認できた。
HTTPリクエストヘッダの「x-em-uid」を取得することで、EMnet対応端末から通知されるユニークなユーザIDを確認できます。
ユーザIDはユーザの操作によって通知を停止することが可能です。その場合、本拡張ヘッダは付加されません。
どうやら、平成19年度中という区切りで、契約者固有IDの全サイトへの送信というのが、「日本のケータイWeb」の「標準仕様」となったようだ。
これが総務省の公開されていない方針に基づくものであるかどうかは知らない。何をもって「ケータイWeb」であるのか、その定義が存在するのかわからないが、とにかく、NTTドコモの「iモード」、auの「EZweb」、ソフトバンクモバイルのWeb、イー・モバイルの「EMnet」のいずれも、契約者固有IDをHTTPのヘッダに載せて全サイトに送信するようになった。
なぜこの時期にこのような展開になったのか。2001年当時の議論では、勝手サイトでも課金を利用したいという、モバイルコンテンツ業界からの要請によるものであったようだが、その後その声はあまり聞かれなくなり、この時期になって急にこうなるというのは、どうも解せない。
ここでピンと来たのが、2月にある人物から相談を受けていたことだ。「青少年ネット規制について高木さんはどう思うか」という相談を受けたのだが、正直、青少年ネット規制のあり方には、これといって考えがなかったので、あまりたいした意見を述べることができなかったのだが、「なぜ私に聞くのか」という違和感を覚えていた。その疑問が、次の記事を読んで氷解した。
劣勢に立つコンテンツ業界を救う手はあるか・MCF岸原事務局長に聞く, ガ島流ネット社会学, 藤代裕之, 2008年3月14日
総務省主導で導入に動き出した未成年者向けの携帯フィルタリング。ユーザーの閲覧自由を奪う、コンテンツ産業の振興を阻害するといった意見はあるものの、「ネット・携帯の闇から子供たちを守れ」という声に押されて議論が賛否に単純化されている感がある。また、フィルタリングや有害コンテンツ対応に関わる人々の思惑が複雑に絡み合っていることも理解を難しくしている。（ガ島流ネット社会学）
第三者機関は、サイトの審査、定期的なチェック、教育プログラムの開発の３つを担う。気になる、サイトの審査はどのようなものになるのか。
「サイトにあるコンテンツの健全性・有害性そのものを判断するのではなく、監視制度、教育などサイトを健全化させる仕組みがあるか、取り組みが行われているかどうかを判断することになる。ISOやプライバシーマークと似た仕組みと考えてもらえれば分かりやすいのではないか」
携帯電話のユーザーIDを利用した年齢の確認、悪質なユーザーへのコミュニティーサイトからの締め出しなども検討している。
「なるほどそういうことか。」と理解した。つまり、悪質なユーザを締め出すために、契約者固有IDの勝手サイトへの送信を必要としているわけだ。
このことは、5月28日の日経デジタルコアの討論会「民間主導によるネット有害情報への取り組み」を聴講して明確になった。配布資料には次のように書かれている。
・サイト管理領域でサイト認証基準を策定するとともに、啓発・教育プログラム策定WGと連携して活動を実施する。
・個別サイトごとの取り組みに加え、共同監視プログラム（例：悪質ユーザーのブラックリストの管理）の導入を検討する。（略）
モバイルコンテンツ審査・運用監視機構が考える青少年保護施策について, モバイルコンテンツ審査・運用監視機構
講演者の岸原孝昌氏は、この部分の説明で、「ドコモも3月からユーザIDを取れるようになりましたし」と発言し、また、「認定サイトではユーザIDを取ることを義務化する」とも説明していた。*2
つまり、これは、一定の基準を満たす「健全コミュニティサイト」というものを認定して、青少年保護のコンテンツフィルタリングの対象から、明示的に外してもらえるようにしようという計画のようだ。*3
フィルタリングでコミュニティサイトを丸ごと見えなくするような施策を国会議員から強制されてしまう前に、健全な書き込みからなるコミュニティサイトを実現できるようにするというのは、とても良い考えだと思う。
私は、以前から小倉秀夫弁護士が主張していたような「全てのサイトを実名制にする」という考えには賛成しないが、「全てのサイトで2ちゃんねる的な匿名のノリを理解せよ」という意見にも賛成しない。2ちゃんねる的な匿名を極めたコミュニティも、匿名を排した実名前提のコミュニティも、両方存在して使い分けられるようになるのがいいと以前から思っている。匿名・顕名には様々なレベルがあり、表示上の匿名・顕名、ログ上の匿名・顕名もいろいろな組み合わせがあるだろう。
そんな中で、青少年に限って、デフォルト設定で（親の許しがない限り）、匿名性のないコミュニティサイトにしかアクセスできないようにするというのは、良い落しどころではないかと思う。
たしかに、携帯電話のWebでは、Webサイト側で、IPアドレスで書き込み者を区別することができないという問題がある。通常のインターネットのWebならば、アクセス元IPアドレスと時刻の情報でISPに開示請求すれば契約者を突き止めることができるが、携帯電話のWebでは、アクセスが携帯電話会社のゲートウェイを介して来るため、ゲートウェイが匿名化Proxyのようになってしまっている。犯罪的な書き込みがあったときに、犯人を突き止めるために、「何時何分何秒にこの書き込みをした人は誰か」と、携帯電話会社に開示請求しても、携帯電話会社がPOSTアクセスの送信データ本体をログに記録していなければ、時刻とURLだけを頼りにどの契約者なのかを判別するほかなく、時刻が1秒でもずれていたら犯人を正確に特定できなくなってしまう場合も生じ得ると思われる。通信の秘密の原則からして、電気通信事業者がPOSTのデータ本体を記録してよいとも思えない。
その理由からも、HTTPのリクエストヘッダに何らかの識別情報を送信する必要性があるのはわかる。ProxyサーバがX-Forwarded-Forヘッダを付加して中継するのと同様に。
ただ、その目的のためであれば、常時同じIDを送信することは必要ではないことに留意しておきたい。例えば、（IPアドレスと同様に）何日かで変わるランダムなIDを送信するようにして、携帯電話会社側でそのIDと時刻から契約者を特定できるログを保管しておけば、十分その目的を達成できる。固有ID送信によるプライバシー問題の発生を回避しながら、犯罪的書き込み者等の追跡を可能にすることは、両立できる。（PCから利用する通常のインターネットではそうなっている。）
にもかかわらず、契約者固有IDを直接使うというのは、別の目的、つまり、悪質なユーザを締め出すという目的があるからであろう。
通常のインターネットでは、悪質なユーザの締め出しが困難である。コミュニティサイトをユーザ登録制にしても、新規登録を繰り返し行われたら、何度でも悪質なユーザが名前を変えて再びやってくる。
これを排除するには、韓国のように、コミュニティサイトでのユーザ登録時に住民登録番号（日本ならば住民票番号）を入力させ、他人の番号を使ってなりすましする者には刑事罰を科すという方法があるが、日本では実現できないだろう。
その目的のために、携帯電話の契約者固有IDを使うというのは、そこそこ有効だと考えられる。もちろん携帯電話を新たに契約すれば別のIDを使うことができてしまうが、青少年にとって携帯電話を再契約することのハードルは高いため、青少年のためのコミュニティサイトにおける健全性維持の目的であれば、そこそこ機能すると思われる。
ユーザの希望で契約者固有IDを変更することができるかどうか、各社のサポートセンターに問い合わせてみたところ、au以外は基本的に変更できないとの回答だった。
iモードIDは「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続きは存在しない。ただし、電話番号の変更手続きをするとiモードIDも変更されるとのこと。
EZwebサービスの利用を「廃止」して、同サービスの「再追加」を行うと、EZ番号は新しいものが割り当てられる。廃止に1時間、再追加に1時間かかり、計2時間ほどメール等が受信できなくなる。メールアドレスも新しいものが割り当てられるが、1つ前のメールアドレスに戻すことができるので、2時間の空白を気にしなければ、同じメールアドレスを維持できる。ただし、1日1回までしかできない。IDが変更されることで、有料コンテンツは一旦すべて退会となる。未受信のメールは消える。お財布ケータイに不具合が生じるかもしれない、とのこと。
変更できない。電話番号を変更する手続きをとってもIDは変更されない。SIMカードの再発行手続きをすれば変更されるが、紛失した場合など限られた事情があるときにしか応じていない。
変更できない。迷惑電話など事情により電話番号を変更することはできるが、電話番号を変えてもIDは変更されない。SIMカードを交換すると番号が変わるが、紛失時にしか交換しない。交換手数料は2100円。
EZweb開始当初からIDを送信していたauは、上記のように容易にIDの変更が可能であるが、最近になってIDの送信を始めた各事業者では、ID変更のハードルが高くされている。もしこれが、青少年ネット規制対抗策として位置づけられた施策であるならば、auも近いうちに、EZ番号の変更をできなくしてしまうのではないだろうか。（EZwebを廃止して再追加しても前のEZ番号が割り当てられるようになる。）
もちろん、この目的のためであっても、全てのサイトで共通のIDを送信することは必要ではない。例えば、アクセス先のサイト（ドメイン名またはホスト名）ごとに異なるIDが送信されるという仕組みでも、悪質ユーザの排除には役立つだろう。ある日サイトAで出入り禁止になった青少年が、サイトBでも同時に出入り禁止になるというのは、あまり良いやり方だとは思わない。悪質ユーザ認定は、サイトごとに独立していた方がいいと思う。
しかし、サイトごとに別々のユーザIDを送信するという仕組みを、携帯電話会社のゲートウェイに作り込むというのは、技術的な理由から、すぐにできることではないのだろうと思う。
なにしろ、青少年ネット規制の話は、国会議員らによって性急にもたらされたものだ。当初は極めて強い規制がかけられそうになったわけで、それに抵抗する一つの方法が、民間による自主的な取組みを進めることだったのだろう。このような国会情勢から、悪質ユーザの排斥は今すぐにでも実現できる必要があったのだと思われる。*4。
したがって、すぐに簡単に実現できる、契約者固有IDを全てのWebサイトに送信するという仕組みの導入は、たとえプライバシー上の問題が生ずるとしても、やむを得ない選択だったのではないだろうか。
既に、iモードIDを活用するケータイサイトが続々登場しているようで、今後、iモードIDの送信を止めると使えなくなるサイトが増えていくと思われる。
auなど一部の事業者だけが送信していたときは、「これは脆弱性であり廃止されるべき機能である」という立場をとっていたが、今年からとうとう各社横並びの標準仕様となってしまったので、私としては立場を変えざるを得ない。
契約者固有IDを全サイトに送信するのが標準仕様である「ケータイWeb」においては、次の通り使い方に注意する必要がある旨、情報セキュリティを専門とする者として一般利用者へ勧告したい。
商品配送先として住所氏名の入力が必要となるネットショップは利用しない。（着メロ等のダウンロード購入のように、住所氏名を送信する必要のないショッピングしかしないようにする。）
どうしても物を買いたいときは、携帯電話会社が運営するショップを使う。（携帯電話会社は、ユーザIDを流用することはないので。）
ケータイWebにおいては、完全に匿名で使うことを覚悟するか、又は、常に非匿名であることを前提に行動する。
匿名を選択する場合は、自分が誰であるかわかるようなことを、どのサイトでも明らかにしないようにする。
非匿名を選択する場合は、自分が誰であるかはどのサイトでも知られ得ると覚悟して、それでもかまわない行動しかとらないようにする。
PCから使う通常のインターネットなら、GoogleやYahoo!で検索して見つけた、初めて訪れるネットショップで、いきなり買い物をする（代引き等で）というのも、そこそこ普通のことである。商品の送付先として住所氏名を入力するわけだが、仮にそのネットショップの信頼性が低いものだったとしても、単に住所氏名を渡すことくらい、たとえ名簿に記載されて販売されようと、それだけなら問題がないという判断もあり得る。実際、私も、3年前に東京に引っ越した際には、かなりの数の見知らぬネットショップをWeb検索で見つけて利用した。
しかし、ケータイWebではそうはいかない。住所氏名を送信する際に、同時に携帯電話の契約者固有IDも送信してしまう。当該サイトの信頼性が低い場合、その固有IDの契約者が誰であるか、住所氏名とひもづけられて記録され、第三者に販売されるおそれがある。ひとたびそうなってしまうと、別のサイトを訪れても、訪れただけで、住所氏名を特定されてしまう（そのサイトがその名簿を購入している場合）。このような事態は、PCから使う通常のインターネットでは起こり得ない。IPアドレスは固定ではないからだ。
PCから使う通常のインターネットでは、匿名で使うサイトと、顕名で使うサイトの両方を利用することができた。SNSやblogでは名前を明らかにして活動し、掲示板では匿名で活動するということが安心してできた。（警察の取り調べが入るような犯罪的行為をしない限り。）
ケータイWebではそうはいかない、どこかのサイトで匿名で行動したいと思うなら、他のどのサイトでもずっと匿名のまま使うように気をつけないといけない。どこかに明かした個人的な情報は、契約者固有IDと紐付けられて他のサイトで共有され得る。逆に、どこかのサイトで自分が誰か明かして行動したいなら、他のどのサイトでも自分が誰かは知られていると覚悟の上で行動しなくてはならない。匿名で使うことを選択したなら、ネットショップを使うわけにはいかない。
とはいえ、ケータイWebをPCほど積極的に使っていないユーザ層にとっては、元々そのような行動をとっていたのではないか。少なくとも私はそうだ。ケータイWebで使っているのは、ごく少数の着メロサイトと、銀行、NAVITIME、交通情報通知サービス、都バスの運行情報サイト、2ちゃんねる掲示板の一部スレッドの閲覧、はてなブックマークのホッテントリの閲覧などに限られ、いずれもブックマークから直接訪れて閲覧し、そのリンク先の外部サイトまで訪れることはほとんどないし、Web検索で新たなサイトを探すことはしていない。この使い方は、上記の「安全なケータイWeb利用」の要件を満たしている。上記に加えてmixiを使っている場合でも（外部サイトまで行かないようにしていれば）要件を満たす。そのようなユーザにとっては、これまで通りにしている限り、おそらく問題は起きない。
しかし、一昨年のauとGoogleの提携に端を発して、ケータイWebでもWeb検索を活用する動きが活発になった。ソフトバンクモバイルなどは、ケータイWebのビジネスをPC同様の広告モデルで成功させると予告していた。今後ケータイWebもPCと同様のスタイルで使われるようになっていくだろうと言われていた。
そんな折に、契約者固有IDの全サイト送信を全キャリアが足並みを揃えて開始したことは、そうしたPC流の利用形態の普及にとって足かせとなるであろう。業界が自ら首を絞めたと言えるが、それは業界自身が選択したことなのだから仕方がない。私としては、ケータイWebビジネスの健全な発展、つまり、PCから使う普通のインターネットと同様の発展を願って、契約者固有IDの全サイト送信はやってはいけないと啓蒙してきたつもりだったが、業界がそれを選択した。たとえネットショップの新規参入が阻害されようとも、青少年ネット規制で魔法のiランドやモバゲータウン等を潰されてしまうのを避けることの方が優先されたということなのだろう。
ＮＴＴドコモは31日から携帯電話の「識別番号」をコンテンツ会社に通知するサービスを開始する。コンテンツ会社は識別番号を活用し、携帯でサイトを閲覧した履歴などが把握できるようになる。利用者の特性に応じた広告を提供することができるなど、携帯向けのネットサービスを活発にするのが狙い。
ドコモがコンテンツ会社に情報提供するのは、携帯の電話番号ごとに付与される「ｉモードＩＤ」と呼ばれる識別番号。電話番号とは異なる英数字の組み合わせで構成。「氏名やメールアドレスは含まれておらず、個人情報開示には当たらない」（ドコモ）という。
ドコモからの「重要なお知らせ」では、導入の目的が「お客様利便性の向上」「特別な操作をすることなくカスタマイズされたページを表示することができるようになります」として、耳障りのよい話だけで説明されていたが、日経新聞が言うように、裏の目的には、広告会社に便宜をはかることがある。翌々日には、日経新聞は次の報道もしていた。*5
インターネット広告配信のエイチエムシステムズ（略）は携帯電話のサイト閲覧履歴を分析し、利用者の興味に合った広告を配信するサービスを始める。履歴を把握するのに必要な携帯端末の識別番号をＮＴＴドコモが3月31日から携帯関連事業者に公開したのに対応する。（略）
エイチエムが4月中をメドに参入するのは「行動ターゲティング」と呼ばれる広告市場。サイト別の履歴情報を収集して利用者の興味にあった広告を配信するシステムを自社開発した。まず百サイトと提携する。
ここで重要なのは、これらのケータイWeb向けのバナー広告会社は、サイト横断的に閲覧者の行動履歴を取得できてしまうという点である。
バナー広告の貼られたWebページを閲覧すると、同時に、広告会社のサーバにもアクセスすることになる。これは、埋め込まれている広告画像をダウンロードするために発生する。そして、その広告会社のサーバへのアクセスには、契約者固有ID（個体識別番号）が送信されることになる。したがって、あちこちのWebサイトに同じ広告会社のバナー広告が貼られている状況になると、同じ人物がどのWebサイトを何時何分に訪れたかを広告会社が把握できるようになってしまう。「行動ターゲティング広告」とは、消費者がどんなWebサイトを閲覧しているかの行動を分析することで、それに合った広告を表示しようとするものである。
しかも、契約者固有IDは全てのWebサイトに同じ番号が送信されているのだから、通販サイトや、懸賞サイト、アンケートサイトなど、どこかのサイトで住所や氏名を入力すると、そのIDの人がどこの誰であるかが紐付けられることになる。
もし、広告会社が、各IDの人のWeb閲覧履歴情報を他社に販売するような事態になると、その情報を購入したWebサイト運営者は、自分のサイトに来た人がどんな行動をしている人か把握できるようになる。また、自分のサイトに入力される住所氏名によって、どこの誰がどんな行動をしているかを把握できるようになる。
日本の法律ではこういった行為が明確に禁止されていない。日経新聞の記事でNTTドコモが言っているように、契約者固有IDが個人情報保護法の言う個人情報に該当しないのであれば、広告会社が「各IDの人のWeb閲覧履歴情報を他社に販売する」行為は合法ということになってしまう。
NTTドコモのサポートセンターが言うように、iモードIDが「基本的にお客様にずっと通して使って頂くもの」であるなら、何年、何十年にも渡って行動履歴が蓄積される。しばらくの間は匿名のままでいられるかもしれないが、いずれ、それが誰であったか紐付けられる日が来ると、過去に遡って何年、何十年もの行動が自分のものだと特定されてしまう。
「自分の趣味に合ったダイレクトメールが郵送されてくることくらい気にならない」という人もいるだろうけれども、こうした「行動ターゲティング」は、必ずしも真っ当な事業者だけが行うとは限らない。たとえば、ヤミ金融業者や、悪質リフォーム業者、架空請求詐欺団などは、弱者を求めてカモリストを欲しがっており、ケータイWebの閲覧行動履歴は、そうした業者にも活用されてしまうだろう。
個人的には、ケータイWebが不自由なものになろうとも、私は気にならない。ケータイWebはごく限られたところしか使っていないからだ。Web検索が付いて、広告も発展し、PCに近づきつつあるケータイWebであるが、契約者固有IDが全サイトに送信される以上、今後もごく限られたところしか使わないつもりだ。
当面、ケータイWebにおける青少年保護は、契約者固有IDを用いた悪質ユーザの排斥によって、健全コミュニティサイトを育むことができ、一定の成功を収めるであろう。しかし、何年か後には、携帯電話デバイスが進化し、PC並みの性能とソフトウェアを備えるのが普通になっていくと考えられる。また、PCも小型化して、携帯電話並みに持ち歩いて利用するのが普通になっていくだろう。ケータイとPCの区別がなくなり、青少年もPCでコミュニケーションするのが普通となるときがやってくる。
すると、いずれ、健全コミュニティサイトのモデルが立ち行かなくなるときがやってくる。なぜなら、PCから利用する通常のインターネットには「契約者固有ID」が存在しないからだ。再び、青少年保護を目的としたインターネット規制が叫ばれるようになり、PCもケータイWebと同じ仕組みを導入するよう、議員立法で義務づけられてしまうかもしれない。
PCに対する法規制は既に始まりそうな様子がある。国会で審議された青少年ネット規制法案では、フィルタリングソフトのプリインストールをPC販売者に義務付る案が急浮上したと伝えられている。*6
法案は携帯電話会社に対し、子供がネットで有害情報を閲覧できないようにするフィルタリング（閲覧制限）サービスの提供を義務づける。パソコンメーカーには、フィルタリングソフトの組み込みを義務づける。
この調子で、何年か後には、「PCもケータイWeb同様に固有IDの送信を義務づける」という法案が浮上するかもしれない。*7
「PCもケータイ同様に!」という勢力に対して、ID送信の何が問題で、どうしてインターネットではそれをやってはいけないのか、いつでもすぐに30秒で説明できるよう、構えておかないといけない。
こういうとき、私たちのインターネットの自由を守る代弁者として、村井純先生にご登場願いたいところであるが、村井先生は、RFIDを推進するAuto-ID Lab. Japanを率いておられる関係上、固有IDは問題ないとするお立場かもしれない。
先月の白浜シンポジウムのナイトセッションで（私は登壇させられたのだが）、岡村久道先生から、ちょうどその日に青少年ネット規制法案が衆議院を通過したとの紹介があったため、私は、契約者固有IDの全サイト送信と青少年ネット規制との関係についての話題を持ち出した。すると、会場からこういうことを言い出した人がいた。
「銀行の口座だって名寄せされているんですよ。複数の口座を持っていても住所氏名で名寄せして1人の情報として役所に報告しているんです。」
そんなことは誰でも知っているわけだが、その発言者は得意げだった。WebのID送信の話をしているのに、銀行口座の名寄せの話など何の関係もない。IDの話をしただけで全否定してしまう人が今もいるようだ。これは、6年前の住基ネット反対運動で「牛は10桁、人は11桁」などという愚かなキャンペーンがはられたことの弊害だろう。IDの問題を語る者がすべて櫻井よしこレベルだと混同して、個別の問題を検討しようとしない人がいる。重要なのは、IDがどのように使われ得るかの個別の検討であって、IDが付くことではない。
その人は続けて、「IPv6だって、MACアドレスを含むIPアドレスが一人一人に付き、アクセス先に通知されるようになるんです」とも言った。それは生半可な知識に基づく誤った理解だ。まさにそういう設計はプライバシー上許されない欠陥であるとして、1999年に批判が巻き起こり、RFC 3041という解決策が作られて、そうはなっていない。（詳しくは後述。）
また、その後の二次会の席で、「cookieと同じでしょ」などという人もいた。その認識も技術的に明らかな誤りである。（詳しくは後述。）
こんなふうに、白浜シンポジウムに出席するようなセキュリティ関係者にさえ「IPv6だって……」「cookieだって……」などと言い出す人がいるような状況では、日本のインターネットをケータイWebと同様にする議員立法の動きがもし始まったら、もう止めることはできないのではないかと不安になる。
白浜シンポジウムのナイトセッションでも、「私はこうしてこの問題についてずっと言い続けてきたけど、もっと他の人たちも声を出してくださいよ」と訴えた。
まずは、すべての関係者にこの固有IDの問題を正しく理解してもらいたい。私はなにも、ケータイWebでID送信を開始したことに反対しているわけではない。冒頭に書いたように、青少年ネット規制対応のためには避けられないことだったと理解するし、限られた使われ方しかしないケータイWebでなら概ねあり得る選択かなと理解する。それなのに、この問題について語っただけで、反発する人がいる。そういう人は、反発するが故に、問題自体が存在しないと主張する。それが危険だ。
問題の存在を理解した上で最終設計を選択するならよいが、設計が先にあってそれに不都合な問題には目を瞑るという態度は危険だ。より良い（問題の小さい）設計が存在しても、それに気付かなくなってしまう。
固有IDの全サイト送信という携帯電話のやり方は、冒頭にも書いたように、必然ではない。ドコモのiモードがcookieをサポートしてさえいれば、他にいろいろなやり方があっただろうが、すぐにそれを導入することは難しいという、やむを得ない事情があったための選択にすぎない。PCの普通のインターネットにはそういう制限がないのだから、他の方法がいろいろ考えられる。プライバシーの問題を生じさせない手段で、健全コミュニティサイトも維持するという、両立させる手段はある。
たとえば、OpenIDや、Liberty Allianceなどの標準的なID連携技術を用いて、健全コミュニティサイト間を連携するログイン環境を構築しておくという実現手段も考えられるだろう。
ただ、誰がそれを準備するのかという問題がある。ビジネスとしてまわるものでなければ、誰も準備する気にならないかもしれない。ボヤボヤしている間に、ケータイとPCの垣根が崩れてきて、青少年ネット規制の機運が再び性急に浮上し、「これから設計して構築します」などという意見が通らない情勢になってしまうかもしれない。
あまり高度な仕組みを作ろうとすると実現しなかったりするので、もっと単純化した落とし所を考えておくのも重要かもしれない。たとえば、フィルタリング事業者が、Proxyサーバでフィルタリングサービスを提供している場合に、認証付きProxyとした上で、ホワイトリストでフィルタリングから除外する健全コミュニティサイトに対してだけ、ユーザIDを送信するというアイデアが考えられる。大人も、そういった健全コミュニティを利用したい人は、当該サイトへのアクセスについてだけ、そのProxy経由でアクセスするようにブラウザを設定して使うことになる。Proxyによるフィルタリングサービスがビジネスとしてまわるのであれば、このユーザID付加機能もいっしょに実現できるのではないだろうか。
注視しておかないといけないのは、冒頭で参照した総務省モバイルビジネス研究会の、谷脇康彦課長の動向である。モバイルビジネス研究会の報告書には全サイトID送信をするとは書かれていなかったが、5月に出版された谷脇氏の著書「世界一不思議な日本のケータイ」（インプレスR&D）には次のように書かれている点が気がかりだ。
（略）しかし、ユビキタスネットワーク化が進展する中、1回のユーザー認証で複数のコンテンツやネットワークを利用できるとすれば、利用者はもっと便利になる。特に共通のユーザーIDによって異なるネットワーク上においてもシームレスに認証を可能とする仕組み、つまりIDポータビリティーが実現すれば、新しいビジネスの登場も可能性として出てくる。
（略）個人のID情報は、あくまで携帯会社が格納して厳重に管理し、その個人の承諾なく部外の利用を許すことは個人情報保護法に違反する行為となる。しかし、個人の承諾を得て、そのIDに紐付けられた年齢や性別などの属性情報を一定の基準を満たしているコンテンツプロバイダーに提供する仕組みが確立されたら、何ができるようになるだろうか。
（略）タグ情報自体が結びついて、このコンテンツにアクセスした利用者は別のコンテンツにも興味があるといったことも把握しやすくなる。いわゆるセマンティック・ウェブ（semantic web）と呼ばれる世界で、情報のタグ化とID情報を組み合わせると、コンテンツプロバイダーは特定の顧客グループをターゲットにしたコンテンツの販売が従来以上に容易になるだろう。
ネット広告の分野でも、こうした情報タグとID情報を組み合わせて、広告の訴求効果を詳細に分析し、効果的なスポット広告を展開するといったことも可能になる。
（略）モバイル広告やモバイル検索広告が急速に拡大してくる可能性がある。その意味でもIDポータビリティーの実現は、重要な課題になってくる。
（略）クッキーなどを使ってこれらの情報を記憶させておくことも可能だが、これからのシームレスネットワークの時代にはもう一歩先を見越して、固定系であれ移動系であれ、ネットに接続した瞬間に同じ作業環境を実現させて作業を再開するといったことも求められるようになるだろう。
90年代末にインターネットを舞台に言われていたような構想が、再びこんなふうに語られている。Intel社がPentium IIIにプロセッサシリアル番号（PSN）を搭載して「電子商取引に活用してください」と提案したのが、消費者団体の反対運動を招き、Pentiumの不買運動にまで発展したのは1999年のことだった。日本のケータイWebが今やっていることは、まさにIntelがPCの世界でやろうとして潰されたことである。*8
携帯電話のネットはどうぞご自由になさったら結構でしょう。でも、僕らの自由なインターネットまで同じようにされたのではたまったものではない。
固有IDの全サイト送信というアーキテクチャは、韓国の、掲示板の利用に住民登録番号を登録させる設計よりも粗悪な選択だ。
日本の消費者は欧米と違って反対運動をしない。嫌なことは嫌だとちゃんと普段から声をあげるようにしていないと、ある日突然、議員立法で日本だけインターネットの世界を変えられてしまうかもしれない。
固有IDの全サイト送信がなぜいけないのか、この日記の読者なら既に理解されているところと思われるが、白浜シンポジウムの二次会で「cookieと同じ」と言った人はセキュリティ専門家の方だっただけに、まだまだ説明し続けなければならないと思った。以下、IPv6やcookieとどのように違うのか念のためまとめておく。
ユーザは、通常の固定のIPv6 IPアドレスの他に、「Anonymous Address（匿名アドレス）」ないし「Temporary Address（一時アドレス）」と呼ばれる、一日か最大でも一週間で変化するアドレスを使うことができる。IPv6では、1つのネットワークインターフェイスに複数のアドレスを持つことができるので、待ち受け用アドレスとは別のソースアドレスを使うことができる。
したがって、Webブラウザは、Anonymous Addressをソースアドレスとして使うよう実装されるだろう。アクセス先のサーバから見ると、アクセス元は、現在のIPv4のIPアドレスと同程度に変化するアドレスとして見えるようになり、新たなプライバシー問題は生じない。*9
このように、「IPv6になればどのみちIPアドレスで個人が特定されるようになる。それは世界の技術者が許しているのだから、問題ないはずだ」という考えは、半可通の技術者が陥りやすい誤った考えである。
cookieはプライバシーと関連づけて語られることがあるため、「IDのプライバシーの問題は、せいぜいcookie程度のものだろう」と考える人がいるようだ。まず、cookieには2つの種類があって、問題とされるのはその一方であり、現在ではその問題がおおむね解決されていることについて理解して欲しい。
cookieは、第一者（1st party）cookieと第三者（3rd party）cookieとに分けられる（図1）。第一者cookieとは、訪問したサイトから発行されるcookieのことで、再三者cookieとは、訪問したサイトに埋め込まれているオブジェクト（画像や、Flash等）の置かれている（訪問先とは別の）サーバから発行されるcookieのことである。
典型的には、広告業者が提供している広告画像やFlashへの埋め込みリンクがそれに該当する。閲覧者は www.example.com を訪れただけであっても、自動的にWebブラウザが ad.doubleclick.com にもアクセスするようになっており、ad.doubleclick.com 発行のcookieを受け取り、送信することになる。
広告会社は、広告をより効果的に表示させるために、閲覧者ひとりひとりにID番号をふって、cookieとして閲覧者のブラウザに記憶させている。これにより、同じ人が広告を見た回数等をサーバ側でカウントすることができ、同じ人に何度も同じ広告を見せないようにするといった制御ができる。ここまでなら、閲覧者にとっても都合の悪くない話で、ほとんど問題にならない。
ところが、第三者cookieを用いると、さらに踏み込んだ広告制御ができるようになる。たとえば、もしある広告会社がシェアを独占し、どこのWebサイトに行ってもその広告会社の広告が埋め込まれているという状況になると、閲覧者は、どこのWebサイトを訪れても、その広告会社のサーバにアクセスすることになり、そのとき、広告会社が発行したID番号付きのcookieを送信することになるので、広告会社は、各IDの人ごとに、その人が何時何分にどのWebページを閲覧したかをすべて（その広告会社の広告が出ているすべてのページについて）把握できる状態になる。広告会社としては、閲覧者の嗜好に合った広告を表示するために、この仕組みを活用することができる。
そのIDが具体的に誰であるのかが判明しなければ、プライバシー上問題ないと主張する人もいるだろう。しかし、何らかの方法で、広告会社がそのIDの人が誰であるかを特定することができれば、過去にさかのぼって、実は誰だったということが全部判明してしまう。
実際に広告会社がそうしたことを行おうとしていたかは定かでないが、そうした懸念から、米国では2000年に、当時大きなシェアを占めつつあった広告会社のDoubleClick社に対して、消費者から集団訴訟を提訴される事態となった。その訴訟は、結局、DoubleClick社が、ネットでの閲覧情報とそれが誰であるかの情報をひも付けない（消費者の許可がない限り）ことを約束して、2002年に和解した。
米ダブルクリックがプライバシ侵害の集団訴訟で和解, , 日経IT Pro ニュース, 2002年4月1日
・DoubleClick社は、収集した個人情報と以前にWebサイトから取得したクリック・ストリームの情報を照合する際は、インターネット・ユーザーにその旨を明確に通知し、ユーザーの同意を得る。
また、EUでも、そのころからcookieを法律で規制する動きが始まり、現在では、EU加盟各国はcookie規制に関する立法措置が求められている。
欧州委員会は、迷惑メール削減とcookie規制のためのEU法を、自国の法律に組み入れていない加盟国8カ国に、2カ月以内に対応するよう最終警告を出した。
一方、そのころ、技術的な対策もとられるようになった。Microsoft社は、Internet Explorer に、バージョン6 から、P3P (Platform for Privacy Preferences)という仕組みを導入した。P3Pは、Webサイト運営者が、cookieをどのように使うかのプライバシポリシーを、ブラウザに対して機械的に自己申告できるようにする仕組みで、Internet Explorer 6 では、P3P宣言のない第三者cookieは、デフォルトで拒否する設定になった（図2）。第三者cookieの全部を拒否するのではなしに、P3Pポリシーで区別するようにしたというのは、広告業界の既存のビジネスを妨害することなく、利用者のプライバシーも確保したいという、妥協の産物だったのだろう。
しかしながら、P3Pポリシーは自己申告であるため信用できないという主張もある。昨今のスパイウェア対策ソフトは、「トラッキングクッキー」型のスパイウェアとして、DoubleClick社のcookieを検出するようになっている。（2007年1月21日の日記「「スパイウェア」が侵入してくるのはどんなときか実験してみる（CA基準）」参照。）
日本ではあまり語られることがないが、Googleが2000年ごろに大成功をおさめたのは、第三者cookieを使わない広告方式を発明したからだった。
アドセンス広告は、JavaScriptとして配信される。これは、<script>タグによって広告掲載ページに挿入するようになっているのだが、これは単に手間を省くためのものではない。DoubleClickのように<img>タグで挿入するオブジェクトは、cookieの発行先が広告配信サーバとなり、第三者cookieとなってしまうのに対し、<script>で挿入したJavaScriptコード上で「document.cookie="..."」でcookieをセットした場合は、広告掲載ページのドメイン上にcookieが生成されるため、第一者cookieとなる。
実際、Google社の、JavaScriptコードを配信するサーバは、Set-Cookieをしないようになっており、Googleが第三者cookieを発行しないよう配慮していることを確認できる。Googleは、当時DoubleClickがプラバシー訴訟を起こされる社会情勢の中で、このような仕組みを発明したことで、専門家からの批判を免れることができ、技術者らからの信頼を獲得して、成功したのだと言える。*10
そして近頃では、第三者cookieがもはや活用されなくなってきたのか、Apple Computerのブラウザ「Safari」は、デフォルトで全ての第三者cookieを拒否する設定になっている（図4）。広告業界も第三者cookieを活用することを諦めつつあるのではないか。
「スーパーcookie」と呼ばれる概念がある。スーパーcookieという技術があるわけではないが、一時期、Windows Media Playerがそのような仕組みを導入してしまって、BugTraqで脆弱性であると批判され、Microsoftが即座にその機能を撤廃したという歴史がある。
これはどういうことかというと、Windows Media Playerに、ユーザごとに唯一のIDが埋め込まれており、これが「document.WMP.ClientID」というJavaScriptコードで読み出せてしまうため、Webサイトにこのコードが仕掛けられていると、それらのサイトで閲覧者が追跡されてしまうという指摘である。
これは、追跡性において、第三者cookieを包含しつつそれを上回る能力を持つため、スーパーcookieと呼ばれる。
もし第三者cookieが使えなくなったとしても、広告会社は、その代替手段としてこの Windows Media Player のIDを用いて同様に閲覧者を追跡できるわけで、スーパーcookieは第三者cookieの能力を含んでいる。
一方、第三者cookieによる追跡では、広告会社が異なれば異なるcookieのIDで管理せざるを得ないため、追跡できる範囲がその広告会社の広告の設置される範囲に限定されるものであったのに対し、スーパーcookieでは、どのサイトでも同じIDを取得することができるためその制限がない。
また、第三者cookieの場合は、そのcookieを発行する画像なり何なりを、あらゆるサイトに埋め込んでもらわないと、第三者cookieとしての能力が出てこないという限界がある。いろんなサイトに埋め込めんでもらうというのは、まさに広告なら起こり得ることであるが、他に、ブログパーツなども該当するにしても、いずれにせよ、いろいろなサイトから信用されているものしか埋め込まれることはない。悪意あるサイトがトラッキングのために第三者cookieを発行しようとしても、広範なサイトから信用を得ない限り、それができなかった。ところが、スーパーcookieでは、そうした準備が不要であり、悪意ある者にも利用できてしまう。
このように、スーパーcookieは、第三者cookie以上の追跡能力を持つのであり、それゆえそのように呼ばれる。1999年に、Intel社がPentium IIIのプロセッサシリアル番号（PSN）でやろうとしたこともこれと同等の結果をもたらすものである。
Microsoft社は、2002年にこのことを指摘されると、この機能がマズいものであることを即座に認め、この機能をデフォルトでオフとするように仕様変更した。現在でも、Windows Media Playerの初回起動時に「一意のプレーヤーIDをコンテンツのプロバイダに送信する」という設定項目が出てくるが、そこはデフォルトで無効になっている（図5）。
このように、通常のインターネットの世界では、スーパーcookieのような機能が存在することはセキュリティの脆弱性として認識されており、世界的な展開をする企業がもし勇み足でそのような機能を導入しようとしたならば、市民がそれを許さないという構図になっている。しかし、日本の技術者はこうしたことに疎い。技術がいつも英語圏で設計され、駄目な設計に対する批判も英語で行われて淘汰されるため、日本人は理由を知らないまま、安全に設計されたものをただ使うだけになっている。
白浜シンポジウムで「cookieと同じ」と言った人は、その際に、「じゃあ、実際どんな被害が出たというの？」とも言ったのだが、こうやって技術者らによって解決が図られてきた経緯があるからこそ、大きな問題になっていないのであって、「現に問題が起きていないようだから、問題はなかった」という考えは誤りである。*11
そして、日本のケータイWebの契約者固有IDの全サイト送信は、まさにスーパーcookieと同一である。*12
スパイウェア対策ソフトが「トラッキングcookie」としてスパイウェア扱いする第三者cookieであるが、それがもたらすプライバシー上のリスクは、スパイウェア対策ソフトが騒ぐほど深刻なものではないとする考え方もあるだろう。DoubleClickの件でも、上で、「何らかの方法で」と書いたように、どうやって広告サーバのID情報とリアルな個人とを紐付けるかという話があるし、cookieはいつでも閲覧者側でリセット（削除）できる。
しかし、携帯電話の契約者固有IDの全サイト送信はそれとは違う。NTTドコモのサポートセンターが「（iモードIDは）基本的にお客様にずっと通して使って頂くもの」と言うように、リセットするものではないし、第三者cookieを超えたスーパーcookieである。
国民生活センターのサイトに「あわてないで!! クリックしただけで、いきなり料金請求する手口」という、いわゆるワンクリック不当請求に対する注意喚起が掲載されている。2004年12月に公表されたものであるが、現在もセンターのトップページから案内されており、消費者に知らせるだけでなく、消費生活専門相談員や消費生活アドバイザーらのバイブルとして活用されていると思われる。
しかしながら、この資料うち、携帯電話の場合について解説された以下のページには、不適切なアドバイスがあり、これは修正するべきである。
国民生活センターのこの解説を読むと、この警告ダイアログで「YES」を選択しても「NO」を選択しても同じだという理解をさせてしまう。そして、「契約者名等の情報が伝わることは絶対にありません」、「個体識別番号から個人情報は伝わらない」と解説されているので、「YES」を選択しても何ら問題がないと理解させてしまう。
ワンクリック不当請求の場合、「請求されても支払わなくてよい」ということを伝えなくてはならないため、「個体識別番号を特定しました」といった脅しは無視するようアドバイスすることになる。その趣旨は理解できる。だが、その思いが高じて、個体識別番号を「YES」で送信してしまってかまわないとまで言ってしまうのは間違いだ。
携帯電話の個体識別番号は、インターネットのIPアドレスとは異なり、個人が特定され得るものである。 （略）
ユーザXが、マイナーな携帯電話向けネットショップYを訪れて、買い物をする。Xは、商品の送り先として、自分の住所氏名を記入してYに送信する。Yは合法なサイトで、商品もちゃんと送られてくる。
しかし、Yは、顧客が5000人以下で個人情報保護法の個人情報取扱事業者に該当しないとの認識から、顧客リストを売却してしまう。
Yは、ネットショップで住所氏名を記入させる際、不正防止の目的で携帯電話の個体識別番号（携帯電話製造番号等）も合わせて記録していた。売却された名簿には、住所氏名に個体識別番号も併記されていた。
ユーザXは、リンクを辿ってたまたまワンクリック不当請求サイトを訪れる。そこはZが運営するサイトであった。このときXは、NTTドコモの「携帯電話情報を送信しますか？」の警告ダイアログに対し「YES」を押してしまう。
すると、Xの携帯電話に、Xの住所と氏名が画面に表示される。（もしくは表示はされなかったが、）後に、郵便で請求書が送られてくる。
つまり、「安全なケータイWeb利用リテラシ」から外れた行動（例えば、たまたま訪れたネットショップなどで商品送付先の住所氏名を記入するなど）をしたことがあると、ワンクリック不当料金請求サイトを訪れてしまった際に、住所氏名を示して請求されることが起こり得る。
iモードも、契約者固有ID（個体識別番号）を自動で送信するようになり、もはや「NO」を選択する余地がない。
住所氏名を示して請求された場合、契約が成立していると見なされる状況では、無視することはできなくなるのではないか。過去には、架空請求で裁判所に少額訴訟を起こされるという事例があったが、架空ではなく、ワンクリックサイトで何らかのコンテンツにアクセスした場合には、本当に無視できなくなる場合があるように思う。
無視しちゃいけない架空請求？正しい知識で自己防衛を 「無視出来ない架空請求」を知る, All About, 2004年9月22日
無視していられるためにはまず住所氏名を相手に特定されないようにしている必要があり、そのためには、契約者固有ID（個体識別番号）を送信してしまうようなケータイWebを使わないようにするか、使う場合には、ネットショップにさえ住所氏名を明かさないよう注意せざるを得ない。
*1 このIDがどんな文字列で送信されているかは、たとえば、このIDをあえて表示するようにしている掲示板の書き込み例を見ることで、知ることができる。たとえば、2ちゃんねる掲示板のこの板には、多数の契約者固有IDの表示が見られる。ここに表示されているID文字列をキーにGoogleなどで検索してみると、同じ人が別のところでどんな書き込みをしているかを調べられることがわかる。
*2 6月30日、モバイルコンテンツ審査・運用監視機構が、「コミュニティサイト運用管理体制認定基準」を公表した。認定基準の要求項目の1つとして、「16. ユーザー情報管理 事業者は、会員及び非会員投稿者（非会員による投稿が可能なサイトの場合） に対し、携帯端末を特定する個体識別番号等を取得しなければならない。」とされている。
*3 6月28日、読売新聞に「犯行予告を監視、悪質利用は退会…携帯サイトに「健全基準」」という記事が出た。
*4 この取組みが功を奏したのか、6月11日に可決成立した「青少年が安全に安心してインターネットを利用できる環境の整備等に関する法律」は、罰則規定もなく、民間による自主的な取組みを尊重するものとなった。この法案に懸念を表明していた団体の一つであるMIAUは、6月15日の「青少年ネット規制法の成立について」で、「（略）しかしながら、条文や付帯決議、答弁等によれば、関係者各位の努力によって、MIAUを初めとする多くのインターネット・ユーザーが懸念を表明していた問題の幾つかは払拭され、最悪の事態は回避されたと考えております。 」と表明している。
*5 このiモードIDの送信開始の件は他の新聞では報じられていなかった。おそらく、日経新聞の記者ないし編集者は、これがプライバシー上問題があることを認識して報じたのだろうと思っている。問題があるとは書けないだろうが。
*6 その後、6月11日に可決成立した法律では、プリインストールの義務付けではなく、「フィルタリングサービスの利用を容易にする措置を講じた上で、当該機器を販売しなければならない。」と、弱められたものに修正された。このことについては、小寺信良氏の6月11日のブログエントリ「ネット規制法の解釈」で解説されている。また、6月10日の参議院内閣委員会で、マイクロソフト技術統括室CTO補佐の楠正憲氏が参考人として次の通り発言しており、法案提出議員から次の通り答弁を引き出している。
（略）楠参考人にもう一つ、ちょっと技術的なことですが、大事なことなんで伺っておきたいんですけれども、先ほどちょっと例示しましたＰＳＰとかアイポッド・タッチとかアクトビラ対応テレビとかリナックスマシン、これ、それぞれに組み込み可能なフィルタリングソフトというのはあるんでしょうか。
残念ながらまだ市場に出て間もないということもございまして、個別にフィルタリングサービス等が提供されているデバイスはＰＳＰ等に限られるというふうに考えております。また、こういった機器は組み込み機器でございまして、後からフィルタリングソフトウエア等を導入することが難しいといった制限もございます。
ですけれども、元々多くの機器がプロキシーサーバー設定機能という、いわゆるインターネットに接続する際のサーバーを指定する機能を持っておりまして、ＰＳＰ向けにフィルタリングサービスを提供しているベンダー等もこのプロキシーサーバー設定機能を用いて提供しておりまして、同様のことはデジタルテレビ等でも対応可能であろうというふうに考えております。
また、現段階で幾つかのデバイスにつきましてはプロキシーサーバー設定機能を持っていない現状がございますけれども、こういった機器もファームウエアの更新で容易にこういった機能を付加できるようには作られておりますので、今回のような法律ができることによってそういった適切な対応を促すことができるのではないかというふうに考えております。
（略）フィルタリングサービスの利用を容易にする措置を講ずるということが求められるわけでありますが、例えば今参考人がおっしゃったような言葉で言うと、組み込みソフトが現時点でないという場合はプロキシーサーバーの設定機能を提供することをもってして、この十九条に言うところのフィルタリングサービスの利用を容易にする措置であると、そういうふうにみなしていいかどうか、これは法案提案者の見解を伺いたいと思います。
松井委員御指摘のとおり、そういった措置はフィルタリングの利用を容易にする措置を講じたものというふうに解されると考えているところでございます。
*7 6月11日に成立した法律は、小寺信良氏が言うように「すでに業界でやってることを上から法でなぞっただけであり、現状はほとんど変わらない」ものとなったようだが、参議院内閣委員会で、法案提出者である青少年問題に関する特別委員長は、最後で次のように釘を刺しているわけで、民間に委ねたものの再びうまくいかなくなれば、規制強化ということも十分にあるのではないか。
本法では、その意味では効果としては青少年がインターネットに関連して被害に遭わないようになるということを期待をしていることは間違いないところでございますが、本法案の目的は、題にもありますように、青少年が安全に安心してインターネットを利用できるようにすることということでありますし、またこの第一条の目的にも、青少年の権利の擁護に資するというふうに記しましたのも青少年が意図せずに、若しくは図らずも接したくない情報に接することがないようにする権利が青少年にはあるんだと、情報を言わば自ら管理をする権利があるんだということを私どもとしては考えておりまして、そういったものを確保するためのこの法律ということになります。
その意味では、犯罪が増えたとかそういった事実をもってこの見直しに端的につながるものではないというふうに考えておりますし、またこの法律を制定をするに当たっても、表現の自由、通信の秘密などを考えますと、そもそも規制を今回も青少年の大変な今の危機的な状況にかんがみれば、やむを得ずせざるを得なかったという状況でこの法律は制定をされているものというふうに解しておりますので、今後も更なるリテラシーの強化などといったことも考えられると思いますが、一概に規制強化というものは私ども提案者は考えていないというふうに申し上げたいと思います。
ただいまの点でありますけれども、今、松本委員から答弁があったとおり、単純に規制強化というものを念頭に置いているわけではございません。ただ、委員長としては、やはり特にインターネット関係者の皆さんに、今回の有害情報から子供を守るということについての施策のほとんどを、まさに民間の自主的、主体的な取組にゆだねているわけでございます。したがって、そのゆだねているということの意味をインターネット関係者の皆様にはよくお考えをいただきたいと、そういうことは併せて申し上げておきたいと思います。
Pentium IIIパソコンのボイコット運動始まる シリアルナンバー添付で、プライバシー保護団体が反発, 日経パソコン, 1999年2月22日号
2月26日から搭載パソコンが出荷される米インテルのPentium IIIに対して、米国のプライバシー保護団体がボイコットを呼びかける運動を始めた。「Electronic Privacy Information Center (EPIC)」などの団体は、米連邦取引委員会(FTC)にインテルに対して調査を行うよう求め、同社の標語「Intel Inside」をもじって「BigBrother（ジョージ・オーウェルの小説『1984』に登場する独裁者・監視者）Inside」というWebサイト上でPentium III搭載パソコンの購入を見合わせるようユーザーらに呼びかけている。
プライバシー保護団体が問題視しているのは、インテルがPentium IIIに個別のID番号「Processor Serial Number (PSN)を付加することについて。インテルは、PSNによりパソコンを個別に管理でき、インターネットでの電子商取引を円滑に行わせたり、企業内でシステム担当者が管理しやすくすることを想定しているが、これが個人のプライバシーを不法に侵害する恐れがある、としている（略）
ノート用PenIIにシリアルナンバーを組み込む 無効にすることを望むユーザーにはBIOSで対応, 日経パソコン, 1999年4月5日号
（略）PSNは、Pentium IIIのセキュリティ機能として、CPUに個別の番号を組み込んだもの。インテルでは、インターネット上での電子商取引における個人の認証や、企業内のパソコンの資産管理などに使えると説明してきた。しかし、いつどこからアクセスしてきたといった情報が分かってしまうことから、米国のプライバシー保護団体が、PSNはプライバシーの侵害にあたるとして反発。このため、Pentium IIIではユーティリティやBIOSを使って、PSNの有効／無効の設定ができるにようになっている。（略）
*9 もし、家庭向けのインターネット接続サービスで、IPv6アドレスの上位アドレスが固定的に割り当てられるようになったら、上位アドレスで個人が特定されてしまう。そこで、上位アドレスについても、現在のIPv4アドレスの割当と同様に動的に割り当てられるように運用するべきである（固定した割当を利用者が望まない限り）旨、関係者に意見してある。そのように運用されることを願うばかりだ。
*10 そんなGoogle社も、最近ではプライバシーについて批判される立場になってきたが、それは第三者cookieの問題ではなく、Google自身がたくさんのサービスを提供するようになったため、第一者cookieによるプライバシーの懸念が無視できなくなってきたためである。
*11 これはセキュリティ対策の必要性を訴えるときにしばしば苦労させられるのと同様の話だ。きちんと事前に対策を打てば被害は出ない。それを後になって、「現に被害はない。その懸念は杞憂でしょう。」と言われたとき、セキュリティ専門家はどう応じるべきだろうか。
*12 Windows Media Playerのスーパーcookieを読むには、JavaScriptでIDを読む仕掛けを設置する必要があったのに対し、ケータイWebのID送信は、ブラウザが自動で送信してしまうという点で、スーパーcookieをも上回るものとも言える。
EV SSL証明書（EV証明書）がどういうものかについて「銀行や有名企業などの特に社会的信用の高い組織しか取得できないもの」と誤解している人がいるようだ。たとえば、マイコミジャーナルのEV SSLの解説記事は、そういう誤解に基づいたものとしか思えない。
【連載】SSL入門 〜 ショップオーナーも利用者も安心! (1) 安全サイトの見分け方、わかる? - グリーンは安心カラー, マイコミジャーナル, 2008年6月30日
もし、オンラインショッピングに不安がある人でも、アドレスバーが緑色になるサイトなら大丈夫。安心して買い物をすることができます。
この記事は致命的に誤っている。アドレスバーに緑色で表示されるのは「認証局名」ではなく「サイトの運営者名」である。この記事は、運営者名が表示されることを一言も説明していない。運営者名を確かめて利用することに一言も触れずに、ただ「アドレスバーが緑色になるサイトなら大丈夫」などと無責任なことを教えている。
実際、EV証明書を取得できる基準*1を見てみると、普通の民間企業でも取得することができる。EV証明書は、その企業が実在することを証明するだけで、その企業が信用できる会社かどうかを保証するものではない*2。そもそも、「信用できる会社」なるものを一律に定義することは困難なのだから、どの会社を信用するかは、利用者各自が自分で判断するしかない。そのために、EV対応Webブラウザは、運営者名を表示するのだから、利用者はそこを読まなくてはいけない。
ところで、今後、EV証明書は金融機関だけでなく、普通の事業者も採用するようになっていくと思われる。EV対応Webブラウザは、SSL接続時の表示において、EVでないサーバ証明書の場合は（いわゆるClass 3の証明書であっても）「このサイトの運営者：（運営者は不明です）」などと表示するようになった（図1）。このような表示を嫌う企業が増えるかもしれない。
もちろん、このような証明書も、サーバとブラウザ間で暗号化通信を実現して盗聴や改ざん、DNSスプーフィング等の通信路上の攻撃から防御するという目的では十分であり、これからも依然として有効であるし、そのような機能しか必要としないサイトも少なくないだろう*3。元々、SSLはそういう目的で使用するものであり、実在証明は付加的な機能である。
では、どんな企業でもじゃんじゃん気軽にEV証明書を採用してよいものだろうか。次の例を検討してみたい。
図2は、ブログサービスの一つである「ドブログ」のユーザ登録の途中の画面である。SSLが使われており、https:// のページになっている。
もし将来、このSSLが、EV SSLに変更されたらどうなるだろうか。図3にそのときに表示されるはずの画面を空想で描いてみた。
ANSER WEBというASPサービスでインターネットバンキングを提供している金融機関が、EV証明書を導入した理由は、「NTT DATA CORPORATION」という社会的信頼の高い企業による運営であるという表示によって、利用者に本物サイトであることの確認手段を提供したことにあるのだから、これらの金融機関は、利用者が「NTT DATA CORPORATION」という名称さえ見てくれればいいことを前提としている。
しかし、もし、図3のように、ドブログのようなサイトでまで緑色で「NTT DATA CORPORATION」と表示されるような世の中になってしまったら、どうなのだろうか。
もし、ドブログのユーザコンテンツ（つまりブログ）のページが、https:// でも表示できるようになっていたらどうか。どこの馬の骨ともわからない者によるコンテンツが、「NTT DATA CORPORATION」という緑色表示の下に表示されることになってしまう。これはまずいのではないか。
現在のところ、実際には、ドブログのユーザコンテンツを https:// で表示しようとアドレスバーの http を https に変えてアクセスしてみると、 http:// のページリダイレクトされるようになっていて、そのような表示は起きないようになっている。（たまたまそうなっているのか、わかっていて対策されているのかはわからないが。）
つまり、ブログサービスのようなサイトが EV SSLを導入するときは、ユーザコンテンツのページが EV SSLサイトとして表示されないようにするべきだ。
ドブログの場合は、ユーザコンテンツに対する制限が非常にキツく、HTMLタグは全く書けないタイプのようなので、閲覧者を誤解させるようなphishing的なコンテンツを作られることはないと思われるが、スタイルシートを自由に書けるタイプとか、<input>タグを書けるタイプとか、レンタルサーバのように自由にHTMLコンテンツを書けるタイプのサービスで、ユーザコンテンツが https:// で表示可能で、かつ、EV証明書で運用されているとしたら、それは脆弱性であると言ってよいと思う。*4
しばしば、「共用SSL」などとして、共同利用型のSSLサーバを提供しているレンタルサーバサービスを見かける（たとえばこのサービスなど）。レンタルサーバ会社が代表でサーバ証明書を取得して、コンテンツは利用者に自由に書かせるというものだ。もし、こういったSSLサーバで、EV証明書が使われるようになると、運営会社の信用を誰でも汚すことができるようになってしまう。このようなサービスにEV証明書を導入する意義はなく、避けるべきである。
インターネットバンキングサービスの「ANSER WEB」のサーバ証明書の詳細を見ると、組織の部門名（OU）が「ANSER2008」となっている*5。ANSER事業部なのだろう。ググって調べてみたところ、「決済ソリューション事業本部」がそれだろうか。一方、ドブログの https:// ページのサーバ証明書の部門名（OU）は、「Business Incubation Center」となっている。
まさか、NTTデータが「共用SSL」のレンタルサーバを運営することはないだろうとは思うけれど、社内的にそうした合意が取れているだろうか。上記の3つの社内組織は、互いに、サーバ証明書の取得にあたってコミュニケーションはとれているだろうか。
決済ソリューション事業本部としては、「NTT DATA CORPORATION」という緑表示を、信用のおけるサービスの印としてEV証明書を導入したのに、B-CAS関係のMedia Industry Business Unitが勝手にEV証明書を取得したら、さらには、ブログ運営のBusiness Incubation Centerが勝手にEV証明書を取得したら、その信用を下げることになる。
従来のSSLでは、会社名だけ見て判断することは普通なかった。「安全なWebサイト利用の鉄則」にもあるように、閲覧者は、ドメイン名を確認することがまず基本で、初めて訪れたサイトでドメイン名を知らない場合に限り、サーバ証明書の発行先を見るものだった。しかも、そのサーバ証明書の確認では、組織名と部門名と所在地を確認するものだった。ところが、EV証明書では、ブラウザが緑表示する会社名だけを見て判断することになる。
そのため、EV証明書の導入にあたっては、会社単位で管理するべきであると思う*6。従来のSSLでは、部門単位で勝手にサーバ証明書を取得することができたが、EV証明書の取得では、会社で唯一の管理部門の許可なくしては部門が勝手に取得できないようにするべきではないだろうか。
管理部門としては、自社名で運営するサービスのうち、最も信用の問われるサービスが何であるかを把握しておく（たとえば金融サービス）。そして、それとは段違いで信用性の低いサービス（たとえばブログやレンタルサーバ）に対してEV証明書の取得を許可しないよう、管理する。
それだけではない。巨大な企業（NTTデータのように）が多数の種々雑多なサービスでEV証明書を使用している場合、そのうち一か所にでもクロスサイトスクリプティング脆弱性が存在すると、同社の全サービスがphishingの危険にさらされることになる。
従来でも、phishing被害を防止するにはクロスサイトスクリプティング脆弱性がないように対策する必要があったが、それは同じドメイン名の下のサーバに対して求められることだった。これが、EV証明書がどこでも使われるようになると、企業名しか見られなくなるので、同じ企業名で運営している全部のサービスが影響される。
EV証明書を取得するということは、そのリスクを新たに抱えることであり、全社的なサービスの把握なしには安易に導入してはいけないのではないか。
もっとも、ANSER WEBのEV証明書を「NTT DATA CORPORATION」とせずに、各銀行の会社名にしていたならば、そのリスクは回避された。銀行がレンタルサーバやブログサービスを運営することはないのだから、銀行名でEV証明書を取得していれば、リスクは銀行サイト内で閉じたものになる。
ANSER WEBが銀行名ではなく「NTT DATA CORPORATION」でEV証明書を取得したことについて先月27日の日記では、「まあ、それでもいいかと思うようになった」「NTTデータは著名な会社であるし」と書いたが、やはり、これは愚かな行為であると思う。EV SSLの普及とともにNTTデータは重大な責任を負っていくことになる。もしくは、NTTデータはANSER WEB以外で一切EV証明書を採用しないよう全社的に管理することで、リスクの拡大を防ぐほかないだろう。
CAは、以下に定める要件を充足する民間組織および行政機関に対してのみEV証明書を発行しなければなりません。
(1) 民間組織は、法人設立管轄地の法人設立機関への届け出(または法人設立機関の行為)(例：法人の設立を証明する証明書の発行など)によってその存在が確認できる法人でなければなりません。
(2) 民間組織は、(法人設立管轄地の法律に基づき要求される場合)法人設立機関に、Registered Agent、Registered Officeまたはこの相当物を登録しなければなりません。
(4) 民間組織の法人設立地および/または事業所所在地は、CAの管轄地の法律によって取引または証明書の発行を禁じられているいかなる国にもあってはなりません。また、
(5) 民間組織は、CAの管轄地の法律に基づく行政機関の拒否リストまたは禁止リスト(輸出禁止など)に記載されていてはなりません。
本ガイドラインが追加の審査基準を設けない限り、CAは上記要件を充足しないいかなる人物あるいは組織またはエンティティにもEV証明書を発行してはなりません。除外されるサブジェクトには以下のものがありますが、これだけに限定されません。
*2 では、従来のサーバ証明書とは何が違うのかというと、実在性を証明する基準が明確化され、認証局間で統一されたという点が新しい。従来では、たとえばVeriSign社は運営する認証局に、Class 1、Class 2、Class 3という区分を設けていた。Class 3は企業の実在性を確認するものでEVに近い基準を持っていたのに対し、Class 1はそういった確認をしないもので、個人でも誰でも取れるものであった。VeriSign社は、Class 1の証明書の発行は、S/MIMEメール用としては行っていたが、サーバ証明書としては発行していなかった。ところが、後に、Class 1に相当するサーバ証明書を発行する新興認証局事業者が現れるようになった。そして、Webブラウザのユーザインターフェイスは、Class 1かClass 3かといった区別を表示する仕組みを持たなかったため、利用者が証明書の信頼性を確認するには、詳しい知識を必要としていた。EV証明書は、このClass 3に相当する信用性基準をより厳格に定めて、業界で統一したものと言える。この基準ができたことに対応して、Webブラウザもそのクラスの証明書であることを、わかりやすい形で表示するユーザインターフェイスを備えた。
*3 たとえば、ドメイン名として go.jp を使っているサイトでは、実在証明は不要だろう。図1のように、Firefox 3では、URLからドメイン名部分を切り出してわかり易く表示してくれる。一方、汎用 .jp ドメインで行政機関が何かを運営するときには、EV証明書を使った方がよいかもしれない。
*4 こうした問題は、Mutualアクセス認証をブログサイト等に導入した場合にも生じ得る。ログイン中の緑表示の出る画面上に、他人が自由なHTML（入力フォーム等）を書ける場所を作ってはいけない。
赤☆ネットのご利用環境 セキュリティ証明書（Mozilla Firefox3をご利用の方）, 主婦の友社
愛読者サイトにアクセスをすると下の画面が表示されます。「赤☆ネット」は「www.en-jin.com」のセキュリティーを使用しているために、このような警告がでますが
2005年2月20日の日記で「フィッシング防止のため地方銀行はこうするべき」ということを書いた。つまり、インターネットバンキングのログイン画面のページで、ちゃんと銀行のドメイン名を使用するべきだという話だった。たとえば、NTTデータの「ANSER WEB」を利用してインターネットバンキングのサービスを提供している小さな銀行らは、anser.or.jp というドメイン名のURLのページ上にログイン画面があるため、一般の利用者達にとって、本物と見分けるのが簡単ではなかろうという話だった。
インターネットバンキングサービスのフィッシング対策を強化！ 〜「EV SSL証明書」と「フィッシングサイト閉鎖サービス」を導入〜, NTTデータ, 2008年4月22日,
NTTデータでは、こうした状況を踏まえ、サイトの信頼性を確認するための「EV SSL証明書」および「フィッシングサイト閉鎖サービス」を約80の金融機関にご利用いただいているANSER-WEB（アカウントアクセス）ならびに ANSER-WEB（アカウントアクセス）コーポレートエディションに導入し、フィッシング対策の強化を図ってまいります。
日本ベリサイン株式会社の「ベリサイン グローバル・サーバID EV」は、Internet Explorer7を利用する場合、ソフトのダウンロードを要することなく、正当なサイトであればアドレスバーが緑色表示になり、サイト運営者も表示することができるため、利用者が視覚的にサイトの正当性を確認できる点がメリットと考え、導入を決定しました。
ドメイン名はどうなったのだろうと、地方銀行のいくつかを見に行ってみたところ、なんと、下の図のように、「NTT DATA CORPORATION」と表示されていた。
図2: 緑色部分をクリックしてEV SSL証明書の発行先を確認した様子（Firefox 3の場合）
これにはいささかがっかりした。しかし、まあ、それでもいいかと思うようになった。ANSER WEBを利用している金融機関は80にものぼるというし、それがこの1つのEV SSL採用で、80もの金融機関が対応済みとなるのであれば。NTTデータは著名な会社であるし、銀行のサービスがNTTデータによって運用管理されているであろうことは、多くの人々にとって想像に及ぶものであろう。
この場合、重要なのは、各銀行が利用者に対して「NTTデータに委託している」事実を正直に説明できるかどうかとなる。
いくつかの銀行を見てまわったところ、EV SSL導入を知らせるページが用意されていて、銀行によっては、「当行のインターネットバンキングはNTTデータ社のシステムを利用していることから、組織名には同社の名称が表示されます」といった説明をしているところもあった。銀行によっては「NTT DATA CORPORATION」と表示される理由を説明していないところもある。おかしなプライドがそれを許さないのか、あるいは、単に説明する必要性に気付いていないのか。後者であれば、その銀行の担当者自身、安全にWebを使うことのできない人だろう。
(2) SSL暗号化通信を表す鍵マークと共に、ウェブサイトを運営している組織名(※)（NTT DATA CORPRATION [JP]）とEV SSLサーバー証明書を発行した認証局（VeriSign によって識別）が表示されますので、それぞれを確認してください。
(※) 当行のインターネットバンキングはNTTデータ社のシステムを利用していることから、組織名には同社の名称が表示されます。
このことをもっとちゃんと明記するべきだ。ANSERのログイン画面にジャンプする直前の、銀行自身のWebページに書いておくのがよいだろう。
ちなみに、かつて「cyber-biz.ne.jp」という怪しげなドメインにログイン画面を構えていた銀行もたくさんあったが、今ではそのほとんどが銀行自身のドメイン名の上に移転したようだ。（移転といっても、IPアドレスは替わらず同じサーバが使われていると思われる。）
そのうちのいくつかの銀行が、EV SSLを採用したようで、それらではちゃんと銀行の社名が緑色表示されるようになっている。
ところが、Firefox 3で見ると、図5のように、通常のSSLサイトとして表示されてしまう。同様に、Opera 9.5でも、図6のように、通常のSSLサイトとして表示されてしまう。
また、Windows XP Service Pack 3 のInternet Explorer 7（EV SSL対応のはずだが）で表示したときも、通常のSSLサイトとして表示されてしまう。しかし、Windows Updateの追加インストールで「ルート証明書の更新プログラム」を導入すると、Windows Vistaの場合と同様にEV SSLに対応した緑表示となる。このことは、スルガ銀行のEV SSL証明書の説明ページにも次のように書かれている。
WindowsXPをご利用のお客さまは、自動的にアドレスバーが緑色にならないため、下記の手順でWindows Updateの作業をしてください。
どうやら、「EV SSL対応」といっても（しかも同じVeriSign社発行のものであっても）、少なくとも2つのタイプがあるようなので注意が必要そうだ。
スルガ銀行、フィッシング詐欺対策として携帯電話対応EV SSL証明書を採用, ＠IT情報マネジメント, 2007年11月8日
グローバル・サーバID EV for Mobileを導入したサイトにユーザーがアクセスすると、ブラウザのアドレスバーが緑色になり、安全なサイトであることが一目で判別可能になる。同証明書はさらに、PCからのアクセスだけではなく、SSL対応携帯電話からアクセスした際も同じようにサイトの安全性を判別できる。
この記事は間違っている。携帯電話のWebブラウザでEV SSL対応のものはまだ存在しないのだから、「携帯電話からアクセスした際も同じように」「ブラウザのアドレスバーが緑色になり、安全なサイトであることが一目で判別可能になる」などということはない。
なぜこんなおかしな記事が出てしまうかというと、ベリサインの「グローバル・サーバID EV for Mobile」という商品がどういうものなのかわかりにくいためだ。これがどういうものなのかは、ベリサインのFAQを読むとわかる。
Q.グローバル・サーバID EVとグローバル・サーバID EV for Mobileの最も大きな違いは何ですか？
グローバル・サーバID EVは、Windows Vistaに加えて、Windows XPに搭載されたInternet Explorerでもブラウザのアドレスバーを緑色にすることが可能ですが、その一方で、一部の携帯電話端末ではSSL通信ができないということを確認しています。 グローバル・サーバID EV for Mobileでは、SSL通信に対応するほぼすべての携帯電話端末でSSL通信ができるようになります。
つまり、通常のEV SSLでは、携帯電話の少なくない機種で、そもそもSSL接続が正常にできなくなる（オレオレ証明書状態になる）ため、携帯電話で正常に接続できるような特別なEV SSL（CAの認証パスを工夫したもの）を用意したというのが「グローバル・サーバID EV for Mobile」のようだ。「for Mobile」といっても、現在の携帯電話でEV SSLとして意味をなすわけではない。
@ITの記事が参考にしたと思われるベリサインのプレスリリースは、嘘は書かれていないものの、デメリットの存在が非常にわかりにくく書かれているため、@ITの記者は間違えてしまったのだろう。
デメリットは、Windows XPのユーザは「ルート証明書の更新プログラム」を導入しないとEV SSLが有効にならない点とされているが、どうやら他にも、Firefox 3やOpera 9.5でもEV SSLが有効にならないようだ。
ベリサインの用途別の選び方の説明（下の方）には、「現在はPCのみだが、将来的には携帯電話からのアクセスにも対応させる場合」には「グローバル・サーバID EV for Mobile」がよいと勧められている。しかし、これから携帯電話向けサイトを構築するなら、そもそも同一のサーバ証明書を使う必要がない。PC向けサイトでは普通のEV SSLを使用し、ケータイ向けサイトでは別サーバで普通のSSL証明書をもう一枚用意すればよい。
サイトが小規模の場合には別サーバにできない事情があるかもしれないが、複数台のサーバを要する規模のサイトでは、PC向けとケータイ向けはサーバを別にした方がよい。今後もこの種の不都合が出てくるだろう。2048ビットRSAへの対応やSHA-2への対応でも、PCでは先行して進むのに対し、ケータイでは古い機種が残るため遅れると思われる。
スルガ銀行は、EV SSLの説明で、「パソコンだけではなく、携帯電話でも」と先進性を誇っているようだが、単にシステムの都合上そうせざるを得なかったという話で、PC向けとケータイ向けを分離したシステム構成に変更しなかったおかげで、せっかくのEV SSLの有効性を一部のブラウザに限定してしまっている*1わけで、ちっとも先進的でない。
被害が深刻化しているフィッシング詐欺対策として、EV SSL証明書、「グローバル・サーバID EV for Mobile」（携帯電話併用）を採用し、パソコンだけではなく、近年利用が増加している携帯電話でも、お客さまに安心・安全にご利用いただける環境をご提供します。
*1 スルガ銀行は、「推奨環境について」に書かれているとおり、Firefoxを排除しているわけではない。

 

戻る