Putting privacy controls in the hands of your users

I mentioned yesterday that Bob and I have just finished up some research on privacy.  In this upcoming report, we stress the importance of establishing privacy principles and then using those principles to guide privacy practices.  I happen to see this NY Times article (via Nishant’s Twitter stream) and had a bit of a Baader-Meinhof moment.  The article talks about how social networking sites are giving their end-users more and more control over how information is disclosed.  Giving users choice as to how their information is disclosed and used is important.  Giving users meaningful choice as to how their information is used is much better. 

 One of the privacy principles that Bob and I examine in our report is the principle of Meaningful Choice:

Robbing others of the ability to exercise their free will is an affront to dignity; therefore we allow people to decide how we will use information about them.  When presenting people with choices about how we will be allowed to use their information, we design easy-to-understand interfaces which reduce the possibility of confusing people, and we avoid creating “Hobson’s choice” situations in which people are forced to choose the lesser of a set of evils.

As an ex-interface and product designer, I am especially sensitive to usability and the principle of Meaningful Choice directly addresses this.  Providing an end-user with a difficult to use privacy settings tool and then saying, “Well, we gave you choice as to how your information gets used” exploits the power imbalance between the service provider and the user.  As the interaction between the user and the service provider become more and more valuable (moving from social networking to, say, electronic health records), such an exploitation is less and less acceptable.

 In the course of our research we talked to one company who spent many months trying to get their privacy settings interface right.  They brought people (non-techies even!) into their usability lab and studied how these user set (or didn’t set) privacy settings.  The design team fully acknowledge that building a usable, meaningful interface for privacy settings was hard but considering the context, the effort was required.

 

 End-user privacy controls are mandatory.  But in the absence of a usable interface, end-user control is not control at all. 

(Cross-posted from Burton Groups Identity Blog.)

 

Combining business and IT roles has a strange familiarity

Kevin Kampman has added his opinion to latest RBAC thread.  Kevin makes an interesting point:

Another challenge is to clarify what a role represents. A business role is an articulation of a business relationship or responsibility. A technical or IT role is a set of privileges or tools that are used to accomplish the business role. Business roles map to IT roles. If you try and merge the two into one, you come up with an IT role. It becomes difficult to ascertain what it was or is intended to accomplish, and it becomes inflexible, bound to an application.

This reminds me of Alan Cooper’s The Inmates are running the Asylum.  Cooper makes the point that anything coupled with a computer becomes a computer.  This includes but is not limited to: alarm clocks, cars, ATMs, and naval warships.  (Come on admit it, you too have ripped a hotel alarm clock out of the wall because you couldn’t figure out how to shut it off; we’ve all done it.)  Cooper’s overall point is that the Designer must be extremely careful in her design choices so as to not lose the intent and spirit of the original object before it got coupled with a computer.

The same holds true in Identity-land.  Identity program teams must be clear with each other and the enterprise as to their goals for roles.  If they are looking to strengthen the organizational structure itself, then business roles, in a stand-alone fashion, are what is called for.  If the teams want to deliver permission aggregation into coherent policy, then IT roles are needed.  That being said, if an identity program team finds itself swirling the two together, they have likely hamstrung the advantages they sought to gain, inappropriately using roles to solve all of the problems of context and intent.

As the team at Burton Group furthers the conversation about relationships, I think we (the collective we of enterprises, vendors, and service integrators) will see that the challenges of context and intent are addressed by relationship management and that roles, both business and IT, have a part in addressing those challenges.