I cannot run another Electron app on my computer, I simply do not have the RAM left. Signal as a web-app would allow me to put it inside of Franz or Rambox, where all my other chat services live.
Right now Signal is the only chat service that I cannot run in Rambox or a browser.
All the other major chat services provide a web-app that can run in a browser:
- messenger - whatsapp - wechat - hangouts - skype - zulip
These apps all have web versions for good reason, a website is the most versatile, portable way to share an application with users who's devices you cant support individually. If a user's chrome extension gets hacked a steals their messages that's their fault, it should be the choice of the user whether they run the app in an insecure environment. After all, you're relying on them to not have keyloggers or rootkits on their computers that run the desktop app.
I don't see any reasoning for Signal to not follow WhatsApp's model and release a web-app that links to your phone.
The service (either intentionally or by virtue of being hacked) can serve up Javascript crypto code that either uploads plaintext, or subtly backdoors the crypto so it can be decrypted. And they can do this to just a single user, so unless you audit the Javascript every single time you load the page, you'd never know.
A signed app is more secure, because a backdoor would have to be distributed to everyone, greatly increasing the chances of it being discovered.
Furthermore, we're using their website to download the Desktop app, the binaries are neither signed by them nor by Apple (or macOS). So the threat model is "almost" the same here as a web app here except for:
* CSRF would not work on an Electron-based app.
* Trusting an Electron-based app is a one-time thing (close to a Trust-On-First-Use trust model). (thx Nik Kinkel for pointing that to me.)
[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
That said, at least they have the option of closing that hole with the electron app.
You could indirectly solve this problem by making some sort of electron multiplexer that could take multiple electron apps and make them share the same electron host browser, achieving the same thing you have now.
I personally just use a bluetooth keyboard and my phone. I get a native app, keyboard typing and nothing hogging resources on my computer.
A fresh launch without logging in or having it run for any period of time immediately uses 211.2MB:
1. Signal: 58.3MB
2. Signal Helper: 128.6MB
3. Signal Helper: 24.3MB
- It said it was 'Importing contacts and messages' when I signed in without first prompting me if that was OK.
- Importing contacts and messages failed.
- Manually importing contacts fails.
- Conversations show up, but each message just shows as an error.
- Deleting a conversation doesn't delete it, it just makes it as read.
- Messages marked as read randomly reappear as unread.
- Incorrect unread message count next to conversations list.
- Messages often don't arrive at all, seems at random.
- The application loses it's 'link' to your account seemingly at random upon launch and needs to be relinked.
- Appears to use an outdated version of electron with published security vulnerabilities.It uses 130MB RAM here (Win). How much is it on your side?
We seemed to get by with MSN Messenger with far less RAM, and the features were pretty much identical.
It boggles the mind how memory-intensive some of the modern apps are. It's insane.
It seems to me that many Electron apps these days are super-thin wrappers around a web app that don't actually need the full desktop access offered by Electron (things like local filesystem access, multi-process execution, multi-window management, arbitrary node APIs, etc).
They just need a way for users to "install" the app so that it 1) has a separate shortcut and appears in a separate window from the browser, 2) can send notifications through the native notifications stack, and use a fallback on systems where one isn't available, 3) is available for use offline.
The Progressive Web Apps spec has answers to all of these problems, and it would vastly improve the resource usage model compared to Electron because each PWA would share the same browser runtime as the user's browser of choice, which is more likely than not running 24/7 anyways.
Security-minded apps like Signal might need more guarantees such as asset verification and version pinning on install, but surely those could be added to the spec, as they would be beneficial for other Progressive Web Apps as well.
I know PWA was designed with mobile apps in mind originally, but it'd be a shame to limit it to that use case, as there is clearly a lot of demand for building desktop apps with web technologies, and PWA sounds like an excellent alternative to the current status quo that's dominated by Electron.
The web platform is a really great example of backwards compatibility - it has to, because people wouldn't tolerate breaking changes to websites. Browsers (and Electron) have made a lot of progress in the last years, but now I think this platform is very capable and you can get a lot done without waiting for a new feature. This makes something like Electron a good candidate to ship with the OS. Remove the burden of updates from the individual vendors, and use a lot less disk space and memory because there is only one runtime.
I don't see installable Electron any time soon, but interestingly Edge might fulfill that role on Windows (if it is compatible and PWAs are powerful enough to replace most electron apps).
Signal support is coming later this year. Right now it supports Slack, Skype, Facebook, and Gmail.
So this isn't light or native. It uses the same Chromium codebase, but atleast twice the size of Electron apps.
https://hardbin.com/ipfs/QmNttGPf65DZ3eeuNCCWemrxyNzaHxLhpAZ...
If the rest of you are wondering where the bulk of it came from, check libcef.so (466 MB)- which is Chromium Embedded Framework.
Franz https://github.com/meetfranz/franz
These are similar apps. Though they do use Electron, they let you share one Electron instance for all your chat services.
window can't be resized, standard menus are missing, standard keyboard shortcuts for text fields don't work, conversion text can't be selected, no way to cut or copy text (tho paste does seem to work).
is it implementing its own ui toolkit? qt maybe?
I could understand if it was a GB or so, but in this day and age it's USD 9c or less worth of disk space (assuming you use high end SSDs, if it's a HDD then it's under 1c).
I am very privacy conscious, and I don't use a smartphone, at all, because it's basically a spying device in your pocket.
Why Signal is all about privacy and then it forces me to pair it with a telephone?
Telegram desktop is really standalone. They require a telephone number too (and that's very annoying), but they don't require having a smartphone or keeping your phone open. My phone number on telegram is not even my phone number anymore, and it doesn't make any difference... Privacy wise is far from being perfect, but it's already better. At least it's usable.
So I guess there is a way to use signal without having a phone nowadays! That's a great news!
I will try right now.
How did you evaluate Telegram to decide that you trust it?
It’s got a pretty bad case of kitchen-sink flat ui, but is otherwise not bad.
I know it's open source, but modifying it and recompiling all the clients I'm using would be very annoying.
My personal computer runs an open source bios (coreboot) with an open source operating system (linux) and no closed source software (at least one of my PCs does). My phone on the other hand has many processors running on it (that I know about) that can interact with my device without me knowing and binary blobs (yes even with lineageos and with microg) that I can't control and many parts I can't update or update as fast/easy as my pc.
My point: for most people the attack surface of the smartphone is far larger than the attack surface of the PC
To me it's simpler and works better than Signal while being decentralized and federated. It has excellent clients for all platforms (and these keep measages in sync with each other) and does not require a phone number.
There's a fantastic one in the works, qmatrixclient (quaternion: https://github.com/QMatrixClient/Quaternion), but it doesn't support E2EE yet.
The developers badly need to invest in a UX engineer, but are currently stuck scrambling for money as their corporate sponsorship ran out.
I've also stopped using an IRC client and just use a Matrix bridge. Really happy so far.
Main drawback is that E2E is a bit clunky to set up, and downright confusing for non-technical users.
For an app that is supposed to be the pinnacle of secure messaging, leaving anything unencrypted on the local device is just breathtakingly negligent.
The way moxie ushers people to take the discussion elsewhere doesn't help either. It just reinforces the perception that he doesn't care.
The people in the report (not necessary the original submitter, the "Now I'll go and tell everyone to uninstall Signal! There you have it!" crowd) seemed to be demanding/whining and spammed a bug tracker with random anecdotes and their personal agendas in a rather rude way.
Whereas moxie - again, in my opinion - replied in a very friendly, objective and calm manner and invited these people to discuss the issue further. In the _right place_ for an open debate about design decisions.
https://chromereleases.googleblog.com/2017/07/stable-channel...
https://chromereleases.googleblog.com/2017/09/stable-channel...
https://chromereleases.googleblog.com/2017/10/stable-channel...
Guess you can never please everyone.
But in all seriousness thank you for the great work, this is excellent news!
$ curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
$ echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
$ sudo apt update && sudo apt install signal-desktop(To be a bit more explicit: searching for either the pub (57F6FB06) or sub(0E46390F) keys on hkps.pool.sks-keyservers.net returns no result)
It's ludicrous that you can't download a security-focused app when your browser settings are unusually secure. ;)
Inspecting the app, it appears to be just another Javascript app (Electron).
Oh come on guys. Don't forget Fedora. Fedora means SELinux. SELinux means you are getting the people who value security.
Proper, very strict sandboxes implemented with seccomp & friends are much more secure. You simply block the large majority of system calls.
Surprisingly, they are often easier to set up.
Maybe that's just me, but it's good news!
So, you're migrating from Firefox to multiple instances of Chrome...
Am I the only one who thinks this defeats the whole point?
Signal feels slightly like the pigs in Animal Farm getting everyone riled up against the unjust farmers, only to take their place.
edit: And anyways, if you read their blog posts you can see how you phone number is only required to make it easy to connect for the masses. You already have your social graph in your contact book.
Really happy to have it as a standalone app outside of Chrome now.
https://github.com/WhisperSystems/Signal-Desktop/issues/1632
Also a bit annoying that it can't be run in the background, at least on Windows.
https://whispersystems.discoursehosting.net/t/new-desktop-ap...
The solution is to build a common Electron runtime that all Electron apps can use. But it seems nobody is working on it despite all the complaints.[1]
I really don't understand why there isn't anybody working it. If that got implemented, it would put a swift end to the biggest complaints about Electron.
Qt, Gtk, .NET, Java, Android, Cocoa, UI Kit, KHTML, even crufty old Motif had such widgets.
It is just web developers not getting native development.
A common runtime would be as if you ran five Node.js apps using the same runtime and opened five tabs in a single instance of Chrome.
I'm not super well versed on the low level implications there, but I find it hard to believe that wouldn't save a lot of resources.
I mean, do .NET apps load up a full copy of .NET and all its libraries into memory for each app you open?
Kinda the Wechat model
So it is not _really_ standalone. You still need a phone. This is still a geeky version of WhatsApp.
In fact, why would I want to use this instead of WhatsApp if they're basically using the same encryption features and I have to trust the same people (who assert that)?
(I don't use WhatsApp, I think it is the worst mankind nightmare.)
Yay...
From the bottom of the main page on their website. I removed the marketing copy.
I'm very happy with it nonetheless!!
Desktop apps are supposed to be: native code, well integrated in the OS, still working when the net is down and using system widgets and OS look&feel.
For me desktop apps are apps that run on my desktop computer, requiring an installation process instead of being loaded via an URL and not subject to the browser's sandbox.
I've had access or owned desktop computers in various shapes and sizes ever since 1993 and let me tell you, since then until now the notion that desktop apps have a unified look and feel is a really recent phenomenon, that happened due to Apple, OS X and the iPhone.
Yes, even Windows 3.1 had standard widgets but historically standard widgets haven't been expressive enough and many developers did not care anyway, especially since most apps were reincarnations of former DOS apps or ports from other platforms. And then the birth of Java made it much worse.
E.g. the most popular MP3 player ever on Windows has been Winamp. Besides the file opening dialog, there was nothing standard about it. Most popular chat apps several years back? ICQ and Yahoo's Messenger. Have you been acquainted with their UIs? In terms of nativeness, let me tell you, the web-enabled Facebook Messenger and Hangouts are improvements, because at least they don't mess up the text rendering.
The Apple HIG dates as far back as the Macintosh. That’s 1987[0]. Visual and behavioral consistency have always been a staple of good design for those who cared.
[0]: https://guidebookgallery.org/books/applehumaninterfaceguidel...
That excludes every single .NET application.
> well integrated in the OS
Don't even know what you mean by this.
> still working when the net is down
Not necessarily, a "native" app for Signal still wouldn't work if the net was down.
> and using system widgets and OS look&feel
I guess that excludes pretty much anything built with Qt.
Sure I can understand the reasons behind it, it's JavaScript, programmers for that are abundant, is multi platform because web, but still. If you look at the functionality offered versus the resources used it's just ridiculous.
I'd like to see a graph of code/memory used vs unused in such binaries.
Thank you but I'll just keep using Wire on the desktop and Signal + Wire on mobile. Too bad, because the mobile version is really good.
Chrysler shouldn't make their tires square just because Ford was first to the circle.
I'm happy they're not burning cycles reinventing the wheel.