RE: Fighting phishing on Hive - 2 solutions to better deal with phishing on Hive. Your feedback is needed.

Thanks for giving this important issue a thought, Louis!

• I already offered a solution that should quickly mitigate this issue: my universal script for hive frontends. It just needs a bit more work to use multiple banlists (easy) and to allow frontends to let their users remove one/all banlists so that they still have a choice (easy).
  The same applies for phished users, as mentioned in my “universal script” post, I was already planning on allowing all hive frontends to block all links from users added to the phished accounts list or at least display a prompt/confirmation/warning).

• I think that the problem we currently have is that phished accounts are not added quickly enough to spaminator (if they were, any comment of theirs would already get my dedicated auto-reply). Only one/two people have access to those blacklists. I was offered access but replied that I prefer having my own in order to improve decentralization and allow adoption/acceptance of my solution.
  I was also thinking that I should start supporting a "!hacked" command (and its related list) to let trusted users put accounts into my own phished accounts list (and a "!recovered "command to remove them if necessary - important too for recoveries).

• Phishing campaigns quite often are detected early by my bot (happened at least 3 times in the past couple months).
  (Furthermore for this attacker I now have in place a way to detect waves even earlier. PS. this was effective in preventing last night's wave as soon as it started!)
  What sometimes happen is that the attacker tests an automated comment on a previously phished user and that triggers an early notification into my discord server. In order to have someone react in a timely matter, more trusted users should be in my discord or more discord servers owners should allow my bot to post warnings in a dedicated channel in their discord server. In this way, the reputation of irremediably lost accounts controlled by the attacker could be nuked early so that all their messages would get hidden by default.

• blacklisting users: I could automate adding to my mute list any new user added to @spaminator’s list, if that helps. Maybe the !hacked command is a better approach though - my bot already replies to any comment (with at least one link) left by a user marked as hacked in @guiltyparties’s GitHub. I do not think that the approach you suggested is good enough because the attacker switches to a new phished account as soon as they notice it’s being counteracted. That still happens during phishing waves even though filling their database with fake credentials using a script (like I do during every wave) seems to slow them down a lot. Blacklisted users then also need to be removed if they recover. IMO blacklisting phishing domains is more effective (and that’s why I started with that in my universal script for hive frontends - unfortunately only adopted by 5 frontends so far..).

• I already have on my backlog to start supporting “!scam” commands -> my universal script for hive frontends will show an alert saying “the Hive community classified this link as SCAM, are you sure you want to proceed??” (works in any Hive frontend, it’s just a prompt() command supported in every browser).

• ( we should train new users with simple rules: never ever use your master key on a new website you just found out about. Leave your funds either powered up or in savings.)

• “I want the mute list to expand automatically as soon as someone new falls for the phishing crap” - the issue is that if the account is then recovered it requires a manual removal. I think that at the moment only fully lost accounts indeed end up on @spaminator’s hacked accounts list and that makes my auto-replies less effective for that scenario.

• Suggested solution 1 - “ give an account the Posting Permission or Active Permission to manage my community's mute list from the outside” - this could work and additions to each community mute list could be automated as soon as a new phishing link is detected by @k.d., but every existing and future community would have to do it and that's not guaranteed to happen, leaving some users still unprotected. +

• Suggested solution 2 - all community leaders would have to do it (and maybe some changes are required by the core dev team too?) so same, it may not be effective.
  --> Blocking all known phishing domains in all frontends (including Hive chat) with my universal script is more feasible and effective IMO.