I’m a photographer. I care a lot about pixels and image quality and resolution. My main workstation has three 5120x2880 5k displays that run at 218ppi.

I’m also someone who really likes music and audio engineering who has been known to DJ occasionally.

I also come from a network and storage engineering background, so I’m not entirely ignorant of the considerations that are made in terms of trade-offs for size/cost versus quality. I remember once in the 90s being totally flabbergasted upon performing an ABX (computer-assisted double blind test) in ideal conditions to find 160kbps MP3 (lossy) compression entirely acoustically transparent across a range of different audio samples. I encourage you to try the same sometime, and I’ll bet you any amount of money that you wish that you cannot reliably distinguish 320kbps MP3 from FLAC/WAV, ever.

Today I sent a picture I’d taken of Tutu with my Sony A7R4 camera via Signal. I’d loaded the raw in Lightroom, done some of the usual silly traditional photographery things one does to portraits in post-production, and exported it using one of my export presets, which limits the long edge resolution to a maximum of 4000 pixels and the overall total file size to a maximum of 25MB (along with slapping my email address on the bottom corner because we still haven’t figured out how to reliably attach metadata to bitmaps across multiple generations/edits). I think in 2021, 25MB or so is probably the upper “reasonable” limit of file size for passing around a single compressed image. In this case, the exported JPEG file was only 3.9MB, quite a bit below that.

Signal took that 4000x2667 JPEG image comprising precisely 3,916,886 bytes, encrypted it, and transmitted it to my friend. She received a different 4000x2667 JPEG image comprising 784,524 bytes: 80% smaller.

Signal threw away 80% of the data in my already-compressed image. (The original image, not the export, was 9504x6336 and 67,358,106 bytes.) I had already compressed it once by eliminating 94% of the data from when it came out of my camera.

Camera raw: 67MB

My “reasonable person” standard for maximum filesize for an image to be sent across the internet in 2021: 25MB

My actual file export: 3.9MB (-94%)

Signal’s unasked-for, silent edit: 0.8MB (another -80%)

Did you know that the everyday, normal-sized (<4MB) images you send via Signal are being silently altered in transit to look like dogshit?

I didn’t.

Now we both do.

I don’t think Signal should do this.

If they feel it’s absolutely necessary for them to do this to continue to exist as a free service: they should be much, much clearer about the fact that this is going to happen, at the time of recompression, and permit you to opt out of sending an altered file. As well as, just, you know, not touching images that are already reasonably sized.

What if I were sending evidence to my attorney? You just fucked that up, both from a file integrity standpoint, as well as an image quality one. I hope it wasn’t exculpatory!

You’re a messenger. Don’t edit the text in the messages I send without my consent, and don’t edit the bytes in the attached files I send without my consent. Neither one is okay.

(It happens with videos too, much worse. I’m just using photos as an example.)

Security Footnote

Before you get worried about message privacy, note that Signal messages are fully end-to-end encrypted, and all of this quiet fuckery happens on your own device, in the Signal client software, before it gets encrypted and transmitted. This isn’t happening inside the Signal service, this is a misfeature in the Signal software, designed to benefit the operators of Signal-the-service, at your expense (or at least at the expense of the quality/integrity of your files).

This behavior was observed on 2021-04-25 using Signal Desktop for macOS version 1.37.3.

A Note About The Open Source Signal Client

It’s a common misconception that you can’t make forks of the Signal client software that work with the main, Signal-organization-operated centralized Signal service. This is false. The Signal client software is AGPL (sort of a silly choice for client software, tbh) and can be forked at will by anyone, and you are free to leave the main upstream Signal service API URLs in the code. (You are probably not free to use the string “signal” or “Signal” in the name of the derived work though, but that’s an entirely separate trademark issue.) The Signal service Terms of Service (TOS) govern API clients, not the publication of software, and at the moment the Signal service TOS does not prohibit use of the Signal service by authorized users that are using non-official clients (although it’s fairly obvious that the Signal founder is personally opposed to that). In any case they apply to different entities: the AGPL license for the Signal client software applies to distribution of derived works; the Terms of Service for the Signal service API governs end-users who connect to those APIs.

(I’m not even sure you can govern the use of client software in a Terms of Service for an API, that would be like Google claiming that you’re not authorized to use google.com if you’re loading it in Firefox. That’d be insane.)

As you can probably tell, I’m really hoping that someone makes a much better client for the Signal service. The “official” ones from the Signal service operators are pretty lame.