[ Annotations | Handbook | User Observation ]

Log Sharing and Privacy Settings

To gain acceptance for Nabu and server-side logging in general, it's important to ensure the user's privacy. This means that Nabu must

  1. leave the user in full control over what is logged and what not
  2. give the user the ability to delete sensitive information at any time
  3. Allow access to the archive only over a clearly defined interface that handles authentication and respects the privacy settings
  4. be conservative when it comes to defaults (i.e. disable logging, use restrictive privacy settings)

On the other hand, one of Nabu's goals is to encourage information sharing within peers to make valuable information available to others when wanted. So a privacy model is needed that satisfies both needs, ensuring privacy and making it possible to share conversation logs.

In Nabu, every user is the owner of the message he sent, and he can control who can read his messages or delete them later if wanted. This means that a message is under control of the message sender and only of the message sender. If two users have a conversation, every user is responsible for his own messages and has no control over the messages he received from his dialog partner.

Access control is managed via privacy policies. A privacy policy contains a set of rules that control read permissions by allowing or denying access to certain accounts or groups of accounts. Every message logged has a link to a privacy policy that controls the access to the message. Every user has a list of policies he can assign to logged messages. There is always exactly one policy active at a time. Whenever the user writes a message, Nabu logs the message and links it to the currently active policy. Policies are linked, not copied: For instance, when the user adds a new account to his policy "friendsOnly", the added account gains access to all archived messages that already use the "friendsOnly" policy.

What does it actually mean that a resource is not accessible? When a message (or any resource in general) is not accessible, this means that the resource itself and its CBD is completely hidden from the user: The resource itself and all links from or to the resource are hidden. When querying the model, the resource won't show up in the results. For messages in particular this means that neither the message content nor any links to the message are visible. This includes user statements: If a user statement was added to link the message to a category, the statement is not visible. This is important, because we do not want other users to read the topics we were talking about, even if they cannot read the actual message content.

Privacy Policies in detail

Every privacy policy has

  • a name
  • an owner
  • a set of rules allowing or denying access to an account or a group of accounts

The name is an arbitrary string without spaces, e.g. "default", "friends", "workGroup". In the requests for policy management the name is used to identify the policy. Thus the policy name must be unique for a user (but of course two users can use the same name without conflicts).

The owner is the account that owns the policy. The owner can edit the policy and add or removes rules. The policy always implicitely grants access to the owner, so the owner can access his own messages even if the rules would deny it. It is only possible for a user to change the policy for a message when he owns the currently linked policy.

The rules: A policy can contain any number of rules of the form "allowAccount <accountURI>", "denyAccount <accountURI>", "allowGroup <groupName>", "denyGroup <groupName>". The rules are applied in (deny, allow) order: If access is not explicitely allowed, it is denied. I.e. a policy without any rule denies the access completely (except to the policy owner). If both rules exist that allow and deny access for an account, the deny-rule "wins" and the access is denied.


As mentioned before, access permissions can not only be set per user but also per group. A group is a plain set of accounts, set up by the user to make privacy management easier. For example, a user could set up a group "friends", and add the accounts of his friends to the group. Instead of allowing access per account, he can do a simple "allowGroup friends" and all accounts in the group gain access.


Here are some examples demonstrating how privacy policies are applied. There are five accounts, Alice, Bob, Charlie, Daniel and Emily. Alice is the owner of the policies, and she created a group friends with Bob and Emily in it. (Note that in the implementation, full account URIs are used, but I use Alice instead of http://foo/Accounts/ for clarity here)

policyOwner Alice
allowAccount Daniel
allowAccount Bob

Allows access to Alice (as she is the owner), Daniel and Bob.

policyOwner Alice
allowGroup friends
allowAccount Charlie

Allows access to Alice as she is the owner, friends group, which is Bob and Emily, and Charlie. So just poor Daniel may not read the resource (well, the rest of the world can't either).

policyOwner Alice
allowGroup friends
denyAccount Bob

The first directive allows access to the "friends" group, i.e. Bob and Emily. But as the second directive denies access for Bob explicitely, only Emily has access (and Alice of course).

For more information on how to manage and use policies and groups, read the Nabu Protocol section.

[ Annotations | Handbook | User Observation ]

Last modified 15 years ago Last modified on 07/30/05 23:20:25