The increasing number of Phishing and Scam attempts against the Steem community made me decide to do something about it.
There are already, some attempts at preventing, and, this is what I propose, and will start working on.
This post is a proposal for creating the tooling and database required to protect both end-users and applications based on Steem.
1. Community-centric Database.
The first step will be the creation of a source of trust, a community driven database that could be used freely, by both end-users and application creators.
This database would record domains, applications and Steem accounts, into the following list groups:
1.1 Threat Groups.
The grouping of threads intention is to provide a verification source and prevent legitim applications and users from being wrongly included as threats.
1.1.1. Quarantine Group.
The quarantine group will be the main and entry place for new threats, any users will be able to submit a domain, a Steem account or an application into this group.
This group will serve as a yet not verified list.
Every report on the quarantine group will have a unique, sequential identifier (inspired by CVE) consiting of:
SG-TT-YY-00000
It means,
SG: SteemGuard Prefix.TT: One letter type of thread identification: so, for a phishing threat this part would bePHYY: A 2 digit identifier for the year the threat was reported, serving both age indication and allowing the sequential numbers to reset every 10 thousand times or every year, whichever comes first.
One example of threat identifier:
SG-PH-18-08345, which translates, reading on the inverse order to:
report 8345 made in 2018 about phishing, on SteemGuard
1.1.2. Confirmed Group.
After a threat is found and a given identifier is assigned, pre-approved verifiers, ideally (community voted software developers) will research into it and classify, as confirmed or not.
One report may be confirmed by multiple verifiers to allow a greater level of accuracy.
A verifier, acting in bad faith, will itself be included as a threat, this will assure the verifications quality itself.
1.2.3. Retired Group.
After an entry stops being a source of threat, for instance, the domain has been released and registered by another person or company, it's active report record may be moved into the retired group.
A removal may be done by a given requester, which information and justification for the removal, under a predetermined template.
It's up to the verifiers to remove it or not, and a given number of days and verifications of the threat neutrality will be required.
1.2. Community incentives for making it possible.
On the community side, since we are creating a solution into an incentive-based network, each contribution, being a new threat report or verification, will be done using a Steem post. which could lead both reporters and verifiers to get rewards for contributing to the network security.
Also, it would help prevent bad faith contributions, which are itself subject to downvoting by the community.
1.3. Database Structure.
The database itself will live on Steem blockchain, meaning each record must be previously included in a Steem post.
The raw machine data about the threat may get included in the comment_options operation of each report, preventing later change on an already approved contribution.
The database, extracted from the Steem blockchain and parsed, could be queried on the following structure by applications and integrations:
1.3.1. Report Lists
The three reports categories will be daily bundled into a machine format, for example, CSV and JSON records on a well know location, each one of the files generated having a master, publicly verified signatures to allow content verification.
Domains: A list of domains, and the respective identifier to additional information.
Accounts: A list of accounts, and the respective identifier for additional information.
Applications: A list of mobile applications, desktop applications and or browser extensions and the respective identifier for additional information.
Those lists would allow easy application integrations for offline and/or custom integrations.
2. Usage and Expected Results.
Since the community will provide its own truth on the security, here is a list of things that this database and reporting framework could empower:
- Browser Extensions:
Application developers could create browser extensions allowing alerts when a website, which is listed as a threat is being accessed.
For obvious reasons, one official browser extension provided by SteemGuard itself will be required and provided.
- Mobile & Websites:
Developers creating mobile frontend applications for users could embed and update the lists into their applications, blocking users and users, or displaying a warning about potentially dangerous links.
- Web Service:
Since those lists may grow really big with time, a web service could then be created for allowing queries against a given account / URL or extension name.
The official web service would sign responses with a common private key, meaning all applications using it could verify the responses and assure there was not intercepted.
- Safe Post:
Since frontends will have access to those lists, they could use the verifications mechanisms to completely hide posts and comments which mention unsafe links or applications. Also, they could rewrite the post at posting time. It's on the developer's discretion about what to do with the links. But one warning, you are leaving to a dangerous site would be a start.
- Account Trust:
This would also allow, for example, warnings if a given account is involved in a transaction at 
Disclaimer 1: This is a proposal draft and not so many technical aspects have been provided. As the community tips into this, I will update or make a new post with a greater level of details, and a building plan.
Disclaimer 2: Edits on this post, until the broader specification gets released will be posted on the bottom of the page, allowing those who already read the post, to catch up with updates until next release.
Update 1: 
bot name conflict.
As the time I've written this, I did not know there was a phishing-related bot called
Update 2: DNS & Steem.
One side of this would be allowing Steem based applications to whitelist the Steem accounts used by them:
Example1:
busy.orgpublished a_sg.busy.orgDNS TXT record consisting of a white space separed list of Steem accounts authorized by
_sg TXT TTL "busy busy.pay"
- Do confirm this information, the usernames
"json_metadata": {
"domains": "busy.org"
}