How do you make sure a pdf is deleted after being viewed in the browser?

Question

For things like images or html documents, cache headers make sure that the data is deleted when the browser is closed. However as PDFs are opened in a plugin, the cache headers do not seem to have the intended purpose. PDFs are often left behind in the temp folder on windows machines.

Are there any cross-browser ways of making sure they are removed from the computer?

The scenario is that I have some files on a server accessible via the Internet, and expect that users may read them on shared and/or publicly-accessible computers. I don't want copies of these files left behind on such systems, and can't trust/expect the end-user to clean up after themselves.

Answer 1

For things like images or html documents, cache headers make sure that the data is deleted when the browser is closed.

Mr Unscrupulous Ninefingers the cybercafé owner has just recompiled Firefox to make it totally ignore cache directives.

My point being you cannot necessarily trust the client side to actually implement properly any of the protocols to which it should conform. Mostly, this is just because the developers felt it was unnecessary and the software is say 98% conforming, but it could be done maliciously.

The scenario is surfing on a shared computer where you don't want to leave behind documents, yet you cannot expect the user to delete the temp-folder themselves.

The honest answer is that if it is important that your files are not on that computer, don't put them there in the first place. At all. Ever. Use a laptop with an encrypted hard disk and an encrypted VPN via free wifi so that the data is both protected at rest and in motion, assuming it might not get deleted.

I should also point out that deletion does not guarantee removal of the data. Literally, it means the entry of that file in the filesystem has been dropped so that the filesystem will happily overwrite it. Stopping the operating system immediately following your access and examining the hard disk would with a fairly high probability of success give me that file.

Edit: I would like to make some additional points regarding client side access:

• A live cd image (on an actual CD) might help here. Once created, it cannot be modified except as it runs, so that pushes potential attack attempts to some form of pre-boot intercept, which makes any attack much more difficult. Clearly, however, there is an obvious downside: you need access to the appropriate network configuration information (subnets, proxies etc). Your local cyber cafe may not appreciate this. Another company's corporate network definitely won't.
• Proxy servers. Unless you access this over a trusted, encrypted channel, a proxy server could well cache your document and still pass you the delete request, deleting the content from the client but not the proxy.
• If you trust the shared workstation, i.e. it is part of your corporate network, I'd use another means to ensure this. No local storage would help, since then even physical access to the workstation isn't going to be of any use.

If your aim is just to remove the pdf, I can't really help. I've no idea how you'd do that. I'm not entirely sure how responses containing pdf files behave given http cache headers. However, I do think that even if I knew a way, it wouldn't represent security in the sense that it does not give you any real level of assurance as to the integrity of that file. Even if you encrypt the pdf, you must still ensure that your environment is free from key loggers and that the reader software you have installed can be trusted to decrypt the passwords without reasonably being subverted.

Answer 2

I'm guessing that you're talking about the no-store HTTP header. See RFC2616 (emphasis added):

14.9.2 What May be Stored by Caches

no-store

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation. The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.

So while using them may help in many circumstances, as @ninefingers already noted you just don't have control over what the client does with them. I'm guessing that it is pretty hard for a browser to even try to enforce it on content like pdf which is passed along to other programs for rendering.

Answer 3

As pointed out by NineFingers and nealmcb there's nothing you can do to reliably ensure that any content transferred to a browser and its plugins is not cached. The caused may not even be malicious since in many bandwidth limited environments proxy admins change or ignore caching headers in an attempt to reduce bandwidth usage.

If you can't control what happens on the client in a useful way the answer is then to move the function to the server. There is some good (if dated) discussion on viewing PDFs without a reader plugin at http://news.ycombinator.com/item?id=814642 and options for building a server side viewer, Flash viewer or Java applet viewer exist for most web development stacks.

If the viewer is transferring data via the browser it will leave something behind in the cache but some of them will be far harder to reassemble than others. Flash apps and signed applets can connect directly to servers so they will be able to avoid this (firewalls and proxies in the client environment permitting). If your concern goes beyond just PDFs you may want to look at embeddable RDP or VNC clients.