最新 追記

高木浩光@自宅の日記

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

2003年08月01日

「できることをできるだけやる」

5月25日の日記で、RFC 3041: 「Privacy Extensions for Stateless Address Autoconfiguration in IPv6」の基となったInternet Draft「Privacy Considerations for the Use of Hardware Serial Numbers in End-to-End Network Protocols」の著者であるKeith Moore氏のことを書いた。Jack Dongarra教授と私の勤務先とは、Grid Computingの研究業界で以前から親しい。

このことについて、UTKに長期出張中の同志社大の廣安先生から反応があった。「Knoxvilleの風を感じて」の最新号として「ブロッグと技術者の本能」(このリンク先はしばらくするとここのURLへ移動すると予想される)が掲載されていた。ここには、後半で、

山根 信二さんが自身のページで、「技術者がプライバシーについて議論し、技術的にどこをどうすればいいのかを判断した例。」として Keith MooreInternet Draft を挙げられていてびっくりしました。 Keith Moore は私の隣の隣の隣に住むICL の住人なのです。

廣安知之, Knoxville の風を感じて - ブロッグと技術者の本能 -

という文脈の下で、Keith Mooreにインタビューなさったそうだ。彼の応答として以下が紹介されていて興味深い。

「その当時のポジションがそのような問題提示と解決をすることができる立場にいたから当然のこととしてやったのだ。」...

「IETF は政府とは独立したグループであり、そういう問題提示と解決を行うことも目的の一つなのだ。」...

Keith へのインタビューで彼は直接には言いませんでしたが、「できることをできるだけやるのだ。」という姿勢も感じ取れました。 Knoxville の風を感じて - ブロッグと技術者の本能 -"

事業部と研究所の乖離

上の廣安さんの文にある、「日本では技術者は本当に技術だけを取り扱い……役人が決めるという意識」という点については、若干異論もある。「技術者」といってもいろいろな立場の人がいる。民間の業界で組織する研究会やフォーラムで標準化仕様が議論されたりすることがあるが、このとき結論に力を及ぼすのは事業部の技術者たちであろう。例えば、今後、ネット家電のプライバシー問題がどうなるかは、彼らの問題認識に一任されているかもしれない。

それに対して、「技術者はそのような判断をするものではない」といった考え方をしがちなのは、研究者たちではなかろうか。研究屋の仕事スタイルは、「所属する」学術コミュニティの中での共通認識として設定されている「課題」を、演繹的にもしくは実験による実証で「解く」という作業の繰り返しだ。本当にその「課題」が重要なのかといったことは、問われない場合もあるし、いくらでも理屈付けが可能なこともあるので、コミュニティに積極的に参加して、「課題」を肌で感じ取って仕入れてくれば、あとは知恵と労力と資金とで仕事を進めることができる。

研究屋の仕事はある意味、技術のカタログをただひたすらせっせと作り散らすことかもしれない。学会発表はいわば「ガレージセール」で、使えるか使えないかは見た人に決めてもらえばよいというスタンスだ。この場合、研究屋は「判断をする立場ではない」ということになる。というか、「説明は果たしたので、あとは見る人が判断できるはずだ」と期待して、「それ以上のことをする必要がない」という立場だろうか。これは、研究屋の美学でもあるかもしれない。

しかし、そのガレージセールをいったいどれだけの事業者が関心を持って見ているだろうか。学術コミュニティ内で暗黙的に設定されている「課題」を、事業部の技術者が理解するだろうか。

「できることをできるだけやる」というのは、研究者的な仕事スタイルだとも言える。本当に必要かどうかとは別に、可能な技術的追求をやっておくというものだ。

最近、プライバシー問題関連で、あちこちの大手企業の研究所の研究者と話して感じたのは、研究所と事業部とが乖離してしまっているのではないかという疑念だ。研究者は、「課題」を鼻で嗅いでくることこそが生きていく糧であるから、社会にとって何が問題とされているか(問題となり得るか)を知っている。(自分のものとして考えたか、伝聞として知っているだけかは別として。)その一方、直接社会に影響を及ぼす立場にある製品開発部門の技術者は、その問題の存在自体を聞かされたことがないという状況があるのではないか。

それを特に感じるのは、日本の携帯電話の分野だ。携帯電話のインターネット対応の歴史を振り返ると、技術の本質を理解しないまま、見よう見まねでそれっぽくインターネットの技術を取り入れ、独自拡張したり独自サブセットを作ったりしてきた。そこにある仕様は、汚らしい、洗練されていないものだったりする。たいした議論をすることもなく、見識の低い数人程度の技術者がホイホイと決めてしまったように見えるものが散見される。

「プライバシー問題を避けるためには固定IDに代わる技術が必要である」という認識は、情報セキュリティ関連の研究者であれば、学術コミュニティの共通認識として肌で知っているはずだ。それが事業部の技術者には届かない。たいした議論もなく数人で決めてしまうような仕様に固定IDが盛り込まれる。研究者は事業部から期待されていないのか、あるいは、研究者に事業部に働きかけるメリットがないのか。

この話は、「事業部」を「行政府」に置き換えても同じだ。

本日のリンク元 TrackBack(0)

2003年08月02日

様式作成事務員の行動原理

少し前の話になるが、ある国立大学から講演を依頼されたときのことだ。担当教官の秘書さんから、出張手続きのための書類が送られてきた。謝金を振込んでもらうため、銀行口座を伝える書類には、通帳のコピーを添付せよと書いてある。

過去に別の国立大学からも通帳のコピーを求められたことがある。後で聞いたところによると、かつては全国の国立大学でそれを必要としていたが、最近では多くの大学で廃止した制度だそうだ。当然ながら、民間や学会の講演で謝金を受け取るときに、通帳のコピーを求められたことなど一度もない。

ちょうど忙殺されて逃避ネタに飢えているところだったので、今回は、その大学の事務本部に電話して、「なぜ通帳のコピーが必要なのか」を問い合わせてみた*1。すると、「書類に書かれた口座番号に記載ミスがないか確認するため」で、それ以外の目的には使用しないのだという。当然ながら、本人認証という意味合いもない。金を受け取る側が、ニセ口座を書くわけがない。

そんなクダラナイことのために一々通帳をコピーさせているのかと激怒した。金を受け取るために口座番号を書くのは、自分にとって重大な局面なのだから、番号を間違えないよう何度も確認しながら慎重に書いてきた。その労力は無駄なものだったわけだ。

通帳のコピーを提出するというのは、そうたやすいことではない。ATMが普及して以来、普段、通帳を持ち歩くことはない。通帳は盗まれないよう安全な場所に厳重に保管しているだろう。それを持ち出して、職場のコピー機のところへ持っていき、帰宅するまで安全に保管しなくてはならない。

そのように苦情を述べて、提出を拒否すると言ってみたところ、事務本部の担当責任者は、あっさり、「それでは出していただかなくても結構です」と即答した。追求してみると、通帳のコピーは「できればお願いしたい」というレベルのものであって、必須ではないという。

書類を届けてくれたのは、担当教官の秘書である末端のアルバイトさんだ。アルバイトさん曰く、通帳のコピーなしに学科事務室(本部と教官との間の中間組織だ)に提出すると、書類に不備があるとして突き返されるのだという。「できれば」の手続きが、いつのまにか必須ということになってしまっている。いかにもありがちな話だ。国立大学の学科事務室というのは、この世で最も思考力を失った公務員集団ではないかという、かねてよりの思いを今回さらに強くした。

しかも、「通帳のコピーを添付せよ」と書いてある紙には、こういう但し書きもあった。

最近のネット銀行など、通帳のない銀行の場合は、キャッシュカードのコピーを提出してください。

おいおい、それだったら、全員キャッシュカードでいいだろう?

ようするに、「私の銀行には通帳がないのですが?」という問い合わせが過去にあって、それに対応して、「その場合はキャッシュカードで代用する」という申し合わせになったのだろう。実際には、口座番号を確認するだけが目的なので、キャッシュカードで十分であり、通帳である必然性がない。だったら、「通帳またはキャッシュカードのコピーを」と書くべきだ。そういう思考が連中には欠如している。例外的な事例が発生すると、小手先の対処で乗り切り、本質的な解決をしようとしない。そもそも何のための手続きなのかから考えることをしない。

民間ではこういうことはあり得ない。少しでもお客さんに面倒をかける手続きにすると、客を逃してしまう。処理の確かさと簡便さのトレードオフは、常に経営努力として追及されているだろう。だが、国立大学にそうした手続きを簡略化させる方向の努力目標は存在しない。客である他大学の教官や民間からの講師など、それぞれに少しずつの不便をかけながらも、それぞれの客は、文句を言うよりもその場の作業を言われるがままに片付けてしまった方が時間が少なくて済むので、誰からも改善を指摘されることはない。

この出張では、もうひとつ、履歴書を提出せよとの指示があった。非常勤講師にでもなるなら履歴書の必要性も理解できるが、単発の依頼講演で、履歴書を書く必然性が理解できない。この点も、大学事務本部に電話で問い合わせた。すると、謝金の金額を算定するために、年齢と、最終学歴、学位、職歴、現在の職業と役職を見るのだそうだ。つまり、送られてきた履歴書様式にある、生年月日、本籍地、現住所、性別、古い学歴、電話番号、活動や賞罰などの記入欄の内容は、貴重な時間を費やして一所懸命に書いても、全く無駄に終わるのだ。「性別で謝金額を算定するのですか?」「本籍地で算定するのですか?」「電話番号は何に使うのですか?」と追求すると、答えに窮していた。

ようするに、本来ならば謝金額算定専用の必要最小限の記入項目を設けた様式を用意するべきところ、その仕事をサボっているわけだ。履歴書を出させておけば十分であるから、客の労力を無駄にしてでも、自分たちは考えることをサボる。それが様式作成事務員の行動原理だ*2

こうした事務屋は、とりあえず集められるものは集めておけという発想で仕事をする。怠惰な事務屋だけでなく、作業に凝り性な事務屋も、「あと他に何か書くことないかなー」というノリで、様式に罫線を沢山入れ、ありったけの思いつく限りの記入項目を作っていく。記入する人のことなど考えてはいない。あくまでも見る人のことを考えて、罫線を引いていく。

この話は、プライバシー問題の本質とも関係する。必要のない個人情報を収集してしまうのが誰による仕業で、なぜ起きるのか? という問いに対するひとつの答えだ。

*1 担当教官の秘書さんに迷惑がかからないよう、匿名で。

*2 その点、産総研の事務方は有能で、研究職員の作業の最小化の追求に余念がなく、とても助かっている。ありがたい。

本日のリンク元 TrackBack(0)

2003年08月03日

「重要でない」と「保護する」の二枚舌

ここ数か月、複数の行政官や民間事業者の当事者と面と向かって議論を重ねたことで、固定IDの問題がどうしてこうも解決困難なのか、その根源的要因が見えてきた。

既に何度も指摘してきたように、固定IDの使用を推進する立場の人たちが「問題ない」という主張をするとき、ある人は、ある文脈、ある時刻において、「IDは重要な情報ではない」ということを言う。

無論、それ単体では個人名まで特定できない使用者の使用履歴情報などは個人情報には該当せず、そうした情報を商品に添付しておくことには何ら問題がないことはいうまでもない。

経済産業省, 商品トレーサビリティーの向上に関する研究会中間報告書

EPCには固有のコード番号が記載されているだけで、それ自体は重要な意味を持ちません。

無線タグ上のEPCは製品などのアイテムを認識するためのもので、人を認識するためのものではありません。そのためこのシステムでは、購入された商品と購入者を結び付けることは出来ませんので個人情報は保護されていると言えます。

オートIDセンターQ & A

サブスクライバーIDからお客様の個人情報というのは一切わからないようになっている。

ツーカーセルラー東京コールセンター

Q. 対応サイトごとにユーザ証明書が必要になるのですか?
A. ユーザ証明書は全ての対応サイトで共通です。ただしサイト側で利用者を制限している場合はこの限りではありません。

Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか?
A. ユーザ証明書にはお客様の名前や電話番号等個人情報が記載されていません。ユーザ証明書だけでは個人情報が流出することはありません。

FirstPass Q & A

その一方で、別の人が、もしくは、同じ人が別の文脈で、あるいは単に別の時刻において、「法律で保護すればよい」ということも言うのだ。

万が一の場合は、事後的に司法を通じて問題を解決する方法もあり、対策のコストと事後解決のコストの比較衡量が欠かせない。

泉田裕彦, 非接触ICタグ(RFID)とプライバシー:〜書き込み型RFIDの問題とネットワークの活用〜

泉田さんのお話の中で、... そういうところについては法的な縛り、もしくは事故があったときは訴訟で解決するといった案が出ていましたけども、

日経新聞社世界情報通信サミット2003 ミッドイヤー・フォーラム における泉田氏の発言を高木が繰り返した発言

そういう行為(名簿業者がIDリストを売る行為)は法律で禁止すればよいのです。

CSEC/ISEC合同研究会でのある方の発言

「○○IDだけでは個人情報が流出することはありません」というのは、○○IDが個人情報ではないという定義を前提とした主張であり、「不正に利用されたら罰すればよい」という主張は、○○IDが個人情報であるという定義を前提とした主張だ。

彼らは、あるときは、「○○IDは個人情報ではない」としながら、別のときは「○○IDは(個人情報だから)法律で売買を禁止すればいい」と言うのだ。この両方を、同じグループの別の人が同じ場で言ったこともあるし、同じ人物が(違う時刻に)言ったことすらある。また、研究者は後者を主張し、広報担当者は前者を主張するということもあるだろう。彼らは、文脈や時刻や場や発言担当者が違っていれば、同時には成立しない主張でも矛盾はないと思い込むことができるらしい。

素人さんがそういう発言をするのはいたしかたないことであるから、そういうときは私も懇切丁寧に説明を試みるだけで全然平気なのだが、行政官や研究者がそういう発言をしてくると、正直、頭に血がのぼってしまう。「あなた、よくその仕事してますね」という言葉を喉で押し殺しながら、冷静さを必死に保とうとする自分に苛立ってしまうからだ。涙すら浮かんでしまう。

一般に、プライバシーの問題は、問題ないという意識の人によって問題が作られる。問題のない情報だという認識だからぞんざいに扱われる(蓄積される)のであり、蓄積されたことによって問題のある利用が可能になる。

「固定IDは漏れてはならない重要な情報だ」という共通認識を作る以外に、この問題は解決しようがないように思える。しかし、消費者には「○○IDだけでは個人情報が流出することはありません」と説明されている。

この話は、住民票コードをめぐる議論にも共通する部分がある。2月にこういう報道があった。

銀行口座の開設時などに提示を求める本人確認書類として、一部の金融機関が住民基本台帳ネットワークシステム(住基ネット)の11けたの住民票コードが記載された「通知票」を利用していたことが分かった。総務省は、住民票コードの民間利用を禁止した住民基本台帳法に違反する疑いがあるとして、全国銀行協会(全銀協、会員186行)に利用停止を求めた。

