Comment by nikisweeting | Hacker News Reader

Comment by nikisweeting | Hacker News Reader

Parent Full thread

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

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

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

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.

> A signed app is only more secure if they load absolutely no code remotely

Which they don't. That's why it's not a web 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.

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.

Like DLL Hell all over again.

I can't help shake that DLL and similar is a symptom of a culture of lax backwards compatibility upstream.

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.

Yes there is a point of diminishing return. But all too often these days it feels like projects are not ever trying.

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.

Apple has been doing that thing for ages.

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

Or they could have written the app in .Net, JavaFX, QT, GTK, or any of the other perfectly good languages and frameworks out there

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.

I don't think you're looking at all the processes:

A fresh launch without logging in or having it run for any period of time immediately uses 211.2MB:

  1. Signal: 58.3MB
  2. Signal Helper: 128.6MB
  3. Signal Helper: 24.3MB

After logging in and starting a few conversations I quickly see the total rise to over 350MB.

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.

It is by me, that is the real memory usage, pretty shocking.

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.

Reply on news.ycombinator.com