Reading Assignment: Security vs User Experience

Are you ready for the next Reading Assignment?? I hope so, because here it is! This time about the compromise between user experience and contract security. Read through this blog post and answer the following questions in this forum thread.

  1. Why shouldn’t you just send people their ether directly (push)?
  2. What’s the writers argument against the “pull” design?
  3. What problem did the writer find with people not withdrawing their money?
1 Like
  1. Could run out of gas and could be a malicious contract address.
  2. User error (especially high among new users).
  3. What to do with it then (claim it, send it to charity, or send it to a predesignated address of the user) and depending on what is done what message would that send to participants in deciding how committed they would be in participating in the first place.
1 Like
  1. Why shouldn’t you just send people their ether directly (push)?
    could a malicious contract, contract might not be ready, the end user may not want it or nor wnat to take part in the place.

  2. What’s the writers argument against the “pull” design?
    new user error or user error. but 10% take greater than a week to claim only 10% actually claimed within that time period a week

  3. What problem did the writer find with people not withdrawing their money?
    claim process or designation could be different e.g. a charity and also dependant on winner whether they wanted to participate etc…

1 Like
  1. Sending ether back could run out of gas. Sending ether to unknown addresses could lead to security vulnerabilities.

  2. Users new to smart contracts ten to make mistakes.

  3. Problem was what to do with the money.

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

Due to possible malicious attempts of reentrancy attack.

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

Poor UX for end users. The users fear to make a mistake.

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

Many of them did not bother to widthraw their deposited funds as they were “lazy”. Some of them are willing to pay for “automatic refund”.
The users had to interact too many times with the “BlockParty” service

  1. register
  2. deposit
  3. widthraw
1 Like
  1. Why shouldn’t you just send people their ether directly (push)?
    Sending to many people can end up complete transaction, because running out of gas.
    Another thing is possible malicious reentry attack, when sending on unknown address which is contract.

  2. What’s the writers argument against the “pull” design?
    Users are lazy, also some have fear and they don’t want to again interact with contract.
    They also tend to make mistake when again interacting with contract.

  3. What problem did the writer find with people not withdrawing their money?
    What to do with money leftover, should it be sent to charity, taken by himself
    or returned to sender with (push) and opened security vulnerability because of that

1 Like
  1. because the sending might run out of gas or expose security issues
  2. Users tend not to do “pull” requests due to forgetfulness or fear of error
  3. funds remained unclaimed so how to deal with that issue , fairly ?
1 Like

Why shouldn’t you just send people their ether directly (push)?
Could run out of gas and opens contract to security issues.

What’s the writers argument against the “pull” design?
More interaction with a contract can cause inexperienced users to make mistakes

What problem did the writer find with people not withdrawing their money?
It is tied to the incentive of people showing up changing the payout mechanism may dilute the unique and strong message BlockParty has.

1 Like
  1. Pushing funds directly to users, or external contracts, can lead to more security vulnerabilities and potential errors than allowing people to pull their funds with an separate function they can call themselves. It’s also possible to run out of gas before you the function pushing funds back to recipients is completed, resulting in additional, unintended errors.

  2. He argues that the pull design is not as user friendly. In particular, people new to smart contracts are more likely to make mistakes if they have more opportunity to interact with the smart contract. Therefore, the less people need to interact with the smart contract, the better.

  3. It was left in the smart contract and was given to the smart contract owner after the default cooling period he set. In avoiding the security risks by using pull over push, he found himself with 10% of the original deposits not being collected and left in his possession. While this doesn’t seem like a very bad problem to have, he requested suggestions from the community on how best to disperse the remaining funds. Final solutions included sending it back to recipients with an admin fee, sending it to a predefined address like a charity, letting the contract owner keep it, and retaining the withdraw function.

What’s the problem with leaving the funds in the smart contract until users come back to withdraw the funds? He could just remove the clear function so the funds remain available for withdrawal indefinitely.

Sure, it’s a waste for the money to sit there, and after a certain point something should probably be done. But is there any harm or potential risk to the contract in leaving the funds unclaimed?

