Showing posts with label Social Networks. Show all posts
Showing posts with label Social Networks. Show all posts

Thursday, September 23, 2010

Privacy across Social Network aggregation

Social Network aggregation is a great personal service that allows me to see updates from all my social networks in one place. There are a number of services that provide this functionality: chi.mp and AOL Lifestream to name two. As long as I'm the only one viewing these aggregations, there are no privacy concerns.

However, the problem arises when content is shared (cross-posted) between social networks and then re-aggregated by the social aggregation service. Take the following scenario as one possible use case.

Alice participates in 3 social networks, statii (a real time micro blogging site), snaps (a photo sharing site), and frendz (a social network of my personal friends). In addition, Alice uses a social network aggregation site called socialview to give her a global view of all her social network activity. All of these social networks allow Alice to establish connections with her friends within those networks. Each of the social networks has it's own privacy mechanisms that allows Alice to share information publicly, or just with a certain set of friends. Even socialview allows Alice to establish relationships with other socialview users and share their aggregated social network activity streams. In addition, socialview allows Alice to cross-post status updates to both statii and frendz.

In this example, all of Alice's micro blog updates to statii are public. In addition, most of the photos she uploads to snaps are also public. On frendz, Alice is a little more careful and only shares information with friends. She does allow friends-of-friends to view her updates and any comments her friends leave.

Now, let's say that Alice uses socialview to post a status update to both statii and frendz. Let's also assume that Alice has decided that all her updates originating from socialview should be public. When Alice's status update appears in frendz, her friend Bob thinks it's relevant and leaves a comment in frendz on her status. Then Socialview, during it's normal aggregation cycle, sees the new comment from Bob and adds it to Alice's aggregated view.



This is where it finally gets interesting. Should Bob's comment be made public (given that Alice's privacy settings at socialview state that all her posts are public, and Bob is commenting on a "public" post?) or should his comment be visible only to Alice (because Bob didn't know he was commenting on a public post).

What I think is missing is a "visibility" scope attribute that needs to be attached to the activity as it navigates across social networks. In the above contrived example, this would allow frendz to make it clear to Bob that Alice's status is really public. It would also allow socialview to honor Bob's privacy settings that he only shares comments with friends when aggregating his comment back into Alice's aggregated view.

Monday, December 08, 2008

Social Networks and Strong(er) Auth

I've been thinking about strong(er) authentication mechanisms recently and the slow uptake by the mass market. I was registering for an online brokerage account recently and was required to enter an email address. I thought through the many email addresses that I use and decided to use the one that has a strong auth mechanism attached.

One of the reasons for this decision is that my ever expanding Facebook world has a lot of information about me that might or might not be relevant to a "password reset attack". I recently found a bunch of childhood friends on Facebook and that has been wonderful. However, it also means that all the information about elementary schools attended, childhood friends, etc is exposed to all my other friends on Facebook. From an information perspective, I don't have any problems, but it does concern me from a security perspective.

Rather than think through what information is available on Facebook, and whether any of that information was used with the "Security Questions" for the email account, I chose to pick an email address that can only be accessed via a 2nd factor authentication mechanism.

So, my question/thought is, "Could social networks be the forcing function that drives consumer adoption of strong(er) auth technologies?"

Friday, September 21, 2007

Trust in social networks and identity protocols

So I've been “noodling” over this analogy for a while. People often complain that protocols like SAML are complex and not scaleable because they require “out-of-band” provisioning. In other words, in deployment something has to happen first, before the protocol becomes valuable. In the case of SAML, this “out-of-band” provisioning is what adds trust to the deployed network (hence the name circles-of-trust). (For all the SAML experts out there, please forgive my simplistic characterization).

One of the big selling points for OpenID is that it does not require this “out-of-band” provisioning and hence is easier to deploy and more “scaleable” (I believe the term is “internet scale”). However, one element missing from OpenID is trust. The ideal is that both OPs and RPs trust the user, but that is a lot of risk for especially the RP to take on in today's business climate.

So how does this relate to social networks? Well, in many social networks, both parties have to agree to the relationship before the relationship becomes valid. This might not be explicitly “out-of-band” but it is similar in concept. For example, if I invite someone to be a friend on Facebook, they don't show up as a friend until they have explicitly approved the relationship. Because of this factor, I am in essence building a “circle-of-trust” that is my friends on Facebook.

The “OpenID” example in social networks is AIM. I can add anyone I want to my buddy list (provided I know their AIM id) and they will be part of my network. I will also see when they are online and offline. The only way for a person to “block” this behavior is to reject presence information for all users except those on their buddy list.

My buddy list on AIM is definitely a social network of “people-I-know” but I don't think I could go so far as to call it a “circle-of-trust”:)

Friday, March 23, 2007

Identity Relationships: User vs Service Provider

There has been a significant amount of discussion and work (People Service, XFN, and FOAF to name a few) around the concept of managing personal or social relationships. These relationships are managed from a user-centric perspective and are really a one-to-many relationship between the user and the identities being managed. This allows the identity of the user to be implied in regards to the other identities and groups (e.g. it is my buddy list). The group structure provides a form of role classification that can then be leveraged for permissions and access control among other things.

However, managing relationships between identities at the service level is a little different. For a service provider the relationship is not one-to-many but rather many-to-many. For example, a hospital will want to manage which patients are assigned to which doctors. A doctor can have many patients and a patient might have many doctors. The existing social relationship mechanisms don't really fit this model as these relationships are defined from a service provider centric perspective. The hospital manages the relationships not the user; though the user is free to leave one doctor and move to another.

Where social relationships tend to be defined in a uni-directional manner (from the user to the other identity), service based relationships are often bi-directional. I don't see this as a problem as it is rather easy to model and implement. However, it is important to distinguish between these two kinds of relationships.

Tags: Identity Relationship, People Service, Social Networks