Signal should allow file attachments of any type

[johanw666]

• I have searched open and closed issues for duplicates
  An issue with this title exists but it deals with something else.

---

Bug Description

I want to send someone a (windows) executable but Signal Desktop refuses, claiming something about "dangerous" types. Now I use Signal Android to circumvent that and hope the receiver can get the file from Signal Android to his desktop because the desktop version refuses to download it. This kind of hindering users is contra productive.

Steps to Reproduce

Try to send someone a exe file.

Expected Result:
The exe is sent, just like on Android.

Platform Info

Signal Version:

1.29.3

Operating System:

Windows 7 64 bit.

Linked Device Version:

Android 6.0.1.

[vatterspun]

Some possible suggestions here:

• Disallow by default - It might make sense to allow this, but make it disabled by default. It would be allow it to be enabled under the "advanced" view near "enable / submit debug log" with a clear warning about it.
• Allow only compressed files / compressed - if someone knows how to decompress a file, they are more likely to have the tech knowledge to run antivirus, beware suspicious files, etc.

[scottnonnenberg-signal]

@vatterspun This is our solution - we allow .zip files:

Allow only compressed files / compressed - if someone knows how to decompress a file, they are more likely to have the tech knowledge to run antivirus, beware suspicious files, etc.

[ghost]

@scottnonnenberg-signal This really is a bad, unintuitive workaround to my opinion, for a non problem.

How do you determine 'dangerous' files? In the past I was involved with a larger organization that deemed .zip files dangerous, blocking them in email attachments, resulting in all sorts of ridiculous workarounds, one being to use the suffix '.thisisnotazip'.

Unzipping is such a simple operation on any operation system, you cannot seriously claim that this results in extra protection by making only 'tech-savvy' people able to use an attachment.

If that is considered necessary by Signal, why not simply display a warning on the receiving side (preferably with a setting to disable this), when downloading an attachment that you consider risky?

[vatterspun]

why not simply display a warning on the receiving side (preferably with a setting to disable this), when downloading an attachment that you consider risky?

I don't get the sense that Signal is trying to be perfect security - they're trying to balance simplicity and security. I can count a dozen different projects that were either too simple or too secure, and no one ever used them. The ZIP file trick might not be ideal but I don't have a better suggestion.

As far as the warning message, I can say that people definitely don't read warnings. Hence the suggestion around off-by-default. Also, if the first time I start up the program and I get some kind of warning about a bad file someone's sending me, I might just uninstall the program.

[ghost]

I agree on the good balance between usability and security in general. My comment was only for the case at hand.

I am also not in favour of a warning, I am in favour of allowing users to send any file they like. But I would find a warning better than the obscure 'zip only' approach, if some alleged protection must be implemented.

[johanw666]

I would favor a warning but at least the option to allow. For now, it can be patched out (each build...) in app.asar for desktops. Just look for isFileDangerous and patch the return to false;

I'd have to search how to do that, just editing the file caused a crash at startup.

If you've got root on your phone or can push your own apks, same concept follows.

On Android it is not a problem because this limitation is not there (otherwise I would have removed it already a long time ago).

[OdinVex]

I'd have to search how to do that, just editing the file caused a crash at startup.
On Android it is not a problem because this limitation is not there (otherwise I would have removed it already a long time ago).

Pad the return false; with spaces. Won't crash then. Make sure you're using a hex editor. Don't add to delete bytes, simply replace.

[johanw666]

Ah well, I already found out how to use asar to unpack app.asar, after that I can just edit app\ts\util\isFileDangerous.js as a textfile.

[OdinVex]

Ah well, I already found out how to use asar to unpack app.asar, after that I can just edit app\ts\util\isFileDangerous.js as a textfile.

I figured it easier for most to just byte-patch, the reason I suggested as I did. :P

[gabrc52]

Some things that I think should be considered:

1. With the current solution (ZIP file) the sender would need to reupload, and would need to be creative enough to even consider sending the file as a ZIP. That is, if the sender doesn't incorrectly assume that ZIPs aren't sendable either. If the file is too large, this can be inconvenient due to the time to upload basically the same twice. Or if the sender and/or receiver have limited bandwith or a data cap, then it's going to cost money, literally.
2. This protection is kind of pointless since Signal Desktop doesn't protect against links that download "dangerous" files. A malicious actor can send someone a link, which wouldn't show any warning, and would even get the recipient's IP address and user agent. Chromium-based browsers, will, in fact show a warning against downloading the potentially dangerous file. I think this is inconvenient to legitimate users who wish to send potentially dangerous files. Malicious users have an easy workaround which is sending a link, but legitimate users who don't know about being able to send ZIP files may not wish to upload it somewhere due to lack of end-to-end encryption.
3. Opening a ZIP file isn't actually that difficult. Windows, macOS and Linux open it or extract it automatically, and desktop users generally know how to use a file manager. As mentioned by @Sirius-C.

Taking the first point into account, a potential solution could be: Don't let anyone upload "dangerous" extensions, on any platform. That way, the sender doesn't need to reupload again (which could be an issue if it's a large file). Show an error message saying sending that file type is not supported, but suggesting them to upload a ZIP file. This is already better than what we already have, but it doesn't address the second or third point.

Taking the second and third point into account as well, the solution I'd propose is to show a warning to the receiver: "This file could harm your computer. Are you sure you wish to download/open it?" If that exact warning is going to be shown, then Signal Desktop should only protect against downloading malicious files for the computer, which is a separate issue (#5142), but if it will protect against downloading malicious files for any device, then I would show something similar to "This file could harm an Android phone/Windows computer/etc, if you open it in that device, or send it to someone with that type of device. Are you sure you wish to download it on this computer?".

[OdinVex]

... Or you could sensibly and simply display warnings for extensions you find 'dangerous' and not try to play the part of Big Brother.

[gabrc52]

Yes, I think displaying a warning is the best solution.

[novocaiin]

if someone knows how to decompress a file, they are more likely to have the tech knowledge to run antivirus, beware suspicious files, etc.

Lol that is so random I am astonished something like this is considered a "security feature." In supposedly the most trusted messenger no less.
No, someone who doesn't know how to zip (or hasn't thought about it) is just as likely to have the "tech knowledge" to run antivirus as someone who does, just like someone who happens to know how to zip might or might not know how to run an AV.

Not to mention that AVs are a pretty questionable security measure to begin with since they're for the most part enumeration badness, just like this whole attempt of you trying to white/blacklist certain extensions.

[johnyonson]

Another solution here would be to have an option in settings to disable the dangerous file check. I like using Signal to send files such as apks between devices. It's a massive annoyance that I am not allowed to do so. Not so much in terms of time to rename the file on both ends, but just the audacity of the developers to keep me from minding myself.

[LagSlug]

I would prefer an opt out for this feature. I too was trying to send myself an apk file and was given a message that I cannot for security purposes. Since I know that my data is encrypted, and in a state that cannot execute within any property of Signal's, I think it's only fair that user's get to decide what files they send and receive.

[ghost]

@johnyonson @LagSlug Patch available here (Linux only though).