Deprecate the 'remote' module and move it to userland

[nornagon]

The remote module is a serious security liability and a sizable footgun, as I wrote about here. We should disable it by default and ultimately move it to electron-userland.

This is a fairly disruptive change as it will affect any app that's using the remote module, which is most of them.

Deprecation Strategy

1. ✅ In Electron 9.x, start emitting a deprecation warning when using remote without explicitly enabling the remote module via the enableRemoteModule WebPreference.
2. ✅ In Electron 10.x, set the default value of enableRemoteModule to false. Apps that use remote will need to update to explicitly set enableRemoteModule to true.
3. ✅ Once WeakRef is available, refactor remote to use that instead of our custom GC hook callbacks. [Update]: WeakRef is now available in Chrome 85 / Electron 10. This refactor is targeted for Electron 11, as 10 has already branched for beta.
4. ✅ Once remote no longer relies on native code, create electron-userland/remote and start warning when apps use require('electron').remote or set enableRemoteModule: true, directing them to the userland version. [Update]: This is now targeted for Electron 12.
5. ✅ After 2 major versions of warning on require('electron').remote, remove it. [Update]: This is now targeted for Electron 14.

I can see an argument for delaying (1)–(2) until WeakRef is available, so we can skip straight to the userland module and only have one change instead of two. However, I think it might be valuable to start warning ASAP so that apps can start the process of migrating away from remote if they decide they want to.

[alexhx5]

A few questions:

What features will we loose with this and is there a way to implement those features in an app without using remote?

Since remote connects main and renderer processes, will we loose the ability to send messages between them via ipc and will we loose APIs like "native file drag & drop" that rely on it?
And what about things like remote.getCurrentWindow() and remote.app.getPath() ? Will it become impossible to get current window and get paths of the app directories then?

[nornagon]

IPC primitives (ipcRenderer and ipcMain) will be unaffected. This only affects the remote module, which is a convenience layer wrapped on top of those IPC primitives.

The recommended migration path for apps is to replace usage of the remote module with explicit use of the IPC primitives, for example ipcRenderer.invoke / ipcMain.handle.

There's a small example in my blog post:

Before, with remote:

// Main
global.api = {
  loadFile(path, cb) {
    if (!pathIsOK(path)) return cb("forbidden", null)
    fs.readFile(path, cb)
  }
}

// Renderer
const api = remote.getGlobal('api')
api.loadFile('/path/to/file', (err, data) => {
  // ... do something with data ...
})

After, with invoke:

// Main
ipcMain.handle('read-file', async (event, path) => {
  if (!pathIsOK(path)) throw new Error('forbidden')
  const buf = await fs.promises.readFile(path)
  return buf
})

// Renderer
const data = await ipcRenderer.invoke('read-file', '/path/to/file')
// ... do something with data ...

[alexhx5]

@nornagon thank you for the explanation, your blog post is a good read.

I agree, there's no point wasting development time on remote and making Electron more bloated if it doesn't provide anything more than invoke does. It makes sense to deprecate it since it does more harm than good.

[amirburbea]

What about remote.BrowserWindow/remote.getCurrentWindow()/remote.screen etc...

[nornagon]

@amirburbea those will all be deprecated and moved to a 3rd-party module along with the remote module itself. It's not a good idea to access those from the renderer process (see this post for more info); it's a much better idea to use invoke or similar IPC methods to control the exposed IPC surface and avoid synchronous IPC calls.

[canvascat]

IPC primitives (ipcRenderer and ipcMain) will be unaffected. This only affects the remote module, which is a convenience layer wrapped on top of those IPC primitives.

The recommended migration path for apps is to replace usage of the remote module with explicit use of the IPC primitives, for example ipcRenderer.invoke / ipcMain.handle.

There's a small example in my blog post:

Before, with remote:

// Main
global.api = {
  loadFile(path, cb) {
    if (!pathIsOK(path)) return cb("forbidden", null)
    fs.readFile(path, cb)
  }
}

// Renderer
const api = remote.getGlobal('api')
api.loadFile('/path/to/file', (err, data) => {
  // ... do something with data ...
})

After, with invoke:

// Main
ipcMain.handle('read-file', async (event, path) => {
  if (!pathIsOK(path)) throw new Error('forbidden')
  const buf = await fs.promises.readFile(path)
  return buf
})

// Renderer
const data = await ipcRenderer.invoke('read-file', '/path/to/file')
// ... do something with data ...

@nornagon nornagon
I don't think invoke is any better than remote, because the packaging at the bottom of the electron prevents the invoke from catching the error you need.
lib/renderer/ipc-renderer-internal.ts

ipcRendererInternal.invoke = async function<T> (channel: string, ...args: any[]) {
  const { error, result } = await ipc.invoke<T>(internal, channel, args)
  if (error) {
    throw new Error(`Error invoking remote method '${channel}': ${error}`)
  }
  return result
}

e.g:

ipcRenderer.invoke('read-file', '/path/to/file')
  .then(console.log)
  .catch(console.warn)

if error:

[lx-an]

Hi @nornagon,

Currently, the project I'm working on heavily depends on remote for main-process modules like BrowserWindow, Menu and app. I'd like to replace all of them with ipcRenderer.invoke / ipcMain.handle. Is it OK to use it like this:

// renderer process
const app = await ipcRenderer.invoke('get-electron.app')

// main process
const { app, ipcMain } = require('electron')
ipcMain.handle('get-electron.app', () => app)

[canvascat]

ipcRenderer.invoke('get-electron.app')

@lq-manh
app will be serialized as JSON internally and hence no functions or prototype chain will be included.