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!
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.
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.
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.
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.
> 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.
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.
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.
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
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?
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.
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.
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).
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.
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.
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/)
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.
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)
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
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.
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.
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.
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
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.
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.
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".
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.
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.
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.)
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.
"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...
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.
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.
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.
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.
319 comments
[ 3.5 ms ] story [ 263 ms ] threadGuess you can never please everyone.
But in all seriousness thank you for the great work, this is excellent news!
[1] https://githubengineering.com/how-four-native-developers-wro...
[2] https://slack.engineering/growing-pains-migrating-slacks-des...
Good enough for me personally.
https://eul.im
Signal support is coming later this year. Right now it supports Slack, Skype, Facebook, and Gmail.
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.
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.
[1] https://github.com/meetfranz/plugins/blob/master/docs/integr...
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?
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.
(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!
"Oh no I can't use that business chat tool, it doesn't support smiley faces and cat reaction gifs".
The key thing Slack offers most 'customers' (even those who don't pay) compared to something like IRC is the simple setup/use.
I say this as someone who hates Slack, but has had to endure it on a number of client projects.
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"
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.
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.
https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
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.
I'll switch to Servo in the future, it's only ~20MB.
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).
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 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.
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...
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).
Inspecting the app, it appears to be just another Javascript app (Electron).
(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)
If you(r system) trust the certificate that https://updates.signal.org/ is using, you should be confident that you are getting the correct keys.
(You shouldn't trust a stranger on the internet, but I am getting the same keys when I download them.)
It's ludicrous that you can't download a security-focused app when your browser settings are unusually secure. ;)
Security is about threat models: if you don't trust the code they write on their website, you shouldn't trust the code they shipped in the app.
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.
source https://gizmodo.com/why-you-should-stop-using-telegram-right...
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.
[0] https://telegram.org/privacy#2-storing-data [1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
(Oh, and worth noting: it has an integrated update checker, so not being in F-Droid is less of a problem.)
An update checker is nice though! I wish firefox had one, but at least there's FFUpdater.
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.
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.
Edit: It actually has the option to register without smartphone, but it's only enabled in the debug versions.
Nor would I since it still requires a phone number to use.
This might get you started: https://github.com/WhisperSystems/Signal-Desktop/blob/d1f7f5...
How did you evaluate Telegram to decide that you trust it?
Without having a smartphone, using Signal wasn't an option (at least previously).
Sadly, almost everything involves tradeoffs.
He (understandably) prefers to use a tool which doesn't require a phone, over one with a better security model.
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
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.
Oh come on guys. Don't forget Fedora. Fedora means SELinux. SELinux means you are getting the people who value security.
Edit: https://github.com/WhisperSystems/Signal-Desktop
He only wants users to get Signal builds from himself, and no one else.
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.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Basically, he argues that no one but him has the right to build a client that connects to his servers.
Disclaimer: I personally am critical of Moxie's demands that he fully controls all released client builds, servers, and his use of analytics.
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.
Read the Signal-Android issues https://github.com/WhisperSystems/Signal-Android/issues/53 https://github.com/WhisperSystems/Signal-Android/issues/127 https://github.com/WhisperSystems/Signal-Android/issues/281 and https://github.com/WhisperSystems/Signal-Android/issues/6292, where moxie publicly states that he will not accept or allow any public distribution of third-party builds of Signal to connect to his servers.
He actually directly reached out to F-Droid, and demanded they take it down: https://web.archive.org/web/20160410152543/https://f-droid.o...
So, how the fuck is what I'm saying misleading?
EDIT: Oh, right, some of the linked issues were purged by him later on. Here's an archive.org link: https://web.archive.org/web/20160410153027/https://github.co...
EDIT2: The real question is why you continue to lie to defend Signal.
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.
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.
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
Really happy to have it as a standalone app outside of Chrome now.
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.
A fresh launch without logging in or having it run for any period of time immediately uses 211.2MB:
After logging in and starting a few conversations I quickly see the total rise to over 350MB.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.
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".
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.
That said, at least they have the option of closing that hole with the electron app.
Which they don't. That's why it's not a web app.
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...
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...
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.
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.
I mean isn't one of Signal's target audience people like journalists and activists?
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.
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.