開始使用 Trust Token

Trust Tokens 是一種新的 API，可讓網站在不同的瀏覽歷程 (例如跨網站) 之間傳送少量資訊，以便協助打擊詐欺，而不需要被動追蹤。

Sam Dutton

注意： 這個 API 已重新命名私密狀態權杖。developer.chrome.com 的「私人狀態權杖」一文提供實作狀態更新，說明如何參與及分享意見回饋。

注意： ⚠️ 警告：你可能需要更新應用程式！TrustTokenV3 是 Chromium 信任權杖實作的一系列回溯不相容變更。我們在 Chrome 92 推出相關變革，並在 2021 年 7 月底前將 Chrome 穩定版升級至穩定版。如果您尚未更新現有的應用程式測試 API，請先完成這項操作。如要瞭解詳情，請參閱什麼是 TrustTokenV3？。

摘要

信任權杖可讓來源將密碼編譯權杖核發給信任的使用者。憑證會由使用者的瀏覽器儲存。然後瀏覽器就能在其他內容中使用符記評估使用者的真實性。

Trust Token API 可讓對某情況中的使用者信任，將訊息傳遞到另一個內容，而無需識別使用者身分或連結兩個身分。

您可以透過我們的示範試用 API，並在 Chrome 開發人員工具的「Network」和「Application」分頁中檢查權杖。

在 Chrome 開發人員工具「網路」分頁中信任權杖。

在 Chrome 開發人員工具「Application」分頁中信任權杖。

注意： Privacy Sandbox 是一系列的提案，可在不使用第三方 Cookie 或其他追蹤機制的情況下，滿足第三方使用情境。如需所有提案的總覽，請參閱「深入瞭解 Privacy Sandbox」。這項提案需要您的意見回饋！如有意見，請在「信任權杖說明」存放區中建立問題。

為什麼需要信任權杖？

網路需要建立信任信號，以顯示使用者的身分，而非冒充真人的機器人，或惡意第三方。對廣告客戶、廣告供應商和 CDN 而言，詐騙防護功能格外重要。

不幸的是，許多現有機制可用於測量及反映可信度，例如判斷與網站的互動是否來自真人，例如利用同樣可用於數位指紋採集的技術。

重要詞彙： 數位指紋採集功能可讓網站取得使用者裝置、作業系統和瀏覽器設定 (例如語言偏好設定、使用者代理程式和可用的字型) 或裝置狀態變更等相關資料，以識別及追蹤個別使用者。您可以在伺服器上檢查要求標頭，或是透過 JavaScript 在用戶端進行這項作業。使用者無法得知和無法控制數位指紋採集的機制。

這個 API 必須保護隱私權，讓信任可以跨網站傳播，不必追蹤個別使用者。

Trust Tokens 提案的內容

網路仰賴建立信任信號來偵測詐欺和垃圾內容。其中一種做法是使用全域、跨網站使用者 ID 追蹤瀏覽，針對隱私權保護 API，我們不接受。

透過提案說明：

這個 API 針對「Privacy Pass」樣式加密權杖提供新的每個來源儲存區域，可在第三方環境中存取。這些權杖並非個人化，無法用於追蹤使用者，但經過加密簽署，因此無法偽造。

當來源處於可信任使用者的情境時，使用者便可向瀏覽器發出一批權杖，這可能是之後在使用者不明或較不受信任的情境中「購買」。重點在於，各個符記之間難以區分，導致網站無法透過憑證追蹤使用者。

我們進一步提議提供擴充機制，讓瀏覽器使用繫結特定權杖兌換作業的金鑰簽署傳出要求。

API 使用情況範例

以下內容取自 API 說明中的程式碼範例。

注意： 本文中的程式碼使用 Chrome 第 88 版之後提供的新版語法。

假設使用者造訪的新聞網站 (publisher.example)，當中嵌入了第三方廣告聯播網 (foo.example) 的廣告。使用者之前曾使用發布信任權杖 (issuer.example) 的社群媒體網站，

以下是信任權杖的運作方式。

1.使用者前往 issuer.example 並執行特定操作，引導網站相信自己是真人，例如帳戶活動或通過人機驗證 (Captcha)。

2.issuer.example 會驗證使用者是真人，然後執行下列 JavaScript，向使用者的瀏覽器發出信任權杖：

fetch('https://issuer.example/trust-token', {
  trustToken: {
    type: 'token-request',
    issuer: 'https://issuer.example'
  }
}).then(...)

3.使用者的瀏覽器會儲存信任權杖，並將其與 issuer.example 建立關聯。

4.一段時間後，使用者造訪 publisher.example。

5.publisher.example 想知道該使用者是否為真人，publisher.example 信任 issuer.example，因此會檢查使用者的瀏覽器是否具備來自該來源的有效權杖：

document.hasTrustToken('https://issuer.example');

6.如果傳回的結果可解析為 true，表示使用者擁有來自 issuer.example 的權杖，因此 publisher.example 可以嘗試兌換代碼：

