Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for 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.
We are proud to announce that we have teamed up with Chainlink to launch a new bug bounty program to secure the Chainlink protocol. Chainlink is the …
In partnership with Protocol Labs, we’re excited to welcome builders from everywhere to APOLLO, your mission control to engage with the builder…
Gitcoin is GDPR compliant. 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 with #GitCoin)
We'll need to create an automated scoring and classification system that looks at domains that are not currently in the database and predict how likely they are to be an issue.
Consider some of the work by Blurbesec of the EtherScamDB: https://github.com/blurpesec/categorizer/blob/master/categorize.js
Categorization is done by phrase distance and commonality with other scams.
In order to earn this GitCoin bounty a developer must:
1. Create a proposed system with a framework for classification and scoring. They should be able to explain the logic behind the scoring.
2. Build a well documented version of that system that can be merged into the main extension code without failing. When showing that a site was blocked we must note it was an automated rule, show a score out of 100% and explain which likely reasons caused this site to be blocked.
3. Successfully pass a review by two main contributors to the project.
4. Successfully pass automated tests of scraped domains (not blocking obvious acceptable sites like Netflix.com, and blocking obvious scams)
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.