數位指紋採集是指嘗試在使用者回訪網站時識別使用者身分，或是在不同網站上識別同一個使用者。 您的設定和其他使用者的特性可能有所不同。舉例來說，您可能使用的是不同類型的裝置和瀏覽器，但螢幕大小不同，且安裝了不同的字型。如果我安裝了「Dejavu Sans」的字型，但並未對，任何網站只要檢查該字型，就能分辨您與我有差別。這就是指紋擷取的運作方式；您可以建立這些資料點的集合，並利用更多方式來區分使用者。
更正式的定義看起來像這樣：指紋是指在使用者設定中，使用顯而易見的非隱形特性，盡可能將使用者與更多使用者區隔開來。
數位指紋採集會危害使用者隱私的原因
在少數情況下，數位指紋採集十分重要：例如詐欺偵測。但數位指紋採集也可用於跨網站追蹤使用者，且追蹤通常是在未經使用者同意的情況下進行，或者在某些情況下，其追蹤依據為無效同意聲明，未充分告知使用者。完成工作後，這些使用者通常會感到不自在，且感覺不太舒服。
數位指紋採集是指找出如何隱密區分個別使用者的方式。指紋識別功能可辨識到同一網站上的使用者是否仍為同一名使用者，或同時在兩個不同的瀏覽器設定檔中辨識同一位使用者。因此，數位指紋採集可用於跨網站追蹤使用者。確定確定性和覆寫的追蹤方法 (例如儲存具有專屬使用者專屬 ID 的 Cookie) 可能在一定程度上受到使用者觀察，並且受到使用者控制 (而且先前的單元也說明過這些方法)。但數位指紋採集較為隱密，因此難以避免，因為數位指紋採集的特性，且最有可能發生在無意間。這就是所謂的「指紋列印」無論是數位指紋，還是手指末端的指紋，變更指紋是最不容易的做法。
瀏覽器供應商知道使用者不喜歡追蹤，並且會持續實作可限制數位指紋採集的功能 (我們在前一單元中介紹了其中一些功能)。以下將探討這些功能如何影響您的業務需求，以及如何以隱私保護方式做到這一點。重點在於瞭解瀏覽器保護措施的「禁止」指紋識別功能對您的動作和方式有何影響，而非影響「執行」數位指紋採集的方式。
實務上，大多數開發人員和大多數企業都不需要建立指紋使用者。如果您的應用程式會要求使用者登入，則使用者是在取得使用者同意的情況下向您的身分錶明身分，且讓使用者隨時都能自行選擇退出。透過這個隱私保護方法辨識登入的使用者。應用程式可能不會要求使用者登入，進而進一步保護使用者隱私 (而您將只收集需要的資料)。
正確做法
評估第三方的數位指紋採集。「第三方」模組可能已提供您所納入任何第三方服務的清單，以及這類服務發出的網路要求。您可以檢查這些要求，看看哪些資料正在傳回來源器 (如果有的話)。不過，這通常很難；指紋的本質就是隱密程序，而這包括要求不必經過使用者核准的資料。
建議您一併參閱第三方服務和依附元件的隱私權政策，瞭解使用指紋採集的跡象。有時稱為「機率比對」，或包含在機率比對技術套件中，而非「確定性比對」。
數位指紋採集的運作方式
一般而言，所有這些屬性的個人組合都獨一無二，或至少與一小群相似使用者的個人組合；這可以用來隱含追蹤您的活動。
並行：被動式和主動數位指紋採集
這裡有一項實用的區別，在於被動和主動的指紋採集技術。被動數位指紋採集技術會使用預設的網站資訊，而主動的指紋識別技術則是明確針對瀏覽器攔截額外資訊。這項差異的重要性在於瀏覽器可嘗試偵測、攔截或緩解使用中的技術，API 可能會受到限制，或是閘道顯示在要求使用者權限的對話方塊後方 (進而通知使用者使用者正在使用該 API，或預設允許使用者拒絕 API)。被動式技術會使用已提供給網站的資料，通常是因為在資訊一流的新興時期，該資訊會提供給所有網站。使用者代理程式字串就是這類字串的範例，我們會進一步說明只要提供大量有關使用者瀏覽器、版本和作業系統的資訊，網站就能根據這些資料選擇呈現不同的內容。然而，這也會導致可用的區別資訊量增加，這類資訊有助於識別使用者身分。此類資訊已無法再使用，或至少有凍結來使其無法辨別。如果您需要執行這些資訊的操作 (例如，根據使用者代理程式選擇不同的程式碼分支)，這段程式碼可能會隨著瀏覽器不斷凍結或停止該資訊的情形。測試是最佳的防禦措施 ( 請見稍後說明)。
題材：評估指紋可用性
這些資料點提供多少資訊的技術測量指標稱為「熵」，以位元為單位。如果功能有許多不同的可能值 (例如已安裝的字型清單)，對總計而言可能帶來大量位元，因此，如果沒有太多明顯的力量 (例如，您正在使用哪個作業系統)，則可能僅會增加一些位元。HTTP Almanac 說明現有的數位指紋採集程式庫如何將此程序自動化，將許多不同 API 的回應合併成「雜湊」，而這可能只會識別一小群使用者，甚至可能只有一位使用者。Maud Nalpas 於這部 YouTube 影片中深入探討這個主題。但簡單來說，假設您看到了朋友名單，當中包括他們最愛的音樂、喜愛的食物和使用的語言，但他們的姓名已經移除。每個人的名單可能都會明確在朋友中識別，或者至少將清單範圍縮小為一些人。這就是數位指紋採集的運作方式；你想使用的功能清單成為「雜湊」。只要使用雜湊值，就能在兩個不同的未連結網站上，輕鬆識別同一位使用者，成為追蹤的目標：規避使用者對隱私權的期望。
瀏覽器如何利用數位指紋採集？
重要的是，瀏覽器供應商都知道許多網站 (或網站上包含第三方) 計算使用者辨識指紋的方法，或為了計算指紋的獨特資訊，而提供不同的資訊。其中有些是明確且刻意謹慎的方法，例如瀏覽器的使用者代理程式字串，這些字串通常能識別使用的瀏覽器、作業系統和版本 (所以如果同時使用不同瀏覽器，有助於區別您和我)。其中有些方法並非刻意建立可指紋指紋，而是如此，例如字型清單，或是瀏覽器可用的影片和音訊裝置。(瀏覽器不需要「使用」這些裝置，只要取得裝置名稱的清單即可)。有些則在發布後便成為指紋的貢獻者，例如畫布元素上各種字型的消除效果確切像素轉譯。除此之外，瀏覽器與礦物的差異時，每種方法都會增加熵。因此，只要能在網站上識別你和我，並盡可能明確識別每個人。https://amiunique.org 就有長篇 (但不是非常全面) 的潛在指紋辨識功能清單，就算不是使用者想要的指紋，也不會因為指紋採集而增加。
不支援某些功能強大的 API
瀏覽器供應商對所有計算使用者指紋的方法的回應，是設法減少這些 API 中可用的熵。最嚴格的選項是不要一開始就實作。許多主要瀏覽器都是針對各種硬體和裝置 API (例如透過用戶端網頁應用程式的 NFC 和藍牙存取) 提供這項功能，並為未實作的原因引用指紋和隱私權疑慮。這很顯然可能會影響您的應用程式和服務：您無法在未實作 API 的瀏覽器中完全使用 API，而且這可能會限製或完全切斷某些硬體做法，不予考慮。
使用者權限閘道
瀏覽器廠商採取的第二種做法，是防止在未取得使用者明確授權的情況下，防止 API 或資料存取活動。 這種做法通常是基於安全考量。未經您的許可，網站不得使用網路攝影機拍照！不過，隱私權與安全性可能會有類似興趣。當然，辨識某人的位置本身就是違反隱私權的行為，但同時也導致指紋辨識的重複性構成。要求取得地理位置權限並不會導致位置增加而增加指紋的獨佔性，但基本上可以排除「使用」地理位置進行數位指紋採集，因為系統已無意識地執行這項動作。指紋印記的重點在於「以隱密方式」區分使用者。如果已準備好讓使用者知道要識別對方身分，則不需要數位指紋採集技術：請使用者建立帳戶並登入帳戶。
新增不可預測性
而在某些情況下，採取的第三個做法是瀏覽器廠商對 API 的回應「模糊化」，以降低 API 回應的精細程度，進而降低識別度。相關說明屬於資料模組的隨機回應機制中，您可以在向使用者收集資料時利用這些機制，避免不小心收集到識別身分的資料。瀏覽器廠商也可透過這個方法，存取提供給網頁應用程式和第三方的 API 資料。舉例來說，window.performance.now() 用於評估網頁效能的 API 時間非常準確。瀏覽器知道這些值可達到微秒準確度，但傳回的值會四捨五入至最接近的 20 微秒邊界，大幅降低精確度，以避免其在數位指紋採集中使用 (同時是為了安全性避免時間攻擊)。這個步驟的目標是確保 API 保持實用，但為了確保回應較不容易辨識：基本上，為了讓您的裝置看起來更像其他所有人的裝置，而不是使用者的需求，因此有助於提供「裝置免疫系統」。出於上述原因，Safari 提供了簡化版本的系統設定。
實行隱私預算規定
隱私預算是一項建議，可建議瀏覽器預估每個數位指紋採集介面顯示的資訊。瀏覽器尚未提供這項功能。目標是允許使用功能強大的 API，同時維護使用者隱私。進一步瞭解隱私預算提案。
使用廣泛的測試環境
這些因素都會影響您建構應用程式和服務的方式。特別是這個領域，跨瀏覽器和平台的回應和方法各有不同。換句話說，您必須在多個不同環境中測試工作，這點非常重要。當然，這永遠很重要，但對於特定轉譯引擎而言，無論其位於哪個瀏覽器或平台，HTML 算繪或 CSS 都會保持不變 (這可能只是嘗試在一個以 Blink 為基礎的瀏覽器中進行測試)。但實際上這並非精準地使用 API，因為共用轉譯引擎的瀏覽器，會因使用指紋而強化 API 介面的方式，而有極大差異。
正確做法
- 檢視自己的數據分析和目標對象，以引導測試時應優先使用的瀏覽器組合。
- 有一組適用的瀏覽器要測試，包括 Firefox、Chrome、Edge、電腦版 Safari、Android 上的 Chrome 和 Samsung 網際網路，以及 iOS 的 Safari。這可確保您在三個主要的算繪引擎 (Firefox 中的 Gecko、Chrome、Edge 和 Samsung 網際網路中的 Blink 分支，以及 Safari 中的各種 Webkit) 測試，以及行動裝置和電腦平台上的 Webkit 測試。
- 如果您的網站可能用於較不常見的裝置 (例如平板電腦、智慧型手錶或遊戲主機)，請一併測試該網站。 部分硬體平台可能會在行動裝置和電腦上更新瀏覽器更新，這代表部分 API 可能無法在這些平台上的瀏覽器內導入或無法使用。
- 使用一或多個宣稱使用者隱私為動機的一或多個瀏覽器進行測試。包括常見瀏覽器即將推出的預先發布版和測試版本 (如果有的話)，以及是否可供使用：Safari 技術預覽、Chrome 的 Canary 版本、Firefox 的 Beta 版。這樣就能在這類變更影響使用者前，找出 API 故障情形和影響網站的變更。同樣地，請考量你提供的任何數據分析，考量使用者的環境。如果使用者的舊 Android 手機數量較多，請務必在測試中加入這類手機。大多數人都沒有開發團隊的快速硬體和最新版本。
- 請使用簡潔的設定檔和無痕模式/私密瀏覽模式進行測試；可能表示您已授予個人設定檔必要權限。測試當你拒絕將網站權限授予任何問題時，會發生什麼情況。
- 在 Firefox 的指紋防護模式中明確測試網頁。這樣一來，當網頁嘗試建立指紋時，系統就會顯示權限對話方塊，或者針對部分 API 傳回經過模糊化的資料。 這有助於您確認服務中包含的第三方是否使用指紋資料，或者您自己的服務是否仰賴該資料。隨後，您可以考慮刻意模糊化是否可以讓自己更難執行所需工作。建議您據此進行修正，以便從其他來源取得該資料、在沒有資料的情況下進行，或使用較不精細的資料。
- 如先前在第三方模組中所討論，請務必稽核第三方依附元件，確認他們是否使用數位指紋採集技術。被動數位指紋採集很難偵測 (如果第三方在自家伺服器上執行，則不可能)，但數位指紋採集模式可能會標記某些數位指紋採集技術，如果尋找使用 navigator.userAgent 或非預期的
<canvas>物件建立方式，也可能顯示一些需要進一步審查的方法。您可能也值得留意在行銷或描述第三方的技術資料中使用「機率比對」一詞；這有時可能代表使用數位指紋採集技術。
跨瀏覽器測試工具
如要基於隱私權考量測試程式碼並不容易，如前文所述，手動測試時應留意哪些事項。 舉例來說，如果您拒絕網站存取任何 API 所需的 API 權限，並禁止使用者存取該 API，會發生什麼情況？ 自動化測試無法判斷網站的作用是讓使用者信任網站，反之亦然。
不過，網站經過稽核後，系統會對 API 進行測試，確認新版瀏覽器 (或即將推出的「Beta 版」和「預先發布版」中) 沒有任何遺漏的項目，可以自動執行，且大部分應納入現有的測試套件。使用 API 介面涵蓋率時，要考慮使用自動化測試工具，因為大部分瀏覽器都允許一定程度的 API 和功能控制。Chrome 會透過指令列切換和 Firefox 執行此操作，但若在測試工具設定中存取這些功能，您就能在關閉或開啟 API 的情況下執行特定測試。(例如 Cypress 的 browser-launch 外掛程式和 puppeteer 的 launch.args 參數，瞭解在啟動時如何新增瀏覽器旗標的方法)。
只透過使用者代理程式字串取得粗略資訊
再舉一個例子，網頁一開始就在 HTTP User-Agent 標頭中送出每個要求的說明。幾乎久以來，使用者都迫不及待想要利用使用者代理程式標頭的內容，為不同的瀏覽器提供不同的內容。一直以來，網頁程式開發人員都確實這麼做，有些 (但並非全部) 的正當性也不盡相同。為了避免網站因瀏覽器不佳而受到使用者限制，這會導致每個瀏覽器偽裝成所有其他瀏覽器，因此使用者代理程式字串看起來會像這樣：
Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.
此版本也聲稱 Mozilla/5.0 版本，與首位太空人在二十年前登上國際太空站的同一時間。使用者代理程式字串是一個豐富的熵來源，不但包含數位指紋採集，也較可降低指紋辨識能力，瀏覽器製造商已經凍結使用者代理程式標頭，或正在設法解決這個問題。這另一個例子是變更 API 提供的資料，不必完全移除 API。傳送空白的使用者代理程式標頭會打斷無數網站 (假設有大量網站)。一般而言，瀏覽器正在執行哪些動作，會移除其中的部分細節，然後保持不變。(您在 Safari、Chrome 和 Firefox 中會看到這一點)。這種保護機制能夠防範精細的數位指紋採集，基本上意味著您不再仰賴使用者代理程式標頭的準確性。如果要這麼做，請務必找出替代資料來源。
明確來說，使用者代理程式中的資料不會完全消失，但這些資料的精細程度較低，或者有時可能會回報較舊但未變更的數字。舉例來說，Firefox、Safari 和 Chrome 會將回報的 macOS 版本號碼設為 10 (詳情請參閱「減少使用者代理程式字串更新」一節)。您可以參閱使用者代理程式縮減頁面，瞭解 Chrome 計劃減少使用者代理程式字串資料的詳細做法。但簡單來說，您可以預期報告的瀏覽器版本號碼只會包含主要版本 (即使瀏覽器為 123.10.45.108 版，即使瀏覽器版本為 123.10.45.108)，且版本編號較小，也不會有變動。因此，在虛線「Windows 20」上執行假的 Chrome 123.45.67.89 版，其版本號碼為：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/123.0.0.0 Safari/537.36
您所需的核心資訊 (瀏覽器版本) 仍可使用：適用於 Windows 的 Chrome 123。但是在凍結後，子公司資訊 (方塊架構、用來模擬的 Safari 版本、瀏覽器子版本) 將不再提供子公司資訊。
與其他平台上的「目前」Chrome 使用者代理程式進行比較：
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,
您會發現唯一的差別在於 Chrome 版本號碼 (104) 和平台 ID。
同樣地，Safari 的使用者代理程式字串會顯示平台和 Safari 版本號碼，也會提供 iOS 上的作業系統版本，但其他作業凍結。因此，在虛構的 macOS 20 上執行假的 Safari 1234.5.67 版，可能會得到下列使用者代理程式：
Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,
在虛假的 iOS 20 上，可能是：
Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.
再次提醒您，使用者也能取得核心資訊 (也就是 Safari，適用於 iOS 或 macOS)，而且 iOS Safari 仍會提供 iOS 版本號碼；但先前可用的大多數輔助資訊都已經凍結。重要的是，這包括並非不一定可用的 Safari 版本號碼。
針對回報的使用者代理程式的變化，大多來自熱烈討論。https://github.com/WICG/ua-client-hints#use-casesSummarises 歸納了某些引數和變更原因；Rowan Merewood 則提供簡報投影片，說明從 UA 客戶情境中遷離使用者代理程式的幾項策略。
模糊
模糊是安全性做法中的一個詞彙，在呼叫 API 時會帶有非預期的值，希望 API 能不當處理這些非預期值，並造成安全性問題。網頁開發人員應熟悉跨網站指令碼攻擊 (XSS)，因為這涉及在網頁中加入惡意指令碼，通常是因為網頁無法正確逸出插入的 HTML (因此您可以在搜尋查詢中使用 <script> 文字)。後端開發人員也會注意到 SQL 插入，因為資料庫查詢未正確驗證使用者輸入暴露的安全問題 (特別是在 xkcd 與 Little Bobby Tables 的情況下)。模糊測試 (即「模糊測試」) 則較適合用於自動化嘗試向 API 提供許多不同的無效或非預期的輸入，以及檢查結果是否有安全性外洩、當機或其他不良處理結果。以上均屬於故意提供不正確資訊的示例。不過，這種情況是由瀏覽器預先執行 (透過刻意將使用者代理程式錯誤設為錯誤)，鼓勵開發人員停止依賴這項資料。
正確做法
- 檢查您的程式碼集，看看是否依賴使用者代理程式字串 (搜尋
navigator.userAgent可能在用戶端程式碼中找出最常出現的情況，您的後端程式碼可能會尋找User-Agent做為標頭)，包括您的依附元件。 - 如果您在自己的程式碼中發現用途，請思考程式碼會檢查哪些項目，並找出另一種實現差異化的方法 (或者尋找替換的依附元件，或透過提交問題或檢查依附元件上游來與依附元件上游搭配運作)。有時瀏覽器必須產生差異來解決錯誤，但由於使用者代理程式停止運作，會逐漸不是防範錯誤的方法。
- 你可能很安全。如果您只使用品牌、主要版本和平台的核心值，那麼這些值幾乎仍可在使用者代理程式字串中使用，並且正確無誤。
- MDN 說明避免依賴使用者代理程式字串 (「瀏覽器監聽」) 的好方法，其中主要是一種功能偵測。
- 如果您只是依賴使用者代理程式字串 (即使只使用幾個保持實用的核心值)，建議您在新版瀏覽器中加入即將推出的使用者代理程式進行測試。您可以透過 Beta 版或技術預覽版本，自行測試即將推出的瀏覽器版本，但您也可以設定自訂的使用者代理程式字串來進行測試。進行本機開發時，您可以覆寫 Chrome、Edge、Firefox 和 Safari 中的使用者代理程式字串，檢查程式碼可能會如何處理使用者可能會傳送的不同使用者代理程式值。
用戶端提示
User-Agent Client Hints 是提供這項資訊的主要提案之一，但並非所有瀏覽器都支援這種做法。支援的瀏覽器會傳遞三個標頭：Sec-CH-UA，提供瀏覽器品牌和版本號碼；Sec-CH-UA-Mobile 指出要求是否來自行動裝置；Sec-CH-UA-Platform 則為作業系統命名。(相較於簡單的字串，剖析這些標頭並不容易，因為它們是結構化標頭，而非簡單的字串。此外，如果瀏覽器傳送「tricky」值，則會以不正確的方式處理。如同先前所述，瀏覽器會預先執行「模糊測試」的範例。開發人員必須使用這項資料妥善處理這項錯誤，因為資料的設計旨在以不當或延遲剖析方式產生不良結果，例如顯示不存在的品牌，或是字串未正確關閉。幸好，瀏覽器也會以 navigator.userAgentData 的形式將這項資料直接提供給 JavaScript，在支援的瀏覽器中看起來可能會像這樣：
{
"brands": [
{
"brand": " Not A;Brand",
"version": "99"
},
{
"brand": "Chromium",
"version": "96"
},
{
"brand": "Google Chrome",
"version": "96"
}
],
"mobile": false
}