本文探討裝置端個人化 (ODP) 背後的動機、引導開發方向的設計原則、透過機密性保障隱私的模型，以及這項功能如何協助確保經驗證的私人體驗；建議您在 Android 開放原始碼計畫 (AOSP) 中實作以下說明的技術內容。
為此，我們計劃簡化資料存取模型，並確保所有離開安全邊界的使用者資料在各個使用者、採用者、model_instance 層級 (有時在本文件中縮短為使用者層級) 具有差異化隱私的特性。
請注意，使用者資料從使用者裝置輸出後，任何與其相關的潛在程式碼都將成為開放原始碼，且可由外部實體驗證。在提案的初期階段，我們會談到可能有機會採用裝置端個人化功能的平台，希望能引起客戶興趣，並向他們收集意見回饋。我們會邀請隱私權專家、資料分析師和安全從業人員等利害關係人，一同攜手合作。
視覺
裝置端個人化功能的設計宗旨，是要防止從未與使用者互動過的商家存取他們的資訊。商家或許可以繼續為使用者自訂產品和服務 (例如使用適當的去識別化和差異化隱私機器學習模型)，但無法查看這些為使用者自訂的確切內容 (這不僅取決於商家產生的自訂規則，也視個別使用者偏好而定)。除非商家與使用者曾直接互動，否則情況就會如上所述。如果商家產生任何機器學習模型或統計分析，ODP 會設法使用適當的差異化隱私機制，確保這些內容妥善完成去識別化。
探索 ODP 的同時，我們目前規劃了多個里程碑，涵蓋以下各項功能。歡迎感興趣的各方人士提供具體建議，協助我們進一步開發其他功能和工作流程。
- 沙箱環境，其中含有各式可執行的商業邏輯，允許多種使用者信號進入沙箱，同時限制輸出內容。
端對端加密資料儲存庫，適用於：
- 使用者控制項和其他使用者相關資料。這可能是使用者提供，或商家收集、推論而來。此外還包括存留時間 (TTL) 控制項、抹除政策、隱私權政策等。
- 業務設定。ODP 會提供演算法來壓縮或模糊處理這些資料。
- 業務處理結果。這些結果可能會出現以下情況：
- 在後續處理過程中，以輸入內容的形式消耗
- 根據適當的差異化隱私機制加上雜訊，並上傳至符合資格的端點。
- 透過受信任的上傳流程上傳到受信任的執行環境 (TEE)，其中的開放原始碼工作負載會以適當的集中差異化隱私機制處理。
- 向使用者顯示。
旨在達成以下目標的 API：
- 以批次或漸進方式更新 2(a)。
- 定期以批次或漸進方式更新 2(b)。
- 上傳 2(c)，並在受信任的匯總環境中使用適當的雜訊機制。在接下來的處理過程中，這類結果可能會變為 2(b)。
設計原則
ODP 有三大重點需要兼顧，分別是隱私性、公平性和實用性。
用於強化隱私保護服務的塔式資料模型
ODP 遵循隱私保護設計，預設上即以保護使用者隱私為首要考量。
ODP 會探索如何將個人化作業轉移至使用者的裝置上處理。這種做法可以盡可能將資料保存在裝置上，只在必要時才於裝置外部處理，有利於在隱私與實用性之間取得平衡。ODP 的重點如下：
- 掌握使用者資料的裝置控制權，即使資料不在裝置上也一樣。目標環境必須經認證為受信任的執行環境，由公有雲端服務供應商提供，且執行 ODP 編寫的程式碼。
- 確認使用者資料從裝置轉出後，裝置會如何處理。ODP 提供開放原始碼的聯合運算工作負載，方便採用者協調跨裝置機器學習和統計分析。使用者的裝置將驗證這類工作負載會在未修改的受信任執行環境中執行。
- 確保內容從裝置控管/驗證的邊界輸出後，能夠獲得技術隱私保障，例如經過匯總、加上雜訊，或採取差異化隱私機制。
綜上所述，我們可知個人化功能將因裝置而異。
此外，由於商家需要採取隱私保護措施，而平台應負責處理，這代表您須將原始業務資料存放在各平台的伺服器中。為此，ODP 採用的資料模型如下：
- 每個原始資料來源都會儲存於裝置或伺服器端，以利在本機學習及推論。
- 我們將提供演算法，以便跨多個資料來源做出決策，例如在兩個不同的資料位置間篩選，或是跨多個來源進行訓練或推論。
在這種情況下，可能會出現類似下方的商家和使用者塔式結構：
使用者塔式結構內含使用者提供的資料 (例如帳戶資訊和控制項)、使用者與裝置互動的相關收集資料，以及由商家推論的衍生資料 (例如興趣和偏好)。推測資料不會覆寫任何使用者的直接宣告。
相較之下，在以雲端為主的基礎架構中，使用者塔式結構內的所有原始資料都會轉移至商家伺服器。反之，在以裝置為主的基礎架構中，使用者塔式結構內的所有原始資料都保留在原處，商家資料則保留在伺服器上。
裝置端個人化功能結合這兩種方式的優點，僅利用經認證的開放原始碼，讓系統透過更私密的輸出管道處理可能與 TEE 使用者相關的資料。
多元包容且讓大眾參與的公平解決方案
ODP 的目標是確保多元生態系統中的所有參與者都能享有平等的環境。我們深知這個生態系統的錯綜複雜，是由提供不同服務和產品的眾多玩家構成。
為了激發創意，ODP 提供的 API 可由開發人員及其代表的公司實作。裝置端個人化功能有助於完美整合這些實作項目，同時管理版本、監控作業、開發人員工具和意見回饋工具。裝置端個人化不會產生任何具體的商業邏輯；而是會做為創意的催化劑。
日後 ODP 可能會提供更多演算法。如需決定合適的功能層級，並為每個參與的商家制定合理的裝置資源上限，與生態系統的合作就至關重要。我們期許能收到來自生態系統的意見回饋，協助找出新的用途並排定優先順序。
協助開發人員提升使用者體驗並確保實用性
使用 ODP 時，所有事件都會在裝置層級記錄於本機之中，因此不會遺失事件資料或造成觀測延遲。由於沒有彙整錯誤，且所有事件都與特定裝置建立關聯，因此，所有觀察到的事件都會依時間順序，自然呈現出使用者的互動情形。
這個簡化的程序可省去彙整或重新排列資料的需求，方便以近乎即時且無損的方式存取使用者資料。如此一來，當使用者與資料導向產品和服務互動時，這可讓他們感到更加實用，進而可能提升滿意度並帶來更有意義的體驗。透過 ODP，商家可以因應使用者需求有效調整。
隱私權模型：透過機密性保障隱私權
以下各節將討論做為此隱私權分析基礎的消耗端 - 生產端模型，同時比較運算環境隱私與輸出準確率。
這項隱私權分析是以消耗端 - 生產端模型為依據
我們將採用消耗端 - 生產端模型，檢視透過機密性提供的隱私權保障。這個模型中的運算會以有向非循環圖 (DAG) 中的節點表示，圖中除了節點還有子圖表。每個運算節點都有三個元件：消耗的輸入內容、產生的輸出內容，以及將輸入內容對應至輸出內容的運算過程。
在這個模型中，隱私保護服務適用於下列三項元素：
- 輸入內容隱私。節點可以有兩種輸入類型，如果輸入內容是由先前的節點產生，則該輸入內容已具有先前節點的輸出隱私保證。但若不是，輸入內容必須使用政策引擎清除資料輸入政策。
- 輸出內容隱私。輸出內容可能需經私有化，例如完成差異化隱私 (DP) 處理。
- 運算環境機密性。運算必須在安全加密的環境中進行，確保沒有人可以存取節點內的中介狀態。可達成此目標的技術包括聯合運算 (FC)、硬體式的受信任執行環境 (TEE)、安全多方運算 (sMPC)、同態加密 (HPE) 等。值得注意的是，不論是透過機密性保護措施確保的隱私權、中介狀態，還是從機密邊界輸出的任何內容，都仍需受到差異化隱私機制保護。您必須提供以下兩項聲明：
- 環境機密性：確保只有聲明的輸出內容才會離開環境
- 完整性：確保能透過輸入隱私權聲明準確推斷出輸出隱私權聲明。完整性可讓隱私權屬性向下傳播 DAG。
雖然私有系統可確保輸入/輸出內容隱私，以及運算環境機密性，但如果您在機密運算環境中加密更多處理作業，差異化隱私機制的應用方式可能就會受限。
這個模型有兩大優點。首先，多數系統 (不論大小) 都可以用 DAG 表示。其次，DP 的 後續處理 [第 2.1 節] 和組合 Lemma 2.4 in The Complexity of Differential Privacy 屬性提供強大工具，可以分析整個圖表的隱私權和準確性取捨：
- 「後續處理」可確保在某個數量完成私有化後，如果沒有再次使用原始資料，該數量則無法進行「非私有化」。只要節點的所有輸入內容都是不公開的，那麼無論運算情況為何，其輸出內容也會保持不公開。
- 「進階組合」可保證如果每個圖形部分都採用 DP，整體圖表也會採用 DP，如此一來，假設圖表有 κ 個單元，且每單元的輸出內容為 (ε, δ)-DP，就能有效地將圖表最終輸出的 ε 和 δ 分別限制在約 ε√κ 的範圍內。
這兩個屬性會轉化為適用於每個節點的兩項設計原則：
- 屬性 1 (來自後續處理)：如果節點的輸入內容全都採用 DP，其輸出內容也都會採用 DP，可容納任何在節點中執行的任意商業邏輯，同時支援商家的「關鍵機密」。
- 屬性 2 (來自進階組合)：如果節點的輸入內容並非全部採用 DP，其輸出內容就必須符合 DP 規定。如果運算節點是在受信任的執行環境中執行，且執行的開放原始碼工作負載和設定是由裝置端個人化功能提供，那麼 DP 邊界範圍可能就會較為受限。但若不是，裝置端個人化功能可能就需使用最遭情況下的 DP 邊界範圍。由於資源限制的關係，在初始階段，公有雲端服務供應商提供的受信任執行環境便會優先使用。
運算環境的隱私性與輸出準確率
有鑑於此，裝置端個人化功能會著重於強化機密運算環境的安全性，確保中介狀態不被有心人士存取。這項安全性程序稱為加密，會在子圖表層級套用，讓多個節點同時符合 DP 標準。也就是說，前述的屬性 1 和屬性 2 會在子圖表層級套用。
當然，最終圖形輸出內容 (輸出內容 7) 會依組合進行 DP。也就是說，這個圖表合計採用 2 個 DP。相比之下，如不使用加密，則共有 3 個本機 DP。
基本上，透過保護運算環境，並避免對手存取圖表或子圖表的輸入和中繼狀態，這樣就能實作中央 DP (也就是說，密封環境的輸出內容符合 DP 規範)，與本機 DP 相比，則能提高符合 DP 規範的準確率。這項原則立意深遠，其中採用 FC、TEE、sMPC 和 HPE 做為隱私權技術。詳情請參閱《The Complexity of Differential Privacy》第 10 章。
模型訓練和推論很適合當做實務範例。下文討論的假設有二：(1) 訓練總體和推論總體重疊；(2) 私人使用者資料由功能和標籤構成。我們可以將 DP 套用至所有輸入內容：
裝置端個人化功能可以先將本機 DP 套用至使用者標籤和功能，然後再將這兩項內容傳送至伺服器。此方法不會對伺服器的執行環境或商業邏輯施加任何要求。
這是目前的裝置端個人化設計。
隱私可經驗證
裝置端個人化功能旨在以可經驗證的方式確保隱私安全無虞，重點在於驗證使用者裝置上發生的情況。ODP 會編寫程式碼，處理從使用者裝置傳出的資料，並使用 NIST 的 RFC 9334 遠端認證程序 (RATS) 架構，驗證這類程式碼的執行環境是否為符合機密運算聯盟規範、未經修改，且不具例項管理員權限的伺服器。為了取得使用者信任，這些程式碼將採用開放原始碼，且可供公開驗證。這類措施能讓每個人相信自己的資料受到保護，而商家也能基於穩固的隱私權保證來累積信譽。
減少收集及儲存的私人資料量，是裝置端個人化功能的另一個重要面向。為了遵循這項原則，該功能採用了聯合運算和差異化隱私等技術，讓重要的資料模式得以呈現，但不會揭露私密的個人詳細資料或識別資訊。
確保隱私可經驗證的另一個重要面向，是持續撰寫稽核記錄，記下與資料處理和分享作業相關的活動。此做法不僅可建立稽核報告，還能找出安全漏洞，展現我們對隱私權的承諾。
我們期望與隱私權專家、主管機關、產業和個人，以有建設性的方式攜手合作，以利持續強化設計及實作。
下圖的程式碼路徑顯示如何按照差異化隱私的做法，執行跨裝置匯總及雜訊處理。
整體設計
要怎麼以機密的方式實現隱私保證？大體而言，由 ODP 編寫的政策引擎會在加密環境中執行，做為監控每個節點/子圖表的核心元件，同時也會追蹤輸入和輸出內容的 DP 狀態：
- 從政策引擎的角度來看，裝置和伺服器的處理方式相同。針對執行相同政策引擎的裝置和伺服器，只要政策引擎經過雙向認證，系統就會將這類裝置和伺服器視為邏輯相同。
- 在裝置上，系統會透過 Android 開放原始碼計畫的獨立程序來達成隔離作業。當可用性提高時，長期來說則會透過 pKVM 達成。而在伺服器上，隔離作業會仰賴「信任方」執行，也就是 TEE 加上其他偏好的技術加密解決方案和/或合約協議。
換句話說，只要是安裝及執行平台政策引擎的加密環境，都視為可信運算基 (TCB) 的一環。使用 TCB 時，資料可以在不加上其他雜訊的情況下傳播。而當資料離開 TCB 時，則須套用 DP。
裝置端個人化功能的整體設計，有效整合了兩個重要元素：
- 商業邏輯執行作業的配對程序架構
- 用於管理資料輸入、輸出和許可作業的政策和政策引擎。
這套一致的設計為商家提供了一個公平的競爭機會，讓其可在受信任的執行環境中執行專屬程式碼，並存取已通過適當政策檢查的使用者資料。
以下各節將深入探討這兩個重要面向。
商業邏輯執行作業的配對程序架構
裝置端個人化功能導入 Android 開放原始碼計畫中的配對程序架構，可在商業邏輯執行期間強化使用者隱私和資料安全性。這個架構包含：
ManagingProcess。這項程序會建立及管理 IsolatedProcess，確保其在程序層級獨立運作，且僅能存取已加入許可清單的 API，不具網路或磁碟權限。ManagingProcess 會處理所有業務資料、使用者資料和通過政策檢查資料的收集作業，產生業務程式碼並將資料推送至 IsolatedProcess 執行。另外，ManagingProcess 也會調解 IsolatedProcess 與其他程序 (例如 system_server) 的互動情形。
IsolatedProcess。這是指定的獨立程序 (在資訊清單中為
isolatedprocess=true)，會從 ManagingProcess 接收業務資料、通過政策檢查的使用者資料和業務程式碼。透過這些資料，業務程式碼可在其資料和通過政策檢查的使用者資料上執行。IsolatedProcess 僅會與輸入和輸出的 ManagingProcess 通訊，不具任何其他權限。
只要採用配對的程序架構，您就有機會對使用者資料的隱私權政策進行獨立驗證，而不必要求商家為其商業邏輯或程式碼提供開放原始碼。由於 ManagingProcess 可維護 IsolatedProcess 的獨立性，加上 IsolatedProcess 能有效執行商業邏輯，再再都讓這個架構確實提供了更安全有效的解決方案，進而在個人化期間保護使用者隱私。
以下是此配對程序架構的示意圖。
資料作業的政策和政策引擎
在平台和商業邏輯之間，裝置端個人化功能會導入政策強制執行層，目標是提供一套工具，將使用者和業務控制項對應至集中且可採取行動的政策決策。這樣一來，系統就能橫跨多個流程和不同業務，全面且可靠地強制執行這些政策。
在配對的程序架構中，政策引擎隸屬於 ManagingProcess 內，負責監控使用者和業務資料的輸入和輸出。政策引擎也會向 IsolatedProcess 提供加入許可清單的作業。適用領域的例子包括使用者控管、保護兒童安全、避免在未經同意時分享資料，以及企業隱私權。
這項政策強制執行架構包含三種可用的工作流程：
- 透過受信任的執行環境 (TEE) 通訊，在本機啟動的離線工作流程：
- 資料下載流程：受信任的下載內容
- 資料上傳流程：受信任的交易
- 在本機啟動的線上工作流程：
- 即時放送流程
- 推論流程
- 在本機啟動的離線工作流程：
- 最佳化流程：透過聯合學習 (FL) 實作的裝置端模型訓練
- 回報流程：透過聯合分析 (FA) 執行跨裝置匯總
以下是從政策和政策引擎角度切入的架構示意圖。
- 下載：1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
- 放送：1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
- 最佳化：2 (提供訓練計畫) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
- 回報：3 (提供匯總計畫) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
整體而言，在裝置端個人化功能的配對程序架構中，如果能導入政策強制執行層和政策引擎，就能確保打造獨立且保障隱私權的環境，以便執行商業邏輯並提供對必要資料和操作的受控存取權。
分層 API 介面
裝置端個人化功能可為感興趣的商家提供分層 API 架構。頂層包含專為特定用途建構的應用程式。如果可能的話，商家可以將資料連結至這些應用程式，又稱「頂層 API」。頂層 API 的建構位置在中層 API 之上。
我們預計日後會新增更多頂層 API。如果頂層 API 不適用於特定用途，或現有頂層 API 的彈性不足，商家可以直接實作中層 API，透過程式設計基元提供強大功能和靈活彈性。
結語
裝置端個人化功能是我們早期的研究提案，目的是吸引使用者對長期解決方案的關注和意見，以期透過預計能帶來高實用性的最新技術，解決使用者隱私權方面的疑慮。
我們希望與隱私權專家、資料分析師和潛在使用者等利害關係人合作，確保 ODP 滿足相關需求並解除他們的疑慮。