BuddyPress.org

Many people have been inquiring about privacy options in BuddyPress. Some of you are aware that I am currently coding a Privacy Component for BuddyPress. I decided that it is time to fill the community in on my component, providing more details and a timeline.

My Privacy Component will be entering a private alpha early next week. After the alpha phase is complete, it will then be available as a public Beta. If it goes well, and Andy likes it, it may be included in the BP core for version 1.2. If you look at the BP roadmap, you will see that that is when privacy filtering is scheduled to be included in core.

In this screen capture of one of the privacy setting screens, you can see that there are actually six user classification filters that can be chosen for each BP object. The sixth option, “Relationship Mapped”, is made available by a separate plugin which I’ll be releasing later. The default Privacy Component will offer five levels.

My current estimated release date for the first public beta is the week of October 5. This date may change depending on the feedback from the alpha phase.

More Details

This is taken from the Privacy Component’s current readme.txt file:

BPAz is a privacy control component for BuddyPress that provides a site’s users a mechanism with which to control who has access to which pieces of their personal data.

== Description ==

The BuddyPress Authorization component (also referred to as BPAz, BP-Authz, or BuddyPress Privacy Component) is a BuddyPress component that allows users fine, granular control over who has access to which pieces of their personal data. It provides this service by hooking into BuddyPress’ core functionality, thereby giving users the ability to control (grant or deny) access to each piece, or grouping of, their personal data.

The term “auth” is often used interchangeably for authentication or authorization. There is significant difference in meaning between them. Authentication is not authorization. Authorization is not authentication. Authentication must come before authorization. Authentication is handled by WPMU, initially by the registration process and subsequently by the login script. Authorization deals with verifying and managing the access rights a given authenticated user has to certain objects.

Because of this confusion, the process of authentication is now often referred to as A1, or AuthN, or simply Au. The process of authorization is now often referred to as A2, or AuthZ, or simply Az. Since authentication must come before authorization, the A1-A2 ordinality of the terms is evident. This also explains the alternate names BPAz and BP-Authz.

BPAz deals with authorization by verifying and managing access rights an authenticated user has to other’s objects–although a user may choose to expose their data to non-logged in users as well.

The core BuddyPress objects on which rights can be set:

xprofile fields
activity stream actions
friends list
groups list
messaging
blogs
wire
status updates

The basic access levels configurable per object (some objects offer only a subset of these rights):

allow/deny anyone (globally public or globally private). This is accomplished by setting an object’s viewing rights to either “All Users” or “Only Me”
allow only “Logged in Users” to view a given object
allow only friends to view a given object
allow only a specific list of users to view a given object. This is also called per user access control. This is accomplished by setting an object’s viewing rights to “These Users Only” and then entering a comma-separated list of usernames (a member’s login name) in a textbox that becomes visible.

NOTE: Per relationship-type access control is possible if you use my BuddyPress Relationship Mapping plugin. For instance, allow by friend, colleague, partner, client, customer, fan, etcetera.

Site Administration of BuddyPress User Privacy Tools

Site administrators have ultimate control and oversight over the configuration of BPAz’s features and functionality via an additional administration panel under the BuddyPress menu hierarchy. The BuddyPress Privacy Component is enabled by default for all object groupings. However, Site Administrators can disable user-configurable sitewide privacy, or even individual privacy control objects, by using the Privacy Settings administration panel. As the Site Administrator, you will always be able to see each user’s complete content. Users do not have any options to hide content from Site Administrators.

