唯一 ID 的最佳做法

本文將根據您的用途，提供為應用程式選取合適 ID 的指南。

如需查看有關 Android 權限的一般資訊，請參閱權限總覽一文。如要瞭解使用 Android 權限的具體最佳做法，請參閱「應用程式權限最佳做法」。

使用 Android ID 的最佳做法

為保護使用者隱私權，請使用符合應用程式用途且最嚴格的 ID。請特別遵循下列最佳做法：

  1. 盡可能選擇可由使用者重設的 ID。即使應用程式使用無法重設的硬體 ID 以外的 ID，也能滿足大多數用途。

  2. 避免使用硬體 ID。在大多數情況下，您可以避免使用國際行動裝置識別碼 (IMEI) 等硬體 ID，且不會影響必要功能。

    Android 10 (API 級別 29) 新增了無法重設的 ID 限制，包括 IMEI 和序號。您的應用程式必須是裝置或設定檔擁有者應用程式、具備特殊電信業者權限，或是擁有 READ_PRIVILEGED_PHONE_STATE 權限，才能存取這些 ID。

  3. 只將廣告 ID 用於剖析使用者或廣告用途。使用廣告 ID 時，請一律尊重使用者對廣告追蹤的選擇。如必須將廣告 ID 連結至個人識別資訊，請務必取得使用者的明確同意。

  4. 請勿橋接廣告 ID 重設作業。

  5. 除了防範付款詐欺和電話服務外，請盡可能針對所有其他用途使用 Firebase 安裝 ID (FID) 或私密儲存的 GUID。對於絕大多數的非廣告用途，FID 或 GUID 應該就足夠。

  6. 請使用適合您用途的 API，盡量降低隱私權風險。使用 DRM API 保護高價值內容，並使用 Play Integrity API 防範濫用行為。Play Integrity API 是判斷裝置是否為正版的最佳方式，而且不會造成隱私權風險。

本指南的其餘部分會詳細說明這些規則，並以開發 Android 應用程式為例。

使用廣告 ID

廣告 ID 是可供使用者重設的 ID，適用於廣告用途。不過，使用這個 ID 時，請留意以下幾點：

請一律尊重使用者重設廣告 ID 的意願。 請勿在未經使用者同意的情況下，使用其他 ID 或指紋連結後續的廣告 ID，藉此建立使用者重設前後的關聯。《Google Play 開發人員內容政策》規定如下：

「...廣告 ID 經過重設後，在未經使用者明確同意下，新 ID 不得與舊 ID 本身或其衍生資料建立連結。」

請一律尊重相關聯的個人化廣告標記。廣告 ID 可供設定，使用者可以限制與 ID 相關聯的追蹤量。請務必使用 AdvertisingIdClient.Info.isLimitAdTrackingEnabled() 方法，確保不會違背使用者的意願。《Google Play 開發人員內容政策》規定如下：

「...您的廣告放送方式必須符合使用者的『停用按照興趣顯示的廣告』或『停用廣告個人化』設定。如果使用者啟用上述設定，您就不得使用廣告 ID 建立放送廣告所需的設定檔，或針對使用者放送個人化廣告。允許使用的功能包括內容相關廣告、展示頻率上限、轉換追蹤、報表與安全性，以及詐騙偵測。"

請注意，您使用的 SDK 如與廣告 ID 使用情形相關，則須遵守相關隱私權或安全性政策。 舉例來說，如果您從 Google Analytics SDK 將 true 傳遞至 enableAdvertisingIdCollection() 方法，請務必詳閱並遵守所有適用的 Analytics SDK 政策。

此外，請注意，根據 Google Play 開發人員內容政策規定，廣告 ID「不得與個人識別資訊建立連結，或與任何永久裝置 ID (例如 SSAID、MAC 位址、IMEI 等) 建立關聯」。

舉例來說，假設您想收集資訊，以填入資料庫表格，其中包含下列資料欄：

TABLE-01
timestamp ad_id account_id clickid
TABLE-02
account_id name dob country

在這個例子中，ad_id 資料欄可透過兩個表格中的 account_id 資料欄與 PII 連結，如果您未取得使用者的明確授權，這會違反《Google Play 開發人員內容政策》。

請注意，廣告主 ID 和 PII 之間的連結不一定會這麼明確。如果「準 ID」同時出現在 PII 和廣告 ID 鍵控資料表中，也可能導致問題。舉例來說，假設我們變更 TABLE-01 和 TABLE-02，如下所示：

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

在這種情況下，如果點擊事件不常發生，還是有可能使用事件的時間戳記和裝置型號，在廣告主 ID TABLE-01 和 TABLE-02 中包含的 PII 之間進行聯結。

雖然通常很難保證資料集中沒有這類準 ID，但您可以盡可能概略化不重複的資料，避免最明顯的聯結風險。在上述範例中，這表示降低時間戳記的準確度，讓每個時間戳記都顯示多部相同型號的裝置。

其他解決方案包括：

  • 請勿設計明確連結 PII 與廣告 ID 的資料表。在上述第一個範例中，這表示 TABLE-01 不會包含 account_id 資料欄。

  • 為可存取廣告 ID 鍵控資料和 PII 的使用者或角色，區隔及監控存取權控管清單。 嚴格控管及稽核同時存取這兩項來源的能力 (例如執行資料表之間的聯結)，可降低廣告 ID 與 PII 產生關聯的風險。一般來說，控管存取權是指執行下列操作：

    1. 將廣告主 ID 鍵控資料和 PII 的存取控制清單 (ACL) 分開，盡量減少同時存在於兩個 ACL 中的個人或角色數量。
    2. 導入存取記錄和稽核功能，偵測及管理這項規則的任何例外狀況。

如要進一步瞭解如何負責任地使用廣告 ID，請參閱 AdvertisingIdClient API 參考資料。

使用 FID 和 GUID

如要識別裝置上執行的應用程式例項，最簡單的方法是使用 Firebase 安裝 ID (FID)，這也是大多數非廣告用途的建議解決方案。只有已佈建的應用程式例項可以存取這個 ID，而且只要應用程式已安裝，這個 ID 就會持續存在，因此 (相對) 容易重設。

因此，與無法重設的裝置範圍硬體 ID 相比，FID 具有更完善的隱私權屬性。詳情請參閱 firebase.installations API 參考資料。

如果 FID 不實用，您也可以使用自訂全域專屬 ID (GUID) 識別應用程式執行個體。最簡單的方法是使用下列程式碼產生自己的 GUID：

Kotlin

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

Java

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

由於 ID 是全域專屬，因此可用於識別特定應用程式例項。為避免與跨應用程式連結 ID 相關的疑慮，請將 GUID 儲存在內部儲存空間，而非外部 (共用) 儲存空間。詳情請參閱「資料和檔案儲存空間總覽」頁面。

不使用 MAC 位址

MAC 位址在全球都不會重複，無法由使用者重設，且不會在恢復原廠設定後變更。基於上述原因，為保護使用者隱私，Android 6 以上版本會限制系統應用程式存取 MAC 位址。第三方應用程式無法存取這些資料。

Android 11 的 MAC 位址可用性異動

如果應用程式指定 Android 11 以上版本，系統會為每個 Passpoint 設定檔隨機產生 Passpoint 網路的 MAC 位址，並根據下列欄位產生專屬 MAC 位址：

  • 完整網域名稱 (FQDN)
  • 運作範圍
  • 憑證，根據 Passpoint 設定檔中使用的憑證：
    • 使用者憑證：使用者名稱
    • 憑證憑證：憑證和憑證類型
    • SIM 卡憑證：EAP 類型和 IMSI

此外，非具備特殊權限的應用程式無法存取裝置的 MAC 位址，只能看到具有 IP 位址的網路介面。這會影響 getifaddrs() 和 NetworkInterface.getHardwareAddress() 方法，以及傳送 RTM_GETLINK Netlink 訊息。

以下列出應用程式受這項異動影響的方式：

  • NetworkInterface.getHardwareAddress() 會針對每個介面傳回空值。
  • 應用程式無法在 NETLINK_ROUTE 插座上使用 bind() 函式。
  • ip 指令不會傳回介面相關資訊。
  • 應用程式無法傳送  訊息。RTM_GETLINK

