Just about all desktop containers used in finance today embed browser technology, and just about all of those use Electron to do so. Electron is an open source project that combines Chromium (the engine at the core of Chrome and Edge browsers) and NodeJS (javascript server technology) to create a very powerful and popular environment for developing desktop applications using HTML and Javascript - rather than the more traditional C++, Java, or .NET. Electron is a robust and mature open source project that is used to deliver key applications such as Visual Studio Code, Teams, Slack, and many, many others. It has considerable backing from the teams at Github (who first started the project), Microsoft, and Slack.

Because desktop applications are extremely powerful and privileged, any combination of a browser technology and a desktop technology is always a reason for concern. There is an impedance mismatch in the security bias of browsers and desktop apps.  While a desktop app runs with a high level of trust which imposes a high bar at install as a mitigation, the browser runs its content with 0 trust in exchange for 0 install cost. Therefore, the most secure pattern for building applications with Electron is for your application to not load any remote content at all. In other words: have all of the HTML, Javascript, CSS, etc that your application uses installed and run anything like a website outside of your application in the default browser. 

However, this pattern leaves a lot to be desired (basically, all of the benefits we’ve come to love and rely on with the web). The whole point of web-based desktop containers in FinServ, in fact, is to do 2 things that stand this Electron model for security on its head:

1. Load apps from the web without install
2. Provide those apps with APIs that allow them to do things that aren’t allowed in a commercial browser

The crux of the issue here is that if you run content from the web in any browser, you have these basic threats:

• Man-in-the-middle attack - content being intercepted by a hacker on the network
• These are mitigated by enforcing use of https everywhere and UX mitigation in the browser
  
  
• Cross-site scripting (malicious code has been injected into the trusted website you are on and breaks out of your browser, or uses social engineering to get personal data)
• These are largely mitigated by keeping your browser up to data, application owners using CSP (content security policy) and UX mitigations in the browser (more about this below)
  
  
• Social engineering - phishing attacks that trick users into divulging passwords and other sensitive information to malicious sites that appear to be legitimate. These are the hardest to mitigate and rely on UX mitigations on browsers and email systems, etc.

To the above list, desktop applications using Electron or similar technologies add the following dimensions:

