最新 追記

高木浩光@自宅の日記

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

2006年08月02日

公務員研修で体験させておくべき演習 「蛍光ペンで墨塗り」の巻

という報道が出ている。この種の事故については2003年7月29日の日記にも書いていた。そのときは「フォントの背景色を黒にした」?と書いていたが、Microsoft Wordの「蛍光ペン」機能を黒色で使ったのではないかと予想した。当たりだった。

  • 千葉市教委HP「墨塗り」丸見え、会見で謝罪, 朝日新聞, 2006年8月1日

    「ワープロソフトで会議録を作成した際、個人情報の部分を『蛍光ペン』という機能を使って墨塗りしたが、元の文書を消していなかった。確認不足で、技術的に未熟だった」としている。当時のHP作成担当者は「そのやり方が能率的に速く消せると考えた」と話しているという。

この種の事件は国外では最近もたびたび報道されていた。

「蛍光ペンで墨塗り」とはどういうことなのか、実際にやってみるとすぐわかる。

図1: Microsoft Wordの「蛍光ペン」機能

デフォルトは黄色だ。このボタンを押した状態で、マウスでボタンを押しながら文字列をなぞると、図2のように黄色に塗ることができる。

図2: 「蛍光ペン」で文字列をなぞった様子

「蛍光ペン」は黒色を選択することもできる(図3)。

図3: 「蛍光ペン」で黒色を選択する様子

黒で塗ると図4のようになる。

図4: 黒の「蛍光ペン」で塗った様子

これをPDFに変換して表示すると、図5のようになる。

図5: PDFに変換して表示した様子

ここで、Acrobatの「高度な編集」ツールバーにある「TouchUp オブジェクトツール」機能(図6)を使ってみる。

図6: Acrobatの「TouchUp オブジェクトツール」機能

墨塗り部分の淵を押しながらドラッグすると図7のようになる。

図7: 「TouchUpオブジェクトツール」で墨塗り部分をドラッグしている様子

放すと図8のようになる。

図8: 墨塗り部分を移動させた様子

要するにそういうことだ。ソフトウェア開発に携わったことのある者であれば、直感的にこうなることがわかるけれど、そうでない人々にはこうしたことが予想できないのだろう。

こういうのは一度実験をやって体験しておけばよい。一度体験しておけば体で覚えることになるはずではなかろうか。公務員研修の必須演習課題にしてはどうか。

担当者個人の力量に頼るのもよくない。具体的にルール化した手順書を用意するべきだということは以前から講演などで言ってきた。最近はどうなっているだろうか*1*2

ちなみに、隠れている文章を読むだけならば、上のようなことをせずとも次のいずれかの方法で読める。

  • Acrobatの「選択」機能で当該部分をドラッグして選択し、「編集」メニューの「コピー」でクリップボードにコピーし、メモ帳などでペーストすれば読める。

  • Acrobatの「ファイル」メニューの「名前をつけて保存」で「ファイルの種類」を「テキスト(プレーン)」にして保存し、それを開くとそのまま読める。

  • Acrobatの「表示」メニューの「折り返し」モードを使うと、そのまま読める。

ここで、「Acrobatのセキュリティ機能で暗号化(図9)してコピーペーストできないようにすればいい」と思う人がいそうだが、それでは駄目なので注意が必要だ。

図9: Acrobatのセキュリティ機能

たしかにこの設定で保存すれば、文字列のコピーペーストはできなくなるし、テキストでの保存もできなくなる。しかし、「折り返し」モードは使えてしまう(図10)。

図10: 暗号化されたPDFを「折り返し」モードで表示した様子

そもそも、Acrobatの暗号化機能が十分に信頼できるものかという話もあるので、素から絶たなきゃだめ、と考えるべきである。

「素から絶つ」ことに抵抗を感じ、「蛍光ペン」で済まそうとする気持ちはわからなくもない。文字を記号(たとえば「〓」)に置き換えることが、「文書の改竄にあたる」と感じるからではないか*3。官公庁の情報公開の一環ならば、改竄にあたるようなことをできるだけしたくないという感覚があるのだろう。文字を置き換えてしまうと、文字幅の都合でレイアウトが変わってしまうかもしれない。レイアウトを変えずに素から絶つのは簡単な作業ではない。

一太郎には墨塗りの機能があるらしい。

これを使うと綺麗に消せるのだろうか?

追記(8月6日)「折り返し」機能を無効に?

トラックバックを頂いたので追記する。

これによると、「折り返し」機能を無効にしてPDFを生成する方法があるそうだ。その方法で生成したサンプルの墨塗りPDFファイルが提供されている。

しかし、検索機能で読むことができる(図11、図12)。

図11: 検索機能で墨塗り部分を読んでいる様子

図12: 検索機能で墨塗り部分を読んでいる様子

長い領域が隠されていても、繰り返し検索すれば全部を読むことができそうだ。

いずれにしても、Acrobatの「セキュリティ」と称する機能に頼ってはだめだ。上では「Acrobatの暗号化機能が十分に信頼できるものかという話もあるので」と控えめに書いていたが、ある方から「『全く信用できない』と書くべきだ」とのご意見を頂いた。暗号化に使っているその暗号鍵はどこにあるのかといえば、パスワードなしに閲覧できるファイルである限り、ファイル自身に鍵が含まれているか、Acrobat本体に埋め込まれているかのどちらかまたは両方であるから、解析すれば解除できてしまう。

その昔、この暗号化を解除するソフトウェアを配布したロシアのプログラマが、米国で逮捕されるという事件があった。

  • 『アドビ・アクロバット』ファイルの暗号解読でロシアのプログラマー逮捕, WIRED News, 2001年7月17日

    ロシア人のプログラマーが米連邦捜査局(FBI)に逮捕された。このプログラマーが配布したソフトウェアは、電子書籍の著作権保護のために暗号化された『アドビ・アクロバット』ファイルの制限を解除してしまう、というのが逮捕の理由だ。

    (略)スクリャーロフ氏は、論議の多いデジタル・ミレニアム著作権法(DMCA)の刑事上の責任を定めた項目に基づいて逮捕された。

日本の場合は、不正競争防止法2条1項11号が関係するだろうか*4

不正競争防止法

第二条

この法律において「不正競争」とは、次に掲げるものをいう。

十一 他人が特定の者以外の者に影像若しくは音の視聴若しくはプログラムの実行又は影像、音若しくはプログラムの記録をさせないために営業上用いている技術的制限手段により制限されている影像若しくは音の視聴若しくはプログラムの実行又は影像、音若しくはプログラムの記録を当該技術的制限手段の効果を妨げることにより可能とする機能のみを有する装置(当該装置を組み込んだ機器を含む。)若しくは当該機能のみを有するプログラム(当該プログラムが他のプログラムと組み合わされたものを含む。)を記録した記録媒体若しくは記憶した機器を当該特定の者以外の者に譲渡し、引き渡し、譲渡若しくは引渡しのために展示し、輸出し、若しくは輸入し、又は当該機能のみを有するプログラムを電気通信回線を通じて提供する行為

不正競争防止法2条1項11号

いずれにしても、こうした機能は著作権保護程度の目的ならば使い物になるかもしれないが、情報公開などにおいてセンシティブ情報を隠すための「墨塗り」をする際に、法律による保護に期待するようなこと(「サイバーノーガード戦法」と呼ばれる)をしてはいけない。

*1 内閣官房の「政府機関の情報セキュリティ対策のための統一基準」にも書いてないみたいなのだが……。これからの段階?

*2 総務省訓令第126号「行政機関の保有する情報の公開に関する法律に基づく処分に係る審査基準」に次のように書かれている部分があるものの、どうやって「一部を除く」べきかということについてはこの文書では言っていないようだ。

第4 部分開示に関する判断基準

2 「容易に区分して除くことができるとき」

(1)(略) 「区分」とは、不開示情報が記録されている部分とそれ以外の部分とを概念上区分けすることを意味し、「除く」とは、不開示情報が記録されている部分を、当該部分の内容が分からないように墨塗り、被覆等を行い、行政文書から物理的に除去することを意味する。

(2) 文書の記載の一部を除くことは、コピー機で作成したその複写物に墨を塗り再複写するなどして行うことができ、一般的には容易であると考えられる。なお、部分開示の作業に多くの時間・労力を要することは、直ちに、区分し、分離することが困難であるということにはならない。

一方、録音テープ、録画テープ、磁気ディスクに記録されたデータベース等の電磁的記録については、区分して除くことの容易性が問題となる。(略)

なお、電磁的記録について、不開示部分と開示部分の分離が既存のプログラムでは行えない場合は、「容易に区分して除くことができないとき」に該当する。

*3 ちなみに、暗号研究の分野では、電子署名された文書で署名の効力を保持しつつ墨塗りする(当該部分を抹消する)手法がテーマのひとつになっている。それが実用化されれば、墨塗り以外の改竄をしていないことを証明できるので、素から絶つことに対する抵抗をなくせるかもしれない。

*4 ちなみに、Winnyプロトコルの暗号化が、「特定の者以外の者に……させないために営業上用いている技術的制限手段」に該当するかというと、営業上用いているわけではないといったところか。ということは、Winnyがもし営業目的で作成され、頒布され、特定の者にだけ使用させられていたならば、Winny可視化プログラムなどを提供することは許されなかった(作成と使用自体は禁止されていない)ということだろうか?(その代わりに、その営業の結果起きる事態に対しての責任を営業する者が負うことになるのだろうが。)

