Hi,
I installed Blockstack app for macOS and it’s working fine and I really liked it 
but when I open blockstack app it goes to the browser I’m wondering if it’s possible to implement Blockstack with Electron and make it feel more like an app rather than a web page.
Thank you.
So far the Blockstack App looks promising from looking at the homepage and reading some of the content. For anyone interested here is more information on Blockstack Apps: https://blockstack.org/intro
Looks like that link is broken at the moment. Would like to see Blockstack on Electron too.
Having a bit of familiarity about these sort of platforms, Brave was a browser that used to use Electron until it was unsatisfied with how slow the Electron community updated Chromium patches for security updates. For a pseudo web-browser platform like a native Blockstack app, Electron should be considered fairly insecure.
I would argue doing a Chromium or Firefox fork would be a safer alternative, though a bit more complicated. That’s why I’m working on a browser extension right now instead.
Second this. Electron has had security issues with sandboxing, which is not appropriately maintained when retrieving updates for electron. This issue has existed for years, and concerns have only grown in this area across the security community in general
Furthermore, there have been multiple new security flaws expose in the passed year.
I am out of my own curiosity looking more into this in general as I have tried to use electron before and it was not able to pass security protocols for what I was working on. For now we are not pursuing Electron.
Thanks @retired_user–I was interested in more on the specifics about this. @MichaelFedora’s suggestion of forking an existing browser seems like the best current path.
@alexc.id Outside of the sanboxing issues when acquiring updates, which is an older one, which I do not know the status of that one, there was a bug exposed that enabled remote code execution, that affected Skype, Shopify, Slack, among others.
Host-rules were absent from the blacklist. With this flag, one may specify a set of rules to rewrite domain names for requests issued by "libchroumiumcontent.” This enabled a man in the middle attack for Electron on Windows.
Edit: The man in the middle attack enabled siphoning of information from the application, as well as remote code execution.
This issue was patched in late May of this year. This was a patch to a flawed security patch in January. This is an immediate release to the vulnerability. The electron community is still waiting on a more resilient version of this patch that is something other than a blacklist.
I am aware of other issues related to webview and enabling node.js within the Electron sandbox, as well as sandbox escaping, but not the details. For now, avoiding these vulnerabilities are up to self directed developers to educate and learn on how to code around these issues.
On other platforms besides Windows, I think you can do enough research to avoid most of the known pitfalls, and thus I think there may be a possibility to work with Electron in the future.
it is general practice in the industry at this point that development teams are expected to perform their own due diligence on how to avoid security pitfalls that come out of the box with Electron and code around them. This presents another layer of time investment and learning curves related to security that is not what is supposedly required to develop in Electron.
While there is that issue with exposing Node to the DOM, I was more pointing to the fact that they don’t keep up to date with Chromium, i.e.
Electron will often not be on the very latest version of Chromium, lagging behind by several weeks or a few months.
(Source)
Thus, regardless of Node-in-dom and man-in-the-middle attacks, using it as a base for a web-browser (blockstack oriented or otherwise) would not be secure because it does not have much of a priority to keep up to date with security patches. Muon was created by Brave in order to stay up to date almost immediately with Chromium’s patches, etc, and it’s currently the base of their browser. However documentation of how to set it up / etc is kind of sparse, and it doesn’t have the same API as the latest Electron (as it forked some time ago). They are also slowly building up their own Chromium fork to use because of optimization, etc., and thus I would also be cautious of using Muon because it will probably be left to die sooner or later.
That’s why I feel like forking a browser is the only real way to build a “good” Blockstack Browser, as the Electron and Electron-like platforms are not built to be as secure as a web-browser should be.
@MichaelFedora Thanks for the detail and background. That’s really interesting. I would be surprised if Brave abandons this but I have not been keeping up with it. And yes, it sounds like you have some context I don’t for one of the many security related issues to Electron. Regardless, this conversation should reflect ongoing issues with Electron, as well as existing ones as a barrier for us engaging with it as a top priority. It would actually be fun to try to to develop and do it securely, due to the challenges.
We are looking to get more integration with Brave in the future, which is currently a higher priority than developing with Electron.
@retired_user thanks for your earlier answer. Offhand (and with little though I might add), the bigger risk seems to be the remote execution vulnerabilities for the Blockstack use-case in electron. I say this b/c most transactions are e-e encrypted, but if you can access the runtime context remotely, you can get around that which would be problematic.
@alexc.id Yes, outside of obtaining and exposing sensitive user information, remote code execution is generally considered to be the worst case in every vulnerability related scenario. I am not sure fully about how the vulnerabilities reported would effect a blockstack implementation. It has not been explored yet.