TC
裝置識別碼是一個協助系統區分不同裝置、應用程式安裝個體，或是裝置與應用程式組合的數值。你可能也會看到諸如裝置ID或唯一裝置識別碼這類術語，但這些術語並非永遠指涉相同事物。
有些裝置識別碼屬於實體裝置，手機的IMEI（國際行動裝置識別碼）就是一例。其他識別碼則僅屬於單一應用程式或一群應用程式。例如Android支援Firebase安裝ID與App Set ID這類識別碼；Apple也提供供應商識別碼（IDFV），可用於識別同一供應商旗下多款應用程式所對應的裝置。
這種差異十分重要。裝置識別碼並非永遠是內建於手機的永久編號。現代系統常使用具有限定範圍的識別碼，因為這能為使用者帶來更多隱私保障。Google現建議，對於大多數一般應用程式功能，應使用可重置或應用程式層級的識別碼，而非IMEI這類硬體識別碼。
常見的錯誤觀念是認為每個裝置識別碼都儲存了裝置的完整詳細資訊，但多數情況下並非如此。
有些識別碼僅僅是看似隨機的字串，它們的主要作用是區分不同的應用程式執行個體或裝置。例如，Android 的 App Set ID 採用 UUID 格式。這個編號本身不需要包含你的姓名、電話號碼或位置就能發揮作用，應用程式可以將此 ID 儲存在資料庫中，用來辨識同一裝置上正在使用同一組應用程式。
硬體識別碼的運作方式則有所不同。IMEI 是供行動網路裝置使用的 15 位數識別碼。根據 GSMA 的規範，它包含三個主要部分：型號配置碼（Type Allocation Code）、序號以及檢查碼。型號配置碼可以連結到裝置製造商與型號的相關資訊。
因此，裝置 ID 所對應的資訊取決於識別碼的類型。
舉例來說，假設兩個人安裝了同一個購物應用程式，該應用程式可能會為每一份應用程式複本建立不同的安裝 ID。這個 ID 本身可能看起來像是隨機字串，但企業的伺服器可以將該 ID 與應用程式設定、當機回報或應用程式內的活動等資料關聯起來。這類識別碼的意義往往來自與其關聯的資料，而非識別碼本身的字元內容。
這也是為什麼將裝置識別碼與瀏覽器指紋分開會很有用的原因。一般網站不需要存取手機的IMEI就能辨識瀏覽器，反而會觀察瀏覽器版本、時區、語言、字型、螢幕尺寸及其他瀏覽器設定這類訊號；當這些訊號結合起來，就能形成瀏覽器指紋。
應用程式會使用裝置識別碼，因為它們經常需要確認兩個請求是否來自同一個應用程式安裝個體或裝置，這能支援實用功能，無需使用者每次都登入。
分析就是一例。應用程式開發者可能想了解有多少使用者在安裝後會再度開啟應用程式。Google表示，App Set ID可用於非廣告用途，例如同一開發者旗下跨應用程式的分析與詐騙防護。
安全性是另一個常見用途。線上服務可能需要偵測異常活動、偽裝安裝或重複濫用行為。針對部分濫用偵測任務，Android建議使用像Play Integrity這類重視隱私的工具，而非依賴永久硬體識別碼。
廣告有其專屬的裝置識別碼（Device ID）。Android 提供可讓使用者重設或刪除的廣告識別碼，Apple 則提供稱為 IDFA 的廣告識別碼。在 iOS 14.5 及後續版本中，應用程式必須取得追蹤權限，才能存取可用的廣告識別碼。這類識別碼可用於支援廣告衡量、歸因分析、曝光次數上限管控與詐欺偵測等任務。
舉例來說，假設你在行動遊戲中多次看到同一支廣告，廣告識別碼可協助廣告系統瞭解這些曝光來自同一裝置，進而協助系統限制同一廣告的出現頻率，或是衡量該廣告是否帶來安裝或轉換購買的行為。
網站的運作模式稍有不同。網站通常依賴 Cookie、帳戶資料、IP 資訊與瀏覽器訊號，而非硬體裝置識別碼。瀏覽器指紋辨識可結合螢幕解析度、語言、時區、瀏覽器版本與已安裝字型等細節，協助區分不同的瀏覽器設定檔。
當談論隱私議題時，這種區別就變得相當重要。說網站「知道你的裝置識別碼」可能會造成誤導。在許多情況下，網站根本不會持有傳統的硬體識別碼，它可能只是擁有足夠的瀏覽器與工作階段訊號，能夠辨識出同一個瀏覽器設定檔回訪了。
並非所有裝置識別碼的運作方式都相同。有些用來識別實體硬體，有些用來識別應用程式安裝版本，還有些主要是為了廣告或分析用途而存在。
這就是為什麼裝置識別碼（Device ID）這個術語容易造成混淆的原因。兩款應用程式可能都聲稱使用裝置識別碼，但它們所指的可能是截然不同的識別碼：一款也許使用廣告識別碼，另一款則可能建立自己專屬於該應用程式的識別碼。
了解這些差異，有助於你理解應用程式或網站實際上能取得哪些資訊。
IMEI，也就是國際行動裝置識別碼，是用於連接行動網路之裝置的識別碼，它與蜂巢式設備綁定，而非與單一應用程式綁定。
舉例來說，行動電信業者可能會使用 IMEI 在其網路上識別手機。如果某支手機被通報遺失，IMEI 也可做為封鎖該裝置連接支援之行動網路系統的一部分。
應用程式在日常作業中通常不需要 IMEI。事實上，現代 Android 版本嚴格限制對 IMEI、裝序號這類硬體識別碼的存取權限。Google 建議開發人員盡可能使用限制更多、可重設的識別碼。
MAC 位址則有所不同。當裝置在網路上進行通訊時，它會用來識別網路介面，例如 Wi-Fi 硬體。
數年前，MAC 位址很容易被應用程式與網路做為穩定識別碼使用，但情況已有所改變。現代作業系統針對其加入了隱私保護機制。Android 限制第三方應用程式存取裝置的真實 MAC 位址，同時也支援 Wi-Fi 連線的 MAC 位址隨機化功能。
想像一下你將手機連上飯店的 Wi-Fi，該網路並非總是需要看見手機的永久硬體 MAC 位址，此時可以改用隨機產生的位址。這讓他人難以透過同一個硬體位址，在不同網路間追蹤該裝置。
接下來是通用術語裝置識別碼。
並沒有一個適用於所有手機、應用程式或作業系統的通用裝置識別碼。在某項服務中，裝置識別碼可能指應用程式產生的通用唯一識別碼（UUID）；在另一項服務中，它可能指作業系統提供的識別碼。
當你在應用程式的隱私權政策中看到「裝置識別碼」時，這是一個重要細節。僅靠這個術語無法得知該公司收集的是什麼資料。
例如，Android 針對許多非廣告場景建議使用 Firebase 安裝識別碼（FID）。FID 用來識別特定的應用程式安裝個體，相較於使用永久硬體識別碼，其應用範圍受限許多。如果應用程式被移除後重新安裝，這個識別碼就會改變。
因此，IMEI、MAC 位址與應用程式層級的裝置識別碼不應被視為同一事物的三種名稱，它們分別識別裝置或應用程式環境的不同部分。
廣告識別碼是為更特定的用途設計的，協助應用程式與廣告系統衡量及管理廣告活動。
在 Android 系統中，廣告識別碼是一種可供使用者重設的識別碼，專供廣告用途使用。Google 要求開發人員尊重使用者重設此識別碼的選擇，未經使用者同意，開發人員不得暗中將新的廣告識別碼與舊的綁定。
Apple 也有類似的識別碼，稱為 IDFA，也就是廣告主識別碼（Identifier for Advertisers）。
在 iOS 和 iPadOS 14.5 或更新版本中，應用程式必須先請求追蹤權限，才能取得可用的廣告識別碼。若未取得權限，傳回給應用程式的廣告識別碼會是一串零，而非可用的唯一識別碼。
行動廣告衡量就是一個簡單的例子。
假設你在某個應用程式裡看到一款遊戲的廣告，之後安裝了該遊戲。在允許的情況下，廣告系統可透過廣告識別碼協助衡量這則廣告是否促成了安裝行為。廣告識別碼還可支援頻率限制、轉換衡量與詐欺偵測功能。
但並非每個應用程式都需要進行廣告追蹤。
對於一般應用程式功能，開發人員可以使用範圍較小的識別碼。例如，Android 提供應用程式集合識別碼（App Set ID），供開發人員用於旗下多款應用程式的分析與詐騙防禦等用途。Google 也建議，在許多僅需識別單一應用程式安裝個體的案例中，使用 Firebase 安裝識別碼。
Apple 則提供廠商識別碼（identifierForVendor），常簡稱為 IDFV。同一裝置上，同一廠商的應用程式會收到相同的 IDFV，而其他廠商的應用程式則會收到不同的值。
我們可以這樣理解：氣象應用程式不需要你的手機永久硬體識別碼，就能記住應用程式的安裝個體。一個有限制的、專屬於應用程式的裝置識別碼通常就能完成任務，且帶來較低的隱私風險。
這就是為什麼現代平台逐漸不再讓一般應用程式輕易存取永久硬體識別碼的原因之一。
裝置識別碼與瀏覽器指紋都可用於識別裝置或使用者環境，但兩者的運作方式截然不同。
裝置識別碼通常是一個特定值，可能是 IMEI、廣告識別碼、應用程式集合識別碼、IDFV，或是其他獨特字串。
瀏覽器指紋通常並非單一儲存的識別碼。
相對地，網站會蒐集數項瀏覽器與系統訊號並加以組合。這些訊號可能包含：
這些細節結合起來，就能讓不同瀏覽器的設定檔彼此區分。MDN將瀏覽器指紋技術定義為蒐集並組合這些特徵，用以識別瀏覽器並潛在追蹤使用者的程序。
舉例來說，假設你用筆電造訪某個網站，該網站通常無法向你的瀏覽器索取手機的IMEI，但它仍可偵測到你使用的特定瀏覽器版本、螢幕解析度、語言、時區與作業系統。
單一訊號能提供給網站的資訊相當有限，但多項訊號組合起來就會具備高度獨特性。
這也解釋了為什麼刪除Cookie並不總能讓瀏覽器看起來完全像新的一樣。Cookie僅是資訊來源之一，即使刪除Cookie，網站仍可接收許多相同的瀏覽器訊號。
兩者的核心差異很簡單：傳統的裝置識別碼會提供服務一個明確的識別標籤，而瀏覽器指紋則是透過眾多數據點建立一個可辨識的模式。
當使用多個帳號或瀏覽器設定檔時，這項差異就變得格外重要。即使帳號使用各自獨立的Cookie，相似或前後不一的瀏覽器訊號仍可能讓網站得知這些帳號背後的環境資訊。這就是為什麼瀏覽器層級的識別需要與硬體及基於應用程式的裝置識別碼分開考量。
既然你已經了解裝置識別碼的主要類型，接下來常見的問題很簡單：要去哪裡查詢自己的裝置識別碼？
答案取決於你需要的是哪一種識別碼。並沒有一個能同時適用於Android、iPhone、Windows與macOS的通用裝置識別碼。客服人員可能會要求你提供IMEI，軟體服務可能會要求Windows裝置識別碼，而有些應用程式則會使用你在手機設定中根本看不到的內部識別碼。
因此在複製編號之前，務必先確認服務要求的確切裝置識別碼類型。
在 Android 手機上，IMEI 是最容易查詢的硬體識別碼之一。在許多裝置上，你可以開啟設定 > 關於手機並尋找 IMEI。Google 也支援使用者透過尋找中心（Find Hub）查看相容裝置的 IMEI。部分裝置，例如僅支援 Wi-Fi 的平板電腦，因為不需要連接行動網路，可能沒有 IMEI。
舉例來說，假設你的手機遺失，你聯絡行動電信業者，業者可能會要求你提供 IMEI 來識別該行動裝置。這種情況下，廣告識別碼或應用程式安裝識別碼毫無用處，因為它們的用途各不相同。
在 iPhone 上查詢的流程也很簡單，請前往：
設定 > 一般 > 關於本機
Apple 會在這個頁面列出序號、EID、IMEI 或 MEID、ICCID，以及 Wi-Fi 和藍牙位址等資訊。你可以長按這些編號來複製內容。
同樣地，正確的編號取決於你的需求。
如果 Apple 支援團隊要求你提供序號，別想當然地提供 IMEI；如果行動電信業者要求你提供 IMEI，序號可能並非他們需要的資訊。
還有一項重要限制必須記住：部分應用程式使用的裝置識別碼不會顯示在「關於」畫面中。
例如，Android 應用程式可能會使用 Firebase 安裝識別碼，另一款應用程式可能會使用 App Set 識別碼，iPhone 應用程式則可能會使用 Apple 的 identifierForVendor（供應商識別碼）。這類識別碼是針對特定軟體使用情境建立或提供的，並非設計成使用者從手機背面讀取的序號那樣運作。
因此，如果某款應用程式的隱私權聲明提到它會蒐集「裝置識別碼」，並不代表它一定在蒐集你的 IMEI（國際行動裝置識別碼）。
桌上型電腦同樣具備數種識別碼，至於哪一種重要，取決於軟體的需求。
在 Windows 11 中，請從以下路徑開始：
設定 > 系統 > 關於
此頁面會顯示電腦的重要資訊，「裝置規格」區域包含裝置名稱、處理器、記憶體（RAM）、系統類型以及裝置識別碼等細節。微軟持續更新 Windows 11 的「關於」頁面，讓使用者更容易找到裝置資訊。
Windows 也會針對網路卡、顯示卡、USB 硬體等個別零組件使用低階硬體識別碼，這些與「關於」主頁面顯示的裝置識別碼不同。
如果您需要這類硬體識別碼，請開啟裝置管理員，選擇對應裝置，開啟內容，並查看詳細資料頁籤。微軟說明，Windows硬體識別碼可協助作業系統為硬體配對正確的驅動程式。
這種區別在實際應用中十分重要。
假設某軟體公司在啟動程式時要求您提供「PC裝置識別碼」，這可能指的是Windows設定中顯示的裝置識別碼。但如果您正在進行Wi-Fi驅動程式除錯，技術支援團隊實際上可能需要的是網路介面卡的硬體識別碼。這兩者無法互換使用。
在Mac上，大多數使用者最容易找到的識別碼是序號。
請執行以下操作：
Apple選單＞關於這台Mac
序號會與Mac的基本資訊一同顯示。您也可以前往系統設定＞一般＞關於。若要取得更詳細的硬體與網路資訊，請點選系統報告。
這些例子說明為何「尋找我的裝置識別碼」本身可能是一個容易誤導人的搜尋關鍵字。您必須先確認自己需要的是IMEI、序號、Windows裝置識別碼、硬體識別碼、廣告識別碼，還是其他應用程式專用的數值，再針對該特定識別碼進行搜尋。
A 裝置識別碼可用於追蹤的一部分，但答案並非「單一識別碼到處追蹤你」這麼簡單。
有些識別碼的用途很狹隘，有些可以重置，有些僅限於單一應用程式或開發者使用，其他則是一般應用程式難以存取的。
真正的隱私風險取決於識別碼的有效期長短、可存取對象，以及與其關聯的其他資料內容。
當同一個識別碼重複出現，且服務將活動與其關聯時，追蹤就成為可能。
舉個簡單的例子說明。
你在星期一開啟某個應用程式，該應用程式記錄的識別碼為A123。你在星期五再次開啟它，應用程式又偵測到A123。即使你沒有登入，該應用程式仍可判定這兩次使用來自同一個應用程式安裝或裝置環境。
這並不代表識別碼本身儲存了你的瀏覽記錄，而是服務透過將活動與同一個識別碼關聯來建立記錄。
這就是為何長效識別碼會帶來更多隱私疑慮的原因之一。Google 指出，識別碼的存活時間越長，長期追蹤的風險就越高。因此 Android 建議在大多數常見使用情境中，使用可重置或應用程式範圍的識別碼，而非永久硬體識別碼。
廣告識別碼就是一個明確的例子。
廣告系統可能會使用識別碼來衡量同一裝置是否看過廣告、安裝過應用程式，或是完成其他動作。Android 的廣告識別碼設計為可重置，且 Google 要求開發人員尊重使用者重置識別碼的決定，不得未經使用者同意就暗中將新識別碼與舊識別碼關聯。
Apple 也限制其廣告識別碼 IDFA 的存取權限。在當前版本的 iOS 中，應用程式必須取得追蹤權限，才能存取可用的廣告識別碼。若權限被拒絕，傳回給應用程式的識別碼將全為零。使用者可透過設定＞隱私權與安全性＞追蹤檢視或變更追蹤權限。
這並不代表當某個裝置識別碼無法使用時，所有追蹤行為都會消失。
企業可能仍持有您主動提供的資訊，例如帳號登入資訊。網站也可能使用 Cookie 或瀏覽器指紋技術。這就是為什麼僅從單一識別碼無法完整理解隱私議題的原因。
裝置識別碼通常並非密碼。一般來說，他人無法透過 IMEI 或廣告識別碼解鎖您的手機。
儘管如此，當識別碼與其他資訊結合時，就可能涉及隱私敏感議題。
假設某分析系統將同一個識別碼與數百項應用程式事件儲存在一起，長時間下來，該系統可能會將此識別碼與應用程式開啟時間、使用過的功能或瀏覽過的廣告建立關聯。
再設想同一個識別碼同時連結到某個帳號或其他已知資料點，此時識別碼會變得更具利用價值，因為有更多資訊與其綁定。
這就是現代作業系統試圖限制長期穩定識別碼存取權限的原因。
Android 限制一般應用程式存取不可重設的識別碼，例如 IMEI 與序號。Google 針對許多常見的應用程式功能，建議使用更具限制性的替代方案，例如 Firebase 安裝識別碼。
Apple 在跨應用程式追蹤上採取類似的「隱私優先」作法。應用程式若要為廣告或相關目的，在其他公司的應用程式與網站間追蹤使用者，必須先取得許可。如果使用者選擇要求 App 不要追蹤，開發者就無法存取系統廣告識別碼來進行該項追蹤作業。
實務上的啟示並非每個裝置識別碼都有風險，更重要的問題是「哪些資訊會與它連結」。
舉例來說，將 iPhone 序號提供給 Apple 支援服務進行維修，與允許同一個持續性識別碼在不相關的應用程式間用於行為追蹤，兩者有很大的差異。
裝置識別碼可用來區分不同的實體裝置，但當你瀏覽網頁時，網站並不總是依賴單一裝置識別碼。它們也會透過瀏覽器指紋、Cookie、登入工作階段、IP 位址及其他訊號，來辨識帳號背後的環境。
這就是 DICloak 發揮作用的場合。
DICloak 不會更改諸如 IMEI、序號這類硬體識別碼，反而協助建立並維護不同帳號的獨立瀏覽器身分。每個帳號都能使用屬於自己的瀏覽器設定檔，具備隔離的指紋、Cookie、工作階段與網路設定。
當多個帳號從同一個瀏覽器設定檔開啟時，它們可能會共用許多相同的瀏覽器層級訊號。
DICloak 透過為每個帳號提供專屬的瀏覽器設定檔，協助隔離這些環境。
一個設定檔可包含專屬的 Cookie、登入工作階段、代理伺服器設定、瀏覽器設定與指紋設定。指紋設定可包含作業系統、使用者代理程式（User Agent）、WebRTC、畫面或視窗大小、Canvas、WebGL、語言、時區及其他瀏覽器特性等訊號。
舉例來說，假設一間行銷代理公司為多位客戶管理社群媒體與電子商務帳號。
團隊不必將所有帳號都開啟在同一個 Chrome 設定檔中，而是可以像這樣整理：
客戶 A → DICloak 設定檔 A 客戶 B → DICloak 設定檔 B 客戶 C → DICloak 設定檔 C
用戶端 A 所使用的 Cookie 與瀏覽器設定檔會保留在設定檔 A 當中，不會與用戶端 B 的工作階段資料混合。
這不會建立新的硬體裝置 ID，反而會為每個帳戶建立一個區分更明確的瀏覽器層級身分。
保護瀏覽器身分不僅僅是讓各個設定檔有所不同，一致性也同樣重要。
網站可隨時間比對多種訊號。如果某個帳戶突然出現與過去差異極大的瀏覽器指紋、IP位址、時區或瀏覽器設定，該環境可能會被視為異常。
DICloak 可讓您儲存每個設定檔的瀏覽器指紋與網路設定，並在未來的工作階段中重複使用該設定檔。
您也可以將 Proxy 指派給特定設定檔。這代表帳戶 A 可持續使用設定檔 A 及其現有的瀏覽器設定、Cookie 與網路設定，無須每次開啟都建立一個全新的環境。
對於基於瀏覽器的帳戶管理而言，這通常比嘗試變更實體裝置識別碼更實用。
當多人使用相同帳號時，瀏覽器身分識別的管理難度會提升。
團隊成員可能使用不同電腦，有人可能用不同的瀏覽器設定開啟帳號，還有人可能用錯代理伺服器或開啟全新工作階段。
DICloak 讓團隊可以共用瀏覽器設定檔，不用在每台裝置上重新建置相同的帳號環境。
共用設定檔可保留與帳號相關的瀏覽器設定、指紋設定、代理資訊，以及儲存的工作階段資料。團隊還能將設定檔分組，並管控哪些成員可以存取這些設定檔。
舉例來說，行銷代理商可以針對美國社群媒體帳號建立一個設定檔群組，再針對電子商務帳號建立另一個群組。團隊成員僅能存取其工作所需的設定檔。
重點在於，DICloak 不會取代或修改傳統裝置識別碼，其作用層級僅限於瀏覽器。透過分離瀏覽器指紋、Cookie、工作階段、代理伺服器與其他身分識別訊號，DICloak 協助不同帳號維持獨特且更一致的線上身分。
裝置識別碼是用來辨識裝置、應用程式安裝或「裝置與應用程式組合」的數值。常見範例包括IMEI、廣告識別碼、App Set ID以及應用程式專屬裝置識別碼。不同的識別碼用途不同，因此並無適用於所有裝置或應用程式的單一裝置識別碼。
尋找裝置識別碼的方式取決於你需要的類型。在Android與iPhone裝置上，通常可在裝置設定中找到IMEI、序號這類識別碼；在Windows與macOS系統中，系統設定也會顯示裝置或硬體資訊。至於應用程式專屬識別碼，使用者可能無法看見。
是的，當同一組識別碼出現在多個工作階段時，裝置識別碼可做為追蹤機制的一部分。服務供應商可能會將使用者的活動、應用程式事件或廣告數據與該識別碼關聯。不過，現許多新式識別碼具可重置性，或僅限單一應用程式/開發者使用，以減少長期追蹤的可能性。
部分類型的裝置識別碼可重設或替換，其他則不行。廣告識別碼與部分應用程式專屬識別碼設計為可變更或重設。諸如IMEI或序號這類硬體識別碼則不同，無法像廣告識別碼一樣變更。
透過標準瀏覽器，網站通常無法存取手機IMEI這類硬體裝置識別碼。相對地，它們可能會使用Cookie、IP位址，以及瀏覽器指紋訊號，例如作業系統、語言、時區、螢幕尺寸與瀏覽器設定。這就是瀏覽器指紋不同於傳統裝置識別碼的原因。