毎日新聞, 金融機関が住民票コード通知票使い本人確認, 2003年2月15日

この報道を扱ったスラッシュドットのストーリーに、次のコメントがあった。

住民票コードを使っていたわけではない (スコア:2, すばらしい洞察)
postel のコメント: 2003年02月16日 3時16分 (#260016)

元ネタ [mainichi.co.jp]には

郵送した住民票コードの通知票には氏名や生年月日も記載されていることから、運転免許証やパスポートと同様、本人を確認できる公的書類として紹介。
とあります。
つまり、住民票コードそのものを本人確認に利用したわけではないのです。
それ以前に、住民票コードだけでは金融機関は本人確認できませんよ。
なぜなら住民票コードが正しいのかどうか金融機関には調べられませんから。
ここからは推測にすぎませんが、金融庁・全銀協ラインで官公庁発行のもので、住所・氏名・生年月日が記入されている物をリストアップした際に、今回問題となった通知票もたまたま含まれていただけで、そもそも住民票コードは気にかけなかったのでは?

スラッシュドットジャパン, 金融機関が住民票コード「通知票」で本人確認?, 住民票コードを使っていたわけではない

「金融機関が住民票コードを入手しても、その番号から誰かを調べることはできない」というのは、住基ネットへのアクセスが行政府に限定されているからということなのだろう。しかし、「調べることができない」のは、あくまでも「初期状態」での話だ。

「調べられないのだから問題ない。だからいいじゃないか」と言って、金融機関が住民票コードつきの書類を収集、蓄積していくと、徐々にそれが「調べられる」ようになっていく*1。蓄積したデータを使ってだ。

気にかけずに集めてしまうところにこそ、固定ID問題の解決困難さがある。日本では住民票コードの民間利用を住民基本台帳法で禁止した。この規制を設けたのは、とても適切な判断だったと思う。住基ネット反対派は、「この程度の罰則では、禁止しても使うところが出てくるから意味がない」と言うかもしれないが、それは的外れだ。民間利用の禁止は、悪意ある人を想定したというより、善良な民間事業者が無自覚のうちに収集してしまうことの防止を意図したものだろう。法律とは、悪意ある人を罰するためだけにあるのではなく、それが社会的不利益をもたらすと気づかずにやってしまう人を減らすためにもあるのだろう。

昨日の日記「様式作成事務員の行動原理」にも書いたように、無自覚な事務屋はそこら中にいる。それが事務屋の習性なのだからしかたない。法律で縛るしかないのだろう。

国の定めたIDを国が利用を規制するのは妥当だとして、民間の使用するIDまで法で規制するのはどうかという話もある。法規制が強すぎるのであれば、技術的解決策があることを技術者が示していくしかなかろう。

「固定IDを使う仕組みは筋の悪い技術だ」という考え方を「技術者のたしなみ」としたいところだ。少なくとも研究者の間では、このたしなみなくしては恥だということにしたい。

というか、既に恥でしょ? 何をいまさら。

*1 金融機関の本人確認なのだから調べる必要があるじゃないか」というのは別として、ここでは単に論理矛盾を指摘している。

本日のリンク元 TrackBack(0)

2003年08月06日

まだこんなことを言っている人がいるとは

これ以上どう説明したらいいのか……。いくらここで正論を説明したところで、強大なマスメディアの広報力の前には無力だ。

本日のリンク元 TrackBack(0)

2003年08月08日

「他の情報と容易に照合することができ」とは

岡村久道先生の「個人情報保護法入門」を読んで同法について少し勉強中。同法のポイントがわかりやすく整理されており、そのように制定された背景の根拠や、残された課題も解説されている。技術屋にも読みやすいかもしれない。まだ三分の一ほどしか読んでいないところなのだが、まずは「個人情報」の定義のところに興味深い点があった。

個人情報保護法(平成十五年五月三十日法律第五十七号)では「個人情報」を次のように定義している。

この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

個人情報の保護に関する法律 第二条 第1項

こうした「個人情報」を定義しようとする法文は、この個人情報保護法だけでなく、職業安定法(昭和二十二年十一月三十日法律第百四十一号)や、労働者派遣事業法(昭和六十年七月五日法律第八十八号)、港湾労働法(昭和六十三年五月十七日法律第四十号)、クローン技術規制法(平成十二年十二月六日法律第百四十六号)などにもみられるのだそうだ。

この法律において「個人情報」とは、個人に関する情報であつて、特定の個人を識別することができるもの(他の情報と照合することにより特定の個人を識別することができることとなるものを含む。)をいう。

職業安定法 第四条 第9項

個人情報(個人に関する情報であつて、特定の個人を識別することができるもの(他の情報と照合することにより特定の個人を識別することができることとなるものを含む。)をいう。以下同じ。)を適正に管理し、及び派遣労働者等の秘密を守るために必要な措置が講じられていること。

労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律 第七条 第1項の三

個人情報(個人に関する情報であつて、特定の個人を識別することができるもの(他の情報と照合することにより特定の個人を識別することができることとなるものを含む。)をいう。)を適正に管理し、及び派遣労働者等の秘密を守るために必要な措置が講じられていること。

港湾労働法 第十四条 第1項の四

第六条第一項又は第九条の規定による届出をした者は、その届出に係る特定胚の作成に用いられた胚又は細胞の提供者の個人情報(個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と照合することにより、特定の個人を識別することができることとなるものを含む。)をいう。以下この条において同じ。)の漏えいの防止その他の個人情報の適切な管理のために必要な措置を講ずるよう努めなければならない。 
 ヒトに関するクローン技術等の規制に関する法律 第十三条

同様に、行政機関保有個人情報保護法(昭和六十三年十二月十六日法律第九十五号)、警察個人情報保護法(平成二年六月八日国家公安委員会規則第二号)では、

個人情報 生存する個人に関する情報であつて、当該情報に含まれる氏名、生年月日その他の記述又は個人別に付された番号、記号その他の符号により当該個人を識別できるもの(当該情報のみでは識別できないが、他の情報と容易に照合することができ、それにより当該個人を識別できるものを含む。)をいう。ただし、法人その他の団体に関して記録された情報に含まれる当該法人その他の団体の役員に関する情報を除く。

行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律 第二条 二

個人情報 個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述又は個人別に付された番号、記号その他の符号により当該個人を識別することができるもの(当該情報のみでは識別することができないが、他の情報と容易に照合することができ、それにより当該個人を識別することができるものを含む。)をいう。

警察の保有する電子計算機処理に係る個人情報の取扱いに関する規則 第三条 一

としている。

これらの定義にはほとんど同じ文章が使われているものの微妙に異なっているところが興味深い。職業安定法、労働者派遣事業法、港湾労働法では、

特定の個人を識別することができるもの

となっているのに対し、クローン技術規制法では、

当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの

と、特定の個人を識別する方法について言及する文が追加されている。さらに、行政機関保有個人情報保護法と警察個人情報保護法では、

当該情報に含まれる氏名、生年月日その他の記述又は個人別に付された番号、記号その他の符号により当該個人を識別できるもの

と、個人別に付された番号、記号、符号のことが付け加えられている。

また、括弧書きされている部分について比べてみると、職業安定法、労働者派遣事業法、港湾労働法、クローン技術規制法では、

(他の情報と照合することにより、特定の個人を識別することができることとなるものを含む。)

となっているのに対し、行政機関保有個人情報保護法と警察個人情報保護法では、

当該情報のみでは識別できないが、他の情報と容易に照合することができ、それにより当該個人を識別できるものを含む。)

と、「当該情報のみでは識別できないが」が挿入され、「識別することができることとなるもの」が、「容易に照合することができ、……識別できるもの」という表現になっている。

この行政機関保有個人情報保護法は全面改正され、行政機関個人情報保護法(平成十五年五月三十日法律第五十八号)に置き換わったらしい。

この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

行政機関の保有する個人情報の保護に関する法律 第二条 第2項

(なぜか、法令データ提供システムには出てこないので、上の引用では総務省のページへリンクした。)

これを改正前と見比べると、「又は個人別に付された番号、記号その他の符号」が削られ、「当該情報のみでは識別できないが」のくだりがなくなり、「他の情報と容易に照合することができ」が「他の情報と照合することができ」に変更されている。

これと、個人情報保護法を比べてみると、

この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

個人情報の保護に関する法律 第二条 第1項

となっており、「容易に」が追加されている点だけが異なっている。

このことについて、岡村先生の「個人情報保護法入門」には、

本項において容易性が要件とされた趣旨については、行政機関個人情報保護法は行政機関が保有する個人情報を対象とすることから、より厳格な個人情報保護が必要であるから、容易性を要件とすることなく、保護される個人情報の範囲を広くする必要があるのに対し、民間の場合には営業の自由への配慮から個人情報をある程度限定することが必要であると考えられたことに基づくものとされている(衆議院個人情報の保護に関する特別委員会議録平成15年4月21日(第7号)中の宇賀克也・東京大学大学院法学政治学研究科教授の発言)。

と解説されている。

しかし、容易であるかそうでないかは、具体的にどのような違いなのだろうか。

岡村先生の解説には、

なお、インターネット接続プロバイダはアクセスログ(通信履歴)をとっているが、会員のIDと連動して照合しうるようなデータ形式で管理している。したがって、インターネット接続プロバイダの中では容易に会員個人を特定することが可能であるが、外部の者にとっては特定できない。住民基本台帳コードで特定された場合であっても同様であり、一般人には照合が困難であるが、同コードにアクセスできる者にとっては容易である。

こうしてみると、照合対象となる「他の情報」が、誰でも照合可能なものである必要がある絶対的なものなのか、それとも特定の者だけに照合可能なものでも足りる相対的なものであるのか、「他の情報と容易に照合すること……により特定の個人を識別することができる」の解釈をめぐって、なお問題が残されていることを指摘しておきたい。

とある。

たしかに、インターネット接続プロバイダのIPアドレス発行履歴のように、「内部の者であれば容易」という点で考えることもまず重要だが、加えて、外部の者にとっての容易性は、「誰でも照合可能か否か」だけでなく、携帯電話のサブスクライバーIDやRFIDの固定ID(や固定のIPアドレス)のように、中間的な場合を考える必要がある。つまり、「特定の者」≠「内部の者」となる場合がある。あるいは「内部」とはどういう範囲なのかだ。

たまたま来たWebアクセスに含まれていたサブスクライバーIDや、たまたまカウンターの前に来た人のRFIDタグのIDは、受信した者がそのIDの発行者でなければ「外部の者」であるが、ID保有者の情報を過去に(もしくは未来に)別の正規の手段で入手していたなら、容易に照合することができ、特定の個人を識別できる。しかし、他の人たちにとっても「容易に照合できる」かどうかはわからないわけで、その受信したIDを個人情報として扱う必要があるか否かは、情報(ID)の渡し先が他に何の情報を持っているかを確認しない限り、定まらないのではなかろうか。

本日のリンク元 TrackBack(0)

2003年08月09日

ツーカーセルラー東海から回答書がきた

7月9日の日記「ツーカーセルラー東海に期待」に書いた、ツーカーセルラー東海*1に対するサブスクライバーIDに関する問い合わせに対し、回答書が送られてきた。その内容は以下の通り。(「2002年」となっているのは原文のまま。)

2002年8月1日
高木様
株式会社ツーカーセルラー東海
お客さまセンター

拝啓 季夏の候、時下ますますご清祥の段、お慶び申し上げます。

平素はひとかたならぬ御愛顧を賜り、厚く御礼申し上げます。

先般は、サブスクライバーIDについてのお問い合わせをいただきまして、ありがとうございました。お問い合わせについて、関係部署と相談を致しました結果を以下のとおり回答させていただきます。

サブスクライバーIDは、モバイルインターネットをより快適にご利用いただけるよう、お客様の利便性を高めることを第一の目的として提供してきたものです。

それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありませんので、コンテンツプロバイダー(以下「CP」)への提供自体に問題はないと考えております。

それを取得したCPが個人情報と結びつける等、CP側の管理方法によっては、相対的なものとして個人を特定できる情報になり得ることは認識しておりますが、この場合、当該CPがその収集した個人情報に対する管理責任を果たすべきだと考えております。

しかしながら、ご指摘のような悪意のCPが違法に当該情報を利用する事態も想定されることから、ユーザ保護の観点からは、その利便性とのバランスも勘案しつつ対策を検討していく必要があると感じております。

EZwebサーバーを実際に管理・運営しているKDDIにおいてもご指摘の事象については認識しており、その対策について検討を行っていると聞いております。状況ご斟酌頂き、何卒ご理解賜りますよう宜しくお願いいたします。

敬具

まずは、「KDDIにおいてもご指摘の事象については認識しており、その対策について検討を行っていると聞いております。状況ご斟酌頂き、」とされている点を評価したい。「今すぐやめよ」と言っても無理であることは重々承知だ。重要なのは、こうしたシステム設計がダメであることを(少なくとも技術者と経営責任者の)皆が認識し、将来に同じような問題を生み出してしまうのを避けることである。

しかし、この回答書は、私の質問に答える形式になっていなかった。よくあることだが、個別の質問に答えるのを避けて、自らの主張をに述べるだけということがよくある。そうならないためには、質問を Yes / No 形式で示せばよい。今回も Yes / No 形式で質問したのだが、無視されてしまった。

お客さまセンターに再度電話し、1か月前の私の質問がどうなっていたかを確認したところ、以下のようにしっかりと箇条書きの文章としてセンターに記録されていた。

(1) サブスクライバーIDは個人情報であるか。

(2) コンテンツプロバイダーとの契約において、サブスクライバーIDは個人情報であるので、厳重に管理し外部に漏らさないとの契約はあるか。

(3) 非公式サイトに対してサブスクライバーIDを送信するのはプライバシーの問題があるのではないか。

(4) 非公式サイトへのサブスクライバーIDの送信を止める機能はあるか。EZweb@mail を一旦削除して登録しなおす方法以外に、サブスクライバーIDを変更する方法はあるか。

(1)と(3)については回答を得られたと言える。(1)については、

個人を特定できる情報ではありません

とあるので、「個人情報ではない」という回答だ。(3)についても、

コンテンツプロバイダー(以下「CP」)への提供自体に問題はないと考えております

とあるので、「問題ない」という回答だろう。ただし、(問題はないが)対策を検討しているということのようだ。

これに対し、(2)と(4)の回答は得られなかった。

(2)は、質問にミスがあった。「サブスクライバーIDは個人情報であるので」という前提付き質問なので、前提が否定されたため回答されなかったのかもしれない。改めて、コンテンツプロバイダとの契約について尋ねておいた。

公式コンテンツプロバイダと通信事業者の間の契約には、エンドユーザ(消費者)の個人情報に関わる何かしらの契約条項があるのではないかと考えられる。あるのであれば、通信事業者は、消費者に対して、コンテンツプロバイダとの契約内容を開示する義務があるのではないか。そのような契約がないのであれば、「ない」ことを開示してくれればよい。

