全文
隱私承諾先指定保護對象
原收錄的 L2BEAT 方法頁目前重新導向 ETHBEAT，頁面以五種對手區分隱私評估。閱讀這類框架時，第一個問題不是某項工具是否「有隱私」，而是它要隱藏哪個欄位，以及防止誰得知這個欄位。收款人、金額與行為連結可以有不同結果。
例如一個系統可能讓一般瀏覽者看不到交易金額，服務端卻仍知道請求來自同一個帳號。這兩個敘述可以同時成立。若產品把不同層次壓成一個綠色圖示，讀者就難以看出保護範圍與自己實際需要的差距。
加密內容仍會留下使用模式
以下是假設情境：使用者每天固定時間送出請求，稍後另一個帳戶總在相近時間收到結果。即使內容本身不可讀，時間和次數仍可能形成可比對的模式；這只是說明相關性，不代表觀察者已能確定兩者屬於同一人。
要判斷這種線索有多強，必須看還有多少其他合理候選者，以及觀察者能接觸哪些資料。相同的時間差，在熱鬧服務和幾乎無人使用的服務上可能意義不同。因此，隱私不只是演算法性質，也受到實際使用情境影響。
服務交付方式也是保護邊界
使用者與協議互動通常經過介面、網路請求及資料服務。即使底層設計保護某些欄位，應用程式仍可能在登入、查詢或錯誤回報時送出額外資訊。評估時需要把這條路徑畫出來，確認每一方實際取得的內容。
舉例而言，只問某服務是否保存交易正文，可能忽略它保存了帳號與查詢時間。這不等於指控任一服務蒐集資料，而是說明應用層資料清單的重要性。清楚的保存期限、權限分工與可驗證行為，比籠統宣稱不追蹤更有助於判斷。
評級需要附帶假設與時間
一項評級應綁定被檢查的版本、使用方式與對手能力。軟體更新、更換服務商或使用者重複使用識別資訊，都可能改變原先的條件。對未來攻擊者的討論也應列出具體假設，不能把「尚無已知攻擊」改寫成永久安全。
本文的編輯判斷是，最實用的隱私介紹應讓讀者找到自己的威脅情境，再看到對應欄位的保護與缺口。這個框架可協助整理問題，不能替代特定產品的實際審查；原來源的網站轉址，也應透明保留，而非假裝來源名稱與位置從未改變。