The Interledger Community 🌱: Project Insulate

Project Insulate — Grant Report #1 (Final)

Abhinav Chawla — Tue, 02 Mar 2021 04:19:25 +0000

Project Update

I can proudly say that the Project Insulate work has been completed. I have documented it deeply in my 3-part series.

Progress on objectives

The Chrome Extension is available at Chrome Web Store
Source Code: Link

The backend is deployed at Heroku
Source Code: Link

The source code is overall packed in the project-insulate organization

Key activities

At the core, I wanted to build an architectural solution to solve the issue of protecting data fetched from a backend server - insulating the data, hence Project Insulate. This involved various different steps including:

Step 1: Coming up with an architectural overview and a wireframe. This was probably the hardest part since it involved coming up with a solution to not only protect the data, but also the identity of the user. I explained this step in detail here.

Step 2: Getting access for Coil SSO and establish Coil OAuth to log in users.

Step 3: Build the Chrome extension which end users can use to complement the current Coil extension.

Step 4: Develop the backend server for Project Insulate which the provider can connect to verify users on their website before providing protected data.

This blog shows the final product, and how it works!

Communications and marketing

I have shared the work with my friends and shared the web monetization technology with colleagues. I didn't include marketing in my budget.

What’s next?

I aim the process could be eventually integrated with Coil extension itself. It wouldn't be feasible in the long run for encouraging people to install two extensions, so I wanted this project to serve as a working prototype of how such integration could work.

What community support would benefit your project?

I would love to see what the community feels about the project and work on it. It would be great if it could be shared further in the web monetization community. It would also be interesting to learn other developers' feedback on alternate ways to resolve the issue of protecting data.

Additional comments

It was a great experience to present my project and be a part of this growing web standard and community. Always looking forward to talking with like-minded people, so if any one has any concerns or just wants to say hi, feel free to reach out :)

Lastly, thanks to the Grant for the Web initiative for letting me an active participant.

Let's see it working!

Abhinav Chawla — Tue, 16 Feb 2021 19:25:36 +0000

Firstly, an apology. This blog demonstrating the demo was supposed to be published a month or so ago, but things just kept getting delayed. Nonetheless, here were are!

As looking into the architectural diagrams in the previous post, let's divide the usage by three different personas:

Provider - Someone who is providing protected content
User - Consumer of the content via a Browser
Insulate - The core of this project managing the flow

Let's break it into smaller segments to show different steps involved with the project and which user persona it targetted to.

Step A: Provider - Register with Insulate

curl --request POST 'https://project-insulate.herokuapp.com/api/provider' \
     --data-urlencode 'email=changeme@test.com'

Running this command will give a client_id and a client_secret which should be stored by the provider. client_id is a public value, but client_secret should be, well, kept as a secret!

Step B: Provider - Update meta tags on their website

On the UI side, ensure that you have the following two meta tags:

monetization: Put your wallet pointer id
insulate-id: Put the client_id collected in Step A

Here's a demo file, and would like like this:

<head>
    <meta name="monetization" content="$ilp.uphold.com/H3NqAwkm9g3W">
    <meta name="insulate-id" content="16ebdcd5b3067e95fe7146e5b15052dd27618615fb2296b5">
</head>

We will come back to make a minor update to this file but in a later step.

Step C: User - Install the extension

The user (on a Chrome browser) needs to have the Project Insulate extension installed. It is available on Chrome Web Store.

Once the user installs it, it needs to sign in with Coil.

And that's it for the user! Quick and easy, hopefully, something like this can be directly integrated into the Coil extension itself.

Step D: Provider - Verify the user view

If your website has both a valid monetization and insulate-id, the extension will automatically talk to the Insulate backend, so some maaagiiiccc (details in the previous techie post), and return an insulateTransactionId.

The provider needs to capture this insulateTransactionId, and send it back to its backend where it can be verified.
Let's go back to the HTML file and add a listener:

window.addEventListener("message", function (event) {
        // We only accept messages from ourselves
        if (event.source != window)
            return;

        if (event.data.type && (event.data.type == "insulateTransactionId")) {
            let transactionId = event.data.text;

            // *** Make call to backend (provider) and send transactionId *** 

        }
    }, false)

Again, the demo file has the above as an example.

Step E: Provider - Validate the insulateTransactionId

Now, once the UI gets the insulateTransactionId, it can be passed to the backend, which can use the client_secret received in Step A to confirm with Insulate about its validity.

curl --request POST 'https://project-insulate.herokuapp.com/api/block/verify' \
--header 'Content-Type: application/json' \
--data-raw '{
    "paymentPointer": "$ilp.uphold.com/H3NqAwkm9g3W",
    "clientSecret": "10cc6c3ea96bb3ab525c61af71dfa1e58d11159cfd5de3d6",
    "transactionId": "c3798dce-4893-497e-8b80-f48a52896eda"
}'

Here ensure the paymentPointer matches the one on your website and pass in the insulateTransactionId as the transactionId in the POST call.

Insulate backend will return you the following fields:

recordFound: If the record with the provided transactionId was registered within last 5 minutes, it will return true, else false.
visitedBefore: If (1) is true, this will return true if a previous call was made to check its validity.
oldRecordExisted: If (1) is false, this will return true if the record ever existed before.