(4)について回答してくれなかったのはちょっと理解できない。質問しているだけなのだから、「そのような機能はありません」と回答してくれればよい。ましてや、「プライバシーの問題」はないという回答なのだから、「そのような機能はありません」と答えるのをためらう理由はなかろう。

サブスクライバIDは法律でいう「個人情報」に該当するか

ツーカーセルラー東海の回答では、

それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありません

となっているが、これを、行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律 第二条と比べてみると、

当該情報に含まれる氏名、生年月日その他の記述又は個人別に付された番号、記号その他の符号により当該個人を識別できるもの

とあり、数字や記号が「個人情報」となるかが両者の間で違っている。後者では「個人別に付された番号」とあり、サブスクライバーIDが「個人別に付された番号」であることは自明であるが、前者では「個人別に付された」という事実があえて書かずにおかれている。

検索してたまたま見つけたのだが、自由民主党本部のプライバシーポリシーには次のように書かれている。

個人情報とは、以下の情報により特定の個人を識別できるものをいいます。

  • 氏名、年齢、性別、住所、電話番号、職業、メールアドレス
  • 個人別に付与されたID、パスワード、その他の記号など
  • その情報のみでは特定の個人を識別できないものの、他の情報と容易に照合することができ、これにより特定の個人を識別できるもの

「個人別に付与されたID」が自由民主党本部では明確に個人情報として扱われている。誰が付与したものかを限定していないので、携帯電話から自民党本部Webサイトへのアクセスで送られてくるサブスクライバーIDも、自民党は個人情報として扱うことを約束していることになる。

昨日の日記に書いたように、民間をも対象とした個人情報保護法では、「個人別に付された番号」の記述はなくなっており、他の情報との照合についても、営業の自由への配慮から、「容易に」という要件が加わっているのであるから、ツーカーセルラー東海の回答が法律に反しているとは直ちには言えない。「容易に照合する」ことができるかどうかが焦点となる。

ツーカーセルラー東海の回答では、

それを取得したCPが個人情報と結びつける等、CP側の管理方法によっては、相対的なものとして個人を特定できる情報になり得ることは認識しておりますが、この場合、当該CPがその収集した個人情報に対する管理責任を果たすべきだと考えております。

とあるが、ここで言う「管理責任」とは何に対するどのような管理のことだろうか。

「サブスクライバーIDを個人情報と結びつける」というのは、コンテンツプロバイダが別の手段(そのサイトにおけるユーザ登録など)で個人情報を持っていて、それにサブスクライバーIDを結びつける行為を指しているだろう。そして、「当該CPがその収集した個人情報に対する管理責任を」というのは、コンテンツプロバイダが元々収集している個人情報の管理責任を負っているはずだということなのだろう。

つまり、個人情報と結び付けない状態のサブスクライバーIDは、コンテンツプロバイダにも管理責任がないということだ。なにしろ、通信事業者でさえ個人情報でないとする情報なのだからコンテンツプロバイダがそれを個人情報として扱わされるいわれはない。

すなわち、例えば、アクセスしたという事実そのものが私事性を持つようなサイトが、アクセス者のサブスクライバーID(およびアクセス先内容も含む場合がある)リストを売却していても、違法性がないことになる。

違法性がないことから、「誰だかわからない状態」のままサブスクライバーIDと、そのIDの人の無数のサイトにおけるアクセス行動が集積されることが起こり得る。誰でもそれを購入できたり、無料でダウンロードできる事態にさえなるかもしれない。

あとは、どこか一箇所でも、個人情報とサブスクライバーIDの対応リストを漏らすと、その集積情報が誰のものであるかが、誰にでもわかる事態となるのだが、管理責任があるのはその漏らしたサイトだけだということを、ツーカーセルラー東海の回答は語っている。そのときの、漏らした事業者の損害賠償額はどうやって見積もられるのだろうか。

また、誰も、個人情報とサブスクライバーIDの対応リストを漏らさなかったとしても、正規の理由で個人情報を預かっている者は、上の集積情報が誰のものなのかが容易にわかる。消費者がそのサイトを信用して個人情報を預ける際に、そこまでの集積情報が相手に渡ることをはたして予想しているだろうか。

さらに次の場合はどうだろうか。7月8日の日記「とうとうsubscriber IDの収集が始まったのか?」に書いた、無差別迷惑メール業者が、あてずっぽうのメールアドレスにspamメールを送って、メール中のID付きURLにアクセスしてきた消費者のサブスクライバーIDを収集するケースを考えてみる。

この場合、この業者は、メールアドレスを収集したわけではない。メールアドレスが個人情報保護法で言う個人情報に当たるか否かも議論の余地があるようだが、仮に収集したメールアドレスが個人情報だとしても、この迷惑業者は、消費者からメールアドレスを収集したわけではなく、ランダムに文字列を生成したにすぎない。ということになると、この業者が、メールアドレスのような文字列と対応するサブスクライバーIDのリストを売却することは、違法性がないことになるのではないか。

ツーカーセルラー東海の回答には、

しかしながら、ご指摘のような悪意のCPが違法に当該情報を利用する事態も想定されることから、ユーザ保護の観点からは、その利便性とのバランスも勘案しつつ対策を検討していく必要があると感じております。

とある。あくまでも違法に利用される事態が起きるなら対策を検討する(「俺たちの責任じゃないけどね」という意味)とされており、違法でない事態への対策については述べられていない。

これでよいのだろうか?

*1 つくば市在住なのになぜ「東海」なのかというと、東海地方に住んでいた7年前に契約した電話番号をまだ使っているため。

本日のリンク元 TrackBack(0)

2003年08月14日

「リスクコミュニケーション」はIT分野に馴染むか?

リスクコミュニケーションという考え方があるらしい。主に化学物質などが自然・生活・都市環境に与える影響について対象としているようだ。情報技術やプライバシーは対象となっていないようだ。

経済産業省製造産業局化学物質管理課のサイトにある「こんな思いこみはしていませんか?」はなかなか興味深い。

  • 環境対策が決まるまで情報は公開すべきでない。
  • 情報を出すと世間が混乱する。リスクについて情報公開すれば、住民はパニックになる。
  • 住民は、科学的な情報は理解できない。住民はゼロリスクを求める。
  • コミュニケーションにわざわざ人や時間を割く必要はない。
  • マニュアルを作ったから、問題が起こっても対応できる。

    経済産業省製造産業局化学物質管理課, こんな思いこみはしていませんか?

リスクコミュニケーションがどのようなものかを知るには、たとえば、三井情報開発総合研究所の田島哲也氏の時事コラム「リスクコミュニケーションについて」がわかりやすいかもしれない。

リスクコミュニケーションとは、企業活動等に際して安全・衛生・環境等面で大きなリスクが発生する可能性のある活動を行なう場合、リスクを負う可能性のある関係者(職員、地域住民等)に対してそのリスクの性質・内容等について周知させ関係者の注意を喚起し、関係者からの不安・警戒・疑問等に答えるととも、関係者からの指摘を自己のリスク管理に取り入れることによりリスクの削減を図ることである。(略)

田島哲也, リスクコミュニケーションについて, 三井情報開発株式会社総合研究所 時事コラム

検索してその他のページも見てまわったところ、どうやら、リスクコミュニケーションというのは、基本的には、専門家が分析して結論を出したリスク評価を、行政や企業が一般市民に対して「説得する」ためのコミュニケーション手法のことを指すらしい。コミュニケーションによってリスク分析が進むという話ではない。

ただし、上の田島氏の概説にもあるように、「関係者からの指摘を……取り入れることによりリスクの軽減を図る」ということも、リスクコミュニケーションの意義として謳われているようだ。実際に一般市民の声が専門家の分析を覆すことは、めったには起きないだろうが、その可能性があることを前提としたコミュニケーションを図ることによって、単に不安・警戒を抑えるということだけでなしに、リスク評価を行う者に緊張感を与え、他の意図にそそのかされて評価を誤るという事態を防止できる効能があるのだろう。

さて、IT分野でのリスクコミュニケーションの現状はどうなっているだろうか。化学物質がもたらす環境リスクと、情報技術がもたらすプライバシーリスクとには、どのような違いがあるだろうか。いろいろと論点がありそうだ。列挙し始めると長くなりそうなので今日はやめておく。

ひとつだけ挙げておくと、そもそもIT分野でのリスク分析は、専門家の間でもあまり進められていないのではないかということがある。暗号の強度については専門家による評価が行われてきたが、暗号以外の部分の欠陥がもたらすリスクとか、その他の技術のプライバシーへの影響といったことは、化学物質の環境リスク研究などと比べると、研究分野、研究体制として確立していないように思えるが、どうか。

専門家の評価体制ができていないものを、リスクコミュニケーションだと言って「説得」しようとするのはおかしい話だ。リスクコミュニケーションの定義に反する。

倹約家新婚ご夫婦の誕生日プレゼント

消費者に理解されていない「ICタグ」」より。

いきなりだが,結婚したばかりの友人から送られてきた電子メールを紹介したい。このメールが届いたのは,7月下旬のこと。ちょうど記者が,日経コンピュータの8月11日号で「ICタグの真実」と題した特集記事を執筆している最中だった。

ごぶさたです。最近よく記事で目にするゴマ粒チップについて聞きたいのですが,このチップを埋め込んだシールを作って自分の大切なモノに張っておくと,GPSなどの位置情報システムと連動して所在地が分かるの? 実は,1週間前に奥さんからもらった誕生日プレゼントの定期入れを,定期や免許証と一緒に落としてしまいました。それで,ゴマ粒チップを使って発見できたら便利だなと思った次第です。

栗原 雅(日経コンピュータ), 消費者に理解されていない「ICタグ」, 日経BP IT Pro, 記者の眼

結婚一年目の誕生日プレゼントが定期入れとは、なかなか堅実なご夫婦だ。それを紛失とは、さぞかし痛恨の極みのこととお察しする。

本日のリンク元 TrackBack(0)

2003年08月15日

ニュースの森

先日、勤務先の仕事の件でTBSの取材を受けた。今日夕方の「ニュースの森」で放送という予定。(延期の可能性もあり。)

きちんと伝わるだろうかと不安で、悪い夢にうなされる。

追記

放送されなかった。いつに延期になったかは不明。

村井先生の講義

7月30日の日記で、固定ID型RFIDのプライバシー問題について村井先生の講義で取り上げられていたことを書いたが、別の講義「インターネットの進化と可能性」でも論点のひとつとなっていた。

本日のリンク元 TrackBack(0)

2003年08月16日

理解せずに語られているcookieのプライバシー性

総務省のサイトに「電気通信サービスFAQ」というページがある。「5−1 携帯電話は誰かに盗聴されたりする心配はないのですか。」などは、総務省の公式な見解として読むと興味深い。

このFAQ、よく書けているところと、そうでもないところがあって、それぞれ担当した人が別なのかなあとも感じられるのだが、それはともかく、第5章「通信の秘密、個人情報保護 」に、「クッキーとは何ですか。クッキーを受け取らないようにすることは可能ですか」というQがある。

小さなデータ

回答の冒頭にはこう説明されている。

クッキーとは、ホームページを置いているサーバコンピュータが送信した情報をインターネットの利用者のパソコンに保存させ、その利用者が次に同じホームページにアクセスした時に自動的に保存された情報をサーバに送信するシステムのことをいいます。

総務省 電気通信サービスFAQ

この説明は正しい。続く部分、

このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。

総務省 電気通信サービスFAQ

ここもおおむね正しい。

正しいのが当然なのになぜこれを取り上げるかというと、あまりにもいいかげんなcookie解説が巷にあふれているため、この正しい説明が珍しく見えてしまうのだ。いいかげんな解説はプライバシーポリシーや個人情報保護方針の文中に見られる。例えば、「クッキー 小さなデータ」で検索してみると、わらわらと変な解説が出てくる。典型的な文章はこんな感じだ。

クッキーは、ウェブサーバーからブラウザに送信される小さなデータです。

データが小さいかどうかは、プライバシーに何ら関係がない。総務省のFAQにあるように、サーバが発行し、ブラウザが受信して保存し、後に同じサイトにアクセスするときに自動的に送り返されるところに、cookieの本質がある。プライバシーポリシーを書く立場の職種の人たちは、cookieがどういうものかわからないままに書いている(書かされている)ことがあるのだろう。

「技術的に不可能ではない」?

そういうわけで、「電気通信サービスFAQ」のこのcookie解説は、きちんと技術的な仕組みを理解した方によって書かれたものと思われる。ところが、続く部分がちょっと変なのだ。

利用者がこの機能を正しく認識して使用すれば便利なものですが、ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、他人が利用者のパスワードを読むことも技術的に不可能ではありません

総務省 電気通信サービスFAQ

「技術的に不可能ではありません」と言うと、まるで、どうやっても防げない話のように聞こえる。実際には、セキュリティホールがない限り、他人にcookieを読まれることは起こりえない。cookieを盗まれるセキュリティホールは、ブラウザにある場合もあれば、サーバ側のWebアプリケーションにある場合もある。cookieは、中身がパスワードだろうが、単なるセッションIDであろうが、他人に読まれることはあってはならないものであり、それが起きるのは何らかの欠陥があるということだ。

とはいえ、実際問題として、ブラウザやサーバ側にセキュリティホールが残っていることも避けられない現実であるとして、ユーザ向けにそのリスクを説明することの意義はあるのであるから、そのような意図で書かれた解説なのかもしれない。ただ、仕様上の話と、欠陥がある場合の話は区別して説明するべきだ。なぜなら、欠陥があるならまず欠陥を直すことが第一だからだ。

で、この日記で言いたいのはその話ではない。なぜ、欠陥の存在を前提とした話を、「技術的に不可能ではない」という不用意な表現で書いてしまったのだろうか、ということだ。 これを私は次のように憶測する。

よくわからないが問題があるらしい

そもそも、cookieの話を「通信の秘密、個人情報保護」というFAQに書くからには、プライバシー上の問題点について書かないわけにはいかない。ブラウザにcookieの受入れを拒否する設定機能が存在するという事実から、cookieがプライバシーに何らかの影響があるらしいことは確かだ。そこで捻出されたのが、「他人が利用者のパスワードを読むことも技術的に不可能ではありません」という想定ではなかろうか。

つまり、このFAQの著者は、cookieの動作原理は理解しているものの、cookieがなぜプライバシー上の問題のあるものとされているのか、その本当の理由を理解していないのではないかということだ。

cookieの本当のプライバシー問題(のうち最も重大なもの)は、「第三者cookie」によるユーザ追跡効果にある。

第三者cookieとは、ユーザが今見ている画面のURLとは異なるドメインのサーバから発行されてくるcookieのことを指す。具体的には、たとえば、ページ中に貼り付けられた画像だ。HTMLの仕様上、画面を構成するHTMLの置かれているサーバとは別のサーバに置かれている画像ファイルを、ページ中に貼り付けることができる。このとき、画像を供給するサーバ(第三者のサーバ)がcookieを発行していると、ブラウザはそれを自動的に受け付けてしまう。これを「第三者cookie」と呼ぶ。

