[lloeki]

other evil ideas:

- return a 200 with broken JSON, possibly triggering parse errors or exceptions in the caller

- return a payload that generates catastrophic resource consumption on the other end, e.g Content-Encoding: gzip and feed it a deflate bomb

- hack TCP and/or TLS to leave the other end waiting/stalling in an attempt to rate limit (timeout) or starve resources (ulimit) on the other end (e.g abuse 3 way handshake)

[ransackdev]

The site advertises itself as free for all and unlimited usage. To suddenly return malicious responses to intentionally break these apps might very well be illegal in many countries, or maybe would make them liable for damages claims. These clients are not violating any TOS or doing anything not allowed, after all.

[lloeki]

I said "evil" for a reason.

That said, it seems like a _single_ actor is causing 300% cost increase compared to _every other actor combined_. Even if advertised as free, there's decency to be had.

If I lend someone my home without TOS and say "make yourself at home" there's a reasonable common sense expectation from both parties that visitors should not turn on every water tap and electric device full blast 24/7, because that would be damaging to me in the first place.

Given the scale of the purported app causing this it's very much abuse in its own right, whether intentional, misengineering, or an oversight. The author of jsonip.com seems to have taken every precautionary measure to limit damage and identify perpetrators to reach out, and these failed. Ethically I feel it would be only fair to displace damage from their infra to the app in order to protect themselves. The only alternative is to shutter the service as it's essentially experiencing a financial DDoS.

[ransackdev]

> there's a reasonable common sense expectation

Your logic error is in assuming all people have common sense and setting expectations based on that assumption.

This actually has nothing to do with common sense, a jr and sometimes even senior mobile devs would not have the mindset of avoiding a ddos to a third party api when writing a feature that needs to get the device ip. It wouldn't be on purpose, it would just be that they don't know that they don't know yet. These issues of slamming a backend server are pretty common and mobile devs don't know to avoid it until they cause it imo. This could also be malware too which wouldn't care about decency.

Point is, scale your service, adjust your terms, start rate limiting, or shut it down. Calling your users names is the wrong solution no matter the user's intent, and solves exactly zero of the issues at hand.

The service owner should feel proud to have such a popular service, many folks will never have to deal with scaling issues. As the saying goes "scaling issues are good issues to have".

[pksebben]

> Calling your users names is the wrong solution no matter the user's intent, and solves exactly zero of the issues at hand.

True, but returning fire with malformed responses or other such tactics could absolutely solve:

> assuming all people have common sense

.. sometimes effective communication starts by doing what you have to IOT get someone’s attention.

[lloeki]

> scale your service

Scaling is done entirely at the expense of the service provider, so, not a sustainable option (and AIUI already done so as to continue serving for other users, but at terrible cost). Scaling issues are good to have when you have customers, not when you personally foot the bill.

> adjust your terms

At the very least changing terms won't change the already deployed app instances. In each of the three delineated scenarios it won't even register a blip on the abuser radar. So, not an option.

> start rate limiting

Pretty sure that was attempted. This is DDoS, rate limiting means doing it across the board, impacting every user, including those in good standing.

> or shut it down.

The only effective option. a.k.a the nuclear option a.k.a We Can't Have Nice Things.

> get someone's attention

That's the end game of these gray tactics. Not wreaking havoc but triggering awareness in a last resort way so that dialog can be opened/corrective measures can be taken. Note that "shut it down" would presumably have a similar effect, so there's no real harm done in practice.

[leobg]

Why? There is no guarantee give to victimize that service for free forever.

[ransackdev]

There's a huge difference between blocking traffic to keep your servers online (you are the good guy) and returning payloads that are intended to break consuming services (you are the bad guy, performing a premeditated malicious act on unsuspecting devices, across state lines)

[leobg]

Maybe. Sorry for the auto correct.