最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1501   昨日: 2734

2004年09月06日

「すぐに気持ちよくなるから大丈夫だよ」の世界

ありがちな光景ではあるが、問題点を指摘した人たちの功績を無視しながら(あるいはむしろ蔑視しながら)、得られた成果にタダ乗りしているくせに、踏ん反り返って見せるような人がいる。

  • 渡辺聡・情報化社会の航海図, 普及期の技術と社会受容:RFIDをショートケースに, 2004年9月3日

    安全性への懸念というのは、新しい技術がまだ受容されておらず、リスクが十分に理解検証されていない状態がゆえに発生している。当初激しかったGmailへの反発も同じフレームに乗せられる。これらの議論は本質的な問題であれば、提供側が是正するなりの対応をする必要があるが、議論を深めるうちにそう大した話ではないという認識が一般化していって問題自体が消えてなくなることもあるGmailも気が付けば結構普通に使われている訳である(略)。

    (略)

    おそらくは、RFIDはこういうシナリオで普及していくに違いない

    内容的に特に追記するまでもないが、RFIDは普及前のごちゃごちゃとした状態にあり、メディアで取り上げられる声も危険性を声高に指摘するものあり、反対に安全性の検証の話ありとまったく落ち着いていない。後世から振り返ると、確かに過剰とも言える議論は混ざっているだろう。今の私たちがテレビ普及期のエピソードを聞いて思わず笑みを浮かべてしまうようなこともあるのだろう。

    しかし、普及期というのはそんなものだというのが考え方としておそらく正しい。インターネットからモバイルから大小様々なイノベーション事例を見ていると多かれ少なかれ何か起きている。通過儀礼のようなものなのだろう。

まず、Gmailの件はRFIDの件とは性質が異なるものである。Gmailの件は、ユーザが運営者を信頼できるかという問題であった。

2月1日の日記「混同して語られ続ける、プライバシー問題の6種類の原因要素」に分類した第一から第六までの問題点のうち、Gmailの件は、第三、第四、第五の点が問われた騒動だったと言える。まずこれらの分類を再掲しておく。

第一は、システムの欠陥が原因で、守られるべきプライバシー情報が事故で漏えいしたり、故意に盗み出されたりする可能性である。これは、システムのセキュリティ対策によって解決すべき問題であり、現実的なコストで解決可能かが問われる。

第二は、内通者が情報を外部に持ち出したり、従業員のミスで漏えいさせる可能性である。これは、人的セキュリティマネジメントの強化によって解決すべき問題で、どの程度それが可能なのかが問われる。

第三は、事業者が情報を外部に提供する予定がある場合に、それを消費者が承知しているかの問題である。これは、情報を収集する目的を事業者がプライバシーポリシー等の文書で消費者に説明する責任を果たすことで解決すべき問題であるが、消費者への通知が、実効性のある方法で行われるのかが問われる。

第四は、情報家電が普及したとき、生活のあらゆるシーンで情報技術を駆使したサービスを受けることになると、ありとあらゆるプライバシー情報を多数の事業者のそれぞれに預けることを消費者は選択しなくてはならなくなる。このとき、「この事業者は信頼するが、あの事業者は信頼しない」といった判断が、普通の消費者にはたして可能なのかという懸念である。

第五は、第四のような状況において、プライバシー情報の事業者を越えた共有が顧客分析を目的として広く行われるようになった場合など、どの事業者も同じようにプライバシー情報を多目的に使用する社会が訪れる可能性があり、消費者が事業者を選択できなくなる懸念である。

そして第六は、RFIDタグやsubscriber IDのように、何かにIDが付くことによって、第三者(IDを取り付けた者とは別の)がそれを媒介して消費者のプライバシー情報を収集することが可能になってしまう問題である。

混同して語られ続ける、プライバシー問題の6種類の原因要素

第一と第二の点を除外したのは、Gmailでは、蓄積型Webメールサービスの上にターゲット広告機能を追加するという話であって、蓄積型Webメールサービスを提供する時点で、第一と第二のリスクは既に存在するからである。

Gmailにおける第一と第二のリスクは、ユーザが事故のリスクと利便性を評価して自己決定することであり、その他のサービスにも多かれ少なかれ同様のリスクが存在する。(ただし、蓄積型Webメールは事故時の被害規模を大きくするという点でリスクが大きめになるという点と、分析済みの情報が漏洩することで被害の質が悪化する、あるいは、攻撃の動機が増すという論点はあるにはある。)

第三の点についてGmailがどうか、私個人の認識はこうである。Gmailは超メジャーな運営者によるものであるため、衆人の監視下にあると言えるので、プライバシーポリシーは嘘偽りなく曖昧性なくきちんと整備され(そして遵守され)、大多数の人がそれに納得して使用するようになるであろうから、自分も使って大丈夫だと感じるだろうと予想できる。

もちろん、そうした監視と妥当なポリシーへの収束は、消費者の懸念が十分に運営者に伝わってこそであり、その意味で今回の騒動は必要な役割を果たしたと言えるだろう。たしかこの件は、Gmail側がプライバシーポリシーの改訂をしたと記憶している。

それに対して渡辺氏の、「議論を深めるうちにそう大した話ではないという認識が一般化していって問題自体が消えてなくなる」「思わず笑みを浮かべてしまう」という発言は、問題点を指摘した人たちの功績を無視しながら(あるいはむしろ蔑視しながら)、得られた成果にタダ乗りしているくせに、踏ん反り返って見せるようなものだ。

第四の点については、他のマイナーなサービスまでもが同様の機能を搭載するようになると、それぞれの信頼性をいちいち確認できなくなるという懸念であるが、こうした懸念は、たとえば以下の報道などに見られた。

  • Gmailはプライバシー侵害の危険な前例となりうる〜世界の市民団体が懸念, INTERNET Watch, 2004年4月20日

    Gmailが危険な前例となって、メールのプライバシーは守られるべきだという人々の認識が弱くなり、今後、他の企業が悪意を持ってメールのメッセージを利用する可能性が高くなると指摘。さらに、人々のこのような感覚や一度設定された水準は、Googleという企業そのものがなくなった後も残るとしている。

Gmailはメジャーであるが故に、多くの指摘を受けてポリシーが妥当化され、その遵守状況の監視が行き届くことになったが、今後マイナーな運営者が、外見上Gmailと同様のサービスを新たに開始したとき、人々はそれを、Gmailと同様に妥当なポリシーで運営されているに違いないと思い込んでしまうということが起きてくる。そのときに、実はそのサービスが、Gmailと違って、嗜好情報を第三者に提供しているのが事実だというようなことが起きるかもしれない。

この懸念は払拭されていないのではないかと思うが、Gmailの騒動が大きくなったことによって、それなりに監視の目は行き届いていくのかもしれない。

第五の点については、Gmailのようなサービスにおいては、心配ないだろうと個人的には予想する。さすがに、そうしたサービスを使わないという選択肢がなくなるとは思えない。

そして、第六の点は、Gmailにはないが、RFIDタグにはある問題点である。Gmailは一つのサービスにすぎず、信頼できないなら使わないという選択肢があるが、RFIDタグは、RFIDタグを取り付けた事業者を信頼するか否かの問題ではないのである。

RFIDタグが消費財に取り付けられることは、プライバシー侵害のためのインフラが構築されるということである。侵害する主体は、事業者のみならず、詐欺師や隣人までと幅広い。この点が懸念されていることについて、渡辺氏は単に無知なのだろう。

渡辺氏は、「安全性の検証の話あり」とも発言しているが、どこにそれがあるのか。おそらく、安全性検証とは程遠い主張を安全性の検証の話だと誤って理解しているのだと思われる。

「普及期というのはそんなものだというのが考え方としておそらく正しい」という発言もあるが、問題が指摘されて消滅した技術や修正された技術も多数ある。渡辺氏はそれらのことを知らないのだろう。知らなければ、何でも「気が付けば結構普通に使われている訳である」と言っていられて楽だ。

本日のリンク元 TrackBack(0)

2004年09月11日

エンドユーザにできるフィッシング対策

フィッシング詐欺の被害に遭わないため、エンドユーザが本来習得しておくべきWebの基礎リテラシーは、次の行動をとることである。

  • 重要な情報を入力する直前に
    • アドレスバーに表示されているURLのドメイン名が、自分が記憶している本物サイトのドメイン名に一致しているかを確認する。
    • SSLによる暗号通信がサポートされているサイトならば、ステータスバーにある錠アイコンをクリックしてサーバ証明書を表示し、本物サイトの運営者の英文組織名が書かれていることを確認する。
  • サイトを訪れる前に
    • いかなるメールであっても(本物サイトが発行するメールマガジンやニュースリリースに見えるメールであっても)そこに記載されたURLを信用せず、ジャンプしない。
    • 本物だと知っているURLをアドレスバーに手入力してアクセスし、ブックマークに登録し、それ以降はブックマークで当該サイトを訪れるようにする。
  • 普段から
    • アドレスバーや鍵アイコンの偽装ができてしまう(偽サイトなのに本物サイトの情報を偽って表示できてしまう)ブラウザの欠陥の存在が発覚することもあるので、セキュリティ脆弱性の修正プログラム(パッチ)は常に適用するようにしておく。

しかし、ドメイン名が一致しているかを目で確認するというのは、神経が疲れるし、そっくりの偽ドメインに気付かないかもしれない。サーバ証明書に記載された組織名を確認するのも、面倒だし、英文しか使えない現状では、組織名の英文正式名称を覚えていられるかという問題がある。

また、常にメールを信用しない、常にブックマークを使うというのも現実的でない場合がある。(常にトップページから入らなければならないサイトが不便であるのと同様に。)

そこで次の方法を考えた。

  1. 今見ている画面が本物だと確認できている状態で、そのドメインでのみ有効なcookieを自分のブラウザに手作業でセットする。具体的には以下のURLをアドレスバーに入力してエンターキーを押す。
    javascript:document.cookie="mycookie="+escape("本日は晴天なり")+"; path=/; expires=Thu, 1-Jan-2030 00:00:00 GMT";
    「本日は晴天なり」の部分は、パッと見で自分だけが書きそうだとわかるユニークな文章(ただし他人に知られてもかまわないもの)とする。

  2. 次回以降、そのサイトに訪れたときにそこが本物かどうか確認するには、以下のURLをアドレスバーに入力してエンターキーを押す。
    javascript:unescape(document.cookie);
    「本日は晴天なり」という文字列を含むものが画面に表示されれば、以前自分が上の1.の操作をしたサイトとドメインが一致していることを機械的に確認できる。

これらの操作を簡単にするため、2つのそれぞれのJavaScript文をブックマークに登録する(いわゆる「Bookmarklet」とする)とよい。具体的には、実行した直後にブックマークの操作をすればよい。

上記1.のスクリプトを「オレオレCookie登録」、2.のスクリプトを「Cookie表示」とし、さらに「Cookie削除」の機能([memo:4027]参照)もBookmarklet化し、リンクバーにボタンとして置いた様子を以下の図に示す。

ただしこの方法には以下の使用上の注意点がある。

  • 登録した文字列は、当該サイトのサーバに対して常に送信されることになるので、サイト管理者に知られてもかまわない文字列とする必要がある。
  • 登録した文字列がユニークであると、サイト管理者は、送信されてくるcookieを調べることで、複数のアクセスが同じ人からのものであると知ることができてしまうため、追跡されてもかまわないと信用できるサイトに対してしか使えない。
  • 「mycookie」の部分の名前は何でもよいが、サイト側が発行してくるcookieに同名のものがあると上書きされてしまうことがあるので、ぶつかり難い名前とするのがよい。
  • Netscape 7では文字化けすることがあるため、英文で登録する必要がある。
  • ブラウザにcookieが漏洩する欠陥がある場合には、登録した文字列を第三者に閲覧される可能性があり、閲覧されると、それを偽サイト上でセットされる恐れが生ずるので、セキュリティ脆弱性の修正プログラム(パッチ)は、いずれにせよ常に適用しておく必要がある。
  • サイトにクロスサイトスクリプティング脆弱性がある場合には、登録した文字列を第三者に閲覧される可能性があるため、そのような脆弱性がないだろうと信頼できるサイトに対してしか使えない。

この方法は、「cookieは本物サイトと同じドメインにしか送信されない」という原理に基づくものである。これと同じ原理に基づく仕組みをサーバ側で用意することもできるが、それは効果が薄い。その理由は次の通りである。

