Make ESI IP bans non-permanent

[kennethjor]

Feature Request

I think IP-based bans shouldn't be permanent. Instead, it could have a very long timeout, like four weeks or something, but not permanent. I do realise there's a process where you contact support to be unbanned and all that, but I'd like to make the point that literally permanent IP bans seem excessive.

Use case

There are many reasons why users may switch IPs:

• People are using VPN Services.
• People have non-static IPs with their ISP.
• People are running jobs on cloud services with non-permanent IPs.

In the latter use case, some inattentive developer might not even notice the ban, and suddenly half the AWS region is on the ban list.

Finally:

• People are banned because an app makes a large number of requests on their behalf.

Checklist

Check all boxes that apply to this issue:

• [ ] Feature request description is provided
• [x] Use case exists
• [ ] Feature requires a new route
• [ ] Feature adds data to existing route
• [ ] Feature requires new auth scope
• [ ] Feature can reuse existing scope
• [ ] Feature does not require auth
• [x] Meta feature, applies to all routes

[ghost]

How does the IP based ban work at all with people using CG-NAT which is being used as an IPv6 delaying tactic by carriers?

Gives a new meaning to socialising the consequences, aka sharing the pain, the risk here aside from unintended consequences and collateral damage is it being used as a denial of service attack on those that share the IP address intentionally.

IPv6 IP based bans will be as bad, they would have to ban entire prefixes.

IP based banning is not reliable going forward nor is the strategy of banning your customer base out of existence sustainable, eventually you run out of customers.

Playing devils advocate, perhaps if they (CCP) charged a fee (fiat, PLEX, ISK, crypto) for using the ESI interface?

[SimantoR]

As a developer, I think the more appropriate system would be to use per-application key. You register your application with CCP and your key is unique to your HTTP calls. That way ban can be per actor. As someone who's waiting to hear back from CCP since Friday on IP ban during my testing with ESI, I don't oppose the ban. Some people will abuse it. If CCP enables the per-application approach and sets a clear rate limiting for how much is allowed, it'll benefit all parties involved

[lukasni]

@SimantoR there's actually some pretty strong drive within CCP to make all endpoints authenticated for that exact reason. There isn't really a need for a new system, can just use the existing auth with no scopes. It's slightly more complicated than just an API key on the user end, but most applications already require auth for some endpoints anyways and it would be much easier to implement on the ESI backend and thus stands a chance of actually seeing the light of day :)

[GoldenGnu]

Full authentication is the only reasonable way to do it. Desktop applications have no way to keep anything secret. So you can't rely on the dev app id and/or secret alone, as desktop applications will have to ship with it, opening it up to attacks from bad actors. Anyone would be able to get any desktop dev app banned, in turn invalidating everyone who use the apps authentication and making the application unable to update anything from ESI. That would be bad, so, everyone making desktop apps would have to rely on people making their own dev app (like when evemon was first released with ESI support), but, that means only people who have payed CCP real money at some point can use desktop applications, because, that is the requirement to make a dev app.