Just killed Signal Desktop because it was using 2GB of memory. 🙃
Conversation
(The blame for this, like many things, lies entirely with Electron)
1
7
Replying to
what really prevents me from installing Signal Desktop is not the risk of RCE (there are ways to fix that like sandboxes and VMs!) but that a bug would still lead to accessing other chats, etc. and it's non-trivial to fix that
1
1
i think they added a CSP, etc. now so XSS probably isn't a huge risk
and yet 😰
1
i am perpetually tempted to try and build something using their new Rust client
1
1
Electron tends to cripple Content-Security-Policy. IIRC, it essentially breaks 'self'. Since you only need to deal with Chromium, you can strictly use hash-source as the only way scripts as permitted. Other browsers don't yet support hash-source for external scripts, only inline.
1
1
I very much doubt they have a strict enough CSP to do much to prevent XSS. They also probably aren't using Trusted Types. If you entirely avoid XSS sinks by working with the DOM using structured APIs, you can enforce Trusted Types with a strict policy not trusting sanitization.
1
1
Only 'self' without 'unsafe-eval' or 'unsafe-inline' is still unsafe if you have dynamic content considered to be 'self' which is a major issue with Electron.
See microsoftedge.github.io/edgevr/posts/e for Trusted Types. Strictest is `require-trusted-types-for 'script'; trusted-types 'none'`.
For a website, using 'self' means you permit everything from your server. You can be very careful to only have static content and APIs not serving JavaScript. You can't really do that with Electron. The local JavaScript has the ability to create files considered to be 'self'...
1
1
2
`X-Content-Type-Options: nosniff` is an important security header for making CSP and other security features robust combined with careful control over how you serve things.
Electron really messes with how these things are supposed to work. Android WebView is much better...
1
1
Show replies