We've built our SDK, Critical Moments, based on a concept we call "Trustless SaaS". That is software that is remotely controlled or delivered, without the need to trust a third-party service provider for correctness, security, or uptime SLAs.

In this blog post, we cover what “Trustless SaaS” is, why it benefits both us and our customers, and how we implement it using public key encryption.

Trustless SaaS Model

These three policies collectively form our “Trustless SaaS” model:

Source-Available

Any code you run should be source-available. You can inspect all of the code and compile builds from source yourself. This way, you know that the binary isn't doing anything nefarious without needing to trust us.

Our SDK's source code is available on GitHub.

Self-Hostable

Any required web services should be self-hostable. Moreover, they should be simple enough to self-host that most people choose this option. You don't need to trust that a service provider won't change how the service works without your approval, because they can't.

For Critical Moments, we've implemented this through a web-hosted config file, which controls all of the SDK features.

No User Tracking

A Trustless SaaS company shouldn't track your users. You don't need to trust their data and security practices, because they never have access to private data. Even if they are compromised, your data remains secure.

The core functionality of Critical Moments does not involve accessing servers we own. However, there are two exceptions tied to optional features, which we will explain below. If you choose not to use these features, your clients will never communicate with our servers.

Benefits

We believe that Trustless SaaS offers a wealth of benefits over traditional SaaS models:

Of these aspects, we believe Trustless SaaS excels compared to traditional models in almost every category, though the preference for "Bring your own hosting" might vary. We discuss how we mitigate hosting tradeoffs below.

How we Implement Trustless SaaS with Public Key Cryptography

Trustless goes both ways: we aim for more than just an honour system to ensure that people don't just steal our software. After all, we are running a business.

Critical Moments offers both free and paid plans, featuring different capabilities (with the Pro plan offered for free to small companies). You can see our plans here.

Instead of limiting feature sets through service calls as traditional SaaS companies might do, we rely on public key cryptography. Here's a simple breakdown of our approach:

• The public key is embedded in the SDK. The private key is never published.
• Clients must register on our website to receive an API key, which is necessary to activate the SDK. Each API key includes a signature unique to the app's ID. Using an API key intended for a different app will prevent the SDK from starting.
• The config file you use dictates which SDK features are enabled. Before deployment, you must sign your config file using our signing service. This service checks your subscription level and won't sign if you're attempting to use features you haven't subscribed to.
• Our signing service also scans for common issues, alerting developers to potential problems before deployment.
• The client SDK can independently verify API Key and config file signatures locally, quickly, offline, without needing to contact any server (using elliptic curve signatures). This means your user's app does not need to communicate with our servers.
• This framework also allows you to change your plan at any time, sign a new config, and immediately deploy your new feature set to all existing clients, without needing app store updates.

If there's interest, we'll release a more technical blog post examining the details, including our choices for signing algorithms, signature length, encoding, signing packages, performance testing, and other fun nerdy details 🤓.

Example Trustless SaaS Companies

We're not the first to offer software in this manner. Here's a look at several companies applying the Trustless SaaS model, and the mechanisms they use:

• Critical Moments (Us!): Uses self-hosted config files, elliptic curve signed API keys, and elliptic curve signed config files. All source code is available.
• EmailEngine: Features self-hosted servers, elliptic curve signed API keys with expiration times, and source-available code.
• Campfire by 37signals: Offers source code after purchase and a self-hosted server option for a one-time purchase.
• Jira and Confluence by Atlassian: Provides a self-host option with source code accessible to customers after purchase.
• GitLab: Operates an open-core model with a “trustless” enterprise edition, and optional hosting.
• Bitwarden: Optional self-hosted service, source available on GitHub, downloadable licence file to unlock features, optional cloud-pull of new licenses.

Addressing Concerns With Trustless SaaS

Software Theft

One potential issue with making our code source-available is the risk of it being stolen. There are two avenues for this:

1. Users may subscribe, obtain a signed configuration, but continue using it long after their subscription has ended.
2. Direct theft, such as removing or bypassing our access control measures.

For the first scenario, we believe the dynamic nature of Critical Moments — allowing updates such as new actions, triggers, and logic — makes it less likely for users to benefit from a static setup. Our terms of service disallow such practices, and we hope most companies are honest. If we do see this happening often, we could always implement measures against accounts frequently subscribing and unsubscribing for short periods.

