Convert preload API to a messaging API for maximum security?

[wearhere]

Per https://github.com/atom/electron/issues/1753#issuecomment-137962287:

The current security model for exposing main process APIs to the renderer process (i.e. preload scripts) is fragile because it puts a large burden on developers to ensure main process objects don't leak, such as fs, etc.

I'd be interested in seeing a prototype of what this might look like. I imagine it to be less usable: with a messaging API,

• the client and developer would have to worry about whether that API was asynchronous or no
• the client would still have to load a preload shim (to provide access to the ipc module) as well as registering the event handlers with the window
• and the developer would have to keep shim and event handlers in sync

and given that the preload API isn't going to change that much, I think usability is paramount; but perhaps I am mistaken about usability being a problem with the messaging API and/or usability being the priority.

[wearhere]

Comments from @chromakode that spurred this issue:

Designing JavaScript objects to restrict access to other JavaScript objects is tricky. It's a pattern that repeatedly causes security issues, because you have to keep track of all of the implementation-specific details of scope access and shared JS objects. Long ago Firefox had a string of issues with __defineGetter__ being used to circumvent their barriers between trusted and untrusted code. Chromium has been bitten by similar issues too.

In both cases a getter was used to get a function called by trusted/privileged code. I don't think this technique is directly applicable to the preload script on GitHub. These examples illustrate how JS's dynamic nature can lead to unexpected attack vectors when your untrusted code can modify objects touched by trusted code.

In contrast, with postMessage only JSON data is passing between trusted and untrusted contexts, so there's less chance of gotchas now or in the future. A message-passing API still exposes privileged actions, but only constrained to a data-only protocol you define for the limited needs of your app. I've always admired the Chrome extension model for taking this approach.

The best argument I can make for message passing over proxy objects is that it reduces the difficulty of code review, because ensuring that you don't leak privileged objects via members or dynamic language wackiness is a human intensive process!