サーバ側で用意する場合には、キーワードをユーザに入力させる画面を設けることになる。つまり、ログインする前ないし後に、「キーワードを入力してください」という画面が現れ、入力してボタンを押すと、cookieが発行されるという仕組みとなる。

しかし、本物サイトがそのような作りになっているときには、フィッシングでユーザを騙そうとしている詐欺師は、キーワードを入力させる画面自体を偽サイトに設置するだろう。

このことは、ソニー銀行の「事前登録のパソコンでしか取引できない」という仕組みが、フィッシング詐欺対策としては効果が薄いのと同じである。それについては、昨年5月12日の日記「事前登録のパソコンでしか取引できないという対策」に以下のように書いたが、それと同じ理屈である。

これをネットカフェで実行したとき、キーロガーが仕掛けられているとどうなるか。当然ながら、最初のパスワードと、次の暗証番号と、3つの合言葉は、全部そろって盗まれる。つまり、ネットカフェでキーロガーを仕掛けられて銀行口座を乗っ取られたという事件報道の文脈において、

3種類の「合言葉」を答えないと利用できない仕組み。さらに事前登録のパソコンでしか取引できないという対策も講じている。

というのは、何ら効果のある対策ではない。

つまり、自力でcookieをセットするという今回示した対策方法が効果を持つのは、サイトの指示に従ってではなく、自発的に操作するところにミソがある。

したがって、この対策方法は、元々偽サイトに対する警戒心のあるユーザが対象であり、ドメイン名の一致確認を目視でやってもいいところを、もっと簡単にパッと見でできるようにしたという仕掛けにすぎない。

銀行の深夜営業ATMの入り口ドアにあるカード読取機に注意

  • カード情報盗み預金窃取か ATM脇に読み取り装置, 産経新聞, 2004年9月6日

    調べでは、半田市内の30代の主婦が8月上旬、このATM脇に「防犯上、ご利用のお客さまはカードをお通し下さい」と張り紙のある小さな箱状の磁気情報読み取り装置にカードを通した。同月下旬になって、別のATMから預金計約1000万円が引き出されていることが判明したが、(略)

というニュース記事を読んだ。「フィッシング詐欺のリアル版」……という言い方は変か。昔からあった手口なのかもしれない*1

そういえば、以前、早朝まで都内で飲んでいた帰りに、現金を確保しようと深夜営業のATMに入ろうとしたとき、ドアが開かず「どうなってんの?」と知人に聞いたところ、ドアにカードリーダがあるからそこにキャッシュカードを通すのだと指摘されたことがあった。

そのとき、直感的に嫌なものを感じつつ、カードを通したのだったが、今思えば、それが偽リーダだったらヤラれていたわけだ。

そんなことを思い出していたところ、UFJ銀行からこういう注意喚起の知らせが出ていた。

平成16年8月、ATMコーナーに「防犯のため、この機械にカードを通してください」と記載した貼り紙と共に「カード読取機」が、何者かによって設置されるという事件が発生いたしました。

当行では、深夜0時以降も稼動するATMコーナーに限り、カード読取機を設置しておりますが、他のATMコーナーには設置しておりません。これ以外の不審な機械には、決してキャッシュカードを通さないでください。

おいおい、じゃあ、深夜営業するATMコーナーではどうしろというのだ?

「どうやって本物だと見分けるか」を写真付きで説明するのが、ここでなすべきことだろう。どうしてこう、どいつもこいつも銀行の人たちはそういうことをサボるのか。

ようするに、「お客様の安全のために注意喚起している」のではなく、単に一定の説明責任を果たしさえすれば免責されるという発想で仕事をしている様子が透けて見えてくる。

ところで、ATMのドアがキャッシュカードがないと開かないようにする仕組み自体、効果があるのか疑問に思った。最初は、UFJ銀行のキャッシュカードでないと開かないのかと思ったが、他の都市銀行のカードで開いた。それだったら、銀行のカードを持たない人の侵入を防ぐという程度の効果しかない。

キャッシュカードは本来、ATMにしか通さない「神聖なもの」(安易に得体の知れないカードリーダに通さないもの)という常識があったが、こうしたドアの登場により、そうした感覚が崩れていってしまうのだろう。その結果、事件被害者の主婦のように、「防犯上、お通し下さい」と書かれているだけで通してしまうことが起きてくる。

あのようなドアは廃止すべきではなかろうか。

デジタルコアの合宿討論会に行ってきた

先週、日経デジタルコアの合宿討論会に行ってきた。その様子が以下にレポートされている。

この場で、ビットワレットの川合成幸社長にご挨拶し、少しお話しするお時間を頂いた。7月10日の日記の最後の段落に書いたam/pmの問題点の件を(概略だけであるが)川合社長にお伝えした。私からもam/pmに問い合わせてみるとも伝えた。

おサイフケータイのシリアル番号?

コロラド大学の木實新一さんが、ご自身のblog「Ubicomp+Shopping」の9月3日のエントリで、以下の疑問を呈されていた。

非常に基本的なことなのですが、以下の点がよくわかりません:

  • 電子マネーの端末はRFIDチップのRAMの値の読み書きだけでなくシリアル番号も読んでいるのか?
  • おサイフケータイのタグを利用者が好きなときに取り替えることができるのか?
  • おサイフケータイのタグのシリアル番号は利用者の個人情報とネットワーク上のデータベースで関連づけられているのか?

シリアル番号には複数のものがあるらしい。1つにはカード製造者が製造時に記録したもので、カードの「管理権限」があるときにしか読めないようになっていると聞いたことがある。もうひとつは、アンチコリジョンを実現するためのユニークナンバーを持つカードがあり、これは、通常のリーダライターでも読まれているはずである。ただし、読み取った番号を記録しているかどうかは不明である。

トラブル時の対応目的で記録している可能性はあるが、それをCRMにまで活用しようということは、日本の普通の企業ならば、一般的には、そのような行為は非常識であるとして行わないところがほとんどだろうと、個人的には信じている。

問題は、何らかの拍子にそうした番号をCRMに使ってよいという感覚が生じて、なし崩し的にそのようになっていくことであり、それは食い止めるべきである。また、悪意ある者(詐欺師等)が番号を読み取って悪用することが懸念される。

am/pmの件については、問い合わせて回答が得られしだい、報告する予定。

*1 「ニセ夜間金庫」(昭和49年警察白書 第4章より)なる事件は昔あったそうだが、直接現金を入れさせるのではなく、IDとパスワードを騙して入れさせるという点がフィッシングに近い。

本日のリンク元 TrackBack(0)

2004年09月12日

技術用語「cache」が政治的な言葉として拡大利用される

そもそも「cache」とは

コンピュータ用語としての「cache」は、当初はキャッシュメモリを指すものとして登場した。英単語としての「cache」の本来の意味は、辞書によれば、

cache

―n 《食料や弾薬などの》隠し場, 貯蔵所; 《隠し場の》貯蔵物; 隠してある貴重品; 【電算】 キャッシュ (cache memory).

make (a) cache of… …をたくわえる.

―vt (隠し場に)たくわえる, 隠す; 【電算】 〈データを〉キャッシュに入れる. [F (cacher to hide)]

研究社 リーダーズ英和辞典第2版

とあるように隠れた蓄え場所を指すが、キャッシュメモリはまさにそれである。

下の図のように、キャッシュはメインメモリとCPUの間に配置され、キャッシュがあることによって演算の実行速度が向上するのであるが、キャッシュがあってもなくても演算自体は同じに処理されるというところがミソである。

図1: CPUのcacheメモリ

図の上段は、CPUがメインメモリにデータを書き込む(赤の矢印)と、同時にキャッシュメモリにも同じデータを書き込むようになっており、次にCPUが同じアドレスのデータを読み出そう(緑の矢印)としたときには、キャッシュメモリから読み出しが行われる様子を表している。また下段は、CPUが同じアドレスから複数回の読み出しをする際に、1回目はメインメモリから読み出すものの、同時にそれをキャッシュメモリにも保存しておいて、2度目以降はキャッシュメモリから読み出すという様子を表している。

このような仕組みが意味を持つのは、キャッシュメモリの読み出し速度が、メインメモリに比べて高速である場合である。一般に、半導体メモリは、大容量であるほど低速となり、高速にするには高価となるため、低価格で大容量だが低速のメモリをメインメモリとして、高価で小容量だが高速なキャッシュメモリを中間に配置することに意義がある。

このとき、キャッシュメモリの存在を、プログラムからは意識する必要のないように工夫されているところが、「cache」(隠された蓄え場所)と呼ばれる所以である。キャッシュメモリの容量はメインメモリよりも小さいため、全部のデータをキャッシュメモリに入れるわけにはいかない。キャッシュは、それが満杯になったときには、古いものあるいは使用頻度の低いものを破棄して、喫緊に必要なデータに入れ替えるという動作をする。容量が小さいにも関わらず存在意義があるのは、同じアドレスに対するアクセスは連続して発生しやすいという、プログラムの一般的な性質によるところである。

次の図は、1つのメインメモリを複数のCPUで共有して使用する「共有メモリ型マルチプロセッサ」におけるキャッシュメモリの様子を表したものである。同時複数アクセスが可能なメモリは単一アクセスのものに比べて高価・小容量・低速となるため、図のように、CPUに1対1対応するよう配置するのが基本となる。

図2: 複数のCPUがメモリを共有する場合のcacheメモリ

データを読み出すだけならば、CPUが1台の場合と同様にキャッシュは動作すればよいところが、複数台の場合には、データの書き込みが発生したときに特別な措置が必要になる。図の右側は次の状況を表している。

あるメモリアドレスについて、CPU1 〜 CPU4が既に読み出し操作を行っており、データがそれぞれのキャッシュに格納されているとする。ここで、CPU1がそのアドレスに対して書き込み操作を行うと、そのデータはメインメモリには反映されるものの、CPU2 〜 CPU4 が同じアドレスにアクセスしたとき、キャッシュメモリのデータが読まれてしまうのでは、CPU1が書き込んだデータとは異なる古いデータになってしまう(データの一貫性が損なわれる)という問題が生ずる。そこで、この問題を解決するために、CPU1のキャッシュは、書込み操作が行われたとき、他のCPUのキャッシュに対して、同じアドレスに対応するデータを無効化するよう指示したり、データを直接に転送して更新させるといった動作をするよう、回路が付け加えられる。

こうした機構を備えたものを「snooping cache」などと呼び、データの一貫性を確保する課題を「cache coherency」、解決方式を「coherency protocol」などと呼ぶ。これらはここでの本題ではないが、一般に、「cache」と呼ばれる機構には、このようにデータの一貫性が求められていると言える。

Webにおけるcache

WWWが登場してまもなく、プロキシサーバが発明され、そこにはキャッシュ機構が備えられた。また、Webブラウザ自身もローカルコンピュータ上にキャッシュを持つ。

図3: Webにおけるcache

Webにおけるキャッシュの存在意義は、メモリの速度ではなく、ネットワーク的な近さにある。キャッシュ付きのプロキシサーバは、企業や大学などのネットワークの入り口に設置され、組織内のアクセスをプロキシサーバ経由とすることにより、組織から外へのネットワークアクセスの量を減らすことができる。また、Webブラウザのユーザから見れば、組織内の誰かが既にアクセスしたサイトを見に行くと、データは既に組織内のキャッシュに蓄えられているため、素早く画面をロードできるというわけである。

また、ブラウザがローカルコンピュータに持つキャッシュは、一度見た画面を再び表示するときに、再度ネットワークからダウンロードするという無駄を省くために存在している。

Webのキャッシュは、データの書き込み主体が他のユーザである可能性があるという点で、前述のマルチプロセッサの構成に近いが、マルチプロセッサの場合と異なり、書き込みに対する一貫性の確保がさほど重視されない。その理由は、まず、Webブラウザの操作主体が人である(プログラムではなく)からであり、必要があればリロード操作を行えばよいということになる。

しかし、一貫性が全く求められていないわけではない。「今見ている画面は古いのかもしれない」ということがあまりにも気掛かりとなるようでは、あらゆる画面でリロードすることになりかねず、それでは困る。

そこで、HTTPには、「If-Modified-Since」という仕組みが設けられた。これは次のような仕組みである。

あるURLへのアクセスが発生したとき、ブラウザやプロキシサーバのキャッシュが、既にそのURLのデータを蓄積している場合、その蓄積したときの更新時刻(t1)を添えたIf-Modified-Sinceフィールド付きのアクセス要求で、Webサーバにアクセスする。

