💬 Discussion | How many platforms does signalapp REALLY support? #967
Comments
|
The question becomes more complicated by thinking about different use cases. If I wanted to replace Facebook WhatsApp with Signal, I would be interested in knowing that it can work without a persistent connection to my phone. However as I am not doing that (having replaced it with Wire), the feature doesn't matter to me that much and if I was recommending a IM app for someone without a smartphone (those people do exist, there are a few in my circles), they could install Signal desktop, but they couldn't use it assuming they aren't that technical or inclined to install Signal Android in a VM. I think the solution is having a small print saying that Signal Android/iOS is required for account creation/management + X platforms can be linked to that account. (This needs a better formatting though). |
It's worth noting that while they say this, it also does work on other systems that support Flatpak. I use Fedora and Signal launches just fine. |
Yeah, I've tried to think what it is called that signal is doing :-) But I'm not sure that there is a word for it. It is cross-platform, and officially supports five platforms, but it is not cross-platform-in-the-abstract ... it is cross-platform "in practice" though, for typical use-cases. The closest thing I can come up with, is client-server software... by analogy, it is not very exact here... but consider what the requirements are for RiotIM which is a client. It runs from any of the following platforms: Firefox/Safari/Chrome, FDroid/playStore, iTunes, electron4osx, electron4win7x86-32, deb8+, ubuntu1604+ ...However, all the metadata is exposed thataway. If you want to have a groupchat that is not exposed to server-side compromises like the one in April, you have to self-host your own Synapse homeserver, and (from another domain) self-host your own RiotIM install. Needless to say, you cannot self-host Synapse from Firefox! But... well, to me that means, RiotIM doesn't "really" support being run from firefox, at least one person in the groupchat needs to be running something more beefy. Bob can just flip open firefox, but only if Alice has installed and configured Synapse and self-hosted RiotIM for Bob to use! Which has different system-requirements: deb9+ (not deb8), win7x86-64 with docker (not 32-bit sans docker), docker-or-hand-compile for OSX (not pre-built), and you need a real OS not a browser and not a smartphone :-) If you want to run riot in a privacy-conscious fashion, you need to have at least one person that is running a server, and probably it is going to be a linux-based server PC, though you can use the VM trick or the hand-compile trick to get it to work on OSX and Windows. Does that mean that Riot doesn't support mobile? No... it does... just, for privacy-conscious Riot groupchats that don't leak metadata, SOMEBODY has to be running a linux PC-or-VM, at least one somebody per conversation. Signalapp is like that, in a way. Signal4desktop is no use unless SOMEBODY is running signal4smartphone that it can link unto. It doesn't have to be the person using signal4desktop, they can "borrow" the samsung SecureFolder app on a trusted friend's android device and not interfere with their friend's signal4android install. But there has to be somebody in the group, who is helping the folks that do not have their own master-device, have some kind of master-device.
For people that literally have no phone-num -- including landlines and voip and so on -- and refuse to acquire one, like @libBletchley in #779, signalapp is dead in the water. But for 99.99% of humanity, they are in one of two situations:
Most of which are (unofficially) documented at community.signalUsers.org -- there are a LOTS of ways to get some kind of smartphone-OS-plus-separately-a-valid-telco-num, without actually owning a smartphone yourself personally. Most people that are in the very-privacy-conscious category can usually come up with a combo of 1) some telco-num acquisition method they are comfy with, and 2) some android-app-install method they are comfy with. Often there is a hassle-factor, sometimes a big one. Installing your own gApps-free privacy-oriented ROM and acquiring a simcard from the Netherlands or CzechR or the USA or whatever, then sideloading the signal.org APK, is obviously more of a pain than just pumping in your cellnum to register and installing on your iphone :-) But by comparison to the hassle-factor of installing your own Synapse homeserver and your own self-hosted RiotIM and getting them all configured correctly/securely, to me signalapp is still way ahead.
Yeah, this is "unofficial" but derived from the officially-supported .DEB -- plenty of people run AUR packages for Arch-and-spinoffs (doubly-unofficial), and some people use Snapcraft.io (unofficial), and whatnot. Signal4desktop does run on pretty much any Linux distro that is capable of handling electron, you can even hand-compile for 32-bit x86 if necessary. |
I am also using the Flatpak (on Debian Testing), but it's unofficial and there is open feature request on it at signalapp/Signal-Desktop#1639. For Snap users there is signalapp/Signal-Desktop#1798. (edit: I didn't notice five-c-d said the same above (without the issue refs though), I still don't handle so long comments especially at 01 at night, good night) |
|
I hadn't noticed that we are actually saying that "Mobile: Signal" supports Windows, macOS and Linux in addition to Android and iOS. |
Mikaela
added
🐛 bug
ℹ️ help wanted
🌐 website issue
Yes :-) sorry about that.
Yeah, I figured that was intentional: say in the title it is for "mobile" but then say in the platforms it supports "droid+ios && lin+win+osx" which is pretty confusing at first... but then later, when the readership actually looks into the details of installing, they find out, oh you have to install mobile first before you can install desktop because it is a slave-device-only kind of thing. My suggestion is that we indicate the distinction with parentheses:
So in the IM listings it would look like this:
Although I tried to use the HTML abbr-tag to annotate each of the little icons, I'm not sure it is working in github's mangling of the gfm ... but here is what the signalapp row in the table above "should" be displaying when the mouse is hovered over the little icons:
Thataway, with the icons we can have a nice dense recommendation-card, but people that want more details about what the parentheses mean (or what the p.s. I don't like listing windows-platform first and libre-codebase last. If you have the code, you can (with the correct skillset) port the project to ANY platform needed, and in the long run that is what happens with successful libre-licensed projects. So that should be listed first. Windows10 is explicitly anti-recommended in the OS listings, Linux is explicitly recommended in the listing. However, because the everyday readership is more likely to own a smartphone-OS than they are likely to own a laptop-OS nowadays, we should probably list mobile OSes prominently. My preferred layout would be something like this:
That two-row arrangement puts windows by the warnings, and firefox+linux by the source-code, with apple somewhere in the grey area between the two poles :-) |
|
@Mikaela would the BUG tag be really appropriate here? |
|
I cannot see your Windows emoji on phone and I think mobile users need to also be thought of if there isn't some webfont. I see it as a bug that someone can install Signal on desktop and expect it to work standalone without a smartphone, but please feel free to relabel. |
Oh then it is okay, I just couldn't initially find why you labelled it as such. |
Right, the main questions of this github-issue, are
Currently the listings reflect answers of "Yes, Yes, Yes, Yes". My recommendation is that they should be changed to "No, YesWithParens, Yes, YesWithParensAndTilde".
Wireapp would get parens around their "beta/experimental" linux-desktop-client. Threema would maybe get double-parens and double-tilde because they don't have a desktop client... but they do have a webapp which is often good enough? There are lots of way to annotate the platform-icons with nearby punctuation, to better express what degree of support each platform has from the tool in question.
Yes, no doubt. :-) I was just using unicode-emoji because I was too lazy to create imagefiles, which are tougher to cut-n-paste. My suggestions are, in order of "importance"
But the use of unicode codepoints was just me being lazy, not because, I think the icons themselves should be switched. I don't dislike the current icons (except the github-one seems overly specific and the desktop-lcd-one seems not specific enough to my mind). I would like to have alt-tags on every icon, so that when I select a recommendation card and then copy-n-paste into a text editor no information is lost ... this also helps readership that have screen-readers for vision problems get the info they need. |
|
We use Font Awesome FYI |
|
How would you mark Android/iOS (tablet) linked to the main phone (if it gets supported)? Or would there be a need if it was the same app and thus just had an option for this? |
Depends on whether privacyToolsIO considers "100% tablet-support" to be a dealkiller feature, or just a nice-to-have. To me it is a nice-to-have, and not something worth putting de-emphasis parens nor approximately-only tildes to indicate. Instead I would just mention it in the tooltip-text, or in a footnote perhaps.
Going with the footnote route, there would be a little asterisk or caret thing, towards the top righthand corner of the platform-icon. But if the plan is to implement hover-or-longpress to get platform-specific details like minimum version and whatnot, to me it makes sense just to explain tablet-support right in the tooltip. Might become too wordy though, for smartphone screens when the readership is on the go?
Not a significantly-large-slice-of-the-userbase to need explicit dedicated annotation of the platform-icons, I would argue. rationale and links
I think that tablet-support is a niche thing, albeit not quite as niche as WinFon support. There are some people that have a tablet, yes, but 99% of the time they ALSO have a smartphone... and more than 90% of people with both kinds of device, use the smartphone-device way more than they use their tablet-device. Making a cryptocall from a tablet-device, while possible is not something that most people are likely to want to do :-) Like IM webcam chats from the late 1990s on enormous CRT displays and tower PCs with ethernet cables to a university backbone-connection, it is a bit masochistic-feeling, when it works at all! Threema officially supports android smartphone, android tablet, android watch (severe limitations), android automotive, apple smartphone, apple tablet, apple watch (severe limitations), but not apple carplay. They also have slave-device threema-web, which I believe is reverse-tethered in the whatsapp manner since they have a warning "may drain your battery [of your smartphone]. But when you look into the details, there is not REALLY tablet support... just like with signal4tablet, threema requires a distinct identifier for every master-device, and if the enduser screws up they usurp their underlying telco-num-or-email identifier within threema, screwing up their smartphone-install. Also like signal4desktop which only offers async voiceNotes support but not quasi-realtime cryptocalls, threema4web has no cryptocall support, and neither do the "second-class-citizen" platforms like winFon. Signal4android has a slight advantage over threema, for privacy-conscious endusers that have removed playServices: incoming cryptocalls still work with https://signal.org/android/apk on an FCM-less device, whereas threema-calls require playSvcs be installed. Overall though, both are pretty similar. Threema has "official support" for tablets with secondary identifiers, and for WinFon-of-the-smartphone-variety, whereas on signalapp tablets are "officially unsupported" but usually work fine as long as you use a secondary telco-num to register, and WinFon10 support is only available via unofficial soft-fork. My understanding is that whatsapp is in a similar vein, but has stronger platform-breadth (e.g. until recently supported old-school Symbian handsets!) There are a lot of messengers that "fully support" tablets, in the sense of being able to fire up a client on the tablet which will link/sync to the exact same messages that are on the enduser's smartphone... but most of them seem to be non-end2end encrypted, or have significant penalty (telegram has tablet-support I believe... but no end2end crypto for groupchats and only device-to-device crypto when you do enable the off-by-default MTProto crypto). RiotIM is more of a web-app than an APK, so it pretty much supports a tablet because a tablet has a browser... but the key-management is a pain, because keys are per-device, right? Apple lets you have iMessage+Facetime on your iPad which sync via the iCloud to your iPhone ... but of course, as with all apple stuff, you can only contact other iDevices so as soon as a person with an android tablet and/or android smartphone joins the groupchat, Apple's sync-with-my-tablet support instantly dissipates because they don't permit non-apple-hardware to encrypt anything. Wireapp might have proper tablet-support, where you can install a master-device tablet, and then sync to a laptop, never needing a smartphone nor a phone-num, no limitations in terms of loss of features nor difficulty with key-management? p.s. I never knew this: "the open source project links against the open source Wire audio-video-signaling (AVS) library. The binary Play Store client links against an AVS version that contains proprietary improvements for the call quality" This would cause me to instantly put parens around the "source code" icon for wireapp ... just like Oracle JRE on windows, and Google Chrome, they embed proprietary components as the secret sauce. OpenJDK for linux and chromium are just "reference implementations" which are subtly crippled... am disappointed to learn that wireapp does the same sort of thing. Signalapp has some proprietary dependency on GoogleFCM, and battery-life suffers when not using that on a handset with playServices exorcised -- sometimes severely -- because there is a background-socket open to signal-server alone in order to detect incoming cryptocalls and texts and whatnot. So it is hard for any app that wants to be used by the masses, to REALLY be 100% libre-licensed to the max. But it sounds like (heh! pun) wireapp devs are specifically writing a proprietary audio-codec for their own playstore APK only, and only people that hand-compile get the reference-implementation crappy-quality codec. This is not a limitation imposed by the platform, this is a conscious monetization-strategy methinks, in the long run. |
|
Shall we wrap up this conversations and make a decision, having a bunch of stagnent silent issues won't solve privacy. |
|
What is your proposed wrapup? My preference would be having the requirement for Android/iOS be clear and that there are remotes for the other platforms. |
|
Seeing as Android or iOS is required I would imagine only listing the mobile client icons would be more helpful for those looking for options at a glance. |
* voice-video-messenger: remove duplicates with instant-messenger also move Tox and Jami to Instant Messengers, Change Jitsi to Jitsi Meet * instant-messenger: remove platforms of Signal Desktop https://github.com/privacytoolsIO/privacytools.io/issues/967#issuecomment-520268788 * instant-messenger: add indepedent security audits * voice-video-messenger: mention that many are already listed above * instant-messenger: fix formatting & mention features of Jami * voice-video-messenger: list Mumble * update source_code.md * voice-video-messenger: fix card * add Mumble.png * Small revisions to the instant messengers * Spelling! * voice-video-messenger: add a warning on Jitsi Meet WebRTC * instant-messenger: remove a from Jami * instant-messenger: add VoIP badges * Use updated label functionality The labels/badges functionality added to cardv2.html in cbe5de4 work better here. * Fix Jitsi Meet warning badge
From a pull-request comment by @Mikaela, the question came up as to whether Signalapp supports five platforms, or really just two platforms.
The answer is complicated. Per signal.org/download , Signal Foundation officially supports
The way that the laptop-n-desktop flavours are supported, though, is a bit strange!
signal4desktop is a slave-device... but, it operates fully standalone in MOST usage
By contrast, most other software projects that implement IM for PCs, let you install them, register them, and use them without any smartphone. As usual, there is a privacy&security-rationale explaining why signalapp works the way it does: because your signal-num is directly mapped to an underlying telco-num, and registering that signal-num requires you to receive an inbound robo-SMS (or robo-call if you register via a landline-num or whatever), that is where your master-device cryptographic key-material is stored. Many/most smartphones nowadays have hardware-backed keystores and on-by-default full-disk-crypto and hard-to-bypass biometric unlocks and various other security measures.
The vast majority of laptops and desktops do NOT have those things out of the box, and since signalapp is aimed at everyday endusers, and trying to keep them secure DESPITE their use of win7home sans any drive-crypto with 1234 as their Administrator password ... signal4desktop is treated strictly as a slave-device. You cannot register it, you must link it to a smartphone master-device (or an unofficial workaround is to use AsamK/signal-cli or perhaps an android emulator or whatever). However, signal4desktop does not require that your signal4smartphone be there physically present, nor even that it be powered-up, during USAGE. The smartphone master-device is required when you first install signal4desktop, and for certain features that signal4desktop does not implement yet such as cryptocalling and groupchat-management functionality.
But for 90% of what folks want to use signal4desktop to do, including texting + file transfer + voiceNotes + videoClips + etc ... you can be working on your laptop in signal4desktop, and have your phone in airplane-mode (or even powered off with the battery physically removed sixteen blocks away) and everything works just fine. You cannot uninstall signal4smartphone and never use it again, things will start to break when signal-server detects you are no longer getting APNS/FCM notification-popups, or something like that(?) and this results in problems.
For practical reasons, you will want to have your smartphone powered-up and internet-connected every few days at least, so that it can "catch up" with all the message-sync'ing of stuff you have been chatting about over in signal4desktop on your laptop -- because signal4desktop is a standalone slave-device, that means the smartphone needs to decrypt and process message-traffic itself. And vice versa: if you install signal4desktop on your laptop, and then never open it for six weeks, it will be unusable when you DO finally open it for several minutes, because of the way the double-ratchet perfect-forward-secrecy crypto works it will have to download and decrypt all the message-traffic that it missed! Lots of CPU time, and usually quite a bit of dinging&buzzing :-) There are some queue-limits, if you get more than a few hundred messages to any of your linked devices, without checking them, signal-server will discard your copies, and you will have to get the info from your contacts (the sent-message will still be on their device(s) which they linked).
At the end of the day, signal4desktop works fine on Linux -- you get LineageOS or GrapheneOS or stock android handset, install signal4android, register with your choice of telco-num (for maximum privacy I recommend a secondary-num which is not linked to your identity). Then you put your choice of Debian-compatible Linux distro on your laptop, install signal4desktop, link it to the smartphone-based master-device, wait a couple hours for all the contact-sync and stuff to fully complete, and get busy. ("Unofficially" you can also get Snapcraft for multiple distros, Flatpak for RPM-oriented distros, AUR precompiled-binary and source-based packaging for Arch&friends, and so on... if you are a desktop Linux enduser you will probably have no real problem getting signal4desktop up and running despite 'official' support only being offered for Debian-based flavours.)
If you don't do much cryptocalling -- or are satisfied with voiceNotes rather than quasi-realtime cryptocalls, and you aren't in a lot of constantly-churning groupchats where you need to be clicking NewGroup and LeaveGroup all the time, signal4desktop will be sufficient for you 99% of the time. Personally I tend to spend about 90% of the time in signal4desktop, and I actually like the master-slave thing because when I am on a cryptocall with signal4android on speakerphone, I can simultaneously be touch-typing in a chat with that same person (or in a large groupchat perhaps) from a fullsize physical keyboard and large display. If necessary, I can still get all the groupchat messages right in my pocket, of course, via dataplan or wifi-at-the-library or whatever when I am mobile and don't want to haul out the laptop.
TLDR: the way signal4desktop works, is that it has been designed to act as a slave-device to signal4smartphone: they are intended to work in TANDEM as a pair, each of them handling what they are good at, letting the enduser select the proper tool for the job, and switching tools or using tools simultaneously as the situation merits.
Correct, using JUST signal4desktop, is a *temporary* situation
Once installed and linked, each of your devices (max 6 if memory serves) can work independently of the others, you don't have to have one powered-up to use the other... and if you lose your master-device, all is not lost, just get a replacement and restore your encrypted-backup-blob when you re-register your telco-num, and you won't even need to re-verify safety-nums. If you don't have a backup-blob, or lost your piece of paper with the 30-digit decrypt-passphrase, you can start fresh as long as you still control the underlying telco-num, but (as is proper) your contacts will all see the key-change alert "Your safety-number with +1-111-111-1111 [Mikaela] has changed."
But yes, the way signal4desktop works, is as a slave-device. You need to have signal4smartphone as the master-device. That doesn't mean you have to use an actual physical handset type of smartphone, there are unofficial workarounds such as installing android in a VM or using unofficial sig-cli.
Does that mean Signal is "only for mobile" like the privacyToolsIO listings currently say? No, it works fine on desktops, just, you also need to install the app. Is signalapp "truly cross-platform" in some abstract sense? No, you always need to install signal4smartphone, and officially it needs to be on a smartphone, tablets are unofficial, VMs are unofficial, downstream CLI-oriented projects are unofficial, etc.
So from my perspective, Signal is "pragmatically cross-platform" pretty much: the everyday enduser will be able to install it on their home PC (assuming they fully trust their roommates!), and also on their work-laptop (assuming they fully trust their coworkers!), after installing it onto their smartphone, and everything with JustWork
It functions well, and makes sense, but is a bit jarring of an architecture, if you are coming from skype-land or something, where the desktop is primary and smartphones are an afterthought-kludge.
On the other hand, refugees fleeing the burning ship known as facebookWhatsapp tend to be right at home in signal4desktop, because like whatsapp the smartphone is the master-device, but unlike whatsapp (which is reverse-tethered such that whatsapp4web running on a laptop basically remote-controls their whatsapp4smartphone apk) signal4desktop is standalone during use, you can send and receive messages on your laptop WITHOUT eating battlife and dataplan-cap of your cellphone.
Signalapp officially supports five platforms, but two of them are master-device platforms, with the other three of them being multi-device-sync-set platforms.
various helpdoc-type forum threads
The text was updated successfully, but these errors were encountered: