最新 追記

高木浩光@自宅の日記

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

2007年06月01日

キンタマウイルス頒布にマスコミ関係者が関与している可能性

Winnyを媒介して悲惨なプライバシー流出事故が続いているのは、言うまでもなく、自然現象なのではなく、ウイルスを作成し頒布している者が企図するところによるものである。いったいどういう人が何の目的で作成し頒布しているかということは、憶測にしかなりようがないので、あまり多く語られることはないが、よく耳にする陰謀論的な説としては、(1)著作権侵害行為をやめさせたいと考えている者が、Winnyの利用を危険なものにするためにやっているという説、(2)ウイルス対策や流出対策の事業者の関係者が、事業の需要を創出するためにやっているという説(これは、Winny媒介ウイルスに限らず昔のウイルスのころから語られていたもの)などがある。

私の憶測では、少なくとも初期のキンタマウイルスは、単純に愉快犯だったのだろうと思う。論座2006年5月号では私は次のように述べていた。

「最新のウイルス対策ソフトを導入していれば大丈夫」というのは間違い。対策ソフトを常に更新していても、対応できないウイルスはある。ウィニーユーザーを標的にした日本独特のウイルスへの外資系の対策ソフトの対応は、どうしても後手に回らざるをえない。裏を返せば、「国産ウイルス対策技術の不在」という構造的な問題がある。ウイルスが早くから猛威を振るった英語圏では、ウイルス対策がかなり普及した。しかし日本では、「ウイルスをばらまく愉快犯は子どもっぽい」という文化的風潮があり、ウイルス発生が比較的少なかった。その結果、対策技術がビジネスとして育たなかったものと思われる。

ところが、日本でも情報暴露型のような「冷酷」なウイルスが増えている。当初は、非難の矛先がウイルス作者ではなくウィニーユーザーに向けられ、違法ファイルを欲しがる者は被害にあっても自業自得とされた。ずさんな情報管理の実態を暴いたとして、ウイルスがヒーロー扱いされる風潮さえある。しかし、悪質なプログラムを流布している者の責任は当然、問わなければならない。

最近の「ウイルス製造」には、高度な技術は必要ない。「ウィニーのアップロードフォルダにパソコン内のファイルをコピーする」というわずか1行のプログラムが情報流出を引き起こす。ウイルスは自己複製機能がないと大規模に広がらないが、ウィニー自体がウイルスの複製機能の役割を果たしてくれる。

ウイルス作成者を罰する立法の動きは、すでにある。今国会に提出されている刑法改正案には「不正指令電磁的記録等作成等の罪」、いわゆる「ウイルス作成罪」が盛り込まれている。(以下略)

ウィニー騒動の本質 あまりにも情報流出のリスクが大きい, 論座 2006年5月号

国内のウイルス被害に対する世論を見ていると、被害者に落ち度があると被害者に同情しないという傾向が、日本社会にはあるように感じられる(他の要因があってもそっちが軽視されてしまう傾向)。「喧嘩両成敗」あるいは「どっちもどっち」的な判断保留態度の文化が、個々の状況に関係なく単に思考停止の道具として使われているためかもしれない。キンタマ系ウイルスは、そうした日本の文化に根ざすよう作られていると思えた。自己顕示だけを目的とした愉快犯、例えば典型的なWebページ改竄の「○○参上」のような落書きは、日本では嘲笑の的になることは皆が知っており、そういう輩は現れない。一方、「悪いことをしている人だけが被害に遭う」ようにしておけば、作成して頒布した者への非難が避けられてしまう。キンタマウイルスの頒布者らはそれを承知でやっているのだろう。*1

しかし、キンタマウイルスの威力がもはや実証済みとなったこの2年ほどは、頒布者らの動機は別のものに移ってきているのではないだろうか。コンセプト実証としての目新しさはない。今行われていることは、漏洩事故が継続して起きるよう、キンタマウイルスの効力を維持していく小さな改良だ。そのような地味な活動を継続させている動機は何なのか。

陰謀論の基本に立ち返れば、「儲かったのは誰か?」ということになる。

キンタマウイルスの被害で金銭的利益をあげたといえば、マスコミではないだろうか。連日繰り返し報道される流出事故。次から次へと見つかる事故にネタに事欠くことがなかった新聞社もあっただろう。夕刊紙にいたっては、若い女性のプライベート写真が流出すると、何の落ち度もない一般人であるにもかかわらず、目と性器だけ隠して裸体写真を掲載することまでした。

彼らはどうやって事実確認用のデータを入手していたのか。専門の取材班を結成して日夜Winnyでキンタマを集めていたと噂する説もあれば、自分の手は汚さないよう外部の協力者に依頼して集めさせていたという憶測レベルの噂も耳にする。さすがに、新聞社自身がウイルスを作ったり頒布するなどという行為は行っていなかったに違いないが、「外部の協力者」はどうだろうか?

そうした疑念を強める記事が今頃になって日経ビジネスに掲載された。

このジャーナリストは次のように言っている。

ファイル交換ソフト「Winny(以下ウィニー)」がウィルスに感染、至るところでPCのハードディスク内の情報をネットにばらまき始めたニュースは印象深かった。 (略)

しかし私自身の印象は、怯えや焦りとは相当に隔たっていた。そうか、ウィニーはもはやジャーナリズムになったのだな――。そんなことを私は考えていたのだった。

(中略)

(略)結果としてウィルス感染によってパソコンの持ち主の意志を越えてハードディスクからデータを垂れ流し始めたことを「歴史の偶然」として片付けるべきではない。そんなことが可能な既に技術が用意されている。それはジャーナリズムにおいて言えば、ウィニーのようなプログラムですらジャーナリストの活動ができてしまう時代が到来したということだ。

(略)その中に政治家や官僚の接待記録や、防衛関係や警察の内部資料あたりが含まれていて、それが首尾良く報道関係者に見つけられれば価値を発揮するが、流出情報の殆どは市井の人々の個人情報だろう。

だが、その種の情報の価値も軽視すべきではない。(略)個人情報をうまく扱える人間の手に渡れば、それは千金の価値を帯びるようになる。ジャーナリズムにおいても事情は変わらない。流出情報がどんな価値を持つかは、受け手側次第なのだ。

(中略)

(略)対してブログの書き手の場合、以前に大手のマスメディアで仕事をしていたことをプロフィールに書けるブロガーを除いて、素姓がいまひとつ不確かなひとが多い。(略)公的なテーマを扱いながらも、所詮は「独り言」のように扱われてしまう。

しかし、ここでも状況は一変しうる。たとえばウィニーによってブログの設置者関連の個人情報が流出したとしよう。それと組み合わせられると、ブログに書かれていた「独り言」が俄然、意味を持って輝き始める。あるいは課金支払いのために登録したクレジットカードの名義などからブロガーのリアルな情報が明らかになると、その見たこと聞いたことが確かな事実の報告として信頼されるようになる。特にそれまでは匿名で、ごく身近な知人にだけ分かる形でブログに書かれていた私的な内容が、いつ、どこで、誰によって、どのように書かれたかが分かるようになり、確かな事実として利用できるようになる。こうして別の個人情報と接続されることで、事実の「表情」が変わってしまうのだ。

(略)個人ブログ百花繚乱の日本のネット状況は、そうしたシステムが、社会の隅々にまで毛細血管のように張り巡らされていることを意味する。今まではそれをジャーナリズムのメディアとして利用することはできなかったが、たとえばウィニーのようなソフトの関与ひとつで状況は劇的に変わる。

僅かな楔を打ち込むだけで、既存ジャーナリズムに属するプロフェッショナルたちの「人間的」な頑張りなどなくても、ジャーナリズムが調べて報じるべきだった情報が手に入ってしまう――。そんなことが可能となる時代の入口のすぐ近くにまで私たちは来ているのだ。

(中略)

(略)備えた新しいアームチェア・ノンフィクション、いわばハードディスク・ジャーナリズムが求められているのだろう。

そんなジャーナリズムだけが、ウィニーが作られてしまった時代に自らをジャーナリズムと自称できるのではないか。 (了)

武田徹, ウィニーこそ史上最強の「ジャーナリスト」?, 日経ビジネスオンライン, 2007年5月31日

「僅かな楔を打ち込むだけで」――すなわち、小さなプログラム*2をトロイの木馬(ウイルス)として送り込むだけで、誰の秘密でも引き出せる。それが、「千金の価値を帯びる」と、このジャーナリストは言っている。しかも、ターゲットは一般人の「私的な内容」だという。

何が本題か知らないが、このジャーナリストは、「僅かな楔を打ち込むだけで一般人の私的な内容を千金の価値にできる」という手法について、否定していない。否定する表現が一切書かれていない*3。これが倫理に反する行為であることをこのジャーナリストは素で知らないのではないか。もし、「キンタマウイルスを作成し頒布しているのはあなたでしょう?」と問いかければ、憤慨するどころか、褒められたと勘違いして「いえいえ私にそんなプログラム力はありません」とニコニコするのではないか。

馬鹿は死ねと言いたい。

マスコミの委託を受けてか知らないが、キンタマコレクターと呼ばれる人たちがいる。ネットエージェントの杉浦社長も言っていることだが、私も自作のNyzillaを使って何箇所ものWinnyノードを観測した際に、ウイルス入りのキンタマファイルばかりを送信可能化しているノードが存在するのを見た。

これは、「キンタマ」などの文字列をキーワードに全ファイルを自動ダウンロードする設定*4にしているノードだろう。この設定をしていると、流出ファイルを延々とダウンロードし収集し続ける。これがキンタマコレクターの仕事であるわけだが、通常のWinnyを使ってこれを行うと、それは同時に、キンタマファイルを公衆送信可能化する(他人に提供する状態にする)ことにもなる。コレクター達は、それも承知でやっているだろう。

そしてキンタマファイルにはウイルスも入っているのだから、キンタマコレクター達のキンタマ公衆送信は、ウイルス頒布に他ならない。

もし、国会で審議中の刑法改正案が成立し施行されれば、不正指令電磁的記録供用罪(第十九章の二第2項)で、三年以下の懲役又は五十万円以下の罰金だ。しかも、供用が確認されなくても、「前項の罪の未遂は罰する」とあるので、供用するつもりで送信可能化しただけで同未遂罪となる。

「ジャーナリスト」が「僅かな楔を打ち込むだけで一般人の私的な内容を千金の価値にできる」という手法を望むなら、その委託先の協力者達はこぞってウイルスの拡散を望むだろう。それは、地引きでダウンロードし続けるWinnyを24時間稼動させ続けるだけでできる。

現行法ではこれを処罰する手立てがないらしいと耳にする。合法なら何でもやるというのがジャーナリストなのか。倫理などというものは一つの価値観でしかないとでも言うのか。国会の議事録を確認してみると、不正指令電磁的記録供用罪について野党からも反対意見は出ていないのであり、上記のようなウイルスを頒布する行為が人の道を踏み外した行為であることは、既に合意されているといってよい。

そもそも、Winny経由での情報漏洩事故はもう3年以上続いていて状況に変化はないわけだが、このジャーナリストのような発言をする人はこれまでに居なかった。なぜ今頃になってこのような発言が新しいものとして出てくるのか。

もちろん、Winnyネットワークへの情報漏洩が起きている事実を市民に広く伝えるのは、報道機関の使命であろう。初期の漏洩のころからその報道に携わってきた真面目な記者を私は知っている。そこには常に葛藤があったはずだ。報道しないわけにはいかないが、ファイルを入手する作業自体が問題を含んでいた。

このようなWinnyの仕組みは、設計段階から意図されたものだろう。つまり、いかがわしい行為の事実を掴もうと、いかがわしくない者が中に入ってこようとしても、いかがわしい行為をしなければ、いかがわしい行為の事実を掴めないように設計されているわけだ。

これが、2002年までの単純な情報漏洩事故の報道とは異なる、Winny流出の報道の新たな難しさであり、昔から情報漏洩問題に取り組んできたメディア記者らは、そのことをきちんと理解していただろう。

愛媛県警の流出事故で Nシステムの実態等が明るみになった際には、「自動化されたジャーナリスト」のような声は(雑談としては面白いので)あちこちで会話されていただろう*5が、それをプロの記者が真顔で語ることはなかった。不謹慎だからだ。下品さで知られるボーガスニュースでギャグにされていたくらいの話だ。

ところが、何年も経つうちに世の中が少しずつ変わってきた。パソコンが普及し、Winnyが普及し、新たな初心者市民が被害に巻き込まれるようになったのと同時に、かつては情報セキュリティ問題に関心のなかったような新たな「ジャーナリスト」が参入してきた。

その結果起きた現象のひとつが、先月の「北海道新聞の記者がWinnyを使って流出ファイルを入手したことを公言しているが自分のやっていることがわかっているのか」の事例であり、もうひとつが、この日経ビジネスの「ウィニーこそ史上最強の「ジャーナリスト」?」だろう。

なにかもう末期的な危うさを感じる。どうにかならないものか。

