[FEATURE] Mechanism for prevent spam gov

[vuong177]

Problem definition
Currently, we have many spam/scam gov proposals. We should have a mechanism to prevent those.

Feature specification
Add initial deposit requirement for proposals, when the user wants to submit a proposal, they need to deposit a part of the government-required deposit.

Acceptance Criteria

• Proposal passed governance
• Solution implemented

Additional context

• Determine minimum deposit to charge users for submitting a deposit proposal.
• Create proposal for governance - set fee to prevent spam. (Ed)

[ZaradarBH]

It might be worth looking into adding CSRF & XSS "safe-html encoding" protection to the system processing the contents of gov proposals to try to block some of the phising attacks aimed at our users? :)

[lunc808]

Hi since this is something I'd been thinking about here is a medium article to outline a possibility.
https://medium.com/@lunc808.eth/utilize-scam-proposals-on-terra-station-for-terra-luna-classic-v2-845eee1676b0

[LuncBurner]

Formatting updated and acceptance criteria added.

[fragwuerdig]

So I and @edk208 looked it up. A minimum initial deposit for gov props is available in Cosmos SDK since v0.47. So if we don't update the SDK to that version in the mid-term, then we would have to backport it to get it...

[letorbi]

Hi,

I hope this is the right place to ask, but wouldn't it be also helpful to enhance the matching pattern for external links in a gov proposal to match any string that would be recognized as an URL by a common browser?

I did a fast check and it seems that any string that consists of "the usual letters" (a-z, umlauts, accents etc.) and dots, followed by a valid TLD, is considered a domain name. Thus any such string, maybe followed by a / and even more chars, is considered an URL that should be opened directly.

Right now scam proposals with "links" to malicious sites like "www.v2Terra.de" still show up regularly. I think enhancing the matching pattern for external links could stop those, since the scammers would not have an easy way to point inexperienced users to their websites anymore.

Regards,
Torben

[esoderquist]

@letorbi, I have a pending PR with TFL station (stationmoney/station#159) that attempts to expand the regex used for detecting URL patterns initially established by the implementation of governance prop 7101. Part of the challenge here is dealing with obfuscated URL patterns as well (www. v2terra. de) with spaces, etc. while not overmatching (e.g. something like "LUNC is great. Be sure to participate!", where "great. be" might considered a "valid" domain obfuscated by whitespace. If we omit obfuscation, the regex simplifies, but the risk is that we end up with a similar volume of spam props with newly-obfuscated URL patterns. Arguably, most modern browsers won't accept URLs with whitespaces, so perhaps the obfuscation approach would be a zero-sum game to those attempting to put forward spam proposals and we would see a natural attrition of these spam props given the lack of economic viability.

Furthermore, Interchain station has not currently adopted the URL obfuscation changes in 7101, but I'll be keeping an eye on how that develops with the pending PR and see if another PR might be warranted.

At the L1 level, URL regex detection might be possible, but great care is warranted to not overmatch.

[letorbi]

The Terra Station repo is indeed the better place to ask ;) However, it is great to see that a PR regarding my idea already exists. I'll write there, if I have any suggestions regarding the regex or anything else. Thanks for your work, I hope it gets merged.

[esoderquist]

Not directly L1 related, but stationmoney/station#202 has been submitted to Station to improve end-user education around mnemonic security and (hopefully) limit the effectiveness of external URL links in gov proposals for spam purposes.

[ZaradarBH]

This issue has been rescoped to only focus on the proposal itself, the POC work has been moved here: #41

[ZaradarBH]

@fragwuerdig told me Classy has already authored the propsal. So there is really no reason for us to do more on this subject. Will close this issue as the remaining work is done in #41