[docs] needs docs on how/why to use Muon instead of Electron

[diracdeltas]

i have gotten some questions from devs about whether they should use Muon instead of Electron. we should document the reasons to do so (and how to do it) somewhere, maybe a wiki page.

this is especially of interest to developers migrating off of Chrome Apps, which will be deprecated within a year. https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html

related: #87

[tarruda]

Electron has added basic sandbox support back in september/2016, but that is only a first step towards making a framework that can be considered secure for running untrusted content.

Since I've been working on improving electron's security and sandbox mode, I'm interested in knowing what are muon advantages over electron from a security POV.

[diracdeltas]

@tarruda one thing I have noticed is that many security-focused apps (Keybase client, Cryptocat, etc.) do not have the sandbox enabled; is that because the sandbox causes problems with app functionality or because they do not know about this feature? Paul Betts alluded to some tradeoffs in electron/electron#8578 (comment), and I'm curious what those are for Electron.

Other than having features like sandbox and lack-of-nodeintegration on by default, I think the other big security benefit of Muon is keeping more up-to-date with Chromium upgrades. IIRC we aim for no more than 2 weeks gap between Chromium stable and Muon.

[tarruda]

is that because the sandbox causes problems with app functionality or because they do not know about this feature?

I think it is not known yet. I implemented this feature a few months ago as experimental/incomplete but only recently got the time to resume my work. You can keep track of some planned enhancements here: electron/electron#6712 . There's already a PR with some documentation: electron/electron#8983

As for the tradeoffs, a sandboxed window is indeed more limited than a normal electron window, but I'm working to reduce these limitations. This month I already sent quite a few PRs with many fixes/improvements, such as making the remote and crashReporter modules are available(in addition to ipcRenderer). I currently have a private branch where <webview> and other non-sandbox features are made available to sandbox(including native window.open inside <webview>).

If you only care about accessing node.js APIs, sandbox is not so limiting since you can already access every module in the main process through ipcRenderer/remote, but this is the main reason why sandbox is not currently very useful in electron: The main process trusts all IPC messages, and it is possible to access any API through IPC(which kinda defeats the purpose of the sandbox). This is another problem I plan to fix in the following weeks with a very simple strategy: Allow the main process to filter messages from sandboxed processes.

My long term goal is to make it possible for sandbox renderer to have every electron feature/API, even running all electron specs with sandbox enabled, but also make it a viable choice for running untrusted code.

[3n-mb]

@diracdeltas , I agree with @tarruda , the story of an already available sandbox in electron hasn't been spread far enough. I, for one, read in May 2016 about some efforts to bring sandbox back, and only today, April 2017, noticed that webPreferences.sandbox = true is available (subsequently jumping in pure joy :) ).

Historically, though, since there was no perfect sandbox story, people didn't try to split crypto into electron's main, aka crypto core, and UI and whatnot into electron's renderer processes. Cryptocat may be an example here, code has been written before story of available sandbox went to Electron's blog -- that's right, there is no such story on the blog, although this is a huge deal.

Unlike Cryptocat, there are folks that do even less. And those are not proper examples of Eletron app, at all. <rant>Notice that issue was closed with PR, that doesn't stand for Pull Request.</rant>

Let's propagate the story we have now! Electron now allows to split important core, and less important UI, which is POLA, and is lazy security.

My envisioned use case is as follows. Yes, even PGP is e2e encrypted. We can have protocols were clients do not expose metadata. But, sometimes, I want a message to be an interactive postcard, with full html, css and javascript enabled, to have a wonderful experience. (... asking programmers, when was the last time you hand-crafted a gift card for your mom?)
Electron's sandbox, into which 3rd party code can be placed, makes this dream of mine possible. Hence, my current joy.

@tarruda some primitive documentation is needed about writing a preload script that goes on the start of a sandbox-ed window. For one, it seems that it should be browserified, as exports are not known in that environment. Ya. Tiny docs and a post or two on Electron's blog will be helpful to all of us.

[3n-mb]

@tarruda can you ask on electron repo to put a few words about sandbox on the front of Electron's repo page? You have weight there. Point folks to muon, that bluntly suggest to give up on Electron, and stick with Muon.
People may not realize that muon is 207 times heavier than electron :)

[3n-mb]

@diracdeltas I want to add a little detail into compartmentalization of UI picture in electron. Yes, in electron sandbox mix of vulnerable code has XMLHTTPRequest as part of DOM. But, main process has all hooks to filter it. This is what I do in our project: our own UI code doesn't have a permission just to go out and do any request(s).
So, if muon has this filtering, then there is a parity between the two. Else, electron provides a tighter constraint on 3-rd party js-hacks that want to call home.

[tarruda]

@tarruda can you ask on electron repo to put a few words about sandbox on the front of Electron's repo page?

@3n-mb electron's sandbox mode is still not ideal for running untrusted content. IMO we still need at least these extra features:

• Allow running sandbox with contextIsolation option(WIP: Refactor: Share AtomRenderFrameObserver with AtomSandboxedRendererClient electron/electron#9148)
• IPC filter to whitelist/blacklist messages from renderers running untrusted content(as I said in the previous comment, it is still not implemented yet). I imagine this will be a very simple task, possibly an API to pass a callback to filter messages from webContents instances.
• <webview> tag, which would allow one to implement the main browser interface in pure html5/javascript(imagine a react UI that manages tabs of <webview> to display the content). I already have most of this working in private branches, but still needs extensive testing before sending a PR.

Once we have these(I imagine in the next couple of months), I will implement a very simple web browser as a showcase of sandbox and other security features. Until then I'd rather not encourage anyone to use electron for running untrusted content, and mentioning sandbox in the front page might give an idea that electron is fully ready for that use case.

[3n-mb]

@tarruda

• For IPC, as a user of this api, I'd say to put all messages from sandbox-ed windows into different event, like sandbox-messages. This way everything else can stay the same in api. So that, when api's user forgets in main to check identity of window sending messages (forgets to filter), potentially bad inputs are already diverted to another event with possibly tainted inputs, like sandbox-messages, or whatever you choose.

Cannot overstate how glad I am to hear that you do this sandboxing. Thank you.