3月にも、田原総一朗と高野孟がこんなことを言っている。

  • PodTV - 田原総一朗 こもんずセミナー1 これからの経営(5), 2007年3月31日

    (番組開始60%前後のあたりから)

    田原: それからもう一つね、なんていったっけ、今問題になっているソフト、情報が漏洩するという。

    高野: ウィニー?

    田原: ウィニー。今日実は朝ね、ウィニーの開発者、有罪でパクられた、金子勇。一時間半ばかり話し聞いたんですよ。おーもしろかったーですよー。ウィニーって知ってますよね?(会場を見渡す)

    だいたい悪いソフトだっていうふうに言われますね。一般的に。有罪になったんだから。でも新聞も全部ね、ボロクソに書いてるよ。 まったく悪くないね。

    高野: そうですね。

    田原: うん。これ知ってるでしょ? まったく悪くない。

    高野: 私、まったく悪くないと思います。

    田原: うん。つまりー、これはー、ようするに、まー(略)

    田原: 情報をね、このあのー、ようするに名前を出さないで、自由に交換できるんですよ。いろんな情報を取り入れる、情報を出せる。というのがウィニーなんですよ。

    そこへー、その、コンピューターウイルスが、入ってくると、つまり、情報を交換するね、してもいいって情報はあるわけね。ところがその、コンピューターウイルスが入ってくると、交換しては不味い出しては不味いってとこまでね、出しちゃうようになるわけね。

    で、こんなことは、どのソフトにもあるわけね。で、ところが彼だけが、パクられて、彼だけが有罪になった。世界で、ただ彼だけなんですよ。こういうことでパクられるのは。で、なんでパクられたかっていうと、単純なこと。京都府警がね、京都府警のある男が、ウィニーを使って情報が漏れたわけ。クソーコノヤローこいつをタタッ殺してやるー、っていうんでね、有罪になったんですよ。

    高野: ふっふっふ。

    田原: でね、そうすると世論は、みんなこれ、

    高野: 野蛮ですよね。

    田原: 野蛮。みんなこいつが悪いんで、安倍さんまでが、ウィニーは使わないでおこうとか言うわけね。(略)

    田原: だかんねー、世論は怖いなと思ってるわけ。まったく悪くない。

    で、彼はもっと酷いんですよ、彼はウィニーの開発を禁止されてるんですよ。で、ウィニーの欠陥をね、直したい。で、あのー、直すようにいくらでもできる。それもやっちゃいけないっていうふうにね、え、あのー、検察の、なってんのね。

    高野: むちゃくちゃですよね。

    それはだからー、僕はよく言うんですけど、あのー、電話がね、このー、全国あまねくいきわたったら、それを電話を使って脅迫電話をかけたやつがいたと。「電話が悪い」と、言ってるようなのと同じなんですよ。ね。

    田原: そう。

    高野: むちゃくちゃな話ですよね。 (以下略)

この調子でサンデープロジェクトで番組作りされるようなことにでもなれば、新たな「新参者」が次から次へと湧いてくるだろう。

関連

*1 「誰の仕業かバレなければ嘲笑されてもかまわない」ではなく、「誰の仕業かバレないにしても、自己を正当化する理屈がないと自分自身納得できない」という屈折した自尊心がそこにある。彼らは、被害者が何か悪いことをしていないか探す。どんな小さな「悪いこと」であっても、たとえそれが特定の価値観に基づくようなものであっても、「悪いのだ!」と糾弾し、自尊心を維持しようとする。

*2 jar cf "/Program Files/Winny/Up/俺のキンタマ.zip" "~/My Documents/" というような内容の1行のプログラムでよい。

*3 記事の導入部に、「こう書くと何を言い出すのか、気でも狂ったかと非難されそうだ」という記述があるが、これは、「ジャーナリズムとは新聞社や放送局のようなプロ集団が担うもの」という価値観の人達に、「ネット界のしかも人間ですらないファイル交換ソフトに神聖なるジャーナリズムの名を与えるとは何事かと、怒りに沸騰する人」に「気が狂ったか」と非難されることを指しているのであって、職業倫理を逸脱した発想について「気が狂った」と自認している様子は見られない。

*4 地引網のように根こそぎ全部持ってくるという意味で「地引き」と呼ばれる。

*5 ちなみに、日経ビジネスの記事は、「自動化されたジャーナリスト」を説明するのに、防衛庁の機密情報漏洩を例に挙げている。

たとえば2006年11月は、防衛庁にとっては北朝鮮よりもウィニーの恐怖に震えた月だったろう。29日には航空自衛隊那覇基地の内部資料と米軍情報が流出。翌日には陸上自衛隊中部方面隊と航空自衛隊北部航空方面隊の内部情報が相次いで流出していたのが発覚した。

防衛関係の情報は、いずれにせよセキュリティ上の理由を建前に非公開とされがち。ジャーナリストが取材しようとしても門前払いされることが多い。そんな情報が呆気なく流出してしまったのだから、見方によればウィニーは凡百のジャーナリストよりも「剛腕」だったとも言える。マスメディアジャーナリズムが自衛隊の内部情報をスクープするなんて、最近では滅多にないのだ

武田徹, ウィニーこそ史上最強の「ジャーナリスト」?, 日経ビジネスオンライン, 2007年5月31日

これは全くおかしい。この事故では、情報が漏洩したことが報道に値する事件だったのであり、情報そのものが報道に値するような内容ではなかった。

本日のリンク元 TrackBacks(100)

2007年06月06日

Upcoming Advisories


IPA#33593387

製品開発者: KDDI(株)
深刻度: 高
届出日: 2007年3月19日
受理日: 2007年3月26日
経過日数: 72日
状況: 調整機関は4月5日に製品開発者に通知したとのこと。
評価: 修正版の提供と利用者への周知は届出者にも可能であるが、この製品の場合、利用者への迅速な情報の伝達を達成するためには、製品開発者自身が確実な告知を行うことが望ましい。

     
(45) (60) 72日(経過日数)


IPA#45031375

製品開発者: KDDI(株)
深刻度: 中
届出日: 2007年3月28日
受理日: 2007年3月29日
経過日数: 69日
状況: 調整機関は4月5日に製品開発者に通知したとのこと。製品開発者は誤った説明を5月上旬に中止したとの話を、届出機関から5月21日に連絡を受けたが、中止したというのは事実でないことを6月1日に確認した。
評価: 修正による対応は現実的でないため、事実の周知が対応策となる。(誤った説明を中止し、過去の説明を撤回し、正しい情報を周知すること。)周知するだけの作業の実現に60日以上もかかるというのは、組織の脆弱性対応体制に不備があるのではないか。

     
(45) (60) 69日(経過日数)


日記予定

  • ITmediaはネット界の朝日新聞になれるか
  • ACCS久保田氏の啓発活動が下手で裏目に出た件
  • 金床問題のまとめ(情報セキュリティ論議に求められる科学的リテラシー)
  • 「定期的言うな」キャンペーン開始計画
  • JPNICによると「自己署名の検証」というものが可能らしい
  • PKI製品の配布でPKI技術の存在意義を否定している日立製作所
  • 最近のBluetooth事情

本日のリンク元 TrackBack(1)

2007年06月08日

愛媛県警の報告書曰く「Winnyは音楽や映像などの情報を自由に共有できるソフト」

サイバー犯罪に関する白浜シンポジウムで白浜に滞在中。今日の午後一番目のご講演に対してさせていただいた質問に補足すると、「愛媛県警の報告書が『Winnyの利用は自由』としていた」というのは以下のこと。

これについて、2月下旬に以下の問い合わせを送っていた。

調査結果報告書 警察職員の「ウィニー」利用による警察情報流出事案について
http://www.police.pref.ehime.jp/soumu/ryusyutu_chousa.pdf
を拝見しました。内容に疑問点がありますので質問させてください。

報告書の終わりのところに「用語等の凡例」という部分があります。ここに、Winnyの説明として以下のように書かれています。

ウィニー: 使用者同士がインターネットを通じて音楽や映像などの情報を自由に共有できるファイル共有ソフトの一種で、通信の暗号化と高い匿名性を備えている。

質問:
Winnyで音楽や映像などを共有することは自由ですか?

以上、お尋ねします。

しばらくの後に担当部署から電話でご回答を頂き、大変丁寧な説明を受けたのだが、この質問をしたのは、この報告書にはWinnyによるダウンロード行為(同時にそのファイルは公衆送信可能化される)の違法性について何ら記述がなく、むしろ次のように、正当な利用であったかのように読者を誤解させ得るような書き方になっており、もしかして本当に違法性を知らないのではないか? と疑問に思ったからだった。

(2) インターネット、「ウィニー」の使用状況

A警部は、平成11年ころからインターネットの利用を開始していたところ、平成15年夏ころ、情報の検索に便利なファイル共有ソフトとして「ウィニー」を知り、自宅の個人所有パソコンに導入し、本件事案が発覚するまで、映画・音楽等を収集するために使用していた。

県警においては、平成16年4月以降、内部規程により、職場で使用するパソコンのみならず、公務に使用しない個人所有パソコンにおいても、「ウィニー」等ファイル共有ソフトの使用を控えるとともに、使用している場合には、これを削除することなどを指示し、すべての県警職員を対象にその徹底を図ってきたところであるが、A警部は、自宅の個人所有パソコンについては、普段公務に使用しておらず、職場で作成・収集したファイルも保存されていないため、「ウィニー」を利用しても構わないと誤って認識していたことから、上述の指示の後も自宅での同ソフトの使用を継続していた。

調査結果報告書 警察職員の「ウィニー」利用による警察情報流出事案について, 愛媛県警察本部, 2006年6月16日

この報告書の文から、愛媛県警の内部規定では、Winnyの利用は禁止ではなく「使用を控える」という程度のものであったことがわかる。禁止とまで言えないのは自宅での使用まで内規で禁止できるかということがあるのだろう。というのも、使用を控えるべきとする理由が、あくまで情報漏洩を起こさないためとされていたからだ。もし、「公衆送信すると違法になるファイルをダウンロードする行為には違法性がある」という理由で指示していたならば、この警部は、「職場で作成・収集したファイルを保存していないためWinnyを利用しても構わない」などという認識には至らなかったはずだろう。なぜなら、警察官は一般市民以上に法遵守の精神があるはずだからだ。

2月の質問に対する愛媛県警の担当者からの説明は、「Winny自体が違法かどうかはっきりしていないし、使い方しだいだと思う」というような内容だったように記憶している。(メモをとらなかったので、確かな表現はもう思い出せないため、あまり書くことができない。)

そこで私は、2月25日の日記「Winny問題解決への糸口が今、山梨県警の手に託されている」で書いたことを意見として説明した。すなわち、以下の点を伝えた。

  • Winnyは、ダウンロードしたファイルは同時にアップロードする状態になる仕組みになっている。
  • そのため、公衆送信可能化すると違法になるようなファイルを、そうと知りながらダウンロードする行為は、違法性を問われる可能性がある。
  • すべての人がその事を知るべきところだが、特に警察職員は、何が違法行為であるのかを知っていなければならないのでは?
  • 仮に、裁判例がないなどの理由でその違法性について警察が見解を述べることが難しいとしても、内部規定で職員向けに注意する際の文書であれば、違法性を問われ得ることを理由として明示することは可能では?
  • また、そのような内部規定で職員の規律を正していることを県民に向けて公表することもできるのでは?

ひとつひとつ説明したところ、本当に理解していただけたようだった。

報告書を修正することは難しいかもしれないが、内部規定はどうなっただろうか。その後どうなったかは知らない。

本日のリンク元 TrackBacks(100)

2007年06月12日

キンタマコレクターは約1000人もいるらしい

先週の白浜シンポジウムでは、夜の部で様々な情報を耳にした。驚愕の事実もいくつか聞いたが暗黙にオフレコ前提なのでここに書くということはできそうにない。

ネットエージェントの杉浦社長からも興味深い話を何点か聞いた。いわゆる「キンタマコレクター」(キンタマウイルスにより漏洩させられたファイルを収集し続けているWinnyノード)は、約1000人(ノード)との観測結果(2日間での観測)があるのだそうだ。

キンタマコレクターには2つのタイプがあり、ひとつは、普通のWinnyを使って流出ファイルを手当たりしだいに自動ダウンロードしている者――(A) で、もうひとつは、OpenWinnyやその他の自作と思われるダウンロード専用Winnyプロトコル互換プログラムによるダウンロードをしている者――(B) であるが、この約1000という数値はこれらの両方を含む。それぞれがどのくらいの割合を占めるかについては未調査とのこと。私も追実験して確認してみたいところだ。

どちらのタイプも、その収集の目的はわからない。正当な目的で取得しようとしている者もいるだろうし、単なる覗き見趣味で集めている奴もいるだろうし、犯罪目的で収集しているような連中もいるのかもしれない。いずれにせよ、(A)のタイプは、たとえ正当な目的で収集しているつもりであっても、ダウンロードが同時にアップロードになる(公衆送信の送信を可能化する行為になる)Winnyの特性からすれば、不適切な行為(流出ファイルを二次公開する行為)であるし、ファイルの内容によっては違法行為とされ得る。それを知っておくべきだろう。

ファイル交換/共有ソフトの分類の必要性

最近は会社などの組織で、「P2Pソフト」などの名目で特定のソフトウェアの使用を禁止しているところが多いだろう。そこでしばしば耳にするのは、会社のシステム管理部門が十把一絡に「P2P」なら何でも禁止していて、Skypeまで禁止されるような事態に、社員達が不満の声をあげているという話がある。

不満の理由は、「管理部門の連中はP2Pが何だか理解する能力もない。名称で適当に禁止しやがってアホか」といったものだ。「P2P」ではなく、「ファイル共有ソフト」「ファイル交換ソフト」という括りで禁止している場合もあるだろう。

管理部門が禁止する理由にはいろいろあるだろうから、そう簡単に「管理部門がアホ」としてしまうのはよくない。何が禁止理由になっているのかを明確にしていく作業が必要だろう。

ここでは、まず、ファイル交換ソフトまたはファイル共有ソフトについて検討してみる。

会社の管理部門が使用を禁止する理由のひとつには、機密管理の理由から、ファイルを他人に送信できるようなソフトウェアを全て禁止にしたいということがあるかもしれない。その意味では、電子メールだってファイルを他人に送信できるものなわけだが、メール中継サーバ(MTA)でフィルタリングを実施している会社ならば、それ以外の方法でのファイル送信を制限するということになるのだろう。その方針がない会社の場合であっても、外部からアクセス可能なサーバを許可なく立ち上げてはならないという方針の会社もあるだろう。

ここで、BitTorrentについて検討する。BitTorrentの使用を禁じている会社もあるという話をしばしば耳にする。そして、それに対する不満の声も耳にする。

BitTorrentの基本的な使い方は「ファイルのダウンロード」である。もしその会社の方針が、従業員のWeb閲覧、Webからのダウンロードに対して制限しないものである場合、「なんでBitTorrentは駄目なんだよ!管理部門はBitTorrentが何か理解してないだろ!」という不満が出てくることになる。

BitTorrentが、実態として、著作権侵害ファイル(著作者に無断で公衆送信を可能化すると著作権法違反になるファイル)のために使われることが多いことから、BitTorrentに悪いイメージを持つ人が少なくないようだが、再配布が自由な大規模ソフトウェア(OSなど)の配布などにも使われており、正当な使用方法も十分に存在する。そのため、「正当な目的で使おうとしているのに、使用禁止だなんて、管理部門はわかってないだろ。」という声が出てくるわけだ。

だが、次の点に注意したい。

