Powered by Elgg

Josie Fraser :: Blog :: Permissions granularity ABC

March 29, 2008

http://feeds.feedburner.com/~r/Socialtech/~3/260352920/permissions-

Lolcat783278

Picture credit: Peek-a-boo by Annie in Belziers, Lolcat title added

I'm almost sure that's my most boring title to date, but hey, please feel free to refrain from reliving any duller former glories.  Anyhow, I should have two fantastic launches to celebrate soon, both of which will be of interest to people using, providing or running social networking services, so I'm going to thrash out a few of the issues I've been mulling over recently, prior to whatever trumpeting heralds my blog budget will run too.

Granularity in this context refers to the degree of choice users have about sharing their information- the choices a site member can makes over who gets to see what information and data they upload or create on site. Most services offer basic permissions within broad friend categories - you can share all your information with no-one (private), with all friends (friends in this context meaning people who you have approved/included on your contacts list), or with everyone (the public - this may be the broader site membership but usually refers to the internet viewing public).

The more granular the service, the more flexibility members have over what is made available and to who. The level of permissions granularity for any given piece of social software can actually be expressed quite simply:

who can see stuff x what kinds of stuff they can see = level of granularity

Permissions granularity is made up of there two main sub sections: the who and the what.

As outlined above, the who baseline permissions extend to three broad categories: myself (private), friends (privileges), or everyone (public). Of course across sites and services there are variations on these permission sets – Flickr for instance provides you with two levels of people you have given permissions too, labeled friends and family. Some services allow you to divide your friends list into sub-groups of your own making, so that you can label them and, in theory, manage who gets to see what more effectively.

The what refers to your stuff – blog posts, audio visual files, status updates and activity logs. So how granular the permissions are in this respect refers to how finely you can control the size of bits that you want to make available or restrict access too. So at the chunky end of the scale, you may only be able to make every thing public, private, or available to yoour pre-approved list. In the middle, you’d be able to assign viewing preferences to all of the different categories of activity and assets. Very granular services would enable you assign permissions make each individual post, update or whatever.

However, life isn't this simple. Unless permissions are easy to understand, use, and change, most users will fall back on whatever the site defaults are, or to setting up their own defaults and leave permissions management at that. Any transparency about management is obviously further complicated by the increasing use of third party widgets and services into the mix.

Overly complex granularity, like an indiscriminate friends list, leaves users in the same fall back position – ignoring permissions controls because its easier.


Posted by Josie Fraser


Comments

  1. Interesting.

    Popular economic utility or preference theory pundits might have something to say. If we (widely we = society/the world) move towards mesh networks and away from trusted (commercial/institutional) intermediaries we have 2 more dimensions to the granularity equation: routing and (federated) authentication/access.

    There is the granularity of who sees what of my stuff/me

    Then there is: who will I route for, i.e. I will extend the courtesy of sharing my bandwidth but not my databases.

    Finally there is who will I vouch for.

    I am not sure if this gets stacked:

    • vouching
    • routing
    • public sharing

    Private shares  (friends) I vouch for and route for?

    George RobertsGeorge Roberts on Sunday, 30 March 2008, 19:22 BST # |

You must be logged in to post a comment.