Background

The Mozillians.org project has several interesting requirements

• High risk for privacy and legal concerns (Phonebook)
• Innovative data privacy features planned (profile page)
• Potential integration for profiles/identity/SSO/MozillaID across Mozilla web properties

We need to store very sensative user data and provide authentication services. Users will be pending until a community member vouches for them. Pending user's access to other'rs data should should be limited.

Data Privacy Release

After the 1.0 release, an innovative 'data privacy' release will add a per-user, per-attribute privacy preference, which is based on a user's community role.

Any data storage solutions should accommodate these planned features; it should give us building blocks for push the boundaries of easy to use privacy user interfaces.

Solution - LDAP

Pros

• Systematic support for Access Control Lists (ACL)
• Mature and open protocol
• Well tested and established open source product - OpenLDAP
• Optimized for heavy read/low write loads that match a Phonebook
• Mozilla already relies on it for mission critical systems
  • We are already looking to invest in our LDAP Ops expertise (cross-org win)
• Gerv built Domesday on LDAP
• Easier to test than adhoc NIH solution

Cons

• LDAP Directories aren't as sexy as NoSQL datababases
• Current expertise is lacking in Operations and Webdev

Although choosing LDAP isn't sexy, it's the responsible choice for getting a secure, quick to market 1.0 release out.

We'll get LDAP directory training and have designs vetted by an expert, to alleviate some of the risk from the Cons section.

LDAP Training

LDAP Training will begin August 29 and will be conducted by Dr. Andrew Finlay

Participants include: Ops:

• Justin Dow, jdow@mozilla.com
• Rob Tucker, rtucker@mozilla.com

Dev Tools:

• Peter Bengtsson, peterbe@mozilla.com
• Robert Helmer, rhelmer@mozilla.com

Flux TBD

Alternatives Considered

I interviewed many engineers in webdev, operations, and externally to brainstorm about off the shelf products that provide per-user, per-attribute data access control. No perfect "off the shelf" solutions were identified, many NIH solutions where invented ;)

A general comment: re-inventing ACL will take extra engineer time, testing time, and security review. Probably 3x to 10x as much time as the LDAP DIT and ACL work. This is fun and enjoyable for the hacker, but isn't the best for time-to-market, nor protecting our community's data.

MySQL

Pros

• Well understood, easy to hire for
• RDBMS are the default backend for Django
• Already in production
• Like Open LDAP, books and education is available

Cons

• No robust, general purpose ACL support
• Privacy features will be built in application layer for every feature
• Slower time to market, lower quality from privacy and security POV

MongoDB

Pros

• Sexy, easy to recruit talent (new hawtness)
• Flexible schema

Cons

• No ACL
• Privacy features built in application layer for every feature
• Another new system for Operations
• Not in production internally
• Not a ton of books, smaller community

Redis

See MongoDB, except we have some production experience with it

NIH Server

We can invent a totally new server which is the application layer and data-store.

Pros

• Funnest option for devs

Cons

• Too many to list