「信任權杖」是一種新的 API,可讓網站從一個瀏覽環境 (例如跨網站) 傳遞少量資訊,協助防範詐欺行為,不必被動追蹤。
摘要
信任權杖可讓來源核發加密編譯權杖給信任的使用者。這些權杖是由使用者的瀏覽器儲存。然後瀏覽器即可在其他內容中使用符記來評估使用者的真實性。
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(...)
使用這組代碼:
- 兌換者「
publisher.example
」要求兌換。 如果兌換成功,核發機構
issuer.example
會傳回兌換記錄,說明他們在某個時間點核發有效憑證給這個瀏覽器。7.解決
fetch()
傳回的承諾後,兌換記錄就能在後續資源要求中使用:
fetch('https://foo.example/get-content', {
trustToken: {
type: 'send-redemption-record',
issuers: ['https://issuer.example', ...]
}
});
使用這組代碼:
- 兌換記錄會以要求標頭
Sec-Redemption-Record
的形式納入。 foo.example
會收到兌換記錄,並且可以剖析記錄,以判斷issuer.example
是否認為這位使用者可能是真人。foo.example
會據此回應。
您可能擁有購物記錄,例如電子商務網站、在某個位置平台上簽到,或者是銀行的帳戶記錄。此外,核發者也可能會考量其他因素,例如您擁有帳戶多久時間,或是還有其他互動 (例如人機驗證 (Captcha) 或表單提交) 以提高發卡機構對您是真人的信任。
信任權杖核發作業
如果信任權杖核發者 (例如 issuer.example
) 認為使用者值得信任,則核發機構可以使用 trustToken
參數發出 fetch()
要求,擷取使用者的信任權杖:
fetch('issuer.example/trust-token', {
trustToken: {
type: 'token-request'
}
}).then(...)
這會使用新的密碼編譯基元叫用 Privacy Pass 核發通訊協定的擴充功能:
產生一組偽隨機號碼,稱為「nonces」。
對 Nonce 進行編碼 (進行編碼,讓核發機構無法檢視其內容),然後將其附加至要求中的
Sec-Trust-Token
標頭。將 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 平台狀態
- 隱私權通行證
- 隱私權通行證擴充功能
感謝所有協助撰寫及評論這篇貼文的使用者。