請注意，大多數開發人員應使用 ConnectivityManager 的高階 API，而非 NetworkInterface、getifaddrs() 或 Netlink Socket 等低階 API。舉例來說，如果應用程式需要目前路線的最新資訊，可以透過 ConnectivityManager.registerNetworkCallback() 監聽網路變更，並呼叫網路的相關聯 LinkProperties.getRoutes()，取得這項資訊。

ID 特徵

Android OS 提供多種 ID，具有不同的行為特徵。應使用哪個 ID，取決於下列特徵如何與您的用途搭配運作。不過，這些特徵也會影響隱私權，因此請務必瞭解這些特徵之間的互動方式。

範圍

識別碼範圍說明哪些系統可以存取識別碼。Android ID 範圍通常有三種版本：

  • 單一應用程式：ID 是應用程式內部 ID，其他應用程式無法存取。
  • 應用程式群組：ID 可供預先定義的相關應用程式群組存取。
  • 裝置：裝置上安裝的所有應用程式都能存取 ID。

授予 ID 的範圍越廣，該 ID 就越有可能用於追蹤。反之，如果 ID 只能由單一應用程式例項存取，就無法用於追蹤不同應用程式中的交易。

可重設性和持續性

可重設性和持續性會定義 ID 的生命週期，並說明如何重設 ID。常見的重設觸發條件包括：應用程式內重設、透過「系統設定」重設、啟動時重設，以及安裝時重設。Android ID 的生命週期可能有所不同，但通常與 ID 的重設方式有關：

  • 僅限工作階段：使用者每次重新啟動應用程式時，系統都會使用新的 ID。
  • 安裝後重設：每當使用者解除安裝並重新安裝應用程式時，系統都會使用新的 ID。
  • 恢復原廠設定：使用者每次將裝置恢復原廠設定時，系統都會使用新的 ID。
  • FDR-persistent：ID 在恢復原廠設定後仍會保留。

重設功能可讓使用者建立與現有設定檔資訊無關的新 ID。如果 ID 持續存在的時間越長，且越可靠 (例如在恢復原廠設定後仍存在)，使用者就越有可能遭到長期追蹤。如果應用程式重新安裝後，識別碼會重設，這會縮短保存期限，並提供重設 ID 的方法，即使沒有明確的使用者控制項，可從應用程式或系統設定中重設 ID 也是如此。

唯一性

唯一性可判斷發生衝突的可能性，也就是相關範圍內存在相同 ID 的可能性。在最高層級，全域不重複 ID 絕不會發生衝突，即使是在其他裝置或應用程式上也是如此。否則，唯一性程度取決於 ID 的熵，以及用於建立 ID 的隨機性來源。舉例來說，如果隨機 ID 是以安裝日期 (例如 2019-03-01) 做為種子，發生衝突的機率會比以安裝的 Unix 時間戳記 (例如 1551414181) 做為種子高出許多。

一般而言，使用者帳戶 ID 可視為專屬 ID。也就是說，每個裝置/帳戶組合都有專屬 ID。另一方面，如果 ID 在族群中越不獨特，就越能保護隱私，因為這類 ID 較不適合追蹤個別使用者。

完整性防護和不可否認性

您可以利用難以偽造或重播的 ID，證明相關聯的裝置或帳戶具有特定屬性。舉例來說，您可以證明裝置不是垃圾內容傳送者使用的虛擬裝置。難以偽造的 ID 也提供不可否認性。如果裝置使用私密金鑰簽署訊息，就難以宣稱訊息是由其他人的裝置傳送。不可否認性可能是使用者需要的屬性 (例如驗證付款時)，也可能是不需要的屬性 (例如傳送後悔的訊息時)。

常見用途和適用的 ID

本節提供使用硬體 ID (例如 IMEI) 的替代方案。建議不要使用硬體 ID，因為使用者無法重設，且 ID 僅適用於裝置。在許多情況下，應用程式範圍的 ID 就已足夠。

帳戶

貨運公司狀態

在這種情況下，應用程式會使用電信業者帳戶與裝置的電話和簡訊功能互動。

建議使用的 ID：IMEI、IMSI 和 Line1

為什麼會推薦這項內容？

