OpenIDとプライバシー
最近ずいぶんフィード消化してませんでした。で、久しぶりに見てみたら、こんな話がZIGOROuさんとこに。
Web+DBのOrenID特集を読みました。、教えて欲しい疑問点があります。素人なので初歩的な疑問点で申し訳ありませんが、よろしくお願い致します。
今、携帯電話の契約者固有ＩＤのプライバシーの懸念が問題になっています。http://takagi-hiromitsu.jp/diary/20080710.html
問題点を以下に要約しますと、
ａ サイトで住所氏名Ｅメールアドレス等の個人特定情報を入力することによって、その個人特定情報と契約者固有ＩＤ（ｉモードＩＤ等）とが紐付けられ、ネット上での行動履歴情報が契約者固有ＩＤを手掛かりに収集され（名寄せされ）、その収集情報と個人とが結び付けられる。
ｂ 収集情報と個人とを結び付けた情報（以下「個人特定型ライフログ」という）が、悪徳業者の手に渡り、詐欺行為等のツールとして悪用される。
というものです。世界に１つの固有ＩＤという点では、OrenIDも契約者固有ＩＤと同じですよねえ。そうすると、契約者固有ＩＤと同じ問題が生じるのではないかとの疑問が生じます。
OrenIDでは、このプライバシー問題をどのように解決しているのか教えてください。
id:futureeyeさんからの質問
OrenID。オレオレIDみたいなものですね、わかります。
まあ冗談はさておき、
大きく違う点は、
* 携帯の方は自分の意思とは無関係に第三者に自分固有のIDが通知されている
* OpenID は自分の意思で第三者に認証結果を通知すると言う訳で誰がそれを行っているかの観点で話が明らかに違います。
OpenID とプライバシーについて - Yet Another Hackadelic
以上はまず重要な前提として
クロール可能なデータはプライバシーではないと個人的には思います。
OpenID とプライバシーについて - Yet Another Hackadelic
という点について、もうちょっと深掘りしてみる。
例えば僕のはてなダイアリーは全然クロール対象だし、はてなのOpenIDつかって入ったサイトと、クロールされた結果としての僕のブログのいろいろな発言と結びつけられても、まあ仕方ない。それはそういうもんである。
だけど、例えば僕が今からログインしようとしているOpenIDのRPサイトが、ネット上の人格とは別のアクティビティである場合（最近あんまりそういうこともなくなってきたけど）、不用意に結びついてしまうとまずいな、と警戒することはあると思う。
プライベート、仕事、コミュニティなど、複数の面を持つ人は、きっと少数派ではない。そういうとき、どうするのが正しいのだろう？
はてなOpenIDじゃない、ほかのOPを使えばいい？でもそのサイトがログインを受け付けてるOPのリスト（ホワイトリスト）の中に自分のアカウントを持っていなかったら？
別のアカウントを用意する？あれ、OpenIDでアカウントの濫造は抑制されるのではなかったけ？
この例だと、問題をホワイトリストの非オープン性やペルソナ実装の必要性に持っていくこともできるけれども、プライバシーの観点から絞って見てみる。
端的に言うと、OpenID は（2.0以前は）プライバシーという観点で言うと、段差が急すぎだった。つまり、こう言っているのと同等。
「ログインしたければあなたのIDを私に曝せ、でなければ私のとこにはログインさせてあげないよ。」
この中間にあり得るはずの「ログインはしたいけれども、IDは教えたくないよ」という要求には答えられていなかった。
というと「なんだそれ？IDを教えずにログインなんてできないじゃん？誰が誰だかわからなくなるよ！」と言われそうな気がする。
うん、ログインには確かに来訪者を一意に表す識別子は必要だけど、それがグローバルである必要は無いんだってこと。インターネット中で一意なIDってのは、ログインという事象を実現することだけを考えたら、結構オーバースペックなのだ。
実際、このようなOpenIDプロバイダがある。OpenID.ee。(via tkudo) このサービスはOpenID 2.0 の仕様を元に実装されている。
具体的には OpenID.ee と Yahoo!. とくに OpenID.ee では自身の管理しているアカウント名とは別の識別子を, RP (Relying Party) ごとにランダムに生成し払い出すらしい.
http://blogs.sun.com/tkudo/entry/using_pseudonym_in_openid2_deployment
ただし、そもそもOpenIDって、URLが自分を表してる、って言う前提から入ってきたような仕様なので、そこに立ち返りたい人にとっては、「本物の」URLを渡さないOpenID.eeやYahooのようなやり方はむしろなじまないのかもしれない。
たとえばOpenIDからSocial Graphにつなげようとしたいとき、FOAFのデータがそのURLにおいてあって、それディスカバリできたらいいじゃん、分散SNSだよ！みたいなことを考えてる人にとって、URLがIDじゃないのはひどくめんどくさく思えるんだろう。
だが、プライバシー原理主義からみたら、グローバルIDになり得るURLを教える同意と、ログインセッションを伝播させることに対する同意とは別物であるべきであって、その選択の自由を与えるべきだ、ということになるのだろう。
さて、実は、こういっておいてなんだけれども、自分自身の意見は、必ずしも段差はなだらかである必要はないよな、という意見でいます。結局、今はまだOpenIDはデベロッパーのものです。デベロッパーにとってわかりやすいのが一番です。あと、エンドユーザにとっても、選択肢の多さは混乱を招きます。OpenIDというだけでも（ホワイトリストつきでさえも）十分従前と比べて選択肢が増えてしまっているので、いかに混乱させないかが今の一番の課題のはずなのです。
-
-
-
-
- -
-
-
-
以下、ちょっとOpenIDから離れて、だらだらと書く。
携帯の場合も、サイト毎にローカルなIDを渡すようにすればよかった。ドメイン毎に違う、しかし同一ドメインの中では固定で識別できるIDをゲートウェイが振ってあげられればよかった。それをしなかったのは、おそらくそれでは膨大なリクエストに対して処理能力が間に合わないという試算でもあったのだろうか。さすがに何も考えずやってることはないよな、と思ってるが。
元のIDにドメイン文字列を加えた値にハッシュ関数を適用したようなものでもいいのではないか。この場合、マッピングDBをルックアップする必要はないから、DB負荷は減らせる。でも、ハッシュ計算のCPU負荷がもっと高いだろうので、結局キャリアでは採用できないかもしれない。
ちなみにこの方法（ハッシュ）は、FeliCaのIDを記録する機能を持った組み込み機器が、プライバシー問題に対してこの方法で対処しようとしていたという話を聞いたことがある（この場合ハッシュに追加して入れるのはドメインではなくって製品／サービス毎の独自の値）。実際に商品化されたものが出ているのかどうかはわからないけれども。
そういえば、昔、ドコモがやってたな。マイボックス。今もちゃんとやってるのか。事業やサービスの善し悪しとぜんぜんちがうところで、事業者毎に違う識別子が届く、っていう細かな仕様で、ちゃんと考えてんだな、って思った記憶がある。
以下のサイトにそれっぽい記述はあるけど、明確に事業者毎に異なるIDだ、とは書いてない。もしかしたら記憶違いかも。
１．ユーザ認証機能
エラー | ドコモビジネスオンライン | NTTドコモ
ユーザ認証機能とは、お客様が企業様のサイトにアクセスすると同時に、お客様を特定できるＩＤを企業様に通知する機能です。お客様はＩＤ／パスワードなどを入力することなしに自分専用の情報にアクセスすることで、より簡単に企業様の提供するサービスをご利用できます。
