PCounsel@

How to Counsel an API Launch—6 Best Practices

Robin Moore -

Disclaimer: Reading legal articles on the Internet and naively applying it to your situation would be silly. What follows isn't legal advice, it's general legal information. If you aren't an attorney, consult one.

tl;dr Before launching a new API to your service, you should do the following:
1. Implement contractual restrictions
2. Create granular access
3. Present honest user-authorization language
4. Don't overly rely on your honest user-authorization language
5. Perform a security review
6. Be careful about COPPA

There have been a surprising number of front-page stories about APIs this year (to be fair, any front-page API-related stories are surprising). For example, the New York Times wrote a breathless story about Facebook partners, the Wall Street Journal wrote about Gmail apps having access to user data, and, earlier this year, the Times published the biggest API story to date—Cambridge Analytica.

All this extra attention could make you nervous about approving your company’s API launch. But don’t worry. I’ve got you, fam. Here are the things you need to get sorted before you sign off.

1. Implement contractual restrictions.

Drafting the API legal terms is the easiest part of the whole process. There are good examples of API agreements from all the big tech players (e.g., Pinterest, Google, and Dropbox). I would choose one of those as your starting point.

Drafting a good “acceptable use policy” is a little tougher. There are again numerous examples of these policies (Pinterest, Google, and Dropbox) but you don’t want to just cut and paste one of these. Instead, you’ll want to think hard about what activities you specifically want to prohibit while, at the same time, giving yourself enough flexibility to shut down a developer that has thought of a creative way to abuse your platform. Some common themes are:

  1. Data misuse;
  2. Creation of competing services; and
  3. Illegal and unsavory practices.

2. Create granular access levels.

Your product team will be tempted to create just one or two levels of data access (for example, super-limited-read-only-mode and god-mode). While this could be the path of least resistance for your engineering team, push them to see if there are more granular levels of access you can give. The ultimate goal is to only give each developer access to as much data as he or she needs. Privacy dorks call this the principle of least privilege.

3. Present honest user-authorization language.

When a user decides to install one of these third-party plug-ins, you want to be explicit about two things:

  1. The third party will have access to the certain portions of the user’s data; and
  2. The plug-in is covered by the third-party’s TOS and Privacy Policy.

Here’s how Gmail does it (source):

4. Don’t overly rely on your honest user-authorization language.

When a user authorizes a third-party plug-in, she is authorizing it not just for herself, but for all people who send her information. For example, if I authorize a shady third-party Gmail extension, I am giving that Gmail extension access to all of my email messages and all the email messages my family and friends send me. Or, to take an extreme example, when someone authorized the Cambridge Analytica personality quiz, they inadvertently gave up all their friends’ data.

This not-just-your-data problem puts extra pressure on you to ensure your platform isn’t isn’t hosting shady apps. Which brings us to the importance of the security review process.

5. Perform a security review.

The level of effort you put into your security review process will depend on your business objectives and your legal/PR risk tolerance. One model is “anything goes.” The Android store took this approach early on but later tightened up the security review, although problems persisted. Another approach is more cautious. Pinterest, for example, has been very measured and selective in rolling out its developer platform.

When performing a security review, here are some things your security team can look at:

  • Encryption practices
  • Authentication policies
  • Vulnerability disclosure program
  • Patching and anti-virus practices
  • Phishing protection measures
  • Physical security measures
  • Vendor security processes
  • Employee training
  • Logging practices
  • Auditing practices
  • Privacy policy compliance

As an attorney, you will want your security team to keep records of their completed security reviews so you can point a regulator to them if something goes wrong.

6. Be careful about COPPA.

Twitter and Google have both been sued over allowing non-COPPA-compliant apps into the “family” section of their app stores. Because the FTC has taken a platform-friendly interpretation of COPPA, I can’t see how these lawsuits are going to survive. FTC COPPA FAQ H.16. Regardless, having a good story about how you’ve taken extra steps to protect kids from illegal data use is nice to have when the New York Times comes calling.