Child pages
  • Comprehensive User Privacy BOF
Skip to end of metadata
Go to start of metadata

BOF Session: Comprehensive User Privacy

BOF Description: The current Sakai Privacy Manager takes an optimistic approach where tools go to a service and ask whether a user has elected to be visible or hidden. This BOF will discuss ideas for framework changes to allow institutions to make privacy the rule instead of the exception.


This session is scheduled for Wednesday, June 13th, at 14:00 (2:00pm) in the Basel conference room.


To achieve privacy the current approach requires a user to explicitly choose to be private and requires each tool to be modified to honor their privacy and not display the confidential user information to which is readily has access. This does not allow for institutional privacy policy to be established and enforced and allows tools to display data that should be hidden.

To provide comprehensive user privacy in Sakai, Unicon proposes a couple of core changes to the Sakai framework:

The first set of changes are to modify the User framework (User Directory Service, User Directory Provider, DisplayAdvisorUDP) so that tools that have not been modified to consider privacy will see masked user attributes for users the institution consider confidential/private. The set of attributes to be masked should be fully configurable. This approach treats the default for confidential/private user data as masked and lets tools try to unmask the data as they deem necessary and appropriate.

The second set of changes are to modify the PrivacyManager framework to provide tools with a service for unmasking data. Currently the PrivacyManager answers a simple "Is this user hidden?" question based on the user and site. PrivacyManager should be able to handle requests like "Show me the private user data for this user object given this site + tool + role". Not only does this increase the data with which PrivacyManager has to make decisions (adds tool and role, possibly more) but it also allows for more fine grained results to be returned. For example, maybe an institution feels a student's address should be hidden to instructors, but visible to administrators – a PrivacyManager implementation could be written by an institution to provide that behavior.

To summarize, this proposed set of changes would allow the User framework to provide configurable privacy by default and would allow the PrivacyManager framework to provide controlled access to confidential data.

  • No labels

1 Comment

  1. This sounds like a good suggestion to me ("maybe an institution feels a student's address should be hidden to instructors, but visible to administrators"). I have no idea of the technical implications proposed here. So, what was the result of the BOF?