-
Notifications
You must be signed in to change notification settings - Fork 86
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
BSIP: Proposals Scam Prevention #154
Comments
The whitelist idea is a great idea imho. |
Absolutly agree. accounts should have to be whitelisted in order for a proposal to be created. This should also apply to the barter feature. There is no good reason to propose a transaction or barter with someone you have not communicated with beforehand. |
Perhaps a couple extra steps warning users in the UI when looking at a proposal which affects keys? A couple extra prompts to remind people that giving away their account is a bad idea you would hope would be sufficient to prevent the user from falling for such a scam? I don't agree with a centralized whitelist over who can create proposals, and I'm hesitant to support locking down proposals to only mutually whitelisted individuals because that could be a major barrier to bartering. |
I would kindly request to use the template provided in the root directory of this repo when submitting new BSIPs. |
@xeroc updated per template, hopefully is acceptable. I was hot under collar when I posted... burns to see people get taken. I got into this BitShares scene because I was fed up with directing people to centralized exchanges only to see them later complain of hacks and exploits. screen caps from another scam proposal sent to a user this morning the user has to click: THE ACTUAL GRAPHENE OF SUCH AS SCAM LOOKS LIKE THIS https://open-explorer.io/#/objects/1.10.24449 With the untranslated detail there is little way for a lay user to understand the nature of the proposal presented. Without a sizable background in both cryptocurrency and dex technology, nor is there a strong understanding as to whether to immediately approve or reject such an offer. "What should I do?" |
I created bitshares/bitshares-ui#2527 in bitshares-ui repository for the proposal rejection fee issue. |
IMO crippling functionality is not the right solution when dealing with user stupidity. (General rule: when you think you've made your software foolproof, evolution kicks in and creates bigger, better and faster fools.) The idea about having the proposer pay a high fee is bad because it breaks with one important thing: anyone who has to pay for an operation must approve the transaction. It also opens up ways to cause damage to users and businesses by deliberately rejecting legitimate proposals. Account upgrade may be a viable solution, although that might be seen as a rip-off by some. Whitelist can be implemented client-side. Regulation on account names might be perceived as a proof of centralization. I think we don't want that. Delayed transfer is useless because there are many ways to empty an account for a profit, for example by trading funds away for a worthless UIA. Also note that the root of the problem is that the users is giving control over his account away, so he will not be able to reverse transactions anyway. Rating system can be implemented client-side. Also, ratings systems / social score are never secure against abuse. |
Bitshares UI: Add Scam Alert |
2527 and 2529 both added to op |
https://bitsharestalk.org/index.php?topic=27856.0
also reply:
|
If it was functional there would not be users routinely getting scammed. It is inherently dis-functional as it stands in the "reference" user interface: there is a button to accept a proposal who's details are not disclosed nor translated into plain language. It is all to easy for malevolent actors to spoof a malicious proposal to appear to be important and from an official source. This is not functional software, it is liability and disgrace in the making. It does not matter how many warnings or steps you put between accept and deny. Until there is a plain English contract it should not be exposed to lay users.
This issue is easily solved by requiring the proposer to pay the fee in advance and get a refund upon acceptance via vesting balance.
Shoving contracts in people's faces who have no interest in such contracts is harassment. There is nothing legitimate about contracts that have not been negotiated and agreed to in advance between parties. The proposal system as it stands creates an open door to misrepresentation and incompetency; leaving the contracts legally invalid. If any of these scams saw the light of day in court invariably those behind the exploits would see criminal and civil penalties. |
Of course the software is functional. If users don't read and mindlessly click on "OK" three times(!) even if they don't understand what they are doing you can hardly blame the software. On-chain contracts will never be "plain English" (and if they were they'd still be invalid in most countries).
How can you ever enter a contract if you demand that it's been negotiated and agreed upon before it is even presented? Btw, I regularly receive invoice addressed to my business, for "registration in the world online catalog" and stuff like that. Needless to say, I never did register. The trick is that by paying the invoice I agree to the contract. Perfectly legal, and still I call this a scam. And SPAM too. |
Presenting only the signature line of inherently obfuscated content is not presenting "a contract". A legal contract has certain elements which have evolved over time in common law. If we are to call things contracts on blockchain... then they should mirror these required elements as established through time. Namely, mutuality of agreement... |
@litepresence I don't think it's the case. |
|
I posted an idea here: bitshares/bitshares-ui#2658 (comment) |
Abstract
There are rampant scam proposals being sent to lay users posing as official sources with fake official looking names to "upgrade accounts" or "improve security". The user believes the correct thing to do is accept the proposal. Shortly thereafter they realize they've agree to give all their funds away.
Motivation
It is poor business practice to create tools which are prone to be used by hackers to steal user funds.
Competency
andFree Contract
are legal requirements for a valid contract.There cannot be free contract when there is misrepresentation.
There cannot be competency when all detail of contract are not disclosed.
Where there are on blockchain invalid contracts there will be legal consequences in brick and mortar courts.
Further, whenever there are invalid contracts, the standard choke points for exit from crypto markets will be burdened with the blacklisting of scammer funds. This includes Gateways, Centralized Exchange Operators, and Faucet Providers. All of which are ultimately staffed by developers who will be redirecting development time to chasing down ghosts of scammed accounts.
It is my hope that this BSIP and resultant discusssion will be a focal point for suggesting and validating technical solutions to the proposal scam issue until every vector of such attack has been shut down and stamped out.
Rational
Without a technical solution in place this scam will continue to tarnish the reputation of BitShares. The day after the user, which prompted this bsip lost funds, another user reached out to me with a scam proposal. It is all to common and the results for those taken are beyond devastating.
Discussion
I think we've all seen it coming. Here it is.
$80,000.00 Gone
Proposals lacks a metric of trustworthiness, this needs a technical solution. I don't know what it is, but this outcome was predictable as a consequence of the code base in light of human nature, yet unacceptable from both moral or business perspective.
This needs to stop.
This is a gaping hole in the legitimacy of the platform; we cannot have new users randomly getting scammed for large sums of money. The subject needs to be fleshed out as to what is and is not possible from technical perspective to mitigate this risk.
via telegram "BitShares Community" group
(https://t.me/bitshares_community)
Potential Specifications
HIGH FEE FOR REJECTED PROPOSALS
If accept and reject proposal fee could be separated; not sure of technical end of this... but in theory you could set reject fee high and imposed on the initiator of the proposal. Perhaps as high as $10 equivalent such that nobody proposes anything without knowing in advance that the other party intends to accept. That is, negotiate first, agree, then propose, and finally accept. Or take risk that you will be charged $10 for failure to first disclose your intentions openly. As it is not possible to be charged a fee unless you give permission, the proposer should be charged the $10 fee ALWAYS and then REFUNDED if the proposal is accepted via a vesting balance.
FREE PROPOSAL REJECTION
There is currently a fee associated with rejecting a proposal. This fee should be set to ZERO. A user should not have to PAY to make a "accept scam" button to go away.
DUE CONSIDERATION ACCOUNT UPGRADE
By default a new account cannot receive proposals at all without explicitly "upgrading" the account and signing some contract that makes clear the type of scams proposals are prone to. I would be in favor of having to PAY to upgrade to receive proposals as a matter of contractual "due consideration".
WHITELIST
Bhuz, [10.03.19 13:58]
What about adding a whitelist for proposals? How hard would it be and how would that impact legit business? I think just having a whitelist on proposals make both sense and potentially solves the majority of scams without really affecting legit business that may want to use proposals. For whitelist on proposals I mean a user defined list that contains account names that are allowed to create proposals for the account in question. Cons I see is more RAM needed for consensus witness node, probably need to set an hard limit on the list length
Christopher Sanborn, [10.03.19 15:40]
I like this idea. Vast majority of users don't need or expect others to propose transactions on their behalf. Those that do, could/should take steps to enable it.
NAME REGULATION
The majority of these scams seem to arise from users that are either using an account name that sounds like a legitimate business or initiating a proposal with the word "security" in it as a method of deceit. A potential solution is to regulate any account name with "BitShares", "security", "open-ledger", "rudex" and disallow accounts with specific words in them from proposing transactions.
In most countries the word "bank" cannot be used by anyone except a state approved bank. eg Australia: "APRA limits use of ‘bank’, ‘banker’, ‘banking’ and ‘ADI’, and by extension words or expressions with like meanings (such as ‘banque’)."
Bhuz, [10.03.19 14:38]
It's hard to define what names need to be "regulated", it's hard to defend from similar/misspelled names, it's hard to update such a global list
DELAY TRANSFER WITH OPTION TO REVERSE
What about any funds that transfer via proposal move to some type of "vesting" balance and are non accessible for some period and there is option for reversal/refund within 24 hours? Is this possible?
P2P SOCIAL CREDIT SCORE
Is it possible to know percent of proposals accepted/denied by this user?
Would it be possible to have some form of rating system like you do at ebay where post transaction you rate the other party?
UI LEVEL FILTRATION
Stefan, [09.03.19 23:55]
The recent UI update 190227
needs double checking to see the approve button,
with a warning hint.
One first step could be to allow the UI to use an on chain whitelist on top of hard-coded scam account names to allow swift react
MAKE EXPLICIT THE NATURE OF THE CONTRACT
There is no attempt currently made by the bitshares-UI to parse the nature of the proposal. Until such time as the proposals are
1) TRANSLATED
from Graphene into English2) DISPLAYED
to the user, then under no circumstance should a button be presented to the lay user toACCEPT
terms of a contract both presented in obscure foreign language and without any apparent link to greater detail.BASIC AND ADVANCED UI VERSIONING
h/t @murda_ra
There could be two versions of the reference UI:
RELATED ISSUES
differentiate between scam and unkown proposals
bitshares/bitshares-ui#2429
Show required fee amount on permanently-reject-proposal page
bitshares/bitshares-ui#2527
Clearly render proposal contents
bitshares/bitshares-ui#2499
Increased user failsafe and security
bitshares/bitshares-ui#2460
Whitelist tab enhancement
bitshares/bitshares-ui#2423
Handle proposals related to phishing accounts
bitshares/bitshares-ui#2178
Document how proposals work
bitshares/bitshares-core#731
UI Scam Alert
bitshares/bitshares-ui#2529
KNOWN BLACKLISTED ACCOUNTS
https://github.com/bitshares/bitshares-ui/blob/develop/app/lib/common/scamAccounts.js
EXAMPLE SCAM PROPOSALS
https://open-explorer.io/#/objects/1.10.24449
Screen Capture of $80,000 loss
Summary for Shareholders
Copyright
WTFPL
The text was updated successfully, but these errors were encountered: