You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 4, 2023. It is now read-only.
Rendering untrusted content in Electron is still somewhat uncharted territory, though some apps are finding success (e.g. Beaker Browser). Our goal is to get as close to Chrome as we can in terms of the security of sandboxed content, but ultimately we will always be behind due to a few fundamental issues:
We do not have the dedicated resources or expertise that Chromium has to apply to the security of its product. We do our best to make use of what we have, to inherit everything we can from Chromium, and to respond quickly to security issues, but Electron cannot be as secure as Chromium without the resources that Chromium is able to dedicate.
Some security features in Chrome (such as Safe Browsing and Certificate Transparency) require a centralized authority and dedicated servers, both of which run counter to the goals of the Electron project. As such, we disable those features in Electron, at the cost of the associated security they would otherwise bring.
There is only one Chromium, whereas there are many thousands of apps built on Electron, all of which behave slightly differently. Accounting for those differences can yield a huge possibility space, and make it challenging to ensure the security of the platform in unusual use cases.
We can't push security updates to users directly, so we rely on app vendors to upgrade the version of Electron underlying their app in order for security updates to reach users.
While we make our best effort to backport Chromium security fixes to older versions of Electron, we do not make a guarantee that every fix will be backported. Your best chance at staying secure is to be on the latest stable version of Electron.
The text was updated successfully, but these errors were encountered:
Hey. I'm not directly involved in the project, but interested in the topic. Most of these caveats exactly apply to Chromium-based browsers as well (updates managed by the vendor, lots of variety, security backports, centralized services), so I am not hugely concerned about those. However, as far as I'm aware and despite all the securing efforts by the Electron team, as soon as you can access the app's JavaScript runtime you can basically compromise most of the computer. This means that the biggest concern should be the isolation between the BrowserWindow/BrowserView and the main application. I would be interested in how secure that is.
Electron security model is very similar to the Chromium's, but sometimes vulnerabilities happen to be introduced by Electron, for example window.open used to create a BrowserWindow with nodeIntegration enabled by default. As long as you monitor everything and make sure that every process is context isolated and sandboxed, you should achieve similar safety to Chromium.
This project is no longer maintained though and I use Chromium.
First of all I really admire the initiative, I believe custom browsers should be a thing.
What I would like to ask is how the issues that electron mentions are addressed:
A note on rendering untrusted content
The text was updated successfully, but these errors were encountered: