Post-conditions allow/deny mode

[jasperjansz]

This discussion is about the post-conditions mode in the web wallet. We're looking to get feedback from developers to help decide our implementation.

Context: Post-conditions are a tool to protect users from bugs in contracts that make unexpected transfers from their account. The web wallet can evaluate post-conditions in two modes:

• In Allow mode other asset transfers not covered by the post-conditions are permitted
• In Deny mode no other asset transfers are permitted besides those named in the post-conditions

Read more about how post-conditions work here.

When we first drafted the designs for transaction signing in the web wallet, we decided the web wallet would evaluate post-conditions in deny mode always. This would mean that unless an app specifies post-conditions, no transfers can be made from the user's account. We would show the specified post-conditions and the user would learn that the transfers that show up on this screen are always what will happen, a boost to user experience and security:

The flipside is that an app developer would always need to specify post-conditions.

Discussion: We would like to learn about any difficulties of stricly deny mode would cause you as a developer, what your preferred method of evaluating post conditions would be and why. Besides the web wallet being in strictly allow or deny mode, there's also the option of enabling the app to set the mode and the wallet showing a warning if the app chose allow mode.

[friedger]

I am all for security, and prefer the deny mode. A dry run tool/button "See what transfers will happen?" could be helpful to verify the expected transfers by running the function as read-only as proposed in stacks-network/stacks-core#1641

[LNow]

I think that wallet should allow developer to choose which mode he want to use.
However if allow mode is chosen, then wallet should inform user about potential risk of this mode and force user to perform additional action (ie. type wallet password again, solve simple math equation, or type "i accept the risk" or something similar) prior signing and sending transaction. This additional action should be added to force user to do something more engaging and mentally demanding than clicking a button.

[friedger]

What are use cases where a user would choose allow?

I don't see one that could not be done in deny mode. I can imagine cases where users are tricked into selecting allow mode by malicious app owners.

[psq]

for example, swapr has no way to guess what the underlying native token is when dealing with a SIP-010 token, there is no meta data, there may even be multiple of these, so it can use some heuristics, databases, but if all else fails, letting the user chose allow is the only thing that would make the swap possible.

[friedger]

I see. It is a problem of matching sip-10 tokens with their native asset(s).

Would a dry-run execute different transfers than the real one?

Would the user be happy to execute a transaction where they don't know the outcome in advance?

[psq]

or a rebasing token with a multiplier that can not be inferred from metadata, so even if you could find the native token name, you could't specify the amount.

Not sure what you mean by dry run, the only thing I can think of would be terrible from a UX POV.

[jasperjansz]

@psq thanks for chiming in. I understand you can't infer the correct token from its SIP-10 name or symbol. But I don't quite understand how allow mode would solve this.

If I want to swap my STX to Miamicoin on Swapr, where does the list of tokens I can choose from come from? Does it display a list of all Stacks' native tokens or will it use something like tokenlists? If the former, don't we have the same problem where the user won't know which Miamicoin to pick?

[markmhendrickson]

I'm personally not sure whether we should support "allow" mode in the long run, for the security reasons that @jasperjansz cites and with the optimism that we may iron out these issues with surfacing data about SIP-010 tokens and the like.

However, I'm inclined to suggest that we do support this mode in the short-to-medium run given @psq's apparent need for it – and combined with the general philosophy of supporting more possibilities so we can then learn from their real-world usage.

Right now, it seems that we frame post conditions in the UI the exact same whether the transaction is taking place in "allow" or "deny" mode. This itself is confusing since in "allow" mode, the data shown in the UI is simply guidance (and the contract might do whatever it wants in reality). I believe @philipdesmedt mentioned that he uses post conditions and "allow" mode for Arkadiko so the user has a best guess as to what will happen, but his contracts also have more flexibility for their actual execution.

I suggest we do two things differently for "allow" mode:

• Clearly indicate this mode with some sort of warning saying "There are no guarantees this contract will do anything it's promising!". With post conditions, this could go in place of the "...or the transaction will abort" guidance in "deny" mode, or as a standalone message if no post conditions are passed.
• Soften the framing of post conditions. E.g. instead of "You'll send" for each condition, "You may send".

[philiphacks]

Correct. We use allow mode in combination with post conditions since it shows a nice message "you will send X STX/DIKO/..."

I don't really like scaring the user too much personally with something like "There are no guarantees this contract will do anything it's promising!".. but I understand you have to draw the line somewhere.