Best practices for unique identifiers

この例では、このようになります。 これは、ユーザーから明確な許可を得ていない場合、Google Play DeveloperContent Policy に違反することになります。

Advertiser ID と PII の間のリンクは、必ずしも明示的でないことに留意してください。 PII および Ad ID キー付きテーブルの両方に表示される「準識別子」を持つことが可能で、これも問題を引き起こします。 例えば、TABLE-01とTABLE-02を以下のように変更するとする。

この場合、どうすればいいのでしょうか。 十分に稀なクリックイベントで、イベントのタイムスタンプとデバイスモデルを使用して、広告主ID TABLE-01とTABLE-02に含まれるPIIを結合することは可能である。

データセットにそのような準識別子が存在しないことを保証するのは難しい場合が多いですが、可能であれば固有のデータを一般化することで、最も明白な結合リスクを防ぐことができます。

その他の解決策としては、以下のものがあります。

• PII と Advertising ID を明示的にリンクするテーブルを設計しないこと。 上記の最初の例では、TABLE-01にaccount_id列を含めないことを意味します。

• 広告IDキーデータとPIIの両方にアクセスできるユーザーまたは役割のアクセス制御リストを分離して監視する。両方のソースに同時にアクセスする能力を厳密に制御および監査（たとえば、テーブル間の結合を実行）すると、広告IDおよびPII間の関連のリスクを軽減することができます。 一般に、アクセスの制御とは次のことを意味します。

  1. 広告主IDのキーデータおよびPIIに対するアクセス制御リスト（ACL）を分離して、両方のACLに含まれる個人または役割の数を最小限に抑えます。

Advertising ID を責任を持って使用するための詳細については、AdvertisingIdClient API リファレンスを参照してください。

FID と GUID の使用

デバイスで実行中のアプリ インスタンスを識別する最も簡単なソリューションは、Firebase インストール ID (FID) の使用で、これは広告以外のほとんどの使用例で推奨されているソリューションです。 プロビジョニングされたアプリ インスタンスのみがこの識別子にアクセスでき、アプリがインストールされている間のみ持続するため、（比較的）簡単にリセットできます。

結果として、FID は、リセットできないデバイス スコープのハードウェア ID と比較してより優れたプライバシー プロパティを提供します。

FID が実用的でない場合、カスタムグローバル一意 ID (GUID) を使用してアプリ インスタンスを一意に識別することもできます。 これを行う最も簡単な方法は、次のコードを使用して独自の GUID を生成することです。

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

この識別子はグローバルにユニークなので、特定のアプリ インスタンスを識別するために使用することができます。 アプリ間の識別子のリンクに関する懸念を回避するために、GUIDは外部（共有）ストレージではなく、内部ストレージに格納します。 詳細については、「データとファイルの保存」のページを参照してください。

MAC アドレスで動作しない

MAC アドレスはグローバルに一意で、ユーザーがリセットできず、工場でリセットされても存続します。 これらの理由から、ユーザーのプライバシーを保護するために、Androidバージョン6以降では、MACアドレスへのアクセスはシステムアプリに制限されています。 サードパーティアプリは、MACアドレスにアクセスすることができません。

MAC address availability changes in Android 11

On app targeting Android 11 and higher, Passpointnetworks for MAC randomization is per Passpoint profile, generated a unique MAC address based on the following fields.Android11以降のアプリでは、MACアドレスのランダム化はPasspointプロファイルごとに行われ、以下のフィールドに基づき、一意のMACアドレスを生成します。

• Fully-qualified domain name (FQDN)
• Realm
• Credential, based on the credential used in the Passpoint profile:
  • User credential: user name
  • Certificate credential: cert and cert type
  • SIM credential: Certificate, type

  SIM: Cert, type

• Credential: user name

Cert, type SIM: Cert and certificate type

• Credential: User credential

User credential, type

さらに、非特権アプリはデバイスの MAC アドレスにアクセスできず、IP アドレスのネットワーク インターフェースのみが表示されます。 これは、getifaddrs()およびNetworkInterface.getHardwareAddress()メソッド、ならびにRTM_GETLINKNetlink メッセージの送信に影響します。

• NetworkInterface.getHardwareAddress() はすべてのインタフェースに対して null を返します。
• アプリは NETLINK_ROUTE ソケット上で bind() 関数を使用することはできません。
• ip コマンドはインターフェースに関する情報を返しません。
• アプリは RTM_GETLINK メッセージを送信できません。

ほとんどの開発者は NetworkInterface, getifaddrs(), あるいは Netlink ソケットといった低レベル API よりも ConnectivityManager 高レベル API を使うべきであることに注意しましょう。 たとえば、現在の経路に関する最新の情報を必要とするアプリは、ConnectivityManager.registerNetworkCallback()を使用してネットワークの変更をリッスンし、ネットワークの関連するLinkProperties.getRoutes()を呼び出してこの情報を取得できます。

