Chandler's design goals include support for Jungle.Privacy, Security, and Sharing.

In this wiki page I will describe at least one, probably several, scenarios related to these topics that (1) I have personal experience with, and (2) I think are important to future PIMs.

Fully visible repository synchronization should NOT be the default

Some Chandler pages talk about how the typical user will have at least two repositories - one at work, the other at home. Possibly three, including a laptop or PDA repository.

Consider, for purposes of argument, the PDA as the primary "personal" repository - everything that a user cares about is there. The PDA repository is synchronized with the repositories at work and at home.

Clearly, you want security via encryption on all repositories.

The user's personal data, such as credit card numbers, will be backed up to the work repository, and must be protected from all of his coworkers and managers. There should be no key escrow - from the point of view of the user's employer, such data should be totally non-readable and non-writeable. At home, such financial data may well be shared with the user's spouse, but should be protected from their teenage children.

Conversely, work related data may need to be non-accessible to anyone else at home, but shareable at work.

Now consider that the user may be interviewing for a job with a competing company. Obviously, the user will not want his employer to know; if he works for Intel, he will not want his employer to see the Appointment item "Interview with AMD" on his company calendar, but he will want to share that with his wife. Similarly, the appearance of AddressBook^? items for AMD contacts may be telling. Simply marking the item "Private", denying access to all others, is too restrictive.

Further, the user may want to block space out on his company calendar, possibly providing a cover story, aka lie or misleading title. I.e. not only do we wish to control accessibility, but we may wish to control the appearance of such meetings according to who is viewing them.

Conversely, the user may work on projects that he is not allowed to tell his wife about.

Even farther fetched, the user may be having an affair, kept secret from both wife and company. (No, that is not based on personal experience.)

Conclusions:

• no single repository may be a "full backup" or authoritative
• security via encryption should be used in all repositories, in combination with sharing control
• sharing control via access control lists
  • "private" is too restrictive
• sharing control may simply produce "Access Denied" messages, or may change the Apperance of an item

Further consequences:

• an employer may object to providing disk space for a repository holding data it cannot access. Similarly, employers may not want to, indeed, may have a legal requirement, to prevent their data being stored in repositories they do not control. So selectivity about what data gets synchronized where is necessary.

• administering security is a pain. Simple policies controlling the above may be necessary - e.g. "Do not synchronize any company other than my employer on my work repository".

-- AndyGlew - 03 Feb 2003