Securing Booplet (Beta)

The aim of Booplet is to make it easy for anyone to create an app. But with great power comes great responsibility. We want Booplet users to enjoy the freedom of building any app they can imagine, without having to worry about leaking data or unknowingly modifying an important folder. How do we grant this superpower while minimizing risks?

In the beta release of Booplet, we focused on the following:

• An initial set of hardcoded safeguards limiting what Booplet apps can do
• A way for users to finetune security settings, while providing sensible defaults

This article is divided into two parts.

The first section provides an overview of the security settings. We encourage all users to go through this to understand what security settings are available.

The second section is a more technical look at the initial safeguards implemented in the beta release, meant for anyone interested in learning more about what goes on under the hood.

Customizing your apps' security

Part of Booplet's security entails the user (you!) deciding what should be allowed or blocked, while providing a set of sensible defaults.

The global security settings can be found by clicking on the gear icon at the top of the Home window (which contains all of the app icons) and navigating to the Security tab. These global settings apply to all Booplet apps by default.

Here are the different settings available:

1. Allow external libraries

Enable libraries from external content delivery networks (CDNs). Disabling this ensures only local libraries are used, which improves security but limits functionality.

Apps often make use of libraries, which are code packages that grant additional capabilities, such as three.js for 3D visualization and chart.js for plotting graphs and charts. Enabling this means Booplet apps can access these libraries and support a wider variety of capabilities.

On the other hand, we want to avoid using libraries from untrusted sources. By default, Booplet apps can use external libraries that are limited to only reputable domains. See the CDN access scope setting for more details.

2. CDN access scope

Define which external CDNs are permitted for loading packages. Restricting this helps ensure only trusted sources are used.

This setting is shown when Allow external libraries is enabled.

External libraries and packages can be very helpful, but we want to prevent Booplet apps from fetching code via potentially malicious sites.

This setting limits which library sources can be accessed by Booplet apps and defaults to a list of reputable sources, including https://unpkg.com and https://esm.sh, which typically mirror or query the official npm package registry for JavaScript.

3. File read permissions

Specify which files or folders apps are allowed to read. Protect sensitive files while granting access to documents you want the apps to work with.

This setting allows you to configure which files and folders can be opened by Booplet apps via an allow-list and a block-list.

When a Booplet app requests for access to a file, we first check if the file adheres to both of these rules before granting permission.

For example, suppose we have the following configuration:

This configuration means that you will only be able to open files and folders inside the Desktop and Downloads folders. In addition, you will NOT be able to open any files and folders inside the Desktop/Private folder since that is included in the blocked list.

To give some concrete examples:

• /home/username/Photos/image.jpg will not be accessible because it is not in Desktop or Downloads
• /home/username/Desktop/image.jpg is accessible since it is in the Desktop folder
• /home/username/Desktop/Private/image.jpg will not be accessible because it is in the blocked Desktop/Private folder

This is the default configuration.

The default configuration only allows access to your Desktop, Downloads, and Documents folders, as well as the app’s own special data folder on your computer ($APP_DATA_DIR above). It also blocks access to anything that begins with the period sign ".", which typically indicates hidden files or folders that should not be accessed.

4. File write permissions

Define where the apps are allowed to save or modify files. Restricting this ensures apps can only modify intended locations.

This is similar to File read permissions, but entails the permission to modify, create, and delete files.

It has a similar default configuration.

5. Network request scope

Control which websites apps can fetch data from. A narrower scope reduces exposure while still allowing necessary integrations.

Some apps may require access to external websites. For example, an RSS feed reader will need to fetch the latest articles from RSS feed URLs. This setting controls which websites can be accessed by the apps.

By default, only URLs via a secure https connection can be accessed.

Important notes about scope settings

• If the allowed list is empty, it means “everything is allowed,” unless specifically denied by the block list. In the configuration below, since the allowed list is empty, it means all files and folders will be accessible except for /home/username/Desktop/Private/.

• If the blocked list is empty, only the allowed list will be enforced. In the configuration below, since the blocked list is empty, it means only files and folders in the Desktop and Downloads folders will be accessible.

• If both lists are empty, no restrictions will be enforced for that specific scope.
• Use the "*" character as a joker or wildcard. For instance, setting "Allowed files/folders" to "/home/username/Desktop/A*" will only allow access to files and folders in the Desktop that begin with "A", while setting "Blocked files/folders" to "*" will block ALL files and folders from being accessed.
• If there is any conflict, the blocked list takes precedence over the allowed list.

App-specific settings

By default, all Booplet apps inherit the global security settings. But if you want to override the settings for a specific app, navigate to the app-specific settings by first opening the app, clicking on the gear icon at the top, and navigating to the Security tab.

In the app-specific settings, each section has a "Follow global setting" toggle that defaults to true. This means that the app will follow the global setting for this particular section. Turning this off will allow you to configure settings and override the global defaults for this particular app.

Overriding global settings for a photo app to give access to the Pictures folder.

Protecting you with built-in safeguards

This section discusses some of the additional security measures built into Booplet and involves slightly more technical language.

In addition to the settings mentioned above, Booplet also implements further security measures under the hood.

When any app is generated in Booplet, we first screen the code for potential red flags and inject safeguards during the compilation step. Subsequently, each app is run within a restricted environment with limited or augmented access to native utilities.

Restricting Tauri APIs

Booplet is built with the Tauri framework, which provides access to a wide variety of features, such as reading and writing local files, sending notifications, and showing dialogs.

We start off by limiting Booplet apps to a restricted set of Tauri capabilities that is nevertheless sufficient for the majority of use cases.

In some cases, the capability is completely removed, such as the ability to execute arbitrary code via a shell command.

In other cases, the feature is augmented. For instance, Tauri's file system plugin has a "remove" method for removing files and folders. The native implementation is similar to the "rm" command, which causes the file/folder to disappear without recourse. In Booplet, we modify this so that deleted files and folders are moved to the local Trash bin instead.

All methods that entail reading or writing files are also intercepted in order to enforce the user-configured security settings discussed earlier.

Restricting common utilities

Common JavaScript utilities are wrapped or augmented with additional safeguards.

For example, each Booplet app supports local storage for saving long-term data and preferences. This storage has been updated to prevent inter-app access, and to remove cleanly when an app is deleted.

We also block the native fetch method in the restricted app environment. Instead the app should use alternative methods depending on the use case.

• For loading external libraries, a custom CDN loader is implemented that enforces the CDN access scope setting
• For fetching data via GET requests, a custom fetch command is implemented that enforces the Network request scope setting
• Non-GET requests are disabled for now

During the compilation, we also try to screen for eval and eval-like functions and throw an error if such code is found. The restricted app environment also has a secondary measure to disable eval and eval-like functions.

What’s next

The ultimate aim of Booplet is to make it easy for anyone to create an app. To that end, we believe app security should also be made accessible and easily understood, and a lot more can be done to improve the user experience security-wise. You can expect a more readable security interface, as well as greater transparency over the permissions used in an app.

At launch, Booplet’s security measures focused on preventing users from accidentally creating dangerous software. Subsequently, we will also be implementing more comprehensive measures to tackle potential malicious activity. This is especially important when we eventually allow Booplet users to share their apps with one another.

If you are interested in this area, do reach out!