Refactoring the Mozillians.org authorization scheme

One of the platforms I work on at Mozilla is Mozillians.org. Mozillians.org is Mozilla’s multi-constituent identity repository (or “phonebook”, as some prefer to call it). It is a simple profile-and-group management tool that serves data via a responsive UI and a read-only REST API. It houses about 4,000 user profiles: People who contribute to Mozilla in some way, whether staff or volunteer; people who consider themselves to be Mozillians.

Screen Shot 2013-10-14 at 2.34.07 PM

The post below is an analysis of Mozillians.org’s authorization system, which I believe is broken, and a rallying call to fix it.

Summary

Mozillians.org has become a mature platform and a valuable source of information about people who contribute to Mozilla’s products and mission, and it is likely to be important to Mozilla’s ambitious contributor goals over the next decade. But Mozillians.org has outgrown the authorization paradigms it started with. Therefore, in order to prevent data safety issues and questions about product integrity, we must design and implement an authorization system that accommodates current and future data and users. We should apply this system evenly to both the UI and the API.

Overview

Mozillians.org supports two classes of user account: unvouched and vouched. Anyone in the world can create a new account; that account will be unvouched, and it has very limited rights in the system (just a step above an anonymous browser). In order to be vouched, an unvouched user must find a vouched user who will vouch for them. In practice this means asking in IRC. Once a user is vouched, they have full permission to search and browse all Mozillians.org data and can also vouch other users.

Mozillians.org also supports two classes of API consumer: Mozilla Corporation and Community. Mozilla Corporation API consumers can access almost every attribute of most users and groups in the system. Community API consumers can only access the vouched/unvouched flag of a user whose email address is already known to the consumer. As initially conceived, accessing the API as a Mozilla Corporation consumer would require the requester to be paid staff and the URL of the consuming application to be a mozilla.org URL.

Problem

Vouching has lost much of its practical meaning, since we have no shared understanding or documentation of what vouched means or when vouching is appropriate. Some users are vouched immediately upon asking for it, while others must demonstrate some record of contribution. In practice, getting vouched is unevenly applied and poorly explained. Once vouched, accounts remain vouched forever. Mozillians.org’s current membership includes users who contribute daily or monthly; users who contributed in the past, but no longer contribute; and users who have never contributed beyond creating a Mozillians.org account.

Corporation/Community API authorization has lost much of its meaning, too. The criteria for being a Corporation consumer are not clearly stated in a policy document, and the data provided to Community consumers are not rich enough to meet the needs of most Community requesters. These factors combined encourage an ad-hoc approach to API authorization (for example, this bug).

While the erosion of meaning in our authorization paradigms has advanced, so have the quality of the data we solicit and the promises we make about its protection. In the past year we added numerous fields to user profiles, and we have plans to add more. We also added per-field privacy controls to profiles, a measure intended to give individual users more confidence about sharing private identifying data. These are definitely working well in the UI, but we have not yet applied per-field privacy controls to the content of API responses.

These are data safety and product integrity risks that we must address.

By granting easy access to the platform (either by vouching or granting Corporate API access), Mozillians.org exposes personal information that might not be shared if the actual exposure was clearly understood by users of the platform. We implicitly suggest that a trust network exists, but that network has an uneven (and low) barrier to entry; we implicitly suggest that API consumers will adhere to certain standards, but we do not strictly enforce these; and we explicitly declare that certain fields will be exposed to smaller groups, but we don’t yet apply these rules in the API. These are data safety and product integrity risks that we must address.

Solution

One obvious response to the problems described above is, “Stop vouching people who aren’t obvious contributors, and stop granting Corporate API access to Community API consumers!” But that response looks backward, not forward.

Mozillians.org has incredible potential as the single source of identity information across Mozilla’s varied constituencies — staff and non-staff, technical and non-technical, contributing daily or contributing just once, Foundation and Corporation. It is perfectly positioned to serve critical data about people to applications we haven’t even dreamed of. Look no further than the MozillaIndia Leaderboard (the subject of the bug linked above), which shows the most active bugzilla.mozilla.org contributors in India by mashing up bugzilla data with Mozillians.org data.

The ClawIt doesn’t take much imagination to realize that any number of contributor tools and outreach efforts will benefit from more Mozillians with richer profiles. From simple ad-hoc mailing lists to ad-hoc group-based authorization; from mashups like the MozillaIndia leaderboard to a unified Mozilla events system; from identity unification in bugzilla.mozilla.org to Dr. Claw, the Mozilla Schwag Bot©, which automatically sends t-shirts to contributors when they achieve certain badges; from 4,000 Mozillians to 1 million Mozillians: It all depends on more inclusion and more API access, not less.

It all depends on more inclusion and more API access, not less.

This blog post marks the start of the conversation. It is accompanied by a tracking bug in bugzilla.mozilla.org and a discussion thread on the developers mailing list. I’ve turned off comments here, but would love to hear other perspectives on the mailing list.

Ultimately, we may need to replace vouched/unvouched with something else, and we will certainly need to reconsider how API users authenticate and authorize to get API data from Mozillians.org. It’s going to be a fantastic technical and organizational challenge.

What an exciting time to be a Mozillian!

Update: In response to subsequent feedback on various channels, I proposed a framework for solving this, plus a concrete solution.


Appendix A:

If you are a Mozillians.org user and are concerned about the safety of your data, please don’t delete your account! You can take some simple steps to restrict access to your profile while we work through this bigger question:

  1. If you wish, you can change what applications (if any) can access your profile through the API. Look for the “Services” section in the Edit Profile view. But beware: Services like Badges.mozilla.org, Air.mozilla.org and others may require API access to function.
  2. While API users are not currently restricted by per-field privacy rules, UI users are. You can change fields to be visible to either Public (anonymous) or Mozillian (vouched) users.
  3. Very few fields are required. You can choose what you share. As Mozillians.org’s authorization scheme evolves, please consider sharing more information. Dr. Claw, The Mozilla Schwag Bot© won’t work without your t-shirt size and address!

Appendix B:

Dr. Claw, The Mozilla Schwag Bot© was conceived during the composition of this blog post for illustration purposes. Developers needed!