Signal should allow file attachments of any type

[daveloyall]

• I have searched open and closed issues for duplicates

---

Bug description

Signal doesn't appear to support .txt files as attachments (via the paperclip button in the message window).

Steps to reproduce

• click paperclip button
• navigate to a .txt file

Actual result: error message: "unsupported file type"
Expected result: It should send the .txt file

Platform info

Operating System: Windows 7, 64-bit
Browser: Chrome 55.0.2873.0 dev (64-bit)
Signal version: Z.Y.Y

[hoyla]

Also true on this platform:

Extension: Signal Private Messenger 0.25.1
Operating system: MacOS 10.11.6
Browser: Chrome 52.0.2743.82 (64-bit)

[weienwong]

Did some investigation into this issue. I manage to do a bit of a fix on my end by adding an extra case to switch cases to handle text. I can successfully send / receive a text file using the desktop app.

From a UI / UX standpoint, are there any requirements we should satisfy? ie. What icons we should use when sending text attachments? What should be shown when a text attachment has been received?

[ghost]

.txt is not the only unsupported file type. Try sending an office document, for example, and you will see the same error.

Renaming a non-JPEG file to have a .jpg extension, and then attempting to send it as an attachment to a message, produces a different result. Instead of yielding an error, it seems to cause Signal to silently lose both the message and the attachment. (See also: #419.)

Please can this bug be renamed to something like "No attachments should be rejected or silently lost due to file type or file extension"?

[daveloyall]

@sampablokuper What about renaming it to "Signal should allow file attachments of any type"?

[ghost]

@daveloyall, yep, that would be more concise :)

[daveloyall]

Done.

[smichel17]

IIRC from other discussions (but this is just my memory, don't quote me), OWS' opinion was that Signal-desktop should only support attachment types that are also supported on iOS and Android.

So, if my memory is correct, then "Allowing file attachments of any type" would be a wontfix.

@liliakai Is my memory correct? If so, is any part of this issue actionable? ie, are there any attachment types that we don't support but should, or error messages we should show but don't?

[Trolldemorted]

@smichel17 i think and hope "supported" means "it does not explode" in this context. I.e. you would have to ensure Android and iOS cope with every incoming file.

[smichel17]

So it seems like the steps to resolve this issue are:

1. Identify which file types can be opened on android and iOS, and allow those to be attached.
2. Display a helpful error message when you try to attach an unsupported file type.

[Trolldemorted]

In my opinion, it would be completely fine to send attachments that cannot be opened on mobile devices, as long as they do not misbehave and shoot themselves in the foot while trying to open them.

We want to send arbitrary file types from Signal-Desktop to Signal-Desktop, don't we? I do not want my Signal-Desktop experience to be constrained because a certain filetype cannot be opened on certain android/iOS versions.

[smichel17]

Honestly, I'm not sure. (Almost) every signal install has a mobile device as master. I'd imagine most people will at least read a large % of messages from mobile. Receiving a file you can't open is bad ux. So is being unable to send a file to another desktop instance because mobile can't handle it. I'm not sure which is worse for the average, non-technical user (since that is Signal's target audience).

Regardless of which way we feel or decide about that, the steps above remain largely the same. The only addition would be "If the mobile clients do not misbehave upon receiving an unsupported file type, allow Signal-desktop to attach those files in addition to the error message.".

[Trolldemorted]

Is receiving a file you cannot open really bad ux? If a person sends me a file my platform cannot open (e.g. no pdf viewer installed, whatever), it is hardly the messenger's fault.

A major problem is that Signal does not transmit the file's name and extension, now that i think of it.

[smichel17]

Is receiving a file you cannot open really bad ux? If a person sends me a file my platform cannot open (e.g. no pdf viewer installed, whatever), it is hardly the messenger's fault.

Scenario:

• A installs signal-desktop, sends unsupported file to B.
• B only has the mobile client, can't open it.
• B can't figure out how to get it off their phone and onto their computer.
• A and B are both frustrated.

Step 3 is the big one. You or I would probably just save the file, then email/owncloud/whatever to ourselves. There's a (maybe un)surprising amount of users who just won't do that. If it doesn't "just work", they'll end up getting frustrated and give up. If that situation can't happen in the first place, great!

It's somewhat a philosophical question, whether we want to say, "Once something is in Signal, all signal clients can handle it." or not (and, there's additional questions about whether it's OK to send file types that need to be saved to the potentially insecure file system, rather than viewed inside of Signal). I'm not going to argue in favor of one or another; they both have their merits.

A major problem is that Signal does not transmit the file's name and extension, now that i think of it.

👍

[daveloyall]

1. Transmit the filename. (The extension is part of the filename.)
2. On mobile, provide a mechanism to save the file.

Item 2 has been solved before by various apps on Android. I have no information about iOS.

The New York Times and others are recommending Signal for sending sensitive news tips to journalists. https://www.nytimes.com/newsgraphics/2016/news-tips/ File attachments would be useful.

Here's a little feedback about "non-technical users"... Each of us used to be one. We became technical users by interacting with applications that were not necessarily user friendly. Just something to ponder!

[jtbrown3]

The ability to send file attachments of any type is a CRITICAL feature requirement.
Perhaps some files (like .EXE files) should be required to be placed in a container (.ZIP .7Z .RAR) first to minimize certain immediate execution risks.

