Update file deletion or corruption

As stated in section 3.5, if a server receives a request for Publius content that has an associated update file, the URL contained in that file is sent back to the requesting proxy. We now describe three different attacks on the update file that could be used by an adversary to censor a published document. In each of these attacks the adversary, Mallory, has read/write access to all files on a server hosting the Publius content P, he wishes to censor. In the first attack we describe, P does not have an associated update file. That is, the author of P has not executed the Publius Update operation on P's URL. Mallory could delete P from one server, but this does not censor the content because there are other servers available. Rather than censor the Publius content, Mallory would like to cause any request for P to result in retrieval of a different document, Q, of his choosing. The Publius URL of Q is Q_url. Mallory now enters Q_url into a file called ``update'' and places that file in the directory associated with P. Now whenever a request for P is received by Mallory's server, Q<sub>url</sub> is sent back. Of course Mallory realizes that a single Q<sub>url</sub> received by the client does not fool it into retrieving Q<sub>url</sub>. Therefore Mallory enlists the help of several other Publius servers that store P. Mallory's friends also place Q<sub>url</sub> into an ``update'' file in P's directory. Mallory's censorship clearly succeeds if he can get an update file placed on every server holding P. If the implementation of Publius only requires that k shares be downloaded, then Mallory does not necessarily need to be that thorough. When the proxy makes a request for P, if Mallory is lucky, then k matching URLs are returned and the proxy issues a browser redirect to that URL. If this happens Mallory has censored P and has replaced it with Publius Content of his own creation. This motivates higher values for k. The update flag described in section 4.1 is an attempt to combat this attack. If the publisher turned the update flag off when the content was published then the Publius client interpreting the URL will refuse to accept the update URLs for the document. Although the content might now be considered to be censored, someone is not duped into believing that an updated file is the Publius content originally published. In the second attack, P has been updated and there exists an associated update file containing a valid Publius URL that points to Publius Content U. To censor the content, Mallory must corrupt the update file on n-k+1 servers. Now there is no way for anyone to retrieve the file correctly. In fact, if Mallory can corrupt that many servers, he can censor any document. This motivates higher values for n and lower values for k. One other attack is worth mentioning. If Mallory can cause the update files on all of the servers accessed by the client to be deleted, then he can, in effect, restore Publius content to its previous state before the update occurred. This motivates requiring clients to retrieve from all n servers before performing verification. The attacks described above shed light on a couple of tradeoffs. Requiring retrievers to download all n shares and n copies of the document is one extreme that favors censorship resistance over performance. Settling for only the first k shares opens the user up to a set of corrupt, collaborating servers. Picking higher values for k minimizes this problem. However, lower values of k require the adversary to corrupt more servers to censor documents. Thus, k, the number of shares, and the number of copies of the page actually retrieved, must be chosen with some consideration.