I’ve been thinking about “Addressgate.” Watching the conversations flow. And it was an interchange between Nishant and Eric that finally trigger this post and these questions – who is responsible for the use of an API? Who should the market hold accountable for using a provided-API in a way that provides an unwanted surprise on the part of a user? And to whom should researchers turn when they discover an unwanted surprise, or a bug, or a feature, that unknown to users, spews forth personal data, silently, in the dark, like a pulsar?
The API provider is the obvious choice. They built the API after all and they provide the underlying service. The API provider wants their APIs to be free-ranged, to be able to show off all the amazing things their service can do. They want an API that is fully featured, and the market demands this.
But along with a terms-of-service an API provider issues, it doesn’t publish a code of ethics. There are no stone tablets accompanying that SDK a dev just downloaded. Try as they might an API provider has little leverage over what a developer does with their APIs and services. No matter how walled the garden is, surprise API use will happen, privacy will be impinged.
Can those purveyors of walled gardens do more to alert users that an app is accessing a piece of data? Of course. But at what point does this cease to be useful? I already get alerted when an app wants my location. Soon I’ll get an alert when an app wants some address book data. Eventually the alerts will out number the useful messages, and these alerts will be ignored, and we’ll be back to arguing about whether Apple should take more paternalistic actions to protect users from app developers.
Sad to say, but I think ethically-treating APIs, APIs that can only be used for the benefit of the user and display no unwanted surprises are impossible. Too many conflicting interests are at play. Platform providers can and should do more to inform users about apps accessing their data. App developers have to consider multiple privacy-perspectives when building their apps. But neither of these things may be sufficient.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.