Hacker News Reader

Comment by social_quotient | Hacker News Reader

Reminds me the time we integrated a web survey with giftbit (api driven gift card service). While developing this for our client I had this nagging sense that we needed to rate limit or block multiple submissions by a single email but the client wanted it to ship ASAP and not take the extra time to have some validation flow.

Day 1 - 8 legit surveys each getting $50 amazon card Day 2 - just over a hundred with 90+ being the same gmail account. Day 3 - out of credits, campaign over.

Between this and the Voi write up I think it’s important to have a dark mind in the room to avoid stuff like this being so trivial. Some hacks you hear about and the first thought is about how gifted or smart the hack/er was, other times you just think how dumb the developer was. I’ve been on both sides of this and while I’m not proud of it I think the stories like these keep people on their toes.

View on HN

> block multiple submissions by a single email but the client wanted it to ship ASAP and not take the extra time to have some validation flow.

Surely that would have taken you ten minutes at most? I can't imagine anything more trivial. I can't imagine that the client wanted multiple survey results from the same person either.

This might actually delay things if you work at some bureaucratic company where you need to discuss with another department whenever you want to add a table to the database or something.

Also, while keeping track of email addresses is simple, making such a system hard to exploit isn't all that trivial, with there being wildcard and throwaway email addresses and so on.

He said they already stored the email address, and that the offender used the same one. At least the most trivial of checks would have deterred the person most likely.

This to me would be a fundamental feature of the system - multiple survey results from the same person are of no value.

I upvoted you because in my heart I agree. Yet now having shipped commercial games my mind tells me otherwise. The simplest behaviour can cascade into bugs, edge conditions, more feature requests, and for some features the base implementation is never the hard part.

Any feature which fundamentally transforms the final result, say by blocking a transaction, will be one of those cascading features. Sure just adding a "good enough to be 80% there" could be simple. Yet what happens when the client turns around and says "You delivered a broken app to me, I tried submitting my survey 3 times and only the first time was it accepted".

Sure this feature can be accommodated. The client might ask for special handling of test email accounts. Or an admin panel. Or a report & moderate workflow where they can override the block.

Getting to the core issue: the client did not see the value in the proposed work. If you are getting paid and spending extra time unpaid to give value to clients, you better be doing so because the client is going to be thankful.

Imagine a scenario where the OP ignored the clients wishes, implemented the feature anyway, tanked the negatives, all so that the client would not lose money to fraud, and thus prevent the client from seeing why the feature was needed in the first place. Lots of work, negative reward for the programmer.

> Getting to the core issue: the client did not see the value in the proposed work.

The Op sounds like they were trying to graft more money from the client to me. The email was already stored. A trivial check would have reduced the triviality of the exploitation.

Not to mention that multiple survey results from the same person cannot be assumed to be what the client wanted.

Your attitude is the difference between a junior developer and an experienced one.

Remindes me of the lamentations of a friend working at a webdev company. Step 1: Their customer wants a "Don't send me e-mail" option for users of the system. Step 2: Customer goes into rage mode since an important users doesn't get some mails. Step 3: Do not to punch the customer in the face because that user had the "Don't send me e-mail" option set - and the customer could see that from their admin panel.

When you are new you should do exactly what the client says. When you are experienced you should get clients that are willing to pay extra for your experience.

The amount of time to develop a feature makes no difference if the client didn’t want to pay for the time it would take to develop it.

It's all in how you present it. If you say "hey, I just thought of X, do you want to do it?" It's much less likely to get approval.

If you say, "hey, for the cost of a gift card or two we can prevent a single person from disrupting our campaign" it's much more likely to get approval.

And agree, this should be extremely trivial to implement and if the project was quoted prior to development should be included in the initial scope.

We can't prevent all malicious behavior but we can prevent the easy stuff.

Ask the question: How many gift cards should go to the same email address?

I think a lot of time a client wants the developer to implement business rules, but these change so frequently that developers should not automate it, but make operations easier. In this case the business rule was “every submission gets a gift card” but this business rule needs exceptions. So giving out gift cards should be done manually but should be easy to do and this would prevent problems like these as well as other probably fraudulent behavior.

Maybe they had no database to store emails? They just called an API to give out the giftcard. No longer 10 minute change.

True, but we raised the issue also that we needed to solve the dynamic alias name+@gmail for example, along with the free email providers @mailinator, all of this got rejected as a single feature. So yes just blocking dups on it’s own is trivial, it was wrapped in an epic around some other points.

But I want to echo that your comment is accurate, maybe not 10 minutes, but it’s a rounding mistake worth of time on it’s own. The results got emailed as soon as POST so we didn’t keep a db along side the app. Keeping the list of used emails would have been easy but it would mean keeping a log/db/redis/flat file somewhere. That ends up eating a little more time.

I think what we have illustrated here is exactly what happens in the bigger hacks. “Why didn’t they just... it takes 20 minutes to do that” and yes it does but it was packaged probably with other things that got killed.

It probably wouldn't have helped, creating an email account is easy enough.

Reply on news.ycombinator.com