Can you explain how the process-level sandbox is broken using webviews?
Also, I hope y'all don't have to fork Electron but instead can upstream your changes. I have successfully implemented web APIs that use private IPC to communicate w/ the backend side (and then killed node integration). Granted I have not attempted this with iframes and web workers...I wonder if it's just an oversight on their part and would welcome a PR. I know the webview and custom protocol support leaves a lot to be desired. But I fear all of these Electron forks (e.g. Brave) for browser use will end up fragmenting features that could help all browser implementers.
On a side note, this is really awesome. I have not dug into it too deeply, but as I have mentioned before here and on the maidsafe forums, this is a big step towards removing user tracking while leaving JS functionality intact. Simply removing the "server" or mutable calls of the implemented protocol (or at least making them opt-in) prevents the fingerprinting from being "phoned home". I hope this project succeeds.
Sure thing. It's the node integration that's an issue. To let the render processes import node's APIs, the process-level sandbox had to be removed. Whether node-integration is enabled or not, that process-level sandbox is gone. The javascript sandbox is still present, but the os-enforced sandbox is gone.
This situation isn't totally unsafe, but it's not as safe as it can be. The process-level sandbox acts as a strong second-line of defense against API compromises. For a project that doesn't need node integration in the browser (such as Beaker) then it'd be best to re-add it.
> I hope y'all don't have to fork Electron but instead can upstream your changes.
That would be nice! The team that works on Electron is superb, but they've explicitly stated, in conversations with the Brave team, that they're not interested in supporting Browser projects such as Brave or Beaker.[1] Their position is reasonable - though obviously I'd prefer they changed it. I'll stay in touch with them, and do my best to contribute upstream when it makes sense. If I don't have to fork, in the end, I certainly won't.
The two candidates I'd suggest are Firefox (obvious) and Vivaldi. The latter has already reached stable release stage and desperately needs a feature to set itself apart from other Chromium forks. It's only partly open-source now but the team have plans to go full in future.
Props to you guys for making the P2P web more accessible.
It took about 2 months to write. I used yo-yo[1] for the frontend UI, which I enjoyed using a lot. The rest is standard es6 and electron.
Dat & IPFS are the first two protocols to get integrations. I also know Maidsafe has been considering using Beaker as well. I might integrate SSB [2] next, because of my history with that project.
Cheers.
1. https://www.npmjs.com/package/yo-yo
2. https://scuttlebot.io/more/protocols/secure-scuttlebutt.html