Complete: - Bounty #9 - Cover Browser Plugin

Cover Browser Extention - #9

Current Status: Discussion

  • Discussion (01/19/2021)
  • Ratification
  • Open for application
  • Assigned
  • In Review
  • Closed

Official Listing

Bounty Details

  • Bounty Amount: 50 ICP - 40 ICP Match Available
  • DFINITY Bounty Acclerator Grant Match Available: 40 ICP - (For every ICP sent to f2b488b80eb22bf57c1556683efcb51e090b46c181ca28e167e6f095223dfa3e, will add two more ICP to the bounty, up to 40 ICP, After 40 ICP, Donations to the above address will add .25 ICP to this issue and .75 ICP to fund other initiatives)
  • Project Type: Single Contributor
  • Opened: 01/25/2021
  • Time Commitment: Days
  • Project Type: Traditional
  • Experience Type: Intermediate - Web Dev; Intermediate - API Integration
  • Issue Type: Web Extension Development


This bounty gives the opportunity to

  • learn how Cover works
  • learn how the dfinity js agent works
  • learn how to create an extension that integrates with the IC
  • learn how to integrate with DAB

Cover(Docs) is an open internet service that can be used by developers to verify and prove that a canister’s code matches the open source code. Reducing the risk of malicious apps & increasing transparency and trust.

This integration would allow users to install a browser extension that will warn users if the deployed canister code does not match a known-good wasm hash.


The extension will need to identify IC network events, and capture the canister principal for each (see for a starting point on capturing IC network events.) This set of canisters will then be verified against the cover API.

  1. The extension should detect which canisters a site is communicating with.
  2. Each canister should be checked on Cover.
  3. If any issues are found, an alert should be shown indicating the agent is configured to communicate with an unknown wasm hash.

The status of each canister should be “Good to Go(Match)” - Green, “Warning(Unknown Canister)” - Yellow, "Exception(Hash doesn’t match) - Red. If the extention api allows for the changing of the color of the extension icon it would be nice to change that color. The alert should have a configurable sound warning that triggers if a RED is detected.

When the icon is clicked a box should show a list of canisters and their warning level as well as any info that can be retrieved from Cover and DAB if info is not available from cover.

To claim the award you must produce a web extension and submit it to the google web store that delivers the above functionality.

To apply for this bounty you should:

  • Include links to previous work writing tutorials and any other open-source contributions(ie. your github).
  • Include a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.
  • Give an estimated timeline on completing the task.
  • Post your application text to the Bounty Thread

Selection Process

The developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.


The bounty was generously funded by the ICDevs community and a DFINITY Foundation Accelerator of 40 more ICP. If you would like to turbocharge this bounty you can seed additional donations of ICP to f2b488b80eb22bf57c1556683efcb51e090b46c181ca28e167e6f095223dfa3e. ICDevs will match the bounty 2:1 for the first 20 ICP out of the DFINITY grant and then 0.25:1 after that. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to More information about how you can contribute can be found at our donations page.

General Bounty Process


The draft bounty is posted to the DFINITY developer’s forum for discussion


The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.


A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission


The award has be been given and the bounty is closed.


DFINITY Acclerator Grant: - 40 ICP

Other Bounties


Ready to apply for this task. Spent a couple of weeks to set up the required backbone of project.

My solution is supposed to have the following dependencies:

React app on Typescript, Vite as a build tool, @dfinity/agent,candid,principal to fetch data from Cover and DAB canisters. Redux store in a background script would serve as a state container between extension parts and is supposed to contain metadata collected from DAB and Cover.

Workflow of extension is supposed to be the following:

Extension retrieves effective canister ids from “:path” request headers. Then fetches metadata from Cover and DAB, stores it and then displays in devtools tab.

Important note is that browser extension is only capable to listen network requests at the time of existence of devtools tab. So the only way to catch canister requests is only by having a devtools tab open. So most of the time of UX would be spend of working on Devtool tab of extension.

Currently I have set a couple of jest tests for parsing network requests and fetching data from Cover and DAB. Most likely improvements with cover integration would be needed as Cover team is changing api and pushing projects’ integrations to it.

About me.
I have not yet developed much applications in web3 and on IC, however I spent some time reading the docs and walked through motoko examples and specifications while preparing project build up for this application.

My experience.
I have contributed to quite a large life science project called ACUITY as a part of my full time job. In the beginning of the year we released it to open source.
Home · digital-ECMT/acuity-docker Wiki · GitHub. My role was to prepare an app for open source release, automate cloud deployment and fix some security and workflow issues on back and front ends. I am coming from Java back end development and learn web3 as a hobby.

