[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
<前の日記(2003年08月02日) 次の日記(2003年08月06日)> 最新 編集

高木浩光@自宅の日記

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

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

検索

<前の日記(2003年08月02日) 次の日記(2003年08月06日)> 最新 編集

最近のタイトル

2024年12月22日

2024年12月07日

2024年12月02日

2024年11月24日

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
<前の日記(2003年08月02日) 次の日記(2003年08月06日)> 最新 編集