This is of course rather stupid but it can be expanded. Think of a DDEX: here you can match someones trade by transferring tokens to a certain address. The only thing the user now needs to do is to broadcast that these tokens are deposited and either the maker of this order can now take them or the user includes a fee for someone else to ““mine”” this token on-chain which gives them incentive to pay for this gas. (This fee is hence in the calldata / salt). If the order is not matched the user can go on-chain to withdraw their tokens by simply providing the supplied calldata and showing that the user wants to cancel the order (to prevent the contract to try to match the order again). (Or the order is fulfilled already).
This seems like a doable first task. The second part about Whisper etc. etc. seems like there are a lot of rabbit holes to go down. If we get these simple mixers, one can start by having users actually generate multiple accounts and not immediately link them. Still relies on OPSEC of the user, but a good start for simple dApp usage.
This is a situation that could use improvement. Two areas come to mind.
Have people here thought about these issues more deeply?
You can even profile what kind of wallet scheme their using. Whether they have a cold storage address, are just using MetaMask or some other hot wallet, etc. This helps to know how difficult it would be to attack the user.
On the UX front, this is mainly a middleware and best practices issue. Can we help out wallets / web3 providers succeed at making this easier to set / generate accounts per dapp?
This problem becomes exponentially worse when you add it to things like airdrops or giveaways where many people are associating their social media identity with their address. Anything that can be used to tie an address down to any other identifiable information makes this blockchain meta-information very powerful to attackers.