-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve designs for dynamic lookup the source of a block #56
Comments
That works for me. We can have a static line with all the lists we are consuming with a link to each repo. When the user wants to [Report a detection problem], we open an issue in the blaming repo. What should we do if more than one list reports the same domain? Should we use our lists as the first option? Is this a blocker for the new phishing warning page @Gudahtt? |
Nope! But it's a blocker to us adopting the new phishing controller update, which is also urgent. My plan was to get something working for this quickly, then revisit to improve it as necessary.
Good question. I wasn't sure about this either. Defaulting to us makes sense for now, but it'd be nice to show all lists that block the site instead. |
Sounds good. Should we have #52 merged first? So we also unblock PS on this.
We can do a |
That prototype looks great! We'll need some sort of loading indicator for after the user clicks "Details" as well. I'll ask in Slack about which to use. |
The initial implementation of this was in #57 with minimal design changes. I will work on the design changes next, leaving this issue open until they are completed. |
Due to a recent change in how we are distributing our phishing configuration, we will no longer have access to the source of a block by the time this page is rendered. That is, we won't know whether the site was blocked by our configuration, or by the Phishfort configuration.
We can workaround this problem by dynamically looking up all sets of phishing configuration MetaMask is currently expected to be using, and comparing the blocked site with each one. However this operation would take a few seconds and it might incur substantial hosting costs, so we should not wait on this during the initial page load.
My suggestion would be to lookup this information after the user has clicked the "dispute block" button, so that we route them to the correct page for disputing that block. Alternatively, we could also perform this dynamic lookup when the user clicks "See more information" or something like that.
The text was updated successfully, but these errors were encountered: