唯一 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 取得高價值內容保護，並使用 SafetyNet API 防範濫用行為。SafetyNet API 是判斷裝置是否正規的最簡單的方法，而不會產生隱私風險。

本指南的其他章節會詳細說明這些規則，說明如何開發 Android 應用程式。

使用廣告 ID

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

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

「...一旦重設，在未經使用者明確同意的情況下，新的廣告 ID 不得與先前的廣告 ID 或是先前廣告 ID 衍生的資料建立連結。」

請一律遵守與個人化廣告標記相關的規定。廣告 ID 可讓使用者設定與 ID 相關的追蹤次數。請一律使用 AdvertisingIdClient.Info.isLimitAdTrackingEnabled() 方法，以免規避使用者的意願。Google Play 開發人員內容政策規定如下：

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

在使用廣告 ID 的過程中，留意與所用 SDK 相關的隱私權或安全性政策。 舉例來說，如果您從 Google Analytics (分析) SDK 將 true 傳入 enableAdvertisingIdCollection() 方法，請務必查看並遵循所有適用的 Analytics (分析) SDK 政策。

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

例如，假設您想要收集資訊，將資訊填入下列資料欄的資料庫資料表：

資料表-01
timestamp ad_id account_id clickid
資料表-02
account_id name dob country

在此範例中，ad_id 欄可透過這兩個資料表的 account_id 欄與 PII 彙整，如果您未向使用者取得明確權限，這就會違反《Google Play 開發人員內容政策》。

請注意，廣告客戶 ID 和 PII 之間的連結不一定明確。您可能會在 PII 和廣告 ID 對應的表格中出現「準識別項」，這也會造成問題。例如，假設我們將 TABLE-01 和 TABLE-02 變更如下：

資料表-01
timestamp ad_id clickid dev_model
資料表-02
timestamp demo account_id dev_model name

在這種情況下，在極罕見的點擊事件中，您仍可使用事件的時間戳記和裝置型號，彙整廣告客戶 ID TABLE-01 與 TABLE-02 中所含的 PII。

雖然您通常難以保證資料集中沒有這類準識別項，不過您可以盡可能將唯一資料的一般化，避免最明顯的彙整風險。在上述範例中，這意味著降低時間戳記的準確度，讓每個時間戳記顯示多個相同模型的裝置。

其他解決方案包括：

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

  • 針對具有廣告 ID 金鑰資料和 PII 存取權的使用者或角色，區隔及監控存取控制清單 (ACL)。 透過嚴格控管與稽核同時存取這兩個來源的權限 (例如執行資料表之間的彙整)，藉此降低廣告 ID 與 PII 之間的關聯風險。一般來說，控管存取權是指執行以下操作：

    1. 保留廣告客戶 ID 索引鍵資料和 PII 的存取控制清單 (ACL)，以盡可能減少兩個 ACL 中的個人或角色數量。
    2. 實作存取記錄和稽核功能，以偵測及管理這項規則的任何例外狀況。

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

使用 FID 和 GUID

如要識別裝置上執行的應用程式執行個體，最直接的方法就是使用 Firebase 安裝 ID (FID)。在大部分的非廣告用途中，我們都建議使用這個解決方案。只有已佈建該 ID 的應用程式執行個體才能存取這個 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 網路的 MAC 隨機化是每個 Passpoint 設定檔，並根據下列欄位產生不重複的 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 通訊端等較低層級的 API。舉例來說，如果應用程式需要目前路徑的最新資訊，可以使用 ConnectivityManager.registerNetworkCallback() 監聽網路變更，並呼叫網路相關聯的 LinkProperties.getRoutes()，以取得這項資訊。

ID 特性

Android 作業系統提供多個具有不同行為特性的 ID。您應該使用哪一種 ID，取決於下列特性如何與您的用途搭配使用。不過，這些特徵也會影響隱私權，因此請務必瞭解這些特徵的相對應方式。

範圍

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

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

授予 ID 的範圍越廣，用於追蹤的風險就越高。反之，如果只能由單一應用程式執行個體存取 ID，則無法針對不同應用程式中的交易追蹤裝置。

可重設與持續性

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

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

重設可讓使用者建立與任何現有設定檔資訊解除關聯的新 ID。越長且更可靠的 ID 仍然存在，例如在恢復原廠設定後，ID 仍然存在，就更有可能受到長期追蹤影響。如果 ID 會在應用程式重新安裝時重設，則就算沒有明確的使用者控制項，也無法在應用程式或系統設定內重設 ID，這種做法會降低 ID 的持續性，並提供重設 ID 的方式。

獨特性

唯一性會確立衝突的可能性，也就是相同的 ID 存在於相關範圍內。在最高層級，全域專屬 ID 絕不會發生衝突，即使是在其他裝置上或應用程式中亦然。否則，唯一性差異取決於 ID 的熵，以及用於建立 ID 的隨機來源。舉例來說，比起透過 Unix 時間戳記記錄種子的 ID (例如 1551414181)，在安裝日曆日期的隨機 ID 出現衝突時 (例如 2019-03-01) 也可能會發生衝突。

一般來說，使用者帳戶 ID 可以視為不重複。也就是每個裝置/帳戶組合都有專屬 ID。反過來說，ID 在母體內越不重複，隱私的保護就越多，因為追蹤個別使用者較不實用。

完整性防護與不可否認性

您可以使用難以假冒或重播的 ID，證明相關的裝置或帳戶具有特定屬性。舉例來說，您可以證明該裝置不是垃圾內容發布者使用的虛擬裝置。難以假冒的 ID 也提供了不可否認的機制。如果裝置使用密鑰簽署訊息，將很難認領其他人的裝置曾傳送訊息。不可否反應可能是使用者想要的，例如驗證付款時，也可能是不理想的屬性，例如傳送令人後悔的訊息。

常見用途和適用的 ID

本節提供使用 IMEI 等硬體 ID 的替代選項。我們不建議使用硬體 ID，因為使用者無法重設 ID，而且這類 ID 的範圍僅限於裝置。在許多情況下，以應用程式為範圍的 ID 即可派上用場。

帳戶

電信業者狀態

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

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

為什麼會顯示這項建議？

如果電信業者相關功能必須運用硬體 ID，則符合規定。例如，您可以使用這些 ID 切換行動電信業者或 SIM 卡插槽，或是透過 IP (適用於 Line1) - SIM 卡使用者帳戶收發簡訊。不過，針對沒有特殊權限的應用程式，我們建議使用帳戶登入，在伺服器端擷取使用者裝置資訊。這是因為在 Android 6.0 (API 級別 23) 以上版本中，這些 ID 只能透過執行階段權限使用。使用者可能會關閉這項權限，因此應用程式應該妥善處理這些例外狀況。

行動訂閱狀態

在此情況下，您必須將應用程式功能與裝置上的特定行動服務訂閱項目建立關聯。舉例來說，您可能必須根據裝置的行動訂閱項目透過 SIM 卡驗證存取權，才能驗證特定付費應用程式功能的存取權。

建議使用的 ID： Subscription ID API，用來識別裝置中使用的 SIM 卡。

訂閱 ID 提供索引值 (從 1 開始)，用於識別裝置上已安裝的已安裝 SIM 卡 (包括實體和電子)。應用程式可透過這個 ID，將自身功能與特定 SIM 卡的不同訂閱資訊建立關聯。除非裝置恢復原廠設定，否則指定 SIM 卡的值會保持不變。但在某些情況下，同一個 SIM 卡在不同裝置上可能會使用不同的訂閱 ID，或是不同裝置的 SIM 卡具有相同 ID。

為什麼會顯示這項建議？

有些應用程式目前可能會將 ICC ID 用於此目的。由於 ICC ID 具有全域唯一性，而且無法重設，因此自 Android 10 起，已有 READ_PRIVILEGED_PHONE_STATE 權限的應用程式受到限制。從 Android 11 開始，無論應用程式的目標 API 級別為何，Android 都會透過 getIccId() API 進一步限制 ICCID 存取權。受影響的應用程式應改用訂閱 ID。

單一登入

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

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

為什麼會顯示這項建議？

透過 Google 帳戶連結，使用者就能將使用者現有的 Google 帳戶與應用程式建立關聯，讓使用者以更快速安全的方式存取貴機構的產品和服務。此外，您也可以定義自訂 OAuth 範圍，僅分享必要資料，明確定義資料的使用方式，藉此提升使用者的信任感。

廣告

指定目標獎

