過去,第三方 Cookie 已用於儲存及傳送使用者狀態的相關資訊,例如登入狀態、所用裝置的相關資訊,或者是否受到已知和信任。例如,使用者是否已透過單一登入 (SSO) 登入、使用者是否有特定類型的相容裝置,或者使用者是否已知且信任使用者。由於第三方 Cookie 支援功能遭到淘汰,因此需要透過其他方式支援這類用途。
私密狀態權杖可讓您在網路上分享資訊,但透過控管實際可分享的資料量,以保障隱私的方式保護資訊。
Private State Tokens (舊稱「Trust Tokens」) 可讓信任將使用者的真實性從一個情境傳遞到另一個情境中,同時協助網站抵禦詐欺行為,以及區分機器人和真人,而不需要被動追蹤。
本文件概述實作私密狀態權杖 (PST) 的技術詳細資料。如需更詳盡的概要,請參閱 PST 總覽。
私密狀態權杖的運作方式
發卡機構和兌換者需要瞭解 PST 的主要關係。核發者和兌換者可以是同一家公司。
- Issuers - 這些實體有關於使用者的某些信號 (例如,使用者是否是機器人),並將該信號嵌入使用者裝置的權杖中 (詳情請參閱後續章節)。
- 兌換者 - 這些實體可能沒有使用者信號,但需要知道一些相關資訊 (例如該使用者是否為機器人),並要求核發者兌換權杖,才能瞭解該使用者的信任。
每次 PST 互動都會要求發卡機構和兌換者搭配運作,以便在網路上共用信號。這些信號為概略值,並未不夠詳盡,無法用來識別個人。
私密狀態權杖適合我嗎?
如果公司做出信任決定,且希望資訊能在各種情境中取用,就很適合使用 PST。如要進一步瞭解 PST 的潛在用途,請參閱 PST 使用案例說明文件。
核發及兌換代碼
PST 實作分為三個階段:
- 核發權杖
- 兌換代碼
- 兌換記錄轉送
在第一階段,系統會將符記核發給瀏覽器 (通常會在某種類型的驗證後)。在第二階段中,另一個實體會要求兌換符記,所核發的符記會讀取該符記中的值。在最終階段,兌換者會收到含有代碼所含值的兌換記錄 (RR)。兌換方隨後可將該記錄用來認證使用者,以用於各種用途。
定義權杖策略
定義權杖策略時,您需要瞭解 PST 的重要概念 (符記和兌換記錄)、變數、行為和限制,才能思考它們的潛在用途。
權杖和兌換記錄:兩者之間的關係為何?
每部裝置在每個頂層網站和核發機構最多可儲存 500 個權杖。此外,每個權杖都有中繼資料,說明核發者使用哪個金鑰。在兌換過程中,這些資訊可用來決定是否兌換代碼。PST 資料會儲存在使用者裝置的瀏覽器內部,且只能透過 PST API 存取。
使用者兌換代碼後,兌換記錄 (RR) 就會儲存在裝置上。 這個儲存空間可當做日後兌換項目的快取。針對每部裝置、網頁和核發者,每 48 小時會兌換 2 次權杖。新的兌換呼叫會盡可能使用快取 RR,而非向發卡機構發出要求。
- 系統會核發新的權杖 (每個核發機構、網站和裝置最多 500 個)。
- 所有權杖會儲存在裝置端權杖存放區 (類似 Cookie 存放區)。
- 如果找不到任何有效的 RR,則會在核發後產生新的 RR (最多每 48 小時 2 次)。
- 在到期之前,RR 都會視為有效,並會作為本機快取使用。
- 新的兌換呼叫會到達本機快取,不會產生新的 RR。
定義用途後,您必須謹慎定義 RR 的壽命,因為這會定義在事件中可以使用的次數。
定義策略之前,請務必瞭解下列關鍵行為和變數:
變數 / 行為 | 說明 | 可能的用量 |
---|---|---|
權杖金鑰中繼資料 | 每個權杖只能使用一個加密編譯金鑰核發,且在 PST 中每個核發者最多只能有六組金鑰。 | 使用這個變數的一種可能方式,就是根據加密編譯金鑰來定義權杖的信任範圍 (例如,金鑰 1 = 高信任,而金鑰 6 = 不信任)。 |
權杖到期日 | 權杖到期日與金鑰到期日相同。 | 金鑰至少每 60 天輪替一次,而且由無效金鑰核發的所有權杖也會視為無效。 |
權杖兌換頻率限制 | 每部裝置和核發者每 48 小時最多只能兌換兩次權杖兌換作業。 | 視用途預估每 48 小時的兌換次數而定。 |
每個頂層來源的核發機構數量上限 | 目前每個頂層來源的核發機構數量上限為兩個。 | 仔細定義各頁面的發卡機構。 |
裝置上每個發卡機構的權杖數量 | 目前每個核發機構的權杖數量上限為 500 個。 | 每個核發者的權杖數量不得超過 500 個。 嘗試核發權杖時,請務必處理網頁上的錯誤。 |
金鑰使用承諾輪替 | 每個 PST 核發者都必須公開具有金鑰承諾的端點,這類修訂版本每 60 天可以變更,且任何速度的輪替時間都會超過系統會忽略的時間。 | 如果金鑰將於 60 天內到期,您必須在該日期前更新金鑰使用承諾,以免服務中斷 (請參閱詳細資料)。 |
兌換記錄效期 | 可以定義 RR 的效期,以便判斷到期日。系統會快取 RR,避免對核發機構發出不必要的新的兌換呼叫,因此請務必提供足夠的最新兌換信號。 | 由於每 48 小時有兩個符記的兌換率限制,因此請務必定義 RR 的效期,至少能在這段時間內執行成功的兌換呼叫 (RR 生命週期應據此設定)。建議您按照週次設定這個生命週期。 |
範例情境
情境 #1:RR 效期短於 24 小時 (t=t),且在 48 小時內多次執行兌換作業。
情境 #2:RR 效期為 24 小時,且在 48 小時期間內多次執行兌換作業。
情境 #3:RR 效期為 48 小時,且在 48 小時內多次執行兌換作業。
執行示範
採用 PST 前,建議先進行示範設定。如要試用 PST 示範,您必須使用標記執行 Chrome 以啟用示範核發者金鑰承諾產品 (請按照示範頁面上的指示操作)。
執行這項示範之後,瀏覽器就會使用示範核發機構和兌換器伺服器來提供及使用權杖。
技術考量
建議您執行下列步驟,以最佳方式執行示範:
- 請務必先停止所有 Chrome 執行個體,再執行含有旗標的 Chrome。
- 如果您在 Windows 電腦上執行,請參閱 這份指南,瞭解如何將參數傳遞給 Chrome 執行檔二進位檔。
- 開啟 Chrome 開發人員工具 (依序點選「Applications」>「儲存空間」>「Private State Tokens」,同時查看示範核發機構核發/兌換的權杖)。
設定以採用
成為核發機構
發行者在 PST 中扮演關鍵角色。他們會指派值給符記,以判斷使用者是否為機器人。如要以核發者的身分開始使用 PST,您必須完成核發機構註冊程序才能完成註冊。
如要申請成為核發者,核發機構網站的操作者必須採用「New PST Issuer」範本,在 GitHub 存放區上建立新的問題。按照存放區的指南填寫問題。端點通過驗證後,系統會將其合併至這個存放區,Chrome 伺服器端基礎架構也會開始擷取這些金鑰。
核發者伺服器
發行者和兌換者是 PST 的關鍵執行者;伺服器和符記是 PST 的關鍵工具。雖然我們已在 GitHub 說明文件中提供部分權杖的相關詳細資料,但還是想提供更多有關 PST 伺服器的詳細資料。如要設定為 PST 的核發者,您必須先設定核發伺服器。
部署環境:核發者伺服器
如要實作權杖核發機構伺服器,您必須建構自己的伺服器端應用程式,公開 HTTP 端點。
核發者元件由兩個主要模組組成:(1) 核發者伺服器和 (2) 權杖核發者。
如同所有面向網頁版的應用程式,我們建議您為核發者伺服器多添一層保護。
核發者伺服器:在我們的範例實作中,核發伺服器是使用 Express 架構來託管核發者 HTTP 端點的 Node.js 伺服器。您可以前往 GitHub 查看程式碼範例。
權杖核發者:核發者加密元件不需要任何特定語言,但基於這個元件的效能要求,我們提供 C 實作範例,讓您使用 Boring SSL 程式庫管理權杖。您可以找到 Issuer 程式碼範例及關於 GitHub 安裝的詳細資訊
金鑰:權杖核發機構元件會使用自訂 EC 金鑰加密權杖。這些金鑰必須受到保護並儲存在安全儲存空間中。
核發機構伺服器的技術相關規定
根據通訊協定,您必須在核發者伺服器中至少實作兩個 HTTP 端點:
- 金鑰承諾 (例如
/.well-known/private-state-token/key-commitment
):可讓瀏覽器前往這個端點,確認您的伺服器是否合法。 - 權杖核發作業 (例如
/.well-known/private-state-token/issuance
):處理所有權杖要求的權杖核發端點,這個端點將成為權杖核發者元件的整合點。
如前文所述,由於這個伺服器可能會處理的流量偏高,因此建議您使用可擴充的基礎架構 (例如雲端環境) 部署伺服器,以便依據變數需求調整後端。
將通話傳送至核發機構伺服器
實作對發卡機構堆疊的網站擷取呼叫,以發出新的權杖。
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
兌換者伺服器
您必須建構自己的伺服器端應用程式,以實作權杖兌換服務。這可讓您讀取發卡機構傳送的憑證。下列步驟概述如何兌換代碼,以及如何解讀與這些代碼相關聯的兌換記錄。
您可以選擇在相同的伺服器 (或一組伺服器) 中執行核發機構和兌換者。
兌換者伺服器的技術相關規定
根據通訊協定,您必須為兌換工具伺服器實作至少兩個 HTTP 端點:
/.well-known/private-state-token/redemption
:處理所有權杖兌換的端點。這個端點會是整合權杖遮蓋元件的位置
傳送呼叫至兌換者伺服器
如要兌換權杖,您需要在兌換工具堆疊中導入網站擷取呼叫,才能兌換先前核發的權杖。
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
請參閱程式碼範例。
兌換權杖後,您可以執行其他擷取呼叫來傳送兌換記錄 (RR):
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
請參閱程式碼範例。
部署實作項目
如要測試實作結果,請先前往發出呼叫的網頁,並確認權杖是根據您的邏輯建立。在後端確認呼叫是根據規格發出,接著前往進行兌換呼叫的網頁,確認已按照邏輯建立 RR。
實際部署
建議您選取屬於特定用途的網站:
- 每月造訪次數較少 (每個月約 100 萬次造訪):建議您先先將 API 部署至少數目標對象
- 其控制權為您所有:如有需要,您可以快速停用實作程序,不必進行複雜的核准程序
- 僅限一個核發者:限制權杖數量以簡化測試。
- 兌換者不得超過兩位:您需要簡化疑難排解過程,
疑難排解
您可以在 Chrome 開發人員工具「Network」和「Application」分頁中檢查 PST。
在「網路」標籤上:
在 [Application] (應用程式) 分頁中:
進一步瞭解這項開發人員工具整合。
伺服器最佳做法和疑難排解
為了讓核發機構和兌換者伺服器能夠有效運作,建議您採用下列最佳做法,確保您不會遇到 PST 的任何存取、安全性、記錄或流量等問題。
- 您的端點必須使用 TLS 1.3 或 1.2 套用高強度密碼編譯。
- 您的基礎架構必須準備好處理變動的流量 (包括尖峰)。
- 請確認您的金鑰受到保護且安全,並與您的存取權控管政策、金鑰管理策略和業務持續性計畫保持一致。
- 在堆疊中加入可觀測指標,確保在實際發布後,您能夠清楚掌握用量、瓶頸和效能問題。
更多資訊
- 參閱開發人員說明文件:
- 透過 GitHub 問題或 W3C 呼叫在對話中貢獻心力。
- 如要進一步瞭解任何術語,請參閱 Privacy Sandbox 詞彙。
- 如要進一步瞭解 Chrome 概念,例如「來源試用」或「Chrome 旗標」,請參閱 goo.gle/cc 提供的短片和文章。