So, Why Project Insulate?

To look into why I started building out Project Insulate, let's first quickly try to understand the current standing of the Web Monetization JS API. Let's take the official example:

<script>
    if (document.monetization) {
      document.monetization.addEventListener('monetizationstart', () => {
        // Remove/Hide DOM element using JS/CSS
      })
    }
</script>

Imagine a photographer trying to provide exclusive photographs (provider) to the users paying through a Web Monetization based subscription (for us, Coil). With the current system, he fetches the data through an open API and then hides it on the frontend using JavaScript or CSS.

While this might seem fine to a few people, developers know how easily the open API call can be figured out (bless developer consoles 😇). To resolve this, we primarily see two options:

1. Log-in to the website: Well, the whole point of web monetization is to stray away from individual logins, and hence subscriptions.
2. SSO via Coil: This can technically resolve the problem of protecting the endpoint but poses two big challenges. Firstly, a user will still need to log in with Coil on every website he or she visits. Secondly, more importantly, the provider will have access to the user's Coil account and thus to the user's email address, if approved (but since email is trivial, most users can readily allow it). This defeats the purpose of restoring privacy when paying through Coil.

The above diagram explains the current workflow. The red arrow shows the unprotected open API call made to the backend which can be leveraged by anyone, with or without an active monetization subscription.

To resolve this issue, I decided to build a workflow that enables providers to secure their exclusive data without requesting users to sign into their websites. How? I'll explain that in the next blog.