予測できなかった第三者cookieの乱用

第三者cookieの応用として最も多いのが、「バナー広告」だ。バナー広告の画像(Flashコンテンツでもよい)は、通常、広告業者のサーバに置かれていて、広告を掲示するページでは、その画像へのリンクが張られている。

広告業者がバナー広告の画像にcookieを発行する理由は、第一には、閲覧者に効果的な広告の見せ方をすることにある。たとえば、同じ閲覧者に同じ広告を何度も何度も見せても効果が薄いかもしれないし、閲覧者が既にクリックしたことのある広告を再び同じ閲覧者に見せても無駄に終わるかもしれないのだから、できるだけ新しい広告を見せるようにした方がよい。そうした仕組みは、cookieを使うことで簡単に実現できる。閲覧者ごとに固有の固定IDを、cookieとして発行すればよい。あるIDの人からアクセスがあったとき、そのIDの人に過去にどんな広告を見せたかを調べて、適切な広告画像を返すようにすればよい。

広告業者は、一社で、非常に多くのサイトに広告を流している。広告業者は、各閲覧者が過去にどこのサイトを訪れているかを、広告画像の Referer: フィールドの記録から知ることができる。これを活用すれば、各閲覧者のアクセス嗜好に応じた広告を選んで流すこともできる。普段ポルノサイトに行くことの多い人は、食品販売のサイトに行ったときにも、ポルノ系広告が現れるということが起こり得る。

もし10万か所のサイトに、同一広告業者のバナー画像が貼り付けられていたならば、その広告業者は、それぞれの人たちがその10万か所にどのようにアクセスしているのかを知ることができてしまう。IDだけでは、それが誰のIDであるかは不明だが、その10万か所のうちのどこかで、ユーザが個人情報を登録していて、それと広告のIDとが突き合わされる事態が起きれば、それが誰であるかも判明してしまう。

これが「第三者cookie」のプライバシー問題である。これが一部の特殊な人たちにだけ懸念されている問題というわけではないことは、最近のブラウザのcookie設定の画面を見れば明らかである。以下のように、NetscapeにもInternet Explorerにも、第三者cookieは、通常のcookieとは別に許可・拒否の設定ができるようになっている。IEでは、第三者cookieは「サードパーティのCookie」と表記されている。

cookieの機能を最初にブラウザに取り入れたのはNetscapeだった。彼らは、cookieなどという複雑な仕組みを編み出さなくても、ブラウザに固定IDを埋め込むだけで目的を果たせたはずだが、それをしなかった。それは、固定IDがプライバシー上の問題があるという見識を持っていたからだろう。だが、そんな彼らにも予測できなかった使われ方をしてしまった。それが、第三者cookieのサイト横断的利用だった。当初予想できなかった問題が起きれば、ブラウザ側で新たな対策をとる。それが上の新しい設定画面だ。

蚊帳の外だった日本が初めて患う大人の麻疹

FAQの文章に戻ると、

このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。

総務省 電気通信サービスFAQ

というように、cookieが固有番号を記憶するために使われていることは理解されているようだが、それ自体はプライバシー上の懸念をもたらすものではないとして説明されている。あくまでも、

ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、 総務省 電気通信サービスFAQ

というように、サイト側がcookieの使い方を誤って、パスワード(やユーザ名)をcookieに直接入れてしまっている場合にだけ問題が起きるとして書かれている。

こうした誤った理解は、総務省の担当者だけでなく、かなり広範囲の人たち(技術者を含む)に根強く残っているのではなかろうか。

このFAQの文章が総務省の総意を示すわけではないことは重々承知しているのだが、携帯電話事業の監督官庁である総務省の関係スタッフが、もし固定IDの問題を理解していないとすると、それはまずい。

EZwebの「サブスクライバーID」や、J-PHONEの「ユーザーID」は、その仕組みからして、第三者cookieと同じプライバシー問題を起こす能力を持ち、それどころか、cookieのようにID発行の準備をせずとも最初から電話会社から勝手にIDが送られてくるという点で、より性質の悪い仕組みになっている。

「電気通信サービスFAQ」でcookieが取り上げられているのは、「cookieにプライバシー問題あり」というのが、国際的コンセンサスとなっているからだろう。それに対し、携帯電話の簡易Web機能は、日本市場で先行して普及してきたため、まだ諸外国ではそのプライバシー問題がほとんど認識されていない。今後、欧米諸国に普及していったときに、消費者団体からのバッシングに遭い、政府の介入という事態にもなると予想される。

私が固定IDのプライバシー問題をここで書いているのは、私個人がプライバシーに敏感だからとかそういうことではない。セキュリティ問題を追いかけてきた経験から、国際的に何がプライバシー問題(どんな技術手法が禁じ手)として認識されているのかを、たまたま詳しく知る立場にあった。それがどうやら、肝心な人たちには理解されていないらしいことが、昨年あたりからわかってきたため、このままではまずいと思い、筆をとっているところだ。

日本は、これまで、こうした技術の標準化において蚊帳の外にいることが多かった。主なWebブラウザは日本製ではないし*1IntelのPentium IIIにIDを内蔵させて活用する件でも日本は蚊帳の外だった。固定IDにプライバシー問題があるという議論は、海外ニュースの翻訳版で対岸の火事として傍観する程度のかかわりしか持ってこなかった。「Webバグ」の議論だって日本のメディアが独自に取り上げることはなかった。日本にとってRFIDの今の議論は、大人になって今ごろかかった麻疹のようなものだ。

e-Japan重点計画-2003」では、「安全・安心」がキーワードとなっており、各技術でプライバシーを確保することが謳われている。国際的に恥をかくはめにならないよう、なんとか固定IDの問題を正しく認識した上での政策を進めていただきたい。そのためにはあらゆる協力を惜しまないつもりでいるのだが……。

と、こんなところで言っていてもはじまらないのだが。

補足

e-Japan重点計画-2003」のp.45に次の記述がある。

(2) インターネット端末やインターネット家電が普及し、それらがインターネットに常時接続されることを想定し、十分なアドレス空間を備え、プライバシーとセキュリティの保護がしやすいIPv6を備えたインターネット網への移行を推進する。

e-Japan重点計画-2003, III重点政策5分野, 1.世界最高水準の高度情報通信ネットワークの形成

IPv6が「プライバシーの保護がしやすい」ものだというのは、初めて目にした。どういう根拠なのだろうか。ちゃんとわかっている人が書いているのかどうか、不安になる。

「電気通信サービスFAQ」の別のページにはこんな記述もある。

4−4−4  自分のパソコンがコンピュータ・ウィルスに感染しないようにするには、どうすればよいのでしょうか。

○ パソコンがコンピュータ・ウィルスに感染すると、パソコンに保存してあるファイルが破壊されてしまうことがあります。このようなコンピュータ・ウィルスに対処するためには、市販のウィルス対策ソフトを活用し、ウィルスの侵入を防ぐことが大切です。

○ ウィルスは電子メールに添付されて侵入する場合が多く、添付ファイルを開くとパソコンがウィルスに感染してしまいます。そして、コンピュータの中のメールアドレスなどを参照して、勝手にウィルス付きの電子メールを送信し、知り合いにもウィルスの被害を広げてしまうことがあります。

○ 最近のウィルスは手口が高度化してきており、メールの添付ファイルを開かなくても、メールを読むだけで、あるいはWebを見るだけで感染してしまうようなケースがあります。 ○ このため、ウィルス対策ソフトを定期的に起動させて、ウィルスチェックを行うことをお勧めします。また、身に覚えのない相手や怪しい件名のメールが届いたときには、安易に添付ファイルを開かずに削除したほうがよいでしょう。

○ また、新しいウィルスが日々発見されている状況なので、ウィルス対策ソフトや、その定義ファイルの更新を常に行うようにすることが重要です。

○ プロバイダによっては、自動でメールのウィルス検査を行うサービスを提供しているので、こういうサービスを利用する方法もあります。

総務省 電気通信サービスFAQ

セキュリティホールの話や、パッチをあてよという話が全く書かれていない。これはちょっと愕然とする。

きっとこの文書は3年前くらいに書かれたものなのだろう。そのころは、こんな報道もあったくらいで、世間の認識はそういうレベルだった。

中央省庁などのホームページの不正書き換え事件で、15件のうち6件は、ハッカーがサーバーコンピューターに一度に大量のデータを送信して異常作動を起こさせる方法で侵入していたことが、15日までの警視庁麹町署捜査本部の調べで分かった。この方法は「バッファ・オーバー・フロー攻撃」と呼ばれる手口。大量のデータを受けたサーバーコンピューターからあふれ出たパスワードなどのデータを使ってハッカーが不正アクセス用の「裏口」を作り、管理者になりすましてホームページを書き換える。防ぐのは難しいという。

毎日新聞, 大量データ送り、異常誘う手口−−省庁ハッカー被害, 2000年2月16日

たった3年半前の話なのに、隔世の感がある。

まだこんなことを言っている人がいるよ その2

  • 菊田一郎, RFIDの実用化と セキュリティ問題, 月刊「マテリアルフロー」, 2003年8月

    タグには危ない情報を入れないこと
    ...

    いろいろなサイトの書き手が、すぐにあの小説「1984年」に出てくる、プライバシー情報を含む一切の支配者・ビッグブラザーを持ち出したりしています。

    RFIDタグに、商品名や製造日や原料や値段(上代・下代)やサイズ・色、といった全ての情報をそのまま書き込むのだろう、そんなこと他人に知られてはたまらない、と言う理解がまず頭にあるから、そうした反応になるのでしょうか。
    ...

    タグに入っているのは製品のシリアルナンバーだけです。数字の羅列。それだけでは意味がなく、製品情報・生産情報・流通情報はそれぞれの責任を担う企業のサーバに置き、ネットワーク経由で権利のあるものだけがアクセスできる方式を目指しています。
    ...

    てなわけで、...
    導入関連社側が根気よく、一般消費者に向けて説明していくことでしょう。

コメントは不要だろう。この人を理解させるにはどういう手段があるのか。

*1 例外はあるが。

本日のリンク元 TrackBack(0)

2003年08月17日

「固有ID」の問題なのか「固定ID」の問題なのか

8月16日の「辺境から戯れ言」に次の主張がある。

「固有 ID」という言い回しは誤解を生みやすく取り扱いが難しいように思う。

私も、「固有ID」という呼び方を避けている。この日記では初日の5月5日の日記でだけ「固有ID」と書いてしまったが、これはミスで、その後は「固定ID」と書くようにしている。4月のネット時評でも、「固定ID」と書いていて、「固有ID」とは書いていない。「固有のID」という表現は出てきているが、問題ありという文脈では使っていない。

両者はどう違うのか。

まずひとつは、IDを(時間的に)固定にしないことによる解決策があるという含みを持たせるためだ。

具体的なことはこれまでの日記にたびたび書いてきた。下の1つ目のように一時的なIDを使う方法と、2つ目のようにIDにスクランブルをかける方法がある。

  • IPv6の匿名アドレスはどう運用されるのか, 5月25日

    アプリケーションレベルの識別子は、一時的なID(セッションID)とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。

  • 「これはいたずらな不安の煽りである」という合理化, 6月29日

    RFIDチップ内に、単純増加カウンタと公開鍵暗号の演算回路と公開鍵を内蔵させる。スキャナからアクセスがある毎に、カウンタの値を1増やしながら、カウンタの値と固定IDの連接ビット列を公開鍵で暗号化してスキャナへの応答とする。スキャナ側は、スキャンする毎に異なるビット列が返ってくるので、そのままでは個人追跡には使えない。チップ内の公開鍵に対応する秘密鍵を保有している者だけが、固定IDを取り出すことができる。

これらでは、仮のID(変化するID)が外に見えているだけで、真のIDが関係者にしか見えないところに存在しており、それは固定IDである。

もうひとつは、IDのドメインを可能な限り狭くすべきだという含みを持たせるためだ。

「IDのドメインが広い」とは、例えば、「どこのサイトに行っても使えるユーザ名」がそれで、具体的には、Microsoft Passportのユーザ名や、NTTドコモのFirstPassのクライアント証明書のcommon name、EZwebの「サブスクライバID」、J-PHONEの「ユーザID」などがそれに該当する。

  • 通信キャリアの独占型PKIは安全なのか

    これは、「Webのあらゆるログインサービスで、ユーザ名が唯一の機関によって定められている」という状況に近いと言える。つまり、たとえば、Microsoftの「Passport」サービスが独占的に普及した世界を想像すればよい。Windowsを購入すると、無料でPassportサービスにアカウントを作ってもらうことができ、どこのネットショップに行ってもPassportの同じアカウントでログインするという世界だ。さらに、勤務先のイントラネットに外出先からアクセスする際にも、MicrosoftのPassportのアカウントでログインするという世界だ。

このときの「ドメイン」は、そのIDの使えるサイト全域に広がっていることになる。これは「共通ID」と呼ぶこともできる。共通IDは、どこのサイトに行っても同じ、つまり固定であるから、「固定ID」という表現は、そのような「共通ID」のことも指す意味を含ませているつもりだ。(ただこれはいまいちな表現だと思っている。きっと定着したもっとよい専門用語があるのだろうが、不勉強なのでまだ知らない。)

必要最小限のドメインで独立した固有IDが、時刻によって変化しない意味で固定のIDだとしても、それは直ちに問題ありとはならない。例えば、ネットショップなどで、その店のことを信用してユーザ登録し、自分の固有IDでログインしてサービスを受けるシステムのことを、プライバシーの問題があると言う人は少ないだろう。

必要最小限のドメインで独立した固有IDの例としては、ネットショップのユーザ名の他に、日本の住民基本台帳の住民票コードもそれに該当する。住民票コードは、民間での利用が禁じられており、行政機関における法で定められた範囲での利用しかできない*1。これは固有IDであるが「共通ID」(=「固定ID」)ではない*2

昨日の日記で第三者cookieのことを書いた。本来、cookieは、DNSのドメインごとに名前空間が仕切られており、必要最小限のドメインで独立したものとなるよう設計されたが、第三者cookieのサイト横断的使用という予測できなかった利用形態により、「共通ID」的な利用がされるようになってしまったという話だと言える。

固有IDのドメインが、サービス提供サイトごとに独立していると、ユーザはその都度、IDを使い分け(さらにはパスワードを使い分け)なくてはならず、それが不便すぎるという話がある。だからといって、ここで共通IDを使うことにするのは、技術的に安直な方法だということを認識しておきたい。

Liberty AllianceのID-Federation Frameworkでは、サービス提供サイトごとに独立した固有IDがあることを前提とし、ユーザが自らの意思によって、自身がそれぞれのサイトに持つ固有IDを、必要に応じてそれらが同じ人のものであることを第三者機関(アイデンティティプロバイダ)に登録(アイデンティティ連携)することで、シングルサインオンを実現する。こうした仕組みを導入することで、プライバシーレベルは保たれることになる。

