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


International Privacy Day: Synchronicity

Today is International Privacy Day (and also National Data Privacy Day here in the USA and maybe where you are too).  The day is set aside to celebrate the anniversary of the Council of Europe Convention on Data Protection.  Put on your reading list for today both the Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data as well as the Organisation for Economic Co-operation and Development’s Guidelines on the Protection of Privacy and Transborder Flows of Personal Data.

 It’s also, felicitously, the end of the quarter for us here Burton Group, which means that we are trying to wrap up the final edits of our reports and send them off for peer review.  This quarter Bob Blakley and I have been researching privacy.  We’ve talked to a variety of different kinds of companies of all sizes in many industries, and we’ve come away with a lot of lessons.

 Two of these lessons are that privacy is deeply contextual, and that this contextual nature prevents privacy from being easily defined.  Without a strict definition, though, how does an enterprise privacy team proceed?  Can you write policies concerning something which means one thing in one setting and something different in another?  It turns out, we think, that you can.


 I practice martial arts.  Every martial art has a set of principles.  Though these principles may differ, their use is the same.  Principles guide practice.  You practice your art in multiple contexts to prepare you for whatever may come.  In each of those contextualized situations, your principles guide your response.  (Synchronicity moment number one).

 My friend Julie is one of the most amazing corporate and brand marketers I have ever met.  She uses a simple approach in building overall market strategies and brands: identify true corporate values (principles), then let those values lead you to tangible market strategies.  Corporate values guide the formation of market strategies.  (Synchronicity moment number two).

 In our forthcoming report, Bob and I examine sets of privacy principles, but we also look at the ways in which these principles can drive real practice.  We discuss the characteristics and activities of effective privacy teams, too.  In building our report, Bob and I used (self-referentially) this method of letting principles drive practice. We built the report by starting with what we are referring to as Burton Group’s “Golden Rule of Privacy” and let the Golden Rule guide our writing.  You’ll have to wait a bit for the full report (unless you want to be a pre-publication reviewer, in which case please drop me a line!), but I’ll share the Golden Rule with you now:

We protect privacy when we consider the dignity of individuals about whom we know things, and when we use what we know about them only in ways which preserves and enhances that dignity.

 Happy International Privacy Day!  And for those of you attending the IAPP’s Privacy After Hours event tonight in Washington DC, I’ll see you there.

(Cross-posted from Burton Group’s Identity blog.)

Down with federated provisioning

There’s been a bit of recent blogging activity about federated provisioning and SPML.  Having worked on both federated provisioning and SPML in a past life, it warms my heart to see this discussion.  Jackson, quoting the CIO of Education Testing Services, Daniel Wakeman, restates the observation that SaaS providers are providing when it comes to federated identity management.  This “major shortcoming” leaves service subscribers to fend for themselves in managing user lifecycle events like on-boarding and off-boarding.  Not acceptable.

That got me thinking – there really ought not to be a concept of federated provisioning.  Provisioning an application in the data center must be the same as provisioning an application in the cloud.  However, in the course of the conversation between JamesJackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective.

SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn’t make them fundamentally different animals.  The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface.  The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same.

Now there are two reasons that we don’t hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications:

  • We’ve dealt with it so long that pain isn’t as acute
  • Provisioning vendors built an array of connectors, shifting the pain up a level, allowing companies to focus on the provisioning technology and not each and every application they want to provision

Provisioning vendors spent lots of time and money to build connectivity to traditional applications.  Lots.  And in doing so provided a bit of absolution for application vendors from their failing to provide a standards-based provisioning interface.  Having gone through all that pain and suffering, vendors are not eager to go through it again with SaaS applications, coding connectors to each one’s different web service.  Customers aren’t too keen on the idea either.

In providing SPML interfaces to their applications, SaaS vendors would do everyone a service.  Provisioning vendors could use their SPML connectors and not have to build to each SaaS application.  Customers wouldn’t have to write custom code to different service interfaces.

You don’t want that fired sales guy walking away with your customer list no more than you want him walking out the door with your pricing information.  To that end, there should be no reason why deprovsioning from an application like Salesforce.com is any harder than deprovisioning from LDAP.  Federated provisioning should not exist; there is only provisioning.

(Cross-posted from Burton Group’s Identityblog)