[Idea] User account protection: "XUMM Co-sign"

[WietseWind]

Idea. Brainstorm phase.

We're getting the occasional support tickets form users with their secret compromised. The most common reasons for users to have their key(s) compromised are:

1. Users (usually not aware of the implications) sharing their secret in e.g. scam forms (Google Forms, fake support, etc.)
2. Users (usually not aware of the implications) being scammed to share their secret in a chat/fake support/for an airdrop (Telegram, Discord, etc.)

I just engaged with two users who had other devices/clients than their own account interact with their account (tickets 28836, 29324). Two different users, different accounts, different symptoms, different destination exchange where funds were sent, but there's one common divisor: it wasn't their own XUMM install that sent funds out. Someone got their hands on their secret.

Based on the amount of fake XUMM Support forms I see on Twitter, based on the amount of airdrop scam websites asking for secrets, etc. combined with 600k app installs, 300k monthly active users, even the smallest percentage of users falling for these scams already result in a couple of these support tickets per month (week? @NetScr1be?)

Once scammers obtain the secret of a XUMM user, they import the secret in another client / on another device. The other clients are easy to spot, as they usually use different fees (fee levels XUMM doesn't support). If Secret Numbers, the scammers import into XUMM in which case they usually sign in at e.g. XRP Toolkit / Sologenic DEX / ... to put up DEX offers to sell all tokens and cash out XRP (with a normal Send flow, so we can't see that in our sign request database).

However, the fact that the account secrets are being imported in another client / on another device offer an opportunity.

What we could offer (opt in) to users, is to enable a XUMM "device lock" on their account. In which case we:

1. KYC the user
2. Set up a Signer List, with a signer account belonging to the XUMM user with weight 1 and a "signer account" from us (XRPL Labs) with weight 1.
3. The Signer List has a quorum of 2.
4. We announce a transaction to be signed to our own platform, with the auth headers normal platform API calls receive from our app. This way we know 100% certain that the call is being made from the original user's device.
5. The user multi-signs, our platform co signs, transaction is combined and sent.

Now if the user gets a new device, they KYC again, and if they are the same person, we map their new device as authorised for our co-sign service.

Things to check:

1. What about compliance?
2. What about legal implications / taxes
3. How can a user screw this up (e.g. losing their signer account)
4. Costs; KYC + platform, legal, etc. If this is part of XUMM Pro: costs covered, but only a small amount of users will use it. Shouldn't we offer to protect all? Vs. is that the risk of the end user, they can potentially mitigate by getting Pro and enabling XUMM Co Sign?
5. Etc.

An argument to prevent the semi custody argument / the "what if XRPL Labs/XUMM closes shop" would be to only offer this in combination with a Tangem card, where the quorum is 2/3: this way the user can sign with keypair + card, or keypair + us.

Edit: Alternatively a 2/3 setup could be achieved with a XUMM Device keypair + XUMM user keypair + XRPL Labs Co Signer keypair.

This has some overlap with things discussed before (@N3TC4T, @RichardAH) regarding XUMM key custody + account recovery for Pro users, where we don't have access to an account but we can help users recover. That's a Pro only feature for sure, but it's worth thinking about a light(er) version where we improve user security. If economically possible, usability OK, legally OK, etc. As getting this right for the masses is important if we want to protect the average user in the future.

[Alexbewier]

Just my 2 cents:

1. Compliance; on https://secret-numbers-to-family-seed.xumm.dev/ we warn the users about the importance of the SN. But I miss the 'real-world' perspective, where this number is almost the same as the PIN code for your debit or credit card. If we add this, we can link the safeguarding of the SN to the communication by banks on the safeguarding of the PIN, and that the PIN will never ever be asked by support or anyone else. This way, it is not only our communication, but we lift on the Banks' communication. This link to PIN security is not a 100% reduction in problems, as also with cards, people give out their PIN code to strangers.....

[Alexbewier]

and referring to points 3 and 4; the problem is with inexperienced users (hopefully, as we cannot address anything if the user is experienced and still gives the SN or other crucial information to third parties).

But what if we were to re-onboard a client when an account is opened on a new device. Or we do a light version of the onboarding, enough so that we can assess whether we are dealing with the same person. If it is not the same person, or there is too much doubt, we will trigger a full re-identification.

If we ask users to identify, it will be costly (no income when there is no PRO account), and we kind of step away from non-custodial/anonymity. This also means we might get into a discussion with regulators because we have information on the users. We have identified who they are, which means we might need to comply with sanction laws and even identification laws as we enter a slippery slope for our discussion with the regulators.

[WietseWind]

@Alexbewier Your point 1: You basically mean: adding the big fat red warning everywhere where we talk about Secret Numbers that "allowing others to see/copy/obtain them equals handing out your bank card + PIN code + signature"?

Re: re-onboarding: that's what I'm aiming at indeed, or at least: proposing. Good point at compliance requirements once we know (even though we don't provide custodial / regulated services). We could have an obligation just by knowing... Good point.

There is an approach that could make sense but it's a big change when it comes to the audience we service.

• We could grandfather in existing accounts and try to push them to getting a Tangem card, but what if...
• We change the onboarding of the app to make it almost impossible (or at least: incentivize users to please NOT continue) to onboard XUMM without getting a Tangem card.
• We could work with Ripple and Tangem to sponsor the cards to the point where the cards & shipping are basically 100% marketing & market expansion budget. Make the financial barrier to get one as low as possible. Make it the "unhappy" flow to continue generating a paper account.
• -Which comes with a disclaimer and users waiving all things.

* [@richardah](): Tangem card or Tangem-alike card :wink:

The thing here is not that I want to prevent spending time on support, I really want to make this a thing of the past. It's the only way we're going to help improve the crypto space & crypto/XUMM user experience.

It could cost us new users, but what it we get 25% of the users, but 90% more satisfaction/security and 90% less users losing their savings?

One thing to consider though is the price and income difference. We want to "provide cheap, fast, open, boundary- and borderless payments for all", and by adding an almost mandatory fee (purchase of card, even if for the absolute minimum amount the shipping is still significant) we'd push some of the potential audience out, which isn't "open" and "boundary-/borderless".

[RichardAH]

Condensing my suggestion from MM chat:

1. We force users to pick between a co-signer or a tangem card (which can replace co-signer), or take a detailed exam and sign a waiver to opt out of co-signing.
2. Co-signer is a separate legal entity sponsored by the foundation.
3. Co-signer is automated: most txns are automatically co-signed, only unusually large or unusual destination triggers an email with a link to confirm the txn.
4. Adding a tangem card causes your card to become your co-signer.

[WietseWind]

Freezing for now, we'll take the route of education for now, and can revisit at any point when we feel confident enough about key custody / co signing / hardware / KYC use.