在此情況下，您的應用程式會建立使用者興趣設定檔，藉此向他們顯示更相關的廣告。

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

為什麼會顯示這項建議？

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

無論您是否在應用程式中分享使用者資料，只要是基於廣告用途收集與使用資料，您都必須在 Play 管理中心的「應用程式內容」頁面的「資料安全性」專區中宣告廣告目的。

數據評估

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

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

為什麼會顯示這項建議？

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

轉換率

在這個例子中，您想要追蹤轉換來偵測自己的行銷策略是否成功。

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

為什麼會顯示這項建議？

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

再行銷

在此情況下，應用程式會根據使用者先前的興趣顯示廣告。

建議使用的 ID：廣告 ID

為什麼會顯示這項建議？

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

應用程式分析

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

  • 使用者可能適合貴機構的哪些其他產品或應用程式。
  • 如何吸引使用者持續使用您的應用程式。
  • 評估已登出或匿名使用者的使用統計資料和數據分析。

可能的解決方案包括：

  • 應用程式組 ID：您可以使用應用程式組 ID，針對貴機構擁有的多個應用程式分析使用者的行為，前提是不會將使用者資料用於廣告用途。如要指定 Google Play 服務支援的裝置，建議您使用應用程式組 ID。
  • Firebase ID (FID)：FID 的範圍僅限於建立該 FID 的應用程式，防止 ID 用於跨應用程式追蹤使用者。此外，由於使用者可以清除應用程式資料或重新安裝應用程式，因此也可以輕鬆重設。FID 的建立程序相當簡單；請參閱 Firebase 安裝指南。

應用程式開發

當機回報

在這種情況下，應用程式會收集使用者裝置當機的時間和原因相關資料。

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

為什麼會顯示這項建議？

FID 的範圍限定在建立該 FID 的應用程式，以防止 ID 用於跨應用程式追蹤使用者。此外，由於使用者可以清除應用程式資料或重新安裝應用程式，因此也可以輕鬆重設。FID 的建立程序相當簡單；請參閱 Firebase 安裝指南。應用程式組 ID 可讓您針對貴機構擁有的多個應用程式分析使用者的行為，前提是您不會將使用者資料用於廣告用途。

成效報表

在此情況下，您的應用程式會收集載入時間和電池用量等效能指標，協助改善應用程式品質。

建議使用的 ID： Firebase 效能監控

為什麼會顯示這項建議？

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

應用程式測試

在這種情況下，您的應用程式會評估使用者對應用程式的體驗，以便進行測試或偵錯。

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

為什麼會顯示這項建議？

FID 的範圍限定在建立該 FID 的應用程式，以防止 ID 用於跨應用程式追蹤使用者。此外，由於使用者可以清除應用程式資料或重新安裝應用程式，因此也可以輕鬆重設。FID 的建立程序相當簡單；請參閱 Firebase 安裝指南。應用程式組 ID 可讓您針對貴機構擁有的多個應用程式分析使用者的行為，前提是您不會將使用者資料用於廣告用途。

跨裝置安裝

在這種情況下，當相同的使用者將應用程式安裝在多部裝置上時，應用程式必須識別正確的應用程式執行個體。

建議使用的 ID：FID 或 GUID

為什麼會顯示這項建議？

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

安全性

濫用行為偵測

在這個案例中，您嘗試偵測多個假冒後端服務的假裝置。

建議使用的 ID：SafetyNet API

為什麼會顯示這項建議？

隔離的 ID 無法用來表示裝置正版。您可以使用 SafetyNet API 的 attest() 方法，驗證要求是否來自正版 Android 裝置，而不是假冒其他裝置的模擬器或其他程式碼。詳情請參閱 SafetyNet API 說明文件。

廣告詐欺

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

建議使用的 ID：廣告 ID

為什麼會顯示這項建議？

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

數位版權管理 (DRM)

在這個案例中，您的應用程式想防止有心人士透過詐欺手法存取智慧財產或付費內容。

建議使用的 ID：使用 FID 或 GUID 會強制使用者重新安裝應用程式以規避內容限制，這可充分減輕大多數使用者的負擔。如果不夠充分的防護，Android 提供 DRM API，可用來限制內容存取權，包括個別 APK 識別碼 (Widevine ID)。

使用者偏好設定

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

建議使用的 ID：FID 或 GUID

為什麼會顯示這項建議？

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