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:
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.
In-browser e2e encryption is vulnerable to targeted attacks on specific individuals.
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.
I don't think I agree with you. Here's a way you could make it work: by downloading a signed index.html, and opening it locally in your favorite browser.
If it loads anything from the outside, use subresource integrity[1] to make sure it's sane.
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.)
Actually, an electron app is very close to the security model of a browser. The fact that they do not load code intentionally, does not solve the problem that electron is able to execute injected javascript.
That doesn't fit my personal threat model (dragnet surveillance), so I'd be happy to accept slightly lower security and use a web app. imo they should offer the option of both, but notify users on web that the Electron app is preferred because it's more secure.
They are a small non-profit dev group, and resource wise it's probably not worth it for them.
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.
The issue with doing that though is that most Electron apps don’t use the same version of Electron. I have apps I’ve built that are still running pre-v1 because updating has been too much of a headache.
Microsoft tried to be backwards compatible with msvcrt.dll . It’s just too much inertia. Also you need to be bug for bug compatible or you may break some old app. Apps may even depend upon behaviour you didn’t know was there.
Maybe because it's not clear there is much to had by trying. The pendulum is currently in swing the other way - see macOS ".app" folders, in effect statically linking apps. And the various Linux initiatives to similar effect.
And much of the stuff on the Linux side seems to be driven by upstream (Flatpak in particular has come out of the Gnome camp), and is riding the "containerization fever".
Not sure what I'm missing here, but I see Signal using 37.5MB of memory. That doesn't seem egregious, but I'm also not familiar with what other Electron apps use.
Memory usage isn't well understood. If you are using Activity Monitor on OSX the memory tab doesn't tell you much. Double click the process and look at the "Real memory size". That's a much more accurate picture of the physical ram being used by the process. It is typically much less than what you see on the memory tab overview.
tbh even that is inaccurate because Chromium uses shared memory heavily. The most real'est way to see is to note the total free memory, close the app, then subtract.
Other than the memory usage - these are problems I've encountered thus far:
- 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.
Call me old, but how can a messaging app like this use 130MB RAM? I am exasperated that Skype on my machine is using 109MB with only one conversation window open.
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.
I get what you're saying and I totally agree with the sentiment, but in this case I can let it slide. It's the only practical way to make a cross platform app for Linux, Windows and Mac. They simply don't have the resources to write and maintain (at least) three desktop apps. I can totally understand that a small company has to make compromises like writing their desktop apps in Electron.
That large companies also do this is another story entirely.
I worked for a company that released control software for audio hardware. I was the only GUI developer (the only guy writing the frontend app), and there was another dev who wrote firmware and a network communication library that I used in the app.
The GUI used wxWidgets using C++ and included a 3D section for system layout (using OpenGL). All of the 2D GUI controls for the rest of the system were "owner-drawn" which means that they overrode the ::OnPaint and drew themselves so as to look different than native controls (as audio systems always have to "look different").
This means buttons, toggle buttons, radio controls, control surfaces, sliders, meters, compressor meters, knobs, graphs, charts, lists, grids, EQ control graphs, everything. There were no native controls other than in popup dialogs (like saving/exporting). It redraw every 50ms based on data that it was receiving over the network from a series of hardware, with this data logged and processed in background threads. It used less than 1% CPU and a fraction of the RAM mentioned here for a chat app, even with cached in-memory bitmaps that it generated in code for drawing.
This ran on Mac OS, Windows and Linux. This means a native binary on each system. It can be done.
It is wrong to say that this embedded-web-app way is the "only way" of doing it. Not to be rude, but it just means that the devs can't be bothered to do it another way.
And that was me writing all of it, plus one guy who did the networking library. Two of us.
We did not ship often! Quality is more important to me than being able to quickly fling rubbish out of the door. Anyone can do that.
For audio hardware, you don't want to be grabbing software + firmware updates multiple times a week. You might be on tour with the hardware and changing it whilst on the road is likely a no-no.
I am now at a place where we ship daily, sometimes multiple times (different branches). The emphasis on decent code and quality is now higher than the previous place I worked. The codebase here is also incredibly vast by comparison.
We can still add features quickly but it is of little use if it is of poor quality. What's the point of bad software even if it is quickly shipped?
Telegram has found a way to deliver the same client on both Linux, Windows and MacOS using Qt. One does not need to consume hundred of megabytes of memory to achieve a cross-platform solution.
> "They simply don't have the resources to write and maintain (at least) three desktop apps."
I feel Signal should have implemted the core messaging components as a non-gui program or library or plugin to another Messaging app (e.g. Pidgin). Then if they want their own app, they could have used a lightweight cross platform window toolkit (e.g. WxWidgets or Qt).
Is that really improvement if you need to run a browser to run the app? I guess most of us have the browser open all the time anyway, so adding an Electron app is just one more thing, but I know that Chrome on my machine soaks up a lot more than 130MB ...
I've got a lot of tabs open right now and I'm not sure how to read the memory usage in Chrome's task manager, but Chrome appears to claim to be using about 450MB just for the browser, plus some additional amount for each tab I have open.
Last time I've had it installed it was something close to a gig. But then it became a cluttered monster I rather fear so that's not relevant anymore.
Same goes for this. I'm happy to give that RAM to Signal since what I get for it, is more then worth it and I have the RAM left. It took me more time and headaches to get people to use Signal on their phones in the first place than it will ever for that 130MB RAM.
This is odd. It indicates a badly written application with disregard for resources.
If efficient use of something like RAM is blatantly disregarded, what about more important things like performance-critical sections of code? Would you be happy that it is shoddily written?
The same approach on a mobile device would be widely condemned due to the hogging of RAM. I don't see why the same metrics cannot be applied to desktop software.
Is the solution for badly-written slow software "just get a faster CPU"?
I see it that way: there is a new program for Signal which enables me to sent messages from my PC. It's the first version out there and it just works. This is much more then I've expected.
I would like if it could use less resources, minimize to tray, etc. etc. etc. but for the moment, this is good and the RAM usage is a far less dramatic issue to me than it seems to be to many here.
I mean, there is far worse out there. I sometimes play Elite Dangerous on my other Win machine. There is a community build tool to track your flight route from the games logs (EDDiscovery) and it delivers an endless amount of features. It rests on a pretty huge database. This thing eats up my ram like it's some free gigabyte cake. I even have to launch the game first or it would take forever. It's horrible. The tool is great though and I will have it running when I need it and it does not hurt my remaining experience. I would love if it could use less resources but I won't stop using it because of it.
The mobile aspect is important. Nowadays we are starting to see more non-Android Linuxes on mobile phones (like Post market OS or KDE Plasma), so it is important that messaging doesn't hog RAM.
It's because Electron has taken over desktop app development. While it does significantly lower the knowledge barrier to building desktop applications, it does come with a heavy memory overhead.
Electron lowers the knowledge barrier for people who are already knowledgeable in web development. For others, learning Electron can be far more complicated than learning, say, Vala or PyQt or Tk or even one of the plethora of Java toolkits, just as examples.
Honest question: What's an easy-to-use, popular cross-platform framework with bindings to a sane language? Something like QT/GTK to Python? I hate Electron, but what's the alternative? I used wxWindows back in the day, with Boa Constrictor, and I loved that workflow.
Lazarus: http://www.lazarus-ide.org/
It does multiplatform the right way, that is, compiling natively for every architecture instead of creating slugginess and bloat by forcing software to run interpreted or under VMs. Here are some projects using it.
http://wiki.freepascal.org/Projects_using_Lazarus
Also, both the IDE and generated software can run on different architectures, including ARM based boards such as the Raspberry PI and similar ones. I played with it also on Orange and Nano PIs with just one gig RAM: definitely not fast but useable; it should scream on the Odroid C2 or faster boards. My only wish is having something similar for Nim.
Yeah, as I said in a sibling comment, Lazarus is pretty much exactly how things should work. I share your wish, though, I wish they had Python/Nim/Rust/something bindings.
So I don't know about the definition for popular or sane languages but FWIW Lazarus is a free framework for producing truly portable, native applications for Windows/Mac/Linux/Android/iOs from the same code project. Think FOSS child of Delphi from back in the day.
Ah, yes, I've heard good things about Lazarus. The problem with it is that it uses its own language (Delphi, as you say), so it's got its own ecosystem and things. No matter how good the UI toolkit is, it's not worth giving up all the niceties of a language with an extensive ecosystem, for me.
It's a pity, because Lazarus does seem fantastic for desktop application development...
All it needs is a critical mass of users and the right support from some big names; if Go was developed outside Google it probably won't be where it is today.
I'm not a fan of Pascal, though I really enjoyed using Delphi at work many moons ago, to me promoting Lazarus is also a way to tell other IDE developers that Delphi and today Lazarus got things right; it's not just about the language.
That is actually not a bad amount, the native Telegram macOS client hovers around the same. WhatsApp Web (also built on Electron) consumes a staggering 300-500mb.
What constitues a "bad amount"? It is displaying a series of text onscreen, with a history of messages for each contact. What's it eating all that RAM for? My mind boggles.
That's all very true, but can you point to an alternative? If you were a small team with few resources, and you wanted to ship a cross-platform desktop app, what would you choose?
There ar plenty of portable toolkits out there. Gtk, Qt, WxWidgets, Fltk, Tk, several others, with bindings to more or less any language you may care to think of. And Lazarus/FreePascal, of course.
You may even embed some web-engine. It doesn't have to involve obscene amounts of megabytes and the selling of your soul to the Google monster.
Howdy, glad to hear it’s less for you, that’s a much more reasonable amount of memory to use but are you sure you’re including all active memory from each of its processes / worker threads?
I had a load of problems when I first installed it and tried to migrate. A main issue was that it took a while for the "migrate" function to appear in the Chrome app.
Any reason why there's not more support for the Progressive Web Apps standard on desktop browsers [1]?
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.
It's coming, at least for Edge on Windows. If you add appropriate meta tags, your app will even automatically appear in the windows store.
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).
That's the main reason, I think: the PWA is getting there, but only just now. Discovery (mostly on mobile) and integration (on desktop) is still relatively lacking. Once those are fixed, I'm guessing it will slowly be getting more uptake.
For what it's worth, it only uses that when adding an account initially to display the login webpage. The CEF is not used in normal operation of the app. It appears the app's GUI is created using OpenGL.
That said, I could not get the app to work with Google Hangouts or Facebook Messenger after 5 minutes of fiddling, so I gave up.
Why in the world would they do that? Can't they just launch a normal browser window or something? Downloading 500MB of chrome bloat just to display a login window seems ludicrous.
eul requires cookies for authentication. Initially it was decrypting Chrome cookies, but this was rightfully detected and flagged by antivirus software.
I'll switch to Servo in the future, it's only ~20MB.
Thanks for the links! I knew about Rambox, but wasn't aware of Franz. Looks excellent.
My main problem with Rambox when I first tried it was that it couldn't remember my sessions across restarts for some reason. A quick test shows that Franz doesn't have this problem.
Also, the API for adding new integrations looks delightfully simple [1]! I'll probably take some time over the weekend to try to port over some of the things I use frequently that aren't yet available. Though it'd be even better if it offered a first-class escape hatch to add simple integrations through the app itself like Rambox does.
native in that it's not a web-app, sure, but it sure doesn't feel like a native citizen on the mac.
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).
Right now the focus is on features and performance, but the app is going to be polished before the 1.0 release to have a more native feel: native notifications, shortcuts, textfields, etc.
cool, good to hear. with enough dedication and an eye for ui detail, i believe it is possible to make a custom-widget app feel like a good citizen -- the unity editor is a good example of this, imo. it's a ton of work tho!
(actually, i'm not sure if it's possible to make your app friendly to screen readers w/o using native widgets. maybe?)
if you do pull it off, you'll end up with a great ui toolkit for go. that would be a very interesting thing!
Non-native widgets can certainly be accessible with screen readers and other assistive technologies. But it's a lot of work. You'll need to implement the UI Automation provider API for Windows, AT-SPI for desktop Linux, and the Cocoa accessibility API for Mac. And you probably won't get any of them right the first time. So I think it would have been better not to create a custom toolkit.
I need something like this for my phone. I never used it but I heard about blackberry's messenger app that brought all the messaging services of its day together, why doesn't this exist on every platform today!?!?! (rhetorical, I know why)
Used to, there were a ton of multi-chat-network desktop clients back in the day. Several still exist... Trillian, MirandaIM, Pidgin. Not sure what the mobile scene is like, but this problem was solved decades ago
Those features are important, if your colleagues are using them. You don't want to miss an ironically winking emoji, or a gif showing that your colleague is getting slowly frustrated. It is hard enough to convey emotion and other metadata through text, but you should at least all see the same thing.
if your whole team is using IRC (or using nothing and choosing what to use) they by definition aren't using those "features".
Also, if you're relying on a stupid cat gif to judge your colleagues mental well-being (and you are concerned about their mental well-being), perhaps you need to spend more time talking to them and less time searching for dank memes.
> The interface, features, mobile app, and simplicity
3 of those 4 things I would class as "simple setup/use".
I can imagine someone saying "we switched to/chose Slack/HipChat/etc over IRC because it's much simpler to administer and a lot more user-friendly for people to communicate with the team".
I cannot imagine someone saying "we switched to/chose Slack/HipChat/etc over IRC because I need my daily dose of cat reaction gifs"
My team uses slack because, alongside simplicity, the gif and emoji integration makes for a fun break from the grind. So, childish as it is, we love it.
Genuine question: Why do you care about a few hundred MB of disk space for an app?
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).
This question has already been answered a bazillion times.
- Longer downloads (especially with updates) -> Discord update times are ridiculous, I can't imagine dealing with that for every app
- Slower to launch
- Can't keep the entire program in RAM
- It's Electron so it will use a ton of RAM anyways
Although I understand people don’t like the bloat, the reason why Electron is so popular is because it’s easy for (web) developers to build apps in. Maybe we can drop the dissaproval and work together towards optimising it?
Signal Desktop is not really standalone, because you still need to pair it with your phone. And the phone should be turned on.
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.
Signal Desktop works without having your phone turned on. It acts like a full, independent client after linking it to your smartphone app (unlike WhatsApp, which does require your phone to be turned on).
You still need a phone with a registered Signal on iOS or Android initially to activate the desktop version (sorry if that wasn't clear), but you can turn your phone off after.
Edit: It actually has the option to register without smartphone, but it's only enabled in the debug versions.
Speaking of edits, you should probably edit the misinformation out of your original post, while you have time. It's ranked pretty high up the thread and it's completely inaccurate.
The original poster was correct though. Just because you only need to do it once doesn't mean it isn't required. As a person without a smart phone I can't use it.
Nor would I since it still requires a phone number to use.
You can build it yourself from source. While it's true that the debug version uses different servers, the functionality is there and can probably be enabled in a production build with little modifications.
You can get a google voice number and just activate through that. On iOS you have to type a confirmation code in manually, so there is no need for a debug version there.
The desktop version never required a running smartphone (one might even be able to complete signup using the app in an emulator and a dumbphone or a VoIP provider to receive the SMS, not sure)
Wire seems to have better security, and it’s desktop app doesn’t require a phone number and supports multiple logins. Client and server are open source.
It’s got a pretty bad case of kitchen-sink flat ui, but is otherwise not bad.
Wire has crazy usability issues after sending a few hundred messages. Clients just freeze up and crash. Another issue is centralized metadata collection.
I know it's open source, but modifying it and recompiling all the clients I'm using would be very annoying.
How can you be very privacy conscious yet lack ownership of the phone number that your Telegram account's registered on? Whoever takes ownership of that number can easily lock you out of your account while retaining access to everything you've ever posted.
Here you go: "One major problem Telegram has is that it doesn’t encrypt chats by default, something the FBI has advocated for. “There are many Telegram users who think they are communicating in an encrypted way, when they’re not because they don’t realize that they have to turn on an additional setting,” Christopher Soghoian, Principal Technologist and Senior Policy Analyst at the American Civil Liberties Union, told Gizmodo. “Telegram has delivered everything that the government wants. Would I prefer that they used a method of encryption that followed industry best practices like WhatsApp and Signal? Certainly. But, if its not turned on by default, it doesn’t matter.”"
That's not entirely true.
While Telegram's "cloud chats" are not end-to-end encrypted by default, they're encrypted at rest. They claim that "all data is stored heavily encrypted and the encryption keys in each case are stored in several other DCs in different jurisdictions."[0] It's not even close to perfect, but it's also not everything that the government wants.
For me, the problem with Signal is based mainly moxie's position on the LibreSignal fork, which aimed to be a Google-Free version of signal, but moxie said he was not OK with LibreSignal using the Open Whisper Systems servers and the name "Signal".[1] I kind of understand his position, but that's not what I'd expect of the free software community and definitely not what I expect from someone who's in the middle of my communications.
In the end, the hope's in matrix.org. It supports end-to-end encryption, works without a number and is fully federated. Maybe someday Telegram and Signal can even federate with matrix.
I think it's fair to not want a project whose quality you cannot control use your servers and your name to compete for users in a market whose focus should he keeping those users safe.
The issue with not encrypting in transit by default is that it makes profiling encrypted communications MUCH easier and can potentially defeat the purpose via the Streisand Effect.
It may now support working on devices without Play Services, but being the same apk, Google's libraries are still inside the app. This way it's not entirely free and doesn't fit F-Droid's inclusion policy. (https://f-droid.org/en/docs/Inclusion_Policy/)
How do you define attack surface? I trust my personal computer more than my phone.
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.
Matrix is fantastic. However, riot desktop sucks in my opinion. Yet again, an electron app. You say that matrix "has excellent clients for all platforms". That is simply not true at this time. For linux, there's pretty much only 1 client that's currently usable, and that is riot (electron app).
I don't agree that Matrix has excellent clients for all platforms - IMHO, only Riot Web/Desktop is usable, and that only in comparison to other open-source messaging software - it doesn't compete against pretty much anything that people make money off of. Riot iOS and Android both make it nearly impossible to handle a large amount of chatrooms, IME. And nothing else implements even most important features of Matrix.
The developers badly need to invest in a UX engineer, but are currently stuck scrambling for money as their corporate sponsorship ran out.
Matrix is terrific. I've "converted" some friends from Signal to Riot and we're not going back. Video/calls and group chats work a lot better, and the riot.im web client is excellent (at least, compared to Signals lack of).
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.
Use full disk encryption, or store Signal's database in an encrypted volume. Signal for Android only has encryption due to the litany of issues associated with FDE on android, from wiping your phone when you encrypt it, to accidentally bricking your phone cause your vendor broke FDE in their Android build.
As someone that doesn't care at all about Signal (I'm in the "no federation & mobile number as ID is unappealing and I can just as well use WhatsApp" camp) I came away with the opposite opinion:
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.
Then again, you can't expect Signal's target users (normal tech un-savvy people) to have FDE.
But that's not necessarily bad in my book. IIRC Signal's security model wasn't aiming for maximizing security but instead making mass-surveillance harder to execute while offering an acceptable UX.
Also, encrypting files on disk is not actually protecting anything. The Signal app still has to decrypt is somehow, and has to store the private key somewhere, usually on disk, unencrypted..
It is not Signal's job to encrypt your device. It is your OS or device's job. If you care about these things you should already have FDE (Full Disk Encryption) enabled on your device hence Signal encrypting your data on disk would be redundant.
That is Moxie's main point, full disk encryption should be used everywhere, and encrypting Signal's message database on Android is purely due to full disk encryption on Android being a steaming pile or bricking your phone.
Yes, but the point is, if those people don't use ecryption, then they have a problem anyway - and if they do, but their system is compromised, than the attacker gets anything anyway.
In either case, I think Signal's job is to secure the messages going out and coming in and not protecting the disk.
Using Electron is a bad idea: it's not secure. Electron has many security vulnerabilities. The latest version is still based on old Chromium (58 & 59) so it inherits many of the security vulnerabilities published in Chromium 60, 61 and 62
Sure, but it doesn't pull HTML or Javascript from servers, it is all packaged along with the native Electron runtime. Exploiting a Javascript vulnerability is an absurd waste of time when you could just add a backdoor or whatever to the native code.
It's not as simple as you thought. Consider a bug in the image decoding library Chromium used that can be exploited by simply sending a crafted image in the chat.
Most major browsers, including Edge and Chrome, do this and are really good at it.
> closely monitor your deps for vulnerabilities and ship patches as quickly as possible
Most major browsers do this too, and they have well-established update pipelines that can patch vulnerabilities in short order.
> choose deps with a better security track record, when possible
Most major browsers do this (e.g., "boringssl").
> independently scan, test, and validate the deps you bring in
Most major browsers do this as part of QA and vulnerability scanning.
> things you can do in an electron app:
> * pray
* leverage all of the work that thousands at Microsoft, Google, Mozilla, etc., put into deploying what I suspect are the most heavily-attacked, heavily-scrutinized, and heavily-audited software platforms in existence.
Not that I'm specifically advocating web apps over native apps, but I don't think your list does a good job outlining their advantages.
That's likely to get fixed quickly and I can just apt-get upgrade. With electron we have to wait for google to fix it in chrome, wait for electron to update the chrome version or backport the patch, wait for the app developer to update their version of electron and then update it on your machine.
browser security vulnerabilities are expensive and heavily scrutinized. Just because they are on top of it for reporting vulnerabilities and fixes so that you become aware of it doesn’t make the alternatives more secure. You just wouldn’t be aware of them which is more dangerous.
They could use NW.js instead, which stays up-to-date with the latest Chromium version, including security updates. They usually release on the same day as Chromium. https://nwjs.io/blog/
This is interesting, I feel like NW.js has lost the war against Electron, but I haven't closely been following the topic. Can anyone summarize the latest common opinion on the subject?
There was a period in late 2014-early 2015 where NW.js stagnated, but since then it's been very actively developed. I found this 2016 comparison pretty even-handed and comprehensive; it'd be nice to see an updated version for 2017. http://tangiblejs.com/posts/nw-js-and-electron-compared-2016...
So you are suggesting they drop a battle-tested, production ready solution currently powering hundreds of apps (https://electron.atom.io/apps/) for one in beta that the developers warn in large capital letters "use at your own risk, still under development"?!
I want to say "finally!" but they're deprecating the chrome extension so now my chromebook won't be connected anymore but at least I'll be able to get rid of chromium on my desktop.
Guess you can never please everyone.
But in all seriousness thank you for the great work, this is excellent news!
That you won't be able to run it on a chromebook any more is a big deal actually... will you be able to sync the android version on chromebook w/o a phone #? I haven't tried that but I don't think you can "slave" the android version to an existing account the way you do the standalone app.
Unfortunately that was going to happen anyway, as Google's planned to deprecate Chrome apps. Note sure if in general, or if they'd still be supported in Chromebooks, but it's quite a lot of work to support it just for Chromebooks.
Deprecating doesn't necessarily mean you can't keep using what's already there. Even if it's removed from the store you should still be able to run it locally.
It uses `electron-builder`, which has rpm support. I don't think it would be that difficult to add in a pull request, might do it myself later. (I use Fedora, with SELinux and Wayland and all that good stuff)
Ideally upstreams, rather than distributions, should sandbox their own projects.
However, Debian is shipping a number of hardened systemd unit files.
To see some examples on how the sandboxing is being set up you can grep for SystemCallFilter, CapabilityBoundingSet, ProtectSystem, ProtectHome in /lib/systemd/system/*.service
Oh come on kuschku, stop it with the deliberate misinformation about Signal! You bring nonsense like this up in just about every thread on Signal and it's becoming harder and harder to assume that you operate in good faith.
Moxie is most decidedly not against building the code yourself. He doesn't want anyone distributing forks or other clients using the official servers because a) that creates a giant hassle when updating the server and suddenly someone's fork doesn't work anymore and people will blame Signal, and b) if the client doesn't do what they want it to, people will blame Signal even though it's a third-party bug because it's got Signal in the name.
Moxie has publicly stated that he is against anyone publishing a third-party build of Signal.
He has openly and loudly ranted against F-Droid. Of course he's not against users building it for themselves, but he's publicly stated he won't allow F-Droid, or distributions, or anyone else, to build and publish the client, under the name Signal, so that it can connect to his servers.
noja said: "Give us a github repo and we can build it ourself" and I pointed out that moxie never opposed it when people build the code themselves. I'm not denying that he doesn't like it when people distribute their own builds (F-Droid) or forks (LibreSignal), and I'm not a fan of that policy either. But I understand why he's acting this way. If you read the issues you so kindly linked, he explains his reasons, and they are valid points to make even if I don't like their consequences. It's a pity that as a result, Signal is controlled by a small group of people in Silicon Valley, just like any other software product these days. I would like to have a good native desktop client just as much as you. But that's not a reason to misrepresent his position, or to inject it into only tangentially related discussions.
I’m interpreting it in the way that noja is writing it from the perspective of distributions. As in, just link us a repo, and we (Fedora) can include it. That interpretation might be wrong, and I might have misinterpreted it because I’ve been working with distro maintainers on getting some of my software into distributions recently.
But with that interpretation (and the context around that, where users asked about including it in distros), my arguments are certainly relevant.
> If you read the issues you so kindly linked, he explains his reasons, and they are valid points to make even if I don't like their consequences.
His points are basically irrelevant if compared to the risks that the centralization causes.
Users of distributions have to trust their distro anyway, for many other packages (including the kernel build) already, trusting them for Signal, too, actually reduces the number of parties you have to trust.
On the topic of LibreSignal, a fork with the only change being that it supports notifications without relying on proprietary libraries:
> I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.
A lot of people have given negative feedback(because of electron?). I for one, am happy for this. I am in the middle of migrating slowly to Mozilla Firefox from Google Chrome, and one of the hardest things, is to have some of the apps as standalone. I couldn't use my MacBook for anything else if I wanted to chat using signal (..and have chrome running in the background).
No. Signals okay for a drop in replacement for a phones built-in text messaging app (unfortunately really few of my contacts are using it) but once I'm on a laptop/PC there are way better messaging apps imo.
Signal feels slightly like the pigs in Animal Farm getting everyone riled up against the unjust farmers, only to take their place.
Signal is about _privacy_ not necessarily anonymity. Understand the difference?
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.
Does signal do search for text as well as a way to view all images exchanged within a chat ? The only way I found was to scroll up while keeping my eyes focused on certain key words or images. Not a pleasant experience.
Another Electron app, another thread full of people complaining about Electron.
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.
Web widgets require a hybrid codebase. It's not "web developers not getting native," it's web developers preferring the Node.js APIs to writing C++ code to read and write files to the filesystem.
All the options you listed require two or more programming languages. Electron apps can be written entirely in JavaScript, requiring zero context switching between multiple programming languages, as well as sharing code on the backend and frontend. Hence the popularity.
Then we are back to HTML 5 APIs, which any browser can already do.
If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves.
In the end is all about using an hammer for everything.
No, that isn't the case. The Node.js APIs bundled with Electron expose considerably more functionality to JavaScript than the HTML5 APIs that Chromium exposes. And the Electron framework exposes even more native OS APIs that Chromium and Node.js don't provide.
Look, you can call it "using a hammer for everything" pejoratively if you want, but it's popular for a reason, and that reason isn't the moral decay of society. It offers real utility that reasonable people find valuable for rational reasons.
So because open(2) is implemented in C in the standard library, I should only call it via C, and never invoke the wrapper function open() in python or whatnot?
“Hybrid” does not mean what you think it does. The platform may be built on code in many languages, but to program for that platform, you only have to know one.
> All the options you listed require two or more programming languages.
You can write Qt apps entirely in C++ or entirely in QML (of course you can mix and match both... in my experience whatever the environment you always need to resort to native modules at some point anyways, eg numpy, opencv, etc and Qt makes exposing them to Javascript dead easy).
I don't think that is correct. The extent to which Electron uses resources today is as if you install five copies of Node.js and five copies of Chrome and launch them all.
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?
Yes, and that would be the case with Electron too, but in the case where n apps share the same version of the runtime, I assume it saves a lot of resources?
The web browser for UI drawing is only part of what Electron does. It also bundles Node.js and all its APIs, which web browsers don't ship. And Electron also provides APIs for native OS integration, e.g. native macOS menus and whatnot.
I'm not familiar with Electron myself, however it's relatively easy to identify which applications are using it.
I know Discord doesn't support using a keybind for push-to-talk whilst the (Chrome) tab is not in focus with their web application whilst their Electron app supports this. Something vital to PTT users whilst playing games.
The weird thing that isn't supported is Signal on 2 Android devices. I tried to install in on my tablet, but if I put in my phone number it blocks the app on my phone... bewildering..
Great! But it found back some old groups with the same logo as a new group (what a pain if someone changes their phone, but I understand it is for security reasons), took me some tries to find what is what. It's doesn't sync back my older messages apparently, again, probably for security reasons. I was also unable to delete the old groups although they were long deleted from my phone, they popped up there again. After deleting them on my phone, they still remain on the desktop.
"If you’ve never used Signal Desktop before, this is a great chance to start. Download the app, pair it with your phone, and experience private messaging with all ten fingers."
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.)
So now rather than being able to use my existing browser runtime with the Chrome extension version, I get to run yet another browser runtime that only runs Signal...
I can't tell from the page if the client can be run without using any nonfree software. Does anyone know? The Android application unfortunately requires nonfree components.
Can we please stop calling Webapps that come with the whole browser desktop apps? The fact that you give me to install a dedicated browser for your web app does not magically make it desktop app. It makes it a worse web app, which does not even share the browser runtime with other web apps.
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.
That might be your definition of it, but it's in general wishful thinking.
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 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.
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.
there is a certain section of third party app-developers that argue that app ux should absolutely emulate the host operating system. when this isn't sufficiently expressive, new interface elements should be designed such that they blend in naturally (ie, resemble what likely would have been the os-developer's choices).
Well call me picky, but I find electron apps to be super wasteful and gobbling up memory like there's no tomorrow.
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.
I completely agree that most of them are extreme memory hogs. I was just pointing out that the previous commenter's definition of a desktop application made almost no sense to me.
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.