The Mozilla Manifesto is in favour both of individual privacy (bullet 4; ‘security’ is intended to include privacy) and transparent community-based processes (bullet 8). One of my goals for Domesday, and therefore the Mozilla Phonebook, is to promote both better user privacy and transparency in the processes for the community that each Domesday installation is tracking.

Privacy

Domesday’s privacy features are intended to be simple, understandable and powerful. Users should have full control of what data can be seen by whom, in a way so easy and natural to configure that the defaults are almost irrelevant.

So, in Domesday, a user can configure the privacy of their data on a per-field level. Privacy is a first-class organizational principle in the UI:

You can drag and drop fields from one privacy level to another to change their privacy – or try out one of the suggested sets of settings by moving the slider.

This is in contrast to systems like Facebook, which only allow you to set the privacy level of types of data, and also make the settings hard and obscure to change. Their business model is antithetical to privacy – the less you have, the more money they can make. There’s nothing wrong with making money, but communicating with your friends should not require you to sacrifice either your privacy or theirs.

Transparency and Accountability

Each user in Domesday has a set of tags associated with them. Some tags are special and cannot be self-awarded, but must be awarded by a user who has another tag, called the “blesstag”, for that tag. (A tag can be its own blesstag.) This feature allows Domesday data to be used to create flexible systems of access control for resources – including to data within Domesday itself. Whether someone has access to data in Domesday which has particular privacy level is based on whether they have the particular tag associated with that level.

Crucially, for all users, the ‘tags’ field is always public. This means that any user of the system can see who has access to what data (inside Domesday or elsewhere), even if they can’t see the data itself. If you want to see who has access to “Mozillians” data, just ask the system for a list of everyone who has the tag “mozillian”. That’s important for transparency and accountability across the project.

So if, for example, we ever decided to manage the security group using Domesday, everyone would be able to see who is in it. dveditz would not have to manually maintain the list of members, because the system would do it for him. It is right that everyone in Mozilla can see who we are trusting with access to security bugs, even if they can’t see the bugs themselves. Domesday enables accountability patterns like that.

Transparency and accountability also suggest it is very important to clearly define the privacy levels within Domesday, their purpose, and how you get them. If there was a level called “admin”, with no description, how could you tell whether a particular person actually needed that capability? But if there was a level called “contributor-community-team”, which was described as “people who organize Summits and ship t-shirts”, because the purpose of the level is clear, people can look down the list and raise an issue if they think someone is on it who shouldn’t be.

So both within Domesday and outside it, the system promotes transparent community-based processes, and thereby accountability and trust.