携帯電話のWebにとっては、ID-Federationのような仕組みを導入するのは、複雑すぎて現実的でないという議論があるかもしれない。しかし、簡略化したシステムを導入することはできるのではなかろうか。

簡略化したアイデンティティプロバイダを携帯電話事業者が担い、認証を携帯電話事業者が行う。サービスプロバイダはそれぞれに独立した固有IDの空間を持ち、ユーザとその各サービスプロバイダ用の固有IDとの対応付けを携帯電話事業者が行う。

対応付けの簡単な実現方法としては、DNSのドメインを基にして、ドメイン毎に異なるサブスクライバIDを携帯電話事業者が決めて、それをサービスプロバイダに送信するようにすることが考えられる。サービスプロバイダ側から見ると、ユーザの固有ID(= サブスクライバID)は携帯電話事業者から与えられることとなり、そのIDは別のサイトでは通用しないものであるから、「共通IDのプライバシー問題」は生じない。サービスプロバイダは、認証機構の実装を省略でき、簡単な実装でサービスを提供できるのではなかろうか。

このように、固定IDの問題は技術的に解決可能な方法が存在している場合が多い。利便性を捨てよと言っているわけではないことは、言うまでもない。

今話題となっている、固定ID単純応答型RFIDタグのプライバシーの議論は、固有IDのドメインが制限されていないところに問題の本質があるといえる。供給側の意図として特定のドメインでだけ使う固有IDのつもりであっても、それ以外のところでも使えてしまうのでは「共通ID」として働いてしまう、という話だ。

そして、技術的解決方法は存在するのだが、一部の応用分野では、低コスト化が最優先されているため、対策せずに導入されるのではないか、という懸念が出ているという話だ。

*1 ことになっている。

*2 ただし、本当にドメイン範囲が必要最小限になっているかという議論の余地は残る。

本日のリンク元 TrackBack(0)

2003年08月19日

家電製品と汎用コンピュータの切り分け

今月公開された、株式会社ラックの「脆弱性報告と公開のポリシー」に、「SNSポリシーに関する意見」として、夏井高人先生の見解が公表されている。この中で、ソフトウェア製品を2つに区分する提案がなされており、たいへん興味深い。

興味深かった結論は、次の部分。

技術的に完全なものとしてソフトウェアを製造・販売またはライセンスし、かつ、完全な法的責任(損害賠償責任、補修責任、交換責任)を負うことを約束しているベンダーについては、そのベンダーの事前の同意がない限り(コンテクストから同意しているものと推定される場合を含む。)、その脆弱性情報を公開することが許されないと解釈すべきであろう。この場合、もし問題が発生したら、そのベンダーが全責任を負うべきである。

これに対し、技術的に完全なものとしてソフトウェアを製造・販売またはライセンスし、かつ、完全な法的責任(損害賠償責任、補修責任、交換責任)を負うことを約束しているのではないベンダーについては、事前の同意なく、その脆弱性を公表しても違法ではないと解釈すべきである。この場合において、そのベンダーが、自分自身以外の者から脆弱性情報が提供されることを嫌うのであれば、誰よりも早く脆弱性を発見し、その情報をユーザに提供するような仕組みを完全に保証すべきである。

夏井高人, SNSポリシーに関する意見

この結論に至るまでの論旨はこうだ。まず、

一般に、欠陥のある商品やサービスの提供は、それ自体として違法である。多くの場合、債務不履行(不完全履行)として欠陥の補修や損害賠償の責任を負わなければならない。

夏井高人, SNSポリシーに関する意見

とし、ソフトウェアがPL法の適用外であるのは、単に、欠陥の不存在の立証を製造者側に持たせる「証明責任の転換」が適用されないという話であって、欠陥の存在を原告が立証するのであれば、債務不履行(不完全履行)として製造者の責任を追及できるということが説明されている。

続いて、

ほとんどのパッケージソフトウェアの利用契約(ライセンス契約)には、免責条項(免責約款)が付記されている。...(略)... しかし、このような無制約の免責条項は、消費者契約法によって無効なものとされているので、意味のない条項である。

夏井高人, SNSポリシーに関する意見

としながらも、

しかしながら、汎用のソフトウェアには多少困った事情もある。つまり、ソフトウェアの開発・出荷時には、そのソフトウェアがどのようなPCにインストールされるのか、インストールされるPCにはどのような装置や機器が接続されているのか、インストールされるPCには他にどのようなソフトウェアがインストールされているのかを予め知ることができないという問題である。この組み合わせ問題は無限に存在し得るので、...(略)

夏井高人, SNSポリシーに関する意見

として、汎用コンピュータにおけるソフトウェアの完全性を求めることが困難であることにも理解を示し、

厳格に法を適用することは、確かに酷であるような場合がある。

夏井高人, SNSポリシーに関する意見

としている。

そこで、提案されているのが、最初に引用した部分の結論である。つまり、欠陥に対する「完全な法的責任」を約束している場合には、第三者の脆弱性公開を許されないものとし、責任を約束していない場合には、脆弱性公表を違法でないとするべきだと。

夏井先生のこの小論では、第三者による脆弱性情報の無断公開を許されないものとする立場を基本とした上で、「完全な法的責任」を約束をしていない場合を例外として、その場合には脆弱性公開が許されるという構成になっているように思う。

「完全な法的責任」を約束をしている場合に、第三者の脆弱性公開がなぜ許されないのかという点について、まだ議論の余地があるように感じられるのだが、この小論では、脆弱性公開が許される条件を示すことに力点が置かれているのだと思う。現状は、ほとんどのソフトウェア製品が「完全な法的責任」を約束していないのだから、この小論は、脆弱性公開を違法でないと解釈すべき根拠を示したもの言える。

それと同時に、「完全な法的責任」を約束する販売形態を製造者に促す意味も含まれているように思う。製造者の立場として、脆弱性情報をコントロールするという目的のために、「完全な法的責任」を約束することにメリットが生まれる。

私もかねてより、家電製品と汎用コンピュータはそろそろ明確に区別すべき時期にきているのではないかと考えてきた。汎用コンピュータ用のソフトウェアの完全性保証が無理なのは、夏井先生の小論にもあるように、同時に動作する他のソフトウェア部品との相互作用など、予測が困難な要素が多すぎるからだ。その一方で、消費者の多くが、「パソコン」を電子メールとWebとデジカメ写真編集くらいにしか使っていないという実態があるように思う。

つまり、メールとWebと写真(とあといくらか)の機能しか持たないような、お手軽なネット端末が、「家電製品」として販売されてもよいのではないかと思う。そうした製品は、過去にもいくらか出ていたと思うが、ことごとく失敗してきた。売れなかった原因は、拡張性がないために、最新のWeb技術に追いついていけずすぐに陳腐化したこと、もうひとつは、価格を抑えることが簡単でなかったためではなかろうか。

本来、技術者が自己責任で使う道具であった汎用コンピュータが、ごく普通の消費者にまで「パソコン」として売り込まれているという、ここ数年の状況は、汎用コンピュータにソフトウェアを載せるという作り方が、低価格で製品を提供できたことと、アプリケーションソフトウェアの進歩が著しかったためであろう。

しかし、ここ1年ほどで、Webにせよ、メールにせよ、進歩が緩やかになってきたのではないだろうか。だとすれば、今こそ、「家電製品」としてのネット端末が商機を迎えているかもしれない。そうであるなら、セキュリティ欠陥について「完全な法的責任」を負うと約束する販売形態も、現実味を帯びてくるのではないか。

携帯電話は、「完全な法的責任」を負うと約束しているかどうかは知らないが、搭載ソフトウェアに欠陥が見つかった場合、回収・交換という措置がとられている。その一方で、搭載機能が高度化し、欠陥をなくすのが大変になってきていると聞く。あるシンポジウムで、現場の開発技術者の声として聞いたところでは、携帯電話のソフトウェアも、Windowsなどと同じように、パッチを(電波経由で)自分でダウンロードして修正できるようにしたいという意識があるようだった。

Java搭載の携帯電話は、拡張性と完全性の両立を実現したものだったと思う。同時に複数のアプリケーションが動かないようにしたり、非常に強く制限されたJava機能により、安全性も確保されていた。しかし、これも最近では、拡張性が不十分だということで、複雑化、機能制限の緩和という方向に向かっており、「パソコン」への道を歩み始めている。携帯電話も「無保証」の文化に移ってしまうのだろうか。

それはさておき、「完全な法的責任」が約束されている製品に、第三者が脆弱性を見つけた場合、どのような展開を生むだろうか。発見者が製造者に報告をしたとき、無視されたらどうなるだろうか。公開が法的に制限されているとなると、発見者はどこかに告発しなくてはならない。どこがそれを受け付けるのか。

現在のように、「無保証」のソフトウェアに欠陥が発覚しても、製造者がたいした社会的、経済的ダメージを受けない状況では、発見者も比較的気楽だったのに比べて、「完全な法的責任」が約束されている場合には、発見者に身の危険が及ぶ(もしくは、そうなると発見者が感じる)可能性が高くなるため、告発者の保護にも配慮が必要であろう。

また、製造者が「それは問題ではない」という見解を示すことが起こり得る。それは、これまでにもたびたびあった。特に日本では携帯電話事業者がそうした見解を示すことがある。

例えば、2001年4月にiアプリ開発者達のメーリングリストで発覚したスクラッチパッドの欠陥では、発見者が情報漏洩の危険性があると指摘していたにもかかわらず、携帯電話事業者は「動作が不安定になる場合がある」とだけ説明したということがあった。

他にも、2002年7月にauの料金照会ページが他人にも見えてしまうという欠陥が発覚した際に、携帯電話事業者が、「個人が特定できる情報が漏れることはありません」と発表したことがあった。

こうした場合に、発見者が自由に情報公開できないとなると、誰がどうやって脆弱性を評価するのかということになる。

ところで、ソフトウェアの製造物責任を考えるとき、他の製造物と比べてソフトウェアのセキュリティ欠陥には、再現性が高いという特徴がある。

壊れやすい椅子とか、火を噴きやすい電源といった欠陥は、確率的にしか事象が発生しないため、構造的な欠陥があることを消費者が立証するのは困難であり、だからこそPL法によって、欠陥の不存在を被告が証明しなければならないことになっているのだろう。それに対し、ソフトウェアのセキュリティ欠陥は、見つかってしまえば、100% の再現性があって検証が可能な場合が多く、欠陥の立証が容易かもしれない*1

*1 ただ、被害は起きたものの、原因がわかっていない場合には、やはり立証が困難かもしれないが。

本日のリンク元 TrackBack(0)

2003年08月21日

自動車登録番号追跡サービスのビジネスモデル

結城さんの「固有IDのシンプル・シナリオ」の、「加筆・修正予定のメモ」に現時点で掲載されている論点のいくつかについて、私なりのコメントを書いてみる。


自動車のナンバープレートは固有IDになりうるだろうか。

昨年のJIPDECのヒューマンインタフェース技術調査委員会の席で出た話題なのだが、あまり書くと本当にやる奴が出かねないと、あまり書きたくない気もしないでもなかったのだが、書いてしまおう。

次のような、USB2.0接続のCCDカメラと専用ソフトウェアのキットが、ブロードバンド家庭に無料配布され、そのソフトを動かしておくだけで、月に1,000円〜1万円程度もらえるとしたら、あなたは参加するだろうか。

  • USB2.0接続の安価で高解像度なCCDカメラを、窓の、外の道路がよく見える位置に取り付ける。
  • カメラを接続したパソコンを、常時電源を入れ、常時接続のインターネットにつないだままにし、専用ソフトを動かしておく。
  • 専用ソフトは、窓の外の画像に映った自動車のナンバープレートを画像解析し、自動車登録番号(ナンバー)を抽出し、これをインターネット経由でサーバに送信する。(設置場所の情報と供に)
  • 情報を集めたサーバは、その情報を必要とする人に有料で提供する。
  • 運営者は、参加者に対し、車の流量に応じた協力謝礼金を支払う。

このシナリオは、ほんの数年前では、コスト的にあり得ない話だった。現時点でもやや苦しいが、ナンバープレートを読み取るのに十分な解像度のCCDカメラが、このビジネスに見合うだけの低価格となるのは時間の問題であろうし、パソコンが十分に低い負荷でナンバープレートの解析を実行できる時は、もうすぐにでもやってくる(もしかしたら既に可能か?)だろうし、ブロードバンド常時接続はもう普及してしまった。

あとは、協力者への謝礼金の額と協力ノード数、集積情報の販売価格とその需要のバランスが、ビジネスとして成立するかどうか。こうしたビジネスが考えられ得るのが、自由なインターネットの優れたところだ。

余談だが、自動車登録番号が得られると、最寄の陸運局に行けば、誰でもどこの地域の車でも、所有者や使用者を調べることができるという話がある。平成13年から本人確認が必要となったようだが、本人確認といっても、請求者が偽でないかを確認するだけのようなので、請求することに後ろめたさがないならば、誰でも取得できるのだろうか。

それはともかく、所有者を特定しない場合でも、情報の価値はあるだろう。同じ車が、いつどこにいたかの情報は、渋滞予測や、マーケティングなどにも利用できそうだ。そして、所有者を特定できる人がその情報を購入すると、所有者のプライバシーが損なわれることになる。

さて、これが本当に民間で始まったとすると、その後どうなるだろうか。おそらく、法規制を求める声があがり、個人情報保護法の延長か何かで規制されることは起こり得るように思う。

このシナリオが規制されそうに思えるのは、次の性質があるからだろう。

  • 自動車登録番号が「個人情報」だと直感する人は多い。(陸運局で調べられるため。)
  • 自動車登録番号は法律で定められた番号であるため、法律で規制しやすい。
  • 自動車登録番号の民間での特定利用を禁じても、利便性にあまり不都合はない。

それに比べて、RFIDの固定IDや、現状のサブスクライバIDや、固定IPアドレスは次の性質を持つ。

  • IDが個人情報だと直感できない人が多いらしい。(今の議論を見ていると。)
  • IDは民間が自由に用意したものなので、法律で規制しやすいわけではない。

加えてRFIDの場合には、さらに次の性質もあるので、法による規制はうまくいかないように思える。

  • RFIDのIDは街中でスキャンして積極的に有効利用するというのが、期待されている「ユビキタスコンピューティング社会」の姿である。

そして、自動車登録番号をナンバープレートとして見えるところに設置しなくてはならないのは、ひき逃げ事件があったときに、現場にいた人が(特別な装置を持たなくても)目で見て番号を記憶できるようにしておくためなどの理由で、やむを得ない制度であるのに対し、RFIDにはそうした、やむを得ないという事情が存在しない。


「固有IDをもったアイテムを知らないうちに渡される」は団体客が目の前を通った場合、アリス個人の特定は難しいかも、という指摘あり。

