Publius系统的信任与安全问题解析
1. Publius系统的审查问题
在Publius系统中，存在着文档审查方面的挑战。假设名为Eve的服务器管理员想要审查特定的Publius文档。她得知了该文档的Publius URL，且其服务器恰好存储着加密文档副本和相应的份额。
Eve若仅删除自己服务器上的加密文档，无法实现审查，因为该文档还存在于其他19台服务器上。要审查文档，需说服至少17位其他服务器管理员删除对应份额，使可用份额不足以形成解密密钥。不过，这种审查虽有可能，但难度较大，可视为Publius的一个小局限，也可看作一种“安全”特性，若多数服务器运营商认为文档有问题，可对其进行审查。
Eve及其同伙还尝试利用更新机制审查文档。他们在原加密文件和份额所在目录放置更新文件，其中包含Eve发布文件的Publius URL。Publius客户端收到URL后，会拆分URL确定存储加密文档和份额的服务器，随机选择3台服务器获取份额，并从其中一台获取加密文档。若3个份额请求都返回相同的更新URL而非份额，客户端会跟随更新URL获取相应文档。
从20台服务器中选3台有1140种方式，只有1种组合会导向Eve的文档，所以每次有人检索文档时，Eve及其同伙审查成功的概率仅为1/1140。随着参与其计划的服务器管理员增多，Eve成功的概率会上升。若多人检索具有社会意义的文档并发现差异，Eve可能会让整个检索过程受到质疑。
为应对更新攻击，发布者可指定文件不可更新，这会在Publius URL中设置标志，让客户端忽略服务器发送的更新URL；还可选择“不删除”选项，虽不能阻止服务器管理员删除文件，但可防止有人反复猜测删除文件的密码。此外，Publius URL会编