Signal AppImage for Linux(github.com)
github.com
Signal AppImage for Linux
https://github.com/signalapp/Signal-Desktop/issues/1758
98 comments
There's also a Flatpak available here:
https://flathub.org/apps/details/org.signal.Signal
I wish Signal would officially adopt the Flatpak and AppImage versions. They are pretty widely used and depend on third-party build pipelines right now, which is a risk.
https://flathub.org/apps/details/org.signal.Signal
I wish Signal would officially adopt the Flatpak and AppImage versions. They are pretty widely used and depend on third-party build pipelines right now, which is a risk.
Yeah, I was thinking this as well - the only official versions are for Debian-based repositories, feels a bit misguided to me for the "privacy and only privacy" messenger that probably has an essential userbase on Linux.
The other messengers with the same amount of funding can do it and it's not a great amount of work, with the community being able to contribute to build scripts.
The other messengers with the same amount of funding can do it and it's not a great amount of work, with the community being able to contribute to build scripts.
Don't you find Flatpacks and snaps a little slower? The overreliance of Ubuntu 20.04 on snaps was my reason to finally ditch it for something else
Flatpaks, nope. At least nothing I could notice.
Snaps, yes definitely, but mostly when there is a UI involved.
I tend to prefer Flatpaks for apps with a UI.
Snaps would have been good for CLI apps if Canonical would just give it a rest already, and allow them to be decentralized and stop pushing them so hard as if that would make us use them.
So while I do sometimes use snap packages, I'd prefer not to.
Snaps, yes definitely, but mostly when there is a UI involved.
I tend to prefer Flatpaks for apps with a UI.
Snaps would have been good for CLI apps if Canonical would just give it a rest already, and allow them to be decentralized and stop pushing them so hard as if that would make us use them.
So while I do sometimes use snap packages, I'd prefer not to.
[deleted]
Thanks a lot rhamzeh!
I never really liked AppImages. Until I got one recently that asked if it was allowed to be in my menu... Game changer!
Now, if they would just automatically move to a ~/apps folder, be executable and indeed, in the menu. My love for AppImage would grow orders of magnitude. Even more if they could self update.
Right now, snaps are the only universal packaging format that really gives me a smooth experience (install experience that is.)
Now, if they would just automatically move to a ~/apps folder, be executable and indeed, in the menu. My love for AppImage would grow orders of magnitude. Even more if they could self update.
Right now, snaps are the only universal packaging format that really gives me a smooth experience (install experience that is.)
I've used AppImageLauncher to do just that. When an AppImage is opened with AIL, it moves it to a configurable ~/app directory and creates a "start menu" entry for it.
I've never though about it but I guess it also makes them executable, since I've never had to do that myself.
It doesn't handle removing the AppImage, but you can always just delete the file from ~/apps.
I've never though about it but I guess it also makes them executable, since I've never had to do that myself.
It doesn't handle removing the AppImage, but you can always just delete the file from ~/apps.
For reference, what whatatita is talking about is at:
https://github.com/TheAssassin/AppImageLauncher/releases
;)
https://github.com/TheAssassin/AppImageLauncher/releases
;)
I've been a big fan of AppImage since I discovered that Firejail has AppImage support. Makes it super easy to do, for instance, bandwidth shaping for a single application, or to disallow network traffic etc.
There is a snap for Signal as well (signal-desktop). So far it's been working for me!
How are snaps universal and smoother than Flatpak? For once, they're only really supported by Ubuntu and not its derivatives.
Snaps work under Arch and under Fedora, and many more. They are only actively blocked for philosophical reasons on Mint (an Ubuntu derivative).
imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages...
i fail to see what problems we've solved. it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.
it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging.
i fail to see what problems we've solved. it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.
it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging.
> it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.
Speaking about AppImage only:
They've solved the problem of requiring third party middlemen to include our package in a repo, using updated versions on older "unmaintained" distros, using old versions on the latest distro, using two different versions at once, and being able to store applications on different media.
> it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging
Unfortunately this seems to be the best that can be done with the Linux Desktop community's extremely fragmentary and complexity-worshiping nature. There is no agreement on what constitutes the base "Linux Desktop" platform, and very little ABI back and forward compatibility.
Speaking about AppImage only:
They've solved the problem of requiring third party middlemen to include our package in a repo, using updated versions on older "unmaintained" distros, using old versions on the latest distro, using two different versions at once, and being able to store applications on different media.
> it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging
Unfortunately this seems to be the best that can be done with the Linux Desktop community's extremely fragmentary and complexity-worshiping nature. There is no agreement on what constitutes the base "Linux Desktop" platform, and very little ABI back and forward compatibility.
> imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages...
> i fail to see what problems we've solved.
Any of those can be installed on most big distros, so you only need to release one for your app. Though I would use only docker for services and only flatpak or appimage for apps. Snap is proprietary; only Canonical runs a server.
Any of those can be installed on most big distros, so you only need to release one for your app. Though I would use only docker for services and only flatpak or appimage for apps. Snap is proprietary; only Canonical runs a server.
yes, it solves problems for devs at end-user expense.
5-7 years ago, i could "apt upgrade" and upgrade, nearly, my entire box.
Now i have to manually upgrade DEBs, have separate systems or upgrade/management options for AppImages, Flatpaks, Snaps, docker images.
it's a mess and it makes keeping up with security patches an absolute nightmare.
Now, if you're lucky, apps do all their individual checking if an upgrade needs to be done and you do apps one at a time, piece meal, which requires a lot more time from end users.
I now spend more time managing my machine than using it.
so yay for devs saving some time on their end ,or something.
5-7 years ago, i could "apt upgrade" and upgrade, nearly, my entire box.
Now i have to manually upgrade DEBs, have separate systems or upgrade/management options for AppImages, Flatpaks, Snaps, docker images.
it's a mess and it makes keeping up with security patches an absolute nightmare.
Now, if you're lucky, apps do all their individual checking if an upgrade needs to be done and you do apps one at a time, piece meal, which requires a lot more time from end users.
I now spend more time managing my machine than using it.
so yay for devs saving some time on their end ,or something.
Flatpak apps are also faster to start (at least in my experience, Snaps always take multiple seconds while Flatpaks usually start instantly)
Just switch to Arch. I know it's become a meme distro, but the AUR really is amazing. I don't have AppImages, snaps, Flatpak, or anything of the sort on any of my systems. Everything is either installed from the official repositories, or automatically built as proper packages and installed the same way.
This is exactly what I did. Snap's are basically docker gone wrong. Snaps are sandboxed, blocking access to NFS shares which I use extensively. Under Ubuntu, Chromium is usually broke (apt-get installs a deb that then installs a snap); You have to install either a debian .deb or use a PPA to make it work. I love that Ubuntu is directly including ZFS, but the distro has gotten so bad that I don't want to go near it anymore. Arch works, and works well.
> it may have made a couple of devs lives easier,
how do you propose to have software depending on, say, Qt 5.15 for hidpi bugfixes and ffmpeg 4.3 for codec support, available for users stuck on ubuntu 16.04 or debian jessie ?
how do you propose to have software depending on, say, Qt 5.15 for hidpi bugfixes and ffmpeg 4.3 for codec support, available for users stuck on ubuntu 16.04 or debian jessie ?
This solves this problem for me quite well: https://github.com/TheAssassin/AppImageLauncher
It asks whether an AppImage should be integrated (with .desktop files, etc.) upon launching one and does everything automatically, even on my system running Arch+i3 where I except little to work automatically.
It asks whether an AppImage should be integrated (with .desktop files, etc.) upon launching one and does everything automatically, even on my system running Arch+i3 where I except little to work automatically.
If you use the KDE Discover, it's pretty smooth as well. Searched for "Signal", found the app, clicked on install, waited, then clicked on open. Signal App opened. Uses Flatpak in the Background and handles updates too.
You could always just rig up a couple Bash aliases and change where your menu works. Say for example appimg() { chmod +x $1; mv $1 ~/apps/ } and then bind a key sequence to `$(ls ~/apps/ | dmenu)`.
Not to dismiss your reply, but I've always thought that the "just open the terminal and..." kind of solution that is always brought up is holding Desktop Linux back.
There's a workaround for almost everything. Wherever there is a workaround, the problem becomes less severe. As a result, it is less likely to get fixed.
There is nothing preventing AppImages to work like app containers on Mac OS except lack of integration that comes out-of-the-box. Advocating for that integration becomes more difficult, when you can "just open the terminal and...".
There's a workaround for almost everything. Wherever there is a workaround, the problem becomes less severe. As a result, it is less likely to get fixed.
There is nothing preventing AppImages to work like app containers on Mac OS except lack of integration that comes out-of-the-box. Advocating for that integration becomes more difficult, when you can "just open the terminal and...".
I posted this above, but at least for me, this project seems to do the trick: https://github.com/TheAssassin/AppImageLauncher
I did use a terminal to install the AUR package on my system, however. ;)
I did use a terminal to install the AUR package on my system, however. ;)
I've been using Signal for a few years now. Got most of my friends and actually all of my coworkers to switch.
The one thing that really bums me out is that the desktop app is another Electron app.
At the time of initial development and even now, there's really been no good cross platform way to build a desktop app with a team as small as Signal's, but they recently had an AMA on reddit where I asked if they had considered migrating to a Flutter based desktop app in the future. Their answer was generally positive regarding Flutter, but also a fairly firm no to future migration, so it seems we're stuck with Electron unless something changes.
The one thing that really bums me out is that the desktop app is another Electron app.
At the time of initial development and even now, there's really been no good cross platform way to build a desktop app with a team as small as Signal's, but they recently had an AMA on reddit where I asked if they had considered migrating to a Flutter based desktop app in the future. Their answer was generally positive regarding Flutter, but also a fairly firm no to future migration, so it seems we're stuck with Electron unless something changes.
This is what surprised me most, using Telegram next to Signal in the recent months - their Windows app is fully native and super fluid + speedy. It's really a night and day difference, I hope Signal devs will reconsider some time.
Same deal on ubuntu/linux! For a year or so I've been really happy with Telegram's resource usage and snappiness.
I would donate specifically to an effort to develop a native Signal Mac app.
Donations are kind of a funny thing IMO. Some folks who develop for open source are not motivated by money, and may not even want it.
I personally have been developing MMS to get it on the pinephone, and I don't think I would want anyone to donate to me. The main reason is now I feel like it obligates me to work and support people, versus now I do not feel any obligation. I get that I can ask for donations with no expectation in return, but I would still feel that way.
I would offer if that is truly what you want, perhaps taking some of the first steps to get it going may be a lot more useful than donating. If you have the first steps done, it makes the goal much easier if others want to help. That is exactly what I have found wokring through my project. A lot of people come out the woodwork to help on smaller issues that they can tackle, but there was no large scale effort until I finally rolled up my sleeves to start.
I personally have been developing MMS to get it on the pinephone, and I don't think I would want anyone to donate to me. The main reason is now I feel like it obligates me to work and support people, versus now I do not feel any obligation. I get that I can ask for donations with no expectation in return, but I would still feel that way.
I would offer if that is truly what you want, perhaps taking some of the first steps to get it going may be a lot more useful than donating. If you have the first steps done, it makes the goal much easier if others want to help. That is exactly what I have found wokring through my project. A lot of people come out the woodwork to help on smaller issues that they can tackle, but there was no large scale effort until I finally rolled up my sleeves to start.
[deleted]
>I feel like it obligates me to work and support people
Couldn't you just make it very clear that any donations are only endorsements of the work you've already done and independent of any work you may or may not do in the future?
That way everyone is on the same page and you don't have to feel like you owe your donors support or continued development.
Couldn't you just make it very clear that any donations are only endorsements of the work you've already done and independent of any work you may or may not do in the future?
That way everyone is on the same page and you don't have to feel like you owe your donors support or continued development.
I could yes, but at the same time, I do feel that if I got a donation and then life/work/etc. got in the way and I stopped doing anything, I still feel like I in some way let them down since they did donate to me.
I will offer that I am also in a fortunate position where I don't need the money in the first place too.
I will offer that I am also in a fortunate position where I don't need the money in the first place too.
I'm not interested in donations, but I might have a go at this in a few months, if I get the time - as I'm a regular user of Signal, but I refuse to use Electron apps. Can't promise anything though.
Nothing expected, very much appreciated.
There is also a Flatpak: https://flathub.org/apps/details/org.signal.Signal
I don't know why people insist on running this particular siloed encrypted instant messenger everywhere in every way. There are tons of these things out there. Since none of them interoperate anyway all you need to do is pick one that everyone in your group can run.
Kind of an upside to very unfortunate situation...
Kind of an upside to very unfortunate situation...
> need to do is pick one
That is exactly the de-facto selling point of Signal. It does this and enough of other things better than the rest of the truly secure messengers. (Still not as good as Whatsapp is at these network effects, obviously.)
This is exactly why people insist on it. And exactly why if there was other messenger in it's place you would be asking the same thing.
That is exactly the de-facto selling point of Signal. It does this and enough of other things better than the rest of the truly secure messengers. (Still not as good as Whatsapp is at these network effects, obviously.)
This is exactly why people insist on it. And exactly why if there was other messenger in it's place you would be asking the same thing.
Matrix is interoperable.
Moving to signal is going to end up being the same problem that moving to WhatsApp was: single point of failure.
Moving to signal is going to end up being the same problem that moving to WhatsApp was: single point of failure.
I haven't really seriously looked into Matrix before. I've briefly skimmed what I could find about it, but didn't see any simple way to get something running where I could easily onboard friends/family. Correct me if I'm wrong, but this seems like the single biggest issue with Matrix.
I see you've managed to make an account on HN.
It is exactly the same. Download one of the clients, for example, Element. Then register. You don't even need an email address. Just make up a name, and a password.
There's even a web client that is functionally identical to the desktop and mobile clients.
It could not be simpler.
Ta da.
It is exactly the same. Download one of the clients, for example, Element. Then register. You don't even need an email address. Just make up a name, and a password.
There's even a web client that is functionally identical to the desktop and mobile clients.
It could not be simpler.
Ta da.
> simple way to get something running where I could easily onboard friends/family
He's not talking about himself, he's talking about (non-IT) friends and family. Most of them probably would be barely able to find the register dialog on HN, that's at least what I would say about my non tech-savy friends. A good chunk of them doesn't even have a PC.
For those people, Signal is optimal. Its onboarding and usage is a lot easier than Matrix.
He's not talking about himself, he's talking about (non-IT) friends and family. Most of them probably would be barely able to find the register dialog on HN, that's at least what I would say about my non tech-savy friends. A good chunk of them doesn't even have a PC.
For those people, Signal is optimal. Its onboarding and usage is a lot easier than Matrix.
Baloney. If they're that inept, GP is going to have to do it for them anyways. He should save himself some trouble and start with something he won't have to replace in 5 years when precisely the same thing that happened at WhatsApp happens to signal.
Along with the same kind of lock-in to Android or IOS smartphones and the forced use of phone-numbers as user identifier.
So yeah, great that it's not Facebook, but not very useful otherwise.
So yeah, great that it's not Facebook, but not very useful otherwise.
Signal is also not a good messenger...
You can't delete signal contacts and other potentially incriminating meta... Like wtf?!
You can't delete signal contacts and other potentially incriminating meta... Like wtf?!
I find it particularly annoying that it inherits almost all of the worst features of WhatsApp which people are supposedly fleeing, such as being completely centralized and tied to your phone number.
Not exactly sure what you are talking about. People are fleeing from Whatsapp because it's owned by Facebook (which has one of the worst privacy reputations), because it's closed source and because facebook can replace your E2EE private key if they want so the E2EE is pretty useless. Facebook could also use the metadata if they want, which is pretty valuable.
Signal on the other hand is a nonprofit run by trusted people like Moxie Marlinspike, it's accessible to casual (non-IT) users as well (unlike XMPP) and it's fully open-source. It also minimizes metadata, like with the Sealed Sender functionality.
Signal on the other hand is a nonprofit run by trusted people like Moxie Marlinspike, it's accessible to casual (non-IT) users as well (unlike XMPP) and it's fully open-source. It also minimizes metadata, like with the Sealed Sender functionality.
> trusted people like Moxie Marlinspike
Just out of curiosity and not challenging: what makes Moxie trustworthy?
Just out of curiosity and not challenging: what makes Moxie trustworthy?
His code. Go check it out and decide for yourself.
https://github.com/moxie0
https://github.com/moxie0
So if someone can write good code they cannot be malicious? Not sure we are using the same definition of trustworthy.
Personally, I think that WhatsApp has an excellent user experience (including their encryption which is fine) and the only reason I am leaving is because of privacy concerns.
Signal also has an excellent user experience (much better than I was expecting) and most of the privacy concerns are alleviated. Decentralised would be better, but I have not found Matrix to be a particularly smooth experience.
Signal also has an excellent user experience (much better than I was expecting) and most of the privacy concerns are alleviated. Decentralised would be better, but I have not found Matrix to be a particularly smooth experience.
I suppose this is a matter of opinion, but for many the worst feature of WhatsApp is the fact Facebook has access to most of your stuff and its E2E encryption barely worked.
Signal being centralized and tied to a phone number are design choices to make things easier for users. That's a far cry from the presumed reasons WhatsApp did things. The only reason that Signal has gained what traction it has is because of those features.
Signal being centralized and tied to a phone number are design choices to make things easier for users. That's a far cry from the presumed reasons WhatsApp did things. The only reason that Signal has gained what traction it has is because of those features.
The problem is the lack of alternatives for non-technical people.
My grandmother can easily use WhatsApp or Signal.
My grandmother can easily use WhatsApp or Signal.
People fleeing WhatsApp is basically fleeing from it because it is owned by Facebook. So it's usually for political reasons (especially in the USA) and/or for privacy concerns.
A minority of tech-savvy users are leaving it for the reasons you say.
Is it possible to use signal without having to have a smartphone app installed?
Kinda. You can set up a matrix server and signal bridge. That's what I am doing with all chat applications.
No, you need an active smartphone and a phone number to sign up to Signal and register the desktop app at the moment. Maybe that'll change once they introduce usernames.
https://signal.org/donate/ would maybe help so they can apply resources to this issue!
donate to change one line of code in the build process?
there are reasons other than finances that are getting in the way of this moving forward, i'm afraid.
there are reasons other than finances that are getting in the way of this moving forward, i'm afraid.
As a user, I love having a single executable file and not worrying about anything else like alien dependencies that will usually not work on my outdated distro.
But from the developer point of view, I've seen some claiming that maintaining an AppImage is a PITA and pretty difficult / time consuming to get right: https://github.com/phw/peek/issues/502#issuecomment-58757433...
But from the developer point of view, I've seen some claiming that maintaining an AppImage is a PITA and pretty difficult / time consuming to get right: https://github.com/phw/peek/issues/502#issuecomment-58757433...
~/apps isn't the answer.
There is already a well-established convention for ~/bin.
Applications should not be installed in user profile space.
Many supported *nixes deprecate your touching system directories /bin, /usr etc and there's a well-established convention for placing added software in /opt, a filer share, removable media etc.
An advantage of AppImage is that they don't change the system package database and can be run from /opt a share or removable media.
Yes, there needs to be a mechanism for update of third-party applications. ~/apps isn't it.
Imagine in a corporation that uses Linux desktops, 1,000 users clicking to update a third-party bloated electron app to ~/apps.
There is already a well-established convention for ~/bin.
Applications should not be installed in user profile space.
Many supported *nixes deprecate your touching system directories /bin, /usr etc and there's a well-established convention for placing added software in /opt, a filer share, removable media etc.
An advantage of AppImage is that they don't change the system package database and can be run from /opt a share or removable media.
Yes, there needs to be a mechanism for update of third-party applications. ~/apps isn't it.
Imagine in a corporation that uses Linux desktops, 1,000 users clicking to update a third-party bloated electron app to ~/apps.
I just wish the desktop app could send regular sms via my phone.
Having an AppImage for Signal would be nice, but just yesterday I used kdocker to make it create an icon onto my system tray, which I don't think the AppImage would work with.
Unfortunately Signal doesn't do this natively, so I have to keep the window open all the time (and my chats visible to passers-by). I'll pick kdocker for this one, I think.
Unfortunately Signal doesn't do this natively, so I have to keep the window open all the time (and my chats visible to passers-by). I'll pick kdocker for this one, I think.
I don't use the AppImage, but I do use the unofficial Fedora package and it seems to work well.
https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desk...
I believe AppImage does not have an update mechanism which would make it more likely users will end up outdated versions which contain security issues. That is why I am more in favor of flatpak.
It can be possible, JetBrains Toolbox seamlessly auto updates but I'm not sure how they achieved it. On the other hand, maybe it is not so easy, I wish use the rpcs3 AppImage and have never had success with it's built-in update feature.
The AppImage documentation mentions auto updating an electron-builder image is possible: https://docs.appimage.org/packaging-guide/optional/updates.h...
The AppImage documentation mentions auto updating an electron-builder image is possible: https://docs.appimage.org/packaging-guide/optional/updates.h...
Is there some particular reason why it's not in the distros repositories or is it just a case of nobody has stepped up to do the work yet?
signald[^1] + signal libpurple plugin[^2] (finch, pidgin, adium, bitlbee, etc) works beautifully.
[^1]: https://gitlab.com/signald/signald
[^2]: https://github.com/hoehermann/libpurple-signald
[^1]: https://gitlab.com/signald/signald
[^2]: https://github.com/hoehermann/libpurple-signald
Each time I tried something like that I had to authenticate every devices again. But maybe I am doing something wrong.
For the life of me I can't see why people use this over Matrix. But if it was because you want an AppImage for the client, then here: https://appimage.github.io/element/
Because in contrast to Matrix it looks much more accessible to the average user. Not all of my friends are in IT and want to/are able to use matrix.
Signal is also nonprofit, fully opensource and minimizes metadata to a minimal amount (e.g. [0]), so it might not be as good as Matrix, but it's certainly not as bad as Whatsapp.
[0] https://signal.org/blog/sealed-sender/
Signal is also nonprofit, fully opensource and minimizes metadata to a minimal amount (e.g. [0]), so it might not be as good as Matrix, but it's certainly not as bad as Whatsapp.
[0] https://signal.org/blog/sealed-sender/
I find Matrix to be super abrasive to use. Weird popups asking me about encryption, missing messages, and a confusing UI. I'm a nerd, and I find it baffling. Feels like it needs a UI stripdown. Something like Telegram is way more intuitive to use, but obviously not fully free on the backend.
Fluffychat is a Matrix client with a much simpler UI. I've been testing it for a few days. It's still not to the level of Telegram, but it looks promising.
The problem is that having multiple clients for a given platform is confusing for non-technical users. Most users will give up after they have failed with the first client they found, especially if alternatives like WhatsApp etc. are easier to use.
That's the first time I see this client mentioned. Maybe in a few years, the dust will have settled and there'll be a prominent Matrix client that's the obvious choice for most users. I don't think it'll reach widespread use before that.
That's the first time I see this client mentioned. Maybe in a few years, the dust will have settled and there'll be a prominent Matrix client that's the obvious choice for most users. I don't think it'll reach widespread use before that.
FluffyChat is promising but is missing some pretty key features such as sending files and calling. I can't wait until we have some really easy to use and fairly complete clients because I agree that Element is a bit much. Even as a power user I wish it was a bit less noisy.
Because I can install Signal on my Grandma's phone and it "just works". Sharing pictures, phone calls, etc, all work the same way she's used to.
Matrix is just not there yet. Hopefully soon, but not now.
Matrix is just not there yet. Hopefully soon, but not now.
I've spent the past half hour reading up on Matrix again. What about the metadata issue? Seems like Signal goes to great lengths to ensure that the only data they have about a user is their phone number and the most recent day they connected to the network.
Meanwhile, Matrix servers just ... log everything by default? https://github.com/matrix-org/synapse/issues/4565
Meanwhile, Matrix servers just ... log everything by default? https://github.com/matrix-org/synapse/issues/4565
The setup for Signal is basically just two steps: Open Google Play / App Store, click Install, open app and confirm SMS code (automatically handled on iOS and probably also Android). You search for other users with your existing phone contact list. How easy is the Matrix setup?
There's some major issues with Signal right now.
1. Signal was used by Chinese dissidents and were whisked away by the CCP. The most likely proposed method was that the GBoard (google soft-keyboard) was "updated" with a poison update that uploaded everything typed. What defenses does Signal have against that? And will Signal warn against unverified GBoard updates that haven't been vetted?
2. Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
3. Signal still demands/pesters the user to share the whole phonebook with Signal. Anyone who does gets notifications when their phonebook shows up on Signal. And when you show up on Signal, everybody else is also told you're there as well. (Massive domestic abuse issues here)
1. Signal was used by Chinese dissidents and were whisked away by the CCP. The most likely proposed method was that the GBoard (google soft-keyboard) was "updated" with a poison update that uploaded everything typed. What defenses does Signal have against that? And will Signal warn against unverified GBoard updates that haven't been vetted?
2. Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
3. Signal still demands/pesters the user to share the whole phonebook with Signal. Anyone who does gets notifications when their phonebook shows up on Signal. And when you show up on Signal, everybody else is also told you're there as well. (Massive domestic abuse issues here)
> Signal was used by Chinese dissidents and were whisked away by the CCP. The most likely proposed method was that the GBoard (google soft-keyboard) was "updated" with a poison update that uploaded everything typed. What defenses does Signal have against that? And will Signal warn against unverified GBoard updates that haven't been vetted?
If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
> Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
> Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
> > Signal was used by Chinese dissidents and were whisked away by the CCP. The most likely proposed method was that the GBoard (google soft-keyboard) was "updated" with a poison update that uploaded everything typed. What defenses does Signal have against that? And will Signal warn against unverified GBoard updates that haven't been vetted?
> If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
There are also open source and 3rd party repos (F-Droid) that could provide properly vetted soft keyboards. And I'd also mention that Signal is not available on F-Droid or Guardian Project's repo.
And Signal can also run basic checks for sanity of the system, and loudly warn if things aren't as the application expects.
> > Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
> The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
All of the encrypted comms goes through their servers. They also prevent others from running federated Signal servers. That would lead that they have access to both who, where (ip address), how long (by length of encrypted data), and with whom.
The same metadata was/is the basis of the NSA's spy projects. Metadata is just as important as the very content.
> If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
There are also open source and 3rd party repos (F-Droid) that could provide properly vetted soft keyboards. And I'd also mention that Signal is not available on F-Droid or Guardian Project's repo.
And Signal can also run basic checks for sanity of the system, and loudly warn if things aren't as the application expects.
> > Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
> The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
All of the encrypted comms goes through their servers. They also prevent others from running federated Signal servers. That would lead that they have access to both who, where (ip address), how long (by length of encrypted data), and with whom.
The same metadata was/is the basis of the NSA's spy projects. Metadata is just as important as the very content.
You can't call 1.) an "issue with Signal". It is not even correct description. It is an issue with any messenger app on any device or OS that installs automatic updates of anything from CCP.
1. That isn't an issue with Signal or something that Signal could fix. Every messaging app will have that problem.
2. That is an issue but they do have their reasons. They are working on implementing a username system that does not depend you giving them a phone number.
3. That can be solved once they implement usernames. Until then a workaround can be to use a Google Voice Number or a burner sim.
2. That is an issue but they do have their reasons. They are working on implementing a username system that does not depend you giving them a phone number.
3. That can be solved once they implement usernames. Until then a workaround can be to use a Google Voice Number or a burner sim.
It will also be interesting to see the p2p Matrix version, since they also use the same encryption tech as signal (it's equally private) and won't rely on centralized server.
https://snapcraft.io/signal-desktop