本日のリンク元 TrackBacks(100)

2006年08月04日

Winnyに関する国会の議論

国会議事録(3月14日の法務委員会)にこのようなやりとりが記録されていた。

○竹花政府参考人 先ほど来法務省の方からの答弁にもございましたように、ウィニーというソフト自体を、法令に違反する、そういう存在として定めている法令がないわけでございますので、そのもの自体を取り締まることは現行法令においては難しいものと私どもは思っております。

しかしながら、ウィニーというものあるいはそれに類似した機能を有するものが今後さまざまな形であらわれていくであろう。しかし、それが有用な側面を持つ一方で、悪用されるおそれもあるという点について、私どもといたしましては、今後の状況を十分注視しながら、適切な対応が必要な場合も生ずるのではないかというふうに考えておるところでございます。

○高山委員 それでは、最後に法務大臣に伺います。

このウィニーというソフト、便利な反面、法務省でも大情報流出を起こしてしまったように、ちょっと問題も多いソフトじゃないかな。しかも、正しくという言い方は変ですけれども、正しく使われたとしても、音楽の無料交換に使われている。

法務大臣のこのウィニーというソフトに対する評価をちょっと伺いたいんですけれども、今後、どうですか、こういうソフト、今は、現行法の範囲内ではちょっと罰することは難しいということでございますけれども、法務大臣としては、このウィニーというソフトに対して今どのようにお考えか、その感想だけまず伺いたいと思います。

○杉浦国務大臣 私は古い人間なものですから、コンピューターはよくわからないんですよ。この間、情報が流出しましたが、自宅へ持ち帰ってウィニーにつないでおいたら全部出ちゃったというんですね。そんなことが可能なのか。技術は日進月歩ですから、今、流出問題については調査を徹底的に進めておりますけれども、正直言って、私はよくわかりません

ただ、犯罪が成立するかどうかは、一般論ですが、当然のことながら個別の事案ごとに、こういう証拠があって、では、著作権法違反ならば罰せられるよということになるわけなんですが、先生のお考えでは、ウィニーそのものを禁止するといいますか、つくることを禁止すべきだというお考えもおありかと思うんですが、立法論としてあり得るかもしれませんね。これはいろいろと御検討願って、今警察の話を聞いていても、法律がないから取り締まれないんだということを言っていましたから、検討すべき課題かもしれませんね。

正直言って、私にはそういう能力がございませんので、何とも申し上げられないのが実情でございます。今、現時点では、何度説明を聞いてもまだよくわからない状況でございます

○高山委員 それでは、もう一問だけ。

技術的なことは杉浦大臣はいまいちだということですけれども、今聞いて、警察あるいは法務省の方でも、事案によると犯罪になるものもある、ちょっとどう評価していいかわからない、ただ、完全に、すごくいいソフトですねと手放しで言うわけにもいかないなというような雰囲気だったと思うんですけれども、こういったソフトを行刑施設の職員ですとかあるいは警察署の職員の方までが自分のパソコンにインストールしていた、この行為に関しては、大臣、どう考えますか。ちょっと軽率だったんじゃないかと考えるでしょうか。

○杉浦国務大臣 軽率きわまるものだと思います。今調査をしておりまして、処分も厳正に行うつもりでおります。今はもう一切持ち出しを禁止しまして、そういうことのないようにいたしましたが、ソフトとして便利かもしれないけれども、ちょっと首をかしげたくなるようなソフトであるという印象は持っております。

第164回国会 法務委員会 第5号(平成18年3月14日(火曜日))

あまりにも正直な発言をする大臣。

本日のリンク元 TrackBacks(100)

2006年08月05日

ウゲ、イーバンク銀行の誤ったセキュリティ解説

イーバンク銀行のセキュリティについてのページに、「よくわかるイーバンクナビ」というFlashコンテンツが置かれていた。

その中の「セキュリティについて」に「イーバンクのフィッシング対策」という項目があるのだが、その内容が間違っていて、その通りに覚えた人は危険だ。

へぇー、送信元のメールアドレスがいつも送られてくるアドレスと似てたら、うっかりしちゃいそうだね。
図1: イーバンク銀行の「よくわかるイーバンクナビ」の一シーンより引用

おいおい、「メールアドレスが似てたら」って……、似てるとかいう問題じゃないじゃろが。同じだったらいいっていうの?

イーバンクではフィッシング詐欺対策として、URLの最初が必ず https://fes.ebank.co.jp であることを確認できるようにアドレスバーを表示してくれるし、
図2: イーバンク銀行の「よくわかるイーバンクナビ」の一シーンより引用

それじゃ駄目じゃろが。「/」まで確認しないとだめじゃろが。実際、「フィッシング詐欺サイト情報」の7月28日のエントリに報告されているように、

● ebay.comの偽サイト 以下のように複数あります
ttp://signin.ebay.com.WMRgh.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.8TFfB.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.fr43S.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.e1aRQ.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.6dzPj.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.u9kwr.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac
ttp://signin.ebay.com.ePbr9.aw0confirm.com/sc/ebay/index.php?eBayISAPI.dll=nouac

フィッシング詐欺サイト情報, 2006年7月28日

「http://signin.ebay.com」で始まることを確認したってだめなわけで、「.com/」まで見ないといけない。

メールの送り主はちゃんと確認しないとね。
図3: イーバンク銀行の「よくわかるイーバンクナビ」の一シーンより引用

だからさー、どうやってメールの送り主を確認するわけ?

素人に作らせるとこうなる。というか、このアニメーションを作らせるのに使われたと思われる元の解説からして間違っている。

・URLの最初が、「https://fes.ebank.co.jp」であることをご確認ください。

フィッシング対策, イーバンク銀行

とにかく、イーバンクがメールで個人情報をきくことはないわ。だから、そういうメールがきた時点で、まず疑うことね。
図4: イーバンク銀行の「よくわかるイーバンクナビ」の一シーンより引用

「イーバンクがメールで個人情報をきくことはない」ですって? どうしてそういう事実に反することを平気で言うのかね。

送信されてきた通知メールの本文中に記載されているURLをクリックすると、受取方法選択の画面が立ち上がるの。「○○○○様からの送金の受取手続きは下記のURLを押してください」http://www……………/
図5: イーバンク銀行の「よくわかるイーバンクナビ」の一シーンより引用

自分でそう言ってるわけで。どうしてこうデタラメなんだ。しかも、画面のURLがニセくさいURLになってるし。

三菱東京UFJ銀行の要領を得ないセキュリティ解説

東京三菱UFJ銀行の「「三菱東京UFJダイレクト(旧東京三菱)」ご利用時に真正なサーバーであることを確認する方法について」の出来も悪い。

なぜか「/」の前に空白を入れているという雑ぶりはともかくとして、どうでもいいパス名部分まで覚えさせるつもりなのか。「mufg.jp」だけが要点だってことをなぜ言わないのか。

別のページの「金融犯罪にご注意ください」でもこうだ。

【三菱東京UFJ銀行のSSL(暗号化通信)証明書】
・三菱東京UFJ銀行のドメイン名は「bk.mufg.jp」です。証明書の「発行先」は「www.bk.mufg.jp」「www02.bk.mufg.jp」「direct.bk.mufg.jp」のように、「bk.mufg.jp」で終わっています

なぜ「bk.」まで入れるのか? なんだか、基本的なことがわかってないらしい*1

「簡単!やさしいセキュリティ教室」にS/MIMEの解説

簡単!やさしいセキュリティ教室」に、「電子メールが本物であることを確認するしくみ」というコラムが追加されていた。

よくできている。

*1 mufg.co.jp ではなく、mufg.jp などという信頼性の低いドメイン名を使っているのも不用意だ。mufg.co.jp が既に第三者に取られていたからなのだろうが、ならばなおさら危ないわけで。新会社の名前を決めるときにドメイン名を取れるかを考慮に入れなかったのか。

本日のリンク元 TrackBacks(7)

2006年08月06日

銀行スパイウェア犯と同じ手法でWindows XP SP2の警告を回避する警察庁電子申請システム

政府が整備を進める電子申請システムにおいて、中央官庁の大半がオレオレ証明書を使用し、オレオレ認証局をWebからダウンロードしてインストールするなどという不用意極まりない習慣を国民に植え付けようとしていたなか、警察庁だけは当初から違う対応をとっていた。

警察庁の電子申請システムはオレオレ証明書を使用しているものの、「警察庁認証局」のルート証明書をCD-ROMで入手しなければならないことになっている(第三種オレオレ証明書)。

警察庁認証局の自己署名証明書(ルート証明書)の入手

インターネットを利用して警察庁へ電子申請をしようとする場合には、通信の安全性を確保するために事前に以下の窓口に問い合わせて警察庁認証局の自己署名証明書(ルート証明書)を入手して下さい。

入手方法はCD-Rの手渡し又は、郵送による方法を用意しています。

国家公安委員会 警察庁 電子申請・届出システム 事前準備

素晴らしい。

ところがだ。4月に「署名用ソフトウェアのインストーラの更新について(平成18年4月21日)」という通知が出ていた。それによると、署名用ソフトウェアが更新されたからダウンロードせよという。

下記より、署名用ソフトウェアをダウンロードしてください。

https://www.shinsei.npa.go.jp/ars/downloads/syomei.zip

署名用ソフトウェアのインストーラの更新について(平成18年4月21日) , 警察庁

この .zip ファイルには「警察庁電子申請・届出システムセットアップ.exe」という1個のファイルが格納されている。これに、電子署名(コード署名)がされていないのだ。

