唯一 ID 的最佳做法

本文件提供指引,協助您根據用途選取應用程式適用的 ID。

如需一般 Android 權限的說明,請參閱「權限總覽」一文。如要瞭解使用 Android 權限的特定最佳做法,請參閱「應用程式權限最佳做法」。

使用 Android ID 的最佳做法

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

  1. 盡量選擇可由使用者重設的 ID。即使應用程式使用無法重設的硬體 ID 以外的 ID,應用程式還是可以達到大部分的用途。
  2. 避免使用硬體 ID。在大多數情況下,您可以避免在不限制必要功能的情況下使用硬體 ID,例如國際行動裝置識別碼 (IMEI)。

    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 建立放送廣告所需的設定檔,或針對使用者放送個人化廣告。允許使用的功能包括內容相關廣告、展示頻率上限、轉換追蹤、報表與安全性,以及詐騙偵測。"

對於與廣告 ID 使用行為相關的 SDK,請留意與 SDK 相關的任何隱私權或安全性政策。 舉例來說,如果您將 true 從 Google Analytics (分析) SDK 傳遞至 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 索引鍵資料保留存取控制清單 (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 網路的 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,而非 NetworkInterfacegetifaddrs() 或 Netlink 通訊端等較低層級的 API。舉例來說,如果應用程式需要最新的路徑資訊,可以使用 ConnectivityManager.registerNetworkCallback() 監聽網路變更,並呼叫與網路相關聯的 LinkProperties.getRoutes(),即可取得這項資訊。

ID 特性

Android 作業系統提供多個具有不同行為特性的 ID。您應使用何種 ID,取決於下列特性如何與您的用途搭配運作。然而,這些特性也會影響隱私權,因此請務必瞭解這些特性如何互動。

範圍

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

  • 單一應用程式:ID 僅供應用程式內部使用,可供其他應用程式存取。
  • 應用程式群組:一組預先定義的相關應用程式群組可存取這個 ID。
  • 裝置:裝置上安裝的所有應用程式都能存取這個 ID。

ID 授予的範圍越廣,就越容易用於追蹤。反之,如果 ID 只能由單一應用程式執行個體存取,就無法用於追蹤不同應用程式中各項交易的裝置。

可重設與持續性

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

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

可重設功能可讓使用者建立新的 ID,且該 ID 會與任何現有個人資料資訊解除關聯。ID 的時間較長且更可靠 (例如在恢復原廠設定後保留的 ID),使用者越容易受到長期追蹤影響。如果在重新安裝應用程式時重設 ID,即便使用者未在應用程式或「系統設定」中明確控管重設 ID,ID 依然可以減少持續性,並提供重設 ID 的方法。

獨特性

獨特性會定義衝突的可能性,也就是說,相同的 ID 存在於相關聯的範圍內。整體來看,全域專屬 ID 絕不會發生衝突,即使是其他裝置或應用程式也一樣。否則,不重複程度取決於 ID 的熵,以及用來建立 ID 的隨機性來源。例如,與安裝日曆日期時出現的隨機 ID (例如 2019-03-01) 發生衝突的機率遠高於安裝包含 Unix 時間戳記 (例如 1551414181) 的 ID。

一般來說,使用者帳戶 ID 可視為不重複。也就是說,每個裝置/帳戶組合都有一個專屬 ID。另一方面,如果不重複 ID 在人口中越少,就能保護隱私,因為追蹤個別使用者的實用性就會提升。

完整性防護與非全面性

您可以使用不易假冒或重播的 ID,證明相關裝置或帳戶具有特定屬性。舉例來說,您可以證明裝置並非垃圾內容發布者使用的虛擬裝置。難以假冒的 ID 也提供非純粹的辨識能力。如果裝置使用密鑰簽署訊息,則很難聲稱其他人的裝置傳送了這則訊息。非精準性可以是使用者想要的東西,例如在驗證付款時,也可能是不想要的屬性,例如使用者傳送後悔莫及的訊息。

常見用途和合適 ID

本節提供使用硬體 ID 的替代做法,例如 IMEI。我們不建議使用硬體 ID,因為使用者無法重設這些 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 卡 (包括實體和電子) 的身分。透過這個 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,因為使用者可以重設廣告 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 在所有機構組織的其他應用程式中使用,因此使用廣告 ID 是最適合的解決方案。根據《Google Play 開發人員內容政策》的規定,廣告用途必須強制使用廣告 ID,因為使用者可以重設廣告 ID。

應用程式分析

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

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

可能的解決方案包括:

  • 應用程式組 ID:應用程式組 ID 可讓您分析貴機構擁有多個應用程式中的使用者行為,前提是不得基於廣告目的使用使用者資料。如果您指定的裝置採用 Google Play 服務,建議使用應用程式組 ID。
  • Firebase ID (FID):FID 的範圍限定在建立該應用程式的應用程式,因此使用者無法使用 ID 跨應用程式追蹤使用者。也很容易重設,因為使用者可以清除應用程式資料或重新安裝應用程式。建立 FID 的程序相當簡單。請參閱 Firebase 安裝指南。

應用程式開發

當機回報

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

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

為什麼會顯示這項建議?

FID 的範圍限於建立 FID 的應用程式,避免 ID 被用於跨應用程式追蹤使用者。這也很容易重設,因為使用者可以清除應用程式資料或重新安裝應用程式。建立 FID 的程序相當簡單。請參閱 Firebase 安裝指南。應用程式組 ID 可讓您分析貴機構擁有多個應用程式中的使用者行為,前提是不得基於廣告目的使用使用者資料。

成效報表

在這種情況下,您的應用程式會收集載入時間和電池用量等成效指標,以改善應用程式的品質。

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

為什麼會顯示這項建議?

Firebase 效能監控可協助您著重於對您而言最重要的指標,並測試最近在應用程式中變更的影響。

應用程式測試

在此情況下,應用程式會評估使用者體驗,以便進行測試或偵錯。

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

為什麼會顯示這項建議?

FID 的範圍限於建立 FID 的應用程式,避免 ID 被用於跨應用程式追蹤使用者。這也很容易重設,因為使用者可以清除應用程式資料或重新安裝應用程式。建立 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

為什麼會顯示這項建議?

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