BitTorrentで「ダウンロード」する行為は同時に「アップロード」する行為にもなる。再配布が自由なファイルを「ダウンロード」する行為は何ら問題がないわけであるが、無断で公衆送信可能化することが著作権法違反になるようなファイルを「ダウンロード」する行為は、送信可能化権侵害の責任を問われる可能性があり得る。使い方によって、禁止すべき行為と、そうでもない行為があるわけで、ここが難しい。

もし、従業員の全員が、この「ダウンロードが同時にアップロードになる」という仕組みのことを理解し、公衆送信すると違法になるファイルかどうかを常に意識しながら「ダウンロード」するのならば、BitTorrentの使用を自由としてもよいかもしれない。(Webでのダウンロードに何ら制限を設けない方針の会社の場合。)

だが現時点ではそのような理解は従業員に普及していないだろう。従業員が、Webでのダウンロードと同じ感覚で、BitTorrentでの「ダウンロード」をしてしまい、公衆送信権侵害等の責任を問われる事態が生じかねない。

こういった理由で管理部門がBitTorrentの使用を禁止することは理解できる。

したがって、技術フリーク達にとって、BitTorrentの普及を願うならば、次の啓発活動が必要になる。

  • ダウンロードがアップロードになるソフトと、そうでないソフト(ダウンロードは単にダウンロードするだけ)の区別の理解の普及
  • 後者は(ほとんど)何をダウンロードしても適法(その使用は別として)だが、前者はそうではなく、どういうものならば「ダウンロード」して適法なのかの理解の普及

今、著作権法改正に向けた検討で、ファイル交換ソフトによるダウンロードを私的複製の範囲外にしようという動きがあるというが、こうした、ダウンロード/アップロードの区別の理解が人々に普及しないことが原因で、十派一絡げにダウンロードごと違法化してしまえということになっているようにも感じられる。

会社の管理部門の方針ならともかく、国の方針として一律にそこまで規制してよいのかという疑問は出てくるだろう。十派一絡の規制を避けるためにも、今こそ、上のような区別の理解を普及させるべきだ。

そのためにも、まず、各種ファイル交換ソフト毎に、それぞれが「ダウンロードが同時にアップロードになる」タイプなのか、「ダウンロードはダウンロードにしかならない」タイプなのか、分類しておきたいところだ。

  • Winny ―― ダウンロードが同時にアップロードになる(ほか中継あり、自動運転あり)
  • poeny ―― ダウンロードが同時にアップロードになる(中継なし)
  • OpenWinny ―― ダウンロードはダウンロードにしかならない(中継なし)
  • BitTorrent ―― ダウンロードが同時にアップロードになる(中継なし)
  • Skypeのファイル送受信機能 ―― 送信が公衆送信でない
  • .... その他確認中*1

ACCSの啓発方法は下手で理解を得られにくい

先月、発売前の漫画作品をWinnyに放流していた2人が公衆送信権侵害で逮捕される事件が起きた際に、ACCS(コンピュータソフトウェア著作権協会)が次の声明を出していた。

  • ファイル交換ソフト「Winny」を使った公衆送信権侵害事件について, ACCS, 2007年5月18日

    Winnyの「合法的な利用」に関して、自分で撮った写真や自分が作詞作曲した楽曲などをアップロードする利用があり得ることをもって正当化しようとする意見がありますが、前出のファイル交換ソフト利用実態調査を通じては、このような利用はごく少数にとどまっているものと考えます。さらに、現状の Winnyネットワークでは、参加するだけでファイルの断片を勝手に中継させられるという機能があることからも、完全な合法利用と言い切るのは無理があると考えます。

    また(略)ことから、現在のWinnyが合法利用にも役立つとの主張は、机上の空論と言わざるを得ないのです。

    以上の理由から、ACCSは、Winny利用者に対し、Winnyは、そのネットワークに参加した時点で違法な送信行為に「加担」しているということを警告し、Winnyの利用をやめるよう求めます。

この啓発方法は、論拠が過剰なため理解を得られそうにない。

これを言い出すと、「ならISPのルーターも違法かよ!」とか「Skypeも潰す気か!」という声が出てくるのは目に見えている。案の定、即座に次の指摘が出ていた。

  • Winnyの合法利用説は「机上の空論」、ACCSが利用停止呼びかけ, 弁護士 落合洋司 (東京弁護士会) の 「日々是好日」, 2007年5月19日

    京都地裁の公判で村井教授が証言したように、システム自体は価値中立的なものであり、(略) 単に中継しているだけで個々のファイルについて個別的な認識を持たない利用者の行為まで違法と決めつけその責任を問えるか、という疑問は当然生じるでしょう。

    P2P技術の有用性、将来性が強く指摘され、実際に活用(「悪用」ではなく)もされつつある中で、「現状」を過度に強調して、合法利用を「机上の空論」と決め付けてしまって良いのか、ということは、考えてみる価値のあることではないかと思います。(以下略)

「P2P技術」で十派一絡にする典型的な(非技術者が陥りやすい)雑な印象論になってしまっている。一般に、過剰な論拠を持ち出すと、議論が雑なものとなり、不毛なやりとりに終始してしまいがちなので注意したい。*2

言うまでもなく、ACCSのこの啓発活動の目的は、著作権侵害を抑制したいというところにあるだろう。私は著作権侵害の抑制には関心がないが、不本意な流通を止めたいという点ではACCSと共通するところだ。

不本意な流通を阻止したいというだけであれば、上のエントリで書いたように、「ダウンロードすると同時にアップロードになる」ということを言えばいい。ACCSの場合であれば、次のように言えばいいだろう。

Winnyをまだ使い続けている人達は、「自分はダウンロードしているだけだから合法だ」と思っていませんか? Winnyの場合、ダウンロードしたファイルはそのまま他人に提供する(公衆送信する)仕組みになっています。そのことを知ってください。著作者に無断で不特定多数に提供すると著作権侵害になるようなファイルについては、Winnyでダウンロードするとあなた自身の責任が問われます。ダウンロードしてよいファイルなのか、いけないファイルなのか、自分で区別できない方には、Winnyを合法に使うことは困難です。ACCSは、そのようなWinny利用者に対し、Winnyの利用をやめるよう求めます。

(妥当な勧告の例文)

それなのに、「参加した時点で違法な……」という過剰な論拠を持ち出すのはなぜなのか。

先月のACCSの声明は、「Winnyが合法利用にも役立つとの主張は机上の空論」という点が主題になっている。「自分で撮った写真や自分が作詞作曲した楽曲などをアップロードする利用があり得ることをもって正当化しようとする意見」(またはそういう主張をする人間)のことが気に食わないのだろう。だが、それを否定することは、ACCSの目的(著作権侵害の抑制)を達成するために必要なことだろうか?

「Winnyが合法利用にも役立つとの主張」をしている人達は、本気でそのような利用をしたいと思って言っているわけではなかろう。彼らは、Winnyの作者が著作権法違反幇助に問われた裁判で、被告の弁護に必要な論拠として、「Winnyが合法利用にも役立つ」事例の存在を作り出すために、そう主張しているのだろう。(これについては、2006年4月14日の報道ステーションの映像が興味深い。)

ACCSは金子被告を有罪にすることも目的としているのか? その必要はあるのか?

たしかに、Winnyと同類のソフトウェアを開発する輩が今後現れることを牽制するために、金子被告が有罪となる方が、著作権侵害を抑制する目的において都合がよいという発想はあり得る。しかし、それはあまり望めない効果だろうと思う。一審判決を見る限りでは、不言実行ならば同じ理屈による処罰は難しいように思われる*3

今なすべきことは、「ダウンロードが同時にアップロードになる」仕組みを知れという啓蒙ではないか。岡山県警の流出事件で「他人への譲渡などはなかった」とされてしまった事例一部の県警に問い合わせるとダウンロードが違法になり得る事実の認識が警察職員に欠けていることがわかる件北海道新聞社の記者がWinnyでダウンロードしたことを公言して憚らなかった事例、また、テレビ局が協力者にカメラの前でWinnyでダウンロードさせる様子を放映(「特殊なソフトを使用しています」といった注意書きなしで)する事例が後を絶たないことなどに見られるように、この啓発がまだまだ全然足りていない。

ACCSの活動には「Winnyではダウンロードは同時にアップロードになる」という事実の周知を期待する。私とは目的が異なるが、流出情報の不本意な流通を抑制するためにもそれをやってほしいと思う。

*1 誰かやって!

*2 一般に、「完全な○○と言い切るのは無理がある」というような表現を使わざるを得ないようなことは、言わない方が議論の目的にとって得策だと心得るとよい。

*3 関連:Winny事件判決で考える内面の問題, 神近博三, 日経ITPro, 記者のつぶやき

本日のリンク元 TrackBack(1)

2007年06月13日

東京労働局がITmediaを否定「spamを遮断しないと措置義務違反というわけではない」

6月1日にITmediaからこんな記事が出て各所で話題となっていた。

この記事は一読して変だと思った。何が変なのかと、もう一度読み返してみると、ようするにこの記事は、事実と伝聞と推論と意見がごちゃまぜに書かれていて区別されていない。こういった文章に必須の基礎が守られていない。

この記事の肝は次の部分であろう。

セクハラ相談などを受け付けている東京労働局雇用均等室によると、性的なスパムメールは、男女雇用機会均等法上で事業主が防止を義務づけられている「性的な言動」に当たり、受信を防止せずに放置した場合は「環境型セクハラ」とされる可能性が高いという

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

東京労働局雇用均等室の話をベースに書かれた報道記事の体裁をとっている。したがって、読者は、この記事の内容は東京労働局の見解に沿っていると思って読む。

しかし、続きを読んでみるとどうもおかしい。

まず、

厚生労働省の告示(2006年615号:PDFへのリンク)によると、性的な言動とは「性的な内容の発言と性的な行動」で、社内にわいせつなポスターを掲示したり、裸や水着の女性のスクリーンセーバーを使用したりする場合などもこれに含まれる。性的なスパム受信をフィルタリングせず、結果的に従業員に閲覧を強要する場合もこれに当たるというわけだ

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

この段落は、前半は告示に書かれている事実の紹介が書かれており、後半は、spamの件がそれに当てはまるという見解だが、誰の見解なのかというと、明確には書かれていないものの、「……というわけだ」とあることから、前の段落の東京労働局の話を噛み砕いた解説と読むのが普通だろう。

次に、

環境型セクハラとは、性的な言動や行動によって労働者が不快な思いをしたり、仕事に支障が生じたりするセクハラを指す。性的なスパムを受け取ることで不快な思いをしたり、仕事が手に付かなくなったりするケースがこれに当てはまる

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

この段落では、「これに当てはまる」と書かれているが、誰の見解かは不明であり、もはや東京労働局の見解なのかどうかわからなくなっている。

次に、

今年4月1日に施行された改正男女雇用機会均等法では、事業主のセクハラ防止が「配慮義務」から、具体的な措置を求める「措置義務」に変わった。経営者がとるべき措置は、前出の厚労省告示に9項目定められており「セクハラを認めない方針の明確化と周知・啓発」「セクハラが起きた場合の迅速な事実確認と対処」などが含まれている。

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

この部分は、法改正で「配慮義務」が「措置義務」に変わったという事実が単に書かれている。

しかし、次の、

スパム問題に当てはめると、性的スパムの受信強要というセクハラが起ないよう、経営者はサーバレベルで可能な限りシャットアウトするよう努め、そのために具体的な防止措置を講じる義務がある──ということになりそうだ。スパム受信が実際に起きてしまっているなら、ただちに事実を確認し、防止策を講じる必要があるだろう

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

この段落がかなりおかしい。「当てはめると」というのは誰による検討なのか? 「ということになりそうだ」というのはどういうことか? 誰の予測なのか? 識者なのか? 世論なのか? 東京労働局なのか? 「ただちに……必要があるだろう」というのは誰の見解なのか?

単に記者の見解を書いているだけなのなら、ニュース記事の体裁でなく、blogにでも書いたらどうか。「ということになりそうだ」などと「一流マスコミ」ばりの表現を使ったりせず、「と思う」と書いたらいい。

さらに、

「サーバレベルでのスパム対応はコストがかかる」として経営側が対応をおろそかにした場合、労働局から行政指導を受ける可能性があるほか、「義務違反で精神的苦痛をこうむった」として従業員から損害賠償を請求される可能性もある

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

この段落もかなりおかしい。可能性があると断定しているが、内容を見てみると、セクハラ一般について、措置義務を怠った場合に行政指導の可能性や損害賠償請求の可能性があるというのは事実であろうが、「サーバレベルでのスパム対応」についてその可能性があることは、「サーバレベルでのスパム対応」を怠ることがセクハラに該当するという前提で成り立つことであり、これは推論である。成り立つかどうかが不確実であれば、このように断定することはできない。

結局、どこまでが東京労働局雇用均等室の見解なのか、記者の文章が下手で読み取れないことが、この記事を変なものにしている。

そこで、6月4日に東京労働局雇用均等室のセクハラ相談窓口に電話で尋ねてみた。

問い合わせた内容は次の通り。

  • ITmediaにこのような記事が出ている。どこまでが労働局の見解か?
  • 「サーバレベルでのスパム対応」を怠ると行政指導の可能性、損害賠償請求の可能性があるというのは東京労働局の見解か?
  • ITmediaの取材にはどのように回答したのか?

検討して折り返し返事を頂くことになり、翌日に電話で以下の内容の返事があった。

厚生労働省本省に照会して結論を得るのでしばらく待って欲しい。(波及効果の大きい問題と考えるので。)

今しがた他にも同様の問い合わせがあったところだ。

そして、12日に回答があった。厚生労働省本省の見解として承認をとった正式な回答だという。回答の内容は以下の通り。(電話で受けた説明を私が文章にまとめたもの。)

spamを見て嫌だと思わない人もいる。環境型セクハラかの判断では主観も重視するが客観性も重視することになっている。spamを受信してしまう状態が環境型セクハラであるとは必ずしもいえない。ただし、spam受信が嫌だという抗議を受けてそれに対処しない場合は、環境型セクハラに該当し得る。

spamを受信しないようにしておかないと処置義務違反になるかについては、

  • メールを仕分ける方法を周知する
  • メールを開かなくても業務上問題ないなどの指示する
などの、その他の対処方法もあるのだから、必ず遮断しないと措置義務違反ということではない。

これはITmediaの記事とはずいぶん見解が異なっている。ITmediaの記事では、従業員がspam受信が嫌だと意思表明をしていることを前提とせずに書かれており、いきなり、