• Auto-updating (if the browser engine is not auto-updated, the vector for especially cross-site scripting attacks becomes more prominent)
  
  
• Code supply chain vulnerabilities through NPM.  This is a problem across every part of the stack - but the stakes are higher in Electron where Node is running directly on the end user’s desktop.  Beyond eternal vigilance by devs in sourcing, maintaining, testing and updating their packages, the best mitigation is limiting the surface area of what an electron app is doing - especially in Node.  The all singing, all dancing client platform simply has a much larger surface area for these kinds of attacks.
  
  
• Custom APIs - almost all desktop containers add additional APIs that grant more power to the applications running in them.  With great power comes great vulnerability vectors.  Without thoughtful and consistent mitigation, these APIs can become a serious security risk.
  
  
• Security architecture. While Electron now has reasonable defaults for security and strong guidelines. Ultimately, the security implementation is up to the development team building the Desktop Container and they may or may nor have this as a priority and have the knowledge needed to make the right design choices.
  
  
• Security UX. This one is often overlooked.  Browser makers invest a lot of time and resource in ensuring that the UX of the browser provides users with strong indicators about security (i.e. displaying a lock if you are using HTTPS and a warning if you are not, handling and blocking pop-ups, communicating and managing elevated privileges a website may request (e.g. notifications or access to the camera). None of this UX is provided out of the box  in a project like Electron.

To summarize: the high level of why using browsers to build desktop applications is both so compelling and also constrained by risk and trade-offs between features and security. It’s easy for anyone who’s worked on a FinServ thick desktop product to understand the appeal of a technology like Electron eliminating the need for cumbersome installs, slow development cycles and even slower releases. It’s also critical for us to understand the source of risks, the responsibilities that come with them and the mitigations that are available.

2. Auto updating and Current State of Electron Security

Earlier iterations of Electron were not secure by default, were significantly behind the Chromium updating schedule, and required a fair amount of lift to auto-update. However, those days have long since passed. Electron has been in sync with Chromium stable releases since September of 2021, enforces critical security features by default, and any open source Electron project on Github can integrate with Github’s auto-update service for free. There are a host of other update services/projects as well that support private repos and/or non-Github repos.  Including:

• Hazel
• Nuts 
• electron-release-server 
• Nucleus 

Chasing Chromium

It can’t be stressed enough what a significant achievement the Chromium release parity is. All of us in FinTech owe a huge debt to the Electron team and especially the teams from Github and Microsoft for persevering and making it happen.  Given the scale of the effort, it’s unlikely that any of the desktop container platforms in finance would be up to date with Chromium without this monumental effort from the Electron community. This kind of cooperative effort is exactly the kind of problem solving that open source excels at and I’m hoping we can see more flow of contribution from the FinServ/FinTech community back to projects like Electron - which we all benefit from.

Note on the Scope of Code Signing

To get your Electron app auto-updating through Github, you need to have your code signed for both Windows and Mac. This is a critical component of security for any desktop application and ensures that the code being installed has not been tampered with after the fact and if you trust the creator of the application, you can trust what you are installing.  Which raises an interesting question about the meaning of code signing for desktop container platforms, where the Electron code is signed by the platform, but the application being installed is typically coming from another 3rd party that is using the platform APIs to deliver desktop functionality. If the API of the platform is sufficiently secure and limited (i.e. doesn’t allow for arbitrary execution of code, launching of external processes, or access to the hard drive) or if the platform provides a robust sandboxing and permissioning of such features (like we see in mobile ecosystems) then code signing a platform is meaningful.  Otherwise, it may be more like signing a blank check.

3.  API Injection Surface Area

Desktop container platforms mostly exist because of gaps in standard browsers. Application developers in finance want to build and deliver their applications via web technology and rightfully leverage the enormous advantages that this tech brings. End users want their work apps to have the same look and feel they’ve become accustomed to in the consumer web. There are simple use cases - like having a launchable icon on the desktop that have already been addressed by PWA technology in standard browsers. But significant gaps remain.

For the most part, desktop container APIs fill fall into three categories:

• Interoperability - allowing applications to exchange messages, provide service discovery, and orchestrate behavior. This is the domain FDC3 standardizes.
• Native Integration - launching external processes, accessing the hard drive.  These are the most obviously sensitive areas of security and according to the Electron security standards no remotely loaded content should ever have direct and arbitrary access to these functions.

(see https://www.electronjs.org/docs/latest/tutorial/security)

• Windowing: we like to manipulate windows on financial desktops, moving them, grouping them, launching them, hiding them, giving them an artistic flare. Desktop platforms in finance often provide applications with APIs to do all of this stuff - which means all of these APIs are exposed to remote content from the web (i.e. potentially malicious). There is a reason modern browsers discourage even pop-up window use. Windowing APIs create a large surface area for attack - especially social and phishing hacks.  

More about Security UX

For the Chromium Security UX team, one of the biggest security challenges on the web is providing end users with a UX that keeps them on a safe path while they go about normal interactions on the internet.  Are people warned if the content on a site is potentially malicious or compromised? How do they know that the site they are on is using HTTPS?  How do they know if they’ve been unexpectedly navigated to a different domain? Are permissions (for notifications for example) being asked for clearly and accurately? Can they be revoked easily after the fact? How should it identify phishing content? There is a ton of thought and work that goes into the UX in Chrome, Edge, Firefox, Safari, etc to make browsing the web tolerably safe.  

4.  Security in Electron FDC3

The Electron-FDC3 project implements standard Electron security guidelines. All remote content is run in BrowserViews with sandboxing and no Node integration. Context Isolation is used to further protect the api from cross-site scripting. What’s more:

• Electron FDC3 is open source, so it can leverage free auto-updating from github. Any open source fork of it can as well. (and if you want to make a private fork - there are plenty of other options as well). The Electron FDC3 community will be working in the coming weeks to begin releasing signed and auto updating FINOS builds of the project so that developers can get up and running quickly and securely. As part of Electron auto-updating, these will be in sync with Chrome stable releases by default.
  
  
• Electron FDC3 doesn’t inject any APIs into its web content beyond the FDC3 API. This means the security surface area is relatively small - there are no windowing APIs that could be exploited by a malicious app, no APIs to launch external processes or access the file system.  Security is a big point of discussion when we are designing the FDC3 APIs and all APIs are designed to let the Desktop Agent (in this case Electron FDC3) manage the rules of interop.  Going forward with this project, there is the opportunity for the community to decide and implement the defacto standards for those rules in the open.
  
  
• The same is true of Security UX, Electron FDC3 presents an opportunity for the community to determine how Application identity should be presented to the end user.  Or what sort of UX mitigations need to be in place when an end user broadcasts context or receives an intent.  These are all vital questions of security and usability of interop going forward and the best place for them to be sorted is in the open.
  
  
• Finally, since Electron FDC3 is open source, all of the code can be inspected by the developer community - helping to ensure that it stays secure. We’ve seen time and time again that open source projects are more secure and better able to address security head on than closed ones. Electron’s turn around on security in the past few years is a great example of this.  

5. Bringing it All Together

A perfectly secure system would do nothing, but of course, it would also have no value. Security is always a balance of risk and opportunity, costs and benefits, and features held in check by layers of mitigations.

When in doubt, using an actual browser is the best way to securely use web apps.

If you need functionality that you can’t get in a browser, look for the solution with the smallest surface area possible and that aligns to the standards of the web as closely as possible and ideally, one that is open source and built on and closely aligned with robust open source projects. 

Most of all, have fun and stay safe.

Further  reading

Electron’s Security Tutorial: https://www.electronjs.org/docs/latest/tutorial/security: ​​

Electron’s Auto updating Tutorial: https://www.electronjs.org/docs/latest/tutorial/updates 

Chrome’s Security UX home: https://www.chromium.org/Home/chromium-security/enamel/

Electron FDC3: https://github.com/finos/electron-fdc3