場所Aで、アリスが団体にまみれた一人だったとしても、場所Bでアリスが単独で存在していれば、場所Bにおいて、目の前にいるアリスが場所Aにいたことは判明してしまう。こうした判明を避けるには、アリスは、ID読取機を持っている知人の前、個人情報を提供する場(のうちID読取機が設置されているかもしれない場所)のすべてで、団体行動をとるようにせざるを得ない。


「薬品の固有IDをすりかえるというのは極端な例なので不自然」という指摘あり。

これはプライバシーとは別の問題だが、物の管理を電子的な方法に頼り過ぎたとき、過信によってそうした事故や事件が起きかねないことが、業界でも心配される点として議論の要点のひとつとなっている。

ネタメモ

甲南大学法学部の園田寿教授による「韓国法最前線」に、興味深い資料がある。

まだ読んでいない。

  • (韓国)個人情報保護ガイドライン

    第10条(技術的対策)サービス提供者は、利用者の個人情報を取扱うにあたって、個人情報が紛失、盗難、漏れ、変造または壊されないように、安全性の確保に必要な次の各号の技術的対策を講じなければならない。

    1. パスワードなどを利用した保安装置
    2. ワクチンプログラムを利用したコンピューターウイルス防止装置
    3. 暗号アルゴリズムなどを利用して、ネットワークに個人情報を安全に電送できる保安装置
    4. 侵入遮断システムなどを利用したアクセスコントロール装置
    5. その他安全性確保のために必要な技術的装置

ウイルス対策ソフトの導入は書かれているのに、セキュリティホールの修正のことが書かれていないあたりが、情けない感じ。2000年に書かれたものだから、「セキュリティ対策といえば、ファイアウォール、ウイルス対策、暗号」という素人発想もやむを得ないか。日本の各種ガイドラインもその程度だったし。それにしても、どうして素人がこういう文書の作成に携わるのだろうか。

本日のリンク元 TrackBack(0)

2003年08月22日

プライバシーに関わらないRFID応用

日経デジタルコアの4月のトレーサビリティ研究会の席で、RFIDを研究題材となさっている国立情報学研究所の佐藤一郎さんから、興味深い話をうかがった。

(ユビキタスコンピューティングをプライバシーを確保しつつ実現するには)RFIDを(人が身に付ける)物ではなく、街角の方に付け、人の方がリーダを持って歩けばよい。

リーダを携帯ネット端末と一体にし、読み取った場のIDをネット経由で検索して利用するようにすれば、プライバシーは、携帯端末の通信に使用する通信事業者と、通信先のコンテンツプロバイダの運用体制によって確保されることになる。

このように、当然ながら、RFIDも使い方によって、プライバシーの問題を生じさせない場合がある。佐藤さんの7月12日の日記でも、

Wal-MartがRFIDタグを実証実験の延期を決めましたが、物流や倉庫管理を目的に、複数商品を詰めたパレットや段ボールにRFIDタグを貼る分にはプライバシー上の問題もおきないのに、個々の商品にまで色気を出すので話がややこしくなります。どちらにしてもRFIDは話題先行のバブル状態でしたから、これで落ち着いて実用化ができるのではないでしょうか。

と述べられている。

日経ニューメディアの7月25日の記事に次の記述があった。

今回の欧米の動きは,日本の関係者にも衝撃を与えている。欧米と同じ事態を招かないために総務省は,日本では電子タグに対応した各種のネットワーク対応サービスを充実させることによって,消費者に様々な利便性を訴える考えである(詳細は日経ニューメディア2003年7月28日号に掲載)。
 日経ニューメディア, 解説:電子タグの導入中止に傾く欧米の流通業界,プライバシー問題から消費者が反発

これを見て、「ごまかし通そうという話?」と嫌な予感がしたのだが、日経ニューメディア2003年7月28日号を取り寄せて記事の全文を読んでみたところ、次のように書かれていて、ちょっと安心した。

こうした事態について総務省は,「欧米では犯罪発生率が高いという背景があるため,万引きや盗難などを防止するために電子タグを導入するという発想から抜けきれない。管理者サイドに立ったこうした導入方針が,消費者の反発を招いたのではないか」としている。...(略)

欧米と同じ事態を招かないために総務省は,日本では電子タグに対応した各種のネットワーク対応サービスを充実させることによって,消費者に様々な利便性を訴える考えである。例えば食品の流通管理では,消費者に農薬の使用履歴などの正確な情報を提供できる。またITS(高度道路交通システム)関連では,車両ごとに最適な経路に誘導するサービスなどが考えられている。...(略)

もっとも日本でこうした導入方策が考えられたのは,外国に比べて犯罪発生率が低いため,流通業者が犯罪防止の目的だけから電子タグのシステムを導入しても,現行のバーコードに比べて採算が合いにくいという事情があったからだ。実際こうした理由から日本では,流通業者による電子タグの導入意欲は低い。...(略)

「高度道路交通システム」についてはどうやってプライバシーを確保するのか、やや心配なところもあるが、この応用事例では、RFIDのコストは数百円以上するものでも受け入れられるだろうと考えると、チップ内暗号演算による解決が可能かもしれない。

8月18日には、総務省の「ユビキタスネットワーク時代における電子タグの高度利活用に関する調査研究会」の中間報告が公表された。

まだ全部を読んでいないが、中間報告概要をざっと見ると、推進分野として選出された応用事例が、比較的、個人のプライバシーに影響のないものが注意深く挙げられているようにも見える。

中間報告の第4章を、「プライバシ」で検索してみると、

■プライバシー開示制御

電子タグが一般消費者との接点を持つ場面においては、タグの機能の無効化、および消費者のパーミッションによる情報開示レベルのコントロールなどを実現することによって、技術面からのプライバシー保護を実現する必要がある。

■ユーザーに対するサービス品質・リスクの開示

電子タグを利用したサービスを消費者等に対して提供する場合、そのサービスの品質レベルの保証を行う必要がある。また、サービス利用者にとって何らかのリスクがある場合には、そのリスクを明確にした上でサービスの提供を行う必要がある。

■データ活用のメリット訴求による社会的コンセンサス形成

電子タグの利活用が高度に進んだ場合のメリットを消費者あるいは企業に示した上で、電子タグ普及に対する社会的コンセンサスを形成する必要がある。コンセンサスを得ることにより、プライバシー等の問題に対する過剰な抵抗を軽減させることも可能であると考えられる。

■プラットフォーム間プライバシー保護

タグの無効化やユーザーのパーミッションによる情報開示レベルのコントロールなどを、プラットフォームが連携した場合にも有効にする必要がある。また、異なるプラットフォームに対してはそれぞれ適した情報開示レベルを設定する、などの仕組みを実現する必要がある。

■「人」に関わる情報を扱う際のプライバシー保護

電子タグが人によって所有され、個人の属性情報と紐づいた場合には、プライバシーの保護をどのように行うかが課題となる。前述のように技術的な対応方策の開発・実用化を積極的に進めると同時に、運用面の対応を強化することも必要であり、このため、電子タグの利活用に対応したプライバシー保護ガイドラインの制定などが必要になると想定される。

総務省 ユビキタスネットワーク時代における電子タグの高度利活用に関する調査研究会 中間報告

といった論点が書かれている。

RFIDは、応用目的によって、ICチップにコストをかけられる場合や、通信距離を数ミリに抑えてかまわない場合や、個人に属さない場合など、プライバシーに影響を与えないものとなることがある。

重要なことは、それぞれの応用において、プライバシーをどのようにして確保するかを洗い出し、解決が困難な応用については当面実用化しないことを早めに決断し、消費者に隠すことなく説明していくことであろう。

日経コンピュータ誌のように「問題がないことにする」というのは、業界の足をかえって引っ張るだけだろう。そろそろそのことに気づいて欲しいものだ。

本日のリンク元 TrackBack(0)

2003年08月23日

続・ツーカーセルラー東海から回答書がきた

8月9日の日記で、(1)〜(4)の4項目の質問をしたのに(1)と(3)にしか回答をくれなかったと書いた件について、その後、再度コールセンターに問い合わせ*1、(2)と(4)についても回答をくれるように依頼していたのだが、その回答書が来た。

2003年8月15日

(挨拶部 略)

■コンテンツプロバイダとの契約にて「サブスクライバーIDは個人情報なのでこれを厳重に管理し外部に漏らさない」との項目はあるか?

(回答)コンテンツプロバイダとの契約におきましては、本サービスの提供にあたり知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しないことを明記致しております。

■非公式サイトヘのサブスクライバーIDの送信を止める機能はあるか? またEZweb@mailを一旦削除して登録しなおす方法以外に、サブスクライバーIDを変更する方法はあるか?

(回答)現行のシステムでは、非公式サイトにサブスクライバーIDへの送信を止める機能はございません。またEZweb@mailを削除して再加入頂く以外にサブスクライバーIDを変更することはできません。

「知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しない」ことが契約で約束されているというのであるから、顧客としては、この文章を見ると直感的に安心感を覚える。

しかし、この回答文は、よく読むと、サブスクライバーIDが「知り得た顧客に関する情報」に含まれるのかどうか、答えていない。「一切の情報」という文節に注目すれば、含まれるように聞こえるが、「顧客に関する」という文節に注目すると、顧客に関するものとしているのかどうかが、不明だ。

この回答を前回の回答とあわせて4項目を並べてみると次のようになる。

(1) サブスクライバーIDは個人情報であるか。

それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありません。

(2) コンテンツプロバイダとの契約にて「サブスクライバーIDは個人情報なのでこれを厳重に管理し外部に漏らさない」との項目はあるか?

コンテンツプロバイダとの契約におきましては、本サービスの提供にあたり知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しないことを明記致しております。

(3) 非公式サイトに対してサブスクライバーIDを送信するのはプライバシーの問題があるのではないか。

コンテンツプロバイダー(以下「CP」)への提供自体に問題はないと考えております。

(4) (略)

(1)の回答からすれば、サブスクライバーIDは、(2)における「顧客に関する情報」にはあたらないと解釈できる。

その解釈の下では、公式サイトとの契約においても、(個人情報との結び付けさえしなければ)外部に転売することが許される(誰かわからないこのIDの人が、いつどんな閲覧をしたかの情報の転売が許される)という解釈も可能に思える。

一方、(2)の質問は、「これ(サブスクライバーID)を厳重に管理し外部に漏らさない」ことを約束しているかという問いである。「顧客に関する情報」でないのなら、

サブスクライバーIDは個人情報ではないので、契約において個別に明記していません。
と回答してもよさそうなものだ。それなのに、「顧客に関する一切の情報について開示・漏洩しない」という回答をここにもってくるのには、「サブスクライバーIDの保護を契約で明記していない」とは回答したくないという気持ちがあるのだろう。

であるなら、なぜ(3)のように、契約関係にないコンテンツプロバイダーである「非公式サイト」への提供について、「問題はない」という回答になるのだろうか。

ここでもやはり、「お客さまの情報は守る」ということと、「お客さまの情報ではない」という二枚の舌が巧みに使われている。

日記がトップに

とうとう、自分の氏名でGoogle検索したときのトップが、勤務先でなく、この日記になってしまった。いかん。勤務先のタイトルを日本語にすれば元に戻るかな。

*1 コールセンターの責任者は、今回もとても顧客想いの対応だった。私からの電話だとわかるやいなや、こちらから話の口火を切るより先に、回答書が回答になっていなかったことに理解を示すのだ。私も昔、いろいろなコールセンターに問い合わせたことがあるが、こんな顧客本位の対応はとても珍しい。回答に責任を持つため明快な回答を避けざるを得ない立場の者と、顧客対応の者とは別といったところだろうか。まさに組織と顧客の仲介役という感じだった。

本日のリンク元 TrackBack(0)

2003年08月24日

セキュリティ研究者はプライバシーを理解しているのか

日本の移動通信システムに関わる業界と個人が集結した「モバイルITフォーラム」というグループがある。ここに、7月25日に公開された「MC部会平成14年度活動報告書」という資料がある。その中に「技術専門委員会活動報告 認証WG報告書」という文書がある。この中に「モバイルID」という用語が出てくる。

「モバイルID」という用語が現れる個所を引用すると次のようになる。

  • 携帯電話で実装される可能性の高いという観点(既述)から、電子メール、Webアクセス、電子署名(FORM署名)を考える。
  • 電子メールでは、メールアドレスがユーザID として一般に利用されている。認証の確実性を上げるための方法としてはS/MIME が一般的であり、S/MIME 用証明書がプロファイルの参考になる。
  • Web アクセスにおいては、携帯電話固有のID(ソフトID、ハードID など、以下モバイルID)がユーザID としてE コマースに使われているこれらはモバイルの世界固有の方法で実現されている。PKI ベースの認証が行なわれていないため、証明書のプロファイルは存在しない。
  • 電子署名は、市場ニーズは顕在化していないが、法的効力をもたせるために、個人の氏名を含むユーザID が使われると思われる。民生向けの特定認証業務のプロファイルがある。
モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.42

2.2.2.2 証明書の位置付けに関するプロファイル
2.2.2.2.1 証明書発行対象

本プロファイルでは、携帯電話契約の「契約」に対して発行することとする。なお、証明書に記載する発行対象は、契約ごとに一意で、かつ証明対象の特定が困難なモバイルID で表現する。

モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.49

2.2.2.3.2 証明対象の表現

証明対象は「Subject」にDN(distinguished name)で表現する。以下の項目は共通仕様とし、他の項目(OU 等)は任意とする。

C = jp
O = (オペレータ社名の英語表記)
CN = (モバイルID。フォーマットは任意)

モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.50

用語集

モバイルID
携帯電話会社が携帯電話契約の「契約」に対して付与するID で、契約ごとに一意で、かつ証明対象の特定が困難なID を意味する。

モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.87

「モバイルID」とは、KDDIグループ(auおよびツーカー)の「サブスクライバーID」、J-PHONEの「製造番号」ないし「ユーザID」NTTドコモの「端末ID」などのことを指すようだ。この報告書は、これらのIDが、「証明対象の特定が困難なID」であるという前提をおいている。

この報告書は、モバイルコマースを実現するための認証技術として、どのような方式が適切であるかを議論し、結論をまとめたものだ。この報告書は90ページにもおよぶが、この内容を8ページにまとめたものが、7月18日に開催された、情報処理学会コンピュータセキュリティ研究会と電子情報通信学会情報セキュリティ研究会の合同研究会で、研究会報告論文として発表されている。

その論文から冒頭部分を引用する。

1. はじめに

公開鍵基盤(PKI)を認証技術として用いた電子政府の実現にともない、これまでのPKIの様々な技術検討が実サービスとして結実し、その技術の可能性が立証されつつある。一方、携帯電話の普及に伴い、モバイルインターネットサービスが普及し、着信メロディの有料配信サービスのような携帯電話を用いた決済サービス(モバイルコマース)が立ち上がり始めている。このような背景を踏まえ、より安全で信頼性の高いモバイルコマースの実現と、オープンな標準技術によるモバイルコマースへの適用が注目されている。

