Seperate what we say from what we do

Status Mobile
,
1

Objective
Discuss and apply our principles to make product decision regarding the feature ‘Send transaction’.

Context
We currently allow sending a transaction to anyone we come across on Status. This offers some great utility such as sending kudos in a public chat. This utility comes with a drawback:

  • we expose the wallet address by default. And more than merely exposing the wallet address, we are exposing a mapping between the wallet address and what people say.
  • we do not inform users that there wallet address is exposed as soon as they join any chat

I think this is unacceptable if our intention is:

“to build a secure communication tool that upholds human rights, enables community money, community law, and through privacy preserves culture.”

Proposal

In the distance there are more complex solutions coming up regarding key and pofile management. This is a proposal for a short term solution.

  1. Remove the option to ‘Send a transaction’ for all users that have not added you to their contact list (a.k.a. Trusted user group). This option appears in the UI:
  • Profile view
  • Command features in chat
  • Send transaction > Select recipient
  1. Inform users what information they share when adding someone as a contact (a.k.a. assign to a Trusted user group). As is part of the latest Profile designs.

Discussion

This is not a new topic. I’ve heard many arguments in the past. Here’s my take on some, looking forward to hear more.

#1 What’s the problem?

Anyone can see what transactions you’ve made and match them to what you say, with ENS, this can be connected to who you are and by that a host of other information bits. The biggest issue in that is the fact that this mapping is exposed without consent and knowledge and required to use basic functionality of the app (chat).

#2 This is inherent to transparency on the blockchain.

Transparency of transactions is; Transparency of the mapping between transactions and what we say is not.

#3 We would lose utility, people should be able to send transactions

People still can, they would need to ask the other person to add them as a contact.
Key management, and allowing people to decide what key they use in Chat versus other activities would be a much more secure and private way to provide this utility. A utility of which we don’t know to what extend it is actually being used.

#4 You can derive the wallet address from the contact code anyway

Awareness and capability to derive the address is different from having it served to you in our UI. Mitigation of an undesireable threat doesn’t mean resolving it, but at least we are reducing a risk.

5 Likes
2

Great point!

It is somewhat related to privacy handling with extensions. A number of events/queries might expose privacy sensitive information.
e.g. a slightly modified send command could be dynamically deployed as an extension

How do we handle those generically from a UX perspective?

3

#3 we can’t do tribute to talk as is done in the MVP, so we can’t do that until the next version of tribute to talk

Weird title, sounds like politics 101 :smiley:

4

came here to say #4. Glad you addressed it. This won’t get resolved until the new profile changes + new key separation happens.

How much work is this, as it basically only reduces the freely giving aspect of address exposure without consent.

Would a simple modal explaining that this is exposed (and we’re actively working on changing this) be easier while providing around the same amount of mitigation?

5

Great points & @hester your analysis is all sound and clear !

Overall it’s as much a question of managing timelines (effort to implement this short term change, impact on TtT, when we can foresee to have a new key management system) than how we respect our principles :slight_smile:

Overall, @petty suggestion for a simple modal might be a good trade off to limit the overall work on this, and still allo Ttt in the short term. Wdyt @hester ?

6

Thanks for thinking along on this topic @petty @julien @yenda @guylouis.

Overall, there’s seems to be consensus for a short term mitigation rather than preventing any view on wallet address. This mitigation should be in place until we have a key management solution implemented.

For a mitigation the best position would be:

  1. Before joining a chat; as this is the moment the address becomes exposed
  2. Before proactively using the wallet (sharing the address by tapping on [Receive].
    If the address is only used for chat, there is actually nothing exposed, whereas the address may be visible any transaction activity or mapping that counts as information has not been as there is none.

#2 is the most contextual option that would impact least number of people. Also, it wouldn’t hurt to inform first time users that transactions are public even once we have key management in place.

What do you guys think about this bottom sheet variation?
cc @andmironov @maciej

Once we have key management, we can leave out the second sentence (i.e. “People you talk to on Status can see this code”)

AzgnbOPIqt.png375×812 33 KB

2 Likes
7

Concluding with this issue on Github: Information bottom sheet on Wallet > [Receive] · Issue #7968 · status-im/status-mobile · GitHub

1 Like