For direct software theft, while there is a risk, we don't believe it will significantly impact our business. Many other companies with open-core and source-available models have preceded us and successfully proven this business approach. Our most important customers are unlikely to undertake the legal risks associated with piracy, such as DMCA violations, breaches of our terms of service, or compromising their own intellectual property.

We don't want to compromise the user experience for our best customers just to deter those who are unlikely to pay anyway.

We think the benefits of Trustless SaaS outweigh the risks when in comes to software theft.

Company Shutdown

Another concern is what happens if our company ceases operations. Here's our plan for if that ever happens:

• Our SDK's source code is publicly available. The code shows that access controls don't have time-bombs, and can be removed.
• Should we discontinue the CM signing service, we're committed to release our client code under an open-source license, including the public key to allow signing new config files for existing installations. We hope to codify these promises in our licence in a future update.
• Trustless SaaS is self-hosted from the beginning, reducing your dependency on our continued operation.

Again, this is a significant improvement over traditional hosted SaaS alternatives. They usually lack a commitment to release their software as open-source in the event of a shutdown. Even if they do release it, self-hosting a complex service while ensuring its ongoing operation and security can be costly and impractical. In contrast, Trustless SaaS is designed from the outset to be simple and straightforward to self-host.

Trustless Build System

To simplify onboarding, we provide binary builds as part of our release process. Here's how we ensure these remain trustless:

• Builds are executed using GitHub Actions, which generate publicly viewable logs that confirm the integrity of the build process.
• Our Package.swift file verifies that the binary's signature corresponds with the signature logged by GitHub Actions.
• Users have the option to compile binaries themselves using our provided scripts, offering an additional layer of trustlessness.

Hosting Convenience

Some companies prefer hosted SaaS for its ease of use; not everyone wants to manage another service. Here's how Trustless SaaS can address this:

• Keep self-hosted services simple. For example, Critical Moments only requires a single config file that can be hosted on any web server. Other companies offer one-click cloud deployments, or single-container hosts.
• Offer partially hosted options for more complex services. For instance, Critical Moments provides hosted weather and geo-IP services to make things easier for customers. Similarly, Bitwarden offers mixing self-hosted password vaults, with a hosted license service.

If enough customers are interested, a Trustless SaaS company can add full hosting services to complement their self-hosted options.

Signing Service Robustness

While the core SDK does not require any service hosted by us for ongoing operations, you do need to contact our signing service to sign new configuration files. An outage at our service will not prevent your existing clients from continuing to function as usual, but it would temporarily hinder your ability to implement changes. Despite this, we view our system as a substantial improvement over traditional hosted SaaS, where SaaS outages could completely disable end-user functionalities.

Additionally, our team possesses over a decade of experience in hosting complex, high-volume services. Given the relatively simple nature of the signing service compared to our previous projects, we anticipate that outages will be exceedingly rare.

Optional Services

While the core Critical Moments service never requires the client calling a server owned by us, some optional features require external data sources:

• Geo-IP Service: Determines the user's approximate location using IP addresses—this requires a database which can't be embedded in the SDK because it's too large, and changes often.
• Weather Conditions: Requires access to frequently changing weather data.

We have implemented several measures to ensure customer data protection. We transmit only the minimal data required for service functionality, and never transmit any personally identifiable information. We maintain a brief log retention period to enhance privacy. For weather services, we add up to 1km of 'noise' to obfuscate the user's location before it is transmitted (as precise GPS accuracy is unnecessary). Additionally, we proxy all requests to our third-party weather provider, which conceals the end-user's IP address from them, ensuring they don't retain IP data long term.

We are open to offering self-host options for these services if there is sufficient customer demand.

Conclusions

We are optimistic about our choice to build our company around the Trustless SaaS model. It aligns our interests with the interests of our customers:

• Companies can trust us precisely because they don't have to.
• Customers can see exactly what we're offering and can try before they buy.
• Our system already supports your existing security model, because it works within your infrastructure.
• It reduces blockers for enterprise sales (like the need for SAML or Single Sign On protocols, and complex audits), thereby speeding up the sales cycle.
• Operationally, it simplifies the "service" aspect in SaaS to a single remote config file, which can be hosted anywhere.
• Unlike the open-core model, we don't have to balance giving away too much or too little in our free offering. We're honest that it's a paid product, and it's fully source-available for total transparency.
• Designing for Trustless from the start provides flexibility. On-premise solutions are available immediately, and it's also easy for us to introduce a hosted option if our customers prefer convenience.

Time will tell if this approach proves successful, but we're eager to see how it unfolds!