 |
 |
On Dec 2, 2013, at 1:25 PM, Kevin Ford wrote: > > A key (haha) thing that keys also provide is an opportunity > > to have a conversation with the user of your api: who are they, > > how could you get in touch with them, what are they doing with > > the API, what would they like to do with the API, what doesn’t > > work? These questions are difficult to ask if they are just a > > IP address in your access log. > -- True, but, again, there are other ways to go about this. > > I've baulked at doing just this in the past because it reveals the raw and primary purpose behind an API key: to track individual user usage/access. I would feel a little awkward writing (and receiving, incidentally) a message that began: > > -------------- > Hello, > > I saw you using our service. What are you doing with our data? > > Cordially, > Data service team > ---------- It's better than posting to a website: We can't justify keeping this API maintained / available, because we have no idea who's using it, or what they're using it for. Or: We've had to shut down the API because we'd had people abusing the API and we can't easily single them out as it's not just coming from a single IP range. We don't require API keys here, but we *do* send out messages to our designated community every couple of years with: If you use our APIs, please send a letter of support that we can include in our upcoming Senior Review. (Senior Review is NASA's peer-review of operating projects, where they bring in outsiders to judge if it's justifiable to continue funding them, and if so, at what level) Personally, I like the idea of allowing limited use without a key (be it number of accesses per day, number of concurrent accesses, or some other rate limiting), but as someone who has been operating APIs for years and is *not* *allowed* to track users, I've seen quite a few times when it would've made my life so much easier. > And, if you cringe a little at the ramifications of the above, then why do you need user-specific granularity? (That's really not meant to be a rhetorical question - I would genuinely be interested in whether my notions of "open" and "free" are outmoded and based too much in a theoretical purity that unnecessary tracking is a violation of privacy). You're assuming that you're actually correlating API calls to the users ... it may just be an authentication system and nothing past that. > Unless the API key exists to control specific, user-level access precisely because this is a facet of the underlying service, I feel somewhere in all of this the service has violated, in some way, the notion that it is "open" and/or "free," assuming it has billed itself as such. Otherwise, it's "free" and "open" as in Google or Facebook. You're also assuming that we've claimed that our services are 'open'. (mine are, but I know of plenty of them that have to deal with authorization, as they manage embargoed or otherwise restricted items). Of course, you can also set up some sort of 'guest' privileges for non-authenticated users so they just wouldn't see the restricted content. > All that said, I think a data service can smooth things over greatly by not insisting on a developer signing a EULA (which is essentially what happens when one requests an API key) before even trying the service or desiring the most basic of data access. There are middle ground solutions. I do have problems with EULAs ... one in that we have to get things approved by our legal department, second in that they're often written completely one-sided and third in that they're often written assuming personal use. Twitter and Facebook had to make available alternate EULAs so that governments could use them ... because you can't hold the person who signed up for the account responsible for it. (and they don't want it 'owned' by that person should they be fired, etc.) ... but sometimes they're less restrictive ... more TOS than EULA. Without it, you've got absolutely no sort of SLA ... if they want to take down their API, or block you, you've got no recourse at all. -Joe