On your side from what I understand Seems as simple as muting that account with an account setup specifically to identify phishing. Then a UI implementing some features for that (maybe some of what you have created not sure)
But holding of this information and referencing by the platforms is what I'm looking at... with mute lists seems so easy.
Create an account phishing.defense add a description to the account that UIs could also use and users could understand and then just mute all the users in your list. Doesn't need some new random centralized api. It comes with all the features we know how to use on hive. We can view all this stuff easily.
Or maybe I'm missing something regarding what you're doing.
users could understand and then just mute all the users in your list
I am not very familiar with mute lists yet so I'll need to read some docs. I think that the only problem with mute lists is that when phished users re-gain access to their account they would still be muted. So that would require some manual steps to blacklist/whitelist users all the time. Doable but I'm wondering if it's the right approach and effective enough.
The whole point of this first version of my script is not about preventing a single user spamming phishing links. It would not be effective focusing on preventing that because usually the attacker has many accounts, can create more or use the newly phished accounts to keep spamming more phishing comments. I think what's more effective is blocking the known phishing domain itself.
Definitively centralization is a concern, as stated the post. We should have redundancy in place. As per comment above I think I will also host a copy of the blacklist myself and add some automation to it to allow trusted users (witnesses) to add new phishing domains to the list.
This is also what I am in favor of @jarvie . . in fact, we are scheduled to release @blocktrades' Decentralized Blacklists / Mutelists solution on https://d.buzz this Tuesday.
Red lining suspected phishing domains is also a decent idea, but it should be opt-in @keys-defender, and there should be more than one list of suspected phishing domains, and it should be handled by more than one person / groups of people.
Opt-in + Multiple Choices, decreases centralization and in the end, censorship.
I’m not part of the spaminator team and I’ll start offering my own known phishing domains list with some automation in place to allow trusted members of the community to automatically add new domains to the blacklist
And yes, we agree but it’s up to the frontends to let users choose which blacklist (if any) to use. IMO at least one should be ON by deafault though in order to protect them.
Yeah, you're right, there should be a default blacklist with an opt-out option though.
If you create a Blacklist / Mutelist like @jarvie mentioned, I can consider using it for D.Buzz
I want there to be a tool where any user can create a list of domains that would be lined out in red, and that their list could be followed by any other user.
#3 would decentralize the service you are offering.
You replied to your own comment instead of on @keys-defender's comment. 🤨 Therefore, they would not receive a notification. 😒 Anyway, this comment is enough for them to get notified of your comment. 🤨🤨
1 - we already have 3 phishing domains blacklists available. When I have time I'll release a new version of this script that uses them all, including the phishing links reported by the community (see my latest post). It will be up to the frontends to offer a way to let the user choose which one to use or to opt-out. My code will make the integration simple.
2 - blacklists and mutelists are to mute users and that's not effective because phishers keep rotating new accounts in their attacks.
3 - that seems like a feature for the core dev team.
@asgarth or @blocktrades may have a link to that specifically.
On your side from what I understand Seems as simple as muting that account with an account setup specifically to identify phishing. Then a UI implementing some features for that (maybe some of what you have created not sure)
But holding of this information and referencing by the platforms is what I'm looking at... with mute lists seems so easy.
Create an account phishing.defense add a description to the account that UIs could also use and users could understand and then just mute all the users in your list. Doesn't need some new random centralized api. It comes with all the features we know how to use on hive. We can view all this stuff easily.
Or maybe I'm missing something regarding what you're doing.
I am not very familiar with mute lists yet so I'll need to read some docs. I think that the only problem with mute lists is that when phished users re-gain access to their account they would still be muted. So that would require some manual steps to blacklist/whitelist users all the time. Doable but I'm wondering if it's the right approach and effective enough.
The whole point of this first version of my script is not about preventing a single user spamming phishing links. It would not be effective focusing on preventing that because usually the attacker has many accounts, can create more or use the newly phished accounts to keep spamming more phishing comments. I think what's more effective is blocking the known phishing domain itself.
Definitively centralization is a concern, as stated the post. We should have redundancy in place. As per comment above I think I will also host a copy of the blacklist myself and add some automation to it to allow trusted users (witnesses) to add new phishing domains to the list.
This is also what I am in favor of @jarvie . . in fact, we are scheduled to release @blocktrades' Decentralized Blacklists / Mutelists solution on https://d.buzz this Tuesday.
Opt-in + Multiple Choices, decreases centralization and in the end, censorship.
Exactly what I stated in my post.
And yes, we agree but it’s up to the frontends to let users choose which blacklist (if any) to use. IMO at least one should be ON by deafault though in order to protect them.
Yeah, you're right, there should be a default blacklist with an opt-out option though.
If you create a Blacklist / Mutelist like @jarvie mentioned, I can consider using it for D.Buzz
I want there to be a tool where any user can create a list of domains that would be lined out in red, and that their list could be followed by any other user.
#3 would decentralize the service you are offering.
You replied to your own comment instead of on @keys-defender's comment. 🤨 Therefore, they would not receive a notification. 😒 Anyway, this comment is enough for them to get notified of your comment. 🤨🤨
1 - we already have 3 phishing domains blacklists available. When I have time I'll release a new version of this script that uses them all, including the phishing links reported by the community (see my latest post). It will be up to the frontends to offer a way to let the user choose which one to use or to opt-out. My code will make the integration simple.
2 - blacklists and mutelists are to mute users and that's not effective because phishers keep rotating new accounts in their attacks.
3 - that seems like a feature for the core dev team.
@chrisrice is not notified of your comment, since you have neither replied directly to him nor tagged him. 😐
Yeah, I'll pull the phishing api from.your blog and will probably impliment it in April.
I don't disagree with everything you do and say, just the way you communicate with users, which was likely.adopted from HW's culture.
Posted via D.Buzz
It looks like @dbuzz can rest from marking posts with phishing links as blatant scam on D.Buzz. 🤔