全文
隐私承诺先指定保护对象
原收录的 L2BEAT 方法页目前重新导向 ETHBEAT，页面以五种对手区分隐私评估。阅读这类框架时，第一个问题不是某项工具是否「有隐私」，而是它要隐藏哪个栏位，以及防止谁得知这个栏位。收款人、金额与行为连结可以有不同结果。
例如一个系统可能让一般浏览者看不到交易金额，服务端却仍知道请求来自同一个帐号。这两个叙述可以同时成立。若产品把不同层次压成一个绿色图示，读者就难以看出保护范围与自己实际需要的差距。
加密内容仍会留下使用模式
以下是假设情境：使用者每天固定时间送出请求，稍后另一个帐户总在相近时间收到结果。即使内容本身不可读，时间和次数仍可能形成可比对的模式；这只是说明相关性，不代表观察者已能确定两者属于同一人。
要判断这种线索有多强，必须看还有多少其他合理候选者，以及观察者能接触哪些资料。相同的时间差，在热闹服务和几乎无人使用的服务上可能意义不同。因此，隐私不只是演算法性质，也受到实际使用情境影响。
服务交付方式也是保护边界
使用者与协议互动通常经过介面、网络请求及资料服务。即使底层设计保护某些栏位，应用程序仍可能在登入、查询或错误回报时送出额外信息。评估时需要把这条路径画出来，确认每一方实际取得的内容。
举例而言，只问某服务是否保存交易正文，可能忽略它保存了帐号与查询时间。这不等于指控任一服务搜集资料，而是说明应用层资料清单的重要性。清楚的保存期限、权限分工与可验证行为，比笼统宣称不追踪更有助于判断。
评级需要附带假设与时间
一项评级应绑定被检查的版本、使用方式与对手能力。软件更新、更换服务商或使用者重复使用识别信息，都可能改变原先的条件。对未来攻击者的讨论也应列出具体假设，不能把「尚无已知攻击」改写成永久安全。
本文的编辑判断是，最实用的隐私介绍应让读者找到自己的威胁情境，再看到对应栏位的保护与缺口。这个框架可协助整理问题，不能替代特定产品的实际审查；原来源的网站转址，也应透明保留，而非假装来源名称与位置从未改变。