What’s the problem with leaving the funds in the smart contract until users come back to withdraw the funds? He could just remove the clear function so the funds remain available for withdrawal indefinitely.

Yes, that’s correct. There is no harm. But many projects want their tokens and users to be active. So they put in different measures to motivate their users to act in certain ways. And in this case, the author wants to make a point regarding push/pull. Many people think that the contract could simply pay out the balances when they expire, but that’s risky as we saw in the article.

1 Like

1 - you expose to some malicious callback functions
2 - user inexperience
3 - what to do wiht the money

1 Like
  • Why shouldn’t you just send people their ether directly (push)?
  1. Sending ether back to all the participants could run out of gas.
  2. Sending ether to unknown addresses could lead to security vulnerabilities.
  • What’s the writers argument against the “pull” design?
    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 favor pull over push for payments.

  • What problem did the writer find with people not withdrawing their money?
    More than 10% of participants do not withdraw their payout within 7 days. The problem is - What to do with it?

1 Like

1.Why shouldn’t you just send people their ether directly (push)?
Sending ether back could run out of gas and/or lead to security vulnerabilities.
2. What’s the writers’ argument against the “pull” design?
Users may have a fear of and/or make mistakes when interacting with a smart contract.
3. What problem did the writer find with people not withdrawing their money?
What to do with the un-withdraw amounts (without push/ send people their ether directly).

1 Like

Security vs User Experience

1. Why shouldn’t you just send people their ether directly (push)?
Cost more gas to complete this transaction. User pull function uses less gas and isn’t prone to malicious virus being downloaded into the contract.

2. What’s the writers argument against the “pull” design?
Limit the user interaction with the contract as much as possible because users tend to make mistakes.

3. What problem did the writer find with people not withdrawing their money?
10% of the users didn’t withdraw their admin fee within 7 days. The writer needed to create a rule to manage unclaimed funds.

1 Like
  1. Why shouldn’t you just send people their ether directly (push)? Sending ether directly could lead to issues like depletion of gas and security issues associated with unknown contracts. An address may run malicious fallback functions.
  2. What’s the writer’s argument against the “pull” design? The Pull design does not provide a good user experience, as the users do not want to interact with the contract more than necessary.
  3. What problem did the writer find with people not withdrawing their money? The writer runs into the problem of deciding who should get these funds while maintaining the incentive to participate.
1 Like
  1. Pushing ether to people directly can result a calling function to run out of gas. The address where we push ether could be a smart contract that has callback function implemented that can throw error. Thus, we can trust that our function will be executed without error.
  2. The argument of author against pull design is customer satisfaction. Many people are lazy to withdraw their funds and they expect to have funds send to them directly.
  3. The problem the writer found with people not withdrawing their money is what should be done with the funds that were not withdrawn. Should they be returned to the owens with additional fee or donated?
  1. You can run out of gas and secondly, probably more important, the other adress (maybe a smart contract) could execute code with a fallback therefore the security risks will be too high.

  2. 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. However, I have a bit of concern that donating the no show deposits to charity actually weaken people’s will to turn up because it goes to a good cause rather than random participants. Also, changing the payout distribution logic depending on events may dilute the unique and strong message BlockParty has.

  • 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.

  • What’s the writers argument against the “pull” design?
    Users may have a fear of mistakes when interacting with a smart contract.

  • What problem did the writer find with people not withdrawing their money?
    They do not know what to do with it.

  1. Why shouldn’t you just send people their ether directly (push)?
    To avoid your contract function to be exploit by a fallback function implement in the smart contract, if you split your contract logic and the withdraw function it safer, also your main function will cost less gas because the transfert will happen only once (no for every action but only when the user want his funds back)
  2. What’s the writers argument against the “pull” design?
    The issue here is that is less user friendly it’s require the user to do more actions, and sometime because they are lazy or they forgot they leave the fund on the contract.
  3. What problem did the writer find with people not withdrawing their money?
    He need to implement a logic which feet to the majority of his user about the unclaimed funds. The problem here is that his users opinion is divided.

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

It is a bad user experience since users may be able to get confused cause they may screw up something or they just forget.

He has to come up with an idea about what to do with the money of the people who didnt withdraw.

1 Like