課題：ユーザ背景情報の扱い方

第 ３ 章 課 題 分 析

47

３．４ 課題，考察事項

本章の３.２.１項で述べた解決課題を，図３.９を参照して述べる．パーソナル情報 などをＰＰＳに集約し，ユーザ背景情報やコミュニティ状況をチェックし，その結果 を匿名度調整や開示情報調整に反映させ，調整された開示情報をプロバイダに提供し サービスコンテンツを受けるという一連の流れのなかで，（２）～（３）においてど のようにチェックし，どのように匿名化処理や開示処理に反映させるかが課題である．

以下，基本的な対処の考え方も含め，それらについて述べる．

第 ３ 章 課 題 分 析

48

図 ３.１８ ユーザ背景情報の考え方 属性もＲ´よりＲに段階的に増やしていくことが考えられる[59]．

しかし，もしプロバイダにユーザに関する何らかの背景情報がある場合，希望匿名 度 L を確保できなくまり，意図しない情報開示につながる恐れがある．つまり，プロ バイダに背景情報として属性Ｍ（属性の集合）があれば開示された属性Ｒ´と合わせ ることで実質Ｍ＋Ｒ´の属性を開示したと同じことになり実質的な匿名度がＬより下 がったＬ－になる可能性がある（図３.１７参照）．

ここでユーザ背景情報の考え方で あるが，ユーザから預かるパーソナ ル情報（ユーザＤＢ）はセキュアな ＰＰＳで管理されるため，外部に漏 れることはないが，その要素の出所 よりＤＢの断片情報，あるいは断片 に繋がる何らかの情報としていろい ろなルートやタイミングで漏れ，結 果プロバイダに渡ることが予想され る．ＰＣやスマホより漏れたり，会 社のサイトや個人のブログ，ツイッ タより漏れたり，ＳＮＳや風評，関 連プロバイダからの横流しとか，で

ある．この様子を図３.１８に示す． 図 ３.１９ プライバシ保護の２ステップ

第 ３ 章 課 題 分 析

49

そのように漏れたＤＢの断片がプロバイダにたまたまあったとき，問題が発生 する．開示情報と背景情報が合わさって紐付けされ，Ｌが損なわれる可能性があ る．

そもそも，プライバシ保護とは，実空間の本人と，仮想空間のプライバシ情報 が結びつかないことであり，仮想空間でＩＤとプライバシが結びつき，且つ実空 間でそのＩＤと実本人が結びつく，という２段階のステップを踏まない限りプラ イバシは保護される．プロバイダの背景情報は実空間での手がかりを与えＬを損 なう可能性がある．Ｌで決まる開示属性は仮想空間上のみで計算されるので，も し実空間に背景情報があり，それと紐付けされるとＬが保証されない可能性がで てくる．本研究の意図は，背景情報と開示情報とを合わせてもトータルにＬを確 保することであり，そのためには，事前に背景情報を探知し開示情報と合わせて もＬを保証ができるプロバイダかどうかを確認することが必要となる．図３.１９ は，この考え方に基づく．

例えば図３.２０に示す事例において，左上の表はある６人グループのＤＢであ るが，ユーザを Alice として，希望匿名度Ｌ＝２（Ｓ＝３）¹ のとき，プロバイダ に何の背景情報も無ければ（血液型：A 型）は開示できる（他に３パターン，全

図 ３.２０ 紐付けの様子

1 ６人集団ではＬの各レベルＬ＝０，１，２，３に相当するＳの値は，Ｓ＝０，１，２，

３，４人としている．

第 ３ 章 課 題 分 析

50

４パターンが開示可能）．しかし，仮にプロバイダに背景情報として（初渡航：

Ｙｅｓ）があれば，（血液型：Ａ）の開示は不可能となり，（血液型：Ａ）を開 示してサービスを受けたいとき，このプロバイダは利用できない．なぜなら，そ れら両属性が紐付けされるとＳ＝１となりＬ＝２（Ｓ＝３）が確保できないから である．つまり，背景情報と開示情報が紐付けられてもＳ＝３を確保できるのは，元 のＤＢで二つの属性の組合せがＳ＝３が確保している時に限る．

もちろん，図３．２０に示すように，紐付けされないかぎり，（血液型：Ａ）の開 示のみでＳ＝３は損なわれないが，いつなんどき，紐付け情報によってＳ＝３は 保証されなくなる可能性があり，本研究においては，プロバイダに開示前すでに

（初渡航：Ｙｅｓ）が背景情報として有る場合，（血液型：Ａ）の開示は，Ｓ＝３に おいては開示不可能属性と考える．

このような事態を避けるには，情報を開示する前にそのプロバイダの背景情報を探 り，その結果によって適切な対応措置をとる必要がある．例えば，背景情報があって 希望匿名度を守れない恐れがあるプロバイダからのサービスは控える，あるいは，希 望匿名度を変更して再試行するなどの措置である．

以上，課題：プロバイダのユーザ背景情報への対処，であり，これについて背景情 報の探索方法などを含め，提案手法の詳細を次章以降で述べる．