許多應用程式都依賴使用者資料來提供有用的功能。例如，瀏覽器遙測技術可以透過收集和彙總個人資料來識別網路錯誤或有缺陷的網站。然而，瀏覽歷程記錄可能很敏感，分享這些資訊會帶來隱私風險。有趣的是，這些應用程式通常對單個資料點不感興趣（例如，某一特定使用者在嘗試存取 Wikipedia 時是否遇到網路錯誤），而只關心彙總資料（例如，無法連線 Wikipedia 的使用者總數）。
分散式彙總通訊協定 (DAP) 允許在不洩露任何個人資料點的情況下彙總資料。對於資料收集器對總體趨勢感興趣但無法存取敏感性資料的應用程式來說，它非常有用。DAP 有很多用例，從 COVID-19 暴露通知到 Firefox 中的遙測，再到 iOS 中的個人化相冊等等。Cloudflare 正在協助標準化 DAP 及其底層原語。我們正在致力於 DAP 的開放原始碼實施，且正在構建一項與當前和未來合作夥伴一起執行的服務。查看這篇部落格文章，瞭解有關 DAP 工作原理的更多資訊。
DAP 在正確的方向上邁出了重要的一步，但僅靠私人彙總往往不足以保護隱私。在本篇文章中，我們將解釋 DAP 的不足之處，以及如何透過增加差分隱私來改進 DAP。
問題：私人彙總並不足夠
DAP 使用一種稱為_多方運算_的加密技術。在高層，多方運算透過將彙總計算分配給多個伺服器來提高隱私性，這樣任何伺服器都不會看到任何個人的資料。（有關多方運算的入門知識，請參閱我們之前關於 DAP 的部落格文章。）乍一看，這似乎應該足以保護每個單獨使用者的隱私：資料收集器僅瞭解其_需要_的資訊（即 ，彙總資訊），而不是用於計算它的基礎資料。不幸的是，情況往往並非如此，因為彙總資訊本身有時會洩露大量私人資訊。
8 英尺 11.1 英寸（2.72 公尺）高的羅伯特·瓦德洛 (Robert Wadlow) 擺姿勢拍全家福，1939 年。圖片來源：Paille // CC BY-SA 2.0。
舉一個簡單的例子，假設有一組數字，其中所有的值都相等，那麼計算這一組數字的平均值，即可得出這一組數字中每個數的值。但是，知道一些數字的總和也可以得出這一組數字中是否存在特別大或特別小的數字。例如，假設我們正在計算一群人的平均身高。如果這群人中的某個成員特別高（如上圖所示），那麼知道這群人中有多少人以及預期的平均身高，我們就可以推斷出有關該人身高的大量資訊。
更普遍地說，如果發佈太多有關一個資料庫的精確彙總資料，則可能使得攻擊者能夠重建整個資料庫。
這種攻擊在現實生活中是存在的。例如，針對美國人口普查的去匿名化攻擊已經得到了可靠的證實。大型語言模型（如 ChatGPT）也很容易受到攻擊；機器學習模型可以看作是在訓練資料集上運算的一種特殊類型的統計集合。下面是一個攻擊範例，研究人員給 GPT-2 下達了一條特殊指令，提取了一個真實個體的姓名、地址和電話號碼，而這個個體的資料在訓練資料集中只出現過一次：
圖 1 摘自「Extracting Training Data from Large Language Models」（從大型語言模型中提取訓練資料），USENIX Security ‘21，https://arxiv.org/pdf/2012.07805.pdf。
保護模型訓練輸入的一種方法是稱為_聯合學習_的技術，其中資料保存在終端使用者裝置上，模型更新由中央伺服器彙總。（彙總步驟甚至可以在 DAP 中完成。）然而，即使這些系統也容易受到巧妙攻擊的影響，此類攻擊可以利用最終模型以及一些中間版本來重建敏感性資料。
我們用下圖來說明這一想法，該圖來自最近的一篇論文，描述了對正在進行影像分類訓練的機器學習模型的攻擊。在此範例中，我們從 8 個使用者開始，每個使用者都有一個帶標籤的影像（例如，一張被標記為「貓」的貓的影像）。這些起始影像被稱為_基本事實_。每個使用者都讓他們的影像通過影像分類模型，看看它是否可以準確地標記照片中的內容。當模型失敗時，它會產生模型更新——一組資料，告訴模型如何自我改進，以便下次更可靠地識別該使用者的照片。
所有八個使用者都在本地產生自己的模型更新，然後使用聯合學習來提取這些模型改進的平均值，這種方式表面上是為了避免提取任何單獨的更新或照片。不過，研究人員能夠利用這種方法。
攻擊的目標是在只能存取聯合的平均更新的情況下，重建圖中最下面一行的 8 個基本事實影像。攻擊者從隨機猜測（「初始」）開始，並逐步改進猜測，使其更新方向與真正的平均更新相似。經過足夠多的反覆運算後，我們看到攻擊者猜測（「完全洩露」）中的影像與真正的基本事實資料集中的影像接近，儘管順序可能不同。
圖 4 來自「Deep Leakage from Gradients」，NeurIPS ‘19，https://arxiv.org/pdf/1906.08935.pdf。
這些攻擊表明私人彙總（使用 DAP 或透過其他方式）不足以保護隱私。幸運的是，有一條前進的道路：包括 Apple、Google、美國人口普查局以及越來越多的產業和政府參與者在內的各種組織現在都在使用差分隱私來保護他們的資料。
差分隱私
差分隱私 (DP) 是一種統計框架，可為安全彙總系統提供額外的資料保護層。它會向彙總資料新增干擾資訊，防止攻擊者過多地瞭解任何個人的資訊。粗略地說，隨機新增的量與隱私參數成反比，隱私參數通常用希臘字母 𝜖（發音為「epsilon」）表示：小 𝜖 值表示隱私性更強，但結果有干擾資訊，而大 𝜖 值表示隱私性較差，但更準確。透過這種方式，𝜖 嚴格量化彙總資料所揭示的資訊量。
平心而論，即使沒有差分隱私，一些對敏感性資料集進行計算統計的部署也已經透過施加某些限制來防止最公然的隱私侵犯。例如，DAP 有一種機制，可以防止資料收集器彙總過小輸入批次。在其他情況下，當某些屬性在資料集中不常出現時，可以對其進行編輯，或者限制資料點的彙總次數。不過，這種臨時性的隱私保護措施很容易對資料做出無效的假設。
首先，這些限制本質上是針對一些明顯攻擊的「修補」，但不一定涵蓋所有可能的攻擊。例如，某些彙總任務對異常值特別敏感，但仍然可能洩漏特別不尋常的測量值是否是彙總集的一部分。此外，雖然簡單的彙總（例如總和）更容易透過自訂規則來保護，但多維和結構化統計資料（例如（平均）神經網路更新）可能會洩漏大量資訊，如上一節所示。相反，差分隱私是一種通用屬性，可以保護複雜的統計資料，甚至可以抵禦我們一無所知的對手。
其次，差分隱私的另一個好處是它可以協調跨應用程式的安全參數：隱私保證表示為 𝜖 的特定值，可以在從位數到聯合學習的用例之間進行比較。𝜖 的值也可以公開傳達或與 DP 專家討論。雖然設定 𝜖 仍然是一件複雜的事情（見下文），但它至少比設定參數（例如要彙總的測量值數量）更少依賴于應用程式。事實上，差分隱私參數構成了一個額外的自由度，它將隱私與其他特定于應用程式的參數分開，從而更好地控制實用性和隱私之間的權衡（例如，可以先修復 𝜖，然後再獨立決定彙總任務的批量大小）。
最後，大多數人工設計的保護和匿名技術無法提供與差分隱私相同的優雅和實用屬性。例如，當多組報告相互關聯時，或者當相同的基礎資料被多次彙總時（這在聯合學習等某些應用程式中至關重要），DP 可以保證柔性降級，而臨時方法或 k 匿名 (k-anonymity) 等定義在這些情況下可能會災難性地失敗。DP 還具有其他可取的屬性，例如抵禦邊資訊的能力（例如，一些現實生活中的隱私攻擊可能會利用從資料經紀人處購買的資料集）。
從根本上說，差分隱私將隱私工程的貓捉老鼠遊戲轉變為嚴格的數學框架，在該框架中，隱私得到證明，而不僅僅是聲稱。
隱私工程科學：使 DAP 具有差異性隱私
作為 Cloudflare 的實習生（2023 年夏季），我的任務是設計一種賦予 DAP 差分隱私的策略，同時針對我們將在本文中探討的 Cloudflare 的一些 DAP 用例進行最佳化。有很多方法可以做到這一點。我們重點介紹三種技術，它們具有不同的威脅模型：
最簡單的方法是照常計算彙總，然後新增干擾資訊。DAP 通訊協定定義了一個稱為「收集器」的角色，其是彙總結果的預期接收者。收集器本身可以新增干擾資訊（我們可以將其稱為收集器隨機化或 Central DP）。當然，問題是從收集器的角度來看，彙總結果不是 DP。
另一種方法稱為 Local DP（或 DAP 上下文中的用戶端隨機化），要求每個用戶端在提交報告之前新增干擾資訊。這提供了強有力的隱私保證（即使所有彙總器和收集器都是惡意的，DP 仍然有效），但通常會犧牲準確性。這是因為為了實現隱私，必須在每個測量值中新增更多干擾資訊。不過，最近的進展使得此類通訊協定在某些情況下變得實用。
DAP 涉及另一個稱為「彙總器」的角色，它計算彙總結果的一部分。（將各彙總器的份額合併即可得到彙總結果。）作為中間方案，我們可以讓每個彙總器向其彙總份額新增干擾資訊，從而確保從收集器的角度來看彙總結果是 DP。當然，我們必須相信至少有一個彙總器是誠實的，並且會透過正確的分配新增干擾資訊。
第三種方法，我們稱之為彙總器隨機化，是在我實習期間大家決定研究的方法。它實施起來很簡單，計算開銷與基本 Central DP 大致相同，並且滿足與 DAP 相同的威脅模型（稍後會詳細介紹！）。彙總器隨機化如下圖所示。
儘管我們的 DAP 彙總器隨機化版本看起來很簡單，但我們需要確信它提供了我們期望的隱私保證。這意味著要寫下通訊協定，並對其保證進行正式分析。
有趣的是，DP 的傳統定義和標準證明技術並不立即適用於我們的設定。事實上，與大多數 DP 機制不同，DAP 是一種互動通訊協定，涉及分佈在網際網路上的許多方（用戶端、彙總器、收集器），其中一些可能是惡意的。此外，DAP 的安全性基於計算假設（我們假設如破解 AES 之類的某些加密問題成本高昂），其中考慮了可能在「合理」時間內執行的對手。DP 的標準概念考慮了具有任意執行時間的對手。
幸運的是，過去已經研究過將差分隱私與多方計算相結合的其他通訊協定，而且在計算差分隱私**的大框架下也有合適的定義。**DP 的這一定義使我們有可能模擬一個計算受限的對手與現實世界中包含加密元件的通訊協定進行交互。然而，我們還需要做更多的工作，才能建立一個通用框架，將 DP 機制與現有的 DAP 副程式（具有經過證明的安全保證）組合起來。
範例：將網路錯誤記錄設為私有
為了使問題具體化並獲得一些實驗資料，我們尋找了現實生活中的 DAP 使用案例，在這些案例中，差分隱私可能有用，並且可以立即應用。考慮一種通訊協定，它可以私下彙總用戶端連線錯誤並報告給源站，作為網路錯誤記錄 (NEL) 的隱私保護替代方案。對於 DAP 而言，這是一個很好的用例，因為收集彙總統計資料（例如，特定網域的 tcp.timed_out 的錯誤數量，或過去 24 小時內錯誤最多的網域）是可取的，但個人報告可能會洩露有關瀏覽習慣的敏感資訊。
為簡單起見，讓我們重點關注網域清單已知的情況，例如，追蹤單個網域或一組封閉的付費客戶的連線錯誤。對於本部落格文章的其餘部分，您可以假設我們正在使用 DAP 部署來計算單個網域的連線錯誤長條圖（但 DAP 規範中的其他統計資料也具有相同的結構，因此適用於類似的 DP 機制 ）。真正的彙總資料可能看起來像這樣：
從圖中我們可以看到 1000 份報告中典型的錯誤分佈情況。實際錯誤類型無關緊要，因此這裡只用數字表示。error_type = 8 是目前最常見的錯誤類型，但我們也觀察到一些其他錯誤類型。
正如我們前面所看到的，這種彙總資訊仍有可能洩露敏感資訊——例如，如果一種錯誤類型只出現一次，我們就有可能知道某個使用者是否存取了某個網站。現在，我們的目標是修改 DAP，以輸出一個略帶干擾資訊的長條圖版本，這樣就不會洩露單個報告的資訊了。
libprio-rs 是 DAP 中使用的加密原語的廣泛使用的 Rust 實施。為了增加 DP，我們首先設計一個任何彙總器隨機化方案都應滿足的通用 API，並使用物件來表示隱私預算和干擾資訊新增。然後，我們為具體的統計彙總實施了 DP API。在回顧了各種 DP 機制之後，我們選擇了離散高斯 (discrete Gaussian) 和離散拉普拉斯 (discrete Laplace) 機制，因為它們有明確的保證並且適合模組化環運算。我們利用 OpenDP 庫用 Rust 編寫的安全干擾資訊採樣器。在對 DAP 的 Daphne 實施進行調整後，我們能夠在網路錯誤記錄資料上執行具有差分隱私的 DAP 玩具部署！
隱私工程的藝術：探索隱私效用權衡
回想一下，差分隱私涉及一個參數 𝜖，它決定了我們的系統所能達到的隱私程度。從代碼的角度來看，任何正實數都是有效的選擇：越小越私人，但也越無用。那麼，我們應該如何選擇 𝜖 呢？
到目前為止，我們已將 DP 工程視為一門科學，但選擇 𝜖 在某種程度上仍是一門藝術。為了說明這一點，讓我們回到 NEL 資料，計算一個網域上網路錯誤的 DP 長條圖。以下是 𝜖 不同值的干擾資訊長條圖：
我們觀察到，減少 𝜖 會產生包含更多干擾資訊的結果，甚至在某些情況下給出負計數——儘管我們始終可以在不失去隱私的情況下截斷或舍入結果。由於此範例有許多報告和一些可能的錯誤，因此很容易掩蓋任何單個人的資料。在這裡我們可以看到，𝜖 = 1 似乎是這個用例的合理選擇。我們仍然可以觀察到，罕見事件（例如 error_type = 15）的相對誤差高於常見錯誤（例如 error_type = 8）的相對誤差。
讓我們重點觀察這兩個事件，看看 𝜖 如何影響準確性：
越來越明確的是，準確性會隨著 𝜖 值的增加而增加——干擾資訊較少的彙總結果更不隱私，但更加準確。這種權衡被稱為隱私效用權衡。您可以注意到，權衡取決於我們測量的內容。如果我們只對 error_type = 8 感興趣並且最多可以容忍 2% 的相對誤差，那麼使用 𝜖 = 0.01 就足夠了。如果我們對 error_type = 15 感興趣，那麼我們需要使用 𝜖 = 0.1 才能達到相同的準確度水準。
我們還可以查看其他參數（如批次大小）如何影響固定隱私保證的準確性：
直觀地說，如果我們在計算彙總結果之前等待更長的時間，我們就能在相同的隱私層級下得到更準確的結果，因為如果一份資料被淹沒在一大批資料中，就更容易被掩蓋。如前所述，我們可以預先設定隱私層級，然後再調整彙總參數。如果我們試圖針對大小為 1 的批次收集彙總資料，那麼 DP 結果將接近隨機，從而保護該批次中單個報告的值。在準確性特別重要的應用中，這種柔性降級（針對小批次輸出無用的結果，而不是破壞隱私）可能會成為一個問題，但可以透過選擇一個滿足準確性和隱私性之間舒適權衡的 𝜖 來控制。如果我們願意付出隱私代價，則始終能夠獲得更準確的結果。
這讓我們回到了這個問題：對於 𝜖 而言，怎樣算是一個不錯的值？不幸的是，正如 Cynthia Dwork（DP 發明者之一）、Kohli 和 Mulligan 在 2019 年發表的論文中指出的那樣，專家們仍未就決定 𝜖 值的正確方法達成共識。事實上，𝜖 的某些值適用於某些部署、演算法、資料集或威脅模型，但不適合其他部署、演算法、資料集和威脅模型。與迫使攻擊者猜測可能具有 2^128 個值的金鑰的加密應用不同，𝜖 必須設定為某個不可忽略的值才能從資料中瞭解到有用的資訊。歸根結底，是否有用以及怎麼樣會造成隱私損害取決於應用。
在我們有更好的理解之前，對於非專家來說，一個簡單的方法是搜尋類似應用中使用的「標準」𝜖，並在隱私約束下最大限度地提高準確性。如果我們可以存取「𝜖 註冊表」（針對各種用例和威脅模型的詳細部署清單），那麼這種方法就能奏效。美國人口普查局有一個內部註冊表，但到目前為止只發佈了一些用例。NIST 在這篇非正式部落格文章中給出了一些建議範圍（tldr：0 < 𝜖 < 5 是強值，5 < 𝜖 < 20 在實踐中可能已經足夠）。這篇部落格文章列出了 Apple、Google 和其他公司部署的 𝜖。
還有其他策略可用於設定或評估 𝜖 的經驗保證。一種補充方法是確定您願意接受的最大誤差（例如計數上 5% 的相對誤差），利用標準 DP 機制的簡單屬性找到 𝜖 的相應值，並檢查它是否在可接受的範圍內。
結論
隨著 DAP 等安全彙總通訊協定越來越多地部署在現實世界的應用中，我們必須記住，安全彙總並不總是能滿足使用者對隱私的期望。差分隱私為這些通訊協定增加了一層額外的保護。簡而言之，安全彙總保護「方式」（如何根據一組報告計算彙總結果），而 DP 保護「內容」（我們應該發佈什麼樣的含干擾資訊彙總結果以避免洩漏過多資訊）。
得益於越來越多的開放原始碼實施、應用研究以及針對差分隱私和安全彙總的標準化工作，現在有了一條整合 DP 和 DAP 的清晰路徑，從而加強了實際測量任務的隱私保證。有趣的是，在分析過程中，我們發現 DAP 通訊協定的某些部分可能會對某些形式的 DP 保證造成問題，例如彙總器可以存取測量次數或用戶端的 IP 位址。這些發現以及對通訊協定邏輯的更多思考，促進了 IETF 圍繞這一主題和其他主題的討論。
我們還發現了許多在 DP 文獻中經常被忽視的細節，如模組化運算、API 考慮、安全採樣或定時攻擊。總之，密碼學專家和差分隱私專家之間可以就能產生實際影響的通訊協定開展富有成效的合作。
如果您對差分隱私、DAP 或 Cloudflare 的其他隱私專案感興趣，可以考慮申請研究團隊的實習機會。
特別感謝
我要感謝我出色的導師 Christopher Patton 在整個夏天對我進行了指導，從加密細節到 IETF 標準，我學到了很多東西，並且一路上獲得了很多樂趣。感謝 Josh Brown 和 Tanya Verma 與我們的討論，感謝 Avani Wildani 和研究團隊其他成員的大力支援！