PKIは、その技術標準の核となるX.509がITU-T/JTC1で、また、様々な拡張検討がIETFのPKIX-WGで検討されており、現在、ドラフトも含めて膨大な技術仕様ができあがっている。これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、PKIに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、PKI技術の利用促進に大きく寄与すると考えられる。

これらの点を考慮し、非営利団体であるモバイルITフォーラムMC部会の認証WGでは、平成13年度から、上記に述べたPKIのモバイルコマースへの適用を目的とした技術検討を進めている。本稿では、モバイルコマース部会・認証WGでの14年度の検討結果であるPKI技術の現状、PKIをモバイルコマースへ適用する際の課題とその検討状況について報告する。

2. モバイルITフォーラムMC部会

モバイルITフォーラムは、第4世代移動通信システムやモバイルコマース等の新世代モバイルの早期実現を図るため、新世代モバイルに関する研究開発及び標準化の調査研究、関係機関との連絡調整、情報の収集を目的とした非営利団体であり、その中でも、モバイルコマース部会(MC部会)は、インターネットにおける標準技術をベースとして携帯電話、モバイル網を対象に、モバイルコマースを実現するためのビジネスおよび技術の側面からの検討を行う作業部会である。

モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証WGの活動状況―

この論文は、まず最初に、モバイルコマースにおけるオンラインクレジット決済の方式を、「データ入力型モデル」と「端末格納型モデル」、「サーバ管理型モデル」に分類し、それぞれにおいて必要となる認証方式を洗い出した後、ドメイン間認証技術を分類し、その後に、共通プロファイルの規定について述べている。

さて、肝心の部分は、3.4.3節「モバイルID」にある。ここには次のように書かれている。

3.4.3. モバイルID

一般に、公開鍵証明書が証明する対象(subject)としては、氏名、電話番号、端末製造番号、契約番号などいろいろな可能性があり、サービス提供者が統一的に扱うためには共通化が必要である。プロファイルの規定に当たっては、証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した。

(1) 加入者のプライバシ保護

公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。

(2) 回線契約業務との整合性

(略)

(3) 端末変更の可能性

(略)

以上の考察により認証WGでは

  • リアルの世界で利用者個人を特定する情報(実名、電話番号、住所)が隠蔽される。
  • 機種変更時にも連続性を保証される。

という性質を持つIDとして、加入者契約と一対一に対応し匿名性を持つIDを定め「モバイルID」と呼ぶこととした。モバイルIDは上記条件を満たす限りフォーマットは自由である。モバイルIDはオペレータドメイン証明書のSubjectのCNとして用いられる。

モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証WGの活動状況―

つまり、NTTドコモのFOMA向けクライアント認証証明書発行サービス「FirstPass」が、ここで提案されている方式の一実装といえる。

6月24日の日記「通信キャリアの独占型PKIは安全なのか」や、8月17日の日記「「固有ID」の問題なのか「固定ID」の問題なのか」で書いたように、すべてのCP/SP(コンテンツプロバイダ/サービスプロバイダ)ドメインに共通のIDとなる「モバイルID」を使用することは、第三者cookieや、住民票コードの民間利用などと同様のプライバシー問題を生むものである。

しかし、この論文にはそのことが全く考察されていない。「MC部会平成14年度活動報告書」にもその考察はない。

3.5節で考察されているように、現状のモバイル端末がネットワーク的、ハードウェア的に非力であることと、ユーザのリテラシの低さからくる制約は、たしかにあるだろう。3.5.1節には、ドメイン間認証方式として「独立方式」を採用しない理由が次のように述べられている。

独立方式を用いてドメイン間認証を実現する場合には、複数のドメインの証明書を検証するために、ドメインの数だけ認証局証明書をモバイルユーザがポリシーを理解した上で、安全に入手する必要があり、これは、ユーザリテラシ、端末の記憶容量等の観点から問題点が多い。

モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証WGの活動状況―

「独立方式」とは、サービスプロバイダ自身が運営する認証局からユーザ証明書としてクライアント証明書を発行してもらう方式のことで、PCのWebブラウザではこれが標準となっている。6月25日の日記では次のように書いた。

この件で私が言いたいのは、「FirstPass」は大成功するかもしれないが、「クライアント認証ってこういうものなのね」という理解はして欲しくないということだ。

モバイル端末の上記のような制約から、独立方式ではなく、オペレータドメイン(携帯電話事業者)が認証局となる方式を採用せざるを得ないという結論を出すのは、まあ、よいとしよう。プライバシー上の問題があるにもかかわらず、それを採用し、問題点について触れないようにしておくというのは、営利企業の行動としてはしかたのないことだと、諦めるとしよう。「モバイルITフォーラム」が非営利団体だとはいえ、所詮は業界団体なのだからしかたのないことだと、諦めるとしよう。

だが、情報処理学会のコンピュータセキュリティ研究会、電子情報通信学会の情報セキュリティ研究会という、学術発表の場において、問題点の議論を避けるというのは、いかがなものか。

論文では、「証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した」として、「加入者のプライバシ保護」を挙げているものの、実名、電話番号、住所をDNに含めないようにしたというだけで、問題は解決しましたと言わんばかりである。

「固定IDのプライバシー問題は程度問題であるから、程度を考察した結果、モバイル端末の制約上、やむを得ない選択といえる」という結論を出したのなら、その過程を書くのが学術発表というものだ。

これが、意図的に問題点を隠蔽したものではないとするならば、固定IDの問題を知らないということなのだろう。

「セキュリティ研究者」といっても様々な分野の人たちがいる。暗号のプライバシー応用の研究をしている者からすれば、モバイルIDが「匿名性を持つID」とは片腹痛い話だろう。セキュリティ脆弱性を研究する者からすれば、第三者cookieのプライバシー問題や、SuperCookies問題といった過去の事例から、モバイルIDがプライバシー上のセキュリティホールと批判されることは容易に予測できるだろう。PKIのセキュリティ研究者は、固定IDの問題を本当に知らないのか?

しかし、2001年11月に掲載されたZDNet JAPANの記事「「勝手サイトのトラフィックを増やしたい」──WAP2.0に賭けるKDDI」という記事に次の記述がある。

またEZweb端末では,加入者情報である「サブスクライバID」がサーバ側で簡単に取得できるのが特徴だ。NTTドコモなどではサブスクライバIDは公式コンテンツ向けにしか提供されず,一般サイトではユーザー認証に工夫が必要。新端末でも「社内で議論はあったが,サブスクライバIDは変わらず取得できる」と保戸田氏は言う。

「勝手サイトのトラフィックを増やしたい」──WAP2.0に賭けるKDDI

NTTドコモでは、契約の縛りのある公式サイト内で閉じたドメインでしか、サブスクライバーIDは使われておらず、503i以降で導入された、「端末ID」を非公式サイトにも送信できるようになった機能も、<form>タグに「utn」属性が付けられているページだけで送信されるもので、かつ、ユーザの同意確認付きという配慮がなされている。これは明らかにプライバシーへの配慮であり、同業他社であるKDDIが、その意図を知らないはずがない。「社内で議論はあったが」とは、プライバシーの問題があるとする意見もあったということだろう。

1年半前に既に「社内で議論はあった」という性質の問題について、モバイルITフォーラムのような場で議論されないなどということがあるのだろうか。ましてや、学術発表の場で話題にしないなどということがあっていいのか。

学会発表の日、質疑応答で質問の手を挙げたが、先に出たぬるい質問にのらりくらりと時間をとられ、時間切れで議論にならなかった。セッション終了後に講演者に質問に行ったとき言われたことはこうだった(メモより)。

  • ユーザに説明すればよいことだ
  • 住民票コードとは別の話ですよね、番号を付けられるのがイヤだとか
  • 法律で担保すればよい

「ユーザに説明すればよいこと」というが、NTTドコモの「FirstPass Q & A」のページには、当時、次のように書かれていた。

Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか?

A. ユーザ証明書にはお客様の名前や電話番号等個人情報が記載されていません。ユーザ証明書だけでは個人情報が流出することはありません。

その後このページは改定されたようで、現時点の同ページは、次のようになっている。

Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか?

A. ユーザ証明書には重複しない番号が契約者ごとに割り当てられており、お客様の名前や電話番号等のドコモが管理しているお客様情報は記載されておりません。ユーザ証明書から、ドコモの管理するお客様の名前や電話番号等のお客様情報を知ることはできません

NTTドコモ, FirstPass Q & A

「ドコモの管理するお客さま情報」は知ることはできないというのは、そりゃそうだろう。だが、問題にされているのはそういうことではない。これが、発表者らの言う「ユーザに説明すればよいこと」なのか? 改定してもこういう説明に終始するわけか。

ユーザに説明すべきことは、まず少なくとも、この図*1の左下の画面にある「ユーザ証明書を送信します はい/いいえ」の確認画面で、「いいえ」を選択すべきなのがどういう場面なのかということだ。「アクセス先のサイトが信頼できないときには「はい」を押さないでください」と説明すべきだ。どうしてそれを説明しないのか。せっかくQ & Aを改定したというのに。

「住民票コードとは別の話ですよね、番号を付けられるのがイヤだとか」という発言には、心底呆れた。住民票コードの民間利用が禁じられた理由を、理解していないということだ。セキュリティ研究者がだ。

「法律で担保すればよい」については、8月3日の日記で述べたとおりだ。

我ながら、こういうことをこういうところに書くのはいかがなものかとも思う。反論があるなら、同じ学会の場で発表するのがスジだろう。だが、そういう悠長なことを言っている場合ではない。これは霞を食う話ではなく、社会に直結した問題だ。加えて言うと、情報処理学会は、そういう問題を議論する場になっていない。淡々と論文発表が積み重ねられているだけで、議論というものが存在しない。「誌上討論」という制度が設けられてはいるが、基礎領域以外の分野で活用されているのを見たことがない。

正直なところ、私もこういうことを書くのはつらい。実はごく身近な方が関係者だったりすることもあるので、こういうところに書くのはつらい。この件は当事者には既に言いたいことを言った。それでもここに書くのは、固定IDのプライバシー問題がかくもきちんと対応されていないという現実を、とりあえず多くの技術者が知ることしか、この問題の解決の道はないと思うからだ。このことについては、7月18日の日記「いろいろな人に会うということ」に書いた。

結城浩氏の日記「「固有IDのシンプル・シナリオ」を書いた経緯」で、氏は

しばらくして高木さんの日記が「はてなダイアリー」で始まり、固有ID(固定ID)の問題がなかなか理解されない、という話題が書かれていました。(中略) 高木さんの書かれている内容もよく理解できました。しかしそれと同時に、高木さんの文章に物足りないものも感じていました。 1つは長いこと。それから話が正確で具体的であるあまり、話の大きな流れが見えにくいこと、それから当事者に対するいらだちがちらちら文章の中に現れるためか、「技術そのもの」よりも「人」にフォーカスがあたりがちだという点です

結城浩, 「固有IDのシンプル・シナリオ」を書いた経緯

と述べている。同氏の「固有IDのシンプルシナリオ」は、この問題の当事者の人の要素を排除したものなのだろう。

だが、これは本質的に「人の問題」なのだ。技術的な理屈はべつにたいした話ではない。問題に薄々感づいていながら、問題がないことにする人、フォーラムや学会の場ですら問題点を整理しようとしない人、「ユーザに説明すればよいこと」と言いながら、ユーザには決して説明することをしない人。そこにこそ問題の本質がある。

学会発表ではこういう「人の問題」は書くわけにはいかないだろう。だから5月5日、このように日記という媒体を使うしかないと決意をしたのだ。

追記

次の部分を考えてみる。

なぜこれが「モバイルの世界固有の方法」となっているのか。

ひとつには、携帯電話の世界では、必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる<$=fn "携帯電話事業者からコンテンツプロバイダまでのインターネット通信路上でパケット改竄が可能な場合を除く"%>ためだ。PCの世界でそれを実現しようとすると、なりすましを防ぐための何らかのプロトコルが必要となる。Intelは、1999年にPentium IIIにPSN (Processor Serial Number)を導入したが、その目的は、

Q: Why is Intel developing security features for the platform?

A: The increased use of the Internet for communications and electronic commerce is raising PC users' concerns about the confidentiality and integrity of transaction-oriented data. Since computers are the primary connections to the Internet, they are a logical place for companies to add security features. Over the next several years, Intel is adding security building blocks in order to move the industry forward in developing secure solutions for our customers.

Intel(R) Pentium(R) III Processor Processor Serial Number Questions & Answers

と説明されていた。単に、PSNをコマースサイトに対して送信するだけの方式では、実在するPSNがどこか一か所ででも漏れれば、どこからでもなりすましができるようになってしまうのだから、何らかの工夫が必要となる。

もうひとつの理由は、PCの世界では、ユーザのコンピュータに固有の番号を付けて活用しようという動きは、ことごとく批判されて、すべてお蔵入りになってきたという歴史があるためだ。しばしば、「Pentium IIIのPSNは問題とされるのに、ネットワークインターフェイスのMACアドレスはなぜ問題にされないの?」という声を耳にするが、MACアドレスをユーザ認証に使おうとしたメジャーな動きがなかったために批判されなかったにすぎない。IPv6で下位64ビットにMACアドレスをそのまま使うという話が出たときは、プライバシーの問題があるとして批判され、RFC 3041ができたという経緯がある。

ではなぜ「モバイルの世界」では批判されてこなかったか。これは、モバイルコマースが日本で先行して普及しているためではなかろうか。EZweb方式のサブスクライバーIDのHTTP上の名前である「X-UP-Subno」でGoogle検索しても、英語圏のページがあまりヒットしない。ほとんど話題になっていないのだ。日本で先行しているからこそ、「モバイルITフォーラム」というドメスティックなグループが、

これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、PKIに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、PKI技術の利用促進に大きく寄与すると考えられる。

モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証WGの活動状況―

という先例のない検討を行うことができるわけである。そして、8月16日の日記「蚊帳の外だった日本が初めて患う大人の麻疹」で述べたように、日本ではこれまで固定IDのプライバシーの議論をする機会がなかった(住基ネットの話題を除いて)ため、技術を設計する立場の人たちが見識を持たないまま、ここまできてしまったと思われる。

PKIの話に戻すと、PKIとはそもそも人を特定するための技術であり、プライバシーとは相反するのはある意味当然である。証明書にズバリ実名と住所を書いていたらどうだろうか。ユーザは、住所と氏名を相手に提供する場合にだけ、その証明書を使うことになるだろう。証明書にメールアドレスを記載している場合はどうだろうか。ユーザは、メールを送信する場合など、相手に自分のメールアドレスを伝えて当然である場面で、その証明書を使うだろう。

Webアクセスでは、メールと違い、通常のアクセスでは自分が誰であるかを伝えないのが前提となっている。商品の送り先を指定する際に、住所氏名を送信するようにして使う。もし、携帯電話用のクライアント証明書に、住所氏名が記載されていたらどうなるだろうか。Q & Aには次のような説明が出てくるだろう。

