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.