Webサーバは、If-Modified-Since付きのアクセス要求を受けると、自分が持っているそのURLに対応するファイルの更新時刻(t2)と、指定された時刻(t1)を比較して、前者(t2)の方が新しい場合にだけデータを応答し、新しくないときは「304 Not Modified」応答だけを返してデータ本体は応答しない。

プロキシサーバ(やブラウザ)は、本サーバが304応答を返したときは、キャッシュのデータをブラウザに返し(画面に表示し)、そうでないときは本サーバから送られてくる新しいデータを、ブラウザに転送する(画面に表示する)とともに自身のキャッシュのデータを更新する。

この仕組みにより、ブラウザのユーザは、リロード操作を意識することなくただサイトにアクセスするだけで、常に最新のデータを閲覧できるようになった。

この仕組みが意義を持つのは、転送するデータサイズが大きく、かつ、応答に要求される早さがさほど短くはないためである。CPUのキャッシュメモリの場合は、メモリから数バイトを数ナノ秒で読み出そうというときに、更新時刻の送受信やら時刻比較をしている暇はない。Webで数十キロバイト以上のデータを数ミリ秒程度の時間で表示しようというときには、If-Modified-Sinceの処理をする余裕がある。

ただし、Webのキャッシュにおいて、常にIf-Modified-Sinceによる最新状態の確認処理が行われるとは限らない。一部のプロキシーサーバには、設定された時間内の同一URLへの再アクセスについては、If-Modified-Since付きのアクセスをすることなく、キャッシュデータをブラウザに返すという機能がある。ブラウザも、設定によっては、一定時間確認を省略したり、ブラウザを再起動するまで確認を省略する。

図4: Mozillaにおけるcache更新タイミングの設定

この機能は、ネットワークが遅かった何年か前までは価値あるものであった。キャッシュデータが新しくてサーバへのアクセスが必要でないときに、If-Modified-Sinceは、データ本体の転送を省略するとはいえ、サーバに一旦接続して応答を待つ必要はあり、これに数百ミリ秒以上かかるようでは、画面表示が遅いと感じられる。アイコン画像などは、めったに更新されないのにもかかわらず、毎回If-Modified-Sinceでサーバに確認するのは無駄であるから、省略した方がよいというわけである。

この省略が都合の悪いものとなることもある。自分でWebページをアップロードしたときは、すぐに最新データで画面表示したいはずだが、リロードしても画面が更新されない現象が起きてくる。そういう場合に備えて、「スーパーリロード」と呼ばれる機能(シフトキーやコントロールキーを押しながらリロードボタンを押す)がブラウザには用意された。また、掲示板やショッピングカードなど、リアルタイムに変化がユーザの画面に反映される必要がある場合にも、更新されないキャッシュは邪魔になる。そういうときには、サーバが「Pragma: no-cache」を応答することで、プロキシサーバやブラウザに対して、キャッシュしないよう指示することができるようになっている。

また、HTTP 1.1では、「Cache-Control」によって、サーバ側が各コンテンツに対して、キャッシュでの取り扱いについて様々な細かな指示を出せるようになった。

著作権とcache

1990年代末に、Webのキャッシュが著作権上の問題を含むか否かという議論が活発になった時期があった。キャッシュに蓄積されるデータが著作物の複製にあたるとなると、無断複製ということになり、誰かが違法性を問われかねないという議論である。

これについては、以下の文献を参照するのがよいと耳にしたがまだ入手できていない。

  • 塩澤一洋, 「一時的蓄積」 における複製行為の存在と復製物の生成, 法学政治学論究, 1999年11月号, pp.213-?.

「一時的蓄積」について、Webで閲覧できる範囲で調べてみると、2000年5月の東京地裁判決に次の記述があった。

三 争点4(受信チューナーにおける複製権侵害の成否)

1 RAMへのデータ等の蓄積が著作権法上の「複製」に当たるか否かについて

(一)(略)このように、RAMにおけるデータ等の蓄積は、一般に、コンピュータ上での処理作業のためその間に限って行われるものであり、また、RAMにおけるデータ等の保持には通電状態にあることが必要とされ、コンピュータの電源が切れるとRAM内のデータはすべて失われることになる。右のような意味において、RAMにおけるデータ等の蓄積は、一時的・過渡的なものということができ、通電状態になくてもデータ等が失われることのない磁気ディスクやCD-ROMへの格納とは異なった特徴を有するものといえる。(略)

(二)(略)すなわち、著作権法は、著作物の有形的な再製行為については、たとえそれがコピーを一部作成するのみで公の利用を予定しないものであっても、原則として著作者の排他的権利を侵害するものとしているのであり、前記のような著作物の無形的な利用行為の場合にはみられない広範な権利を著作者に認めていることになるが、これは、いったん著作物の有形的な再製物が作成されると、それが将来反復して使用される可能性が生じることになるから、右再製自体が公のものでなくとも、右のように反復して使用される可能性のある再製物の作成自体に対して、予防的に著作者の権利を及ぼすことが相当であるとの判断に基づくものと解される。

そして、右のような複製権に関する著作権法の規定の趣旨からすれば、著作権法上の「複製」、すなわち「有形的な再製」に当たるというためには、将来反復して使用される可能性のある形態の再製物を作成するものであることが必要であると解すべきところ、RAMにおけるデータ等の蓄積は、前記(一)記載のとおり一時的・過渡的な性質を有するものであるから、RAM上の蓄積物が将来反復して使用される可能性のある形態の再製物といえないことは、社会通念に照らし明らかというべきであり、したがって、RAMにおけるデータ等の蓄積は、著作権法上の「複製」には当たらないものといえる。

H12.5.16 東京地裁 平成10(ワ)17018 著作権 民事訴訟事件 判決

これは、デジタル放送の再生装置において、装置のシステム構成上の都合として、音楽のデジタルデータが、一時的に揮発性メモリに格納されることについて、それが著作物の複製にあたるかが争われたケースである。

では、キャッシュはどうだろうか。キャッシュは、2度目以降の読み出しを高速化することに目的があるのだから、「将来反復して使用される」ことを意図したものと言えるので、上の裁判例が対象としたものとは異なる。

また、2000年11月に公表された著作権審議会国際小委員会報告書に次の記述があった。

(3)「一時的蓄積」の取り扱いの検討

○ デジタル化、ネットワーク化の進展に伴い、通信機器における蓄積、コンピュータのメモリー上における蓄積、キャッシュサーバーなどにおける蓄積など瞬間的かつ過渡的なものを含め、プログラムの著作物及びその他の著作物に関する電子データの「一時的蓄積」の扱いが重要課題となっている。

○ 「一時的蓄積」に関して、我が国では1995年(平成7年)2月の著作権審議会マルチメディア小委員会ワーキング・グループ検討経過報告書においては、「一時的蓄積」のうち「プログラムの実行に伴うコンピュータの内部記憶装置への蓄積は、瞬間的かつ過渡的なものであって、『複製』には該当しないとの解釈が一般的である(著作権審議会第2(1973年(昭和48年)6月)・第6(1984年(昭和59年)1月)小委員会報告書)」としている。また、1985年(昭和60年)9月の著作権審議会第7小委員会報告書においては、データベースの場合、「内部記憶装置と外部記憶装置を区別せず、インプットした情報を直ちに処理して消去する場合は別として、コンピュータの記憶装置への蓄積は複製に該当すると考えられる」としている。

○ 他方、1996年(平成8年)12月のWIPO外交会議において採択された「WIPO著作権条約に関する合意声明」においては、「保護を受ける著作物をデジタル形式により電子的媒体に蓄積することは、ベルヌ条約第9条が意味する複製に当たると解するものとする。」としつつ、WIPO事務局より、瞬間的・技術的な蓄積についての議論の際に、「蓄積」については各国に異なる解釈の可能性がある旨指摘されている。

○ 「一時的蓄積」に関しては、各国間で、権利の対象外とする範囲について様々な考え方があり、技術的背景の変化及び国際的な議論の動向を踏まえつつ、その扱いについても検討する必要があると考えられる。

<施策の進め方>

○ プログラムの著作物及びその他の著作物に関する電子データの「一時的蓄積」の扱いについて、著作権審議会などにおいて検討する。

著作権審議会国際小委員会報告書 〜情報技術(IT)、電子商取引の進展に対応した国際著作権政策の在り方〜, 2000年11月

「キャッシュサーバーなどにおける蓄積など」という語句の直後に、「瞬間的かつ過渡的なもの」という表現が出てきているが、キャッシュは瞬間的とは言えないので、これには違和感がある。

このままの法律ではおそらく、Webのキャッシュは著作物の複製にあたるということになってしまうと思うが、技術者の心情からすれば、キャッシュの仕組みが著作権法によって規制されることには、直感的に強い抵抗を感じるのが一般的であろう。

それを避けるために、技術面からなしておくべきことは、キャッシュという用語が指す技術的特性の範囲を明確化することである。

蓄積機構がcacheと呼べる条件

最初に整理したように、CPUがメインメモリにアクセスするときのキャッシュメモリにせよ、Webにおけるキャッシュにせよ、データの一貫性管理が要求されているという特徴がある。それはすなわち、キャッシュがあってもなくてもシステムは同等に動作するということが要件となっていることを意味する。つまり、アクセス元からアクセス先を見るとき、キャッシュが透過的であることが要件である。cacheという単語の本来の意味が「隠れた蓄え場所」であることに附合する。

キャッシュの最も狭い定義を、次の機能を備えていなくてはならないとすることができる。

(1) キャッシュへのアクセスがあったら、オリジナルのデータが更新されているときは、キャッシュ上のデータも更新したうえで、データを応答する。

この条件を少しだけ緩めた次に狭い定義を、以下のようにすることができる。

(2) キャッシュへのアクセスが、一定の時間内あるいは条件を満たすタイミングであった場合は、そのままキャッシュ内のデータを応答し、それ以外の場合では、オリジナルのデータが更新されているときは、キャッシュ上のデータも更新したうえで、データを応答する。なお、一定の時間は十分に短い(たとえばWebキャッシュの場合10分など)必要があるし、条件を満たすタイミングはシステムの用途に応じて妥当でなくてはならない。

オリジナルのデータの更新状況は、If-Modified-Sinceのような方法で随時確認する方法や、マルチプロセッサにおけるsnooping cacheのように、データを更新した側からの指示によって他を更新もしくは無効化することで、常に更新が保証されるようにしておく方法がある。

「一定の時間内あるいは条件を満たすタイミング」とは、Webのキャッシュのように、一定時間オリジナルデータの更新を確認しない方式における一定時間や、共有メモリ型マルチプロセッサ向けのキャッシュや分散共有メモリなどでの、同期機構と連携した一貫性プロトコルにおける、同期のタイミングなどが該当する。

オリジナルデータが消滅することのあるシステム(Webなどが該当)では、オリジナルデータが消滅すれば、キャッシュデータも消滅するようにすることが、一貫性制御がなされていると言える要件となろう。

著作権の観点から見たとき、このような特性を備えたキャッシュの存在に、どのような問題が生ずるだろうか。

(1)の定義のキャッシュであれば、ユーザから見える著作物は、オリジナルと常に同じように見えるのであるから、実質上の問題が生じないと言える。

(2)の定義のキャッシュの場合は、オリジナルデータが更新されても、いくらかの時間が経過しないと更新が反映されないという不都合が生ずる。これはたいした問題とならないことも多いが、問題をもたらすこともある。

たとえば、ユーザ認証を経て特定のユーザにだけ閲覧させたはずのデータが、キャッシュに残っていたために、後に別のユーザが同じキャッシュ経由でアクセスしたときにも、データを閲覧させる結果になってしまった場合が該当する。

しかしこれは、HTTPの Cache-Control ないし Pragma: no-cache 機能を使うことで、コンテンツ作成者側が防ぐことができる。

1990年代からの議論を経て、現在では、(HTTPの仕様を無視して動作するキャッシュシステムを除けば)Webのキャッシュは著作権上妥当なものとしてほとんどの人がとらえていると考えられる。

Googleが「cache」と自称するもの

それに対し、Googleなどが始めて、後にYahooやgooなども採用するようになった、Web検索サイトにおける「キャッシュ」サービスはどうだろうか。

まず、アクセス元(ユーザ)側から見て、この「キャッシュ」は透過的でない。その存在は目に見えて意識的に使われるものであって、「隠れた蓄え場所」には全くなっていない。

