3 ms·

Hey all, I'm the author of this project. Happy to answer questions or talk about the software. It took about 2 months to write. I used yo-yo[1] for the fronten

by pfraze 10y ago

Hey all, I'm the author of this project. Happy to answer questions or talk about the software. 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 https://www.npmjs.com/package/yo-yo 2. https://scuttlebot.io/more/protocols/secure-scuttlebutt.html https://scuttlebot.io/more/protocols/secure-scuttlebutt.html

kodablah 10y ago
> 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.
- pfraze 10y ago
  > 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. 1. https://github.com/electron/electron/issues/5210 https://github.com/electron/electron/issues/5210
zbyte64 10y ago
SSB looks very exciting. If all of these are supported by Beaker then would it make sense to cross link from SSB to IPFS to support something like video hosting? Props to you guys for making the P2P web more accessible.
ComodoHacker 10y ago
Please consider integrating into an existing browser with userbase instead of making your own. This is the only way IMO to get IPFS used by real people. I mean to make sense publishing content in IPFS in the first place. 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.
- deleted 10y ago
  [deleted]
_prometheus 10y ago
pfraze: this is great! such a nice surprise to see the recorded demo today in HN. <3 keep up the good work!

by pfraze 10y ago

kodablah 10y ago

> 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.

pfraze 10y ago
> 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. 1. https://github.com/electron/electron/issues/5210 https://github.com/electron/electron/issues/5210

zbyte64 10y ago

SSB looks very exciting. If all of these are supported by Beaker then would it make sense to cross link from SSB to IPFS to support something like video hosting? Props to you guys for making the P2P web more accessible.

ComodoHacker 10y ago

Please consider integrating into an existing browser with userbase instead of making your own. This is the only way IMO to get IPFS used by real people. I mean to make sense publishing content in IPFS in the first place. 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.

deleted 10y ago
[deleted]

_prometheus 10y ago

pfraze: this is great! such a nice surprise to see the recorded demo today in HN. <3 keep up the good work!