Live data from Hacker News

Standalone Signal Desktop

signal.org

251–260 of 320 posts

Re: Standalone Signal Desktop

#251
post #225

Earlier quoted context omitted.

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.

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.

Wow! A race to the bottom of the memory pool.

Electron is several things which HN guidelines probably won't allow me to describe here. I avoid it whenever I can.

Re: Standalone Signal Desktop

#252
post #245
post #177

Earlier quoted context omitted.

Note that Signal supports Google-free itself now - I'm running it on AOSP without Google Play.

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/ )

Ah, I did not know that - thanks for clarifying. Does that mean that library code is still executed, or is it just "there"?

(Oh, and worth noting: it has an integrated update checker, so not being in F-Droid is less of a problem.)

Re: Standalone Signal Desktop

#253
post #110

Why no web app? Moxie closed https://github.com/WhisperSystems/Signal-Desktop/issues/723 without giving any reasoning. Can someone link me to a blog post that explains why Signal is refusing to release a web version? 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 n…

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…

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.)

[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Re: Standalone Signal Desktop

#254
post #82

Does it still store all data unencrypted on the disk? https://github.com/WhisperSystems/Signal-Desktop/issues/1017

Wow, reading that thread basically made me decide against using Signal. 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.

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.

Re: Standalone Signal Desktop

#255
post #235

Earlier quoted context omitted.

A signed app is only more secure if they load absolutely no code remotely, otherwise they open up the same channels of attack. That said, at least they have the option of closing that hole with the electron app.

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.

you get rid of any CSRF from the get go.

Re: Standalone Signal Desktop

#256
post #120

Earlier quoted context omitted.

what do you suggest they should they use instead

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?

Re: Standalone Signal Desktop

#257

Earlier quoted context omitted.

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 up…

How the fuck is this misinformation? 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. R…

EDIT3: Almost forgot, also you should read this comment where Moxie addressed LibreSignal: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Re: Standalone Signal Desktop

#258

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…

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.

Re: Standalone Signal Desktop

#259
post #97

Earlier quoted context omitted.

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 woul…

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.

It's a huge task, sure, but someone needs to take on huge tasks from time to time (and Go does not currently have any good UI toolkit story). :-)

Re: Standalone Signal Desktop

#260
post #141
post #129

Earlier quoted context omitted.

things you can do in the native app to mitigate this risk: * run rendering in a sandbox * closely monitor your deps for vulnerabilities and ship patches as quickly as possible * choose deps with a better security track record, when possible * independently scan, test, and validate the deps you bring in things you can do in an electron app: * pray

In all fairness... > run rendering in a sandbox 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 maj…

[deleted]
Post reply on HN