+++ This bug was initially created as a clone of Bug #224692 +++ Given by bug 224692 comment 92 the encryption properties from the parent folder aren't inherited when downloading a file. That happens because after the download completes, the file is being moved from the download temp directory and the encryption properties aren't updated. Steps to Reproduce: 2. Create a folder on the same partition where the temp directory resists (should be an encrypted volume) 2. If not done yet, add the encrypted flag in the folder properties. 3. Download a file to that directory and see that it doesn't inherit the setting.

Somewhat related: You can't download files to a partition that doesn't support encryption if your Temp directory is encrypted. This is presumably because the downloaded file in the Temp folder is encrypted, but when Firefox tries to move it, Windows throws up an exception. Steps to Reproduce: 1. Encrypt your temp directory (e.g., my whole profile directory is encrypted, with inherit) 2. Download a file to a non-encryptable drive (e.g, FAT32, or a Samba share in my case) 3. Firefox throws the error: X:\file.ext could not be saved, because an unknown error occurred. Try saving to a different location.

Confirming this bug (downloaded files not encrypted) for Firefox 3.5.1 and SeaMonkey 2.0b1 on German Windows XP SP3.

The .part file is never encrypted. When the .part file is moved to the final filename overwriting the 0 byte placeholder file, the file is still not encrypted. The .part should be encrypted at all times to prevent leaking of sensitive data. Also, this is a serious issue, and puts Firefox in violation of several corporate security policies.

So is this happening because the .part file is initially created in a different directory, one that's not encrypted?

Unlikely. I haven't looked at the code, but my guess is that firefox sets special permissions on the .part file when it is made, overriding the inherited permissions from the directory (possibly to set the file as readonly/etc). If I remember right, in windows, you actually have to get an ACL object representing the file permissions and manipulate the permissions manually on it, and then pass that object in to the function when you create the file.

Boris is correct in Comment 6. The encryption (and compression) defaults are inherited at creation time from the file's parent directory with NTFS volumes in Windows. We use the user's temp directory for the .part file before moving it to the download location. We could set the encryption [1] or compression [2] after the file is downloaded, but this can be a lengthy blocking operation without using overlapped IO. And people typically want to use the downloaded file right after it is downloaded anyway. The temp dir and the destination dir may be of different filesystems too and hence diff encryption and compression capabilities. So doing it beforehand wouldn't always be possible. Doing it after would probably cause jank. I'm not sure of the history on why we don't just create the .part file in the destination directory and then rename to the destination path in the same directory. If we did that we could also remove the code from Bug bug 224692 in nsLocalFileWin. I think we just do it because that's how the channel code works with nsExternalAppHandler by calling nsExternalAppHandler::SetUpTempFile. [1]: To encrypt the file, you can do it at creation time w/ the FILE_ATTRIBUTE_ENCRYPTED flag to CreateFile. You can also do it after, but it is extra IO and time with EncryptFile. We can also use the hTemplateFile parameter and probably pass in a handle to the destination directory. [2]: You can compress a file after it is created with a call to DeviceIoControl w/ FSCTL_SET_COMPRESSION. You can't set a file in a compressed state from the CreateFile call other than when it is inherited from the parent directory. There is no CompressFile API but the IOCTL call is equivalent.

> I'm not sure of the history on why we don't just create the .part file in the destination > directory The cases when we create the .part file are the cases when we start downloading due to receiving a response we can't handle internally. Historically, what we would do then is prompt the user asking what to do, and keep downloading to the .part file. Once the user picked "save" and the destination (note that before this we don't know the final destination!) we move the .part file there and keep writing to it. If we now have cases when we know the download destination up front, I see no reason to not create the .part file directly there.

Makes sense thanks for the history there. There are 2 cases that we create the .part file. 1) The user right clicks and selects save as... and he can then select the location. In this case as you said we don't know the destination path. 2) The user clicks on a file like say a .zip file and he can then open it or save it. In that case we do know the final destination before the dialog is shown and the user can't change it.

Maybe people would see it as a bug though if open file saved the file to the destination directory directly in #2 though :(

Yeah, we definitely used to show a filepicker in case #2 back when the exthandler code was written. And of course it's not clear to me that we want to put the temp file used when opening with an app in the Downloads directory. Is that what comment 11 was about?

No in Comment 11 I meant that if you select Open file then we don't move the file to the destination folder at all, we run it from the temp directory instead. Also I just remembered there is a preference for always asking where to save to, so looks like we can't rely on knowing the dest dir in any of the 2 cases. I think to fix this we should add the ability to get the encryption status and compression status of a file inside nsLocalFileWin and then also add functions to compress and encrypt. And we would call those from a different thread after they are downloaded from the download manager.

or just leave it as is

If you compress the temp directory, downloaded files are still not saved in compressed format.