> Beaker is built on Electron, which is a temporary solution. Electron breaks Chromium's process-level sandbox, which needs to be restored. Electron also has API limitations, which (for instance) keeps Beaker from injecting new Web APIs into iframes and workers. So, in the near future, we'll need to fork Electron.
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.
> Can you explain how the process-level sandbox is broken using webviews?
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.
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.