Skip to content
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

Auto blacklist proposal scammers #2658

Open
froooze opened this issue May 4, 2019 · 31 comments
Open

Auto blacklist proposal scammers #2658

froooze opened this issue May 4, 2019 · 31 comments
Labels
[1b] User Story The User Story details a requirement. It may ref a parent Project (Epic). It may ref child Task(s) [3] Feature Classification indicating the addition of novel functionality to the design [4c] High Priority Priority indicating significant impact to system/user -OR- workaround is prohibitivly expensive [6] UX Impact flag identifying the application User Experience

Comments

@froooze
Copy link
Collaborator

froooze commented May 4, 2019

Is your feature request related to a problem? Please describe.
Getting scam proposals is still annoying and I don't have any information what the proposal does from the UI.

Describe the solution you'd like
Blacklist people, who abuse the system:

  • Proposals per hour or day
  • How old the account is
  • How much is the account value in BTS

With blacklist, they can still be visible, but in a less visible way and with warnings. Now I have to pay a fee to remove this, the UI could do this, without any fees.

@abitmore
Copy link
Member

abitmore commented May 4, 2019

I got an idea. Let someone or a group with reputation (manually) maintain a blacklist on chain, E.G. with the on-chain account blacklisting feature, so the list can be updated quickly enough, better for UX than current mechanism which only updates when a new release is out. Although it's a somehow centralized solution, IMHO it would work. The maintainer account(s) can be multi-sig thus would be decentralized to an extent. We can even vote in a worker for the maintenance work.

For every account in the blacklist, show a warning icon next to the account name whenever it appears (on every page that shows account names). Ideally we can have a setting to directly filter out actions related to the accounts.

@froooze
Copy link
Collaborator Author

froooze commented May 4, 2019

User should decide, if it should be removed completely from visibility.

@startailcoon
Copy link
Contributor

We could, with abitmore's idea, also be able to handle whitelisted accounts as verified good accounts. The user could then toggle to hide all blacklisted accounts by this entity.

@startailcoon startailcoon added [1b] User Story The User Story details a requirement. It may ref a parent Project (Epic). It may ref child Task(s) [3] Feature Classification indicating the addition of novel functionality to the design labels May 6, 2019
@abitmore
Copy link
Member

abitmore commented May 7, 2019

By the way users are able to configure their own black/white lists, I guess we can (ab)use the lists for this feature, although it was not by-design (black/white lists are meant to be used by asset admins to authorize actions related to assets).

Actually, this is a non-consensus feature, ideally we can store user settings with custom_operation (rather than account_whitelist_operation which is consensus-related), then we need to write a plugin to track the data, with this approach, we can even design a mechanism so a user can decide to use another user's or a group of other users' lists.

@HB1github
Copy link

How about several stages (2-3) until accepting a proposal and get an overview/information before last stage about what happens, if accepting proposal?

@rsswlkr
Copy link
Contributor

rsswlkr commented May 10, 2019

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

@shulthz
Copy link
Contributor

shulthz commented May 10, 2019

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

This is the right way.

@bitfanatic
Copy link

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

Could the feature be enhanced with a extra step
Where the proposing account if not already is whitelisted
Has to be approved with a signed message?

@abitmore
Copy link
Member

can't create proposed transaction until users added <> to whitelist/contacts

I don't think it should be default behavior in core. It just like saying "don't ring your phone if someone not in your contact list called you", or "reject emails from people not in contact list", usually a client-side feature. Although it's possible to implement it as a core parameter, I think it's better to make it opt-in.

unless the other party has been informed first

The proposal IS informing the party. We just need to make it clear enough.

@froooze
Copy link
Collaborator Author

froooze commented May 15, 2019

My thoughts on implementation:

  • Make clear, that proposed transaction means handing over ownership
  • Auto hide proposals from blacklisted accounts (no user interaction needed)
  • Two confirmations are needed for proposals, which are not whitelisted

@froooze
Copy link
Collaborator Author

froooze commented May 18, 2019

Three people were scammed only by openledger-security the last days, why does this not have a high priority tag?

@abitmore abitmore added this to the 190524 milestone May 18, 2019
@abitmore abitmore added [4c] High Priority Priority indicating significant impact to system/user -OR- workaround is prohibitivly expensive [6] UX Impact flag identifying the application User Experience labels May 18, 2019
@matle85
Copy link

matle85 commented May 20, 2019

Kencode suggested maybe having a sort of automated white list where only people you have sent funds to previously can create proposals for you.

