Update

Our system provides a mechanism for Alice to update something that she previously published. We use the same password mechanism that is used to delete content. Thus, Alice can change any web page that she published, but nobody else can. The idea is to enable Alice to change content without changing the URL, because others may have linked to the original site. After the update, anyone retrieving the original URL receives the new content. In addition to file, share, and password, there is a file called update on the servers in the name_i directory. Initially, if Alice has not updated the content, the file does not exist. When Bob retrieves the URL, if the update file is missing, everything proceeds as described in Section 3.3. To update the content, Alice specifies a file name containing the new content, the original URL, the original password PW and a new password. The update program first publishes the new content by simply calling publish with the file name and the new password. Once the new content is published, the original URL is used to find the n servers that host the Publius content. Each of these servers receives a message from Alice (a call to a CGI script) containing the original password stored on that server (recall that this is ), the old name_i, and the new URL. Each server then places the new URL in the update file and deletes the contents in the old file. When Bob retrieves Publius content, if the update file exists, the servers return the update URL instead of the contents. Bob receives the update URL from k servers and compares them, if they are all equal, he then retrieves the new URL instead. Of course, Bob is not aware of what the retrieve program is doing behind the scenes. From his point of view, he makes a request and receives the web page. If the k URLs do not match, Bob (his proxy) then tries the other n-k servers until he either gets k that are the same, or gives up. In Section 5 we discuss other ways this could be implemented and several tradeoffs that arise. Although the update mechanism is very convenient it leaves Publius content vulnerable to a redirection attack. In this attack several malicious server administrators collaborate to insert an update file in order to redirect requests for the Publius content. A mechanism exists within Publius to prevent such an attack. During the publicaton process the publisher has the option of declaring a Publius URL as nonupdateable. When a Publius client attempts to retrieve Publius content from a nonupdateable URL all update URLs are ignored. See Section 4.1 for more information about nonupdateable URLs.