性的なスパムを放置し続けるとセクシャルハラスメント(セクハラ)と認定され、会社が行政指導の対象となったり、訴訟に直面することもありうるのだ──。

会社宛ての“エロスパム”、対処しないとセクハラに?, 岡田有花, ITmedia, 2007年6月1日

と結論付けている。

これはいったいどういうことかと、東京労働局に「ITmediaには何と答えていたのか」について再び尋ねると、次の通りの返事だった。

誰が問い合わせを受けたか調査した。現在の東京労働局の担当者と3月までの前任者の全員に確認したが、女性の記者とかITmediaという媒体から取材あるいは問い合わせを受けたという事実は確認できなかった。

東京労働局機会均等室では回答していなかったという。では、記事の「東京労働局雇用均等室によると……とされる可能性が高いという」というのは、いったい何なんだろうか?

なお、東京労働局機会均等室によると、その後さらに2人から、計3人から同様の問い合わせがあったとのことで、3人目の人はITmediaのこの記事を見て問い合わせているとのことだったという。やはりこの記事に疑問を持った人は少なくないのではないか。

ITmediaはネット界の朝日新聞になりたいのだろうか。

本日のリンク元 TrackBack(1)

2007年06月17日

プッタネスカが美味い

アンチョビペーストを入手して以来、スパゲティ・アッラ・プッタネスカにハマり中。オリーブの種を取り除くのが面倒なので、種除去済みの缶詰を買ってきた。これは便利だ。

写真1 写真2
チューブ入りアンチョビペーストと黒オリーブの缶詰

いつもは手抜きで瓶詰のポモドーロソースを使うところ、新たな調理器具も入手したので、トマトソースから作った。

写真3
最近ゲットした調理器具

以前はトマト缶だけで作ったがせっかく濾し器があるので野菜を入れよう。ここのレシピによると、野菜を大きいまま炒めて煮込んで取り除くという方法があるらしい。

写真4 写真5
野菜をいためてトマトを入れて煮込む

人参半分とセロリを大きめに切って強火で炒め、玉ねぎ1個を微塵切りにして中火で炒めた。400gのトマト缶を2缶、トマトを潰しながら投入し、ローレルとタイムを入れて30分煮込む。

野菜とハーブを取り除いて、さあ、濾し器の出番。ぐるぐる回すだけできめ細かなソースの出来上がり。

写真6 写真7
ゲットした調理器具の出番

スパゲティを茹でながら、フライパンに大蒜の微塵切りとオリーブオイルを入れて弱火にかけ、大蒜の香りが出てきたら、アンチョビペーストを入れて溶かすようにかき混ぜる。唐辛子も入れる。

写真8 写真9

やや強火にして、微塵切りにしたケッパーと、微塵切りにしたオリーブと、輪切りにしたオリーブを投入して炒める。

写真10 写真11

トマトソースを入れて温め、塩を少し入れて味を確認し、茹で上がったスパゲティを絡めて完成。パルミジャーノ・レッジャーノを少しだけすりおろしてかけた。

写真12
完成

美味い。が、初めて作ったときの感動がない。うーん、トマトソースがマイルドになりすぎたか。プッタネスカには酸っぱいソースの方がよかった。玉ねぎが多すぎたか、微塵切りにせずに取り除けばよかったか。

結局、道具を使ってみたかっただけちゃんうかな結果に。次回はトマト缶だけにしよう。

本日のリンク元 TrackBack(1)

2007年06月23日

銀行2.0はまだ来ない

4月に、「IE7ユーザーにいまさらSSL2.0を使わせようとする銀行」というブログエントリを見かけた。それによると、Internet Explorer がバージョン7に移行し始めたことを契機に、「SSL 2.0を使用する」に設定変更するよう指示している銀行があるのだという。Internet Explorer 7がセキュリティ上の理由でSSL 2.0をオフに変更したにもかかわらずだ。

例えば武蔵野銀行は、4月の時点で図1の解説を掲示していた。

武蔵野銀行の解説ページの画面キャプチャ
図1: 武蔵野銀行の「Internet Explorer7をご利用いただくにあたってのご注意」のページの2007年4月時点の内容

Internet Explorer7の場合は「SSL2.0を使用する」がチェックされていない場合が多いのでご注意ください。

他にも山形銀行が同様の解説を掲示していた。いったいどうしてこんなことになるのかと、問題点の指摘がてら、なぜ書いているのか聞いてみた(4月に電話で)。すると、だいたいこういうやりとりになった。

ある銀行:


銀: 画面が真っ白になって使えないという方にご案内しているものでして。

私: それで本当に解決するのですか?

銀: はい。お客様にご確認いただいたもので……

私: それは次の項目に書かれている「cacheのクリア」も試したから直ったんじゃないですか?

銀: いえ……

私: そっちで試してないでしょ。

銀: 直ったお客さまもあるので……

私: 次の項目も一緒に変えちゃったらどれが原因かわからないでしょ?

銀: ……。


別の銀行:


銀: IE 7を導入したら真っ白になったというお客さまが実際にこの設定をすることで直っている。

私: もしかして、2.0 と 3.0 を間違えた人がそう言っているのでは?

銀: 半分の人がこれで解決している。

私: では、SSL 2.0をそちらのサーバでは使用しているのですか?

銀: しばらくお待ちください。……。当行ではSSL 2.0と 3.0を使用しています。

私: そもそも2.0を止めるべきではないですか?

銀: 技術に詳しい者から折り返し電話を……


その後折り返しの電話はなかったので結局本当は何が原因だったのかわからない*1。現在は、武蔵野銀行の解説ページからも山形銀行の解説ページからも、この記述が削除されている。

IE7ユーザーにいまさらSSL2.0を使わせようとする銀行」によると、「SSL 2.0の利用を制限(SSL 3.0へ移行)していることを明示している銀行」というのもあるということだった。どうやら、NTTデータのANSERを使っている地銀等がそのような記述をしているようだ。これはよい。

  • 「山梨中銀ダイレクト」における通信手順SSL2.0 による通信の停止について, 山梨中央銀行, 2006年12月
    さて、今般、「山梨中銀ダイレクト」のサービス提供元である(株)NTTデータから、セキュリティ強化の一環として通信手順SSL2.0 による通信を停止するので、平成19年1月4日(木)以降、通信手順SSL2.0 では「山梨中銀ダイレクト」をご利用いただくことができなくなるとの連絡がありましたので、ご案内申しあげます。
  • 「つるしんインターネットバンキング」における通信手順SSL2.0 による通信の停止について, 都留信用組合, 2006年12月

    さて、今般、「つるしんインターネットバンキング」のサービス提供元である(株)NTTデ ータから、セキュリティ強化の一環として通信手順SSL2.0 による通信を停止するので、平成1 9年1月4日(木)以降、通信手順SSL2.0 では「つるしんインターネットバンキング」をご利 用いただくことができなくなるとの連絡がありましたので、ご案内申しあげます。

  • 荘内銀行 ご利用環境

    3.設定による不具合(2)

    SSLおよびTLS※のうち、SSL2.0には、セキュリティ上の脆弱性があるため、現在は一般的に使用を推奨されておりません。当行でも平成19年1月4日(木)以降、SSL2.0の使用を制限させていただきました。

    (SSL2.0で荘銀ダイレクトにアクセスした場合、画面に「ページを表示できません」(InternetExplorerの場合)や、「接続が突然切断されました」(Netscapeの場合)というエラー画面が表示されます。)

    ○当行推奨環境でご利用の場合は、SSL3.0もしくはTLS1.0が使用可能です。

    ※ SSL2.0とSSL3.0の両方が可能なブラウザで通信を開始した場合、ブラウザとサーバが自動的にセキュリティ強度の高いSSL3.0を選択して動作しますので、SSL2.0を利用しないように設定を変えていただく必要はございません。

ちなみに、「IE7ユーザーにいまさらSSL2.0を使わせようとする銀行」によると、「IE7への言及はないが、SSL2.0にチェックを入れるように説明している銀行」(大昔の記述の名残?)がたくさんあるのだという。ほとんどは、IBMや日立のASPを借りている小さな銀行ばかりだが、ネット専業のイーバンク銀行までもがそんなことを書いているというのには呆れた。

ところで、SSL 2.0とは別の話になるが、いまだにポップアップウィンドウを使うサイト設計をする銀行があって、作っている業者はどこまでアホなのか?と呆れる。4月8日の日記にも書いた常陽銀行は、今年リニューアルオープンしたばかりで、しかも「地銀ITソリューション」という新会社が新たに構築したサイトだ。なのに、普通にIE 6のデフォルト設定で振込みをしようとすると、「ポップアップがブロックされました」となって、これを見ようとすると先に進めなくなる。

振込み先を指定して「次へ」を押したところで図3の画面となる。

常陽銀行の画面キャプチャ
図3: 常陽銀行でポップアップがブロックされる様子

ここで、「ここをクリックしてください」に従い、「一時的に許可」を選ぶと、図4のようになる。

常陽銀行の画面キャプチャ
図4: ポップアップウィンドウを出そうとすると……

ここでキャンセルを押そうものなら、

常陽銀行の画面キャプチャ
図5: にっちもさっちも行かなくなった様子

となって、ブラウザの「戻る」ボタンを押しても同じ画面となり、にっちもさっちも行かなくなる。図4のところで「再試行」ボタンを押すとどうなるかというと、こうなる。

常陽銀行の画面キャプチャ
図6: 「再試行」を選んだときの様子

ここで「再表示」を押すと、図3の画面に戻って、けっきょくポップアップウィンドウの内容は読めない*2。ポップアップがブロックされるのがデフォルトになっていったい何年が経過してると思ってるんだ? こんな作りにしなきゃいい。

*1 原因はもしかして「IE7でWebページを開くと画面が白くなる」のことだった?

*2 ポップアップウィンドウの内容はこのページ

本日のリンク元 TrackBacks(6)

2007年06月24日

ケータイWebはそろそろ危険

これまでの背景と最近の状況変化

安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基本手順は、(パスワードやカード番号などの)重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。

  • ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。
  • ジャンプ先URLを事前に確認したとしても、それが(任意サイトへの)リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。
  • そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセスして(パスワードやカード番号などの)重要な情報を入力しようとした時点で、アドレス確認の重要性に気づくはず。その時点で、そこまでに辿ってきたページのジャンプ先URLが正しかったかを思い出すことはできない。

しかし、これはPCのWebでの話である。携帯電話世界のWebでは話が違ってくる。

携帯電話のWebでは、アドレスバーがないため、入力の直前に確認することがほとんど行われていない一方、携帯電話では「あまり遠くへ行かない」という使われ方をしているため、ジャンプ前に確認する方法で十分に偽サイトの見分けができる状況があった。このことは、3年前の日記「太古の昔、アドレスバーが入力欄でなかったのを知ってるかい?」と「アドレスバーのない携帯電話はPhishing詐欺に耐えられるか」で次のように書いていた。

携帯電話ではほとんどの人が、公式メニューと数件程度のブックマークから直接サイトにアクセスして利用しているだろう。つまりサーフィンをしない。平均ホップ数がかなり小さいと推定できる。

だから、携帯電話にアドレスバーがなくても誰も困らなかったし、疑問を感じなかったのだろう。今見ている画面は、ついさっき意識的に選んだサイトであるに違いないと確信して使っている。

携帯電話の場合、幸いなことにHTMLメールというものがない。そのため、パソコンにおけるフィッシング詐欺のように、見た目には正規のドメインのサイトへのリンクに見えて、ジャンプ先は異なるドメインになるという罠をしかけることはできない。ジャンプ前にURLを確認できるため、ページ表示にアドレスバーがなくても、それによってドメインの錯誤が起きることはないのかもしれない。

この前提に立つと、携帯電話ではジャンプ先URLの偽装ができてはならないことになる。その前提に立って修正されたのが、「au携帯電話のバーコードリーダでジャンプ先URLが偽装される(2005年4月)」の脆弱性だった。

さて、ところが、それから2年ほどが経過し、携帯電話のWeb世界も状況が変わってきた。検索サービスが普及してきたのである。2006年、携帯キャリア各社がそろって検索サイトと提携して、公式機能としてWeb検索を提供するようになった。

この日記のリンク元を見ていても、携帯Web検索から辿り着いた記録が去年から急激に増えていてる。

つまり、公式メニューから数ホップしかジャンプしないとか、2次元コードで読み取ったURLにジャンプするだけとか、メールで指定されたURLにジャンプするだけといった、「あまり遠くへ行かない」という旧来の携帯Webの使い方は廃れつつあり、PC世界のWebと同様に、適当に検索して目的サイトを探すという使い方が普及しつつある。

となると、フィッシング対策もPC同様に必要になってくるはずだ。フィッシングはメールで誘うものだけではない。検索サイトからたまたま流れ着いて来るのを待つという攻撃も現実にあり得る。これは単なる可能性の話ではなく、2005年6月にフィッシング犯の初の逮捕事例が出た際に、次の通り報道されている。

企業のホームページ(HP)に似せたサイトをインターネット上に設け、本物と思いこんでアクセスした利用者の個人情報を盗み取る「フィッシング」をしたとして、警視庁は13日午前、大阪市に住む40代前半の会社員の男を著作権法違反などの疑いで逮捕した。(略)

偽サイトは、本物のマークが「YAHOO!」であるのに対して「YAFOO!」としていた。

(略)「ヤフー」と検索した際、検索結果の一覧で表示されたため、利用者は本物と誤信したらしい。

男は盗み取ったとみられる他人のID番号を使ってヤフーのサイトに接続した不正アクセス禁止法違反の疑いも持たれている。同庁は、約1週間に20〜30人分のデータを入手したとみている。

偽ヤフーで情報盗む、「フィッシング」初摘発 著作権侵害容疑で会社員を逮捕 , 朝日新聞 2005年6月13日夕刊

インターネット上でヤフーの偽サイトを開設し、個人情報を盗み取る「フィッシング」をしたとして著作権法違反などの疑いで逮捕された大阪市の会社員の男が、携帯電話向けにも同社の偽サイトを開設していたことが、警視庁の調べで分かった。同庁は、男がパソコン用のサイトと併設し、より多くのID番号とパスワードを入手しようとした疑いがあるとみている。

