open All Channels
seplocked EVE Technology Lab
blankseplocked Feeback requested: Lowering the security level required for calls.
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2

Author Topic

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2011.01.12 12:02:00 - [1]
 

Hello peeps,

Me, Stillman and a few other peeps over here have been talking about the current access control on the API. There will be a Dev Blog pertaining to the details of those discussions later in the month for community feedback. However the work involved with that is somewhat extensive and until then we were thinking about doing some easy low-hanging-fruit fixes that we believe might do some good.

The issue here is mainly the FULL API Key requirement of calls that aren't really as sensitive as much of the other stuff the FULL key contains, mostly the body of EVE Mails. This requires characters to give out their FULL API key to CEOs (or others) who only need them to check the not-nearly-as-sensitive information regarding the character. As we all know from Stillmans Dev Blog: you should really think twice about giving anybody your FULL key (or any key for that matter).

The calls we identified as possible trouble makers:
/char/KillLog - Used heavily to populate kill boards
/char/Research - Used by CEOs to verify claims of datacore production

I would like to request your feedback on this.
Should this be lowered to the LIMITED key or stay on FULL?
Can you think of any other calls that might be better of on LIMITED access?

Thanks y'all!

HyperBeanie
Phantom Squad
En Garde
Posted - 2011.01.12 12:11:00 - [2]
 

As a killboard hoster, i'd looove to see the killlog lowered.
No reason to have that on the full api, as most killmails are publicly available online (and 2 parties have it already).

Recruitment (where you often hand out your limited api key) could also be more thorough (as you can see kills ;)).

So, YES to the killlog!

What about the /corp/killlog? Lower that to limited API on directors?

/Beanie

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2011.01.12 13:17:00 - [3]
 

While we only have 2 different access levels I think the current grouping is good.

The above argument re killmails, i.e. that 2 people have them already, could be made for wallet and mail APIs, too.

In the future KillLog should probably get it's own key though.

manasi
Caldari
Ceptacemia
-Mostly Harmless-
Posted - 2011.01.12 14:19:00 - [4]
 

I host our Alliance killboard, and honestly one of the biggest issue we have is with Full API's required by the EDK. Some people especially after reading [CCP's Stillman's blog] were reluctant.. SO I for one would love to see the limited API used for kill boards.

For the love of GOD though can we please find a way to represent logistics? That is a single glaring omission, there simply is no way ( without breaking the kill board ) to even note who was in logistics ships.

~The Mule


Fly8oy
Posted - 2011.01.12 14:23:00 - [5]
 

Well if you guys are going to be moving things around with the API keys, what should really happen is creating a 3rd API key. Ideally all this API would need is your character sheet and your kills/losses. There are lots of applications for various alliances that check which alliance you are in so to continue your access to whatever it is, there's no need for these applications to see your skill info, or wallet. This would also likely make it the heaviest hit API key freeing up the others quite a bit.

Bruno Bourque
Posted - 2011.01.12 14:50:00 - [6]
 

Originally by: Fly8oy
Well if you guys are going to be moving things around with the API keys, what should really happen is creating a 3rd API key. Ideally all this API would need is your character sheet and your kills/losses. There are lots of applications for various alliances that check which alliance you are in so to continue your access to whatever it is, there's no need for these applications to see your skill info, or wallet. This would also likely make it the heaviest hit API key freeing up the others quite a bit.


Agreed

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.01.12 15:04:00 - [7]
 

One that doesn't really make sense is having full key for accountBalance on characters since anyone with limited key can get your balance from characterSheet already.

Change killLog or research would probably not matter to most people either but what really needs to happen is a rethink of how its decided which APIs use what keys. From the sounds of it that is finally going to be looked at. What I would like to see is a system where players can decide to make APIs public (Limited key) or private (Full key) much like we can do with certs in game now.

In addition to that some of the existing APIs need to be split into multiple APIs. Example would be characterSheet where everything from implants to corp roles has been added on even though some could be considered higher risk information than others depend on what you are doing and whom you are giving the key to. Also having the same API return different results depending on which key is used, or even none at all, is less easily managed in applications than multiple APIs IMHO. It also must add a little overhead on the servers as well.

In the best of worlds I can see having a three key system where you have Full, Shared, and Public keys with ability to set each API to be accessible at all, some, or none of the levels. This would be a relatively easy system to program and allows the players a lot of better control over what they share without going to something that requires a large number of keys like per API or per application etc systems that have been talked about by third party developers in the past. Even just letting players decide which APIs to allow for each key in the current system would be great as long as there's an option to not give access to some APIs at all.

Ronan Teisdari
The Graduates
Morsus Mihi
Posted - 2011.01.12 16:28:00 - [8]
 

KillLog definitely for both.

/char/KillLog
/corp/KillLog

/char/Research - No reason to be on full tbh

One thing to note, is that we do have an issue now with having only 2 API Keys.

As a 0.0 corporation, we tend to take a closer look at individuals then other corps due to the spy/meta gaming issue. This causes us to ask for Full Key's, even though we don't need access to all of the API's. It also means that we could pull any Corporation data if they were a director in an existing corp, which we don't need to do.

If there was something in place, where we could have people provide access to "Full API's" via a short period of time through Limited API's, it would make things a lot easier for both.

Example:
We want to look at the char journal record. They log into their API, check the box to allow access via limited API for 10 days (Length could be specified or several options. We get the info, they don't need to go back and reset the permission as it was time limited.

This way, there would never be a reason to give out a Full API key to anyone else except for use in your own apps.

Desmont McCallock
Posted - 2011.01.12 17:02:00 - [9]
 

Edited by: Desmont McCallock on 18/01/2011 18:49:03

As the senior developer of EVEMon, my point of view on this matter is:

- Calls to char/AccountBalance are used mostly to determine the type of the API key the player provides (at least that’s what EVEMon does). Now with the AccountStatus we can have the same result, so char/AccountBalance is somehow redundant.

- I disagree with lowering the security for the Research points. As with Market Orders, Industry Jobs, etc those info are strictly personal. If a CEO wants to have access to claims of datacores production, you should implement a game mechanic and therefore a related corp/Research call, so the player can get RP for the player corporation (s)he is in, similar to the ability of issuing orders and putting jobs for a corp.

- Looking at the list of calls that need a limited API key in eve-dev wiki, I came to the conclusion that the low security level is required for those info that the player can use to brag about to other players (like skill levels trained, standings, medals, FW standings). So the Killlog call (both for character and corp) should fall into that category.

- CharacterInfo call is somehow questionable and redundant from my pov. There are 3 different calls a player can make using None, Limited or Full API key and the differences between them are so insignificant that they can be added to other calls or are already contained in other calls.

For example:
Use of None API key returns basic character info (ID, Name, Race, Bloodline, Corp info, Alliance info) including security status which could be added to the character sheet call (which doesn’t include the security status info of a character).

Use of Limited API key returns the above plus the ship the character is in. Can also be added to the character sheet as both require the same security level.

Use of Full API key returns the above plus the last known location of the character. I agree this is a vital info of type “need to know” and can only be useful to players that are either CEO or Director of a corp (it is already included in MemberTracking call).

- Corp standings should be dropped from Full to Limited to reflect the same security level as the character call (standings shown are only towards NPC’s).

- Info contained in the corp/AccountBalance can be moved to the CorporationSheet call (reflecting the same security level as CharacterSheet) making that call also redundant.

- All other calls can retain their security level.

Concluding, what I see necessary (from other posts) is the creation of an API key to use for Alliance purposes and the related API calls (don’t ask me what they should be, never been in any Alliance nor run one).

Hope I helped.

Cheers,
Desmont McCallock (a.k.a Jimi for those lurking in EVEMon’s forum)

mazzilliu
Caldari
Sniggerdly
Pandemic Legion
Posted - 2011.01.12 21:12:00 - [10]
 

what situations would mean that a CEO absolutely needs to know what datacores someone is producing without being able to take their word on it? moving that to limited makes little sense. this looks more like info that is of personal utility and tracking only, so its probably fine to stay on full api.

killmails should definitely use limited api. compromised killboards expose full director api keys, and lowering this drastically reduces the instances of full API's floating around on the internet.

Putting too much stuff onto the limited API introduces new problems as people will become reluctant to share their limited API key, even more than they are now, due to concerns they will expose sensitive data.

Arkady Sadik
Minmatar
Electus Matari
Posted - 2011.01.12 23:39:00 - [11]
 

KillLog - yes please. Same as /corp/KillLog for director limited API keys.

Also, please consider /corp/ContactList (not /char/ContactList) for the limited API key. That gives corp and alliance standings, and used to be on the limited API key with the old API, but "personal contacts" made it to full. Moving the corp standings only back to limited would be nice.

Sir Wolfgang
Gallente
Posted - 2011.01.13 09:32:00 - [12]
 

+1 Votes for
/char/KillLog - Used heavily to populate kill boards
/char/Research - Used by CEOs to verify claims of datacore production

I also would like to push a new naming system. People are rather touchy about the 'FULL' API and some people even believe that one's account can be compromised with it. Full API sounds too much like FULL control. Even limited API and API would seem more appropriate.

Wollari
Phoenix Industries
Wicked Nation
Posted - 2011.01.13 11:06:00 - [13]
 

  • /corp/Killlog - YES limited api key (but only from DIRECTORS)
  • /char/Killlog - YES no problem with that (Directors, who usually ask for them, can see them anyway through corp/Killog, usually Directors check background on new recruits via public killboards anyway (which shows more then the personal killlog where only final blows are getting listed)
  • /char/Research - NO, i think that should be in line with Market Orders, Contracts (later), Industry Jobs, etc.



Dierdra Vaal
Caldari
Veto.
Veto Corp
Posted - 2011.01.13 12:53:00 - [14]
 

Killmails should be on LIMITED key and Research on FULL - for reasons outlined by other posters in this thread :)

(at least, until we can make our own customizable keys)

Celebrain
1st Steps Academy
Fidelas Constans
Posted - 2011.01.13 13:02:00 - [15]
 

Frankly, it's a bit scary to loosen up any access at all without revamping the whole api key system so we can have a much finer grain of control over our data. Otherwise anything you do is going to tick some people off one way or another...

Peter Powers
FinFleet
Raiden.
Posted - 2011.01.13 14:34:00 - [16]
 

i'd like to be able to
define api keys and decide myself which of the api pages are available through said keys.

Ciryath Al'Darion
FinFleet
Raiden.
Posted - 2011.01.13 14:44:00 - [17]
 

I do not understand the division for two predefined classes, limited and full.

Why not clear out the issue once and for all? Simply allow people to have multiple api keys and choose themselves which calls are available for each key.

Squizz Caphinator
Woopatang
Posted - 2011.01.13 14:54:00 - [18]
 

I agree with the majority opinion about Killmails only requiring Limited API.

Short term: Reduce killmail API to limited API.
Long term: fine grain access to various levels of the API (as PeterPowers envisions it).

Rutger Janssen
Posted - 2011.01.13 15:38:00 - [19]
 

Edited by: Rutger Janssen on 13/01/2011 16:27:21
Killmails: yes, often used externally
Research: No, people don't need to know what I research. Why do CEO's need to verify datacore production claims? Because they all need to go to corp? Wouldn't you have the same issue with production? Maybe CEO's want taxes on market orders too?

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2011.01.13 15:50:00 - [20]
 

Originally by: Ciryath Al'Darion
Why not clear out the issue once and for all? Simply allow people to have multiple api keys and choose themselves which calls are available for each key.



Can we stay on topic? I'm pretty sure my post mentions this is a possible interim solution to a bigger project that I'm not detailing here.

Nadiim Zilch
Posted - 2011.01.13 16:00:00 - [21]
 

Switching killmails to a limited API- considering the popularity of making killmails public- Definately.

On switching research to public, I'm not certain.

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2011.01.15 10:15:00 - [22]
 

I can see the problem for requiring Full API Key for kill mails, so as an interim step to raise security, lowering the demand from Full API to Limited API for KMs seems reasonable.

That said, with "that bigger project" I'd like to see two changes:

- User-configurable API keys.
Mentioned a couple of times throughout the years, no need to rehash that topic.

- Privacy of information revealed to the public through (CEO/direx) API keys.
As a privacy activist, I'm not very comfortable with the way the current system works. Just because certain corporation roles give poeple access to the corp pilots information, doesn't automatically mean that those roles also should have the right to relay that information to the public. KMS are a good example.

Yes, CEO/direx will and should be able to see the combat log of the whole corp. But he shouldn't be able to publish all those kills via the corp API without the individual pilots agreeing to this. So, in addition to granular API keys, pilots need to have the option to switch on & off which of their personal info can be published through the corp's API.

plan q
Caldari
Cosmic Odyssey
BricK sQuAD.
Posted - 2011.01.15 17:03:00 - [23]
 

Originally by: Hel O'Ween

Yes, CEO/direx will and should be able to see the combat log of the whole corp. But he shouldn't be able to publish all those kills via the corp API without the individual pilots agreeing to this. So, in addition to granular API keys, pilots need to have the option to switch on & off which of their personal info can be published through the corp's API.

I just want to say that i strongly disagree that that statement above.If one were to have such a problem with the fact that Ones CEO's and Director's are publishing your km's then i would suggest that person join a new corp, that better fits with there beliefs. I view this as the same issue as Corporate email. Any official emails written a company computer for business (I believe) are property of that company. and As should any Km's (loss or kills) that occur when that person is in the corp , the Director / Ceo should be able to publish them. Think of it as public accountability.

Captain Thunk
Sniggerdly
Posted - 2011.01.15 17:16:00 - [24]
 

Edited by: Captain Thunk on 15/01/2011 17:21:33
I agree with moving char/killlog to limited but I think corp/killlog should stay as full. If you were to drop corp/killlog to limited all you will achieve is a drastic increase of load on the api server as people use 60 keys from their members to be able to update every minute if they wish - I'm pretty sure you don't want that and I'm fairly sure you don't have any protection against people doing that.

I see no reason why research needs to be reduced to limited - it's an entirely personal affair so no reason to be lowered. I don't actually understand why CEOs would be interested in it.

Edit: I don't think lowering the char/killlog will actually achieve much. iirc it shows the last 25/weeks worth compared to the corps 100/weeks worth and only those where the pilot achieved final blow. So I don't really see it being used much even if lowered, it's not practical for killboards unless a truly solo pilot and not that effective for recruitment scrutiny either because of its limitations. That said, there's no reason it needs to be full. Basically the char/killlog is an accurate record of your losses, but for the typical pilot, not much else.

Captain Thunk
Sniggerdly
Posted - 2011.01.15 17:18:00 - [25]
 

Originally by: Hel O'Ween

Yes, CEO/direx will and should be able to see the combat log of the whole corp. But he shouldn't be able to publish all those kills via the corp API without the individual pilots agreeing to this. So, in addition to granular API keys, pilots need to have the option to switch on & off which of their personal info can be published through the corp's API.


That has to be a troll.


CCP Stillman

Posted - 2011.01.15 17:55:00 - [26]
 

Edited by: CCP Stillman on 15/01/2011 19:08:28
Originally by: Captain Thunk
Edited by: Captain Thunk on 15/01/2011 17:21:33
I agree with moving char/killlog to limited but I think corp/killlog should stay as full. If you were to drop corp/killlog to limited all you will achieve is a drastic increase of load on the api server as people use 60 keys from their members to be able to update every minute if they wish - I'm pretty sure you don't want that and I'm fairly sure you don't have any protection against people doing that.

We do. The Memcached server is barely even being touched yet. And that's not even taking into account that the trick you describe wouldn't work anymore, as far as I'm aware. It used to work due to the fact that we have x API servers, which was being load-balanced between, which would have their own cachedUntil for the data. So if you time things correctly, it would allow you to pull the data every 60/xth minute. But now that all servers share the same cachedUntil time, that's no longer the case.

EDIT: See below post, what Captain Thunk describes is still valid.

Captain Thunk
Sniggerdly
Posted - 2011.01.15 18:30:00 - [27]
 

Originally by: CCP Stillman
Originally by: Captain Thunk
Edited by: Captain Thunk on 15/01/2011 17:21:33
I agree with moving char/killlog to limited but I think corp/killlog should stay as full. If you were to drop corp/killlog to limited all you will achieve is a drastic increase of load on the api server as people use 60 keys from their members to be able to update every minute if they wish - I'm pretty sure you don't want that and I'm fairly sure you don't have any protection against people doing that.

We do. The Memcached server is barely even being touched yet. And that's not even taking into account that the trick you describe wouldn't work anymore, as far as I'm aware. It used to work due to the fact that we have x API servers, which was being load-balanced between, which would have their own cachedUntil for the data. So if you time things correctly, it would allow you to pull the data every 60/xth minute. But now that all servers share the same cachedUntil time, that's no longer the case.


I understood it that a different charid/userid is a seperate entity from other members of the same corp pulling their own sheets and so would not have conflicting cache timers.

Thanks for clearing it up

CCP Stillman

Posted - 2011.01.15 19:08:00 - [28]
 

Originally by: Captain Thunk
Originally by: CCP Stillman
Originally by: Captain Thunk
Edited by: Captain Thunk on 15/01/2011 17:21:33
I agree with moving char/killlog to limited but I think corp/killlog should stay as full. If you were to drop corp/killlog to limited all you will achieve is a drastic increase of load on the api server as people use 60 keys from their members to be able to update every minute if they wish - I'm pretty sure you don't want that and I'm fairly sure you don't have any protection against people doing that.

We do. The Memcached server is barely even being touched yet. And that's not even taking into account that the trick you describe wouldn't work anymore, as far as I'm aware. It used to work due to the fact that we have x API servers, which was being load-balanced between, which would have their own cachedUntil for the data. So if you time things correctly, it would allow you to pull the data every 60/xth minute. But now that all servers share the same cachedUntil time, that's no longer the case.


I understood it that a different charid/userid is a seperate entity from other members of the same corp pulling their own sheets and so would not have conflicting cache timers.

Thanks for clearing it up

I just realized we were talking about 2 different things entirely.

The thing I described was due to the nature of the way "caching" used to work. IP-trickery is no longer possible in regards to that.

But what you describe, is definitely still possible. As long as you don't go insane, it shouldn't be a problem though.

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2011.01.16 14:53:00 - [29]
 

Originally by: plan q

I just want to say that i strongly disagree that that statement above.If one were to have such a problem with the fact that Ones CEO's and Director's are publishing your km's then i would suggest that person join a new corp, that better fits with there beliefs.



Well, why not let the corp & pilots decide? I'm constantly told that EVE is all about choices ...

Quote:

I view this as the same issue as Corporate email. Any official emails written a company computer for business (I believe) are property of that company.


See, that's the difference between believing and knowing. I know that this is not the case in my country.

Vaerah Vahrokha
Minmatar
Vahrokh Consulting
Posted - 2011.01.17 18:50:00 - [30]
 

KM API on public: yes
Datacore API: no (*)

As APIs become more and more all encompassing, the "two sizes fit all" approach does not work any more.

The Full API key must become a totally personal thing. I have to audit third parties and I need the full API key for that. This is an hell, because being able to read someone else's mails is one of the worst security breaches in the industry. A guy could be mailing some friend else about confidential RL details which I will come to know just because I am handled a full API key.

If decent granularity cannot be achieved in API keys, I'd prefer to have at least a third API key that is "almost" full but without the ability to see emails and POS location. The best, of course, would be to be able to configure each API key about what to disclose and what not, this is what I (humble PHP noob) am implementing in my next web project.


Pages: [1] 2

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only