[Jeff Sayre]

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.

[gerikg]

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

[Jeff Sayre]

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.

[bpisimone]

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.

[abcde666]

absolutely cool Jeff ! You are my Privacy-Hero !

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

Erich

[John James Jacoby]

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.

[abcde666]

Hi Jeff,

what about a Forum-privacy ?

Not sure if this makes sense ?

[Jeff Sayre]

@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.

[Jeff Sayre]

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

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

[Anointed]

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?

[Jeff Sayre]

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.

[wordpressfan]

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.

[Jeff Sayre]

@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.

[markpea]

@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!

[Anointed]

@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.

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.

[David Lewis]

@Anointed: It’s not that the core is “flawed”… it’s that BuddyPress is simply a plugin that sits “on top” of WordPress MU while Elgg is an integrated solution. Personally, I still prefer BuddyPress. The theming process in Elgg caused me great pain and I find the Elgg interface suffers from inconsistencies and poor usability.

[David Lewis]

Like wordpress fan… I also need a solution that shows different components to registered vs. non-registered users. I can’t launch without it. Unless we build to separate sites… but I really don’t want to do that. The “public” (non-members) should basically only see the main blog’s posts, pages and events. Everything else needs to be hidden until you log in. I guess a bit of PHP might fake it just by hiding navigation options. In fact, there is a thread on the forums about that. I was assuming that the new privacy module would make that information moot however.

[David Lewis]

Replying to myself… I did a forum search and this should do the trick. A simple plugin to make BP components only visible to logged in users.

https://buddypress.org/forums/topic/plugin-to-show-components-to-registered-users-only#post-18381

[Jeff Sayre]

@David

One step at a time. My Privacy Component is a user-centric solution. It is not currently designed to offer Site Admins a way to selectively exclude certain classes of visitors. Perhaps in a future version that could be added, but I do not see that as being of primary importance to a site’s users.

@Anointed

As David says above, there is nothing “flawed” with BuddyPress. BP is still in its infancy. It has a ways to grow but has come a very long way in a short amount of time–thanks to the wonderful spirit and contributions of BP’s open source community!

In fact, in my opinion, BP has a much stronger core foundation, a far superior support and developer community, and is significantly more flexible and easier to customize than Elgg. But, let’s not start a platform war here. This is a BuddyPress forum and suggestions to improve BP are always welcome.

You of course are free to choose whichever platform best suits your needs. But a full-blown ACL system, although possible, is not necessarily practical.

As far as the specifics of access control in BP, please reread my post above:

https://buddypress.org/forums/topic/buddypress-privacy-component-an-update#post-23815

[David Lewis]

@Jeff. That’s cool. I can just use a simple plug-in to block out groups, etc. wholesale. Like that code Burt did… just using is_user_logged_in(). It’ll do for now.

The issue is, I want to use BP as a kind of simple, lightweight “Intranet”/communication tool for our local Search & Rescue group. We’ll mostly use groups and/or bbPress to discuss fundraising, training, recent searches… etc. As well as look up members in the directory. Etc. All that stuff should be just for members. Some of it can be sensitive info. But we still need a public face for news, events and static info (faq, about, photos, etc.)

Two sites (a WordPress site for the public and a BuddyPress site for members) might make sense… but there’s overlap. All that public stuff needs to be available to members as well (pages, posts, events). So having two sites would be kind of a nightmare.

But I digress!!! As I say… I’m sure I can hack something together. Since I’m just hiding entire classes wholesale… it should be simple enough with a bit of PHP. Not sure how events will work though.

Anyway… very much looking forward to the privacy component as designed. Even thought it’s not what I thought it would be… and won’t do what I had in mind… it sounds like it’s actually a lot more impressive than that.

[Anointed]

@David –

Quote:

Personally, I still prefer BuddyPress. The theming process in Elgg caused me great pain and I find the Elgg interface suffers from inconsistencies and poor usability.

I couldn’t agree more with you on the theming issues. Elgg is more like drupal, anything is possible, but the learning curve is beyond steep and straight up hill imo. Of course in it’s current state bp isn’t much easier, though that is going to change bigtime with 1.1. As to the interface, well that can be changed as well, but it’s a huge amt of work. We actually got about 90% finished making an exact ‘clone’ of the theme used for bp on this site. I just got sidetracked on other projects so didn’t complete it yet.

@Jeff – I’m definitely not trying to start a platform war. The only reason I even brought up elgg was as an example of what can be accomplished and a system that I absolutely fell in love with when I found it. In the case that you had not seen the code from elgg, I was simply trying to give an example is all.

My foundation is and will remain wpmu. That is why I keep coming back every few days to check on bp progress. Your privacy plugin is going to make bp usable in many instances where without it bp would not even be an option. I applaud you for the work on this, and the devs behind bp itself. I agree it’s an amazing platform considering how young it is.

I think my request for granular object control has been made pretty clear. I just wanted to get my 2cents in whether it’s accepted or not.

peace

[David Lewis]

@Anointed Ha! I was doing the same thing! Trying to make Elgg look like BP. Funny. I worked on it for about a week before giving up. I couldn’t deal with the 100’s (okay, dozens) of CSS files (that are actually PHP files so you can’t use live CSS editing tools like Coda or CSSEdit for Mac… ARGH!). Plus I was finding I had to override a lot of core files to make it look and act the way I wanted… which didn’t sit well. I agree that Elgg is more advanced in terms of features… but I just didn’t want to deal with it. I also decided that although BP is newer and not as complete… it has a brighter future. My prediction. I could be wrong.

[Jeff Sayre]

@Anointed

I’m definitely not trying to start a platform war.

Lol! Yes, I do recognize that. I said that because by me taking an obvious side in my post above, I was basically starting one myself!

I appreciate your desire for a full-blown ACL. It is a possibility in the future. Some of us have talked about it in length. In fact, I originally started my privacy component with this in mind until I better understood what was really needed. So, I do have a few hundred lines of code already put away toward a separate ACL system. I’m guessing that if it were to be finished, that it would more than likely be a separate plugin, probably not a core component–unless Andy decided otherwise.

If it were to be a core component, it would add 4 additional tables to every BP install. Since most sites would not utilize full-scale RBAC, it would create superfluous bloat. By keeping it as a plugin, those few Site Admins or developers that desire to offer such item-by-item object authorization could choose to do so if they wanted.

[Anointed]

@David – you aren’t kidding about theming elgg…. major pain is putting it nicely. Frankly the theme engine is lightyears ahead of wp, if and only if you are a master at oop, php, css etc… There are serious advantages to having the ability to style each object independently but it comes with an obvious price.

@Jeff – Well if it’s not obvious already, I’m definitely interested in your full-scale RBAC as I am sure many others would be once they understand the power behind it. Simply pm me anytime you need someone to ‘tear it apart’ during beta LOL…. I’m a master at breaking things.

Between this plugin and Justin Tadlocks roll manager plugin that he just released my wpmu world is looking like it has a very bright future ahead.

[Trent Adams]

Great job Jeff!

[wordpressfan]

@David: thanks for the pointer; I had increased security within minutes of following that link.