システムアーキテクチャから見ても、伝統的なキャッシュとは異なり、アクセス元からの要求が来る前から、検索サイトが自らオリジナルデータを収集して「キャッシュ」に蓄えている。必要に応じてではなく、全部を蓄えようとしている。

図5: Googleが「cache」と自称するもの

上に整理した(2)のキャッシュの定義からすれば、「一定時間」が一週間を超える場合もあるような長期間となっていて、キャッシュと呼べるには限度を超えていると見ることもできる。

Googleは、この機能の存在意義を次のように説明している。

キャッシュ

このリンクをクリックすると、インデックス付けの時点で保存されたページのコンテンツが表示されます。Googleでは該当ページのサーバがダウンした場合でも、検索が行えるよう多数のウェブページをキャッシュに格納しています。キャッシュ済みバージョンでもキーワードがハイライトされます。

Googleの検索結果の見方

なるほど、該当ページのサーバが一時的にダウンしていても閲覧できるようにというのは、便利だ。だが、目的は本当にそれだけなのだろうか。

Googleの「キャッシュ」と称すものは、伝統的な本来のキャッシュシステムにより近づけることはできるはずである。具体的には次のようにすることが考えられる。

ユーザが「キャッシュ」のリンクをクリックしたとき、Googleから当該URLのオリジナルサイトへデータの更新状況の確認アクセスを行い、更新されているならば、更新されたデータをブラウザに応答するようにする。

「そんなことを実現するにはコストがかかりすぎる」という声が聞こえてきそうだが、はたしてどうだろうか。現在の「キャッシュ」の更新が一週間以上かかることもあるのは、世界中のすべてのWebサイトを網羅的に巡回して更新しているためである。これをたとえば1時間以内にすべてについて行うのは不可能であろう。だが、それは、閲覧されていないキャッシュも含めて更新しようとするからだ。

ユーザが「キャッシュ」リンクをクリックしたときにだけ更新確認する仕組みで発生する更新確認アクセスの数は、ロボットが全世界を巡回するときのアクセス数よりずっと小さくできるはずである。「キャッシュ」へのアクセス数が、Google全体のアクセス数の何割かということもあるが、すべてのアクセスで更新確認をする必要もない。たとえば、一人目が「キャッシュ」にアクセスに来た時点で更新確認をし、それから10分間は同じURLの「キャッシュ」にアクセスが来ても更新確認をしないという動作をするのは、十分に妥当かつ効果的だと考えられる。

また、一人がたまたま「キャッシュ」を閲覧しただけでは更新確認しないという方法も考えられる。たとえば10人ほどが短時間に連続して異なるIPアドレスからアクセスしてきたら、そのページのキャッシュが何らかの原因で注目を浴びている(たいていは良からぬことが起きている)と判断して、更新確認するようにするといった具合だ。

こうした、伝統的なキャッシュとして振舞うための方策は考えられるが、採用されていない理由は、自分のコンテンツを早く更新させるために、意図的にキャッシュへのアクセスを発生させる輩が現れた場合に、それが多くのサイトについて常態化してしまうと、その処理のコストが無視できなくなるほど大きくなりかねないということがあるためなのかもしれない。

それに対する対策は何か考えられるかもしれないが、そこまでのコストをかけてまで、伝統的なキャッシュの動作に近づける必然性があるとまでは認識されていないのだろう。

こうした「キャッシュ」の仕組みは、やはりこれまでにも何度か著作権上の問題があるとして物議を醸してきている。

また、これは著作権上の問題だけではなく、プライバシー漏洩事故発生時の被害拡大をもたらすという面も持ち合わせている。

Googleに「キャッシュ」されることを避けるには、HTMLコンテンツに METAタグで次のように書けばよいと、Googleは説明している。

サイトのコンテンツをロボットがアーカイブしないようにするには、以下の NOARCHIVE メタ タグを使用します。 このタブをドキュメントの セクションに次のように挿入します。

<META NAME="ROBOTS" CONTENT="NOARCHIVE">

Google, ページの削除, キャッシュページを削除する

これには不満の声も出ている。コンテンツ提供者が自らのコンテンツのキャッシュ方法を指示するというのは、先に述べた HTTP/1.1の「Cache-Control」にも共通しているが、両者はやや性質が異なっている。

Cache-Controlを必要とするような状況は、技術力をもってサイト構築が行われている場合(ログインユーザごとに異なるコンテンツを見せる場合など)がほとんどであるように思える。静的なコンテンツを提供している場合には、透過的なキャッシュが大きな問題を起こすことは少ないと言える。そのため、「キャッシュされるのが困るならばCache-Controlで制御せよ」という言い分はある程度通るのであるが、それに対し、Googleに「キャッシュ」されて困るのは、そのような技術力を持たない一般の人たちであることが多い。なぜなら、Googleの「キャッシュ」は透過的でないため、静的なコンテンツでも小さくない問題が十分に生じ得るからだ。

Googleは、緊急時には次の方法で「キャッシュ」を削除できると説明している。

注意: 緊急を要し、Google が次回サイトをクロールするまで待てない場合は、自動 URL 削除システムをご使用ください。このプロセスが機能するためには、Web マスターがまず適切なメタ タグをページの HTML コードに挿入する必要があります。

Google, ページの削除, キャッシュページを削除する

これはようするに、コンテンツの提供者自身がまず METAタグをコンテンツに挿入して、「キャッシュ」して欲しくないことの意思表示をした後に、Googleに対して申請を行うと、METAタグが確認されて「キャッシュ」が消去されるという仕組みだ。

ここで疑問に思うのは、どうして削除しかしてくれないのかということだ。つまり、申請すると、METAタグとは関係なしに、最新の内容にアップデートしてくれるというだけでも、トラブルは解決するはずである。「キャッシュ」とは本来そのように動作するもののはずだ。Webのキャッシュで言う、スーパーリロードのようなことができるべきである。それが行われていないのは、やはり、不当に申請を乱発する輩が現れることを避けるためなのだろうか。

このようなことを書いたが、これは、私自身が、Googleの「キャッシュ」は廃止するべきであるとか、著作権法違反であると主張したいわけではない。Googleの「キャッシュ」や、archive.orgのアーカイブを便利に使うこともある。

ここで言いたいのは、キャッシュでないものをあえて「キャッシュ」と呼ぶことのインチキ臭さ、不誠実さだ。Google自身が、

サイトのコンテンツをロボットがアーカイブしないようにするには、以下の NOARCHIVE メタ タグを使用します。

Google, ページの削除, キャッシュページを削除する

と言っているように、これはキャッシュではなく、アーカイブである。一時的なアーカイブであろう。

キャッシュでないものを「キャッシュ」と呼ぶ意図は、著作権法違反と指摘される可能性を意識してのものではないか。

つまり、狭い定義の「キャッシュ」であれば、たとえ法的にその位置づけが明確になっていないにせよ、多くの人達が妥当だと考えているのに便乗して、狭い定義の「キャッシュ」を逸脱した仕組みまで「キャッシュ」と自称することによって、素人の目を混乱させて、同様に妥当であるかのように見せかけている。

もしGoogleの「キャッシュ」が著作権法上問題だと問われる事態になれば、「これが違法だというのなら、プロキシサーバや、Webブラウザのキャッシュまで違法ということになってしまう」という馬鹿な詭弁が出てくるに違いない。

妥当な利用まで規制されかねないような、紛らわしい用語の使い方は迷惑である。少なくとも技術者がすることではない。

Winnyの「cache」

そしてWinnyの「キャッシュ」である。

Winnyにおいて、無断で公衆送信可能化すると著作権侵害になるコンテンツが大量に流通しているにもかかわらず、逮捕者が多数は出ない原因は、データを送信可能化しているといっても、それが「中継」であるのか、Upフォルダでの一次配布元であるかの区別が、外部からは判別できないようになっているところにある。

そして、「中継」する行為が違法でないとする立場からは、「もしWinnyの中継が違法ということになったら、ISPのルータのパケット中継も違法ということになってしまうじゃないか」という主張が出てくる。

ISPのルータでは、データは通過するだけである。瞬間的にメモリ上に蓄えられることになるだろうが、これはまさに法的にも通説となっている「一時的蓄積」に該当するであろう。

それに対しWinnyの場合では、多くのケースで、実際の中継は行われず、「キャッシュ」からデータが出ていく形になる。

ファイルを要求したノードA が直接に接続したノードB が中継をしていたとしても、その中継先のノードC がさらに中継している確率は小さく(ゼロに?)設定されており、それがUpフォルダでの一次提供元でないのなら、ノードCは「キャッシュ」からデータを送信していることになる。

図6: Winnyの場合の「cache」

あるファイルがUpフォルダに入れられている間は、一次提供元をrootとしたツリー構成が成立すると見ることもでき、その時点では「キャッシュ」が本来の意味でのキャッシュの構成になっていると言えなくもない。しかし、Upフォルダのデータはすぐに消されることを元から想定しているうえ、Winnyの「キャッシュ」にはデータの更新という機能がない(更新されたデータは別のファイルとして扱われる)。

  • Winnyの「キャッシュ」は、「あってもなくても同等に動作する」という性質を備えていない
  • Winnyの「キャッシュ」には、一貫性制御が存在しない

ここでも技術用語「cache」が政治的に拡大解釈使用されている様子が見られる。

本日のリンク元 TrackBacks(28)

2004年09月17日

セキュリティに関わる解説を素人に書かせる銀行たち

三井住友銀行が先月から、「電子メールお知らせサービス」なるものを始めていた。

  • 三井住友銀行、口座の入出金をメールで知らせるサービスを提供開始, INTERNET Watch, 2004年7月9日

    三井住友銀行は9日、同行のダイレクトバンキングサービス「One'sダイレクト」利用者向けに、「電子メールお知らせサービス」を8月23日より提供開始すると発表した。利用料金は、月額105円。

    電子メールお知らせサービスは、One'sダイレクト契約者に対して、振込の入金や口座の引き落としをメールで知らせるサービス。(略) 同行によると、公共料金やクレジットカードなどの口座引落しを事前に知らせるサービスは、邦銀初の試みだという。

フィッシング詐欺に注意が呼びかけられている真っ只中のこのご時世に、そんな紛らわしいサービスを始めるとは、いやはや、どういう神経をしているのだろうか。

一般に「初の試み」などというものは、アイデアが斬新というわけでなしに、単に「やってはいけないことだから誰もそれまでやっていなかった」というオチである可能性がある。

三井住友銀行のこのサービスの解説ページに、どんなメールで通知が来るのか、「電子メールのサンプル」が掲示されている。こんな感じだ。

どうだろうかこの文面。フィッシングの詐欺メールと区別できるだろうか。

あるいは、口座引落し予告のメールの方はどうだろうか。

知らないところから引き落とすと書かれていたら、どうだろうか。慌ててログインしようとして、偽メール、偽サイトでないかの確認をうっかり怠ってしまいやしないだろうか。

銀行がメールを送ってくるというのは、これまで、自分が操作したタイミングでという場合がほとんどだった*1。少なくとも三井住友銀行では、メールで何かが送られてくることはなかった。だから、三井住友銀行を名乗り、ログインを促すメールがきたら、「あれ?」と思うことができた。これまでは。

こういう通知サービスが常態化していくと、人々はフィッシング詐欺に騙されやすくなっていくだろう。

そもそも、電子メールなどという信用性ゼロのメディアを使って、こういう連絡をしてはいけない。こういうサービスが必要なら、これまでに書いたように、メールに電子署名をするべきである。

三井住友銀行の説明には電子署名の解説はないので、署名なしなのだろう。それどころか、メールのサンプルの説明には、どのメールアドレスから送られてくるかの説明すらない。素人が書いているのか。

ちなみに、みずほ銀行では、きちんとこういう説明がなされている。

「みずほ銀行」の名前をかたり、「口座パスワード確認」という件名でインターネットバンキングのパスワードを知らせる内容の迷惑メールが送信されている事実を確認しております。 (略)

当行においては、フィッシング詐欺の事実は確認されておりませんが、当行のホームページURLや、当行からお送りする電子メールの主な送信元アドレス(差出人、From)は以下のとおりです。(略)

当行の主なホームページURL・電子メール送信元アドレスはこちら

「みずほ銀行」の名 前をかたった迷惑メール・詐欺メールについて, みずほ銀行, 2004年9月7日

さすが、既に事件が起きたところは説明をしている。

三井住友銀行の「電子メールお知らせサービス」の「よくある質問」ページには、「Q12:電子メールお知らせサービスを利用する上で注意しなければならないことはありますか?」という項目があるが、次のことが書かれているだけで、フィッシング詐欺への注意は書かれていない。

A12: 以下の注意点をご理解いただいた上でご利用ください。

  • インターネット等の通信手段の特性により、電子メールに遅延が発生した場合、また、インターネット経路上で消失・二重送信が(略)
  • 口座引落しの事前お知らせにおいて、引落日当日、残高不足・預金取引停止等の理由により引落しができなかった場合(略)
  • 振込入金のお知らせにおいて、振込依頼人から振込の「取消」「変更」「組戻し」があった場合(略)

Q12:電子メールお知らせサービスを利用する上で注意しなければならないことはありますか?, 三井住友銀行

かと思えば、その一方で、インターネットバンキング全体のQ & Aの方に、次の注意書きがある。おそらく別々の人によって書かれたのだろう。

ところが、ここには間違ったことが書かれている。

A4: One'sダイレクトのログイン画面で、ブラウザのアドレスバーに表示されているURLのサーバ名をご確認ください。

One'sダイレクトのサーバ名(赤文字部分)は以下の3通りあります。

(略)

(1)ブラウザのアドレスバーで直接確認する。

ここまではよい。その次はこうなっている。

(2)サーバの証明書で確認する。

それはサーバ証明書ではない。クリックせよという「トラストマーク」はログイン画面にあるが、このマークは、単に以下のURLへのリンクになっているだけだ。どこからでもリンクできる。

https://digitalid.verisign.com/vsj/7a8b412e80baafb4cf2d10988a2da06e

マークのクリック先に書かれたサーバ名と、ログイン画面のアドレスバーのサーバ名が一致しているだけでは、本物の証明にはならない。サーバ名が「上記サーバ名」と一致することを(記憶を頼りに)確認するのであれば、アドレスバーだけ見ればよいのだから、マークをクリックする意味がない。マークをクリックする意味があるとしたら、発行先の組織名を見ることだが、それならば、ブラウザの錠アイコンをクリックして確認するべきである。このマークは単なる飾りだ*2。しかも、マークをクリックした先のアドレスバーが「https://digitalid.verisign.com/……」になっていることも確認しないと意味がない。詐欺師が同じ画面を作ることだってできるからだ。

こんないいかげんな解説では、マークをクリックして見さえすれば本物と信じてよいと勘違いする消費者が続出するだろう。

ちなみに、新生銀行は次のように説明している。

  • 安全なお取引のために, 新生銀行

    4.当行ウェブサイトの安全性の確認方法

    個人情報などのご入力の際、以下の方法で当行ウェブサイトの安全性をご確認いただけます。

    • 当該ページのURLが「https://・・・」となっていることをご確認ください。
      (通常、暗号化通信が適用されたページの場合、URLがhttpsから始まります。)
    • 当該ページの下にベリサインの鍵マークがあることをご確認ください。この鍵マークをダブルクリックすることにより、ベリサインの証明書をご確認いただくことができます。この証明書は、このウェブサイトの運営主体である当行の実在性を証明し、ウェブサーバーとブラウザー間の通信がSSL暗号化通信によって保護されていることを証明します。 (略)
    • URLをご確認いただき、当行の公式ホームページであることをご確認ください。
      当行のURLは以下の通りです。

「ベリサインの鍵マーク」って何だ?

もっとわけがわからないのは、

URLが「https://・・・」となっていることをご確認ください

というが、新生銀行のログイン画面はアドレスバーを消しているんだけど。

これのどこを確認するんだ? 解説を書いた人は自分でやってみたんか? やってみればおかしいと気付くだろうに。

本業の人にチェックさせるくらいのことができないのだろうか。

*1 イーバンクについては現在問い合わせ中。

*2 証明書の取り消しがなされていないかをリアルタイムに確認できるという意義だけはあるが。

本日のリンク元 TrackBack(1)

2004年09月19日

メールのFrom:には複数のアドレスを書けるがS/MIME署名は?

メール本体のヘッダにある「From:」フィールド(Outlook Express日本語版では「送信者」として表示される)には複数のアドレスを記述できる。この仕様のことはあまり知られていないかもしれない。(なしにろ、そもそもFrom:が自由記述する場所だと知らない人も少なくないくらいなのだから。)

From:に複数のアドレスを書くのがどういうときかというと、たとえば、結婚する2人が連名で披露宴の案内メールを出す場合など*1だ。新郎と新婦のメールアドレスをコンマで区切って並べて書く。そして、実際に送信を行う者のアドレスをSender:に書く(ここには1つのアドレスしか書けない仕様になっている)。

From: "新婦の名前" <shinpu@example.com>, "新郎の名前" <shinro@example.jp>
Sender: "新郎の名前" <shinro@example.jp>

さて、この場合に、S/MIME署名をするとどうなるか。

新郎が新郎のコンピュータ上で電子署名しようとしたとき、新郎の秘密鍵入り証明書がコンピュータ上に登録されていれば、shinro@example.jp を署名者アドレスとして署名することになる。これを送信して、Outlook Expressで受信するとどうなるか。

結果は、以下のようになった*2

From:のアドレスを逆順にして

From: "新郎の名前" <shinro@example.jp>, "新婦の名前" <shinpu@example.com>

として、新郎 shinro@example.jp で署名すると、正常な署名として扱われた。どうやら、複数のメールアドレスがFrom:にある場合は、先頭のアドレスを「送信者」として扱い、署名者と比較しているようだ。

この挙動は、はたして仕様なのだろうか?

署名者と送信者の一致確認について、RFC 2632 - S/MIME Version 3 Certificate Handlingは、次のように規定している。

3. Using Distinguished Names for Internet Mail

(略)

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

RFC 2632 - S/MIME Version 3 Certificate Handling

MUAは、ヘッダのFromかSenderのアドレスと、署名者証明書のアドレスが一致することをチェックしなければならないとされているが、Fromが複数ある可能性については書かれていない*3

では、ひとつのメールに複数の署名者で署名する(新郎と新婦で署名する)ことはできるのだろうか。まだ調べていないのでわからない。

ところで、8月29日の日記では、

Becky! 2.11.02 に付属の「Becky! S/MIMEプラグイン Ver.1.01」では、以下の図のように、「正当性が検証されました」と表示されるだけで、From: のアドレスとの一致検査は行っていないようだ。ユーザが自力で目視確認する必要がある。これは改善の余地があると言える。

と書いたが、RFCによれば一致検査はMUSTだとされているのだった。

また、RFC 2632を置き換えるRFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handlingが今年の7月に出ており、一致検査の部分は少し詳細な記述になっている。

3. Using Distinguished Names for Internet Mail

(略)

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification. RFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling

「Sender ID」はphishing詐欺防止に効果をもたらすか

From:に複数のアドレスが書けるという話は、最近話題になっている「Sender ID」にも関係してくるはずだと思い、Sender IDについて勉強してみた。

これらの記事のように、当初はspam対策だとされてきたSender IDが、最近ではフィッシング詐欺対策だと宣伝されている。

Sender IDとはようするに簡単に言うと次のようなものらしい。

  • メール本体のヘッダの発信者等アドレス、すなわち「From:」または「Sender:」もしくは、「Resent-From:」ないし「Resent-Sender:」のアドレスを確実なものにする。

「確実なものにする」というのは、送信元を偽った送信でないかを、DNSを使って調べるようにし、偽っている場合には受信を拒否できるようにするというものだ。

Sender ID対応のMTAは、メールを受信するとき、送信元のMTAが送ってくる「MAIL FROM:」コマンドのアドレス(エンベロープのFROMアドレス)のドメイン名から、DNSを検索して、そこに登録されているドメインのMTAから接続されているかどうかを検査する。一致しなければ、偽りのメールであると判断(本物以外のサイトから発信されたメールであると判断)して受信を拒否する。

この仕組みが機能するためには、人々が次のように行動する必要がある。

-ドメイン名を保有する組織のDNS管理者は、自分の組織のものとして使うメールアドレスの発信元MTA(SMTPサーバ)のIPアドレスを列挙して、DNSに登録する。 -メール発信者は、自分の組織がSender IDに対応している場合(DNSに上の登録をしている場合)、指定されている(登録されている)SMTPサーバ以外からのメール送信をしないようにする。(そうしないとSender ID対応の受信MTAに拒否されてしまう。)

後者の点は、メール送信者の行動に次の制約をもたらすことになる。たとえば、これまでならば、会社のメールアドレスをFrom:とするメールを、ISPのSMTPサーバに接続して送信することもできたが、会社のDNS管理者がそのISPのSMTPサーバをDNSに登録していない限り、それができなくなる。

そこで、Sender IDでは、SMTPを拡張して「MAIL FROM」コマンドの後ろに「SUBMITTER」パラメータを追加できるようにする。会社のアドレス(example.co.jp)をFrom:として、ISP(example.net)のアカウント(POP before SMTPとかで)から送信する場合、ISPのMTAは、以下のコマンドで送信するようにするらしい。

MAIL FROM: <takagi@example.co.jp> SUBMITTER=takagi@example.net

(少し話がわき道にそれるが)このままだと、せっかく会社のFrom:アドレスで送信しているのに、ISPのアカウントのメールアドレスを送信先に知らせることになってしまうので、こんな仕組みに従うのは嫌だと思われるかもしれない。そこで、ISPなどがゲストサービスとしてこれを提供するということが想定されているようだ。つまり、

MAIL FROM: <takagi@example.co.jp> SUBMITTER=guest@mail.example.net

のようにSUBMITTERを指定するよう、ISPのMTAが振舞うことで、その問題を解決できるということのようだ。(以下、本題に戻す)

このとき受信者側のMTAは、SUMITTERアドレスのドメインがexample.netなので、それでDNSを検索し、そこに登録されているIPアドレスのSMTPサーバからの接続なのかを調べるというわけだ。

ということは、From:を偽ってどこからでも送信できてしまうということになる。これでは何の対策にもならないように思えるが、ここで、MTAがメール本体のヘッダに、Sender:やResent-From:を強制的に追加するところがミソのようだ。

受け取ったメールのヘッダに、Resent-From:ないしSender:があれば、それは(Sender ID対応の)MTAによって本物であることが確認されていることになる。

これがspam対策になるとされてきた理由は、Sender:やResent-From:などのアドレスを、spamフィルタのフィルタリング条件判断の入力とすることによって、より効果的なフィルタリングができるということらしい。その程度の効果しかないというわけだが、おそらく、Hotmailなどように大規模にメールユーザを抱えていて、膨大なspamの攻撃に遭っているところにとっては、大きな意義があるのだろう。

一般の組織にとってのspam対策効果は、現時点でははっきりしない。正規のメールまでspamとして扱ってしまう可能性も残るspamフィルタを、会社として導入するというのは難しい面もあるだろう。Hotmailのようなサービスでは、spamフィルタリングするという方針のもとでユーザを募ればよいのだし、Webメールでは、フィルタしたものを直接ユーザに見せるインターフェイスを提供できるのでうまくいくという面があるし、なによりも、spam攻撃の標的になっているために便益がに大きい。今後、企業がMTAで導入できる確かなspamフィルタソフトが普及してくれば、一般の組織にとっても意義が出てくるかもしれないというものだろう。

なので、Microsoft等が「Sender IDでspam対策を!」と主張しても、「なんでおまえらのために俺達が対応しないといけないんだ」という反応になってしまう。そこで、最近はフィッシング詐欺対策なのだという説明方法に転向してきているのだと思われる。

日経IT Proの記事にはこう書かれていた。

同氏によると,インターネットを使ってBtoCのサービスを提供している企業の多くは,フィッシングに名前を使われることを心配しているという。「フィッシングを企む偽メールの送信者に名前を使われると,エンドユーザーにはその企業がフィッシングに加担していると思われる可能性がある。企業はそのことを心配している。信用問題にかかわるからだ」(同氏)

名前を使われることを防ぐ方法の一つが,Sender IDなどの送信者認証を利用すること。もちろん,名前をかたられることを心配する企業側だけでなく,メールの受信者側でも対応しなければ,送信者が偽装されているかどうかは検証できない。しかし,企業側では,ある程度の説明責任を果たすことができる。

「送信者認証は“スパム対策”ではなくて“フィッシング対策”」――マイクロソフト, 日経IT Pro, 2004年9月6日

「偽メールの送信者に名前を使われる」のを防ぐといっても、SUBMITTERがキモであるので、From:アドレスを偽られることは防止できない。

「メールの受信者側でも対応しなければ」とあるのは、ようするに、From:を見てもだめで、Sender:ないしResent-From:などをユーザが目視確認するようにならないと、意味がないということなのだと思われる。