(略)パソコン用の偽サイトには、開設されていた約1カ月間に約70件のアクセスがあり、〓〓容疑者は、ログイン画面に入力があった約20人分のID番号とパスワードを不正に入手。このうち、5人分のデータを使ってログインし、メールの内容をのぞき見していたことも判明した。

携帯でも「フィッシング」 「偽ヤフー」を開設 容疑者を初摘発, 朝日新聞2005年6月14日朝刊

EZwebの検索結果になぜかURL表示がない

さて、auのGoogle検索の結果の画面は次のようになっている。図1は例として「三井住友銀行」で検索した場合の画面(2006年12月に検索した際の画面)である。

au携帯電話の画面の写真
図1: auのWeb検索機能で「三井住友銀行」を検索した結果

図のように、auでの検索結果は、「EZweb」と「携帯一般サイト」と「PCサイト」の3つに分けて表示される。これらは上から順に同じページに並べられ、それぞれ数件ずつが表示される。

この検索結果で、右端の「PCサイト」の検索結果(最も下のブロックに表示される)では、トップに現れたのは本物の三井住友銀行であったが、中央の「携帯一般サイト」では、スラッシュドットジャパンのページがトップにヒットしてしまっている。これは、三井住友銀行が「携帯一般サイト」(ページ形式が携帯用で、かつ、インターネットからアクセスできるサイト)を提供していないために起きていると思われる。これはSEO不足というレベルでなく危険な状態にあると言える。

では、フィッシングのターゲットになりかねない組織はすべて、auが言うところの「携帯一般サイト」を用意しないといけないことになるのだろうか? それも酷な話だろう。auのこのような機能の提供は不用意だと言うべきではないだろうか。

さらに、左端の「EZweb」サイトにいたっては、「魔法のメロランド」などというどこの馬の骨ともわからない着メロサイトが「着うた:三井住友銀行」としてヒットしている。上から順に見ていくと(広告欄を除いて)最初に表示されるのはこの部分である。

現時点でも、検索結果は次のようになる。トップは「携帯先ATM(三井住友銀行)」というタイトルのソニー銀行のページ、2番目は「「三井住友銀行」とは 無料Wiki」というタイトルのGREEのページ、3番目は「イー・ローンで一歩先行くローン選び:三井住友銀行のローン一覧」というSBIホールディングズのページである。

しかも、図1をよく見ると、「携帯一般サイト」と「PCサイト」の検索結果では、緑色で「http://slsashdot.jp/...」というようにリンク先のURLが表示されているのがわかるが、「EZwebの検索結果」にはなぜかそれが表示されない。

図2のように、「みずほ銀行」で検索すると、「無料Wiki」のサイトと「みずほ銀行」というタイトルのサイトがヒットするが、このサイトが何者なのかさっぱり不明だ。「東京三菱UFJ」で検索した場合は、トップには掲示板らしきものが現れるが、信用できるサイトなのかわからない。

au携帯電話の画面の写真
図2: auのWeb検索機能で「みずほ銀行」と「東京三菱UFJ」を検索した結果

つまり、「携帯一般サイト」と「PCサイト」については、「ジャンプ前にジャンプ先を確認するという」旧来の携帯Webの利用手順で利用できるのが、「EZweb」サイトについてはそれができないようになっている。アドレスバーを搭載しないのなら、事前にジャンプ先を確認できるようになっているべきところ、なぜ「EZweb」サイトだけわざわざその表示を隠すのか?

これは「脆弱性」とまでは言えそうにないのでIPAには届け出ていないが、昨年12月から今年5月にかけて、3回ほど、「auお客様センター」に電話して、問題の所在と修正すべき点(「EZweb」サイトについてもURLを表示すること)を意見として伝えたが、半年経っても対処されていない。

「auお客様センター」の言い分としては、「EZweb」(と検索結果で分類されている)ページは、EZwebの所謂「公式サイト」であり、一定の審査基準をパスしたサイトであるから、アドレスを表示する必要はないのだという。

「一定の審査基準と言うが、どんな基準なのか見せて欲しい。公開していないのか?」と尋ねると、公開はしていないとのことで見せてもらえなかった。ざっと検索してみるとわけのわからないサイトがいっぱい「EZweb」サイトとして登録されているようだが、どのくらい信用できるものなのだろう?

仮に信用できるサイトだけが登録されているにしても、おそらくそれはサイト単位であって、ページ単位ではないだろう。もし、ページ内容を自由に記述できるユーザページを提供しているサイトが「EZweb」サイトとして登録されていれば、そこに偽サイトを作り込まれる可能性のある場合もあるのではないか。

結局、サイトが本物かどうかはユーザがドメイン名で確認するほかないのだから、ブラウザにアドレスバーを設ける*1なり、ジャンプ先を常に表示するなりの対策を施すべきだ。

NTTドコモとソフトバンクモバイルがどうなっているかはまだ調べていない。

*1 携帯電話のWebは全てゲートウェイを通しているので、そこでコンテンツを書き換えて、URLを表示するヘッダを常に埋め込むといった方法であれば、今すぐ全機種対応で対処できるのではないか。JavaScript非対応機種が前提だが。

本日のリンク元 TrackBacks(5)

2007年06月29日

EZwebサイトでSession Fixation被害発生か?

au booksでの事故

意図的な攻撃でなく偶発的な事故なのかもしれないが、auの公式サービス「au books」のEZwebサイトで、Webアプリケーションの脆弱性が原因の情報漏洩事故が起きたようだ。

  • 顧客情報漏えい:書籍販売サイト「au Books」で, 毎日新聞, 2007年6月26日

    ゲーム攻略本(1冊1890円)の紹介サイトからアクセスし、その攻略本を買おうとすると、他の顧客の氏名、住所、電話番号、生年月日、会員パスワードが表示された。そのまま購入手続きをとると、他の顧客が購入したことになってしまうという。

  • au携帯電話におけるオンライン書籍販売サイト「au Books」におけるお客様情報の誤表示について, KDDI, 2007年6月26日

    1. 発生事象

    本年6月22日20時37分から23日18時45分までの間、特定のリンク元サイトから「au Books」にアクセスしたお客様に対し、同じ時間帯にアクセスした他のお客様の登録情報 (氏名、住所、電話番号、生年月日、会員パスワード) が表示され、場合によっては、自分の情報が他のお客様の情報に書き換わってしまう事象が発生しました。 なお、誤って表示された可能性のあるお客様情報は最大436件、また書き換えられた可能性のあるお客様情報は最大124件です。

    2. 発生原因

    リンク元サイトから、「au Books」にアクセスしてきた同一のセッションIDを持つお客様に対し、「au Books」が、個別のセッションIDを付与できなかったために発生しました。

KDDIの発表に技術的な原因が書かれていて有益だ。この記述から推測するに、session fixationが起きていたのではないか。

対策が完了してサービス再開された後のau booksを訪れてみると、次の構成になっているようだ。

  • サイト内の任意のページに最初にアクセス時点でセッションIDが発行される。
  • 発行されたセッションIDは、cookieにセットされるとともに、URL rewritingにより、HTML中のサイト内リンクのリンク先URLに「;jsessionid=E34C50....」の形式で埋め込まれる。
  • ショッピングカートに商品を入れた後、注文画面に進むとき、登録済みユーザであれば、パスワードの入力を要求される(ユーザ名は要求されない)構成になっている。
  • パスワード認証後、送付先の住所等が表示される。
  • この間、「;jsessionid=E34C50....」はURLにずっと付けられており、値は変化しない。

その他、secure属性の付けられたcookieと、他に数個のcookieが発行されるようになっている。

改修前とどの部分が違っているか(対策により)は確認できないが、以下、事故当時に何が起きたのかを推測してみる。

まず、「特定のリンク元サイトからau Booksにアクセスしたお客様」に限ってこの現象が起きたということから、おそらくそのリンクは、次のように、セッションID入りのURLで記述されていたのだろう。

http://www.au-books.jp/item_detail.html;jsessionid=E34C50...?item_cd=MJ070.....

このリンクを辿ってアクセスするとき、現在の改修後のシステムでは、このセッションIDは破棄されるようだ。もし「JSESSIONID」というcookieに既に値が入っていれば、そちらの値が優先され、アクセスしたページに(URL rewritingで)埋め込まれる次のリンク先のURLには、そちらのセッションIDが埋め込まれる。また、「JSESSIONID」のcookieがまだ存在しない場合には、新たにセッションIDが発行されて、その値がSet-Cookieされ、次ページへのリンクのURL rewritingに用いられる。つまり、URL中の「;jsessionid=E34C50...」の部分は実質的に使用されていないに等しい構成になっているようだ。

これが、改修前では次のように動作していたのではないかと推測する。「JSESSIONID」のcookieがまだ存在しない場合、URLに指定された「;jsessionid=E34C50...」がセッションIDとして認識され、その値が「JSESSIONID」のcookieとしてセットされる――(A)。(あるいは、「JSESSIONID」のcookieが発行されていなかった可能性――(B)もある。)

こうした動作をすると、同じ時間帯にアクセスした複数の閲覧者が、同じ「E34C50...」のセッションIDでアクセスすることになる。ここで、Webアプリの構成が次のようになっていたとしよう。

  • ユーザがパスワードを入力してログインすると、そのときのユーザID*1がセッションオブジェクト内に記憶される。
  • ログイン中に個人情報をDBから引き出して表示する機能のページでは、このセッションオブジェクト内のユーザIDをキーにDBが検索される。

その場合、一人目のユーザ(1)がログインした後に、別のユーザ(2)がログインし、その後にユーザ(1)が個人情報を表示しようとすると、セッションオブジェクト内のユーザIDは(2)のユーザIDに書き換わっているため、ユーザ(1)の画面にユーザ(2)の個人情報が表示されるという事態が起きる(図1)。

説明図
図1: 同一のセッションオブジェクトを複数のユーザが共有してしまった状態
(黄色はセッションオブジェクト、緑は変数を表す)

通常「session fixation」という用語は、この脆弱性を持つWebアプリに対する意図的な攻撃を指して用いられる*2が、不慮の事故によって起きるこうした事態についても、「session fixation」という言葉を使ってよいのではないだろうか。

Session Adoptionに注意

特に、上記(A)のケースは、session fixationの中でも、その一形態である「session adoption」が起きていたと言える。「session adoption」とは、session fixation脆弱性に名前を付けた最初の論文「Session Fixation Vulnerability in Web-based Applications」で、攻撃手法の解説として、指定のセッションIDをブラウザに送り込む方法を列挙している中で定義された言葉であり、次のものを指す。

まず、WebアプリケーションがセッションIDをブラウザのどこに格納させる構成になっているかで分類すると、(a) URL引数への格納、(b) hiddenなINPUTフィールドへの格納、(c) cookieへの格納の3つ形態あるわけだが、(c) の場合に、攻撃者サイトから他のドメイン用のcookieをどうやってセットするのかが問題となる。攻撃対象サイトにクロスサイトスクリプティング脆弱性がある場合にそれを悪用するといった方法の解説がある中、他のケースとして挙げられているのが、「session adoption」である。

Session adoption

Some servers (e.g., JRun) accept any session ID in a URL and issue it back as a cookie to the browser. For example, requesting:
    http://online.worldbank.dom/?jsessionid=1234
sets the session cookie JSESSIONID to 1234 and creates a new session with that ID on the server6. We'll call such behavior "session adoption", due to the fact that the server effectively "adopts" a session ID that was generated by someone else.

6In JRun, it is required that a session with the proposed ID doesn't exist on the server yet in order for the server to return the session ID cookie. This may be different in other systems with similar behavior.

(訳)

セッション養子縁組

いくつかのサーバ(たとえばJRun)は、URLに書かれた任意のセッションIDを受け入れ、それをcookieとしてブラウザに発行し返す。たとえば、
    http://online.worldbank.dom/?jsessionid=1234
というリクエストを出すことは、セッションcookie「JSESSIONID」を「1234」にセットし、そのサーバにそのIDで新たなセッションを作成する6。サーバが実際上、他の何者かによって生成されたセッションIDを「adopt」する(養子にする)という事実から、我々はこのような挙動を「session adoption」(セッション養子縁組?)と呼ぶ。

6JRunにおいては、サーバがそのようなセッションID cookieを返すためには、提出されたIDによるセッションがそのサーバにまだ存在していないことが必要とされる。これは、同様の挙動をする他のシステムとは異なるようだ。

Session Fixation Vulnerability in Web-based Applications, 2002年12月

この脆弱性を持つWebアプリサーバとしてはPHPが最も有名であり、PHPセキュリティ界隈では「session.use_only_cookies をオンに設定する」ことが鉄則として叫ばれている。しかし、PHPだけでなく、上の文献にも書かれているように、J2EEのWebアプリサーバにも同様の挙動をするものがあるらしい*3

au booksのサイトでどのWebアプリサーバが使われていたのかは知らないが、他のサイトでも注意が必要だろう。

ログイン前Session Fixationの対策は?

一般に、session fixationの対策は、次のいずれかを達成すればよい。

  • セッションをfixされないようにする。
  • セッションをfixされても問題がないように、必要なタイミングでセッションIDを振り直す。

セッションをfixされないようにするには、まず1つにsession adoptionが起きないようにすることである。セッションIDの格納場所として前記の(a)や(b)を採用せず、(c)を採用した上で、session adoptionが起きないWebアプリサーバを使う*4。しかし、残念ながらそれだけでは解決しないのが現状である。2006年10月21日の日記に書いたように、ブラウザに「Cookie Monsterバグ」があるとそれができてしまうのであり、ほとんどのブラウザで未解決だからだ。ただし、サイトを構築したドメイン名によっては影響を受けない場合もある。au booksの場合は、「au-books.jp」であるから、第2レベルで確定するので「Cookie Monster」の影響を受けないであろう。また、携帯電話のブラウザの「Cookie Monsterバグ」がどうなっているかは興味深いところだが、まだ調べていない。

セッションをfixされても問題がないようにする場合、最も単純なのは、ログイン後までセッションIDを発行しない(セッションを作成しない)ようにすることであるが、au booksのように、ログイン前からショッピングカートのためにセッションを作成する必要がある場合には、それを採用できない。

そのような場合においては、ログイン直後にセッションIDを振り直すという方法が知られている。しかし、はたしてそれで解決なのだろうか。2006年10月29日の日記「ログイン前Session Fixationをどうするか」に書いていたように、ログイン前の状態をセッションハイジャックされた場合、何かの被害が出ると言えるかが焦点となる。

