

They dont want to give control to platforms and their policies or update frequencies or some nonsense. Meanwhile they love Google


They dont want to give control to platforms and their policies or update frequencies or some nonsense. Meanwhile they love Google


That depends on where you got the APK from
But note that UnifiedPush is not supported by signal, so you need to register a fake device on a server running MollySocket. Which is very much additional attack surface and only worth it if you really rarely use signal


Use Verified-Apps from PrivacyGuides to verify the signature of the APK before installing.
Before Appverifier was a thing, it was very obscure how to even check that signature.


Yeah, since a month or so, and emphasis on 2 and not unlimited


Yeah unofficially… that is very much a bandaid. It is really bad of Signal to not have a blobfree reproducible build on F-Droid and Flathub, or even just external repos (for F-Droid and flathub).
Instead they have a hidden self-updating APK (which is a very cursed concept) with blobs, and a damn Appimage on Linux.


Session has removed forward secrecy. I dont know if they still have broken autodeletion and still store all messages in a blockchain (delaying actual deletion). Overall though, I would stay away from it.


I use Signal-FOSS by twinhelix. It exists since many years and upatches are fully automated.
They are very simple, deblob signal, remove firebase messages and maps and whatnot.
Twinhelix has also added some of the jw patches, which are nice to have.
It does not
If you dont need those features, I highly recommend it. Signal shipping Google blobs and having no F-Droid repo is very bad and that shouldn’t be supported.
See the list of known 3rd party F-Droid repos
Note that UnifiedPush needs to be supported by the server. The server then sends the push message to a UnifiedPush distributor (like Conversations, ntfy or Sunup). That distributor wakes up the app, which sends you the notification.
There is a slight polling delay of about 1 minute, so notifications are delayed.
I measured the effect of this by comparing molly with UP and the Signal APK with websocket. On a Pixel 8a running GrapheneOS, 12 hours idle on Wifi, airplane mode on (as the modem uses by far the most battery). I configured to send 10 messages to the device using Signals “send later” feature.
Websocket used 3% of the batterylife. Thats it.
And that effect is only significant for people who rarely use Signal, so the likelyhood of a nerd configuring MollySocket falling into that category is pretty low. If you regularly open Signal, this only delays notification alerts for no benefit.
And because the Signal servers don’t officially support this you need to either selfhost MollySocket (which would be fine apart from potential update delays, what this post is about) or trust some server operator. MollySocket is registered as another device, so the Signal servers and any standard Signal client would treat it as a trusted device with its own decryption key.
Apparently MollySocket discards the key and only receives “you have a message” (and no other metadata? I have obviously not researched this a lot), and I suppose Molly ensures that the device will never get a decryption key either. Still, it increases attack surface for very limited benefit.
It would be great if Signal officially supported UP instead of Google FCM.
I appreciate the textured background but the nerd in me wonders how much of the size it takes up


This is so vague we dont even know if it’s a good thing
A way more trusted project is this
https://github.com/mvt-project/mvt