現在のMUAのほとんどは、メールの送信者としてFrom:だけを表示しているだろう。Sender:やResent-From:も同時に表示するようにして、皆がそれを意識して見るようにならないと、フィッシング対策にはならない。

この点について、Sender ID提唱者のInternet Draftは、次のように述べている。

7.5 MUA Implementers

When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address. When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender and a From, an MUA should consider displaying all of them.

J. Lyon and M. Wong, Sender ID: Authenticating E-Mail, Draft Specification, Internet Draft: draft-ietf-marid-core-03.txt, 2004年8月

これはフィッシング詐欺対策としてどの程度の効果があるだろうか。たしかに、これまででも、到着したメールが(From:が本物アドレスでも)本物かどうか疑わしいときは、ヘッダを表示させて、Received:フィールドをジロジロ見て調べるのが基本だった。ただ、そのようなことができるのは一部の詳しい人だけであり、普通の人にはできないことだった。これが、Sender IDの導入により、やりやすくなるということだと言える。

これまでは、Received:フィールドのSMTPサーバのIPアドレスから判断していたのが、(Sender ID対応サイトからの発信であれば)Sender:やResent-From:などに書かれた、メールアドレスから判断できるようになる。

しかし、全部のサイトがSender ID対応になるわけではないので、From:やSender:が書かれているからといって、それが確認されたものであるとの確証は得られない。

この点に対しては、Sender IDで確認済みとのことを示すフラグをMTAがヘッダに挿入して、その情報をMUAが表示するようにする必要があるだろう。もしそうしないのであれば、ユーザは、今見ているメールの送信者になっている会社がSender ID対応の会社であることを覚えていなくてはならない。

この仕組みはようするに、From:が自由記述の部分である(From:は送信者ではなく著者である)というインターネットメールの特性を残しつつ、それとは別に送信者アドレスをきちんと意識して使おう――ということなのだと思う。それはとても正論だと思う。

15年前のMUAユーザは、メールのヘッダを全部見ていた。ところが、ヘッダに余計なものがいっぱい挿入されるようになるにつれ、一部だけしか表示しないのが普通になっていった。それでも、10年前、EmacsのMUAでメールを読んでいたころの私は、Sender:は表示する設定にしていたと記憶している。

ところが、GUIのMUAが普及すると、From:しか表示しないのが普通になってしまった。それどころか、MicrosoftのOutlook Expressなんかは、メールアドレス本体さえ表示しないで、氏名(メールアドレスのコメント欄)だけを表示する。

さらには、日本語版Outlook Expressにいたっては、英語版では「From」と表示されている部分が「送信者」と翻訳されてしまっている*4。Sender ID Frameworkの根底の考え方にあるように、本来、インターネットメールにおいては、From:とSender:の違いがキモであるにも関わらず、日本語版Outlook Expressは、両者を区別しないパープリン翻訳従事者によって作られている。

こういうおバカ仕様のMUAを普及させたことを反省して、本来の姿に戻ろうというのが、この「Sender ID Framework」の本質なのだと言える。

さて、信頼ある企業のとるべきフィッシング詐欺対策という観点で見ると、長期的にはたしかにSender ID Frameworkは有効であるし、本来の姿なのだろうけれども、中途半端にしか普及しそうにないものが普及するのを待つまでもなく、今すぐ電子署名すればよいのであるし、元々そうするべきである。

*1 単に複数アドレスに返事をもらいたいためにFrom:に複数アドレスを書くという使い方は正しくなく、そういう場合は別途Reply-To:で指定するのが正しいだろう。

*2 Outlook Expressでは、複数のメールアドレスは「;」で区切られて表示される。

*3 証明書のアドレスの方が「mail addresses are present in the certificate」と複数扱いになっているのはなぜ?

*4 ちなみにBecky!では「差出人」となっている。

本日のリンク元 TrackBack(0)

2004年09月20日