図1: 「警察庁電子申請・届出システムセットアップ.exe」が電子署名されていない様子

署名しない理由がわからない。せっかくオレオレ認証局をCD-ROMで事前に設定させているのだから、無料で好き放題にコード署名でもなんでも署名しまくりのはずなのに、なぜか署名していない。

署名を確認できない .exe ファイルの実行が必要になっているため、せっかく第三種オレオレ認証局証明書をCD-ROMだけで提供して守ってきたものが水の泡になって台無しだ。*1

しかも、中身が1個のファイルなのになぜかわざわざ .zip でアーカイブされている。.zip なので、Windows XP SP2でも、ダウンロード時に警告が出ない(ダウンロード前の確認では青色のアイコンの画面(図2)となり、「開く」を選択しても警告が出ない)。

図2: .zipファイルをダウンロードしても警告が出ない様子

そして、開いた .zip の中にある「警察庁電子申請・届出システムセットアップ.exe」のアイコンをドラッグしてウィンドウの外に出して起動すると、署名がないとの警告が出ない

Windows XP SP2のセキュリティ機能を回避して .exe ファイルの起動で警告が出ないようにするため .zip でアーカイブして配るというこのテクニックは、昨年の夏に発生した「インターネットバンキング利用者を狙ったスパイウェア」事件で、犯人がスパイウェアを被害者に実行させやすくするのに使ったテクニックと同じである。

(略)しかし、スパイウェアは約10日前の6月25日、T社長のPCへ侵入していた。経営するオンラインショップに届いたある問い合わせメールと共に入り込んでいたのだ。

件名:破損の件!
先日、スクエアテーブルを購入致しました○○です。 到着時、梱包が少し潰れていたので、もしかしてと開封すると割れてはいませんでしたが、ボードにヒビが入っていました。返品交換等の対応は可能でしょうか?参考に到着時の写真を送ります。ご連絡、お待ちしています。○○

写真とされる添付ファイルには、Zipで圧縮された実行ファイルが入っていた。素早く対応しなければと、T社長は添付ファイルをクリックした。しかし、写真は存在せず、購入者リストにも○○の名前はなかったので、そのままになっていた。

「防ぎようがなかった……」、ネット銀不正引き出しの被害者語る, ITmediaニュース, 2005年7月22日

図3: 事件を伝える日経新聞の記事, 日経新聞2005年7月14日朝刊社会面

政府機関は政府の電子申請システムを使えない

内閣官房の「政府機関の情報セキュリティ対策のための統一基準」は次のように定めている。

5.3.3 ウェブ

遵守事項

(2) ウェブの運用時

【基本遵守事項】
(a) 行政事務従事者は、ウェブクライアントが動作する電子計算機にソフトウェア をダウンロードする場合には、電子署名により当該ソフトウェアの配布元を確認すること

政府機関の情報セキュリティ対策のための統一基準(2005 年12 月版(全体版初版))

したがって、政府機関の行政事務従事者は上の「警察庁電子申請・届出システムセットアップ.exe」を開くことはできない。

各省庁が、電子申請システムの利用にあたってインストールを必須としている配布物について、電子署名されているかどうか調べてみたところ、大半が署名していないか、不適切な署名になっている。

これらの .exe ファイルを開く行為は、「政府機関の情報セキュリティ対策のための統一基準」に違反する。

せっかく購入した証明書をまるで無駄にする新潟県

それに比べて新潟県は、電子申請システムで配布している「新潟県申請・届出システム クライアントモジュール」にきちんとしたオレオレでない証明書でコード署名をしている。(VeriSign Class 3 コード署名認証局発行の証明書による署名。)

図4: 新潟県電子申請システムがが配布するプログラムに適切な電子署名が施されている様子

ところがだ。配布ページで配布されているファイル「ClientCS.exe」はこれではない。

「ClientCS.exe」はいわゆる自己展開型アーカイブ形式のファイルで、実行すると図5のように、「setup.exe」という1個のファイルが現れるようになっている。

図5: 配布されている「ClientCS.exe」を実行すると現れる「setup.exe」

なんのためにアーカイブファイルにしているのかさっぱりわからない。サイズを比べても、4.91 MBのファイルがたかが 4.66 MBになっている程度で、圧縮する意義なぞない。どんなファイルでもとりあえず「自己解凍」ファイルにしないと気がすまない時代遅れのパソコン通信マニアが作っているのだろうか。

そして、配布されている「ClientCS.exe」は署名されていない。

図6: 新潟県の配布物が電子署名されていない様子

署名を確認するには、署名のない .exe を一か八か実行しないといけない。いったいなんのために証明書を購入したのか?

日本の恥:アップデートプログラムに電子署名しない日本のパソコンメーカーたち

民間はどうか。

Windows XP SP2がリリースされてからまもなく2年が経とうとしている。当時は、ダウンロード時の警告機能が変わるということで、パソコンメーカーがユーザに告知をしていたものだ。

こうした釈明でお茶を濁すのではなく、発行者を証明する署名をするように改善することがメーカーに求められていることは言うまでもない。MicrosoftがWindows XP SP2で機能改善することによって、そのように各社に促したわけだ。

2年間の猶予を経て、パソコンメーカー各社がどうなっているのか現状を調べた。各社が販売するパソコン用のアップデートモジュールの配布サイトについて調べ、できるだけ新しく配布されているファイルについて確認した。

ソニー以外の国産メーカーは全滅だ。そして、外資系は全部が署名している。

もし外国がパソコンの調達で「アップデートプログラムに電子署名があること」を要件に入れるようなことがあれば、これは非関税障壁となりかねない。

それ以前に、日本政府は「政府機関の情報セキュリティ対策のための統一基準」で、「電子署名により当該ソフトウェアの配布元を確認すること」としているのだから、ソニー以外の国産パソコンを購入すると、オンラインアップデートできなくなる。今すぐ、調達要件に「アップデートプログラムに電子署名があること」を入れて、国内メーカーの改善を促すべきだろう。

横並びで誰もやらない。まったく日本の恥だ。

追記

Toshiba Americaのダウンロードサイトを調べたところ「TOSHIBA AMERICA INFORMATION SYSTEMS, INC.」で署名されていた。Fujitsuは署名していない。

*1 上のダウンロード画面でリンクされている syomei.zip のURLは https:// になっている。https://www.shinsei.npa.go.jp/ はオレオレ証明書で運用されているものの、ここの利用者は事前にCD-ROMで入手した警察庁認証局のルート証明書を設定しているはずなので、SSLによって改竄されることなくダウンロードすることができるはずだから、これでよいのだという考えなのかもしれない。しかし、本当に https:// でダウンロードされたかどうかを確認することができない。なぜなら、リンク元のダウンロードの画面が http:// だからだ。このページが攻撃者によって改竄されていれば、リンク先も http:// に変えられてしまうだろう。そして、ダウンロードする .exe ファイルも偽物に改竄されてしまう(関連事例:「SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも」)。もちろん、ユーザが自力でリンク元のダウンロードの画面でアドレスバーのURLを編集して https:// にしてアクセスしなおして、安全を確認の上でダウンロードすることはできる。しかし、ユーザにそのような習慣付けを求めるのは酷である。「個人情報やパスワードを入力する前に見ている画面が https:// であることを確認すること」という利用の鉄則はどうやってもユーザが覚える以外にないが、ファイルのダウンロードについてまでそれを必須とするのは、ルールの増やしすぎだ。それよりも、ダウンロードした .exe ファイルの起動時にコード署名を確認するというルールで統一するべきである。Windows XP SP2 で、ダウンロードファイルの署名の確認が自動的に行われるようになったのだから。

本日のリンク元 TrackBacks(2)

2006年08月10日

飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき

CAPTCHA*1が基本的に荒らし対策目的で使用されるものであることは以前にも書いた。ユーザビリティの犠牲が少ないものは早いうちに破られるし、改良してもイタチごっこになることも目に見えている。それでもなお活用する意義があるのは、使用目的が荒らし対策だからだ。新規ユーザ登録や、ログインなしでできるコメントやトラックバックなど、元々自由に利用させる機能である限り、完全に防ぐことはできないのであり、たとえ将来破られる可能性があろうとも何もしないよりはましだというわけだ。(荒らしがよりハードルの低いところへ行ってくれることを期待できる。)

そのようなCAPTCHAは、日本ではあまり普及していないようだ。荒し行為が英語圏での状況ほど深刻なものになっていないためか、あるいは、イタチごっこになることが目に見えている技術の採用を嫌う国民性があるのかもしれない*2

そんな日本で最近、三井住友VISAカードがCAPTCHAの仕掛けを導入していた。

以前はこの仕掛けはなかったが、6月下旬ごろにこの仕掛けが追加されたようだ。(何の目的で導入されたのかについては言わない。)

ところがこのCAPTCHA、独自に作ったのだろうか、作りが唖然とするものなのだ。

図1: 三井住友VISAカードがCAPTCHAもどきを使っている様子

1桁目の「9」の画像と2桁目の「9」の画像が全く同一だ。3桁目と4桁目の「0」も同一だ。リロードしていろいろな数字を出してみると、ひとつの数字に1つの画像しかないことがわかる。

図2: 三井住友VISAカードのCAPTCHAで現れる数字画像のパターン

しかもこの画像は一枚板なのではなく、枠線の部分で分離している4枚のバラバラの画像なのだ。(図3は、JavaScriptでブラウザ上のtable要素の大きさを変更して表示した様子。)