如果電信業者相關功能需要使用硬體 ID，則可接受。舉例來說，您可以使用這些 ID 在行動網路業者或 SIM 卡插槽之間切換，或透過 IP (適用於 Line1) 傳送簡訊 - 以 SIM 卡為基礎的使用者帳戶。不過，對於沒有權限的應用程式，我們建議使用帳戶登入功能，在伺服器端擷取使用者裝置資訊。其中一個原因是，在 Android 6.0 (API 級別 23) 以上版本中，這些 ID 只能透過執行階段權限使用。使用者可能會切換關閉這項權限，因此應用程式應妥善處理這些例外狀況。

行動裝置訂閱狀態

在這種情況下，您必須將應用程式功能與裝置上的特定行動服務訂閱項目建立關聯。舉例來說，您可能需要根據裝置透過 SIM 卡訂閱的行動方案，驗證是否可存取特定進階應用程式功能。

建議使用的 ID： 訂閱 ID API，用於識別裝置上使用的 SIM 卡。

訂閱 ID 提供索引值 (從 1 開始)，用於專屬識別裝置上使用的已安裝 SIM 卡 (包括實體和電子 SIM 卡)。應用程式可透過這個 ID，將功能與特定 SIM 卡的各種訂閱資訊建立關聯。除非裝置恢復原廠設定，否則這個值在特定 SIM 卡上不會變動。不過，在不同裝置上，同一張 SIM 卡可能會有不同的訂閱 ID，或不同 SIM 卡在不同裝置上可能會有相同的 ID。

為什麼會推薦這項內容？

部分應用程式目前可能使用 ICCID 達成這個目的。由於 ICC ID 是全域專屬且無法重設，因此自 Android 10 起，只有具備 READ_PRIVILEGED_PHONE_STATE 權限的應用程式才能存取。從 Android 11 開始，Android 進一步限制透過 getIccId() API 存取 ICCID，無論應用程式的目標 API 級別為何皆是如此。受影響的應用程式應改用訂閱 ID。

單一登入

在這種情況下，您的應用程式提供單一登入體驗，讓使用者將現有帳戶與貴機構建立關聯。

建議使用的 ID：與帳戶管理員相容的帳戶，例如 Google 帳戶連結

為什麼會推薦這項內容？

使用者可以透過 Google 帳戶連結功能，將現有的 Google 帳戶與您的應用程式建立關聯，以便順暢且安全地存取貴機構的產品和服務。此外，您還可以定義自訂 OAuth 範圍，只分享必要資料，並清楚說明資料用途，藉此提高使用者信任度。

廣告

指定目標

在這種情況下，應用程式會建立使用者興趣的設定檔，向他們顯示更切合需求的廣告。

建議使用的 ID：如果應用程式使用 ID 放送廣告，並上傳或發布至 Google Play，則該 ID 必須是廣告 ID。

為什麼會推薦這項內容？

這是與廣告相關的用途，可能需要貴機構不同應用程式都能使用的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

無論您是否在應用程式中分享使用者資料，只要收集及使用這些資料放送廣告，就必須在 Play 管理中心「應用程式內容」頁面的資料安全性專區中，聲明廣告用途。

數據評估

在這種情況下，應用程式會根據使用者在同一部裝置上使用貴機構應用程式的行為，建立使用者設定檔。

建議使用的 ID：廣告 ID 或 Play 安裝參照網址 API

為什麼會推薦這項內容？

這是與廣告相關的用途，可能需要貴機構不同應用程式都能使用的 ID，因此使用廣告 ID 是最合適的解決方案。如果您將 ID 用於廣告用途，該 ID 必須是廣告 ID，因為使用者可以重設廣告 ID。詳情請參閱《Google Play 開發人員內容政策》。

轉換次數

在本例中，您追蹤轉換是為了判斷行銷策略是否成功。

建議使用的 ID：廣告 ID 或 Play 安裝參照網址 API

為什麼會推薦這項內容？

這是與廣告相關的用途，可能需要貴機構不同應用程式都能使用的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

再行銷

在本例中，應用程式會根據使用者先前的興趣顯示廣告。

建議使用的 ID：廣告 ID

為什麼會推薦這項內容？

這是與廣告相關的用途，可能需要貴機構不同應用程式都能使用的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

應用程式分析

