Reading Assignment: Security vs User Experience

[jak]

Why shouldn’t you just send people their ether directly (push)?

The two main reasons that you developers prefer pull over push is because:

1. You can run into security issues through having more complex code, which is also harder to read/digest.
2. The contract may run out of gas when executing a push function/s to the recipients.

Push sends which are transferred to unknown addresses can implement a fallback function. This is why most reputable blockchain organisations advise for pull sends if a push can be avoided.

What’s the writers argument against the “pull” design?

The writer suggests in a later argument that having a pull design in the contract is detrimental to the user experience.

Particularly with new users who are not familiar with blockchain, they sometimes submit several requests to the contract before their initial call executes. They waste gas and it’s inconvenient in many cases.

As a general rule, the writer argued that the less people have to interact with a contract the better. People will be less likely to make mistakes if they only have to interact with the contract once.

What problem did the writer find with people not withdrawing their money?

The writer found that more than 10% of participants left their money on the contract for more than a week.

When he brought this to the community, users raised the question as to why the contract couldn’t auto-return the funds (or push transfer).

This brought upon the idea of some expiry period where people can withdraw their funds, else it would be put to use in some other way.

[CryptoPhoenix]

1. Why shouldn’t you just send people their ether directly (push)?
   –Sending ether can trigger fallback functions that run logic, which could be malicious, but it’s also more expensive for the sender and risks running out of gas.
2. What’s the writers argument against the “pull” design?
   –User experience is hampered by more steps on the user’s part.
3. What problem did the writer find with people not withdrawing their money?
   –10% weren’t withdrawing after 7 days, and the longest someone went without withdrawing their funds was 281 days.

[tanu_g]

1. Why shouldn’t you just send people their ether directly (push)?
Because of the following reasons-

1. Possibility of running out of gas.
2. Sending ether to an unknown address could lead to security vulnerabilities.
3. Writing push logic with other parts of the code can increase complexity.

2. What’s the writer’s argument against the “pull” design?

1. People actually don’t take their money back.
2. People shouldn’t interact with the smart contract more than they have to as they tend to make new mistakes.
3. Not good from the perspective of user experience.

3. What problem did the writer find with people not withdrawing their money?
Whether to share it or give it to a better cause, the dilemma of what to do with no-show deposits.

[RBeato]

1. Why shouldn’t you just send people their ether directly (push)?
According to the writer sending ether back to all the participants could run out of gas and sending ether to unknown addresses could lead to security vulnerabilities.
2. What’s the writer’s argument against the “pull” design?
Users should not really need to interact with a smart contract more than they absolutely have to as people new to Smart contracts tend to make mistakes.
3. What problem did the writer find with people not withdrawing their money?
…

[Tomahawk]

1. Why shouldn’t you just send people their ether directly (push)?

• sending ETH to all the participants can run out of gas
• sending ETH to unknown address is less secured, because this address can cointan a fallback function

2. What’s the writers argument against the “pull” design?
It is more confusing for users, UX is not so good.

3. What problem did the writer find with people not withdrawing their money?
They were too lazy or it was confusing for them to withdraw.
The problem was what to do with the leftover money (send them to owner address, distribute to random users or donate to charity), so it won’t affect people’s will to turn up. The best solution would be to predefine address (owner, charity, etc.) at registration, to which should be the deposit send after not withdrawing.

[jelle_van_der_meer]

1. Why shouldn’t you just send people their ether directly (push)?
This way you can drain the contract out of ETH and then no one can use the contract. And it could lead to ETH being sent to unknown addresses which lead to security vulnerabilities.

2. What’s the writer’s argument against the “pull” design?
because this brings more complexity for the user which also leads to more transaction fees being paid by the user. And this is a trade-off to the UX.

3. What problem did the writer find with people not withdrawing their money?
The writer didn’t really know what to do with the money. He could keep it himself, share it amongst all the other participants or give it tot charity. It was the latter one because he let people vote on it wich i find very cool.

[Kamil37]

1. Why shouldn’t you just send people their ether directly (push)?

• Sending ether back to all the participants could run out of gas.
• Sending ether to unknown addresses could lead to security vulnerabilities.

The second point is now best known as “Pull over Push” pattern and advocated by reputable blockchain organisations such as OpenZeppelin and Consensys

Every Ether transfer implies potential code execution. The receiving address can implement a fallback function that can throw an error. Thus, we should never trust that a send call will execute without error. A solution: our contracts should favour pull over push for payments

External calls can fail accidentally or deliberately. To minimize the damage caused by such failures, it is often better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically. (This also reduces the chance of problems with the gas limit.) Avoid combining multiple send() calls in a single transaction.

2. What’s the writers argument against the “pull” design?

His argument was that users should not really need to interact with smart contract more than they absolutely have to as people new to Smart contract tend to make mistakes.

3. What problem did the writer find with people not withdrawing their money?

He had to decide to chose between keeping the pay-out, share between participants or sending to charity.

[ibn5x]

Security Vs User Experience Reading Assignment

1. Because it is possible that your transaction could run out of gas, not to mention the possible security vulnerabilities sending Ethereum to unknown addresses.

2. That user should not have to interact with smart contracts more than necessary especially new people in the space since it is easier for them to make mistakes.

3. What to do with the funds. He discovered that changing the mechanics of the payout could affect the level of engagement of users oscillating their activity.

[cecilia]

Answers

1. We shouldn’t send people their ether directly because you can potentially run out of gas and also you might be sending ether to unknown addresses that can cause security vulnerability.

2. The writers argument with the pull design is that the users will not know how to interact with a contract and wouldn’t take responsibility to do it or will most likely make mistakes.

3. The problem the writer found with the people not withdrawing their money is making a decision on what to do with the funds.

[jtb]

1. Why shouldn’t you just send people their ether directly (push)?

Sending ether to unknown addresses could lead to security vulnerabilities. Also, you can run out of gas faster through this method.

2)What’s the writers argument against the “pull” design?

A user error may occur.

3)What problem did the writer find with people not withdrawing their money?

The problem was what to do with the money.

[Saula_Atama]

1. Why shouldn’t you just send people their ether directly (push)?
   The contract could drain the funds leading to insufficient Ether, and malicious code could be implemented.

2. What’s the writer’s argument against the “pull” design?
   I think the writer has got a point, people want efficiency and they want the money returned with ease instead of an extra step where they have to interact with the smart contract.

3. What problem did the writer find with people not withdrawing their money?
   People weren’t aware or weren’t to fussed about there withdrawals

[livermore123]

1. Because it costs much gas
2. Users seem not to withdraw by themselves after a long time
3. Their fund can be lost

[Denzel]

1.- it could be a malicious contract, or gas outages.

2.- Hard to understand for new users.

3.- What to do with the remaining money.

[nutrina]

1. you can run out of gas, or send to a malicious smart contract address that will throw so you get stuck
2. more difficult for the users (UI / UX, some complain about the fees, some are not so familiar with smart contracts and make mistakes, etc …)
3. He needed to find a designation for the money, as people do not reclaim it.

[yestome]

1.a) because it goes against the security principle of modular code

1. b) the receiving address could implement a fallback function that could try a re-entrancy attack, or trigger an error

2. a) sending ether back to all participants could run out of gas
   2.b) sending to unknown addresses could lead to security issues

3. how to resolve the question of how to handle funds left behind by lazy or non-interested users

[Emmerich]

1. Because it poses a security vulnerability and you could run out of gas.

2. He wanted to minimize user interactions with smart contracts to a bare minimum, because people make mistakes, especially if they are new to crypto and smart contracts.

3. He didn’t know what to do with the left over funds.

[Vivek20]

1. Why shouldn’t you just send people their ether directly (push)?

There is a risk of running out of gas and could lead to security vulnerabilities

2. What’s the writers argument against the “pull” design?

Users should not really need to interact with smart contract more than absolutely have to.

3. What problem did the writer find with people not withdrawing their money?

People complainted about user experience and one user didn’t know how to withdraw.

[andrew.k]

Why shouldn’t you just send people their ether directly (push)?
- it reduces the chance of problems with the gas limit
- Avoid multiple send() calls in a single transaction
What’s the writers argument against the “pull” design?
- To receive the payout, however, you have to call the smart contract function withdraw(). For user’s its hard to understands.
What problem did the writer find with people not withdrawing their money?
-There is a cooling period for 1 week after which allow owner to take it. 10% of people didnt take money for first 7 days

[Emmett]

1. Why shouldn’t you just send people their ether directly (push)?
   Can cost lots of gas
   Pushing in separate transactions can mean some work some fail

2. What’s the writers argument against the “pull” design?
   Its a little more interaction with the contract than might be desired by a user

3. What problem did the writer find with people not withdrawing their money?
   They forgot about it and all sorts of questions about what do with it then

[Bogdan_Manzar]

1. Why shouldn’t you just send people their ether directly (push)?
this can lead to a fallback attack
2. What’s the writers argument against the “pull” design?
the pull design is better for security, but then some people do not want to make the extra effort to take their money back
3. What problem did the writer find with people not withdrawing their money?
he could not figure out what the best way to deal with the un-withdrawn money