Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
(Issue Funded by #GitCoin)
We want to maintain a list of high priority sites (primarily crypto exchanges, wallets, and other important services) where we have a low tolerance for security changes.
One such change will be their host.
For a top list of sites, we should identify acceptable IP addresses (ideally main static ones), and any other information about the hosting environment that can be validated programmatically. This discover can happen server side and be published to a file in the repo for the client to read from.
In the event of a variation from that file, we should warn the user that there has been a change and we are still trying to validate the change.
**To claim this GitCoin bounty a contributor must:**
1. Create a proposed system with a framework for recording host information about a list of top crypto sites.
2. Build a well documented version of that system that can be merged into the main extension code without failing.
3. Successfully pass a review by two main contributors to the project.
4. Successfully pass automated tests of scraped domains.
5. Implement any refinements needed from the automated tests.
6. Be fully implemented into the new code with documentation for future maintainers.
If at any time the contributing developer cannot pass a stage of the review and integration process then a partial bounty or no bounty will be paid out.
**Other important considerations:**
* The implementation methods chosen should be ones that will work with the extension APIs in Chrome (and Chromium based browsers), as well as Firefox and Safari. Extra consideration will be given if the methods work in other browser environments, but, support for Chrome, Firefox and Safari is the minimum requirement.
_Client Side Security:_
* As a security extension, we should maintain as much of the code as possible on the client side of the extension. In order to justify server side communication the protection to the user should be demonstrably greater by an order of magnitude, or impossible to be done in a client side environment.
* If extensive scanning, or record keeping of domains is required, we should implement a light system within the extension client side. Then we should create a scanning server that does **not** directly communicate with clients. That scanning server could scan lists of domains gathered from top sites, and various crypto communities and update a database list within the extension.
* As we are dealing with a users ability to load a page, we must prioritize speed. Our internal guidelines are any process should aim to add less than 0.10 seconds to the average load time, or no greater than 10% additional load time to the average page (which ever is the greater). For each additional 0.10 seconds or 10% of load time, we must be increasing protection in some KPI by a measurable increase greater than one order of magnitude.
* There are multiple checks taking place within the extension. No new system implemented should directly conflict with those checks (i.e. no new system should automatically whitelist something that a check has already blocked, or no new system should ignore a whitelist.) Any implementations related to this issue must consider existing systems. Ideally, existing systems can be updated to include support for the automated scoring rules added in this issue.
* All implemented systems must respect the user whitelist and not override them, unless there has been a clear change since the whitelisting. Acceptable edge cases may be things like the site is hosted on a new IP address, and the SSL is invalid.