What are your “undocumented” APIs up to?

Do you know “Snappening”? It is a story about private Snapchat pictures turning from Casper, the friendly ghost, to a scary Halloween ghost. Recently, there was a second incident at Snapchat in which users had about 200,000 private pictures exposed (mostly pictures of under-aged users, aged from 13-17) online. Most had no knowledge of these photos being stored by anyone. Given the nature of some of those pictures (under aged/minor compromising pictures), these can be considered illegal to possess.

[Image courtesy: Casper’s Scare School]

[Snappening is a little different than the Fappening that occurred a few months ago in which female celebrities’ nude pictures were hacked from iCloud. In that case, the attack was targeted at specific celebrity accounts with a combination of brute force and phishing. Hence, the attack was limited to very few accounts and not massive scale like Snapchat.]

Read more of this post

Is your API an asset or a liability?

This article was originally published on VentureBeat.

A touchy API topic is data ownership and liability, regardless of whether the APIs are open or protected. Obviously, depending on your business model and needs, you will choose to expose the APIs and the underlying assets to your developers, partners, public developers, your consumers, or others that I am forgetting. While almost everyone talks about the API business relationships, the liability concern brings the legal relationship to the forefront.

[Image courtsey: jasonlove.com]

liabilityAPIs are considered a contract between the data supplier (or API provider) and the app provider. If you have different API providers that publish APIs from a central place, and multiple third parties use that API catalog to build apps for their consumers (end users), then it becomes complicated. While you can fix some of this by writing detailed contracts and making the app providers and end customers agree to the terms of usability before they use those APIs, as a provider, you are also responsible for implementing controls around your APIs to mitigate most, if not all, of the risks involved.

Read more of this post