5 ms·

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 inh

by jsnar 9y ago

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

jsnar 9y ago
See here for the security issues published in Chrome stable releases in those versions: https://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/07/stable-channel... https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/09/stable-channel... https://chromereleases.googleblog.com/2017/10/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/10/stable-channel...
- halayli 9y ago
  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.
kijiki 9y ago
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.
- jsnar 9y ago
  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.
  - halayli 9y ago
    same logic can be applied to a native app that is using libpng and an attacker exploits the lib in one way or another.
    - munin 9y ago
      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
      - Jahava 9y ago
        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 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.
        deleted 9y ago
        [deleted]
    - flukus 9y ago
      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.
orange8 9y ago
what do you suggest they should they use instead
- polpo 9y ago
  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/ https://nwjs.io/blog/
  - orange8 9y ago
    Good answer. Some are just good at putting down solutions, and don't even have the courage to suggest alternatives.
  - baby 9y ago
    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?
    - orange8 9y ago
      I suspect most electron devs haven't even heard of NW.js even though it came first, so there wouldn't even be any comparison to begin with.
    - polpo 9y ago
      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-edition http://tangiblejs.com/posts/nw-js-and-electron-compared-2016...
- superkuh 9y ago
  They could try not writing it in javascript and actually make a native application instead hiding behind semantics.
jsnar 9y ago
submitted issue for this: https://github.com/WhisperSystems/Signal-Desktop/issues/1635 https://github.com/WhisperSystems/Signal-Desktop/issues/1635

by jsnar 9y ago

jsnar 9y ago

See here for the security issues published in Chrome stable releases in those versions: https://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/07/stable-channel... https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/09/stable-channel... https://chromereleases.googleblog.com/2017/10/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2017/10/stable-channel...

halayli 9y ago
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.

kijiki 9y ago

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.

jsnar 9y ago
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.
- halayli 9y ago
  same logic can be applied to a native app that is using libpng and an attacker exploits the lib in one way or another.
  - munin 9y ago
    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
    - Jahava 9y ago
      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 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.
      - deleted 9y ago
        [deleted]
  - flukus 9y ago
    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.

orange8 9y ago

what do you suggest they should they use instead

polpo 9y ago
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/ https://nwjs.io/blog/
- orange8 9y ago
  Good answer. Some are just good at putting down solutions, and don't even have the courage to suggest alternatives.
- baby 9y ago
  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?
  - orange8 9y ago
    I suspect most electron devs haven't even heard of NW.js even though it came first, so there wouldn't even be any comparison to begin with.
  - polpo 9y ago
    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-edition http://tangiblejs.com/posts/nw-js-and-electron-compared-2016...
superkuh 9y ago
They could try not writing it in javascript and actually make a native application instead hiding behind semantics.

jsnar 9y ago

submitted issue for this: https://github.com/WhisperSystems/Signal-Desktop/issues/1635 https://github.com/WhisperSystems/Signal-Desktop/issues/1635