Developer Experience

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

Benefits for web developers

We can’t imagine exactly what that would cause, but can at least say the following:

1. The keys are isolated, concealed, and not accessible to any general web app.
2. You, web developers, no longer need key management by delegating it to the browser
3. You would just use native APIs exposed for web apps

It’s worth noting that this is self-custody, not custody, because custody is similar experience to the web developers, as you only access the API and don’t need key management. On the other hand, there is a deep gap for the users between the two, as any Bitcoiner knows, “Not your keys, not your coins”.

However, self-custody is very hard. We won’t go into many of it here - you’ll have to read other texts to find out - but the point is that some of the difficulties of self-custody can be solved by having the browser receive the delegation. It’s important to also note that we never intended for the browser to have any stored assets - just spending online.

That is similar to being put in the web storage and being kept by extension, but any web app can’t access the key. That is similar to treating API via external remote service that holds the key (while being non-custodial), but it can be there from the moment the tab creates and is persisted forever. You may not worry anymore about leakage risks and race conditions.

Browser architecture and APIs

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

“cached data” is put in Local storage, Indexed DB and so on, “secret key” is in the internal store. Both are accessed by the app through a global window. However, secret key is, in addition to the usual web sandbox model, further protected by the browser’s process security model.

Taking Firefox as an example, the “secret key” is in the Parent Process and the “cached data” is anywhere, typically 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 security policy, and the bridge to user land is handled by the native APIs, browser.ssi and window.ssi.

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

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

It means that user keys are not affected even if your web app itself unfortunately - no matter how carefully and conscientiously you develop - becomes vulnerable or malicious enough to steal them. Those problems may be the same about browser software, but it is less susceptible to supply chain attacks due to its limited leverage of package ecosystems (much of it is hand-coded) and more robust due to being centered around the process model described above and significantly limited external communications; the attack surface is much smaller.

Although not as much as completely separated hardware or paper would, it hopefully makes the secret key truly secret and minimizes the risk of leakage by web apps. And, importantly, online usage will be more fluent than hardware or paper, and on par with general web apps that hold keys.