From MozillaWiki
Jump to: navigation, search


Tracking bug:


Draft FAQ (to be linked from the released feature):


Question: How do we make API access more accessible to all Mozillians, while minimizing the risk of overexposing the personal identity information that Mozillians put in their profiles?

The blog post about the risks explains what we're trying to mitigate. We have an opportunity to mitigate those risks while democratizing the API.

How the API currently works

  • Users can request an API key through Bugzilla
  • The API key traditionally granted to users is a "Community"-level API key. Community API keys can only return "vouched=yes/no" in response to request that includes an email address in the parameters. In other words, they're not very powerful.
  • As a result, some users have asked for elevated privileges -- the so-called "Corporate"-level API key. Corporate API keys return every user profile field for every user.
  • Initially the Corporate API key was intended for a select few, but it has been granted more widely, even to users whose applications are unreviewed and running on unknown hardware.
  • In the time since the API was implemented, user profiles have been enhanced with per-field privacy levels. Users can specify that certain fields are public or for Mozillians only. But the API doesn't expose these per-field privacy levels, so API consumers with Corporate-level access don't know which fields are public. There is certain potential for PII leakage as a result.
  • Since realizing all of the above, we've been hesitant to grant new API access to *anyone*. This is unfortunate as we're missing opportunities to extend the platform and grow the community.

New proposal

  • Allow any vouched Mozillian to request a "vouched"-level API key by filling out a form with some basic information about their intended usage.
  • "vouched"-level API keys will be granted immediately, automatically, with no review.
  • "vouched"-level API keys give access through the API to data for users who have at least one public field, and only to their public fields.
  • "vouched"-level API keys also respond to a query including an email address parameter with "vouched=yes/no".
  • Allow users to request "reviewed"-level API keys using Bugzilla.
  • "reviewed"-level API keys will be subject to review and conversation that gives Mozillians stakeholders confidence that the applicant will handle data responsibly and can protect it from overexposure. (This review process remains to be specified)
  • "reviewed"-level API keys will be listed on an FAQ where anyone can see them.
  • The FAQ will also explain such things as "how do I get an API key" and "what does an API key give access to" and "what do I do if I think someone is misusing data" and more.
  • Users can have more than 1 API key and will be encouraged to get a new one for every application.
  • Users can delete their own API keys.
  • API keys will expire (disappear!) after 6 months of disuse.
  • All existing API users will need to request one of the new key types.

Upgrade path

  • Keep the v1 API as-is, with existing keys
  • Progressively deploy the features in API v2
  • When v2 is fully deployed, EOL v1
  • Communicate with API keyholders and all Mozillians about these changes