xxB-2024-003: Haven Browser Extension Implementation

Grants and Bounties
1

Bounty xxB-2024-003: Haven Browser Extension Implementation

Overview

This bounty rewards developers for implementing a secure browser extension for Haven that moves sensitive data storage (including user identity secrets) out of localStorage into a more secure extension-based storage system. The implementation will modify existing Go libraries and create browser extensions for Firefox and Chrome.

Prize Pool

Total Prize: 1,250,000 xx (~$62,500 USD)

Breakdown:

  • Milestone 1 - Go Library Modifications: 300,000 xx
    • Must be completed before subsequent milestones
  • Milestone 2 - Extension Interface Design: 200,000 xx
  • Milestone 3 - Extension Implementation: 300,000 xx
  • Milestone 4 - Haven Integration: 250,000 xx
  • Milestone 5 - Store Publication: 200,000 xx

Requirements

Eligibility

  • Participants must complete KYC verification
  • Participants from OFAC-sanctioned countries are not eligible
  • Multiple contributors may collaborate on submissions
  • Existing xx network contractors are eligible, but must recuse themselves on bounty related decision making if they decide to participate.

Technical Requirements

  1. Milestone 1 - Go Library Modifications
  • Extend xxdk-wasm library to support external KV stores
  • Implement KV interface defined in collective/versioned/kv.go
  • Add functions to pass in KV interface supporting objects
  • Maintain compatibility with existing localStorage implementation
  • Complete documentation and test coverage
  1. Milestone 2 - Extension Interface Design
  • Research existing extension architectures (e.g., polkadotjs-extension)
  • Define interface requirements for KV storage
  • Document security considerations
  • Create detailed technical specification
  • Design extension architecture
  • Define communication protocols
  1. Milestone 3 - Extension Implementation
  • Implement extension for both Firefox and Chrome
  • Secure storage implementation
  • Background script functionality
  • Content script integration
  • Message passing system
  • Error handling
  • Security hardening
  • Cross-browser compatibility
  1. Milestone 4 - Haven Integration
  • Proof of concept integration with Haven
  • Migration system from localStorage
  • Fallback mechanism
  • Performance optimization
  • User experience improvements
  • Integration testing
  • Security audit
  1. Milestone 5 - Store Publication
  • Extension packaging
  • Store listing preparation
  • Documentation for users
  • Marketing materials
  • Support documentation
  • Publication to Chrome Web Store
  • Publication to Firefox Add-ons
  • Maintenance plan

Implementation Requirements

  1. Technology Stack:
  • Go programming language
  • xxDK and xxdk-wasm libraries
  • Browser Extension APIs
  • WebAssembly
  • Modern JavaScript (ES6+)
  1. Security Requirements:
  • Secure storage of sensitive data
  • Protection against XSS attacks
  • Protection against extension tampering
  • Secure communication channels
  • Data encryption at rest
  • Access control mechanisms

Submission Requirements

  1. Source code must be:
  • Open source (same license as xxDK)
  • Submitted via merge request to appropriate repository
  • Well-documented
  • Passing all tests
  • Following project coding standards
  • Security audited
  1. Documentation must include:
  • Technical specification
  • Security analysis
  • API reference
  • Integration guide
  • User guide
  • Development guide
  • Build/installation instructions

Judging Criteria

Submissions will be evaluated on:

  1. Completeness of implementation
  2. Security considerations and implementation
  3. Code quality and maintainability
  4. Documentation quality
  5. Test coverage
  6. Performance
  7. User experience
  8. Cross-browser compatibility

Timeline

  • Submissions accepted until completed or program ends
  • Reviews will occur within 2 weeks of submission
  • Prizes paid within 30 days of approval

Payment Terms

  • Prizes paid in XX tokens
  • Multiple submissions may split prize pool
  • Major awards (>50,000 XX) subject to 6-12 month linear vesting
  • All payments subject to KYC approval
  • Partial payments may be made at discretion
  • Payments may be locked in a linear vesting schedule for up to 1 year

Contact

Submit questions and proposals through:

  • Repository issues
  • Developer forum
  • Developer chat channels

Please respond in the forum if you are pursuing this bounty.

Legal

  • xx network reserves right to modify bounty terms
  • All submissions must comply with applicable laws
  • Participants retain rights to submitted code under project license
  • xx network not responsible for lost or invalid submissions
2 Likes
3

Good afternoon to all of you reading and following this topic,

My name is Michiel, I am working together with Om regarding solving this bounty. Since December, I’ve been in touch with @rick & @Robbie to scope the work on this bounty.

We’d propose to move forward with the following core design:

  • Secure Storage Extension expose APIs to haven
  • Haven wraps this API into the KV interface and passes it to xxdk-wasm

We’d like to express our commitment to initiating this bounty, although we would like to propose/confirm a few details from our end;

  1. As discussed with @rick the implementation will be on Chrome.

  2. The core focus will be on the technical implementation, any other points are secondary. (Such as marketing materials, extensive user documentation, etc.).

Payment plan we’d bring forward:

Total reward 62 500 USD, in xx tokens, splitter into the milestones defined below of which 40% of each milestone is to be paid on delivery, and the remaining 60% is on a 3-month vesting schedule.

Milestone submission post is seen as the calculation date, and as such, will also count to calculate the 2-week moving average price of USD to xx tokens.

Milestone breakdown:

  • Milestone 1 - 15 000 USD
  • Milestone 2 - 10 000 USD
  • Milestone 3 - 15 000 USD
  • Milestone 4 - 12 500 USD
  • Milestone 5 - 10 000USD

Milestone change as discussed:

Milestone 1 API Design & Justification
Milestone 2 Go Library Modifications & remaining extension design

Background on myself & Teri:

mf: https://michiel.degruytere.com/
Om: https://ommore.xyz/
(More links are restricted due to forum policy; all 3rd party social links can be found on our websites)

Excited to hear back from xx, and open for discussion!

Talk soon,

Mf

Post renewed due to changes as discussed with xx

1 Like
4

Hi Mf –

The curator proposal has passed, you’re good to start work on these.

Quoting the pertinent terms here for documentation reasons:

Milestone submission post is seen as the calculation date, and as such, will also count to calculate the 2-week moving average price of USD to xx tokens.

Milestone breakdown:

  • Milestone 1 - 15 000 USD
  • Milestone 2 - 10 000 USD
  • Milestone 3 - 15 000 USD
  • Milestone 4 - 12 500 USD
  • Milestone 5 - 10 000USD

Milestone change as discussed:

Milestone 1 API Design & Justification
Milestone 2 Go Library Modifications & remaining extension design

2 Likes
5

Good evening to all of you,

We want to present the completion of our initial bounty, the API Design. I’m also glad to share some initial work that we have been doing that led to an MVP regarding our testing out the API design.

As attached, there are 2 PDFs, the initial one named API Design, representing the technical details, and the 2nd one named Flow, representing a high-level overview.

xxnetwork - API.pdf (72.5 KB)
xxnetwork - Flow.pdf (39.6 KB)

To see our MVP in working, I’d like to share this video to be previewed on this link.
The GitHub repo can be found here (link)

I’d like to share the following considerations we have made while designing this:

  • We intend to apply DomPurify, a HTML/JS cleaner that will significantly reduce a potential XSS attack.

  • We looked into encrypting the data within a 3rd party storage system (cloud-based) however as our research showed, extensions are sufficiently isolated from the browser to not bear a significant risk that would need an additional encrypted storage. (ref: Content scripts  |  Chrome Extensions  |  Chrome for Developers)

  • We are pursuing the following general logic for next steps and implementation:

    • The web app directly pushes data to the extension, as there wont be any need for holding authentication values in local storage. If there is no extension, it will create the local storage (xx network side will adjust the part of the web app, and local storage as discussed with @rick )

  • As the data is going to be pushed straight from the web application to the extension through the Chrome API, there won’t be any additional need for encryption in the transportation system.

  • We researched and tested a potential synchronous IndexDB implementation (on request of @rick), although we deemed it as not feasible within the existing bounty implementation. However, this is feasible and we do so it is possible for a secondary bounty by a 3rd party.

Our next steps will be to work on the GO Library modifications and continue our MVP into the next stage, alongside the remaining extension design.

We would like to invite any xx.network or interested parties to share with us their questions or criticism, as this stage is very favourable before the implementation of our created design/architecture.

Thank you, and talk soon.

If you’d like to refrain from downloading any documents, I have taken the liberty to upload all files in this Proton Drive

1 Like
6

Great demo.

Now that I see it, it looks like the main hook is to modify wasm-utils which I hadn’t realized:

I’ll prompt folks to unlock the curator today. One thing that would be helpful is code examples of the intended ways to use the extension, among other standard README items, but not required at this stage. Everything looks sound.

