ESI Access logs for apps with granted permissions

Is there a ESI endpoint that gives the logs of what apps have accessed particular endpoints, and at what time?

With the XML API players have access to the log list providing a way of identifying, doing analytics, on what actual usage the there is towards any one character. (Not through the XML API by it self… but… The log is available.)

I’m looking for a way of knowing what apps, that have a granted permission, is accessing what endpoints and at what time. This is of particular interest on those endpoints providing live data, like is character in fleet, and fleet members.

Any advice, or consideration of adding this would be good.

5th

There is not. it would get rather large very quickly in most cases.

If you have evidence of abuse, report it to Team Security.

TL;DR - Need ESI logs of requests so that it’s possible to determine the usage of those endpoints.

API’s in EVE represent the ultimate IA tool. As such it is not abuse for our different organizations to use it.
At the same time it is important for players to be aware what type of scrutiny they are actually under.
For some players it is more important than for others. Usage of EVE API data is not always abuse even though it is unwanted by the character in question.

It’s also a fact today that API access is a essential part of beeing part of an corp or alliance. CCP expanding the API side, while at the same time removing the logs create a unbalance that could increase the risk while infiltrating hostile alliances. Expanded API’s also increases the scruitny regular members are under as a default. As we know most alliances prefer to as good as possible insight into their members whereabouts. The usage of these API for IA purpuses is not abuse, it is what they are intended for. At the same time it’s not wanted, atleast for some character, but there is no option to not make API’s available - that would result in termination from the corps. Logging enables transparancy towards actions done on those API’s made available, and as such should be implemented. One might say logging creates a sort of balance.

Yes such a log could get big; if it does not exist and it was implemented in the traditional log style formating.
Such a event log in a condensed format might be a more scalable way. I do belive transparancy of the usage is important to multiple gamestyles. That is the reason I assumed it had been implemented already.

Since a condensed format is better than nothing I’d settle for a condensed format.
The most important thing is to be able to do analytics to understand the normal level of surveilance a character is under; so that any changes or increases in this is identified and pushed of as an event notification on app level.

EVE is about balancing multiple strengths and weaknesses. Right now, with the ESI, there is no transparancy on any ESI action, increased activity, or character monitoring. Knowing ESI has reduced the vulnerability, but it does not enable a interactive playstyle where it’s possible to assume risk even with a hostile organization having API access.

5th

Using the the api to pull scoped data without user consent is a breach of the developer agreement.

The corp will need to tell you they have this awesome ia tool, everything it tracks and why, and you give them consent to do so; or they are technically violating the agreement.

With that in mind, you know what access they have to your data, so why do you need a log?

You are told upfront what scopes are requested.

So if they tell us they have this awesome ia tool, we (the 5th) have no way of avoiding being cought?
They do have our consent to use the data, in any way they feel like. It’s EVE after all, if you don’t want to be in a corp; it’s always others.

Point is loosing the ability to see when the API’s are beeing pulled is a major disadvantage. That in combination with the increased coverage that ESI provides compared to the old XML API… is a major balance shift.

You have to realize that the ESI endpoints, scopes, is a combination of historical logs (itemtransfer/wallet), current inventory(assets), and and realtime data(is character in a fleet, fleetmembers etc…). Any organization interested in a particular character will most likley increase the sampling rate on characters of interest. Before this was visable in the XML logs, even with what IP address that made the request. With the ESI there is no such transparancy.

So I’m basicaly saying it’s in some characters interest to have access to the logs, even in the cases where there is no agreement violation; since we have to agree to things we rather not…

5th

Only the app that you authorize has access to ESI. why do you need to see what IP address it was?

There is not a need to see what IP address it comes from. Seeing what IP address a XML API query comes from is a nice feature of todays EVE XML API, as it can tell you that there is a “new entity” or sub feature going through your data. Knowing where the queries regularly comes from… is nice.

There is some differences between the XML and ESI interfaces. The XML gives the logs including the IP’s. Seeing how a particular corp normaly queries you from place A, then all of a sudden queries you from place B, C and D with much faster intervalls tell you to back off the target. Before they even have called you in for a IA talk. So the IP availability is just a nice feature, but not realy required.

With ESI there is no transparancy. I’m not saying we need accress to IP’s that make requests. With todays privacy laws that might be a challenge; but I’m saying there is no reason not to make the queries against the endpoints available through logs or condensed logging formats. (Question-focused dataset…)

Without ESI logging we will still be able to make it work; but have to assume all realtime data also is compromised; and not only sampled every 4 - 92 hours. There is a huge difference between assuming realtime data is compromised, and sampled every 92 hours. With a random 92 hour sampling it’s possible to assume some risk. Without knowing the samplingrate there is no way of assessing the risk involved in doing clandestine interactions that is visable on the realtime ESI api. As such all ops need to be planned as the sampling is done at the worst possible times.

5th

I get what you are saying, but there is currently no log.

There is a developer agreement they have to stick to, and a very clear display of what access you are giving the application when you log into it.

The application cannot be used “as a means of tracking Player information or Player activity without the express knowledge and consent of such Player” and also cannot be used “as a means to misappropriate a Player’s in-game items or other information, or to otherwise cheat, scam, or defraud Players.”

So if they have an IA application that you consent to its use, assume any scope it requests is going to be pulled. The sampling rate is likely every five minutes to an hour. In the case of location: every five seconds or less.

The flip side of this is that players need to start asking questions of their alliance: what are these applications doing? If their applications are asking for every scope under the sun: refuse to use it. Join a different alliance, there are many out there.

The only apps that can use your data, are those you authorize via EVEOnline’s SSO interface. If you dont authorize, the app CANNOT even get data. If you authorized it, then you have no control over how often information gets pulled. If you’re trying to pull some hinky-ass awoxing spai ■■■■, you’re going to have to live with the fact that your information can be polled anywhere from every 5 seconds to an hour, depending on the scopes authorized. Which also shows you probably have a fundamental misunderstanding of ESI. It isnt rate limited. I would not need to use multiple servers or some random thing like that to poll information more frequently. I can request information as slowly as once an hour (most endpoints) to as frequently as 5 seconds (character location).

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.