Q. 「証明書を送信しますか?」というプロンプトが出ます。これはどのような場合に「はい」と答えてよいのでしょうか?

A. 証明書にはお客様の氏名と住所が記載されています。送信先のサイトに住所氏名を提供してもかまわない場合にだけ「はい」を押すようにしてください。

これはこれでわかりやすい話だ。消費者は、証明書の取り扱いに注意するだろう。

これに対し、モバイルITフォーラムの論文では、証明書に住所氏名を掲載しなかった理由を次のように述べている。

(1) 加入者のプライバシ保護

公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。
 モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証WGの活動状況―

つまり、ユーザプロンプトで利用者に注意を促しても、ユーザのリテラシレベルが低すぎるから、なんでも「はい」を押してしまうことを懸念し、紛失時に住所がばれてしまうことも懸念したためとされている。

このことがかえって証明書の取り扱いを曖昧なものにしてしまったと言える。証明書には「証明対象の特定が困難なID」しか書かれていないので、ユーザのリテラシが低くて何でも「はい」を押してしまう状況でもかまわないというわけだ。かまわないのだから、Q & Aにも説明がされない。

ところで、これはもはや「モバイル世界固有の方法」ではないことに注意してほしい。PKIを使わない状況でのモバイルIDは、先に述べたように、

必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる

ものであるため、「モバイル世界」ならではの方式だったが、PKIの証明書のcommon nameにユニーク番号を付けるというこの方式は、ゲートウェイやネットワーク方式とは無関係であるのだから、モバイル世界固有でもなんでもない。

PKIのWebアクセスのクライアント認証での使われ方を国際的に見渡したとき、このような各ドメイン全域に共通なIDを付与する方式は、他に類を見ないものだろう。それは、モバイルITフォーラムの案が先進的だからなのではなく、単にプライバシーの問題があるから誰もやっていないというだけだろう。「モバイル世界固有の話なので」という釈明は通用しない。国際的な赤っ恥をかく前に、早めに代替案を検討しておいた方がよい。

本日のリンク元 TrackBack(0)

2003年08月25日

住民基本台帳カードをゲット

住基ネットにはこれといって思い入れのない私なのだが、今日は早起きしたし、せっかくの初日なのだしと、がらにもなく市役所に出向いて住基カードをゲットしてきた。行ってみると支庁舎で2番乗りだった。係員が慣れない様子で発行までずいぶん時間がかかったが、その間、次の申請者は現れなかった。カードは非接触型ではなかった。がっかり。

何に使えるのかと係員に尋ねると、親切に教えてくれた。他の市町村の役所から住民票を取得できるのだという。だが、カードを機械に入れると発行してくれるわけではなく、申請書は手で書く必要がある。住基カードは本人確認のために使われるそうだ。しかも、そのとき、住基カードでなく、運転免許証でもかまわないのだとか。なんだよ、住基カードの出る幕ないじゃん。ようするに、住基カードは免許証を持たない人々のための公的身分証ということらしい。(つくば市の場合。)(今のところ。)

来年の秋には公的個人認証が始まって、自宅からインターネット経由で婚姻届とかが出せるようになるのだとか。楽しみだ。つくば市では、それまでは使い道がないようだ。気長に待つとしよう。

係員さんも初々しく、やたら丁寧に説明してくれるので、役所にしては楽しいひと時だった。窓口の向かい合う席で、係員がオペレータ用ICカードをリーダに挿す。そしてキーボードを打つ。おいおい、パスワードが丸見えだよ。その係員さんの打ったパスワードは、4桁の数字だった。とても覚えやすい番号だった。まあ、そんなもんだろう。たいしたことじゃないんだし。

そしてカードに自分の暗証番号を登録する。もう一台ある手前側のリーダにカードを挿し、フード付きのテンキーを押して4桁の暗証番号を入力。フードの高さは3センチくらい。係員さんからもよく見えたことだろう。お客さんが確認キーを押していなければ、押してくださいとアドバイスができて親切な感じだ。フードは奥側にしかないので、後ろからは丸見えだ。でも大丈夫。誰もいない。

係員さん、操作をミスったのか戸惑っている様子。端末の画面を覗き込んでみると、コマンドプロンプトの黒いウィンドウが。何やら接続中みたいなメッセージが。前にどこかで見たことがある。おお、これが噂の住基ネット端末か。

端末の裏側を見るとごく普通のパソコンだ。裏側を見るといっても、客側なので目の前にそれはある。うむむ、青色のイーサーネットケーブルが普通に挿さっているぞ。抜いたらどうなるかなあ。間に何か挟んだらどうなるかな。鞄の中のノートPCに挿すとどうなるだろうか。カードリーダもUSB接続か。抜いたらどうなるかなあ。間に何か挟んだらどうなるかなあ。キーボードコネクタも手が届きそう。USBソケットにフラッシュメモリとか差し込むとどうなるかなあ。まさか「自動再生」でプログラムが動き出したりしないよね。まあ、そんなことしても何ができるやら。やる価値があるのかどうか。

しかし、考えてみると、こういう風景って他では見かけない。銀行とか、郵便局とか、図書館とか。まあ、お金を盗られるわけじゃないし。公的個人認証が始まったわけでもないし。あ、今のうちに盗まれてたものが1年後に悪用開始されると困るなあ。気をつけよう。

今日も平凡な日記だ。

追記

窓口で客側に向かっている面に開いているUSBの口に、持参したキーホルダー型のUSBメモリを差し込むと、どんな罪に問われるのだろう? 一般に、穴は挿し込まれるために開いているものなわけだが。

追記2

きっと、ケーブルを抜いたりすると、IDS(侵入検知システム)が警告をしてくれるようになっているのだろう。USBに挿したりするとアンチウイルスソフトが遮断してくれるのだろう。

追記3

係員がオペレータ用ICカードを挿入して暗証番号を打つシーンが、夜7時のNHKニュースで放映されていた。以下に、公正な慣行に合致したニュース映像の引用をする。

これはきっと実演を依頼されて、偽の暗証番号をタイプしているところなのだろう。キーボードの見通しは良好。まあ、オペレータの暗証番号くらい、どうってことない。

追記4

http://www1.accsnet.ne.jp/~takagi/security/tsukuba-city-1/

本日のリンク元 TrackBack(0)

2003年08月28日

擬似固有PICC識別子

山根さんの日記8月27日より:

住基カード表面にはチップがついてますが,これに端子を接触させなければ通信できないのでしょうか?

いいえ,住基カードは非接触式と接触式のチップを一つにまとめ,メモリを共用できるようにしており,これをカード業界ではコンビネーションカード(コンビカード)と呼んでいます.


 おお、そういうことだったのか。住基ネットにこれといって思い入れのない私なので、自治体の自由選択なのかなあという程度の認識だった。両方のインターフェイスを持つなどという冗長な設計は思いもよらなかったが、たしかに、カードは全国で使えないといけないのだから、どちらかが必須でないといけないわけで、ISO/IEC 14443 TYPE B の方を必須としたと。

公的分野における連携ICカード技術仕様(公的分野におけるICカードの普及に関する関係府省連絡会議申し合せ)」に基づいたものということだろうか。

地方自治情報センターの「住民基本台帳ネットワークシステム住民基本台帳カード仕様書」は公開されていない(少なくともWebでは)ようだが、ニューメディア開発協会の「近接型通信インタフェース実装規約書 第1.1版R2」の第12章には、次のように書かれている。

12.2.9.2 擬似固有PICC 識別子(PUPI)
(1) 基本仕様

擬似固有PICC 識別子(PUPI)は、衝突防止処理時にPICC を識別するために使用される。4 バイトの数値で、一時的に発生された乱数(または固定値の一部を切り取ったもの)である。PUPI の値は、IDLE 状態の場合以外は変更することができない。

12.2.9 リクエスト応答(ATQB)
(1) 基本仕様

REQB/WUPB コマンドとスロットマーカコマンドに対する応答を、ATQBと呼ぶ。

12.2.9.1 ATQB の形式
(1) 基本仕様

PICC から送出されるATQB の形式を「図12.2−12 ATQB の形式」に示す。

第1バイト第2〜第5バイト第6〜第9バイト第10〜第12バイト第13・第14バイト
‘50’
(1 バイト)
PUPI
(4 バイト)
応用データ
(4 バイト)
プロトコル情報
(3 バイト)
CRC_B
(2 バイト)

12.2.7 REQB/WUPB コマンド
(1) 基本仕様

REQB およびWUPB コマンドは、動作磁界内にタイプB のPICC が存在するかどうかを検出するために使用される。

近接型通信インタフェース実装規約書 第1.1版R2 第12章 衝突防止

ほほう。

ネタメモ

ZDNetニュース「RFIDのプライバシー問題、遮断タグで対応

論文はこれ。アンチコリジョンの制御を逆手にとって、リーダが読めなくする話のようだが、まだ読んでない。プライバシーゾーンを使い分ける話、悪意ある「Blocker Tag」についての考察があるもよう。

本日のリンク元 TrackBack(0)

2003年08月31日

住基カード裏面のサインパネル

先日ゲットしてきた住基カード、裏面を見ると、なぜだかメモ書きできるところが用意されている。何を誰が書くところなんだろう?

やはり、お年をめされた方が暗証番号を忘れないようにメモできる欄なのだろうか。

非接触ICカード普及センターの「カード調達時の選択指針」を見ると、用途はとくに決まっていないらしい。

Q:裏面印刷はどのように考えるか、サインパネルはどう考えるか

A:住基カードの裏面印刷は、特に仕様の提示がないため、独自のデザイン(何も印刷しないことも含め)が可能です。利用面から考えますと、表面の記述内容(住所、電話番号等)が変更になった場合の新しい内容をサインパネルに記述する等のことが考えられ、利用上の注意事項等を記載しておくことも考えられます。NMDAでは、裏面の標準印刷仕様を準備し、検討していただけるように考慮しています。いずれも必須事項ではないので、自治体側の必要性に応じて対応することとなります。

非接触ICカード普及センター, カード調達時の選択指針

とりあえず、ダミーの4桁数字を書いてみた。適当な4桁数字で暗証番号ではない。万が一カードを紛失し、悪意ある者が拾って窃用しようとしたとき、きっとこれを暗証番号だと思って打ち込むだろう。2回目ももう一回試すかもしれない。そうなれば、犯人に残されたチャンスはあと1回だけとなる。

あ、もしかして勝手に書いちゃいけないところかな。よく考えてみると運転免許証の裏もメモ欄があるのだが、勝手に書いちゃいけないっぽい感じがする。だけど、住基カードを受け取るとき、書いちゃダメといった注意は何もなかった。

マイクロソフトのテレビCMで

朝テレビをつけたら、マイクロソフトのWindows 2003 ServerのテレビCMが流れていたのだが、最後の一瞬の画面に、「あなたの資産を守るため、Windows Updateをしましょう」みたいなことが書かれていた*1

たばこのCMの「あなたの健康を損なうおそれがありますので吸いすぎに注意しましょう」、薬のCMの「用法用量を守って正しくお使いください」、はたまた消費者金融の「ご利用は計画的に」みたいだ。

すばらしい。まずはよい一歩だと言えよう。だが、これでは既にわかっている人にしか意味は伝わらないだろう。そもそもうちの両親なんかには「Windows Update」という横文字を読むことすらできまい。

いっそ、Windows Updateの使い方を実演してみせるCMを流したらどうだろうか。無理な話なのだろうか。

政府広報とか、公共広告機構のTVスポットで流すというのはできないのかなあ。特定の民間事業者についてだけ流すというわけにはいかないのだろうか。Mac OS Xと同時にならどうか。

政府広報にはこんな番組もあるようだ。

  • 新ニッポン探検隊!

    身近でホットな情報、知って良かったと思える情報について、VTR取材又は有識者等が出演し、国民各層向けに分かりやすく解説する。

  • ご存知ですか〜生活ミニ情報〜

    政府施策のうち、国民生活に密着したテーマに関する情報及び告知的なものについて、有識者又は各府省の担当者等が出演し、主婦層を対象に解説する。

まあ、無理な話っぽい。政府施策にならないうちは無理っぽい。

誰か試しにスポットCM映像を作ってみるとか。Flashとかでかっこいいのを作ればけっこう出回るかも?

あと、「Windows Update」だと横文字を読めない人たちには記憶に残らない問題を解決するため、名前を日本語に変えたほうがよいのではないか。「欠陥修理」とか。無理か。

追記

マイクロソフトのテレビCM、夕方の番組で偶然録画できていた。メッセージは正確にはこうだった。

あなたのPCを守るため、
“Windows Update” を
今すぐご利用ください。

www.microsoft.com/japan

表示時間は3秒間だった(30秒CMのうち)。

ところで、Windows Update をする必要があることは、マニュアルに記載されているのだろうか。

3年前、Microsoft VM for Javaのセキュリティホール発覚に関わったとき、パソコンメーカー各社に、修正方法の説明なしに、欠陥があるとわかっているソフトウェアを内蔵したパソコンを販売するのはおかしいのではないかと、掛け合ったことがある。当然、無視されたわけだが、その後、ソニーのVAIOでは、箱の中に何枚か入っている注意書きの色紙のひとつに、「インターネットにはウイルスなどの危険が潜んでいるのでセキュリティ情報を収集しましょう」のようなことが書かれた紙が同梱された。他社がどうなっているかは知らない。

もっと明確に、Windows Updateが必須の作業であることを説明し、その手順を説明する紙を、パソコンメーカー各社は同梱する義務があるのではなかろうか。

現状は、「お客様が最新版をお使いになりたければ Windows Update することができます」的な説明に終わっている状況ではないか。

そもそも、パッチを同梱せずに欠陥品を販売し続けていることに、違法性はないのかと。

参照:

一般に、欠陥のある商品やサービスの提供は、それ自体として違法である。...

製造物責任法の適用がなければ一切の法的責任がないという見解もあるが、これは、完全な誤解に基づく間違った見解である。

夏井高人, SNSポリシーに関する意見

メーカと何らかの契約関係にあるときは,契約違反が理由になる。メーカと消費者のように契約関係でない場合は,民法709条が適用できる。条文は「故意又は過失に因りて他人の権利を侵害したる者は之に因りて生じたる損害を賠償する責に任ず」。これを「不法行為責任」と呼ぶ。予見できる欠陥は,製品出荷前に修正すべきである。これを怠り,欠陥を残したソフトウェアをそのまま販売したのなら,メーカに過失があると考えられる。この場合は,不法行為責任を根拠にメーカを訴えられる注12)。ただしその欠陥が一般的に予見できないものと判断されれば,メーカに過失はないことになり,責任は問われない可能性が高い。

セキュリティ法律相談室, ソフト会社の責任, 日経バイト 2002年7月号

パッチがリリースされているのだから、「予見できる欠陥」であるのは間違いないだろう。

追記2

マイクロソフトのCMの画像がこちらで紹介されていた。

*1 録画し損ねた。次はどこで放送かな。

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

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