Hi Bil, > > My motivation for deleting the file retrieval > > session record was that the extended hostname is > > recorded in the browser history. So if the user > > neglects to log out, and is using a laptop, and > > the laptop is stolen (even if turned off), the > > thief can access the file from the history until > > the login session times out. > > Is the thought that once downloaded, the user is storing the file > securely on the hard drive? If not, then I think the attacker will simply > lift the file off the laptop rather than trying to re-download the file > again. Well, the user could have deleted the file. But you're right, the file is likely to be in the stolen laptop. If the browser displayed the file and the user takes no precautions, the file should be in the browser's cache. To tell you the truth, the original motivation was just that it's not a good idea to have a valid authentication token (the file retrievel session ID) embedded in a URL. The stolen laptop scenario was an afterthought. (There is also a more exotic scenario: the attacker reads the authentication token from the user's computer display, as it is shown in the address box of the browser. These days, with a camera phone, the attacker does not have to be James Bond to pull that off.) In any case, I do think now that the file retrieval session ID must remain valid while the login session is valid, in case the browser issues multiple requests for the same file. Actually, I think there may be another case where a browser may issue multiple requests (besides the case where a large file download is interrupted), namely to implement sniffing. A browser may download an initial portion of the file to determine its type, and then download the rest. It's not clear to me why a second request would be needed to download the rest, rather than just continuing the download; but I think I remember seeing some version of IE issue a second request, when downloading MS Office documents. Francisco