esjewett.com

Privacy controls are an area of continuing concern in social applications. Michael Krigsman has hit on the point in a sensationalist manner on his IT Project Failures blog in a post titled Twitter is Dangerous. I think Michael is off-base because I think Twitter gets it right by keeping it simple: Your stuff is either private or public. It's hard to misunderstand that.

The important thing is that users of a given system clearly understand the privacy implications of entering data into that system. In order for this to happen, the user interface and explanation within the application have to correspond with the terms of service and technical platform. As I said, I think Twitter gets it right, but others may disagree.

We see a more muddled case with the recent addition of social sharing in Google Reader. Google could have done better with the initial launch of this feature, but to the credit of the Reader team, they got the message and fixed the problem. For the interaction design nerds out there, I think that the problem here was actually not with the sharing feature per se, but with a user/developer disconnect around the privacy implications of "Sharing" an item via a publicly indexed feed with an obfuscated URL. Many users thought of the feed as private while I'm pretty sure the Reader developers thought of the Shared items feed as public.

Let's wend our way to the point of this post, which amazingly enough isn't Facebook's Beacon. No, I'm going to talk about the Plaxo Pulse and a conversation I've been having with John McCrea on Twitter. The situation is that I, apparently, had a misconception about how Plaxo shares my Pulse items when I elect to make them "Public".

Specifically, I thought that making a feed "Public" would broadcast it to all of my Plaxo Connections. Connections on Plaxo are like Facebook Friends, both they and I have to agree to being connections. When you make a connection, you categorize the contact as any combination of business, friend, or family. As such, I assumed that I had exact knowledge of who would receive my Plaxo Pulse broadcasts, though I recognize that the material being broadcast is totally public for anyone who actually looks for it.

I was wrong. What actually happens is (apparently) that anyone who uses Plaxo and has me in their address book receives a broadcast in their Pulse feed of entries I set as "Public". In other words, I have no idea who I'm spamming with these entries.

At the risk of sounding self-righteous, I'm going to blame the Plaxo user interface for this one. (Whew, I feel better already.) Here's why:

1. The copy reading "choose which of your connections ..." clearly indicates that I'm choosing which Connections have permission to see the feed. Plaxo creates a strong division between the Pulse feature and the Address Book feature in their documentation (for example) so when Plaxo says "Connections", I assume they mean it. There is an expectation of consistency in copy across a site.
2. When "Public" is checked, it automatically checks and grays out the business, friends, and family options, creating the possibility that "Public" corresponds to "All of the above" or "All connections". This interpretation is clearly ambiguous and draws on my (fairly common) experience with HTML check-boxes and multiple choice tests, but any ambiguity is probably a bug in a scenario like this one.

I'll be clear that no damage was done here and all of the Pulse feeds I share are public information, so Michael Krigsman can rest easy. For me this is an academic exercise. But it is conceivable, for example, that a client who has me in his or her address book and uses Plaxo was getting spammed by my tweets and del.icio.us bookmarks 10-15 times per day. I'm a pretty public person, at least online, but I prefer to allow people the choice of whether they want to subscribe to a steady stream of my random thoughts. As such, I've un-Publicized all of my Plaxo Pulse feeds. If you want to see 'em, Connect with me.

I think this is a good example of one thing that can go wrong while designing and changing privacy settings. The complexities are similar to other UI problems, but the ramifications in this area are often invisible to the user and the consequences of misunderstanding could be severe. Combined, these two ingredients put the user at the mercy of the developer and this trust should be respected by taking care in design decisions and testing against real user expectations.