図3: 三井住友VISAカードのCAPTCHA画像が文字ごとに分離した画像の並びで構成されている様子

つまり、数字一文字は一つの画像データに一対一対応している。したがって、画像データの適当なバイト位置(gif形式なので最初の何バイトかをスキップした位置)の1バイトを調べるだけで、表示されている数字が何かを特定できてしまう。人工知能はいらないし、文字認識もいらないし、画像処理さえいらない。

これを作った奴は CAPTCHAが何なのかまるでわかってない*3。この曲線は何なの? 雰囲気作りかい?

図4: CAPTCHA風味を醸し出す曲線

飾りじゃないのよCAPTCHAは。カウンタと違うのCAPTCHAは。

図5: カウンタの例 (ハバネロたんカウンターより)

CAPTCHAなのに数字だけ4文字というのも弱すぎる*4

コメントspamやトラックバック荒らしを防ぐならこの程度のものでも効果が出ることもあるだろうが、三井住友VISAカードのこのCAPTCHA導入の目的は荒らし対策ではない。この目的でCAPTCHAを使うのはよくない。その理由は今はここでは言わない。まともなセキュリティコンサルに相談して、根本からセキュリティを考え直したほうがよい。

CAPTCHA機能の発注仕様をどうするか

CAPTCHAを導入するにあたって、Yahoo!やMicrosoft PassportやGoogleなどのように自社で開発する場合には、たとえイタチごっこになっても、必要なときに必要なだけ自社で改良を加えればよいわけだが、外注で作らせた場合は、破られたときにほいそれと改良するわけにはいかないだろう。

発注の際、仕様に「○○機能にCAPTCHAを備えること」とだけ書いたのでは、雰囲気だけ真似た紛い物を納品されかねない。それを防止するようにキチンと仕様を明確に記すとしたら、何を書けばよいのだろうか……。CAPTCHAの強度を示す基準といったものはまだない。

Microsoft ResearchのKumar Chellapilla氏らが、様々な方式のCAPTCHAの攻撃耐性について調べ、強いCAPTCHAの作り方について探求した論文が以下にある。Microsoft Passportで使用されているCAPTCHAに応用されているそうだ。

*1 「CAPTCHA」はCMUのtrademarkだそうだ。CAPTCHAを含むより一般化された概念が「Human Interactive Proofs (HIPs)」と呼ばれている。

*2 私もあまり好きでない。

*3 もしくは、受注した仕事を故意に雑に済ませたか。

*4 これは発注元の指示によるものと想像される。

本日のリンク元 TrackBacks(100)

2006年08月12日

流出した暗号化ファイルと傍受された暗号化通信データの違い

少し前に武田さんが、

  • 個人情報の暗号化通信は漏洩にあたるか?, 武田圭史, 2006年6月10日

    (略)では逆に128bit SSL相当あるいはそれ以上の強度で暗号化したファイルを紛失した場合において、その事実を公表・謝罪する必要があるのかという疑問が生まれる。

    紛失したファイルを第三者が拾得した場合と、暗号化した通信を第三者が傍受する場合のどちらのリスクが大きいかということになるかとは思うが、実際のところインターネット上での個人情報の暗号化通信と、暗号化された個人情報ファイルの紛失の差異について、どのような認識が一般的なのだろうか。

という疑問を呈されていた。

企業が個人情報ファイルを紛失した際に、単に「暗号化していますので問題ありません」で済まされないのは、まず、少なくともどんな暗号アルゴリズムを用いていたかを明らかにしなければ、客観的に「問題ない」とはできないからだ。そして、お墨付きの暗号アルゴリズムを使用していたとしても、鍵の作り方がどうなっていたかと、鍵の管理をどうしているのかを明らかにしなければならない。

SSLとの対比で言うと、SSLでは通信データ(ハンドシェイク完了後の)の暗号化に用いる鍵に、

  1. 鍵の生成方法がSSLのプロトコルとして規定されている。
  2. 鍵はセッション終了時に消去される。

という性質がある。

これに対して、一般的に行われているファイルの暗号化では、まず鍵の生成方法は自由であり、鍵ファイルの保存を必要としないものでは、パスワード(人間が思い浮かべた文字列)をそのまま鍵にしているものがあるし、パスワードと暗号化用ソフトウェア内蔵の鍵(リバースエンジニアリングによって判明し得る)から生成しているものもあり、それらでは、どんな暗号アルゴリズムと鍵長を用いようとも、強度はパスワードのレベルまで落ちていると見なされるだろう。

次に、鍵ファイルを保存する方法の場合、鍵の生成方法まで規格化されたものを使用すればよいが、鍵ファイルを秘密にしておかなければならず、それが同時に流出している可能性があるならば、鍵ファイルの使用にパスワードを要求するようになっていても、安全性はパスワードのレベルだと見なされる。

SSLが信頼されているのは鍵がセッション終了時に消去されるところにポイントがある。一般に、通信の暗号化では鍵は短期間で捨てられる(ようにプロトコルを設計できる)のに対し、ファイルの暗号化では、その目的上、いつかそのファイルを復号しなくてはならず、それまで鍵を捨てずに温存しておかざるを得ず、どうやってもそこが通信の暗号化にはないリスクとなる。*1

「SSLは許されるのに、暗号化ファイルは許されないの?」という疑問に対する答えは、安全であることの信頼性について、暗号化ファイルがSSL通信並みになることは、それがいつか復号されることを予定しているものである限り、あり得ないからということではないか。

そうすると、暗号化された個人情報ファイルを流出させたときに謝罪しなくてよいためのひとつの条件として考えられるのは、「そのファイルはもう復号することを予定しておらず、鍵を消去している」と示すことではないか*2。そのような場合があるかというと、鍵は安全に消去したが、なぜか暗号化ファイルは消さなかった(もしくは、安全に消去できていなかった)という場合があるかどうかだ。

Windows XP SP2の同時接続数制限

という記事が出た。すばらしい。私も「Winny稼動コンピュータ数調査の追試をしてみた」では、SP1を使わざるを得なかったのだが、早速「BIOT」を使わせていただいたところ、SP2でも、SP1のときと同じ性能を得ることができた。