• Attachments should not be stored on any server (except temporarily, encrypted, until forwarded).
• User should be prompted first before receiving and file attachments above a certain size threshold and also informed of the available remaining space on their device.
• Multiple file attachments should be should be automatically zipped into a single container before sending.

[daveloyall]

The ability to send file attachments of any type is a CRITICAL feature requirement.

Yes.

Perhaps some files (like .EXE files) should be required to be placed in a container (.ZIP .7Z .RAR) first to minimize certain immediate execution risks.

No, thank you. This might be called 'premature optimization' or 'solving a problem nobody has'. Frankly I think you're kinda muddling a couple concepts from other domains: 1. Gmail and others block EXEs and 2. tech savvy users work around that limitation by wrapping EXEs in containers.

Ok, that was the negative thing I had to say about your suggestion... But, you have brought up security, great! Nobody wants a worm to use Signal as a channel for propagation.

I'd recommend:

• Separate the in-line image/media mechanism from the file attachment (paperclip) mechanism.
• Never look inside an attachment. Looking means parsing, parsing means opening yourself to bugs that could result in code execution.
• Inform the user that attachments could contain anything, even something dangerous. Full stop.

• Attachments should not be stored on any server (except temporarily, encrypted, until forwarded).

Yes.

• User should be prompted first before receiving and file attachments above a certain size threshold and also informed of the available remaining space on their device.

Right. Hm, given the stated security goals, maybe Signal should prompt before receiving any file, regardless of size.

• Multiple file attachments should be should be automatically zipped into a single container before sending.

Disagree. I'd like communication app to send what I ask it to.

To summarize my thoughts about non-technical users: I think they won't be receiving files from anyone except technical users. The sender can explain what to do with the file. The app doesn't have to.

[roadkillazpartybird]

Have noticed this too, can't send .zip or .7z or .txt files?

Seems like very basic functionality that is missing here.

[jeffmcneill]

The scenario above where someone has mobile only and can't figure out how to install an app to support an attachment is surely legitimate, but what about other situations, where people can actually either can figure out how to install an app that supports the attachment, and/or as well, where people who have/would also install a desktop client?

Surely the first use case should not trump the second and third use case. It seems that user frustration with an unclear situation (which could be cleared up with a few lines of text error message) isn't a great rationale for not having the functionality in the first place.

I can't even attach a PDF, which is so basic a functionality that I spent time trying to figure out what was wrong with the app and/or my computer. One of the most widely supported file document types. I can understand somewhat about things like docx/odt but .pdf?

Obviously the filename and the file extension is also important information to send, but seems a separate issue. Though I could be mistaken.

[Trolldemorted]

@jeffmcneill you can (at least you could some months ago) remove the file type check and send arbitrary attachments. Down side is, you have to do that again each time a new version rolls out.

[Trolldemorted]

signalapp/libsignal-service-java@b8a8079

filenames are incoming!

[b4rton]

As a journalist who uses Signal with sources, because it's easy enough for anyone to master, I strongly urge you to support attachment of arbitrary file types. We need a dead simple way to transfer files e2ee. If you don't want to support arbitrary file types, the list should include every graphics format, PDF, RTF, TXT, office files and ZIP. This is something iMessage does well, but not nearly as securely, and of course only for Apple users. (More specifically, iMessage on a Mac desktop can send arbitrary files; iOS devices can receive them.)

[Trolldemorted]

@b4rton if you and your colleagues are not afraid to use command line tools, you can always send and receive arbitrary files via your signal account by using signal-cli until filenames come to Signal-Desktop.

[b4rton]

Well, that's a good idea. Just se up signal-cli on OSX, registered a new number (even though I had the Chrome Signal app on the machine) and got this when I tried to send a message. What do I need to do now?

Failed to send/receive message (Assertion): java.security.InvalidKeyException: Illegal key size java.lang.AssertionError: java.security.InvalidKeyException: Illegal key size at org.whispersystems.libsignal.SessionCipher.getCipher(SessionCipher.java:443) at org.whispersystems.libsignal.SessionCipher.getCiphertext(SessionCipher.java:388) at org.whispersystems.libsignal.SessionCipher.encrypt(SessionCipher.java:100) at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encrypt(SignalServiceCipher.java:73) at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:504) at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:461) at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:379) at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:149) at org.asamk.signal.Manager.sendMessage(Manager.java:843) at org.asamk.signal.Manager.sendMessage(Manager.java:767) at org.asamk.signal.Main.handleCommands(Main.java:339) at org.asamk.signal.Main.main(Main.java:68) Caused by: java.security.InvalidKeyException: Illegal key size at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1039) at javax.crypto.Cipher.implInit(Cipher.java:805) at javax.crypto.Cipher.chooseProvider(Cipher.java:864) at javax.crypto.Cipher.init(Cipher.java:1396) at javax.crypto.Cipher.init(Cipher.java:1327) at org.whispersystems.libsignal.SessionCipher.getCipher(SessionCipher.java:438) ... 11 more If you use an Oracle JRE please check if you have unlimited strength crypto enabled, see README

[Trolldemorted]

That happens if you use oracle's java and did not install the Unlimited Strength Jurisdiction Policy Files.

[liliakai]

Please refrain from promoting signal-cli here. It is not maintained or supported by Open Whisper Systems.

Arbitrary attachments are on the roadmap, pending support on the mobile clients.

[liliakai]

Fixed in 7a8f2f0