I am a new Premium BW Individual user and I was trying out the new features. I was testing out the ‘Send File’ and I submitted a file and everything seemed fine. This is the information on the file from the Firefox BW addon ‘Send File’ Edit screen:
I then got the link that one would send off to a person to allow them to download the file. I started out trying it in my default browser- Firefox. I was puzzled by the results so I tied it using Chrome and MS Echo and the embedded screen capture shows the names of the downloaded file.
I have no explanation as to why there is no file name (only the extension) for Firefox. (This might require some investigation on my part.) Now, notice the file names for both Chrome and MS Echo downloads and compare them to the file name of the file that I uploaded!
This presents a real serious issue that any security conscience person would question. I tell the recipient to expect a file with a given name and he/she gets one with a completely different name. Any security expert would tell them never to open the file!
I feel that this is a serious flaw that needs to be addressed. Even if I did something wrong in creating the send file process, it should have been flagged and notice given to me about this situation.
PS: I have looked at all of the files and each one is the correct file.
Obviously, clicking on the Download file button will start the download. Again, note that it is indicating the name of the file that is to be downloaded!!!
A bit of digging shows this isn’t something we’re missing – it’s a result of the fact that we must download an encrypted file locally and then serve it as a blob. javascript - Custom name for BLOB URL - Stack Overflow
The url and resulting guid-like filename is actually a reference to the location in memory the blob is stored. I do not see a way of alerting browsers of a more appropriate filename after opening the blob location.
@mgibson323, I just tested a .jpg file and that worked properly! So your explanation (Don’t quite understand it but that is not really important…) seems to the case.
Might I assume that this will be addressed in a future release and how long until we see the fix in place?
I decided to try a workaround. I added a dummy extension onto a .pdf file as did a file send. This is what the Download link looked like in Firefox:
As you can see, the workaround does work after a fashion. The download done with Chrome came through with the file properly named. (The “(1)” was added by Windows since there are now two copies of the file in that folder-- the original one and one downloaded by Chrome.) The Firefox one is a real head scratcher! It tossed the dummy extension (.RemoveMe) and added a second .pdf.
Is this a problem that is just restricted to PDF files or is it applicable to a wider range of range of files types?
Lol, yeah Firefox must be using some file-level mime-typing and detects the file should be saved as a pdf. On our side, we’re just behaving differently depending on the extension. .pdfs are opened in a new tab (resulting in the issue) and all others are downloaded.
As for a fix… Hmm. In a way it’s not something we can fix directly. Browsers would need to change the way they behave around this. That’s unlikely for security reasons.
The potential application-level workaround for us would be to provide two download options for PDFs – one that opens it in a new tab and one that directly downloads it, with the appropriate file name. I can’t promise that workaround being implemented, but it’s the way I would advocate doing it right now.
As an alternate workaround, you can also choose to print the pdf to a file rather than download it and select a name for it at that time. As you point out, the proper file name is available on the Send’s Access page.
Currently the only file type we treat like this is pdf. This is because we feel that the expected behavior in most browsers/web apps clicking on a pdf is to open it in the browser. It’s possible we add file-type handling in the future. Perhaps for images or videos, for example.
To be fair, Firefox is my default browser as it seems to be the one most concerned about respecting user privacy of the big three. I have Firefox setup so that it always downloads .pdf files (rather than opening it in the browser) as the preferred option. I seldom use Chrome so the amount of customization and add-ons are minimal. Echo is only installed because MS says it will be. (I actually went out of my way to hide it as much as possible.)
One reason why you might want to consider working on a transparent solution to .pdf files is Tax season. People and CPA firms often have to transfer tax information and forms back-and-forth. The problem of security is so great that they often omit sensitive information (like SS numbers) in approval forms. I had a situation where the wrong SS number ended up in a Tax form that was submitted in a Estate case. (Straightening that one out was not fun!!!) CPA Professionals (as a group) take privacy and security very seriously.
I have been thinking about this. I download a lot of .pdf files straight to disk using Firefox without a problem. Granted that most of these files do not require decryption beyond the normal SSL used on https:. Why not just download all files to the browser download directory?
I have a question about what is the thought process behind opening only .PDF files in the browser rather than saving the file straight to disk. My thought is that I am sending a file to someone and I consider that the contents of the file are secret and confidential enough that I went to the trouble of requiring an end-to-end encryption only to have it automatically ( and, perhaps, unexpectedly) opened in a browser window where it might be viewed by anyone in the vicinity. It seems to me that security suddenly got tossed for convenience of saving for a couple extra of mouse clicks! And since the recipient probably needs the actual file, he/she will still need a few more mouse clicks to save it safety out-of-plain-view!
If one were to consider that if it was a paper document transmitted through a Courier service (which Bitwarden Send is) would one (after opening) put it in a transparent zip lock bag to move it around the office or in a file folder/envelope appropriately marked.