ショッピングサイトの場合、買い物をしようとしている被害者が、悪意あるサイトからのリンクを辿ってサイトに到着した場合、買うつもりのない商品までカートに入れられていることに気づかずに決済画面に進んでしまうということが起こり得るが、攻撃が成功する確率は低めであるし、はたしてそのような攻撃を誰がしたいと思うか? という疑問がある。

だが、今回の事故では、誰も意図していないのに、数百人もの人が同じセッションを共有してしまう事態が起きたわけだ。これは、リンク元が信頼のおけるサイトだったことがひとつの要因であろう。「攻撃」ではなくても、事故でセッションのfixationが起きれば、誤発注が多発してサービスを中止せざるを得ない事態が生じ得る。

その意味で、少なくとも、意図せずセッションをfixするようなリンクができてしまう事態はいかなる場合も避けた方がよいということは言えそうだ。幸い、session adoptionを避ける方法はあるのだから、Webアプリサーバをそのように設定すればよい。

残る問題は、「Cookie Monsterバグ」を突いてたとえば「.co.jp」全域で有効な「JSESSIONID」を発行するようなサイトが存在する場合であるが、意図的な攻撃でなく、誤設定でそのようなことをしているサイトである場合には、そのセッションIDは固定であるから、(最初を除いて)必ず無効なセッションIDとなっているはず*5なので、存在しないセッションの「JSESSIONID」cookieを無視する(受け入れてしまわない)ようにしておけばよい*6

そうすると最後に残るのは、意図的に特定サイト用の新鮮なセッションIDをコピーしてCookie Monsterでセットしてくる攻撃(まさにsession fixationの典型)であるが、ログイン前でそれをされることがどのくらい困る事態なのかによって、対策しなくてよい場合もあるかもしれない。

サブスクライバーIDをパスワード代わりに使うべきでない理由

このようなsession fixation対策が面倒だという場合、携帯電話特有の対策方法として、サブスクライバーIDを用いる方法が考えられる。

上記の図1でも、ログイン時にサブスクライバーIDを参照してセッションオブジェクトにuseridとして格納したわけだが、それをせずに、view操作の際に直接サブスクライバーIDを参照するようにすれば前述の問題は起きない。これは、サブスクライバーIDがアクセス毎に毎回送られてきているから実現できることだ。

別の方法として、ログイン時にセッションオブジェクトにサブスクライバーIDを記憶し、その後の各ページのアクセス時に、リクエストに含まれるサブスクライバーIDとそれが一致しているかを確認する方法もあり得る*7。それはちょうど、2007年2月23日の日記「携帯電話向けWebアプリの脆弱性事情はどうなっているのか」で参照した、WEB+DB PRESS誌Vol.37に掲載の記事「携帯サイト開発 実践テクニック 2007」にも書かれていたことである。

携帯サイトでセッションを使うときの注意点

携帯ブラウザの場合,Cookieを使うことができませんので,セッションを使う際はどうしてもURLにセッションIDが含まれてしまいます.URLにセッションIDが含まれる場合はセキュリティに注意する必要があります

本人以外がセッション付きのURLにアクセスできないようにしましょう.特に検索サービスにクロールされてしまうと問題は深刻です.個人情報が簡単に検索できてしまいます.

そのため,セッションには必ず端末IDを保存しておいて,特定の端末のみアクセスできるようにしておきましょう.(略)セッションに格納されている端末IDと照合することで,違う端末からのアクセスをチェックすることができます

携帯サイト開発 実践テクニック 2007, 技術評論社 WEB+DB PRESS Vol.37, p.127

改めて振り返ってみると、携帯用Webサイトではこれまでにもたびたび「誤表示」の事故が起きていた。例えば次などの報道があった。

こうした事故は、いわゆる「race condition脆弱性」(メモリ上のオブジェクトが短時間にセッション間で共有されるプログラムミスや、同じ名前の一時ファイルを使用してしまう欠陥などが原因で、高負荷時に発現するもの)によっても起きることが知られてきたが、今回のau booksと同様に、session fixationによって起きていたものもあったのかもしれない。

「携帯向けWebアプリは危ない」という話は以前からいろいろな人から耳にするが、具体的なことが表立って語られることがほとんどなく、安全な実装が普及しないという問題があった。

上のWEB+DB PRESS誌の記事の著者は、session fixationによる誤表示の問題が実際に起きていることを知っているがゆえに、「URLにセッションIDが含まれる場合はセキュリティに注意する必要があります」と書いたのかもしれない。

その対策方法として、サブスクライバーIDを用いることが書かれていたわけだが、私はその方法をお勧めしない。auの場合にはcookieがサポートされているのだから、cookieを使って、PC向けサイトと同様に対策をすればよい。(au booksはおそらくそのように対策されていると思われる。)

サブスクライバーIDを使わないべきなのは、次の理由による。

サブスクライバーIDは、ユーザに固定の固有IDであり、どのサイトにも同じ値が送信されるものであるため、国民総背番号制に対して示される懸念と同様のプライバシー上の問題がある。そのうえ、ワンクリック不当請求などに悪用される差し迫った現実の危険性も存在するため、できるだけ早く廃止すべき仕組みである。もし、携帯Webアプリの脆弱性に対してサブスクライバーIDを頼りに対策するサイトが増えると、廃止すべき仕組みを廃止しようにも廃止できなくなってしまうのが問題だからだ。

そしてもうひとつ理由がある。

WEB+DB PRESS誌の記事では、次のようにも書かれていた。

端末認証

登録が必要なサイトの場合,利用する際にはログインが必要です.ID/パスワードを毎回入力するのでは,携帯の場合では特に面倒です.

そこで携帯ならではの認証方法として,現在の端末では取得が容易にできる端末自体の情報(端末ID)を利用します.

携帯サイト開発 実践テクニック 2007, 技術評論社 WEB+DB PRESS Vol.37, p.126

これに対し私は2007年2月23日の日記「携帯電話向けWebアプリの脆弱性事情はどうなっているのか」で次のように書いた。

そもそも、「ID/パスワードを毎回入力するのでは携帯の場合では特に面倒です」などといって、端末IDをパスワード代わりにしてはいけない。端末IDは他のサイトにも同じものが送信されるのだから、パスワード代わりになどならない。

これはひとつには、同日記の脚注1にも書いていたように、この記事には、キャリアのIPアドレスからのアクセスであることの確認の話は書かれていなかったことも問題であるわけだが、もうひとつ、次の理由がある。

SSLの利用を必要としているサイトを想定してみる。携帯電話でもSSLは利用されている。携帯電話のWebにおいてどこに盗聴のリスクがあるかというと、キャリアのゲートウェイからWebサーバまでの通信路が主であろう。そこに本当に盗聴のリスクがあるのか? という疑問を抱く人がいるかもしれないが、携帯電話でSSLが必要とされているサイトがあるのは事実である。

その場合に、サブスクライバーIDをパスワード代わりに用いるのは明白に脆弱性と言える。なぜなら、図2のように、通信路上の盗聴者はパケットを改竄するなり、あるいは独自のIPパケットを送出することにより、キャリアのIPアドレスからの任意のサブスクライバーIDを送信することができてしまうからだ*8

説明図
図2: 通信路上の攻撃者がキャリアのIPアドレスからの任意のサブスクライバーIDを送信する様子

これができてしまうのは、サブスクライバーIDが攻撃者に既知となるためである。

こうした事態を避けるには、ランダムに生成されるセッションIDをcookie(secure属性を指定した)に入れてSSLで通信すればよい。PCのWebでは普通そのように実装されている。

問題は、cookie機能がサポートされていない、NTTドコモなどの携帯電話であろう。iモードでは、cookie機能がないため、URLにセッションIDを入れることが広く行われているようだ。それは、前述の(B)および(a)のタイプの構造であり、session fixationに弱い。

NTTドコモは早くcookieをサポートするべきだ。携帯Webの危うさは、NTTドコモがcookieをサポートしないことが主要因ではないのか。EZwebと同様に、ゲートウェイにcookie機能を作りこめば、全端末に対応できるのではないのか。

*1 このサイトではユーザ名が存在しないので、EZwebのサブスクライバーID (最近では「EZ番号」と呼ばれるようになった)がユーザIDとして用いられていると思われる。

*2 図1で言えば、User(1)が攻撃者でUser(2)が被害者とすると、(User(1)のloginは省くことができ、)User(2)がログインしたころを見計らって、User(1)がviewの操作をするとUser(2)の個人情報を意図的に盗むことができてしまう。

*3 上記文献の脚注6には、JRunでは存在しないセッションのセッションIDが指定されたときだけこの挙動をするとされているが、他の製品ではそうではない(いつでも受け入れてしまう)ことが示唆されている。

*4 EZwebでは、cookieをサポートしているので、この対策を採用できる。

*5 偶然に有効なセッションIDに一致してしまう確率はゼロではないが、当てずっぽうのセッションIDでセッションハイジャックできる確率と同じはず(セッションIDが暗号学的に安全な擬似乱数生成器で生成されていれば)なので、無視できる。

*6 domain属性の異なる同名の「JSESSIONID」cookieがリクエストに送られてくることになるので、全部をサーチして有効なものだけ使うようにするか、あるいは、セッションを開始する際に、domain属性が「.co.jp」などのcookieを消すSet-Cookieをするようにしておく対策が考えられる。

*7 これにより、セッションハイジャック全般を防止できるわけだが、それは、そもそもセッションIDすらいらないことを意味する。サブスクライバーIDをセッションID代わりに使えばよい。つまり、セッションオブジェクトをサブスクライバーIDで参照するように、Webアプリサーバを作ればそれが可能である。

*8 これができないというのなら、SSLもいらない。

本日のリンク元 TrackBacks(3)

2007年06月30日

「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る

ワンクリック不当請求が問題となり携帯電話事業者各社が「お知らせ」を発表した2004年夏、8月29日の日記で総務省の「次世代移動体通信システム上のビジネスモデルに関する研究会」について少し触れた。実はもっと詳しく書くべき興味深い内容があったのだが、あまり言うのもいやらしい(せっかく解決に向けて動いて頂いているようなのに)という事情が当時はあったため、その後何もしていなかった。いまさらではあるが、これについて書き留めておく。

2000年に旧郵政省が「次世代移動体通信システム上のビジネスモデルに関する研究会」を開催していた*1。2001年に総務省情報通信政策局が報告書を公表している。

当時この研究会の成果は、垂直統合化しつつある携帯電話ビジネスに対して、「公正な競争」の観点から「オープン化」が求められるとした指摘が注目を浴びたように記憶している。「iモードメニュー」などのいわゆる「公式メニュー」が、他の事業者もサービスできるようになっていなければ公正でないということから、後にこのオープン化は実現されている。

  • IMT-2000ビジネスの成功に不可欠なもの, 松本敏明, IT Pro 記者の眼, 2000年10月30日

    (略)既に日本のiモードなどモバイル・インターネットでの成功は,世界中から驚きの目を持って受け止められている。これをIMT-2000という高速サービスにまで持ち込めれば,まだ先行きが不透明な日本経済の建て直しの大きな柱になるというシナリオすら描ける。

    公平性の確保が最大の懸案事項に

    そこで気になるのは事業者の動きだ。例えば,モバイル・インターネットで最大のシェアを持つNTTドコモはiモードのビジネス・モデルを,そのままIMT-2000に持ち込もうとしている。これまでiモードのビジネス・モデルは,クローズゆえに成功した部分が大きい。iモードのブラウザに表示される公式メニューや料金回収代行サービスなどがその一例だ。

    公式メニューはiモードのコンテンツを紹介するもの。ブラウザが必ずアクセスするこのメニューに参加できるのとできないのとでは,アクセス数に大きな差がでる。

    料金回収代行はコンテンツ事業者に代わって,コンテンツ利用料をユーザーから回収してくれるサービス。インターネットの世界で未だ定着していない少額課金の仕組みを実現している。しかしこのサービスを提供できるのもiモードの公式メニューの座を獲得できた企業だけだ。

  • iモードのオープン化を巡る議論, ITmedia, 2001年7月18日
  • 「iMenu」で他プロバイダのメニュー表示。ドコモがiモードのオープン化具体策, 日経IT Pro, 2002年1月28日

    NTTドコモは1月25日,インターネット接続事業者(プロバイダ)がiモード利用者に対してiモードと同等のサービスを提供できるようにするため,網接続インタフェースを公開した。総務省が2001年に打ち出したブラウザフォン・サービスのオープン化指針に応えたもの。

    (略)NTTドコモは2001年3月に,iモード網を他プロバイダに2003年3月までに開放すると表明していた。「対応設備の開発が順調に進んだので,若干前倒して,2002年11月から接続試験を始めることにした」(立川社長)。

  • ISP,iモードと同様のサービス提供が可能に──ドコモが条件公開, ITmedia, 2002年1月25日
  • NTT Com、iモード網を利用した「MOBILEWING」の詳細を発表, ケータイWatch, 2003年3月10日

