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 with #Gitcoin)
An Anti-Phishing phrase is a personal phrase that a user can set, which will only be loaded when they visit the authentic website.
For example, if the anti-phishing phrase I set for Binance.com was "ArugulaMonkey" when I visited the official Binance.com login page this phrase could be shown either in the URL bar, or injected into the webpage, depending on the design of the particular anti-phishing phrase system.
If however, I visited a phishing site, this anti-phishing phrase would be missing.
We want to add in support for anti-phishing phrases, where a user can set an anti-phishing phrase that is global, and has the option to create individual anti-phishing phrases for specific websites for sake of higher security.
**To claim this bounty from Gitcoin a contributor must:**
1. Create a proposed method for implementing anti-phishing phrases, complete with front-end design. Weigh the pros and cons of injecting the anti-phishing code into the websites layout (more obvious/secure, but more upkeep) vs displaying it in a drop down vs displaying it in the url bar similar to an SSL notice (less obvious, less upkeep). Or present another design choice, that is obvious and secure, but does not hinder user experience.
2. Build a well documented version of that system that can be merged into the main extension code without failing. It will at minimum need to have supported functionality passing in Chrome, Firefox and Safari.
3. Ensure that the anti-phishing phrases are stored locally for the user, are encrypted, are not readable by fake sites or malicious tools, and are not going to be deleted when users clear their browser.
4. Successfully pass a review by two main contributors to the project.
5. Successfully pass automated tests of scraped domains (correctly trigger the anti-phishing phrases on websites, and don't trigger them on fakes.)
6. Implement any refinements needed from the automated tests.
7. 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.
* Ideally, there will be no account system used. If storage beyond the local storage is required, we should consider allowing users to backup their configuration by storing a backup of their entire IronCoin config in a JSON format that can be locally downloaded or pushed to a cloud service like Dropbox or Google Drive. This should only be able to be exported if it is encrypted with a password hash. (Note this is all optional.)
* If you choose to inject into the web page of individual sites, we must consider attack vectors where bad actors could attempt to piggy-back on this functionality and inject malicious code. Examine how you will ensure other elements are unchanged, and clean any anti-phishing phrases from potentially malicious code.
* The users anti-phishing codes should not be stored in plain text and should not be accessible to anything/anyone except the IronCoin 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.