Jeff Sayre, great work, just remember not all our themes are that wide… =(

just remember not all our themes are that wide… =(

Haha!

Since the goal is to eventually have this component merged into BuddyPress core, its CSS is designed to work with BuddyPress’ default theme. It is up to each user to style their site the way they see fit. Anyone with CSS experience will have no problem doing that.

Great and important work for a framework like BuddyPress. Privacy is probably the most important thing for online things in general – people just have not realized that yet.

I’ll be happy to test.

absolutely cool Jeff ! You are my Privacy-Hero !

Thanks a lot for all your effort ! Looking forward to this.

Erich

Since you have an option to allow certain users, do you have an option to block certain users also? Or, can I allow/block specific users while also allowing logged in users/friends?

Maybe I should just wait for the alpha.

Hi Jeff,

what about a Forum-privacy ?
Not sure if this makes sense ?

@jjj

I had considered adding the ability to block a certain user or groups of users but then realized that the selections that are offered do in fact block groups of users by virtue of them not being able to view a given object. For example, if a particular user is bothering you, and they are not in your friends listing, you can make an object only viewable to friends. This, in essence, will block them.

Possibly future versions of the component could enable the grouping of several filter options or even include the ability to filter out certain users. But suffice it to say that the first version offers plenty of options and flexibility.

@Erich73

Since forums are not a core-created object but in fact are objects pulled into BuddyPress from an outside plugin, BPAz will not offer a filtering option for forums. There are simply too many distinct objects that bbPress creates. It truly needs its own privacy filtering system. Therefore, it is up to bbPress to offer such privacy options or a 3rd-party bbPress developer.

Here’s a one-page PDF that shows the 6 access control levels of BPAz:

http://www.sayremedia.com/buddypress/BPAz_Access_Levels.pdf

Coming from an ‘elgg’ point of view, I’m curious if your privacy plugin is going to be similar.

When I create any new item in elgg, be it an image/video/audio/post/etc.. I have the ability to assign the object to a given group at the time of creation.

Meaning, if I upload a new picture, or a new blog post, I have a dropdown permission box where I can set the groups allowed to see the item. (I can select multiple groups if needed).

One thing I absolutely love is I can assign the privacy settings to groups of users.

For instance, I have multiple ‘friends’ groups, ‘coworkers/family/friends/etc’ so when I make a post, I can say that only ‘friends’ are allowed to see it. Or, if I am a member of different ‘groups’, I can assign the permission to members of the given group (that part is really cool)

Basically the permission system is so extensive, that my profile page looks completely different depending upon the permissions of the user visiting my page. (I’ve even managed to take it to the level of custom styles/css on a ‘per permission’ basis)

Of course I can edit permissions on any object after creation should I choose to edit it later.

Is this type of system basically the same as what you are talking about?

The answer is yes and no.

The privacy component is designed to offer users a mechanism to assign access rights (viewing rights) to their various core BP object groupings. It is not designed to let users assign per-item access control to any and all objects. So, for instance as you suggest, at this stage a user will not be able to assign an individual image discrete access rights. Why? Because photos (album objects) are not part of BP’s current core.

Please be advised that this component only provides the assignment of privacy levels to BP’s core object groupings. All 3rd-party components will need to code their own privacy control features–using this component as a model and tying into its access-control table.

Remember that this is a first version Privacy Component, so new features will be added later.

A little more about access control

Typically, Access Control Lists and protocols focus on flexibly setting access rights to resources based on predefined roles (for example: site admin, group admin, moderator, editor, contributor, member, user). This type of access control is more often called, and more appropriately referred to as, role-based access control (RBAC). Role-based AC is necessary when two or more people are involved in the management, oversight, and even ownership of specific subsets of data. This group of people then need to be jointly authorized to perform certain functions.

But BuddyPress is a user-centric platform where there are currently no-jointly owned or controlled subsets of data. Ignoring the overall Site Administrator, in BuddyPress, there is a one-to-one relationship between a given piece of data and a single owner of that data. Even groups (at this time) are owned and controlled by one user. Group Moderators are limited in their power and do not own anything.

The core BP privacy component is what I am calling a light-weight ACL implementation. At some point it may make sense to offer a separate, full-fledged RBAC system but I’m guessing that only a few devs who truly understood such a system would take advantage of it.

Offering privacy control on BuddyPress’ core component objects is more than sufficient.

Jeff, where do I sign up for the alpha tests? I’ve been contemplating the “Members Only” plugin limiting access to registered users. Aside from the question of how it would work with BuddyPress (any experiences with MO?) there is the granularity which your component seems to offer. I want some of my membership site open to the general public, but the core information – profile data – I want to provide access to premium subscribers.

@wordpressfan

The BuddyPress Privacy Plugin offers members the means with which to control who has access to their data. It is a user-focused solution. It is not a component-based solution.

I want some of my membership site open to the general public, but the core information – profile data – I want to provide access to premium subscribers.

It does not offer a Site Admin a mechanism with which to control access to entire BP core components–as you are desiring here. That requires a different approach.

@Anointed

I take it that you are using Elgg 0.9 or at least a pre-1.0 version of Elgg. The granularity of Elgg’s ACL system is brilliant but in my experience of running an Elgg system for two years (https://els.earlham.edu) is that most users do not grasp the power of this system and/or forget to use it when posting to their blog for example. In addition, it seems like most if not all of the access control system has been jettisoned with versions 1.0 although I notice that 1.6 has brought something similar back. But my conclusion is that from the user’s perspective the granularity of access control that elgg provides is over the top — much more comprehensible to have all postings to a group blog be only accessible by the group for example than to have to set access for each individual post. Does this make sense?

Thus it seems to me that Jeff’s conclusion “Offering privacy control on BuddyPress’ core component objects is more than sufficient.” would actually address 99% of what I might need for a college social networking system. Also I want to say that this development is very exciting and definitely encouraging me to move over to BuddyPress. Well done Jeff!

@markpea I am using 1.6.1 so I am not sure what was in or out of previous versions.

My understanding of the permissions system is it has both ‘general’ privacy settings on a per component basis, with the ability for granular override of any given object. Pretty much the best of both worlds. I can set my ‘overall preferences on an object set, and decide to override an individual object should I have the need to.

I can’t think of a single downside to having both systems in place with elgg. Complete privacy control is given to the user for every object, and since it’s in the core, any plugin can hook directly to the permission system to it’s extensible.

Your right, the system for elgg is absolutely brilliant and lightyears ahead of bp in this area. I found that on my network, once I showed everyone the power of granular permission control, that almost everyone started using it instantly. (I did a demo showing how my pages are completely different depending upon the viewers permissions and people loved it).

I would estimate that at least 80-85% of my members are using granular control in one fashion or another.
@Jeff
[quote]So, for instance as you suggest, at this stage a user will not be able to assign an individual image discrete access rights. Why? Because photos (album objects) are not part of BP’s current core.[/quote]

My understanding of bp is nowhere near my level of understanding of how elgg operates, so I use that as a base for my comments. I’m guessing bp is similar in it’s approach.

In elgg, it makes no difference if ‘album objects, or any other object’ is part of the core or not when it comes to privacy. All objects have to pass through the authentication system before they are added to the given page. In fact I’m not even certain a plugin would function properly without passing through the authentication system first, never tried that.

I guess I just don’t understand why this type of system would not work in bp. Is the core really that flawed?

Still I’m glad to see that your tackling the permission system for bp. Imo bp is pretty much useless fodder without permissions.