Signal-desktop: Move to process per conversation

[alex]

Currently all conversations share a single Chromium renderer process; the result of this is that a single XSS vulnerability can be leverage to steal other conversations.

However, if different conversations were in their own process, than an XSS would be unable to steal other conversations. Even better, a renderer RCE would also be unable to steal them!

This idea is inspired by Chromium's process-per-site; I suspect that infrastructure could be leveraged to enable this. (I'm not familiar with Signal Desktop's codebase, but hopefully this idea idea is tractable!)

[genodeftest]

Wouldn't this massively increase memory usage? How about other (non-JavaScript) solutions?

[alex]

Lower memory usage should be able to be maintained by shutting down
processes that haven't been used recently.

On Sun, May 13, 2018 at 12:14 PM Christian Stadelmann <
[email protected]> wrote:

Wouldn't this massively increase memory usage? How about other
(non-JavaScript) solutions?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/signalapp/Signal-Desktop/issues/2375#issuecomment-388638100,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAADBBAEOW_nZUtzNxXiw99K1Qah6uq7ks5tyFvygaJpZM4T8Qfo
.

--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[awong-dev]

This is a complete brainstorm... but if you re-conceptualize each conversation as a separate origin (basically making them their own security principal) this could be interesting. I'm not quite sure how to actually make each behave like a separate origin...but it's theoretically possible to make this work.

Memory impact is likely smaller than you may expect, especially if you only keep an active-pool of some small number of renderers. Given the UI, I could imagine you only truly need 1 active renderer most of the time. There'd be latency cost in switching between conversations due to process spin-up, but it's probably maskable and worth the security increase.

[awong-dev]

Expanding a little more on the memory impact, if we're spinning up a renderer to literally render just the conversation content frame, then the actual DOM structure, JS, Styles, and cached storage is likely not huge. Thus, we're probably dominated by process overhead. As a quick-and-dirty estimate of that, you can open up chrome, load a lightweight extension of your choice, and examine the process size for that extension. Off the top of my head, I think that's around ~50mb last time I checked? So it's a material change, but it's not going to kill your machine either. Especially if you keep the pool of backgrounded renderers pruned.

[davidben]

Another thing to look at is <iframe sandbox>. I don't think it will result in a different process (perhaps it should...), but it will at least give some web-platform-level isolation as a starting point.
https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/