当時の私は、EZwebのサブスクライバーIDの問題に気づいていなかったため気づかなかったのだが、2004年になってこの報告書を読んだところ、この研究会でその問題が指摘されていたことを知った。

  • 「次世代移動体通信システム上のビジネスモデルに関する研究会」第4回 議事要旨, 総務省, 2001年2月

    ・第三者的な機関が提案されている背景として、第一には、利用者にとって個人情報を安心して預けられるサイトであるという仕掛けをつくらなければいけないということがある。第二には、通信キャリアにとって、ユーザIDを開示していいサイトかどうかいうこと、第三には、制作コストの回収、料金回収代行や広告等による回収手段が制作者に与えられるということがある。また、認定されたサイトを常に監視するWatchDogやADRの機能も必要になるかも知れない。

    ユーザID開示の問題については、早急に検討を進める必要がある。これに対して、個人情報保護全体については、基本法案の動向などを踏まえつつ、取り組んでいくことが重要なのではないか。

    ・ユーザが自分で簡単に課金先を指定できる仕組みがあればいいのだが、それができないので、皆困っている。それにはユーザIDなり端末IDの開示が必要で、そうすれば、コンテンツプロバイダ側で課金システムを構築できるようになる。

  • 「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書, 総務省, 2001年6月

    第6章 ビジネスモデル発展に向けた情報の取扱いルールの確立
    1 個人情報の取扱いルールの確立
    (1)個人情報の取扱いの現状

    モバイルインターネット上でビジネスを展開する事業者にとって、通信キャリアのゲートウェイに集まるユーザの閲覧履歴情報(ログ)92や通信キャリア等が独自に収集する個人の属性情報などは、マーケティングに有用で、その取得、利用を希望する声は、数多い。

    従来、個人情報の取扱い93は、基本的に通信キャリアとユーザ間の問題であったが、ビジネスモデルの多様化によって関係者が増加する方向にあり、個人情報の保護の問題が複雑化している。また、新しいサービスが登場し様々な新技術が利用されるようになると、新たに保護しなければならない個人情報が現れることもある。しかし、このようなビジネスモデルの多様化、関係事業者の増加を踏まえた、モバイルインターネットにおける個人情報の取扱いルールは整備されているとは言えず、早急に確立する必要がある。

    個人情報の取扱いに関しては、プライバシー上の問題だけでなく、社内利用や特定の者に対する提供への懸念が公正競争上の問題を惹起している。

    (略)

    2 ユーザID提供
    (1)ルール整備の必要性

    ユーザIDとは、携帯電話の電話番号ごとに固有に割り当てられる変数をいう。各通信キャリアでは、それぞれのゲートウェイサーバでユーザIDを生成、保管している。ユーザIDは、電話番号それぞれに固有に対応しており、認証や決済サービスを伴うビジネスモデルを立ち上げる上で有用な情報として、コンテンツプロバイダによる認証99や通信キャリアの料金回収代行サービス100において活用されている。ユーザIDとその通信履歴情報を紐付けすることで、自社サイトへのアクセス状況の分析やユーザ情報との紐付けによる傾向分析が可能になるほか、セッション管理が容易になるなど、認証や決済サービス以外にも有効な用途は、数多い。

    一方、ユーザIDそれ単体では個人を特定することはできないものの、ユーザ情報との紐付けを行うことで、悪意ある者がユーザの意向に反して個人情報を利用してプライバシーを侵害することも技術的には難しくないようで、ユーザIDを無差別に提供することの危険性も指摘されている。

    このような機能と特性を持つユーザIDに関しては、NTTドコモやJ−フォンが自らが採択した「公式」サイトのみにユーザIDを提供しているのに対し101、KDDIでは全てのコンテンツプロバイダに対して提供するなど、通信キャリア間で取扱いに差異があるのが現状である。また、最近では、ユーザの個別の同意確認をシステムに組み込み、端末製造番号をコンテンツプロバイダに送信する端末も出現している102

    ユーザIDの取扱いについては、近年のモバイルインターネットの普及やIMT-2000 で期待されるビジネスモデルの高度化、多様化といった現状を踏まえる一方で、ユーザの利益を保護する観点から、個人情報保護のみならず「通信の秘密」確保という法益にも配慮し、ユーザIDの特性とユーザに及ぶリスクの可能性を十分に検討しなければならない。ユーザの同意のあり方を含めた、ユーザIDに係る取扱いルールを早急に確立する必要がある。

    脚注:

    99 コンテンツプロバイダは、以下の手順により、ユーザIDを活用した認証を行っている。 ユーザが有料コンテンツを登録する際、通信キャリアのゲートウェイで電話番号を変換して生成されたユーザIDを、コンテンツプロバイダへ送出。 コンテンツプロバイダは、ユーザが入力したパスワードとともに、ユーザIDを認証情報として活用。

    100 コンテンツプロバイダはユーザIDとログに基づいて通信キャリアに課金の請求を行い、通信キャリアは自らが保有するログを確認の上、端末IDから電話番号と照合してユーザに代金請求を行っている。

    101 NTTドコモでは、守秘義務契約を締結の上、「公式」サイトにユーザIDを開示している。J−フォンでは、「公式」サイトにのみ仕様開示している送出要求に基づき、ユーザIDを開示している。

    102 NTTドコモの503iシリーズの端末で実施。ユーザIDが電話番号に対応しているため、機種変更をしても変わらないのに対し、端末製造番号は端末自体に対応しているため、機種変更を行うと番号も変わるという特徴がある。

    (2)問題解決への方策

    アンケート等の簡単な方法で個人情報をデータベース化し、インターネット上の行動とそのデータベースを結びつけるのにユーザIDを用いれば、本人の知らないうちにプライバシーに立ち入ることができる。電話番号から生成されるいわゆるソフトIDに関しては、専門知識のある人ならIDから電話番号を簡単に解析できる。ハードIDは電話番号とは無縁なので、電話番号が解析されることはないが、追跡等を受けるリスクは、ソフトIDと替わらない。

    「個人情報の保護に関する法律案」の下では、ユーザの個人情報を、その「同意」を得ずに通信キャリアがコンテンツプロバイダ等に提供することは原則違法である。ユーザIDは、同法律案の個人情報に該当することから、ユーザの「同意」なしにはコンテンツプロバイダ等に提供できない性格の情報である。一方で、ユーザIDは、ユーザが便利なサービスを受けようとすると、コンテンツプロバイダ等に提供を要する情報である。したがって、一律の提供禁止や、煩わしいだけの「同意」取付けは、ユーザの利益に反することから、ユーザにとって分かりやすく信頼に足りる「同意」に関するルール作りとその実践が求められている。

    ユーザの「同意」は、当該ユーザが提供に伴うリスク等を理解、承知した上で行われる必要がある。少なくともそうみなし得るのに十分な手続き等が措置されていなければならない。このような手続き等を現実の利用シーンに単純に反映させると、煩雑で面倒な操作が必要になり、サービス価値を著しく減殺し、単にユーザを遠ざけるだけに終始しかねない。

    ユーザの「同意」に関するルールは、ユーザが被るリスクをできるだけ小さくしながらも、手続きが煩わしかったり余計なコストが生じたりしてユーザの利益に反するようなことのないようにすることが望ましい。

    個人情報の保護と利用をバランスさせるルールの下で、ユーザIDに限って提供を可能とし、先の評価システムの構築を通じてルールが遵守される仕組みを迅速に構築することを目指すべきであろう。ユーザの「同意」を約款で取り付けるために評価システムをうまく使えば、対策拡大に伴うユーザ保護はもちろんのこと、今日通信キャリアが抱えているリスクを軽減することができるはずである。

    現在のモバイルインターネットのモデルの単純な否定ではなく、公正性や安全性の点で不十分な点を評価システムの導入で補完する視点が大切である。

当時、この研究会の報告書案に対してパブリックコメントが募集され、提出意見の中に次のものがあった。

  • 報告書(案)に対する意見募集に寄せられた意見書, 総務省, 2001年6月26日

    5 ジェイフォン東日本株式会社
    2. ユーザID について

    ユーザID に関しては報告書(案)にも述べられているとおり、ユーザのプライバシーと密接な繋がりがあるため、その取り扱いについては十分慎重であるべき。現在、ドコモやJ-フォンが公式サイトに限ってユーザID を提供しているのもそのためである。ユーザID に強いセキュリティをかけることはキャリアとして今後も更に検討して行くべき事項だが、現在のシステムを改善することによってサービス全体のコストが高くなりすぎるのも、小額コンテンツを取り扱うと言う点からは現実的ではない。

    コンテンツ提供者自身はユーザID を直接不当に利用するものではなくても、獲得したユーザID を他者に転売するなどして利益を稼ごうとするものは存在しうるし、社員管理の徹底がなされていない企業では不心得な社員による情報の流失も十分想定される。

    このような事態を踏まえた上でどのような方法で第3社機関が審査を行うのかまたは審査が可能なのかは重要な問題である。

    勿論、料金回収代行とセットになる可能性が高いので不足の事態が発生した場合の措置については料金回収代行と同様の措置が必要となるが、プライバシーの重要性を考慮するとより慎重にならざるを得ない。

「原則違法」とまで言われたKDDIは、このパブリックコメントに意見書を出しているが、ユーザIDの件について触れていない。

私は、こうした経緯があることを知らないまま、2002年8月、セキュリティホールmemoメーリングリストに次のことを書いた。これは2002年7月にauの携帯電話に「料金情報が漏れてしまう」という脆弱性が発覚した際に、KDDIが「個人が特定できる情報が漏れることはありません」と嘘の発表をしたことを契機にこの問題に関心を持ったためだった。

