Hacker News Reader

Comment by lolinder | Hacker News Reader

The $100 tab paid in dimes causes severe inconvenience to the person trying to count them and to the person who has to take them to the bank to cash them in and wait for them to be counted again.

Their very reasonable question was: if you can't distinguish the reverse engineered traffic from the traffic through your own app in order to block it, then what harm is the traffic doing? Presumably it's flying under your rate limits, and the traffic has a valid session token from a real customer. If you're unable to single it out and return a 4xx, why does it matter where it's coming from?

I can think of a few reasons it might, but I'm not particularly sympathetic to them. They generally boil down to "I won't be able to use my app to manipulate the user into taking actions they'd otherwise not take."

I'd be interested to hear if there are better reasons.

View on HN

"if you can't distinguish the reverse engineered traffic from the traffic through your own app in order to block it, then what harm is the traffic doing?"

If you really believe this you'll use a custom user agent instead of spoofing Chrome. :-)

Some websites use HTTP referer to block traffic. Ask yourself if any reverse engineer would be stopped by what is obviously the website telling you not to access an endpoint.

I'll add that end users don't have complete information about the website. They can't know how many resources a website has to deal to reverse engineering (webmasters can't just play cat and mouse with you just because you're wasting their money) nor do they know the cost of an endpoint. I mean, most tech inclined use ad blockers when it's obvious 90% of the websites pay the cost of their endpoints by showing ads, so I doubt they would respect anything more subtle than that.

If an endpoint costs a lot to run, implement rate limits and return 429 status codes so callers know that they're calling too often.

That endpoint will be expensive regardless of whether it's your own app or a third party that's calling it too often, so design it with that in mind.

Your app isn't special, it's just another client. Treat it that way.

The only reason why "another client" can exist is due to limitations of the Internet itself.

If you could ensure that the web server can only be accessed by your client, you would do that, but there is no way to do this that can't be reverse-engineered.

Essentially your argument is that just because a door is open that means you're allowed to enter inside, and I don't believe that makes any sense.

The argument is that what you call "limitations of the Internet itself" is actually a feature, and an intended one at that. The state of things you're proposing is socially undesirable (and in many cases, anticompetitive). It's hard to extend analogies past this point, because the vision you're describing flies in the face of more fundamental social norms, and history of civilization in general.

It's not a limitation of the internet, it's a fundamental property of communication.

Imagine trying to validate that all letters sent to your company are written by special company-provided typewriters and you would run into the same fundamental limits.

Whenever you design any client/server architecture, the first rule should always be "never trust the client," for that very reason.

Rather than trying to work around that rule, put your effort into ensuring that the system is correct and resilient even in the face of malicious clients.

> If you really believe this you'll use a custom user agent instead of spoofing Chrome. :-)

Read up on the history of User Agent string, and why everyone claims they're Mozilla and "like Gecko". Yes, it's because of all the silly people who, since earliest days of the WWW, tried to change what they serve based on the contents of User-Agent header.

Reply on news.ycombinator.com