Step F: Provider - Return the protected content

Depending on the values returned in Step E, the provider can release its protected content and share it back with the user now safely, and get paid via the Coil extension as it would before.

Voila!

There's more information available on the GitHub Repos:

project-insulate / insulate-extension

Project Insulate Chrome Extension

Project Insulate aims to protect an API call used by a provider to send data when dependent on Web Monetization. Currently, the only way to fetch data is to keep the endpoint public if no paid-user login is present on the UI. Also, this project ensures no user PPI is shared with the provider to maintain the privacy component of the Web Monetization technology.

Follow project at: Web Monetization Community: Project Insulate

Published at Chrome Web Store

How does it work?

Case 1: Provider (any one providing data and trying to secure API call)

Firstly, you would need to register with Project Insulate using the instructions given in API README to get a clientId and clientSecret.

Once register, as you can see in the demo.html page, provider needs to add a meta tag with name as insulate-id and value being the clientId.

Everytime…

View on GitHub

project-insulate / insulate-api

This repository will serve as the backend for Grant for the Web (GftW) project: Project Insulate

Project Insulate API

Deployment

Heroku pipeline is set to auto deploy master branch currently.

Main functionality for Providers

Registration: This will return you client_id and client_secret

curl --request POST 'https://project-insulate.herokuapp.com/api/provider' \
    --data-urlencode 'email=hello@test.com'

Verify transaction: This will return you if the transaction was successfully added in last 5 minutes, if so, has it been used (by any previous verification call).

curl --request POST 'https://project-insulate.herokuapp.com/api/block/verify' \
--header 'Content-Type: application/json' \
--data-raw '{
    "paymentPointer": "$ilp.uphold.com/H3NqAwkm9g3W",
    "clientSecret": "10cc6c3ea96bb3ab525c61af71dfa1e58d11159cfd5de3d6",
    "transactionId": "c3798dce-4893-497e-8b80-f48a52896eda"
}'

API Documentation

Architectural Diagram

Current system…

View on GitHub

Feel free to ping me if you have any doubts or suggestions to make the documentation, code, or series overall better. Cheers!

How Does It Work?

Abhinav Chawla — Tue, 15 Dec 2020 17:46:01 +0000

FYI: This article is a bit heavy on the technical solution and architectural side explaining the inner workings of the solution 🤓 . I promise the next article would be more user friendly with a demo.

In this post, I would like to describe the architectural flow of the solution I came up with to resolve the problem discussed before.

The Base Setup

Let's start by looking at the flow chart below (higher quality available here):

I built a Chrome extension that will allow a Sign-in with Coil, providing Project Insulate the credential access without releasing any personal identification information (PII). It also creates a user on the Insulate platform using a custom identifiable token on Firebase and keeps the user logged in the extension. Also, the provider (the one providing exclusive data) can easily register with Insulate with an email address to receive a clientId and corresponding clientSecret.

The Main Flow

This section delves deeper into how Insulate helps a provider verify the open unprotected call. The short description would be:

When a user opens a webpage, the Insulate Chrome Extension will automatically update the Insulate backend which in turn will verify an active subscription on the Coil account at that very moment. When the webpage makes the open call to the provider's backend to fetch data, the provider can now check-in with the Insulate backend to verify whether to allow access to the user or not.

The image below (higher quality available here) shows the step-by-step calls made to achieve this.

Looking at the diagram, you will notice that the Insulate extension will look for two particular tags on every webpage: monetization and insulateId. The provider needs to add the clientId they received in the base setup step as the insulateId meta tag on their webpage. If both the meta tags are found, the extension automatically sends a request to the Insulate backend (protected by Firebase user credentials) which indeed verifies the subscription on the Coil account for the user.

If valid, it creates and stores a block by hashing paymentPointer (passed from the monetization meta tag), clientSecret (extracted using clientId) and a uniquely created transactionId. This transactionId is passed on to the Chrome extension which then forwards it to the webpage via insulateTransactionId event which can be fetched by the webpage as:

    window.addEventListener("message", function (event) {

        if (event.data.type && (event.data.type == "insulateTransactionId")) {
            let transactionId = event.data.text;
            insulateIdElement.textContent = transactionId;

            // *** TODO: Make call to backend (provider) and send transactionId *** 

        }
    }, false)

The provider can now use this transactionId to be sent to its backend, which in-turn can verify the validity of this transaction by passing in the transactionId, paymentPointer used on the webpage, and the clientSecret received in the base setup.

The Insulate backend will double-check by recreating the hash, and check if this block was created within the past 5 minutes. If so, it will return positively and mark the block used. If a second call is made within 5 minutes, it will let the provider know that the block exists but has already been used once.

Using this information, providers can be sure whether to provide the access to the exclusive content or not, while not requiring a user to sign in on their website and still being able to protect the data 💃 💃

I'll be posting a final post of the series in the coming days showcasing the project with a working demo.

So, Why Project Insulate?

Abhinav Chawla — Wed, 09 Dec 2020 18:55:23 +0000

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:

Log-in to the website: Well, the whole point of web monetization is to stray away from individual logins, and hence subscriptions.
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.