5 ms·

Why no web app? Moxie closed https://github.com/WhisperSystems/Signal-Desktop/issues/723 https://github.com/WhisperSystems/Signal-Desktop/issues/723 without giv

Why no web app? Moxie closed https://github.com/WhisperSystems/Signal-Desktop/issues/723 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.

woolvalley 9y ago
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.
- ezekg 9y ago
  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.
  - Nition 9y ago
    Like DLL Hell all over again.
    - digi_owl 9y ago
      I can't help shake that DLL and similar is a symptom of a culture of lax backwards compatibility upstream.
      - jacobush 9y ago
        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.
        digi_owl 9y ago
        Yes there is a point of diminishing return. But all too often these days it feels like projects are not ever trying.
        jacobush 9y ago
        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.
        digi_owl 9y ago
        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".
- tomc1985 9y ago
  Or they could have written the app in .Net, JavaFX, QT, GTK, or any of the other perfectly good languages and frameworks out there
maerek 9y ago
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.
- mrmondo 9y ago
  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.
  - jacobsenscott 9y ago
    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.
    - mrmondo 9y ago
      It is by me, that is the real memory usage, pretty shocking.
    - xpaulbettsx 9y ago
      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.
kijiki 9y ago
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.
- swsieber 9y ago
  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.
  - lambda 9y ago
    > 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.
  - JepZ 9y ago
    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.
    - baby 9y ago
      you get rid of any CSRF from the get go.
- baby 9y ago
  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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
jampekka 9y ago
Reasoning!? That's for cryptonerds and free software retards who don't understand "modern growth engines" etc big boy business stuff.

woolvalley 9y ago

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.

ezekg 9y ago
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.
- Nition 9y ago
  Like DLL Hell all over again.
  - digi_owl 9y ago
    I can't help shake that DLL and similar is a symptom of a culture of lax backwards compatibility upstream.
    - jacobush 9y ago
      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.
      - digi_owl 9y ago
        Yes there is a point of diminishing return. But all too often these days it feels like projects are not ever trying.
        jacobush 9y ago
        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.
        digi_owl 9y ago
        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".
tomc1985 9y ago
Or they could have written the app in .Net, JavaFX, QT, GTK, or any of the other perfectly good languages and frameworks out there

maerek 9y ago

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.

mrmondo 9y ago
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.
- jacobsenscott 9y ago
  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.
  - mrmondo 9y ago
    It is by me, that is the real memory usage, pretty shocking.
  - xpaulbettsx 9y ago
    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.

kijiki 9y ago

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.

swsieber 9y ago
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.
- lambda 9y ago
  > 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.
- JepZ 9y ago
  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.
  - baby 9y ago
    you get rid of any CSRF from the get go.
baby 9y ago
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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

jampekka 9y ago

Reasoning!? That's for cryptonerds and free software retards who don't understand "modern growth engines" etc big boy business stuff.