-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signal should allow file attachments of any type #3849
Comments
Some possible suggestions here:
|
@vatterspun This is our solution - we allow
|
@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? |
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. |
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. |
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).
|
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. |
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 |
Some things that I think should be considered:
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?". |
... Or you could sensibly and simply display warnings for extensions you find 'dangerous' and not try to play the part of Big Brother. |
Yes, I think displaying a warning is the best solution. |
Lol that is so random I am astonished something like this is considered a "security feature." In supposedly the most trusted messenger no less. 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. |
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. |
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. |
@johnyonson @LagSlug Patch available here (Linux only though). |
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.
The text was updated successfully, but these errors were encountered: