Java 標準では、Object.equals()、Comparable.compareTo()、または Comparator.compare() の実装のパラメーターが null である場合には特定の値を返さなくてはならないと定めています。この規約に違反すると、予期せぬ動作が引き起こされる可能性があります。

例 1: 次の equals() メソッドの実装では、パラメーターと null との比較をしていません。

public boolean equals(Object object)
{
   return (toString().equals(object.toString()));
}

次の場合に Privacy Violation が発生します。

1. ユーザーの個人情報がプログラムに持ち込まれる場合。

2. コンソール、File System、ネットワークなどの外部の場所にデータが書き込まれる場合。
例 1: 次のコードには、データベースに加えられたレコードのコンテンツをログ ファイルに格納して追跡するロギング ステートメントが含まれています。

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

Example 1 のコードでは、平文のパスワードがファイルシステムに記録されています。多くの開発者がファイルシステムをデータの安全な格納先として信頼しがちですが、特にプライバシーに関わる場合は盲目的に信頼しないでください。

プライバシーは、いくつかの理由により、モバイルの世界で最も懸念される事項の 1 つです。理由の 1 つは、デバイスをなくす機会が非常に多いことです。もう 1 つは、モバイルアプリケーション間のプロセス間通信にあります。モバイル プラットフォームでは、あちこちのソースからアプリケーションがダウンロードされ、同じデバイス上で一緒に実行されます。このため、たとえばバンキング アプリケーションのすぐそばでマルウェアを実行するなどの可能性が高くなるので、アプリケーションの開発者は、同じデバイスで実行されている他のアプリケーションに送信するメッセージにどの情報を含めるかについて十分注意する必要があります。機密性の高い情報は、モバイルアプリケーション間のプロセス間通信で扱われないようにする必要があります。

例 2: 次のコードは、Android WebView store から特定サイトのユーザー名とパスワードを読み取り、それを登録済みの全受信者に開示します。

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

この例では、いくつかの問題を示しています。まず、WebView の認証情報はデフォルトで平文によって保存されており、ハッシュされていません。ユーザーのデバイスがルート化されている (またはエミュレータを使用している) 場合、保存されている特定サイトのパスワードを読み取ることができます。次に、平文だけのの認証情報が登録済みの全受信者に開示されることは、SEND_CREDENTIALS アクションによってインテントに接続リクエストを行うように登録済みの受信者の誰もがメッセージを受信することを意味します。この開示は受信者数を制限する許可によっても保護されませんが、この場合対策として許可を使用することは推奨されません。

個人データがプログラムに持ち込まれる方法はさまざまです。

- パスワードや個人情報の形でユーザーが直接入力する。

- アプリケーションにより、データベースなどのデータストアからアクセスされる。

- パートナなどの第三者から間接的に持ち込まれる。

通常、モバイル環境の文脈では、機密情報に (パスワード、SSN、およびその他の一般的な個人情報加えて) 次を含みます。

- 場所

- 携帯電話番号

- シリアル番号およびデバイス ID

- ネットワーク オペレーター情報

- ボイスメール情報


個人情報と明記されていないデータも、別のコンテキストでは個人情報としての意味を持つことがあります。たとえば、学籍番号は、学生の個人情報に結びつくような明示的で公開されたマッピングがないので、通常、個人情報とは見なされません。しかし、学校が学生の社会保障番号に基づいて学籍番号を生成する場合は、学籍番号は個人情報と見なすべきです。

多くの場合、セキュリティとプライバシーの問題は互いに競い合っているかのようです。セキュリティの見地からは、異常な活動があった場合に後で識別できるように、重要な操作はすべて記録するべきです。ただし、個人データが関係する場合、それによりリスクが生じる可能性があります。

個人データの安全でない取り扱いにもさまざまな形態がありますが、一般的なリスクの原因は不適切な信頼にあります。多くの場合、プログラマはプログラムが実行される操作環境を信頼するので、個人情報を File System やレジストリなどのローカルに制御されているリソースに格納することも適切だと考えます。ただし、一部のリソースへのアクセスが制限されている場合も、実際にアクセス権を持っている個人なら信頼できるとは限りません。たとえば、2004 年には、AOL のある不心得な従業員が、約 9,200 万人の個人顧客の電子メール アドレスを、海外のギャンブル Web サイトのマーケティングをしているスパマーに販売しました [1]。

こうした悪用が注目を集めたため、個人データの収集と管理に関する規制は厳しさを増しています。会社などの所在地や業種、処理する個人データの性質によって異なりますが、以下に挙げる連邦や州の規制の遵守を求められる場合があります。

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

これらの規制にも関わらず、Privacy Violation はますます高い頻度で発生し続けています。

HttpRequest クラスにより、プログラムは QueryString、Form、Cookies、または ServerVariables コレクションの変数に配列アクセスの形でアクセスすることができます (Request["myParam"] など)。同じ名前の変数が 2 個以上存在する場合、.NET フレームワークは次の順序でコレクションを検索して最初に検出した変数の値を返します。QueryString、Form、Cookies、ServerVariables。QueryString は最初に検索されるため、QueryString のパラメーターがフォーム、cookie、およびサーバーの変数の値より優先される可能性があります。同様に、フォームの値は Cookies と ServerVariables コレクションの変数より優先され、Cookies コレクションの変数は ServerVariables の変数より優先される場合があります。
例 1: ユーザーの電子メールアドレスを一時的に cookie に保存しておき、そのユーザーに連絡する際にその値を読み取る、というバンキングアプリケーションを例に考えてみます。次のコードは cookie の値を読み取り、指定された電子メールアドレスに口座の残高を送信します。

...
    String toAddress = Request["email"];        //Expects cookie value
    Double balance = GetBalance(userID);
    SendAccountBalance(toAddress, balance);
...

Example 1 のコードが http://www.example.com/GetBalance.aspx にアクセス中に実行されると仮定してみましょう。攻撃者が認証済みユーザーに http://www.example.com/GetBalance.aspx?email=evil%40evil.com をリクエストするリンクをクリックさせることができる場合、そのユーザーの口座残高が記載された電子メールは evil@evil.com に送信されてしまいます。

HttpRequest クラスにより、プログラムは QueryString、Form、Cookies、または ServerVariables コレクションの変数に配列アクセスの形でアクセスすることができます (Request["myParam"] など)。同じ名前の変数が 2 個以上存在する場合、.NET フレームワークは次の順序でコレクションを検索して最初に検出した変数の値を返します。QueryString、Form、Cookies、ServerVariables。QueryString は最初に検索されるため、QueryString のパラメーターがフォーム、cookie、およびサーバーの変数の値より優先される可能性があります。同様に、フォームの値は Cookies と ServerVariables コレクションの変数より優先され、Cookies コレクションの変数は ServerVariables の変数より優先される場合があります。
例 1: 次のコードは、コンテンツを表示する前に www.example.com からリクエストが送信されたことを確認するために、HTTP リファラー ヘッダーのサーバー変数をチェックしています。

    ...
    if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
        ServeContent();
    else
        Response.Redirect("http://www.example.com/");
    ...

Example 1 のコードが http://www.example.com/ProtectedImages.aspx にアクセス中に実行されると仮定してみましょう。攻撃者がこの URL に対して直接リクエストを送信すると、適切なリファラーヘッダーが設定されず、そのリクエストは失敗します。しかし、攻撃者が必要な値を持つ偽の HTTP_REFERER パラメーター (http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com など) を送信した場合には、このルックアップによって ServerVariables ではなく QueryString の値が返され、チェックに合格することになります。