TechPrufer
Get started
Slack
Slack logoSlack · Feature trail

Electron App Sandboxing

6 posts · Apr 2016 – Jun 2020

What this trail covers

This thread tracks the evolution of Slack's security posture for its desktop application, focusing on implementing robust sandboxing mechanisms to mitigate security risks. Initial posts detail the foundational architecture and the rationale behind enabling the app sandbox for all web content. This post details the technical implementation of sandboxing in Slack's Electron app, including the use of Chromium's security features, the challenges of dependency untangling with tools like dependency-cr. This post introduces electron-compile, a library that allows Electron to natively Just-In-Time compile popular web languages like ES2015, TypeScript, CoffeeScript, LESS, and Jade/Pug, simplifying the build pipeline for developers and enabling faster prototyping.

All Slack trails
  1. The App SandboxThis post details the technical implementation of Electron app sandboxing in Slack. It explains the security risks of XSS and RCE in Electron apps, the analogy of political checks and balances for sandboxing, and the tradeoffs involved (renderer processes cannot use Node). It covers dependency untangling using `dependency-cruiser` to visualize and restrict import chains between main, renderer, and preload bundles, and the use of `contextBridge` to safely expose desktop functionality from preload scripts to guest pages, enabling communication with the main process via IPC and Promises.
  2. Interop’s Labyrinth: Sharing Code Between Web & Electron AppsThis post details the technical implementation of sandboxing in Slack's Electron app, including the use of Chromium's security features, the challenges of dependency untangling with tools like dependency-cr
  3. Growing Pains: Migrating Slack’s Desktop App to BrowserViewThis post details the migration of Slack's desktop application from Electron's webview to BrowserView to address rendering issues and improve stability. It covers the architectural changes required for BrowserView, which behaves more like a Chrome tab and is managed as a native window rather than a DOM element. The post explains how Slack managed Redux stores across multiple processes using electron-redux, ensuring eventual consistency with the main process's store as the single source of truth. It also details the use of redux-observable for handling asynchronous actions and side-effects, enabling decoupled communication between main and renderer processes, and demonstrating its power with examples of managing sign-in windows and tallying workspace usage.
  4. Introducing Electron to the Windows RuntimeThis post details the integration of Electron into the Windows Store using Microsoft's Desktop Bridge and the Windows Runtime (WinRT) APIs, enabling access to powerful Windows features like lock screens and notifications. It covers the use of NodeRT to bridge Node.js and WinRT, and contributions to electron-windows-store for packaging Electron apps as AppX bundles.
  5. Building Hybrid Applications with ElectronThis post details the migration of the Slack desktop application for macOS to Electron, replacing the older MacGap framework. It explains the hybrid approach to building the application, where some assets are shipped with the app and others are loaded remotely. The post covers the technology stack (React, ES6, TypeScript), Chromium's multi-process model for isolating teams, the use of the WebView element with preload scripts for security boundaries, and the electron-remote library for efficient inter-process communication. It also lists several open-source libraries developed as part of this effort.
  7. Using ES2015 with Electron — introducing electron-compileIntroduced `electron-compile`, a library that enables Just-In-Time compilation of ES2015, TypeScript, CoffeeScript, LESS, and Jade/Pug within Electron applications. This eliminates the need for manual build pipelines, simplifying development and enabling faster prototyping. It works by intercepting JavaScript via Node.js's require mechanism and Chromium's file protocol. Caching of compiled results is implemented using SHA1s of input contents, with a `compiler-info.json.gz` file storing compiler versions and options. For production, a read-only mode compiles all files and copies the cache, reducing I/O work.