Accounts could choose to 'accept proposals from everyone' somewhere in the permissions (i.e. for committee accounts that won't fall for scams and need to be open for proposals)

@sschiessl-bcp
Copy link
Contributor

The frontend will soon listen to the blacklist of the account bitshares.org-notifications, maintained by UI team and bitshares.org owner. Furthermore, a news headline is added through that account as well (more precisely through the asset TEST), see #2679

@i-am-logger
Copy link

a correction needs to be made for all the accounts that where hacked and lost control.

  1. restore control with weight to the public key (via concensus)
  2. retrieve back the funds that were taken and still on the bitshares platform.
  3. contact authorities for the funds that were withdrawals.

@HB1github
Copy link

Please provide HOWTO

a correction needs to be made for all the accounts that where hacked and lost control.

  1. restore control with weight to the public key (via concensus) -> not possible with weight (see attached)
    Control
    Control2

  2. retrieve back the funds that were taken and still on the bitshares platform. -> bustard hacker has moved already funds

  3. contact authorities for the funds that were withdrawals. -> if they would answer and support not several days after hack, this would not happen

Hacker is "putler666", he should be stopped and banned from ledger!

@HB1github
Copy link

Hacker is "putler666", he should be stopped and banned from ledger!
gdex-security created a proposal: Update account data for putler666
putler666 transfered everything in BTS to huibao000

@i-am-logger
Copy link

  1. it is possible as the 21 witnesses can agree on it or have the committee agree on it. same goes with the other bullets.
  2. not all funds were moved. and if so then 3 is the way.
  3. take responsibility on your side, make the community aware of the hack, put pressure, but don't put the blame on others before you took full responsibility on it.

@HB1github
Copy link

Do you how many times, I wrote them...
Please provide HOWTO for

  1. restore control with weight to the public key (via concensus)?

@i-am-logger
Copy link

create a new transaction approval type for that which requires the multi-sig of x commitee (even votes) to allow the ownership or weight of an account to be changed

@HB1github
Copy link

I use bitshares desktop version 3.1.190618 (latest?)
bitshares-UI to update goes to a different link, where is the latest version?
Thanks.

@sschiessl-bcp
Copy link
Contributor

a correction needs to be made for all the accounts that where hacked and lost control.

  1. restore control with weight to the public key (via concensus)
  2. retrieve back the funds that were taken and still on the bitshares platform.
  3. contact authorities for the funds that were withdrawals.

On 1.: This would require a BSIP. Are you interested in helping work it out?

@HB1github
Copy link

Please advice for BSIP? I am interested to get my funds back.

@sschiessl-bcp
Copy link
Contributor

sschiessl-bcp commented Jun 26, 2019

Please advice for BSIP? I am interested to get my funds back.

The BSIP I had in mind won't get you your funds back unfortunately. It could restore access to accounts.

@HB1github
Copy link

Please start with 1st procedure to restore access to account. Thanks.

@abitmore
Copy link
Member

Just FYI this is a similar BSIP which restore access to accounts as well: bitshares/bsips#149.

@abitmore
Copy link
Member

And there is a discussion about this issue: bitshares/bsips#154

@HB1github
Copy link

A lot of comments and communication to read.
Any available instruction/link to restore access to account will be helpful?

@abitmore
Copy link
Member

abitmore commented Jun 26, 2019

It's impossible to restore access by now. That's why a new BSIP is needed if you want to restore access.

@HB1github
Copy link

I added new BSIP. Thanks.

@abitmore
Copy link
Member

abitmore commented Aug 12, 2019

@startailcoon @sschiessl-bcp What progress had been made about this? Here are new reports:

I used 'send' to withdraw EOS to the bitshares account 'binancecleos', intending to withdraw it to Binance EOS account of the same name 'binancecleos'.
This does not appear to be a Binance account.
... BTS accounts using exactly the same name as the Binance account for certain coins:
deepcrypto8 : STEEM
bnb136ns6lfw4zs5hg4n85vdthaad7hq5m4gtkgf23 : BNB
These 3 accounts are traps set up to catch this mistake and all have payments into them, all presumably the same mistake

We should add those accounts to this page:

bitshares-scammer_2

@abitmore
Copy link
Member

abitmore commented Oct 7, 2020

Blacklist managed by the committee to combat phishing attacks

A new "committee-blacklist-manager" account has been created to fight phishing attacks.

613 accounts have been added to the list (source https://github.com/bitshares/bitshares-ui/blob/develop/app/lib/common/scamAccounts.js).

The blacklist has been enabled on major committee-owned assets.

It's recommended that gateways and other businesses add that account as one of their assets' blacklist authorities.

If found a phishing account is missing in the list, or found a new phishing account, please report on Github https://github.com/bitshares/committee-tools/issues/new .

If found an account in the list is not a phishing account, please appeal on Github too https://github.com/bitshares/committee-tools/issues/new.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[1b] User Story The User Story details a requirement. It may ref a parent Project (Epic). It may ref child Task(s) [3] Feature Classification indicating the addition of novel functionality to the design [4c] High Priority Priority indicating significant impact to system/user -OR- workaround is prohibitivly expensive [6] UX Impact flag identifying the application User Experience
Projects
None yet
Development

No branches or pull requests

10 participants