Developer Experience

In this section, we’ll explain how web app development changes when browsers have self-custodial key management built in, along with browser features designed to directly integrate self-custodial keys.

Benefits for web developers

While we can’t predict all the potential impacts, we can at least highlight the following:

1. The keys are isolated, concealed, and not accessible to any general web app.
2. You, as web developers, no longer need to handle key management, as it’s delegated to the browser.
3. You will simply use native APIs exposed for web apps.

It’s important to note that this is self-custody, not custody, because custody provides a similar experience for web developers, as you only access the API and don’t need to manage the keys. On the other hand, there is a significant difference for users between the two. As any Bitcoiner knows, “Not your keys, not your coins.”

However, self-custody is very difficult. We won’t delve too much into it here—you’ll need to read other resources to learn more—but the point is that some of the difficulties of self-custody can be alleviated by delegating the responsibility to the browser. It’s also important to clarify that we never intended for the browser to store assets—just to facilitate online spending.

This is similar to storing data in web storage, managed by an extension, but with one key difference: no web app can directly access the key. It’s akin to using an API through an external remote service that holds the key (while remaining non-custodial), but this key can be available from the moment the tab is created and persisted indefinitely. You may no longer need to worry about leakage risks or race conditions.

Browser architecture and APIs

To explain how this works, let’s modify the diagram from the previous section to focus on the app side and distinguish between “cached data” and “secret key.”

“Cached data” is stored in local storage, IndexedDB, and similar locations, while the “secret key” is kept in the internal store. Both are accessed by the app via a global window. However, the secret key is further protected by the browser’s process security model, in addition to the usual web sandboxing.

Taking Firefox as an example, the “secret key” resides in the Parent Process, while the “cached data” is typically located in the WebContent Process, in the Child Process.

cite: https://firefox-source-docs.mozilla.org/dom/ipc/process_model.html

These inter-process communication (IPC) operations require privileged permissions and a security policy, with the bridge to user land handled by the native APIs, browser.ssi and window.ssi.

Again, in Firefox, the “chrome:” on the right corresponds to those native APIs and has permissions to privileged services over the parent process, while interference from the left in user land is blocked.

cite: https://firefox-source-docs.mozilla.org/dom/scriptSecurity/index.html

This means that even if your web app becomes vulnerable or malicious—no matter how carefully it is developed—the user keys are not at risk. While the same issues could arise with browser software, browsers are less susceptible to supply chain attacks due to their limited reliance on package ecosystems (much of it is hand-coded). They are more robust because they center around the process model described above and have significantly limited external communications, which reduces the attack surface.

While not as secure as completely separated hardware or paper, this approach should ensure that the secret key remains secret and minimizes the risk of leakage by web apps. Importantly, online usage will be more seamless than with hardware or paper, and on par with general web apps that manage keys.