Ready to demonstate what i’ve build so far if it is necessary. Estimated time to complete the code and documentation is approximately 2 months


Hey @jorgenbuilder any thoughts on ways around this limitation? If the user has to open devtools a lot of the plugin helpfulness goes away.

Indeed that’s troublesome and difficult to see a way around a significant reduction in quality of user experience.

Relying on devtools I don’t think is an option, as the target audience is the general consumer. Maybe there’s a way to piece together a reasonable user experience involving devtools, but I am skeptical.

Perhaps a registry could be created of which domains call which canisters that the extension could query? :thinking:

That is basically DAB isn’t it? The plug plugin seems to know what canisters are about to be called when you connect to a website. Perhaps this needs to query DAB as well.

After a couple of experiments finally I succeeded and found out that this could be done with the help of webRequest API and it would be compatible with manifest v3 (which was main pain during my investigation). Web requests can be intercepted in service worker scripts , extracted from headers, stored. After that we could check them by DAB and Cover and display on popup, when extension popup shows discovered canisters’ ids. Is it a desired workflow? Would we like to see canisters info on popup or might it be a separate options tab?


I will move this bounty to assigned for you. Looks like you have a good plan for execution! Please post here if you need any help from the community.

1 Like

Should I move it open source as soon as possible or share repository with someone and make public on final stage?

The sooner the better as you’ll get some good feedback and it will be easier for others to comment/help out.

1 Like

For now i have started to work on front end part (design is the most challenging part for me). I guess that i would make everything open source in the end of this or next week after making everything clean and completing main logic.

1 Like

All right. Now extension is public. GitHub - DunkanMcLoud/can-check
It is in its working state now, some extra work need to be done, i guess (docs, GitHub actions workflows, and chrome web store upload and corresponding verification)

UPD. Some updates would be needed to satisfy bounty requirements (color alerts)

1 Like

I have met an obstacle implementing comparison of canister wasm_hash and COVER response . To get a wasm hash I use the following

export const getCanisterModuleHash = async (canisterId: string) => {
  const canisterPrincipal: Principal = Principal.fromText(canisterId)
  const path = [
  const res = await agent.readState(canisterId, {paths: [path]})
  const cert = new Certificate(res, agent);
  await cert.verify();
  const module_hash = await cert.lookup(path)
  return module_hash.toString("hex")

However this code is not working for my browser extension with the console error :

CompileError: WebAssembly.instantiate(): Wasm code generation disallowed by embedder

I have found the corresponding discussion for this case and found out that it’s due to current in-browser restriction for extensions of manifest v3. Downgrading to manifest v2 is impossible due to chrome extension store policy.
Is there any workaround to get wasm hash for canister using agent-js or http requests?

If not, I will not be able to implement comparison between Cover response and dfx canister info wasm hashes before Chrome developers enable wasm execution for extensions of manifest V3

1 Like

Well, I have committed extra updates which are supposed to satisfy current requirements.

The previous question is still valid. For now extension alerts if some canisters for dApp are missing Cover data.

Another obstacle I have is uploading extension to Chrome Web Store. To create an account I need to pay a bill - doing this recently became a huge trouble in country I live in. I will take a look at workarounds for this, but is it possible to upload it to web store by someone who has access to it?

For now i will fill the wiki for extension

Let me get back home from travel next week and ICDevs can cover the bill(I hope…how much is it?)

@skilesare The problem is not in the bill itself, it is small (5$), it is affordable. The problem is that i have no chance to pay it, because Visa and Mastercard has disabled cards in country i live in. So i have no chance to create an account because i can not execute this payment. So I am asking is there an option to upload this extension to Chrome Web Store by some DAO members who already have an account in Chrome Web Store? Or should I upload this extension to store and is this a critical part to complete a task?

We will set up an ICDevs account and I can up load it.

Great. I’ve added documentation to repository. Development is complete. I am waiting for your feedback about further steps required from my side. For now i will be around to make some minor bugfixes if find any.

Development complete
Please refer to the following repository

1 Like

Hey… @DunkanMcLoud a couple of changes:

I had to add to the manifest:
“name”: “Can-Check”,
“version”: “0.0.1”,

we need an icon. the 128 one in the repo isn’t working Supplying Images - Chrome Developers

I also need one screenshot

Hi @skilesare , thank you
I have improved manifest and 128 icon as you mentioned.
Left a bundled zip Release Verion 0.0.1 · IT-Union-DAO/can-check · GitHub
Is this screenshot is enough for you?
can-check/description.png at master · IT-Union-DAO/can-check · GitHub