Implement a node.js-free, sandboxed, context isolated renderer

[egamma]

We want to explore a model where the workbench in Electron does not access node.js APIs. In that model the Electron renderer process runs in sandboxed mode, much like any browser tab would do. Privileged code has to either move into a backend process and be accessible via IPC communication or into a preload script that exposes certain methods to the page.

July

• 🏃 Allow to enable sandbox behind a setting and validate it works #154006 @bpasero @deepak1556
• 🏃 Contribute the utility process and APIs to Electron #154007 @deepak1556

Backlog

• Tests:
  • common/browser: run in BrowserWindow with sandbox: true
  • node.js/electron-browser: run in ELECTRON_RUN_AS_NODE

Architecture

[jrieken]

An "implict" node-dependency that's not listed here is code loading. Today, the loader uses the fs and vm-modules which allows for v8 cached data usage.

[bpasero]

Bootstrap sandboxed workbench code pointers:

• enable sandbox & contextIsolation in window.ts
• load something like a workbench-sandboxed.html from doGetUrl
• this will likely fail early on because of our AMD loader requiring node.js for cached data etc. and some other things we depend on from window.js so we need something like workbench-sandboxed.js and possibly workbench-preload.js that work properly in this mode
• instead of vs/workbench/workbench.desktop.main load a vs/workbench/workbench.desktop-sandboxed.main here with those things commented out that are not yet adopted
• instead of vs/workbench/electron-browser/desktop.main, require a vs/workbench/browser/desktop-sandboxed.main here that brings up the workbench without depending on node.js

[dbaeumer]

@bpasero we shouldn't mix localization support in the Web with support for Node free renderer. We need a very different story for the Web whereas for a node free renderer we can still install the LP on the local disk. We can simply not access them from the renderer. So I will change the item (I have discussed it that way with @egamma as well)

[Tyriar]

FYI following up on #116337, I believe the slowness I sometimes see with terminals is a result of the multiple process jumps since we can't communicate directly between the renderer and pty host yet. Was there an issue tracking this direct channel between renderer to arbitrary node process?

[bpasero]

@Tyriar we had it on our project board, but not as issue. I converted it to one and suggest you ping Deepak about status: #131798

[sandy081]

CachedExtensionScanner is owned by @alexdima and hence removing my name.

[wzhudev]

Will floating window get supported (or easier to implement) under this new architecture?

[bpasero]

No, it should not have any impact on that.

[bpasero]

I think it is about time to close this one, insider builds are out on all platforms that allow to enable the sandbox via "window.experimental.useSandbox": true and #155827 is a test plan item to verify it works.

Remaining issues are tracked with sandbox label: sandbox Running VSCode in a node-free environment

Thinking on the timeline:

• enable sandbox by default in insiders in August
• enable sandbox by default in stable in September/October pending issues found

🥇