My "SEND" recipient cannot download the sent file

Note: Your question may already be answered in the Bitwarden Help Center.

I tried to use SEND to transmit a 48Mb file to a friend who is not a registered BW user, and is running Windows 7 and the Chrome Browser. He was unable to receive the file. When he clicked the link to the “SEND” that I emailed to him, he did not get a “Download File” button – what he got was a demand to enter his master BW Vault password.

I failed to ask him what version the browser is, but Chrome tends to keep itself up to date. I am at a loss to explain why Bitwarden SEND is failing so miserably this time, so I am asking the community:

  1. Does anyone know if there is a minimum Chrome browser version required receive a SEND?
  2. Is there anything in SEND or Chrome that would prevent the recipient from being able to download a file? (e.g. are certain formats unsupported in SEND, like Music files or eBook files?)
  3. In a Windows environment, is there something in SEND that prevents it from working correctly on Windows 7?

Windows 7 may be part of the issue, the Send link leads to https://vault.bitwarden.com/#/send/ - but it almost sounds like the browser is removing the anchor and redirecting to the web vault for login.

Hi Trey -
thank you. I had him check and his Chrome Browser is up to date (Ver 91. xxx) so it should work, as Bitwarden is meant to be OS agnostic when accessed from a supported browser.
I have another (more tech savvy) friend who’s still using Win 7 and has been able to receive files from me using SEND, so I’m baffled.

So I’m wondering if SEND is inspecting / policing the types of files it will transmit. (preventing transmission of potentially harmful files like ZIP files, executable files, DRM protected content, script files etc. ) I rather doubt that because BW would have documented that, but … thought I’d ask to see if anyone else is having problems with SEND. (it’s really a neat feature when it works as intended !)

It’s very odd indeed - there isn’t anything that should cause that activity. Send doesn’t inspect the files - we actually have no idea what the file is - it’s just an encrypted blob-o-data to us.

Send is downloading the file and decrypting it within the scope of the web vault’s javascript client. Not sure if there is something in the browser blocking JS or not, but something to look at.

Was it a PDF file? (Apparently, the browser can trap PDF files as they are being decrypted…)

EDIT: one way to prevent any problems with the browser attempting to do anything with the file is to ‘zip’ the file before sending!

3 Likes