*1 ただし、ここでは流出が起きるような事態を想定しているので、通信の暗号化においても、通信の端点(サーバ)から流出が起きる場合を考慮しないと公平でない。まず、セッション鍵がサーバから流出するケースでは、そのタイミングで生きているセッションの通信が傍受されたときに復号され得ることになるが、元々その場合は、サーバ内で復号されたばかりのデータも流出し得るのだから、それは暗号化の問題ではない。次に、(訂正)セッション鍵の交換に使われる秘密情報(たとえば、RSAを用いる場合の秘密鍵が流出した場合を検討すると、流出以降の暗号化通信は安全でないものとなるが、流出以前に行った暗号化通信については、安全である(傍受された通信データは復号されない)と見なすことができる。

訂正(8月30日) 脚注1にミスがあったので訂正。Diffie-Hellman + RSAを想定していたはずだった(DHE-RSA-*)。この場合RSA鍵は認証に用いられ、それが流出するとman-in-the-middle攻撃によりそれ以降の秘密が損なわれる件を言いたかったつもり。しかし……(つづく)

*2 暗号化アルゴリズムと鍵生成の方法にお墨付きのある規格化されたものを用いていたことを示し、かつ、消去するまでの間の鍵の管理体制が適切であったことを示すのに加えて。

本日のリンク元 TrackBack(1)

2006年08月13日

RFIDタグ搭載ランドセルの校門通過記録で仲良しグループを割り出すという小学校教諭の発想は普通?

論座2006年8月号に「IT技術は小学生を守るか」という記事が出ていた。これに次の記述がある。

立教小学校(略)の「登下校管理システム」は、ICタグを用いたセキュリティーシステムの草分けだ。(略)導入を進めた石井輝義教諭(情報科主任)は「動機は、どちらかというとセキュリティーよりも利便性にありました」と語る。(略)

「教師の仕事の一部を肩代わりしてもらうことで、生身の子どもと接することに集中できる」。今後はさらに、記録を時間順にソート(並べ替え)して仲良しグループを割り出す、長期欠席児童を把握するといった可能性を考えている。昨年5月の遠足では、バスに児童が乗り込んだかどうかタグで確認する実験も行った。無線LAN機能と専用ソフトを備えたモバイルPCをリーダーとして用いたという。

さらに、技術開発やシステム導入時の「議論」の重要性も強調する。(略)文系出身の石井さんたちが開発段階から加わることで、現場のニーズや社会的倫理までふまえた議論をした。「何度も手直ししました。ごく一部の技術者が専門知識を専有して突っ走られたら困りますからね」と石井さんは言う。

大内悟史, 「IT技術は小学生を守るか」, 論座8月号, p.130

この話を最初に聞いたときは「その発想はなかったわ」と驚いた。もちろん、「なるほどそういう使い方ができるのか」という驚きではなく、「本当にそんな使い方をしちゃうのか」という驚きだ。

調べてみると、この計画のことは3月の時点で既に明らかになっていた。

石井先生は、保護者の反応、今後の展開について、「保護者の安全意識が高まり、『メールによって子どもの安全を確認できるようになった』『登下校時が危険なものであると意識するようになった』という声が寄せられています。今後は登下校の記録情報によって仲良しグループのソート分けが出来るのではないかと考えています」と語る。

地域の実情にあった対応を 学校危機管理の進め方 立教小学校情報科主任 石井輝義氏, 第3回私学経営セミナー開催報告, 教育家庭新聞, 2006年3月4日号

「時間順にソートして仲良しグループを割り出す」というと、ログをExcelで並べ替えて先生が時々眺める話のようにも聞こえるが、技術的には、言うまでもなく、毎日のログを分析アルゴリズムにかけることで、各児童間の「仲良し距離」を日々刻々と求め、「友達がいない」児童を発見したり、急に「友達がいない」に変化した児童をリアルタイムに発見することができるだろう。(登下校が同時刻であることの多い児童たちを「仲良し」と見なす場合。)

正直言って私の感覚では、この発想はクレイジーだと思う。しかし、根拠を持って批判する術はない。主観的な感想でしかない。人々はこれをどのように受け止めるのだろうか。

ランドセルRFIDタグ検知システムは、立教小学校が草分けとなってマスメディアで大きく取り上げられ、今では小学校だけでなく中学校まで含む多くの学校が「実証」実験を行うようになった。それらはすべて、「子どもの安全のため」として語られているが、立教小学校の石井教諭は当初から、「セキュリティーよりも利便性」という本来の動機を隠していない。

さらに立教小学校における同システムの導入効果として、教職員の作業の効率化も評価されています。全児童の出欠日数の集計事務などが自動化されることで、大幅な時間短縮が可能になります。ITを活用してできるところは自動化し、教職員はその時間を生徒とのコミュニケーションや研究活動に利用することができるのです。「もともとこのシステムを導入するきっかけのひとつに、教職員の労力を軽減することで教えることに専念するための補助ツールがほしい、というものもありました。今回のシステムはそれを実現しながら、同時にセキュリティも向上させる仕組みであると考えています」(情報科主任 石井輝義先生)

学校にできる「安全対策」を追求して 〜アクティブ型RFIDタグで児童一人ひとりの登下校を確認〜学校法人 立教学院 立教小学校様(東京都), 富士通 文教ソリューション 導入事例

本格稼動した時点では本校の独自システムというより、より多くの学校で導入されることを切望しています。

というのも、最初に戻りますが、元々、このシステムを導入するきっかけは、教職員の労力を軽減することで“教え”に専念するための補助機器であり、同時にセキュリティも向上します。(略)

ICタグによる技術の可能性は、学校業務の軽減と言うことに関して、大きな広がりを持っていると考えています。例えば、遠足などの行事での点呼は重要であるにもかかわらず、非常に煩雑で教員の労力の多くが割かれてしまっています。このような面での運用も、今回のシステムの応用によって可能かどうかを富士通さんに提案・要望し、既に実現可能な段階にあります。このような労力を、機械によって可能なことは極力、機械化し、児童との教育的な関わりに、教員の最大の労力を割いてもらうことが、最も重要だと考えています。

労力低減とセキュリティも実現した「RFIDタグ」 児童の登下校時を完全把握で“あんしん”約束 希望者(保護者)にはメール通信サービスも 来春には全校児童で完全導入へ 立教小学校, セキュリティ産業新聞社, 2004年7月25日号

ITによる自動化で空いた時間で「生身の子どもと接することに集中できる」という話には、何か懐かしい響きがある。30年くらい前だろうか、機械化による省力化で働き口がなくなると危惧する人たちの反発の声をテレビなどで耳にしていた。そんなとき子ども心に、「機械化で空いた労働力をより人間的なサービスに注げる」という考え方に同調したものだ。「機械化で味気ない世の中になる」なんていうぼやきも当時は定番だったが、今、駅の自動改札を「味気ない」などと言う人はいない。

同じように、校門の出入り記録で交友関係を分析することも、今は違和感を覚える人が少なくなくても、何年後かには当たり前になる……のだろうか。

石井教諭は「社会的倫理までふまえた議論をした」という。

文系出身の石井さんたちが開発段階から加わることで、現場のニーズや社会的倫理までふまえた議論をした。「何度も手直ししました。ごく一部の技術者が専門知識を専有して突っ走られたら困りますからね」と石井さんは言う。

大内悟史, 「IT技術は小学生を守るか」, 論座8月号, p.130

私は、この3年間、RFIDのプライバシー議論にかかわってきて、技術者よりも非技術者の方が技術に惚れ込んでしまっている様子を見てきた。技術者にとって、IDで何ができるかは自明であり、「こんな使い方も可能」ということに感動したりしない。社会的影響や倫理的な検討をするのは、技術提供者よりも技術の使用者の役割と一般的には考えられているだろうが、技術の使用者が技術に惚れ込んでしまうような場合には、どうすればよいのだろうか。

ひとつ批判的な議論が可能なのは、校門を同時に出入りすると仲良しと見なされるようになっていることを、児童たちが知らされるかどうかという点だろう。

かざして使う非接触ICカードではなく、数メートルの距離から自動検知するRFIDタグを使う理由について、石井教諭は次のように述べている。

立教小の石井教諭は話す。

「当初は、登下校の際に児童がバーコードやICカードを校門の装置にかざす仕組みも検討された。しかし個人的な意見を言えば、それでは学校が特別な場所になってしまう。学校は生活のリズムの中にあるごく普通の場所で、自宅にいるのと同じような感覚で過ごせる場所にしなければならないと思っています。登下校の際にゲートの通過など大げさなシステムを導入すると、学校が特別な場所になって、生活から切り離されてしまうような気がします。本当は子どもたちはもっと地域の中で学んでいかなければならないし、われわれも地域に出ていかなければならない。そうしたトレードオフの中で、ギリギリの選択を考えた結果、 RFIDという使っていることを意識させない仕組みの導入を決めたんです

同校がアクティブ型タグを導入したのも、子どもたちにRFIDを意識させないためだという。交信範囲が大きいため、リーダーにかざす必要がないからだ。

佐々木俊尚, 無線ICタグは子供の安全の切り札になるか?, ASAHIパソコン, 2004年11月号

この考え方の延長だと、校門の出入り記録を仲良しの判定に使うことは児童には知らせないのだろうか。

それを事前に児童たちに知らせた場合は、何が起きるだろうか。あるいは、知らせないで運用したときに、ある日、児童たちがそのことに気づき始めた場合、児童たちはどんなことを思うのだろうか。

参考: 石井教諭の個人サイト(blogあり)

ところで、4月に、チルドレンズ・エクスプレスというところから取材を受けた。取材に訪れたのは、中2と中3の女子中学生と高1の女子高生記者さんたちだった。そのときの記事が出ている。

  • 原 衣織, 発信機をつける子供たち, チルドレンズ・エクスプレス, 2006年6月24日

    古江台中学校では、(略)横内校長は43000平方メートルという広大な敷地と、学校近辺での変質者の出没などからICタグ導入の必要性を考えたという。生徒達自身は嫌がるのではないのかという質問には「自分の身の安全は自分で守るのが基本だという指導をしている。しかし中学生というのは親の保護と子供の自立がちょうどクロスする時期だから、地域の人々の支援とICタグ技術によるサポートが必要だ」と答える。生徒にとったアンケートでは「嫌だけれど、変質者などがいる以上仕方がない」という答えが多かったようだ。また、保護者にとったアンケートでは、ほとんどの人が肯定的だったという。

大阪の吹田市の公立中学校で行われていた実験を取材してきたとのことで、生徒たちの声も聞いてきたのだそうだ。

生徒は先生のいないところで本音を漏らすという。嫌だという声があるらしい。それが表に出てくるときには、「嫌だけれど、変質者などがいる以上仕方がない」という両論併記的な意見になってしまうようだ。優等生ほどそう答えるだろう。「嫌だけど、仕方がない。」子ども達がほんとうに何を感じているのかをうかがい知るのは難しい。

「とりあえず、嫌なこと、感じたことはちゃんと主張しておこう」、私はそう彼女達に伝えた。

本日のリンク元 TrackBacks(24)

2006年08月17日

欧米のプライバシー観はキリスト教的宗教観に基づくもの?

「ICタグ ランドセル」で検索していたところ、次のページにたどり着き、目が点になった。

  • 学校自慢 立教小学校, 「お受験させるか、させないか」こどもの進路を考えるサイト

    立教小学校の学校自慢は
    「キリスト教にもとづいた愛の教育とICタグによる登下校監視システム」です。

一瞬目が点になったのは、これを

「キリスト教にもとづいたICタグによる登下校監視システム」

と空目したからだった。

というのも、

というニュースを目にしたことがあったからだ。

私は信仰する宗教がないし、教養としての宗教にも無関心なまま生きてきたので、一般的なキリスト教徒にとって「獣の刻印」というものがどのようなものなのか知らない*1

これまで何度かRFIDのプライバシー問題について講演を依頼されてお話をしてきたが、質疑応答で、「欧米がプライバシーに敏感なのはキリスト教的な感覚によるもので、日本人には関係ないのでは?」というような質問を受けることがある。

そうしたとき、宗教について無教養な私にはその点の真偽について答えることはできないのだが、それ以外の要因(米国と日本のプライバシー問題への声の違いを生んでいる要因)の可能性として、次のことがあるのではないかと答えるようにしている。

米国では、ID番号が実際にプライバシーの問題を引き起こしているために、何が問題なのかが広く市民に理解されやすくなっているのではないか。Social Security Numberは、民間においても広く用いられ、不適切なことに認証のための秘密キーとしても使われてしまう現実*2があり、他人に番号を使われるなどの被害が問題となっていたし、昨今「スパイウェア」に分類されて問題視されるようになったadwareやtrackwareは、英語圏で蔓延して問題視されるようになっている。

対して日本では、最近まで制度的にも実質的にも国民番号はなかったし、住民票コードが導入されたときにも、住民基本台帳法でその民間利用を禁止したため、そうしたID番号の不適切な利用が防がれてきており、問題が顕在化していない。問題が顕在化しないことはよいことであり、それが求められる目標であるが、その結果として、ある種の人たちにどんな問題が起こり得るのかを理解する機会を失わせていると考えられる。

また、日本では、adwareやtrackwareを用いたビジネス行為はほとんど見られない(第三者cookieやWebバグによるものを除いて)。米国では、お金になることは違法でなければなんでもやるというビジネス風習があるのか、トラッキングによるプライバシー情報をお金に換えるビジネスの追求が進んでいて、スパイウェア問題が行き着くところまで行っている感じなのに対して、日本では、「スパイウェア」の問題というとほとんど「キーロガー」でパスワードを盗んで不正アクセス行為をはたらくことを指しており、IDトラッキングによるプライバシー問題とは性質が違っている。日本では、アンダーグラウンドで詐欺や詐欺まがいの行為をはたらく者たちはいるものの、表立って堂々とtrackwareやadwareでビジネスするといった、違法ではないが倫理的に非難されかねないようなやり方をする会社というのは出てこないのかもしれない。その結果として、ID番号によるトラッキングの問題を理解する機会を失っているかもしれない。

また、Pentium IIIのプロセッサシリアル番号のプライバシー問題や、Windows Media Playerの「SuperCookies」問題、Microsoft Passportに対する批判としてのLiberty Allianceの考え方など、これらグローバルユニークIDを用いた情報システムのアーキテクチャ設計がプライバシー上の問題をもたらすという批判は、いずれも英語圏で議論され、日本ではほとんど議論がなかった。これは、インターネット関連の情報システムのアーキテクチャ設計のほとんどにおいて、日本が蚊帳の外に置かれていたからだろう。

日本社会で問題が顕在しないことは良いことであるが、情報システムを設計する者、またそれを指示する立場の者たちが、この問題に疎いままだと、日本で設計したアーキテクチャが、プライバシー問題を理由に欧米での採用を拒否されるという事態が起きかねないという懸念はある。

*1 昔、自分の自家用車のナンバーが「667」だったとき、友人に「一番違いでぞろ目だったのに」と自慢したところ、「それサタンの数字じゃん」と言われて意味がわからなかった。

*2 Simson L. Garfinkel, Risks of Social Security Numbers, Communications of the ACM, Volume 38, Issue 10 (1995).

本日のリンク元 TrackBack(1)

2006年08月18日

一日中幼児たちの映像を不特定多数に公衆送信している保育所

  • 子ども守るIT ――学校で駅で街で, 朝日わくわくネット, 2005年9月28日

    ネット中継 幼稚園での笑顔満開/職場で家で親安心

    (略)こうしたシステムでは、保護者らには専用パスワードを配布して映像が見られるようにするが、権限のない部外者には映像を見せないのが普通だ。しかし、同保育所は「保育所に興味を持ってほしい」と、一般にも映像を公開している。もっとも、子どもの安全を守るため、カメラのズームアップはできないようにしており、保護者でもない限り、映像で子どもの見分けはできない。

という記事があった。「西脇保育所」で検索してみると見つかった。

たしかに、誰でもライブ映像を見られるようになっている。今見たところ、プールから出た女児たちが全裸になって着替えている様子が映っていた。

「映像で子どもの見分けはできない」というが、どういう意味なのだろうか。普通に顔が見えるのだが。これをどう見るかは人それぞれだと思うが、親御さんたちはこのことを承知しているのだろうか。インターネットも携帯電話も使わない親は知る由もないかもしれない。携帯電話で見ている親は「自分はアクセス権限があるから見えている」と思い込んでいるかもしれない。

「保育所に興味を持ってほしい」というのはどういう意味なのだろう。先生達は一日中見られてたいへんだなあと思う。

追記(19日)

当該ページは、19日午前9時ごろ、Basic認証による利用の制限が課され、誰でも見られる状態ではなくなった。

これは事故で公開状態にあったのではなく、保育所の意思によって公開されていたものであることは、昨年の朝日新聞社の記事で「同保育所は「保育所に興味を持ってほしい」と、一般にも映像を公開している」と書かれていることから明らかであろう。

憶測するに、朝日新聞の記者は、「これはまずいのではないか」と思って取材したのではないだろうか。しかし取材で、「カメラのズームアップはできないようにしている」、「保護者でもない限り、映像で子どもの見分けはできない」と言われてしまえば、これを問題視するような記事は書けないのだろう。「権限のない部外者には映像を見せないのが普通だ。しかし」との一文を入れるのが精一杯だったのだろう。「あとは読者が判断してくれ」ということなのだろう。

監視社会化させるIT利用の拡大に疑問を持ちつつ取材するジャーナリストたちは少なくない(私もそうした方々の取材を受けることがある)はずだが、「○○ですから」と言われたらそれ以上踏み込めないというマスコミの体制ができあがっているように思える。

ところで、この保育所が「無断リンク禁止」を掲げるようにならないかと心配だ。言うまでもなく、「リンクお断り」と主張することで管理責任を果たしたことになることはない。

ちなみに、当該ページのURL(http://nishiwakins.jp/camera/)でGoogle検索してみたところ、2ちゃんねる掲示板のコピーらしきページが見つかった。

そういえば、一時期、意図せず公開状態になっていると思しきライブカメラを検索で探す行為が流行っているのを見た記憶がある。特にパナソニック製のネットワークカメラで、デフォルトで表示される画面の文字列で検索するなどすると、なぜこれが一般公開されているのか理解できないような監視カメラ映像が公衆送信可能化されているのが大量に見つかるということがあった。当時、アクセス制限の設定方法を説明するマニュアルに原因があるのではいかとの疑いを持ったが、調べていない。

本日のリンク元 TrackBacks(2)

2006年08月19日

脆弱なRFIDタグが電波信号的に複製される件を伝える報道映像がYouTubeに

去年話題になった「認証用RFIDタグの暗号が破られ、なりすましの危険性が実証」のJohns Hopkins大学のデモンストレーションを伝えるABC Newsの映像が、YouTubeで見られる状態になっている。

もうひとつあった。KIRO-TVというシアトルの放送局らしい。

さらに、今年、VeriChip電波信号的に複製できたという話があったが、その実演をしたJonathan Westhues氏が電気錠を開ける様子を紹介するABC Newsの映像もあった。

やればできる(ものもある)ことは技術者にはわかりきっているとはいえ、やはりこのように実演して映像でマスメディアが取り上げないと、肝心な人(技術に惚れ込みやすい非技術者)たちに、問題の存在を認識してもらえないのではなかろうか。

ちなみに、日本では最近どうなっているかというと、5月に次のコラムが出ていた。

  • 林 光一郎, 米国の著名雑誌で反ICタグのプライバシ特集、足りないオープンな議論, 日経 IT Pro

    Consumer Reportの記事で触れられていないものも含め、ICタグの利用にはプライバシ上の課題が多く残っていることは厳然たる事実だ。それらの課題を明確にしたうえで、今使うのか使わないのか、どのような規制をどのようなレベルで導入するか(民間のガイドラインか法律か、法律なら罰則はどのようにするのか)といったことをオープンに議論する必要がある。そしてICタグ業界はその議論が不利なものであっても積極的に主導する覚悟が必要だろう。現時点では日本の ICタグ業界は米国よりバランスの取れた対応を行えていると思う。が、個人情報保護法への過剰とも思える反応を思うと、米国の状況は日本にとっても他人事ではない。現時点で大きな問題になっていないからといって「触らぬ神にたたりなし」ではなく、今だからこそ活発なプライバシ議論が行われるべきだと思う。

日本のICタグ業界の「バランスの取れた対応」というのは、具体的にどのへんのことですか? (μ-Chipを電気錠に使わないようにいていることとか?)

議論などしなくても「議論が必要」と言えば満足。それがいつもの日本。

オープンな議論というとこれ一回きりだったと思う。

本日のリンク元 TrackBack(0)

2006年08月29日

金子勇氏の正直な人柄を垣間見られる映像

金子勇氏には1月のこのイベント*1のときにお会いしたので、私としては既にどんなお人柄かは肌で感じていてたが、映像として見られる金子氏というと、4月14日の報道ステーションの放送と、6月13日の毎日放送のニュース番組「VOICE」での放送があるものの、これらはいずれもシナリオどおりに編集された内容なので、金子氏の人柄というのはなかなか見えてこないものだった。

ところが、7月25日付のマル激トーク・オン・ディマンド(有料)でネット配信されている「Winnyは悪くない」での出演では、無編集に近い形で生の発言が収録されているので、彼のお人柄を垣間見ることができる。

特に興味深かったのは、1時間19分28秒あたりから始まる「SkeedCast」に関する話題の部分だった。

司会の神保哲生氏が「SkeedCastというのが、今えー、これは何なんですか?」と話題を振ると、金子氏は「厳密に言うとWinnyとはまた別のソフトウェアではあるんですが、Winny 1を作っていたときにどうにかこれは商用にならないのかっていう(略)」と、説明を始める。

「コントロール可能なWinnyっていうものを作れないのかっていう試みでやっているということです」と説明したところ、神保氏から「これはじゃあやはりファイル共有ソフト?」と聞かれたところで、金子氏はこう答える。

「うーん厳密に言うとファイル共有……共有としても使えるんですけど、どちらかというとですね、peer-to-peerよりは、こちらの、クライアントサーバー方式に近寄っているんですよ。正確に言えば。技術的には戻っているところもあるんでしょうけども。

この直後の彼の顔の動きが興味深い。

さらに少し続いた後のところで、宮台氏が「サーバの部分にこの仕組みを入れるんだ」と発言すると、「ある意味ハイブリッドです」と金子氏。そして少し続いた後、神保氏が「それはまた、キャッシュサーバという考え方とは違うんですか?」と言い始めたところで、金子氏はすかさず、

あいやあの同じです。実は実はただのキャッシュサーバなんです。技術的にはただのキャッシュです。はい。

と応じている。*2

実に正直だ。工学博士であることを忘れていない様子だ。

*1 ちなみにこの記事によると、私が

高木浩光氏は、Winnyの問題は、アーキテクチャそれ自身ではなく、ユーザー側が自覚のないまま著作物ファイルを中継し、著作権法に違反しえたことにあると指摘する。高木氏は「開発者側は、Winnyの利用が著作権違反につながる可能性があることを、ユーザーに分かりやすく告知すべきだった」と話す。
と発言したことになっているが、これでは私の本意が読者に理解されないだろう。私が述べたことは、「ユーザーが自覚のないままファイルを中継」という結果を招くように作られたアーキテクチャが問題だということであり、(このパネル討論では倫理についての議論だったので)倫理的に問題があるとすればどこなのかを東さんから追及されたところで、ひとつ結論として述べたのは、自覚させないような仕組みにしたことは、いわば、大衆ユーザ(コアなユーザではないユーザ達、たとえば利用教唆本で使い始めるような人たち)が騙される(Winnyの実際の機能がどういうものかということについて知らないまま使わされる)よう期待しているわけであって、そこは少なくとも非倫理的と言えるということを述べたと思う。そこを短絡して結論だけ取り出すと「ユーザーに分かりやすく告知すべきだった」となる。ちなみに、イベント終了後の飲み会の席で東さんと話していて気づいたのだが、これは、刑法改正案にある「不正指令電磁的記録等の罪」の「人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」に近い面もあると言えるのではないか。

*2 このあたりの顔色や動作にも注目。

本日のリンク元 TrackBack(0)

2006年08月30日

サイボウズが再び「闇改修」をしたので電話で抗議したが無駄骨だった

結果を先に言うと、サイボウズ社はセキュリティポリシーによって、(アカウントを持つユーザからしか攻撃され得ないなどの)危険な状況が少ない脆弱性については告知するが、第三者から攻撃され得る脆弱性については告知しない(更新履歴やFAQには書いておくが積極的に知らせることをしない)という方針で、今回も、過去もそうしてきたし、今後もそうしていくつもりなのだという。

  • 複数のサイボウズ製品にセキュリティ・ホール,情報漏洩などの恐れ, 日経IT Pro, 2006年8月28日

    (1)は,細工が施されたリクエストを送信されると,公開を意図していないファイル(公開用フォルダに置いていないファイル)を表示してしまうセキュリティ・ホール(略)

    (2)は,Office 6に関するセキュリティ・ホール(略)。細工が施されたリクエストを送信されると,ログイン・アカウントを持たないユーザーに対して,Office 6に登録されているユーザー/グループ情報を公開する恐れがある。(略)

    サイボウズによれば,同社の「ガルーン 2」および「ワークフロー for ガルーン 2」にはSQLインジェクションのセキュリティ・ホールも見つかっているという(略)

という記事が出ている。3つの脆弱性があるわけだが、サイボウズ社のホームページの「重要なお知らせ」で告知されている「サイボウズ製品で発見された脆弱性についてのお知らせ」では、

上記2件の脆弱性の問題を改修したプログラムを公開しています。 改修プログラムのダウンロード、および適用をお願いいたします。

となっており、(2)の脆弱性のことが書かれていない。

最初は問題を認識していないだけだろうと思ったので、問題点を指摘するべく電話したのだったが、「お客さま対応の責任者」に代わってもらって話をすると、これらはサイボウズ社のセキュリティポリシーに従って行っていることなのだという。

やりとりは概ね次のようになった。(前半は堂々巡りが多かったので概略。後半はメモを取りながら話したのでほぼそのまま会話通りになっている。)


私: 御社の告知では、今回の脆弱性は2つだということになっていますが、日経BPの記事を見て、実際には3つだと知りました。どうして1つを隠すのですか?

サ: 隠しているということはございません。製品のホームページ、つまりサイボウズOffice 6のサイト、これは弊社のトップページから行けますが、そこにあるダウンロードのページに「更新履歴」というところがありまして、製品名をクリックすると「サイボウズ Office 6.6 における改修内容」というリンクがありまして、そこに書いてございます。

私: そんなところは誰も見ていないのではありませんか? SQLインジェクションとディレクトリトラバーサルの件は、サイボウズ社のトップページで「重要なお知らせ」として告知しているのに、なぜこの件については同じように告知しないのですか?

サ: サイボウズ社のセキュリティに対する考え方として、セキュリティの情報を公表することは、お客さまにセキュリティの問題をもたらすことになると考えておりまして……

私: じゃあ、どうしてSQLインジェクションとディレクトリトラバーサルは告知するわけですか?

サ: SQLインジェクションとディレクトリトラバーサルについては、重要なことと捕らえましてお客さまに告知させていただいているしだいです。

私: ユーザ名が見えてしまう脆弱性は、重要ではないということですか? 私は、こっちの方が重大だと思いましたが?

サ: お客さまと弊社の認識のズレがあったようで申し訳ございません。弊社ではこのように判断したものです。

私: 今からでも遅くないので、ユーザ名が見えてしまう脆弱性も告知するべきではないですか?

サ: 最新版にアップデートしていただければ、そちらの問題も解消されますので。

私: つまり「闇改修」ということですか。定期点検の際にこっそり欠陥を直しておけば大丈夫だから客に告知はしないという、自動車の闇改修と同じじゃないですか。

サ: そのようなことはございません。更新履歴に書いております。

私: だから、SQLインジェクションとディレクトリトラバーサルと同じように、そこに加えて、ユーザ名が見える件も書けばいいのに、と言っているのですが。

サ: 繰り返しになりますが、弊社のセキュリティポリシーとして、セキュリティの情報を公表することは、お客さまにセキュリティの問題をもたらすことになると……

私: だから、なんでSQLインジェクションとディレクトリトラバーサルはトップページで告知するのかって聞いているわけですよ。危ないというなら、消したほうがいいんじゃないですか?

サ: SQLインジェクションとディレクトリトラバーサルについては、重要なことと捕らえまして……

私: だから、ユーザ名が見えてしまう脆弱性は重要じゃないから知らせる必要がないってことですか? って聞いているわけですよ。

サ: セキュリティの情報を公表することは、お客さまに……

(繰り返し)

私: SQLインジェクションとディレクトリトラバーサルの脆弱性は、「ユーザーが」とあるので、ログインした者にしか攻撃できないという意味ですよね?

サ: はいそうです。

私: 一方、ユーザの名前が見えてしまう脆弱性は、ログインしていなくても見えてしまうということですね。当然ながら。

サ: はい。

私: 私としては、SQLインジェクションもディレクトリトラバーサルも、緊急事態だとは思わなかったのですよ。なぜなら、うちのサイボウズを使っている他のユーザたちが、ログインしたうえでSQLインジェクションやディレクトリトラバーサルで攻撃するなんてことは、ないだろうと思ったからです。

サ: はい。

私: だから、最新版に入れ替える必要はないと思いましたよ。ところが、日経BPの記事を読むと、ログインしていなくてもユーザの名前が見えてしまう別の脆弱性もあるのだと。これで初めて、緊急事態だと思いましたが、あなたがたが告知しないから、この事態に気づかないままになるところでしたよ?

サ: 弊社のセキュリティポリシーとして、セキュリティの情報を公表することは、お客さまにセキュリティの問題を……

私: つまり、SQLインジェクションとディレクトリトラバーサルは、実際には危険な状況は少なめだから公表したけれども、ユーザ名は誰でも見えてしまう問題だから隠したということですか?

サ: 隠すということはございません。更新履歴での公表とするのが適切だというのが、当社のセキュリティポリシーです。

私: ところで、もう一件あるのですが、去年の3月に、「「クロスサイトスクリプティング脆弱性」の影響を受けることはありますか?」というFAQを出してらっしゃいますね? 「サイボウズ クロスサイト」でGoogle検索すれば見つかります。

(場所を説明している様子を略)

私: この脆弱性について告知をなさいましたか?

サ: 確認します。

私: それから、この脆弱性は修正されているのですか?

サ: 確認します。

私: 下の方に「警告画面を表示するよう、設定を変更することができる」とありますが、これはデフォルトでオフということですよね? 管理者が設定を変えてオンにしないとその警告は出ないのですよね。

サ: 確認します。こちらからかけなおします。



サ: この件については昨年、セキュリティ強化についてのメールマガジンを出しました。修正については、Office 6.5 で警告が出る機能を設けました。デフォルトはオフです。

私: つまり、直していないということですね?

サ: 直すといいますか、回避できるように警告が出る機能を設けました。

私: なぜ直さないのですか。

サ: 弊社の製品の問題ではなく、Internet Explorerの問題もありまして。

私: ブラウザのせいだというのですか? Yahoo!メールとかHotmailとかのWebメールは、HTMLメールを表示しますが、そのときに、スクリプトが含まれていたら排除するようにしているわけです。どこのWebメールもやっていますよ? サイボウズはWebメールでHTMLメール表示機能を追加したのに、スクリプト排除をやっていないわけです。指摘されても、直さず、警告機能を付けただけですか。

サ: ……。

私: 警告には何と書いてあるのですか? ユーザは、その警告で踏みとどまらずにHTMLメールを開くとどうなるか、理解できるのですか?

サ: 警告の内容については調べます。

私: しかもデフォルトでオフだから誰も警告機能をオンにしていないでしょ。告知をすることもなく、FAQにひっそりと書いているだけなんだから、誰も知らないでしょ。なぜ告知しないんですか。

サ: 弊社のセキュリティポリシーに沿って、脆弱性が見つかっても大きく取り上げて発表することはありません。

私: それがサイボウズ社のセキュリティポリシーなんですか?

サ: 昨年のそのときは、この対応でした。

私: 間違っていたのなら、今からでも遅くないので告知したほうがよいのではないですか?

サ: サイボウズ社としては表記等を変更をしないという見解です。

私: なぜですか?

サ: さきほどと同じで、公開することによるお客さまへの影響範囲と深刻さから判断して、どういった媒体がよいかと判断しています。

私: つまり、FAQが適切な媒体だということですか?

サ: セキュリティの強化がされたというメールマガジンを出しました。

私: そのメールマガジンにどこがセキュリティの強化なのかは書いてあるのですか?

サ: どこがセキュリティの強化なのかは書いていません。

私: じゃあ、何を書いたというのですか。

サ: 個人情報保護対策で、アドレス帳とメール機能を強化したことを書いています。

私: メール機能の強化とは何のことですか?

サ: 更新履歴へのリンクを設けていました。

私: リンクがあるだけですか。リンク先に何が書いてあるのですか?

サ: 「受信メールの添付ファイルを開くときに警告表示を出すようにしました」ということが書いてあります。

私: デフォルトでオフなのに? 添付ファイルじゃないですよ。HTMLメールですよ? FAQへのリンクを示して告知しないと、誰も設定を変更しないでしょ。

サ: それは理解していますが、それが弊社のセキュリティポリシーです。

私: 今後も、サイボウズに脆弱性が見つかっても、影響範囲に応じで、告知しない場合があるということですか?

サ: 変更履歴に書いています。

私: 変更履歴なんか告知じゃないでしょ。去年のクロスサイトスクリプティング脆弱性で、警告機能を追加したことを変更履歴に書いたとき、その意味を説明したFAQへ、リンクしましたか?

サ: FAQへのリンクはございません。

私: じゃあ誰も読まないでしょ。

サ: 「サポート」というコーナーから見つけることができます。

私: そんなとこ誰が見るんですか。社員であり、おそらくユーザでもあるであろうあなたも、さっき調べるまでこれの存在を知らなかったわけなんだし。サーポートというのは実際に問題が出てから見に行くところですよね? 「よくある質問と答え」とおっしゃるけども、 「クロスサイトスクリプティング脆弱性の影響を受けることはありますか?」なんて質問が「よくある」わけないでしょ。知らなきゃ質問できないんだから。

サ: これが弊社の案内のポリシーです。

私: 脆弱性を気にする人は、FAQの全部に目を通せということですか?

サ: 当時のFAQに関してはそういう対応になっています。

私: これは間違いだったんじゃないですか?

サ: まああのー、この対応に関してもサイボウズ社の中での方針というかポリシーとしてそういう公開のしかたにさせていただいたものです。

私: 今後も同じことをするんですか? と聞いているわけです。

サ: そこに関しては、あくまでも脆弱性が発見されたところではお客さまへの告知は必要だと考えています。公開することによって既存のお客さまに危険を与えてしまうという箇所に関しましては、大々的に公開するかどうかというところについては社内にて検討させていただくということになります。隠すということについては、弊社としては、変更履歴に記載することであくまでも隠しているというつもりはないといことで、ご理解頂ければと。

私: もう一回だけ同じことを言います。脆弱性を気にする人は、FAQの全部に目を通さなくてはいけないのでしょうか?

サ: 今後に関しましては脆弱性が見つかった段階で、アナウンスをさせていただきますので。FAQを全部見る必要はありません。

私: 脆弱性を気にする人は、変更履歴の全てに目を通さなくてはいけないのでしょうか?

サ: ……………………………………。

サ: そうですね、今回の対応ですとそうなります。

私: で、去年のクロスサイトスクリプティングですけども、変更履歴を見ればわかるんですか? 対応が必要だということが、変更履歴を見ればわかるんですか?

サ: 去年の件については、変更履歴には明確に記述されていません。

私: では、去年の件は間違いだったということですか?

サ: 間違いというのはどういう?

私: こんな方法では不適切だったということですか?

サ: そうでございますね。不明瞭なところでお客さまにご迷惑をおかけしたということで、適切な表現ではなかったと考えております。

私: 今からでも遅くないので、告知するべきではないですか?

サ: 去年の内容に関してですか?

私: はい。

サ: 去年の内容をホームページのトップへということですか?

私: はい。

サ: 去年の内容をホームページのトップへということは予定しておりません。

私: 不適切だったって言ったじゃないですか。

サ: 変更履歴に記載するべきであったが、トップページに告知することは予定していません。

私: で、どうするんですか、これから。

サ: 脆弱性というものが見つかった際には、お客さまへの通知等は必要だと考えていまして、公表する内容に関しましては、お客様への影響範囲を考えまして、ホームページにするか、メールにするか、変更履歴、FAQのどの媒体に記載するのがよいか検討してまいります。

私: いや、この去年のはどうするんですか? と聞いているんです。

サ: これをホームページからリンクをはるということは考えていません。

私: 不適切でない、問題ないからですか?

サ: 変更履歴に載せるべきだったという意味で不適切とは言いました。

私: でですよ、今から変更履歴に載せるということが考えられますが、いまから去年のバージョンアップについて変更履歴を改定しても、誰も読みませんね?

サ: そうでございますね。

私: どうするんですか?

サ: ……………………………………。えとー、今後もFAQに関してですね、えとー、なにかあのー、表示等のアナウンスなどの変更をする予定はありません。

私: では、誰が警告の設定をオンにする必要性についてついて、気づけるのですか?

サ: 今の状況ですと、FAQをご覧になられた方ということになります。

私: では私が、FAQを見る必要があることについて、みなさんに伝えようと思います。よろしいですか?

サ: どういうふうにですか?

私: FAQに色々書いてあると。しかし設定はデフォルトでオフなので、自力でオンにしないといけない。なぜオンにする必要があるのかについて、みなさんに伝えます。ホームページ等を通じて。よろしいですか。

サ: どちらのホームページですか?

私: 個人のです。

サ: 個人のホームページでですか。

私: あなた方が伝えないなら、私から、「みなさん、オンにしないといけません。警告が出ても開いてはいけません。」ということをみんなに知らせるのが、社会正義だと思いますね。

サ: 個人のホームページでお知らせされることを、弊社が止めるとか止めないという権利はないと思いますので。

私: わかりました。


一般的に言うと、こうした「お客さま対応」窓口から問題点の指摘をした場合、指摘が判断能力のある部署に伝わらないことがある。その場で矛盾のない回答をすることばかりに注力して、対応から変えなければならないような指摘に耳を傾けないということが起きがちのように思う。そこで今回も、そういう状態になっているのではないかと問い、回答を繰り返すのではなく判断のできる人と話をさせて欲しいと話したが、「自分が責任持って対応する」とのことで、何度も時間をおいて折り返し電話をもらうことになった。したがって、「当社のセキュリティポリシーに従っている」というのは本当なのだろう。

サイボウズ社は技術者たちによって起業された若い会社だと聞いていたから、こういうポリシーになることは考えにくいことだった。非技術系営業マンの判断がこうした事態を一時的に招いただけならよいものの、本当に社の方針になっているのなら、もう、安心して使えない。なにしろ、悪用の現実性が高いものは告知してもらえないというのだから。

ちなみに、「サイボウズ青野の3日ボウズ日記: セキュリティに関するお知らせ」(8月29日)に、

基本的にはイントラネットで使うソフトであり、悪意ある攻撃を受けるケースは少ないかも知れませんが、見つかった脆弱性に対しては、迅速に対応していきたいと考えています。

と書かれているが、社外から直接サイボウズを使うようにしているところは少なくない。Googleで検索してみればサイボウズのログイン画面はたくさん出てくる。

ところで、去年、日経IT Proの「記者の眼」に次のコラムが出ていた。

  • 勝村幸博, セキュリティ・ホールは公開しない者勝ち?, 記者の眼, 日経IT Pro, 2005年10月26日

    「情報は公開している」というベンダーでも,信じられないくらい“深い”ディレクトリにセキュリティ情報ページを用意しているところもある。トップページからはとてもアクセスできないようなところに置いて,「情報を公開している」と言えるのだろうか。

    あるベンダーの方からは,「どうして(わが社の製品の)セキュリティ・ホールの記事を書くのか分からない。一度,理由を聞きたいと思っている」という言葉をいただいたこともある。筆者としては,その製品のユーザーの一助になると思って記事を書いているのだが・・・。

広告で成り立っているマスコミはあてにならないのだろうか。

追記

9月1日に続きあり。

本日のリンク元 TrackBacks(2)

最新 追記

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

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|04|07|11|
最新 追記