The Browser That Powers Apps … Meet Electron
The Browser That Powers Apps … Meet Electron
And, so, Electron has helped developers, but is it the same old story, of bolting the barn door, after the horse has bolted?
You generally know what a browser looks like, and that it never quite achieves the same levels of security and performance as a native App. But, there’s a good chance you are using the Electron browser and framework for many of your applications:
The full list is here, so be ready to scroll down …
https://www.electronjs.org/apps
We can see that WhatsApp, Slack and Signal use it, along with Microsoft using it for Visual Studio Code, Teams and Skype. The advantages are obvious, and where a company can support a wide range of operating systems and environments, without worrying about native code. It also helps with easy installs, and where the whole of the code base is built on just HTML, CSS and JavaScript. Along with this, it is open source. It is thus hinting to a future world, and where whole systems just run in a browser — and it might just be the Electron browser.
But … what about security?
But, as it is a browser, it tries to make things generic and will have limited options to actually access the local computer (and thus set the rights of files on the system). It will also have cookies, session variables, and so on. And, so, we perhaps compromise security for the sake of usability.
In a complete cloud environment, it is likely that our apps will be built to run within browsers, as they make the whole infrastructure so much more dynamic. But, one of the great drawbacks of using the Electron browser is that it does not encrypt the sensitive data that it stores. This can include OAuth tokens, and which can be accessed by other applications — such as malware. Those tokens can then be used to gain wide-scale access to systems — including MFA access — to enterprise systems.
Electron … The Native-like App
The Electron framework provides simplicity for App development. The installation is simple with:
git clone https://github.com/electron/electron-quick-start
cd electron-quick-start
npm install
npm start
With a simple index.html of:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<!-- https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'">
<link href="./styles.css" rel="stylesheet">
<title>Hello World!</title>
</head>
<body>
<h1>Hello World!</h1>
We are using Node.js <span id="node-version"></span>,
Chromium <span id="chrome-version"></span>,
and Electron <span id="electron-version"></span>.
<!-- You can also require other files to run in this process -->
<script src="./renderer.js"></script>
</body>
</html>
we can then run with “npm run”, and it produces a Window for us on any supported operating system. This does not look like a browser, and the user just sees a common window. In Windows, we get:
And on macOS, again we install and run with “npm run”:
Conclusion
And, so, that horrible language that is JavaScript is taking over in the world of applications. Like it or not, it has solved the problem of running code on many systems. It has also solved performance issues, and where browsers can now run code as fast as the user needs. But… what about JavaScript library integration? Can that be trusted, and where a single compromise on a library could open up the whole of the application to compromise? And what about security? At present, Electron does not widely support encryption, so how will sensitive data be protected? And for file access? Well, that’s not well supported either, and where other applications can gain access to the files that each app produces.
If you are interested, here’s some of the latest vulnerabilities that have been identified, including a remote code execution vulnerability in Microsoft Visual Code and revealing OAuth tokens in Teams:
And, so, Electron has helped developers, but, is it the same old story, of bolting the barn door, after the horse has bolted?