Identifier characteristics

The Android OS offers a number of ID with different behavior characteristics.Which ID should use depends on how the following characteristics work with your use case.IDは、さまざまな動作特性を持つIDを提供します。 しかし、これらの特性にはプライバシーに関する影響もあるため、これらの特性が互いにどのように作用するかを理解することが重要です。

Scope

Identifier scope は、どのシステムが識別子にアクセスできるかを説明します。 Androidの識別子スコープには、一般的に次の3つの種類があります：

• 単一アプリ。
• Group of apps: ID は、あらかじめ定義された関連アプリのグループからアクセス可能です。

識別子に付与される範囲が広ければ広いほど、トラッキング目的で使用されるリスクが高くなります。

リセット可能性および永続性

リセット可能性および永続性は、識別子の寿命を定義し、どのようにリセットできるかを説明します。 一般的なリセット トリガーには、アプリ内リセット、システム設定によるリセット、起動時のリセット、インストール時のリセットがあります。 Androidの識別子の寿命はさまざまですが、通常はIDのリセット方法によって寿命が異なります。

リセット機能により、ユーザーは既存のプロファイル情報から切り離された新しいIDを作成することができます。 工場出荷時のリセットを超えてIDが持続するような、より長く、より信頼性の高いIDが持続すればするほど、ユーザーが長期間の追跡を受ける可能性があるというリスクが高くなります。 アプリの再インストール時に ID がリセットされる場合、アプリまたはシステム設定内から ID をリセットする明示的なユーザー制御がない場合でも、ID の持続性が減少し、リセットされる手段が提供されます。 それ以外の場合、一意性のレベルは、識別子のエントロピーと、識別子を作成するために使用されるランダム性のソースに依存します。 たとえば、インストールした日付（2019-03-01 など）をシードしたランダムな識別子は、インストールした Unixtimestamp（1551414181など）をシードした識別子よりも衝突する確率がはるかに高くなります。 つまり、各デバイスとアカウントの組み合わせは一意の ID を持ちます。

Integrity protection and non-repudability

なりすましや再生が困難な識別子を使用して、関連するデバイスまたはアカウントが特定の特性を有することを証明することができます。 例えば、そのデバイスがスパマーによって使用される仮想デバイスではないことを証明できます。スプーフィングが困難な識別子は、否認不可能性も提供します。 デバイスが秘密鍵でメッセージに署名すれば、他人のデバイスがメッセージを送ったと主張することは困難です。 5534>

Common use cases and the appropriate identifier to use

The section provides alternatives to use hardware IDs such as IMEI.このセクションでは、IMEI などのハードウェア ID の使用に対する代替案を提供します。 ハードウェア ID の使用は、ユーザーがリセットできず、デバイスに再スコープされるため、推奨されません。 多くの場合、アプリにスコープされた識別子で十分です。

Track signed-out user preferences

この場合、ユーザー アカウントなしでサーバー側でデバイスごとの状態を保存していることになります。 FID または GUID

なぜこの推奨事項なのでしょうか。

ユーザーがアプリを再インストールして設定をリセットしたい場合があるため、再インストールによる情報の持続は推奨できません。

Use: SSAID

なぜこの推奨があるのか

Android 8.0 (API レベル 26) 以上では、SSAID は同じ開発者の署名キーで署名されたアプリ間で共通の識別子を提供します。 これにより、ユーザーがアカウントにサインインすることなく、これらのアプリ間で状態を共有することができます。

サインアウトしたユーザーの行動を追跡する

この場合、同じデバイス上のさまざまなアプリ/セッションでのユーザーの行動に基づいて、ユーザーのプロファイルを作成しました。 Advertising ID

Why this recommendation?

Use of the Advertising ID is mandatory for advertising use cases per the GooglePlay Developer ContentPolicy because the user can reset it.

Generate signed-out or anonymous user analytics

In this case, you’re measuring usage statistics and analytics for signed out or anonymous users.

Use: Advertising ID Use for Advertising ID

We’s a user for advertising use cases for GooglePlay Developer ContentPolicy: FID、または FID が不十分な場合は GUID

なぜこの推奨なのか

FID または GUID は、それを作成するアプリにスコープされ、アプリ間でユーザーの追跡に使用されるのを防ぎます。 また、ユーザーがアプリのデータを消去したり、アプリを再インストールしたりできるため、簡単に再設定可能です。 FID と GUID の作成プロセスは簡単です。

• FID の取得: Firebase インストール ガイドを参照してください。

• GUIDの作成: 次のコードニペットに示すように、アプリにロジックを実装します。

  Kotlin

  val uniqueID: String = UUID.randomUUID().toString()

  Java

  String uniqueID = UUID.randomUUID().toString();

ユーザーに収集しているデータが匿名であると伝えた場合、識別子をPIIや他のPIIとリンクする可能性がある識別子に接続していないことを確認する必要がありますので、注意してください。

Google Analytics for MobileApps を使用して、アプリごとの分析を行うこともできます。

Track signed-out user conversions

この場合、マーケティング戦略が成功したかどうかを検出するために、コンバージョン数を追跡しています。 Advertising ID

Why this recommendation?

これは広告関連のユースケースで、異なるアプリ間で利用可能な ID が必要となる場合があります。 FID または GUID

なぜこの推奨なのか

FID はこの目的のために明示的に設計されています。その範囲はアプリに限定されているので、異なるアプリ間でユーザーの追跡に使用できず、アプリの再インストール時に再設定されます。

Associate functionality with mobile service subscriptions

この場合、デバイス上の特定のモバイル サービス サブスクリプションにアプリの機能を関連付ける必要があります。 5534>

Use: Subscription IDAPI toidentify SIMs that are used on the device.

The Subscription ID provides an index value (starting at 1) for uniquelyidentifying installed SIMs (including physical and electronic) used on thedevice.

Use: Subscription IDAPI to activate SIMs on the device.

[使用方法: デバイスで使用しているSIMを特定します。 このIDにより、アプリはその機能を、指定されたSIMの様々なサブスクリプション情報と関連付けることができます。 この値は、デバイスが工場出荷時にリセットされない限り、特定のSIMに対して安定した値です。 しかし、同じ SIM が異なるデバイスで異なる Subscription ID を持つ場合や、異なる SIM が異なるデバイスで同じ ID を持つ場合があります。Subscription ID が十分にユニークでない場合、Subscription ID を SSAID に連結することが推奨されます。 ICC ID はグローバルに一意であり、リセットできないため、Android 10 以降、アクセスは READ_PRIVILEGED_PHONE_STATE 許可を得たアプリに制限されています。 Android 11 からは、アプリのターゲット API レベルに関係なく、getIccId()API を介して ICCID にアクセスすることが制限されるようになりました。 影響を受けるアプリは、代わりに Subscription ID を使用するように移行してください。

Anti-fraud: 無料コンテンツ制限の実施とシビル攻撃の検出

この場合、ユーザーがデバイス上で見ることができる記事などの無料コンテンツの数を制限したい場合に使用します。 FIDまたはGUIDを使用します。 Android 8.0 (API レベル 26) 以降では、アプリ署名キーにスコープされているため、SSAID もオプションとして使用できます。 これが十分な保護でない場合、Android はコンテンツへのアクセスを制限するために使用できる DRMAPI を提供し、これには APK ごとの ID、Widevine ID が含まれます。

Carrier functionality

この場合、アプリはキャリア アカウントを使ってデバイスの電話およびテキスト機能を操作しています。

Use: IMEI, IMSI, and Line1

なぜこの推奨なのか

キャリア関連の機能に必要であれば、ハードウェア識別子を使用することは容認されます。 たとえば、携帯電話キャリアまたは SIM スロットの切り替えや、SMS メッセージの overIP (Line1 用) – SIM ベースのユーザー アカウントの配信に、これらの識別子を使用することができます。 しかし、非特権アプリの場合は、アカウントサインインを使用して、ユーザーデバイス情報をサーバーサイドで取得することをお勧めします。 その理由の一つは、Android 6.0 (API level 23) 以降では、これらの識別子はランタイムパーミッションを介してのみ使用できるためです。 ユーザーはこの権限をオフにする可能性があるため、アプリはこれらの例外を優雅に処理する必要があります。

Abuse detection:

Abuse detection: Identifying bots and DDoS attacks

この場合、バックエンド サービスを攻撃する複数の偽のデバイスを検出しようとしています。 エミュレータや他のコードが別のデバイスになりすましているのではなく、本物のAndroidデバイスからのリクエストであることを確認するには、SafetyNet APIのattest()メソッドを使用して、リクエストするデバイスの整合性を確認します。 詳細については、SafetyNet APIのドキュメントを参照してください。

不正使用検出: 高価な盗難クレデンシャルの検出

この場合、不正な支払いなど高価な盗難クレデンシャルで1つのデバイスが複数回使用されているかどうかを検出しようとしています。 しかし、IMEI や IMSI などのハードウェア識別子は、ルート化されたデバイスやエミュレートされたデバイスで簡単に変更できるため、詐欺の信頼できる指標にはならないことに注意してください。