開始使用 Trust Token

「信任權杖」是一種新的 API，可讓網站從一個瀏覽環境 (例如跨網站) 傳遞少量資訊，協助防範詐欺行為，不必被動追蹤。

Sam Dutton

摘要

信任權杖可讓來源核發加密編譯權杖給信任的使用者。這些權杖是由使用者的瀏覽器儲存。然後瀏覽器即可在其他內容中使用符記來評估使用者的真實性。

Trust Token API 可在不識別使用者身分或連結兩個身分的情況下，將某個情境中的信任使用者傳送至其他情境。

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

為什麼需要信任權杖？

網路需要建立信任信號，以證明使用者的身分，而非假冒真人的機器人，或惡意第三方詐騙使用者或服務。詐欺防範對於廣告客戶、廣告供應商和 CDN 而言特別重要。

可惜的是，許多現有機制可用來衡量及傳播可信度，以評估與某個網站的互動是否來自真人，例如利用也可用於數位指紋採集的技術。

API 必須保護隱私權，這樣信任就能傳播至沒有個別使用者追蹤的網站。

信任權杖提案包含哪些內容？

網站會根據建立信任信號來偵測詐欺和垃圾內容。其中一種方法是使用全域的跨網站個別使用者 ID 追蹤瀏覽活動。隱私保護 API 無法接受，

在提案說明中：

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

如果來源位於使用者信任使用者的情境中，他們可能會向瀏覽器發出一批權杖，之後可在使用者可能不明或較不信任的內容中，「分發」這類權杖。基本上，符記是彼此無法區分的，使網站無法追蹤使用者。

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

API 使用情況範例

以下內容是根據 API 說明中的程式碼範例調整而來。

假設使用者造訪的新聞網站 (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 會據此回應。

信任權杖核發作業

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

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

這會使用新的密碼編譯基元叫用 Privacy Pass 核發通訊協定的擴充功能：

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 要求標頭的形式納入。

隱私權注意事項

權杖是「無法連結」的狀態。核發機構可以掌握使用者造訪哪些網站的相關匯總資訊，但無法將核發憑證連結至兌換項目：使用者兌換代碼時，核發機構無法區分憑證與其已建立的其他權杖。不過，目前信任權杖並不存在，理論上來說，核發者目前還有其他方法可將使用者的身分加入各個網站，例如第三方 Cookie 和隱蔽追蹤技術。網站必須瞭解這個生態系統轉換作業，因為他們正在規劃支援。這是許多 Privacy Sandbox API 轉換的通用層面，因此不會進一步說明。

安全性考量

信任權杖耗盡：惡意網站可能會刻意將使用者提供特定核發者的憑證。對這類攻擊有數種緩解措施，例如允許核發機構一次提供多個權杖，讓使用者有充分的供應機制，確保瀏覽器每次檢視頂層網頁檢視時，都只會兌換一個權杖。

防止重複支出：惡意軟體可能會嘗試存取使用者的所有信任權杖。不過，系統每隔一段時間就會執行權杖，因為每次兌換都會傳送至相同的權杖核發機構，這樣可以驗證每個憑證只能使用一次。如要降低風險，核發機構也可以簽署較少權杖。

要求機制

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

重申：這個提案需要您的意見回饋！若有註解，請在信任權杖的說明存放區中建立問題。

瞭解詳情

• 信任權杖示範
• 開始使用 Chrome 的來源試用
• 深入瞭解 Privacy Sandbox
• Trust Token API 說明
• Chromium 專案：Trust Token API
• 要導入的意圖：Trust Token API
• Chrome 平台狀態
• 隱私權通行證
• 隱私權通行證擴充功能

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

相片由 ZSun Fu 在 Unsplash 上提供。