FMVの「セキュリティーエンジェル」(w

今日は休日だったので、久しぶりにパソコンショップをぶらぶらして、各社パソコンのプリインストールソフトにセキュリティホールがあったりやしないか調べるなどして暇つぶしした。

そこで、富士通のFMVの2004年冬モデルに搭載されている、富士通サービスアシスタントの「セキュリティ入門」というフラッシュコンテンツを見て、萎えた。VAIOにはあり得ないセンスだ。さすがは富士通。

そこに登場したのは、「セキュリティーエンジェル」というキャラ。これ、必見です*1

店頭では音がよく聴こえなかった。誰かFMV買わないかなあ。

*1 最後まで観ても落ちはなかったので期待してはいけない。

本日のリンク元 TrackBack(0)

2004年09月25日

NIKKEI NETにコラム

NIKKEI NETの「経営改革講座」で、「個人情報流出事件から教訓は得られるか」という題を頂いて、コラムを書かせていただいた。

私のような経営というものをまったく知らない者に「経営改革講座」などというものを書けるはずがないのであるが、経営者の方々がご存知でないことを伝えるのにはよい機会だと思い、どうにかそれっぽく話をつなげて脆弱性の話を書いた。

本当は最終回に、「技術者は怒っています」「かなり技術に詳しい者でないとできないレベル?」「ハッカーの仕業みたいなもの?」「悪用するような輩さえいなければいい?」「どこまでセキュリティをかければいいのか」などの話を書きたかったが、ビシッと確実な文章が書けず、嫌味を言うに留まる文章しか書けず、完成しなかった。締め切りに原稿を落として申し訳ないです。

Phishingに騙されぬようMozilla Firefoxを使う

とあるように、Mozilla Firefoxはフィッシング詐欺の防止に配慮しているようだ。

まず、Mozilla Firefox 1.0では、デフォルト設定で、ステータスバーの表示が強制されている。つまり、ステータスバーを隠すJavaScriptの機能を無効にする設定がデフォルトになっている*1。(加えて、ステータスバーの内容を自由に変更できるという、ばかげた機能もデフォルトで無効化されている。)

図1: ステータスバーを隠すJavaScript機能を無効にするFirefoxの設定

そして、ステータスバーには、HTTPSのページにアクセスしているときには、錠前アイコンだけでなく、隣にドメイン名(正確には、サーバ証明書のCommon Name)も表示するようになっている。たとえば、イーバンク銀行のログイン画面は以下の図のようになる。

図2: https:// の画面でアドレスバーが黄色になりステータスバーにドメイン名が表示されるFirefoxの機能

これはいい。これまでだと、錠前アイコンをクリックして所定の場所を見ないと、証明書の内容を確認できなかったため、素人にはわかりにくいものだった。これなら、意識の低い一般ユーザでも自然とドメイン名を確認するようになると思われる。

ユーザのとるべき行動は次のように単純化できる。

  • 個人情報やパスワードなど重要な情報を入力する際には、入力する画面のステータスバーに錠前アイコンが現れていることを確認し、その左脇に表示されたドメイン名が、自分の知っているサイトのドメイン名と一致しているかを確認する。

ちなみに、Firefoxでは、上の図のように、HTTPSのページを表示したときは、アドレスバーの背景が黄色になり、錠前アイコンも現れる。より見分けやすくなった。

そういえば昔、Netscape Communications社が最初にMosaic NetscapeにSSL機能を導入したときには、SSLの使用の有無は、青または赤の目立つ線で表示されていたのだった。それが、後にバージョン更新を重ねるごとに、目立たない表現に移り変わっていったのだった。ここ数年でフィッシング詐欺が深刻になったことで、再び目立つ表示が工夫されているわけだが、元々ブラウザ設計者はその区別を重要と考えていたわけで、原点に立ち戻っているにすぎない。

次に、SSLが使われていないサイトでは、個人情報を入力しないのだとしても、偽の情報を読まされて騙されるのを避けるために、アドレスバーを確認する必要がある。ステータスバーには何も表示されないからだ。

残念ながらFirefox 1.0 PRでは、「ツール」メニュの「オプション」の設定ではできないが、以下の方法で、アドレスバーの表示も強制する(アドレスバーを隠すJavaScript機能を無効にする)ことができる。

図3: アドレスバーを隠すJavaScript機能を無効にするFirefoxの設定

上の図のように、「about:config」のURLにアクセスすると、Mozillaの設定項目一覧が現れる。そこに「dom.disable_window_open_feature.location」という項目がある(「フィルタ」欄で「disable」などで検索して対象を絞ると見つけやすい)ので、そこの値を「false」から「true」へ変更する(ダブルクリックする)。

たとえば、意味もなくアドレスバーを隠している警察庁の「@police」で試してみると、以下の図のようになる。

図4: Firefoxでタイトルバーが強制表示になった様子

アドレスバーの背景が灰色になっているのは、ここが入力欄ではないことを意味している。サイト側が隠そうとしているのを強制的に表示させた場合は、このようになるらしい。4月26日の日記「太古の昔、アドレスバーが入力欄でなかったのを知ってるかい?」で書いた昔のMosaicはまさにこんな感じだった。

アドレスバーを隠すサイト運営者の言い分として、「戻るボタンを押されると正しく動かなくなる」というのを耳にする。戻るボタンはツールバーを隠せばよいのだから、アドレスバーだけ表示すればよいのだが、「URLを直接いじられたら正しく動かなくなる」という言い分*2があるらしい。そういう場合に、上のように入力できないアドレスバーというのは都合がよい。これならば、隠すことに何ら正当性がない。

灰色のアドレスバーは、ユーザが dom.disable_window_open_feature.location をtrueに設定しているときに現れるものだが、いっそ、アドレスバーを入力不可にしてウィンドウを開く機能をJavaScriptに新設してはどうだろうか*3

ところで、Mozillaは、7月に、XULを使って本物そっくりのユーザインターフェイスを偽装できることが脆弱性であるとして指摘された。この話は以下などにまとめられている。

slashdot.orgでも議論されていたが、この問題を回避するには、ステータスバーの表示が強制されていることを前提にすれば、ステータスバーが二重に表示されなければ、それは本物だと信じることができ、サーバ証明書は正しく確認できるという話のようだ。

ということは、SSLが使われていない場合にUI偽装に騙されないためには、アドレスバーの表示も強制しておくのが必須となる。

ちなみに、類似の偽装は、3月にInternet Explorerで実際にフィッシング詐欺に使われて実害が発生し、問題となっていた。

このときは、アドレスバーを隠したウィンドウに、画像やフォームを使った偽のアドレスバーをページ内に設置するという偽装方法だった。

この問題を解決するためだろうか、Windows XP SP2に含まれる IE 6 SP2では、ステータスバーの表示が強制されるようになったようだ*4。これはよいことだ。ソニー銀行でさえ、ログイン画面でステータスバーが表示されるようになる。

ただ、Mozilla Firefoxのように、錠前アイコンの隣にドメイン名を表示する機能がない点は劣る。

また、アドレスバーの表示を強制する機能はないようだ。IE 6 SP2では、アドレスバーを隠したウィンドウでは、タイトルバーの冒頭にURLの一部(ドメイン名まで)が強制的に表示されるようになった。たとえば、警察庁の@policeで重要なお知らせを表示させると以下のようになる。

Windows XP SP2のIEではタイトルバーにURLが強制表示される

この機能はイマイチだ。なぜなら、常にタイトルバーを見ていればよいかというとそうではなく、アドレスバーが表示されているときにはタイトルバーにURLは表示されない。<title>タグを使って偽のURLをタイトルバーに表示される可能性があるので、そこだけ見ていては騙される。アドレスバーが現れているときにはそっちを見ないといけない。

図6: アドレスバーが隠されていないときはタイトルバーにURLは表示されない

センスの悪い設計だ。

追記

9月17日の日記に書いた三井住友銀行の件が改善されていた。改善点は以下のようだ。

「(2)サーバの証明書で確認する」を削除しないのは往生際が悪い。「ログイン画面の「トラストマーク 」をクリックしてください」は、(1)の確認も必須だとしているからには、全く意味がない。そればかりか素人ユーザを混乱させるだけ有害だ。しかも、前回書いたようにこれは「サーバの証明書」ではないのだから、誤った解説だ。

*1 Mozilla 1.7.2では、デフォルトは有効のまま。

*2 そんな操作をして動かなくなるのはユーザの責任であり、それに文句を言うユーザはいないと思うんだが。

*3 既にある?

*4 設定で強制をやめることもできない?

本日のリンク元 TrackBacks(100)

2004年09月27日

誰も止めようとしない 家畜用ICタグの小学生への適用

NHKニュースで、ランドセルにRFIDタグを取り付ける小学校の話題が放送されているとのタレコミが入った。自宅のCoCoonを確認したところ録画されていた。

  • 登下校確認 発信装置で識別, NHKニュース 経済, 2004年9月27日

    (略)

    この新しいシステムは、東京の私立小学校が27日から試験的に導入したもので、子どもたちのランドセルなどに取り付けた縦6センチ、横3センチの小型のICタグから発信する電波を校門に設置された受信機で受信し一人一人の登下校の時間を把握するものです。受信機は、10メートル離れた距離から通り過ぎる複数の子どもたちを同時に識別し、ICタグを持っていない不審者が学校内に入ると、警報が鳴るようになっています。また子どもたちが何時に登下校したかは、電子メールで保護者に送信され、無事学校に到着したのかいつ学校を出たのかすぐに分かる仕組みになっています。このICタグには、子どもたちの氏名などの個人情報は入っていないため、紛失しても情報の流出が起きないようにしており、学校では、「登下校の時間が分かれば、異常があったことを知ることができ安全管理に役立つ」と話しています。

7月7日の日記に書いた和歌山県田辺市の計画と同様に、使用されるタグはアクティブ型(電池内蔵型)であるため、10メートルの距離から楽々読み取れるというところが、パッシブ型RFIDの議論(消費財のアイテムレベルタギングにおけるプライバシー問題の議論)と異なる点だ。

その点について、8月に勤務先で日経産業新聞の取材を受け、次のようにコメントした。

  • 情報技術の死角 安全対策を問う(中)ICタグ――市販装置で読み取りも, 日経産業新聞8月24日先端技術面

    だがセキュリティー研究者からは「ICタグを付けることで危険が増す場合もある」(産業技術総合研究所の高木浩光チーム長)と危ぐする声があがる。 児童に付けるICタグの電波の受信可能範囲は数メートルから数十メートル。もし悪意をもつ第三者が読み取り機を持って家の中や物陰に潜めば、壁の向こうに小学生が何人いるかが瞬時に分かる。

    ICタグのIDはただの番号にすぎないが、常に同じ番号を発信しながら歩くので、結果的には番号から個人を識別できる。個人情報がいったん第三者に漏れれば、過去の履歴から行動が追跡されてしまう。

アクティブ型RFIDタグの児童への取り付けは、誘拐犯や変質者にとっての情報源にもなりうる。

今回報道された小学校で使用されるRFIDタグに、第三者からIDを読めなくするスクランブル機能が搭載されているかは不明であるが、仮に搭載されているとしても、同型のタグからの電波だということは判別できてしまうだろう。

今回の事例の問題点の新しさは、裕福な家庭の子供しか通学していない学校の児童が判別されてしまうということであり、これまでの事例よりリスクが高まっている。

RFIDタグの小学生への適用は、時間順に見るとこれまでにも以下の報道があり、次第にリスクの高い方式が導入されていっている。

この事例では、児童が読み取り機にタグをかざすという動作が必要だったので、第三者にIDを読み取られるリスクはまだ小さめであった。

  • ICタグで児童の安全確保 職員室で登下校を集約, 京都新聞, 2004年6月17日

    近畿総合通信局は、情報を読み書きできるICタグ(電子荷札)を、小学生の登下校時などの安全確保に活用する実証実験を始める。(略)

    計画では、自ら電波を発信するタイプのICタグを児童のランドセルに付け、校門にリーダー(読み取り装置)を設置する。(略)

    通学路周辺の危険個所にもリーダーを設置して、立ち入り情報を瞬時に把握、危険を予防する。(略)

    7月7日に検討会の初会合を開く予定で、実験方法やシステムを構築をした上で、10月から和歌山県田辺市の公立小で実験を始める。

この事例では、一歩踏み出して、ついにアクティブ型タグを人に使用するという、世界的にも類を見ない先例を作った。また、これまでの実験がいずれも施設内での利用を想定していた(園児の幼稚園内カメラ追尾の事例のように)のに対し、施設外にも読み取り機を設置するところまで踏み込んだ。地方役人ならではの無意識のなせる業であろう。

ただ、この事例では、田舎で短期間に行われる実験であるため、誘拐犯や変質者に悪用される事態が発生する確率はやや低めであった。

同様の事例が、今月22日にも報道されていた。

  • 通学安全をパソコンで確認 岩邑小で実験開始、カバンにICタグ, 中日新聞岐阜版, 2004年9月22日

    岩村町の岩邑小学校で、児童の通学状況を把握する「通学安心システム」の実証実験が二十一日、正式に始まった。こうした実験は全国初めてで、十一月十九日まで二カ月間、システムの精度などを調べる。

    同町が行っている無線でインターネットなどの情報網にアクセスできる「ユビキタス」ネットワークサービスを利用。ランドセルなどにつけた「ICタグ」と呼ばれる発信器の微弱電波を、学校正門や通学路など四カ所に設置された受信機が読みとる仕組み。

    実験するのは、VRテクノセンター(各務原市)と共同印刷(東京都文京区)。保護者が同意した児童七十二人が参加し、学校のパソコン画面で誰がいつ受信機前を通過したかを、専任教諭が確認する。

    (略)岩邑小の山崎佑助校長は「保護者が安心できるよう、実験がうまくいってくれれば」と話していた。(松平徳裕)

「無線でインターネットなどの情報網にアクセスできる「ユビキタス」ネットワークサービスを利用」というのが、そこはかとない不安感を誘うが、ここは田辺市よりさらに田舎であるから、悪い人などおらず、悪用される確率はさらに低いだろう。各務原市という都会の会社がわざわざ遠く離れた極端な田舎の岩村町で実験するのも頷ける。

ちなみに、VRテクノセンターというのは、「バーチャルリアリティー」が行政用語だった10年前に、梶原拓岐阜県知事の肝いりで始められた第三セクター事業。当時、岐阜県民で、知事に投票したこともある私は、情報技術に力を入れる知事に親近感を覚えたものだ。

田辺市を出し抜いて「全国初めて」を達成! おめでとう。岐阜県万歳。

自治体はお互いに競走し合っているので、地方博覧会などと同様に、この手合いのプロジェクトはどんどん広がっていくだろう。

  • 校門を通過する児童をRFIDでリアルタイムに把握〜立教小学校で試験運用, INTERNET Watch, 2004年9月27日

    学校法人立教学院立教小学校(東京都豊島区)と富士通は27日、児童の安全対策を目的としてRFIDで登下校を把握するシステムを導入すると発表した。同日より児童40人で試験運用を開始し、順次規模を拡大、2005年4月の実用化を目指す。

    導入するシステムでは、315MHz帯の電波を利用するアクティブ型のRFIDを採用。タグ自身から微弱な電波を発信するために10メートル程度離れた受信機からでも情報を読みとれるようになっており、専用のゲートが不要で、児童も立ち止まらずに校門を通過するだけで検知できる。(略)

そして今回の事例である。悪い人間も多い都心で、アクティブタグを使用し、かつ、名門小学校が実施するという点が、新たなリスクへ一歩踏み出している。

さて、この件は、NHKニュースでは次のように扱われていた。(7時のニュースとニュース10で2度放送されている。)

まず、キャスターは冒頭で次のように話し始めた。

7時のニュース:「最近子供達を狙った犯罪が増えていますね、子供達を守るためにICを使った技術まで使われるようになりました。」 ニュース10:「続いて、子供の安全を守る新たな取り組みです。最近学校の行き帰りに子供が犯罪や事故に巻き込まれるのではないかと心配する人も多いかと思いますが、こんな新しい技術が開発されました。」

この小学校に通う母親とされる女性が3人登場し、それぞれ次のようにコメントしていた。


母親A:「朝着いた時間がわかりましたので、無事着いたなということがわかって、よかったと思っております。(うんうんうん)

母親B:「とても安心だと思いますね。(うんうん)」

母親C:「こういうふうに?何時に学校を出たか っていうことがわかるとー、少しあのー気持ち的に落ち着くところはあると思います。(うんうん)。特に都心ですのでえ、あのーいつ何が起こってもおかしくないっていうような?あのー時代ですので、あのー安全対策にはやっぱりこう、何重あっても別にあの、問題になるものでも邪魔になるものでもないと思ってます。」


母親Cのコメントを見ると、本当はたいして役に立たないと思っているフシが見える。「安全対策は何重にあっても邪魔になるものではない」というのは、その対策が有害性ゼロであれば、ないよりは良いという意味なのだから。

この母親は、第三者にも電波を検知される可能性があるかどうか、学校側から説明を受けているだろうか。

母親にはこのような内容のメールが届くという。

NHK総合, ニュース10, 2004年9月27日22時57分ごろより引用

こんなシステムでは、昨今流行の詐欺のように、「○○さんは下校しました」という偽メールが犯罪に使われかねない。携帯メールのような発信者偽装を見破りにくいシステムを使って、このような仕組みを市民に慣れさせていくのは危険だ――という面もある。

キャスターは最後のところでこう語っていた。


キャスターB:「これがその、子供達がランドセルに付けていたICタグなんですけども、ずいぶんとこう小さくて軽いんですねー」

キャスターA:「そうですねえ、なくした場合ちょっと心配かと思うんですけども、この中にはですね、児童ひとりひとりに割り当てられた数字と文字しか入ってなくて、名前ですとか住所とかは、流出することがないんだそうです。大丈夫なんだそうです。」


例によって例のごとく「番号だけだから大丈夫だ」なわけだが、放送には、警備室内の管理用パソコン画面が以下のように映っていた。

NHK総合, ニュース10, 2004年9月27日22時55分ごろより引用

なんと、「タグ番号」がほとんど連番になっているのがわかる。これだと、タグ番号から性別や学年の判別ができてしまうだろう。

もっとも、この画面はデモ用の画面で架空のものなのかもしれない。しかし、番号を連番にするというのは、情報セキュリティに素人な業者が作るシステムで、とてもよくありがちな話だ。少なくとも、番号が持つプライバシー性に配慮したシステム作りをしている業者であれば、たとえデモ画面であれ、テレビで見せるからには、ランダムな番号になるように配慮するだろう。本番でもこのような運用がなされる危険性が高い。

また、キャスターは、タグをなくしたときのことしか心配していなかったが、普段からID電波を出し続けている点を視聴者に伝えるべきである。上の右の説明図では、あたかも、児童が校門にさしかかったときだけ電波を発信するかのように、ほとんどの視聴者が受け取ったであろうが、街を歩くときも、電車の中でも、家の近くでも、同じ電波を出し続けていることをこの図で説明するべきだろう。

キャスターのふたりは、この種の仕組みに対して何ら疑問を投げかける発言をしなかった。せいぜい、最後の最後でこう口にした程度だ。


キャスターA:「子供達の安全を守るこうした技術ね、なんかこれからますます広がりそうですけど、寄り道できませんね。」

キャスターB:「(ニコニコ)ねー、子供達にとっては。(ニコニコ)」


NHK総合, ニュース10, 2004年9月27日22時59分ごろより引用

この報道が、社会部でもなければ科学技術部でもなく、経済部の記者によるものだというところが、RFIDタグの置かれた状況をあらわしている。

ところで、このシステムは「ICタグを持っていない不審者が学校内に入ると、警報が鳴るようになっています」というものだそうだが、それは変な話だ。NHKの映像では、人が横切るのを検出する赤外線センサーを校門の両端に設置していたが、そんなもので不審者の侵入を防げるとは思えない。それこそ、小学生を連行しながら門に入るとか、ランドセルを奪い取って門に入るとかが起きるだけだ。

こんな糞システムでもニュースになってしまうのが、昨年から今年初めまでのRFIDバブルだ。ややバブルに乗り遅れて登場した今年夏の「RFIDタグによるバーチャル昆虫採集」なんかは各方面で失笑を買うものだった。「RFID使いました」言いたいだけちゃうんかと。

今回の報道で、役に立ちそうにもない赤外線センサーを併用したのは、「新しい技術が開発された」という形にするために必要だったのだろう。なぜなら、アクティブ型RFIDタグによる出入りの監視技術は、ぜんぜんちっとも新しくないからだ。

家畜や、愛玩動物、野生生物の追跡のためにとっくの昔から実用化されてきたものだ。

なお、富士通は今回のプレスリリースにおいて、第三者読み取りの防止というタグの安全措置について、何ら書いていない。

  • 児童一人一人の登下校を確認する安全対策システムを導入 〜アクティブ型RFIDタグを使用し児童の安全を確保〜, 学校法人立教学院 立教小学校 / 富士通株式会社, プレスリリース, 2004年9月27日

    【本システムの特長】

    (略)

    2. 不審者の検出

    児童と教職員にアクティブ型RFIDタグを持たせることにより、校門通過時に人物を特定できるため、赤外線センサー等と連動させることで、タグを持たない不審者を検出することができます。

    3. 情報漏洩を防止

    アクティブ型RFIDタグには個人情報が記録されていないため、万一紛失しても個人情報の流出はありません。

    (略)

    お客様お問い合わせ先

    (略)

    富士通株式会社
    パブリックセキュリティソリューション本部
    営業推進部

関連報道:

  • 富士通:ICタグで児童らの安全確保, 毎日新聞, 2004年9月27日

    (略)同小の石井輝義・情報科主任は「登校した児童にタイムカードを押してもらうわけにもいかない。無線タグの導入で、児童の動きを規制することなく安全を確保できるようになる」と話している。【野原大輔】

  • 登下校、無線ICタグで把握 新しい「お守り」に人気, 朝日新聞, 教育ニュース, 2004年9月27日

    無線ICタグ(荷札)を用いて登下校など子どもたちの行動を把握する試みが教育現場で相次いで始まった。インターネットと組み合わせて使えば、学校職員や離れた場所にいる親が子供の所在を知ることができる。ICタグはコストが安く、大勢の子どもに普及させやすい利点がある。子どもを脅かす事件が相次ぐ中で有力な保護手段として注目されそうだ。(略)

なお、このNHKのニュースをみて一般市民(特にプチウヨ系の庶民)はどう感じただろうかと、2ちゃんねるの「番組ch」NHK総合実況板を探したところ、次のように語られていた。

RFIDタグに関する国会の3月の議論

今年3月に、国会予算委員会でRFIDタグに関する議論があったようだ。

  • 第159回国会 予算委員会第七分科会 第2号(平成16年3月2日)

    ○長安分科員

    (略)

    私の地元泉州では、昨年の五月二十日に熊取町で小学校四年生の吉川友梨ちゃんが行方不明になって、これは誘拐か神隠しかわからない。もう九カ月以上が過ぎているけれども、いまだに行方がわからないという状況にあります。私、昨年選挙を控えておりましたので、政治の道具にするのはいかがと思いまして、発言を控えておりましたけれども、私、家が近いということもございまして、友梨ちゃんが一日も早く出てきてくれるように、または見つかるように努力していきたいなと思っておる次第でございます。

    このような事件が起こりますと、地元のお子さんをお持ちの親御さんからしますと、学校の行き帰りに何かあるんじゃないかというような不安を持たれて、心配が多いかと思います。そういった意味でも、そういった治安を守るための政策をしていかなければならない。一義的には、例えば警察を増員する、そういったことも必要ですけれども、警察だけでは見張り切れない、見ることが、目が届かない、そういうこともございますので、例えば地域がみんなで治安維持のために協力していく、そのために地方自治体がそういった地域に対して資金的な協力もしていくということも必要じゃないかと思っております。

    (略)

    ○中川国務大臣

    (略)

    そういう意味で、今委員も大変御熱心にこの問題にお取り組みいただいておりますけれども、政府といたしましても、経済産業省を初め各省庁、それからこれは電波の世界にも関係しますので総務省とも十分連携をとりながら、先ほどの食品のトレーサビリティー、安全性の問題のトレーサビリティーあるいは冒頭お示しいただいた本当に悲惨なお子さんをめぐる事件、事故が続発しておりますけれども、万が一にも、例えばランドセルにとか、何でしょうセーターにとか、そういうものにICタグがきちっとついていればということを考えると、早くこういうことが実用化されれば少しでもこういう事件、事故が防げるのではないかと思っておりまして、こういう大事な技術はスピード感を持って実用化していくことが大変大事でございますから、我々も全力を挙げて、経済産業省のみならず各省連携をとりながらやっていきますので、どうぞ委員におかれましても引き続き御指導よろしくお願いいたします。

    (略)

    ○長安分科員 先ほどお話ございましたけれども、ICタグについては、プライバシーの問題というのが、プライバシーを保護するというのが大きな課題となっております。この点について、どのような対策を講じられているのか。また、必要な法整備、また具体的なスケジュール等、ちょっと御説明いただきたいんですけれども。

    ○江田大臣政務官 今先生御指摘のとおり、電子タグというのが、その性質上、まだ多くの国民の皆様に十分認識されていないというのが現状でございます。

    したがって、消費者が商品に電子タグがついているというその意識がないままにこれを所持して移動して持っていかれますと、消費者の気づかないうちに消費者が望まない形で読み取られるというおそれが十分に将来的に予想されるわけでございます。

    例えば、これはもう個人情報ではございませんので個人情報の侵害にはならないと思いますけれども、やはりプライバシーの侵害にはなる。例えばかばんの中のものとか、着ているものとか、そして家の中にあるものとかが読み取られるおそれがあるわけでございます。

    現段階で、実際にプライバシーの侵害が起こっている、まだ本格的にも普及しておりませんのでそういう状況ではないわけで、立法措置が必要という認識には今はまだ至っておりませんけれども、後手に回ったんでは遅いということで、当省といたしましては、例えば電子タグがついていることの表示をするとか、そしてまた、望まない人にはそれを使えなくする方法を教えるとか、そういう電子タグに関するプライバシー保護ガイドラインを制定して、関係事業者団体に徹底することといたしております。

    具体的には、(略)

悲惨な事件を防げるほどの能力を持つICタグがランドセルに付いていれば、悲惨な事件を起こす犯罪者にもタグが便利なものとなりかねないので、対策なしの導入をしないよう注意が必要だという、基本的な理解が必要である。

靴下にRFIDタグ

  • 【自動認識展】「靴下がそろっていないと警告」,大日本印刷が洗い物を認識する洗濯機を開発, 2004年9月18日

    同洗濯機には,衣服の出し入れ口に無線タグのリーダーを環状に組み込んである。これによって無線タグが付いた衣服の種類などを認識,管理できるようにした(図1)。無線タグのIDデータを読み取った洗濯機は,表示パネルに衣服のアイコンを表示する。その衣服の分類や生地にあった洗い方などを表示することもできる。靴下の片方が足りなければ,警告もしてくれる(図2)。(略)

    (略)アパレル業界は,無線タグの利用に最も熱心な業界の1つ。プライバシーの問題は解決しなければならないものの,衣服に無線タグが付けられるようになれば,こうした洗濯機が将来発売される可能性はかなり高そうだ。

こんなの本気でやるつもりなのだろうか。RFIDタグのイメージを悪くするばかりだと思うのだが。

「共同で洗濯機を開発した家電メーカーの名前も明かさなかった」というくらいなので、洗濯機のメーカーが富士通でないことだけはわかる。

Calvin Kleinのパンツにもタグが縫いこまれる?

先日、CASPIANが次のリリースを出していた。

展示会場で撮影された写真がたくさん掲載されている。

本日のリンク元 TrackBack(1)

2004年09月29日

JVNのことはほとんど知られていないのだろうか

7月から始まった脆弱性情報の届出制で、ソフトウェア製品の脆弱性においては、結果の出口(ベンダーの対応状況の一般公表)は、どうやらJVN (JP Vendor Status Notes) での発表ということのようだが、ひとつの問題は、ここをどれだけの人が見てくれているかだ。

公表第1号となった「JVN#FF73142E: ウイルスバスター コーポレートエディション に脆弱性」の件は、いくつかのメディアで報道されていた。しかし、第2号として今月24日に公表された「JVN#F88C2C13: desknet's に脆弱性」の件は、セキュリティホールmemoで取り上げられたのを除くと、他ではまったく話題になっていないようである。これはなぜなのだろうか。

  1. 当該製品が、ユーザの少ないマイナー製品である?(そうとは思えないのだが)
  2. 当該製品は、組織内の管理者が着々とメンテナンスしているから、一般のユーザが話題にすることがないというだけ?
  3. 脆弱性の説明が十分でないため、緊急性があるとは理解されていない?
  4. 脆弱性の説明が十分でないため、マスメディアが記事にするには取り上げにくい?
  5. ……?

当該製品のWebサイトを見に行ってみると、この件についてのお知らせが出ていない。JVNからリンクされているパッチのページへは、どこからたどれるのだろう?

このパッチのページには、「重要」という赤色の文字が書かれているものの、

修正内容

ウェブメールにて、悪意のあるスクリプトを含んだHTMLメールを参照した場合や、インフォメーションにて、悪意のあるスクリプトを含んだインフォメーションを参照した場合に、個人情報が漏洩する可能性がある問題を解消しました。

アップデートモジュール ( V4.2J R1.6→ V4.2J R1.7 ), ネオジャパン, 2004年9月24日

という説明がなされているだけで、ここには、「脆弱性」とか「セキュリティ」とか「欠陥(せめて不具合)」という言葉が使われていない。

「個人情報が漏洩する可能性がある」という説明も、いまひとつどいうことなのかわからない。「可能性がある」というのは可能性は低いのかどうか。何が漏れるということなのか。そのあたりの不明瞭さが、マスメディアが市民に伝えようとする気を削いでいるのだろうか。発見者による脆弱性の明確な解説があれば、報道されることもあるのだろうか。

こういうとき、JVNが、発見者からの報告内容に基づいて、きちんと必要な情報を自分の言葉で表現して公表すればよいのだが、今回の事例では、ベンダーの発表を丸写ししただけになっている。

概要

ウェブメールにて、悪意のあるスクリプトを含んだHTMLメールを参照した場合や、インフォメーションにて、悪意のあるスクリプトを含んだインフォメーションを参照した場合に、個人情報が漏洩する可能性があることが確認されています。

想定される影響

個人情報が漏洩する可能性があります。

JVN#F88C2C13 desknet's に脆弱性, JP Vendor Status Notes, 2004年9月24日

当該製品がグループウェアであることからして、ふつう(脆弱性情報を取り扱うプロならば)、「個人情報が漏洩する可能性があります」などという具体性の欠如した表現は使わないと思うのだが。

けっきょく、これだけの体制をとっても、ベンダーの発表した通りにしか公表できない*1というのであれば、わざわざこういう体制をとった意義がないのではないか。単なる脆弱性リストとしての役割(CVEのようなもの)しか果たさない。この調子では、発見者が脆弱性情報を自力で公表する必要性を感じてしまうだろう。

権威付けされた脆弱性リストという点で意義があれば十分というのなら、多くの人に読まれて、マスメディアも取り上げてくれるという状況が必要であろう。そこをどうするのか。

やはり、ベンダーが脆弱性情報を公表するときの、言葉の使い方とか、タイトルのつけ方とか、脆弱性の深刻さについての書き方とか、起こり得る被害の内容の書き方とか、そういうものの標準というか、ガイドラインというか、お手本が必要だろう。危惧していた通りの展開になっている。

追記(10月1日)

28日から30日の間にネオジャパンのサイトがリニューアルしたようで、「アップデートモジュール ( V4.2J R1.6→ V4.2J R1.7 )」のページが 404 Not Found になってしまった。いやはや。JVNからもリンク切れになっている。

改装前: http://www.desknets.com/download/patch/patchtov42r17.html
改装後: http://www.desknets.com/standard/download/patch/patchtov42r17.html

Webサイトに適法なバックドア?

  • 「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る, ITmedia ニュース, 2004年9月29日

    続いて、ネット情報セキュリティ研究会(NIS)技術調査部長の萩原栄幸氏は、「国内のWebサイトは脆弱すぎる」と指摘する。「ある有名大学のWebサイトに、不正アクセス禁止法に抵触しない程度の簡単なバックドアを仕掛けたところ、大学の教職員名簿がまるごと見えてしまった」(萩原氏)。このような脆弱なサイトは国内では珍しくないという。

「Webサイトにバックドアを仕掛けた」……? 意味がわからない。記者の書き間違いだろうか。

追記(10月1日)

記事が改訂されていた。

  • 「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る, ITmedia ニュース, 2004年9月29日

    続いて、ネット情報セキュリティ研究会(NIS)技術調査部長の萩原栄幸氏は、「国内のWebサイトは脆弱すぎる」と指摘する。「検索エンジンを利用しただけで、ある有名大学のWebサイトから大学の教職員名簿がまるごと見えてしまった」(萩原氏)。このような脆弱なサイトは国内では珍しくないという。

*1 つまり腰抜けということ。

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記