在這種情況下，應用程式會評估使用者行為，協助您判斷下列事項：

  • 貴機構的其他產品或應用程式中，哪些可能適合使用者。
  • 如何讓使用者對應用程式保持興趣。
  • 評估已登出或匿名使用者的使用統計資料和數據分析。

可能的解決方案包括：

  • 應用程式組 ID：只要不將使用者資料用於廣告用途，您就能使用應用程式組 ID 分析使用者在貴機構擁有的多個應用程式中的行為。如果您指定以 Google Play 服務為基礎的裝置，建議使用應用程式集 ID。
  • Firebase ID (FID)：FID 的範圍僅限於建立該 ID 的應用程式，因此無法用來跨應用程式追蹤使用者。此外，使用者可以清除應用程式資料或重新安裝應用程式，因此 FID 也很容易重設。建立 FID 的程序很簡單，請參閱 Firebase 安裝指南。

應用程式開發

當機回報

在這種情況下，應用程式會收集使用者裝置上發生當機的時間和原因。

建議使用的 ID：FID 或應用程式組 ID

為什麼會推薦這項內容？

FID 的範圍僅限於建立該 ID 的應用程式，因此無法用來跨應用程式追蹤使用者。此外，使用者可以清除應用程式資料或重新安裝應用程式，因此 FID 也很容易重設。建立 FID 的程序很簡單，請參閱 Firebase 安裝指南。只要不將使用者資料用於廣告用途，您就能使用應用程式集 ID 分析使用者在貴機構擁有的多個應用程式中的行為。

成效報表

在這種情況下，應用程式會收集載入時間和電池用量等效能指標，協助您提升應用程式品質。

建議使用的 ID： Firebase Performance Monitoring

為什麼會推薦這項內容？

Firebase Performance Monitoring 可協助您專注於最重要的指標，並測試應用程式近期變更的影響。

應用程式測試

在本例中，您的應用程式會評估使用者體驗，以利測試或偵錯。

建議使用的 ID：FID 或應用程式組 ID

為什麼會推薦這項內容？

FID 的範圍僅限於建立該 ID 的應用程式，因此無法用來跨應用程式追蹤使用者。此外，使用者可以清除應用程式資料或重新安裝應用程式，因此 FID 也很容易重設。建立 FID 的程序很簡單，請參閱 Firebase 安裝指南。只要不將使用者資料用於廣告用途，您就能使用應用程式集 ID 分析使用者在貴機構擁有的多個應用程式中的行為。

跨裝置安裝

在這種情況下，如果同一位使用者在多部裝置上安裝應用程式，應用程式就必須識別正確的應用程式執行個體。

建議使用的 ID：FID 或 GUID

為什麼會推薦這項內容？

FID 專為此目的而設計，範圍僅限於應用程式，因此無法用於追蹤不同應用程式的使用者，且會在重新安裝應用程式時重設。在極少數情況下，如果 FID 不足，您也可以使用 GUID。

安全性

濫用行為偵測

在這種情況下，您要偵測多部攻擊後端服務的偽造裝置。

建議使用的 ID：Google Play Integrity API 完整性權杖

為什麼會推薦這項內容？

如要驗證要求是否來自正版 Android 裝置，而非模擬器或其他可模擬裝置的程式碼，請使用 Google Play Integrity API。

廣告詐欺

在這種情況下，應用程式會檢查使用者在應用程式中的曝光和動作是否真實且可驗證。

建議使用的 ID：廣告 ID

為什麼會推薦這項內容？

根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

數位著作權管理 (DRM)

在本案例中，您的應用程式希望防止他人以詐欺手法存取智慧財產或付費內容。

建議使用的 ID：使用 FID 或 GUID 會迫使使用者重新安裝應用程式，才能規避內容限制，這足以嚇退大多數人。如果這樣還不夠，Android 提供 DRM API，可用於限制內容存取權，包括每個 APK 的 ID (Widevine ID)。

使用者偏好設定

在這種情況下，應用程式會將每個裝置的使用者狀態儲存在應用程式中，特別是未登入的使用者。您可能會將這個狀態轉移到同一部裝置上，以相同金鑰簽署的其他應用程式。

建議使用的 ID：FID 或 GUID

為什麼會推薦這項內容？

不建議在重新安裝應用程式時保留資訊，因為使用者可能會想透過重新安裝應用程式重設偏好設定。