このとき、スラッシュドットで次のように謂れのない中傷をされた。

  • 非公式サイトにも契約者ID垂れ流しのEZWeb, スラッシュドットジャパン, 2002年8月7日

    Re:なんでいまさら? (スコア:0)
    Anonymous Coward のコメント: 2002年08月07日 16時15分 (#141383)

    最近auは調子がいいのでdocomo(またはdocomoマンセーな人)が
    煽り始めただけだったりして


    Re:なんでいまさら? (スコア:0)
    Anonymous Coward のコメント: 2002年08月08日 0時58分 (#141722)

    産総研ってDoCoMoから寄付金受けてたりしてな

当時、なぜここまでの反発を受けるのだろう?と疑問に思ったのだったが、既に総務省の研究会であのような議論(「NTTドコモはちゃんとやっているのに、KDDIは違法なやり方をしている」という趣旨に読める)がされていて、業界の利害対立真っ只中にある話題だったということだったんだなと、2004年にこの報告書に気づいたとき思った。

上のパブリックコメントには、「ユーザID」の問題について至極真っ当な解決策の提案も出されていた。

  • 報告書(案)に対する意見募集に寄せられた意見書, 総務省, 2001年6月26日

    2 株式会社ジェイティービー

    −Cookie 機能の検討について−

    1.概要

    「次世代移動体通信システム上のビジネスモデルに関する研究会」WG1の最終回でももし上げましたが、次世代移動体通信システムにおいても、PCのブラウザーで一般的に利用できる、Cookie の利用を規定(限定)して、Cookie の一部機能を利用できるような仕様として、次世代移動体通信機能システムの仕様としての規定を検討していただきたい。

    (略)

    3.利用のメリット

    1) コンテンツ提供サイドでは、Cookie を利用することでセッションを管理するシステムを作成することが容易になり、安価に制作できる。そのため、一般のインターネット上のコンテンツを若干の手直しをすることで、次世代移動体通信システムのコンテンツとしても提供できることが可能になる。これにより、コンテンツ量の拡大と利用者の利便性増大が期待でき、かつ、安価にサイトを運営できるため、利用者自身に利益を還元できることにもなる。

    (略)

その後この議論はどうなったのだろう?と調べてみると、別の研究会ですぐに、「ユーザID」の問題として議論されていた。

  • ユーザID の開示と個人情報の保護について(第3回研究会のためのディスカッション・ペーパー), モバイルコンテンツビジネスの環境整備の方策に関する研究会事務局, 2001年3月8日
  • 「モバイルコンテンツビジネスの環境整備の方策に関する研究会」(第4回会合), 総務省, 2001年4月20日
  • 同 資料2-1 「ユーザID、料金回収代行サービスの提供に関する評価システムの構築に向けて」(事務局)

    ユーザIDの提供について

    I 問題の所在

    (要約)

    個人情報保護法案の下では、通信キャリアがコンテンツプロバイダ等に利用者の個人情報を、その「同意」なしに提供するなら原則として違法。

    ユーザIDが入手できれば、アンケート等の簡単な方法でデータベースを構築し、ユーザIDを個人情報と連結してインターネット上の行動等を当人の知らないうちに追跡できる。

    3 電話番号から生成されるいわゆるソフトIDに関しては、専門知識のある人ならIDから電話番号を簡単に解析。ハードIDは電話番号とは無縁なので、電話番号が解析されることはないが、追跡等のリスクはソフトIDと同じ。

    4 ハードIDは、端末の買替えの度にこのIDを変更してもらう必要があり、UIMカードが普及すれば、端末の共用や他人への譲渡も普通に行われるため、問題。

    5 ユーザIDは、利用者が便利なサービスを受けるために有用で、一律の提供禁止は利用者の利益に反しかねない。利用者にとって分かりやすく信頼に足りる「同意」に関するルール作り等が重要。

    II リスクの説明責任

    (要約)

    利用者の「同意」は、当該利用者が提供に伴うリスク等を理解し、承知した上で行われるべきもの。少なくとも法令上そうみなされる手続き等が必要。

    2 このような手続き等を現実の利用シーンに反映すると煩雑で面倒な操作が必要で、少額課金サービスに関しては、サービス価値を著しく減殺し、単に利用者を遠ざけるだけに。

    3 利用者の「同意」に関するルールは、利用者にとってリスクが小さく、しかも手続きが煩わしくない合理的な内容にする必要。

    III 現実への適用

    (要約)

    1 通信キャリアによる個人情報の提供は、通信キャリアでないコンテンツプロバイダ等では収集できないか、収集できるにしても面倒な手続きが発生するためコンテンツを簡便に利用したい利用者の利益に反するケースに限って、利用者の「同意」を条件に行われるようにする必要。

    2 具体的には、個人情報の保護と利用をバランスさせるルールの下で、ユーザID(ソフトID)に限って提供可能とし、ルール遵守の仕組みをうまく構築。

    IV 評価システムの特徴

    (要約)

    日本のモバイルインターネットの一つの特徴は、米国や欧州と違ってソフトIDを電話番号から生成して通信キャリア自身が安全と判断する者に対して提供する(ソフトIDを「公式」サイトに限り提供する)方法が広く普及。

    利用者からの「同意」を簡略化する一方で、個人情報の保護にも配意して対象を限定する方法(NTTドコモ、J-フォンの場合。KDDIは対象を限定していない)は、リテラシーの低い低年齢層をはじめインターネットに馴染みの薄い利用者への急速な普及を可能にした一つの要因。

    このような方法は、ひとたび社会的問題が発生すると、その責任追求が通信キャリアに向かう構造でもある。責任の所在が曖昧なままで、少なくとも法的責任はないとする事業者の認識と利用者の一般的な認識との間には大きなギャップが現存。

    IV ユーザID提供に適用されるルール

    (要約)

    1 ユーザIDの提供を受けるサイトは、社内に個人情報保護に関する運用基準を有している等の一定の要件を備える必要。個人情報保護法案との整合も重要。

    2 評価システム確立のための4つのポイント。
    1 行政等からの独立性
    2 ルールメイキングの透明性
    3 外部の審査/監査の導入
    4 コンテンツプロバイダ等の参加のインセンティブ

  • ユーザID、料金回収代行サービスの提供に関する評価システムの構築に向けて(案), モバイルコンテンツビジネスの環境整備の方策に関する研究会事務局, 2001年5月22日
  • 「モバイルコンテンツビジネスの環境整備の方策に関する研究会」報告書, 総務省情報通信政策局, 2001年6月26日

2001年の時点で既にここまで真っ当な検討がなされていたわけだ。

しかし、その後の総務省は、具体策として「モバイルコンテンツ評価システム」なるものの検討を進め、ユーザIDを通知してもよいコンテンツプロバイダを審査する独立機関を設立する方向での検討をしたようだ。

現状を見るに、これらで提起された問題は何ら解決された様子がない。この「総務省デザイン」に対しては以下のように否定的な意見が寄せられていたようだ。

  • 「モバイルコンテンツ評価システムの構築に向けた総務省デザイン」に関する意見募集結果, 総務省, 2002年1月22日
  • 同 NTTドコモ 意見

    検檻押Д罅璽ID通知の対象

    課題・疑問

    ・ユーザID通知において、IPの種類に応じて審査対象を変更させることが、現実的なのか
    - ユーザID通知後にIPが個人情報を収集し始める可能性がある
    - 善意で収集した個人情報が悪意の第三者によって悪用される危険性がある
    - 事後監視で摘発しても、IPに既に渡ったユーザIDを回収するのは困難

    提案

    ・ユーザIDを通知するかどうかは、ユーザ保護の観点から保守的に検討すべき
    ・従い、全てのIPに対し評価機関による事前審査と事後監視が必要であり、それを可能とするシステムの構築を検討すべき
    ・事前審査項目として最低限必要となるものは
    - 顧客情報を適切に管理しているか
    - システムセキュリティは確保されているか
    - 商行為や業務は適切かつ適法か

  • 同 ジェイフォン 意見

    K椒轡好謄爐梁仂櫃砲弔い
    【弊社意見】
    ネットワーク事業者とCPとの間の「ユーザID(若しくはそれに準じる個別ユーザを特定する為の情報)の送信」や「料金回収代行サービスの提供」に関する関係は、携帯電話事業者に特化したものではなく、PHS事業者、固定系事業者、その他ISPとCPとの間にも共通するものである為、本システムをより有効的に機能させ、且つ より広範な社会的支持を得る為にも、モバイルコンテンツに特化したシステムとして立ち上げるのではなく、当初よりインターネット上のコンテンツ全般に対する評価システムとして立ち上げるべきと考えます。

    抑止効果について
    【弊社意見】
    弊社では本年( 2002 年)以降発売予定の移動機よりユーザIDを移動機内部に蓄積する機能を搭載することを予定しており、弊社側でユーザIDの通知を一律停止することが不可能となります。これは、ユーザIDの開示に関し事業者として当該システム提供の社会的責任を負うことで整理しております。

    このように、今後、端末側の機能とネットワーク側の機能との区分がより複雑化していくことが想定され、ネットワーク事業者側でユーザIDの通知を一律停止することが技術的にも困難となって行くことが想定されます。

    つきましては、ルール違反サイトの抑止効果については、こうした状況を踏まえて、当面回収代行サービスの停止のみを対象とするなど、更なる検討を行って頂きたいと考えます。

    尚、ユーザIDの通知は、利用者個々の意志に基づき実施されるものと理解しており、現状弊社のサービスにおいては、必ず利用者個々の意志確認を行った上でユーザIDをCPに通知することとしております。

  • 同 日本テレビ 意見

    ユーザIDの通知や料金回収代行サービスの提供及び当該サービスの停止は携帯電話事業者とコンテンツプロバイダ等との契約に基づくものである。

    ユーザIDの通知、料金回収代行サービスの提供を行うコンテンツプロバイダ等を携帯電話事業者が選別する現在の方法が、コンテンツプロバイダ等を不公正に取り扱うものであるならば、独占禁止法等の既存の法令等を適用することにより是正されるべきである。また、情報の受信者が発信者により権利を侵害されたと主張する場合は、民法や不正競争防止法、既に成立したプロバイダ責任法等の既存の法令等により対応すべきであり、本評価システムを導入したとしても、この基本的な構造は変わらない。

    現在でも星の数ほどあり、今後も増え続けるサイトを評価機関が監視し続けることができるのか、実効性に疑問がある。逆に、実効性を持たせるとすれば、表現行為に対する大きな萎縮効果が懸念され、看過できない。仮に、膨大な数のサイトを監視し続けるとした場合、評価システム運営のためにかかるコストが大きく膨らみ、関係者が負担するコストがビジネスの許容範囲内に収まらなくなることを懸念する。

    さらに、委員会の委員の構成、委員会・評価機関の運営方法をみると、本評価システムの中立性に疑問がある。

    インターネットが全世界において爆発的に普及した理由のひとつは、「規制がないこと」である。本評価システムに対してその設立動機は理解するものの、実体はモバイルインターネットコンテンツの制作、流通の円滑化をむしろ阻害してしまうことを懸念する。

    よって、本評価システムの導入には慎重であるべきと考える。

その後、2004年にはワンクリック不当請求が社会問題となる。

そして2005年になってようやく、KDDIはサブスクライバIDの非通知設定を可能とする対策をとった。

この設定は、サイトごとに設定できるといったものではなく、全サイト一括で通知か非通知かの選択しか与えられていない。非通知に設定変更するときに現れる警告文の通り現実的な有効性性に欠ける対策で、アリバイ的対策にすぎない。

その後どういう議論になっているのか、調べてみたところ、「IP化の進展に対応した競争ルールの在り方に関する懇談会」で次のやりとりがあったようだ。

  • IP化の進展に対応した競争ルールの在り方に関する懇談会(第4回)議事概要, 総務省, 2006年2月22日

    構成員: モバイル・コンテンツ・フォーラム(以下MCF)の資料やインフォシティの資料では、キャリアが上位レイヤーに進出する場合の懸念が示されているが、例えばNTTドコモのiモードのオープン化についてはかつて議論がなされ、いったんは解決されたと認識していたが、当時と何か状況が変わったのか。また、具体的な問題点があれば指摘していただきたい。

    KDDI株式会社: MCF資料の2頁にあるモバイルコンテンツ市場の売上高は、すべてコンテンツプロバイダの売上げであり、キャリアの売上げはない。当社は、プラットフォームを提供しているのみである。

    次に、9頁の認証システム(ユーザID)の開放については、当社はユーザIDをコンテンツプロバイダに開放している。ユーザIDは、メールアドレスとセットになると個人情報に該当するのではないかということで個人情報保護の観点からグレーであるが、コンテンツプロバイダからの要望により開放している。

    さらに、ホームボタンの実装義務化については、当社端末でキャリアボタンを長く押せばユーザが任意に設定したポータルに飛ぶことができる仕組みとなっている。当社としては、端末についても開放を進めてきていると認識。

    ボーダフォン株式会社: 補足すると、コンテンツ利用料は少額であることから、料金回収代行を携帯電話事業者が行っており、携帯電話事業者は回収代行手数料を収受するのみで、利用料自体はそのままコンテンツプロバイダの収入となる。コンテンツは、優良のものを提供しているのであればよいが、コンテンツプロバイダによってはアダルト系などのコンテンツを提供することがある。当時は、こうしたコンテンツを無闇にキャリアが提供することは、公共サービスの観点から問題であるとの議論があり、コンテンツを公式なもの(キャリア公認のもの)と一般のものに分け、公式のもののみ料金回収代行を行っていた。また、当時は、このような公式サイトのみ料金回収代行を行うのは不当な差別的取扱いではないかと議論になったこともあった。

    (中略)

    MCF: (略)端末のホームボタンについても、端末ごとに操作方法が異なるとプロモーションもできないので、共通仕様を決めてほしい。

    ユーザIDについては、メールアドレスが付随すれば個人情報となってしまうかグレーであるが、認証情報自体が直ちに個人情報に該当するとはいえないのではないか。パソコンのクッキーの運用ガイドラインにおけるのと同様の扱いをすることも可能ではないかと考える。

この「MCF」という団体は、ずいぶんと技術音痴な発言をしている。「パソコンのクッキーの運用ガイドラインにおけるのと同様の扱い」などと、cookieの仕組みさえ理解していないようだ。cookieと「ユーザID」の違いを理解していたらこんな発言になりようがない。

このモバイル・コンテンツ・フォーラムという団体は、「mcf.to」というトンガ王国のドメインにWebサイトを構えるというあたりからして不見識ぶりが垣間見えるが、先月にも、「ネットワークの中立性に関する懇談会」で次の資料を提出していた。

  • 新しい競争ルールの在り方に関する作業部会(第6回)資料4-5, モバイル・コンテンツ・フォーラム, 2007年5月11日

    ユーザーIDは識別情報(Identification)でユニーク性を提供するだけで個人情報等は含まない。

    モバイルコンテンツビジネスでは、少額の課金システムが実現されたため、月額定額(100円〜300円)のユーザー課金モデルが急速に拡大した。

    このモデルを成立させるためには、ユーザーに負担を掛けない認証システムが必要条件である。携帯電話ではアクセスした顧客を認証するためにユニークにユーザーを特定すうる識別情報としてユーザーID(PCではCookieで同様な機能を実現)を利用している。

    現状、ユーザーIDは、一部キャリアを除いて一般サイトでの利用は不可能である。

    プラットフォーム機能のオープン性の確保として識別情報(ユーザーID)の開放が必要

    ●時系列認証

    現在、携帯電話のコンテンツビジネスで主流になっている月額定額制のサブスクリプションモデルを実現するためには、簡易な認証で契約期間中の利用を認証する事が必要条件。そのためにはユーザー識別システム(ユーザーID)の開放が必要である。

    ●メディア列認証

    ユビキタス環境のコンテンツビジネスでは、一度の認証で携帯電話、PC、放送等のメディアを横断して利用できるシングル・サインオンの実現が求められている。そのためにはユーザー識別システム(ユーザーID)の開放が必要である。

    ●キャリア列認証

    ナンバーポータビリティが実現されるが、コンテンツポータビリティは、提供されておらず、キャリア変更にともないユーザーとCPとのコンテンツ提供契約は強制解約される。ユーザーIDの開放と、ユーザーIDのポータビリティを実現することで、コンテンツポータビリティも実現する必要がある。

この意見は、2001年当時の総務省の議論をまるで理解していない。

「必要条件」だの言っているが、それは必要(必須)ではない。他の方法もあるからだ。それはつまり、cookieを導入することである。EZwebでは既にゲートウェイでcookieを導入しており、NTTドコモもソフトバンクも同様のことが可能であろう。

「月額定額制のサブスクリプションモデルを実現するため」に、「ユーザーIDの開放」は必要ではない。クレジットカード番号を登録することで同じことはできるし、クレジットカードを持たない若年層にも使わせるにはEdyなどのプリペイド方式の適用も考えられるだろう。サイトごとにユーザが課金用情報の登録をするのが面倒だというのであれば、課金サービスをキャリアとは独立した事業者が行うという方策(IDは課金サービス単位となる)も検討するべきだろう。

つまり、PCと同じようにするだけの話だ。PCで少額課金が成功していないからといって、PCのアーキテクチャが不向きなのが原因という結論には直ちにはならない。携帯電話で少額課金が成功した背景に課金アーキテクチャ以外の理由(PCは無料が先にあるのに対し、携帯電話で有料なのは仕方ないという利用者の認識など)も考えられる。ボタンを押していくだけで本人確認とする仕組みは、cookieがあれば、「ユーザIDの開放」がなくても実現できる。

「PC、放送等のメディアを横断して利用できるシングル・サインオンの実現……のためにはユーザーIDの開放が必要」などとは噴飯ものだ。そんなものは英語圏では即座に消費者団体のボイコット運動になる愚かな発想である。PC世界では、シングルサインオンのためにLiberty Allianceのプロジェクトがあったわけで、SAMLなどが策定されてきたところだ。そういう仕組みが選択可能であるにもかかわらず、「ユーザーIDの開放」すなわち、全てのサイトにユーザIDを送信するなどという最も単細胞な方法を求めるなどというのは、技術音痴も甚だしいと言わざるを得ない。モバイルコンテンツ業者でフォーラムを結成しているくらいなら、そういう解決技術案を作って提案したらどうか?*2 技術者は参加していないのか?

2002年の「モバイルコンテンツ評価システムの構築に向けた総務省デザイン」という方向性はスジが悪かったと思う。キャリアとは独立に複数の課金サービスが登場して、課金サービス事業者がそれぞれ独自にコンテンツプロバイダを選別するのが理想形ではないか。利用者が課金サービスを選べばいいし、複数の課金サービスを1つの携帯電話で同時に使用したっていいわけだ。そのとき、2002年のジェイフォンの提出意見にあったように、「モバイルコンテンツに特化したシステムとして立ち上げるのではなく当初よりインターネット上のコンテンツ全般に対する(略)システムとして立ち上げるべき」というのも正しい指摘だった。

今後、NGNの登場で、またこの種の問題が再燃しそうな気がするが、NGNにおける課金システムはどう設計されているのだろうか。既にいろいろあると噂レベルでは耳にするが、情報が公開されていないため、誰も公に口にできない状況のようだ。

ちなみに、蛇足だが、2001年の「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書案に寄せられた意見の中に、ヤフー株式会社の頓珍漢な主張があった。

  • 報告書(案)に対する意見募集に寄せられた意見書, 総務省, 2001年6月26日

    13 ヤフー株式会社

    Q7について
    【意見】ユーザーIDの提供対象を無条件に拡げる危険性がある点については異論はありません。しかし、IPV6 によって個別PC毎に利用端末をIPアドレスによって特定することができる環境が間近であること等も考慮し、個別に適否を判断するよりも法律等によって利用者一般に個人情報保護に関する義務を課すなどの方策を講じていくことが望ましいと考えます

IPv6は、クライアント側の個別PCがIPアドレスで特定されてしまわないよう、anonymousアドレスの使用と、上位アドレスの割り当て方法の工夫をしていかなければならないものである。こういう「しかたない」といった発想の技術音痴によって個人のプライバシーが蔑ろにされていくことがないよう、消費者は監視していく必要があるだろう。

関連

*1 専門部会の座長は米澤先生だった。

*2 「ユーザIDの開放が必要である」って、お前らクレクレ厨か?

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

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