fetch('https://issuer.example/trust-token', {
trustToken: {
  type: 'token-redemption',
  issuer: 'https://issuer.example',
  refreshPolicy: {none, refresh}
}
}).then(...)

使用這組代碼：

1. 兌換者 (publisher.example) 要求兌換。

2. 如果兌換成功，核發機構 issuer.example 會傳回兌換記錄，表示他們在某個時間點核發了有效的憑證給這個瀏覽器。

   7.解決 fetch() 傳回的承諾後，即可在後續的資源要求中使用兌換記錄：

fetch('https://foo.example/get-content', {
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['https://issuer.example', ...]
  }
});

使用這組代碼：

1. 兌換記錄會做為要求標頭 Sec-Redemption-Record 使用。
2. foo.example 會接收兌換記錄，並且可以剖析記錄，以判斷 issuer.example 是否認為該使用者為真人。
3. foo.example 並據此做出回應。

網站如何判斷你能否信任你？

您可能擁有電子商務網站的購物記錄、某個地點平台上的簽到功能，或是銀行的帳戶記錄。發卡機構可能也會考慮其他因素，例如建立帳戶的時間長短，或是其他可透過人機驗證 (Captcha) 或表單提交等其他互動，提高核發機構對真實真人的信任度。

信任權杖核發作業

如果 issuer.example 等信任權杖核發者認為使用者值得信任，核發者可以使用 trustToken 參數發出 fetch() 要求，藉此擷取使用者的信任權杖：

fetch('issuer.example/trust-token', {
  trustToken: {
    type: 'token-request'
  }
}).then(...)

這項操作會使用新的密碼編譯基元來叫用隱私權票證核發通訊協定的擴充功能：

1. 產生一組稱為 nonces 的虛擬隨機號碼。

2. 將 Nonce 進行編碼 (編碼以便核發者無法查看內容)，然後附加到 Sec-Trust-Token 標頭中的要求中。

3. 傳送 POST 要求至提供的端點。

端點會以盲權杖回應 (盲 Nonce 上的簽章)，然後權杖會保持去盲，並透過瀏覽器在內部與相關聯的 Nonce 做為信任權杖一起儲存。

信任權杖兌換

發布者網站 (例如上述範例中的 publisher.example) 可以檢查使用者是否有可用的信任權杖：

const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');

如果有符記可用，出版商網站可以兌換這些符記來取得兌換記錄：

fetch('issuer.example/trust-token', {
  ...
  trustToken: {
    type: 'token-redemption',
    refreshPolicy: 'none'
  }
  ...
}).then(...)

發布者可以使用如下的 fetch() 呼叫，在需要信任權杖的要求 (例如發布留言、對網頁或意見調查投票) 中加入兌換記錄：

fetch('https://foo.example/post-comment', {
  ...
  trustToken: {
    type: 'send-redemption-record',
    issuers: ['issuer.example/trust-token', ...]
  }
  ...
}).then(...);

兌換記錄會以 Sec-Redemption-Record 要求標頭的形式提供。

注意： 信任權杖只能透過擷取、XHR 和 HTML <iframe> 元素的選項存取：這些權杖無法直接存取。

隱私權注意事項

符記無法連結。核發者可以瞭解使用者造訪哪些網站，但無法透過兌換連結發出：使用者兌換代碼時，核發機構無法區分權杖與已建立的其他權杖。然而，信任權杖目前並不存在於真空中，理論上還有其他方式可以加入使用者的身分跨網站加入，例如第三方 Cookie 和隱密追蹤技術。網站在規劃支援時，必須瞭解這個生態系統的轉換過程。這是許多 Privacy Sandbox API 轉換作業的通用性，因此這裡沒有討論到。

安全性考量

信任權杖耗盡：惡意網站可能會刻意淘汰使用者向特定核發者提供的權杖。這類攻擊有多種緩解，例如可讓核發機構一次提供多個權杖，讓使用者充分確保瀏覽器在每個頂層頁面瀏覽只能兌換一個權杖。

避免重複帳戶：惡意軟體可能會嘗試存取使用者的所有信任權杖。不過，由於每次兌換都會傳送至相同的代碼核發者，因此代碼會隨著時間而出現，藉此驗證每個代碼僅使用一次。為降低風險，核發機構也可以減少簽署的權杖。

要求機制

您或許可以允許在 fetch() 之外傳送兌換記錄，例如導航要求。網站也可能在 HTTP 回應標頭中加入核發機構資料，以便在載入網頁時同時啟用權杖兌換功能。

再次提醒：這項提案需要你的意見回饋！如有任何意見，請在信任權杖說明存放區中建立問題。

瞭解詳情

• 信任權杖示範
• Chrome 來源試用入門
• 深入瞭解 Privacy Sandbox
• Trust Token API 說明
• Chromium 專案：Trust Token API
• 實作意圖：Trust Token API
• Chrome 平台狀態
• Privacy Pass
• Privacy Pass 擴充內容

---

感謝所有協助撰寫及評論這篇文章的使用者。

攝影者：ZSun Fu，發表於 Unsplash 網站上。