當我們在設計社交功能時，最常遇到的矛盾就是如何在提供便利的互動體驗與保護使用者隱私之間取得平衡。傳統的系統設計通常會給予每位使用者一個全域唯一的身分（Global Identity），無論是在哪個功能模組，系統都使用同一套 Profile 資訊。但對於像 Airbnb 這種涉及陌生人互動的平台，如果使用者在參加不同的體驗活動時，都被迫暴露相同的全域身分，將會產生嚴重的隱私風險，例如讓不認識的人能輕易地將使用者在不同活動中的身分串聯起來。
為了解決這個問題，Airbnb 重新設計了其身分與連接模型，核心概念是將內部身分與外部可見的設定檔（Profile）徹底分離，並引入上下文感知（Context-Aware）的機制。
什麼是上下文感知身分模型
簡單來說，Airbnb 不再讓使用者在所有地方共用同一個全域 Profile，而是針對不同的體驗活動（Experiences）建立多個特定上下文的設定檔（Context-specific Profiles）。
在這種設計下，身分被限制在特定的範圍（Scoped Identity）內。例如，當你參加一個烹飪課程時，系統會為你生成一個僅限於該課程的 Profile；當你參加另一個徒步旅行活動時，則是另一個獨立的 Profile。這意味著參與者只能在共同參與的活動中看到你的相關資訊，無法透過這個身分去追蹤你在其他活動中的表現或資訊，有效地將社交圖譜（Social Graph）碎片化，防止身分被跨場景串聯。
確保隱私的技術實作：Himeji 授權框架
僅有邏輯上的分離是不夠的，必須在系統底層確保資料存取的安全性。Airbnb 使用了一個名為 Himeji 的內部授權框架來實作關係型存取控制（Relationship-based Access Control, ReBAC）。
ReBAC 與傳統的角色存取控制（RBAC）不同，它不關心你是管理員還是普通用戶，而是關心使用者之間的關係。在 Himeji 的機制中，系統會在執行階段（Runtime）動態評估兩個使用者是否共享同一個上下文（例如是否在同一個活動中）。只有當這種關係成立時，系統才會允許存取對應的 Profile 資訊。
將這種強制執行機制放在資料存取層（Data Access Layer）而非介面層（Interface Level）至關重要。如果只在前端或 API 接口限制，很容易因為開發疏忽而導致漏洞；而放在資料層則能確保無論哪個服務請求資料，都必須經過一致的隱私檢查。
大規模遷移的工程實務
將全域身分模型遷移到上下文身分模型是一項巨大的工程挑戰，因為這涉及到整個程式碼庫中對使用者識別碼（Identifier）的引用方式。Airbnb 採取了以下步驟來降低風險：
首先是自動化審計。工程團隊開發了掃描工具，在全公司程式碼中搜尋所有存取使用者資料的模式，並根據儲存庫結構將這些潛在的修改點分配給對應的負責團隊。
其次是人工審查與 AI 輔助。由於系統無法完全分辨某段代碼存取資料是為了內部管理（Internal）還是外部顯示（External），因此需要工程師進行人工確認。為了加速這個過程，他們引入了 AI 輔助重構工具，由 AI 建議修改方案，再由工程師審核驗證，形成人機協作的迴路。
最後是跨部門協作。身分定義的變更不僅是技術問題，更涉及法律與隱私合規。這需要工程、產品、隱私與法律團隊共同定義身分的語義（Semantics）以及上線優先順序，確保新功能在推出時就內建隱私保護。
總結與啟發
對於開發者而言，Airbnb 的案例提供了一個重要的思考方向：當系統複雜度增加時，不要依賴單一的靜態屬性來定義權限，而應該考慮將身分與上下文（Context）綁定。透過將權限控制下沉到資料層，並利用自動化工具處理大規模重構，可以在不犧牲使用者體驗的前提下，實現更高強度的隱私保護。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。