2 Likes
7

We set the wrong beneficiary, will send funds back to XXB-2024-003-CURATOR when they unlock which will then redirect them to you.

1 Like
8

Payouts for Milestone 1:

1 Like
9

XX.network Secure Storage Milestone Update

Good afternoon everyone,

I’m happy to announce our next milestone accomplishment, which brings us another step closer to producing the secure storage extension.

In this milestone, we accomplished, as previously agreed, these feats:

Introduction behind

the code:

The current external storage file will make the local storage file obsolete. If no external storage is available, it will use local storage. If external storage is available (extension), it will push the information inside the extension and make it usable for it.

These updates will allow us to capture the data with the extension and keep the keys safe in its external storage. It should also allow third parties to utilise this external storage to allow them to add their own extension.

  • Important
    These changes cannot be merged yet. As discussed in the previous milestone, if the extension exists, a haven-side detection function will be required (to push local or external storage) alongside our updated implementation of the extension itself (which will happen in the upcoming milestones).

the design

The design as seen here implements a modern but simple UI/UX for the user to utilise the application. It integrates the colours of xx.network alongside various opacity to allow for contrast. The UX has been designed to remain simple as a core feature. It includes an error log screen for future maintainability and options to export/import their KV. We believe it’s essential for peers to stay in control of their own keys.

What’s next

Next steps include:

  • Implementing the design with the MVP
  • Update MVP code with new UX flow
  • Test and update MVP
  • Update error handling with a basic log system

After that milestone, we’re reaching the last parts, and there we shall:

  • integrate extension with Haven & node keys
  • performance and testing coverage
  • Store list packaging & preparation
  • Publishment

I am eager to hear your review; changes in design are welcomed.

2 Likes
10

I merged the wasm-utils changes.

What would your opinion be on merging that into client directly? I’m thinking it may make sense to merge all of the client repositories and some of the dependencies.

I reviewed the rest of the changes, they all look good and meet the agreed upon milestone 2 design reqs in my book.

Excited to start using your extension!

11

Milestone 2 Payouts:

https://explorer.xx.network/extrinsics/17327284-1

https://explorer.xx.network/extrinsics/17327315-1

1 Like
12

Good afternoon to all of you reading and following this topic,

We’ve accomplished milestone #3 , implementing the extension for Chrome, alongside the secure storage implementation, content script integration, error handling, and the other relevant milestones for this feat.

I am required to make you aware that we needed to change the design for security reasons. At the end of the post is a further explanation written alongside a little bit of knowledge on extension security.

The new design, alongside a demo video of the application, ready for integration, can be seen here (click to view)

The current application can import, store, export, and clear KV values into the extension storage.
Our core test has been successful in terms of practical implementation:

  1. Export Haven’s browser local storage,
  2. Import into extension storage,
  3. Export out of extension storage,
  4. Reimport the same file into a new (cleared) browser
  5. Access the same user account to access Haven.

This implementation utilises the isolated extension storage as mentioned before, has been documented in the code, alongside a how-to-use readme.md on GitHub. Within our repo you can also have a look at the message passing system & our content integration here

Security made us change UI

As you saw in our demo before, we initially created a different UI alongside the rounded corners, and following the soft linear gradient in light blue. When we finished (click to see), we reviewed our codebase and realised a few issues to achieve this design;

  • Rounded corners within extension design require DOM manipulation, affecting potential security vectors by requiring DOM permissions. However, there are methods to bypass this with the shadow-dom element (click to read more).
    – Code Example
    – Deeper explanation (Video)
  • To maintain a secure and efficient maintainability, complexity is rather to be avoided. Utilising Shadow Dom, alongside having a huge (1500+ lines) service-worker.ts, added additional avoidable complexities, both for maintaining and securing the extension.

Solution

A completely redesigned UI, utilising square corners, but with a gentle mystical background to keep the design exciting.

Rebuild using Svelte, and utilising best maintainability standards to improve further future off-handing and on-handing while avoiding touching upon the DOM.

Up next
A few final tasks remain for us to launch the extension, and these are outlined in the upcoming milestones 4 and 5.

Major updates will be the integration with Haven, and after that, the upload to the Chrome extension browser.

Feel free to provide feedback, criticism, or requests for changes that involve the new design.

-Mf & Mo

2 Likes
13

Great work, and thoughtful. Thank you for that update!