Jamie Becklandis a digital and social media strategist at Janrain,where he helps Fortune 1000 companies integrate social media technologies into their websites to improve user acquisition and engagement. He has built online communities since 2004. He tweets as@Beckland.
Never completely off the radar, privacy concerns recently stepped back into the spotlight.
[More from Mashable: What Was Super Tuesdays Top Social Media Moment?]
In the past months alone, privacy issues have emerged from all corners. The California Attorney General is twisting arms for better app disclosures, and startup Path apologized for scraping address books. And during February's OpenDialogue, CEO of Thornley Fallis Joseph Thornley claimed that Facebook violates our privacy day by day, because its impossible to give informed consent. But the privacy conversation has shifted in an important way. In the past, identity providers like Facebook and Google were blasted for their obtuse and complicated privacy policies. Questions still remain on that front, but by and large, identity providers have given users more control, and the uprisings have quelled for the moment. Consider the difference in the response to Facebooks 2007 Beacon program vs. the new Facebook Open Graph protocol. The former was lambasted as a gross violation of user trust, was built without disclosure in mind, and was killed. Eventually Mark Zuckerberg admitted that it was a mistake. By contrast, the frictionless sharing capabilities of the new Open Graph protocols have not seen any serious backlash (despite protests from Marshall Kirkpatrick, who maintains that it doesn't make sense to roadblock a link). The good news is that authorizing third parties to use an existing social identity is a one-way flow of information: from the identity provider to the application that the user has authorized. User profile data from a brand website or app is not shared with Facebook, Yahoo, LinkedIn or any other identity provider. Your browsing paths are not suddenly available to social networks, and your behavior after authentication is only available to the website you are actually on. But increasingly, the privacy conversation has widened to ask what apps are doing with the permissions they request, and how the information is actually being used. In order to understand what is actually happening with user data, we need to answer three separate questions.
Different identity providers offer differing amounts of information about a user, and require different access credentials. For example, Google delivers a verified and authenticated email address with a basic permission, while Twitter does not deliver any email address at all. My company has indexed the critical data elements and permissions available on more than 20 platforms. On top of what is available, app developers must determine which permissions and data elements they will request from the identity provider. This is implemented on an app-by-app basis; therefore, users can expect no shortcuts when reviewing the now commonplace permission screens that appear when we authenticate through social channels.
[More from Mashable: How to Allow Subscribers on Facebook]
Users can grant apps permission to access field-level information, but if those fields are blank, the identity provider will return a blank value. For example, if the birthday field is not filled out on LinkedIn, users can still use LinkedIn to authenticate, but the application will not be able to automatically send those users free coffee on their birthdays, for example. This is a crude line of defense, but its important to remember. Even when a list of permissions looks long and possibly intimidating, since people use specific identities for different purposes, some of the data may not be available. And with more identity providers offering distinct views into a users identity, its less likely that a complete picture of a user is available from any app in particular.
Its impossible to know exactly what information gets dropped into an applications database, but the reality is that social profile data is incredibly complicated to store and manage. Even when applications receive a data payload from the identity provider, there's no guarantee that the data is being collected somewhere.
However, any profile data that is presented back to the user within the app experience is clearly being stored. If a user sees a list of her friends who also use the app, its clear that the social graph has been shared to the application. For app developers, then, the decision about what permissions to ask for becomes easy: Only ask for what you will use in the experience you are designing. If there is not an immediate use case, dont ask for permission at that time. Its possible to go back to users and ask for additional permissions and data when they want to interact with a specific experience. Align what the user is giving up (his data) with what you are giving him (a valuable way to use his data). Each user will weigh privacy concerns differently, both for himself and for the brand that is requesting the information. The brand relationship, though, ends up being the most important consideration.
In a complicated environment, with so many privacy factors to consider, users often fast-forward their decisions about whether to share social profile data based on soft factors like brand trust. If a user trusts Coke (or the Washington Post, or Zynga), he will likely assume that the brand will use personal data responsibly and for the users benefit. What brands do you trust with your data?
View original post here:
Social Media Privacy: 3 Questions to Ask Before Authorizing Third-Party Apps