The danger of social markers made public (more on the Social Graph API)

Thomas Vander Wal makes a good point in response to my post: Why I’m excited about Google’s Social Graph API. He’s concerned that by exposing social relationship information (social graphs), we’re inviting hackers to mine that information and use it in bad ways:

“I do have great trepidation as this is exactly the tool social engineering hackers have been hoping for and working toward.

Most hacks of organizations (most are populated with 98% of people not like us that are more open to social engineering hacks) that have been hacked (been through more than a few of these meetings after the fact) are done through some clever individual using social engineering to convince somebody to trust the hacker. The identification of connections (usually best approached with weak ties) is a great starting point (this is the major reason why most organizations no longer have their employee list or full-contact list posted on their websites).

The Google SocialGraph API is exposing everybody who has not thought through their privacy or exposing of their connections.

This is an excellent point that needs to be considered.

An example of what Thomas describes might be that someone contacts you and pretends to know all the same people you know, and thereby gains your confidence and uses it for evil purposes. (Hugh Macleod calls these shared social objects social markers)

I think this is the same issue that Tim O’Reilly was getting at when he recently said:

“The counter-argument is that all this data is available anyway, and that by making it more visible, we raise people’s awareness and ultimately their behavior. I’m in (this) camp. It’s a lot like the evolutionary value of pain. Search (searching the social graph) creates feedback loops that allow us to learn from and modify our behavior. A false sense of security helps bad actors more than tools that make information more visible.

So Tim is saying that while we’ll probably have issues going forward (some will get burnt), in dealing with them we’ll learn how to expose our own social relationships on the web, which is a skill we’ll need from now on. Forever.

I tend to agree. But obviously this is a complex issue. Whether or not exposing relationship information comes to be an accepted practice, we’ll likely see new norms of behavior spring up.

Not everyone is happy with the Social Graph API. danah boyd has a dissenting opinion. She says:

“Being socially exposed is AOK when you hold a lot of privilege, when people cannot hold meaningful power over you, or when you can route around such efforts. Such is the life of most of the tech geeks living in Silicon Valley. But I spend all of my time with teenagers, one of the most vulnerable populations because of their lack of agency (let alone rights). Teens are notorious for self-exposure, but they want to do so in a controlled fashion. Self-exposure is critical for the coming of age process – it’s how we get a sense of who we are, how others perceive us, and how we fit into the world. We exposure during that time period in order to understand where the edges are. But we don’t expose to be put at true risk. Forced exposure puts this population at a much greater risk…”

While I agree that what danah is talking about is tremendously important, I don’t know why she says that this is “forcing” people to expose their personal relationship information. From my understanding, the Social Graph API is simply aggregating data and providing a means to query it. Now, that certainly makes it easier to find, and that’s an issue (technology is NOT neutral) But isn’t the bulk of responsibility, on those services where code is automatically generated, on the publisher’s themselves? And isn’t it on the individual who publishes their own code?

I have been assuming that publishing personal information would be done by choice. That is, an individual either makes a relationship public or not. If you choose to make it public, you can choose to mark up your information as XFN (or other supported formats) or not. If you do choose to mark it up, then you reap the benefits of the API and services that are built upon it. If you don’t mark it up, then the relationship is public but you keep some “security by obscurity” and your content is seen only in context.

However, there is still the issue that one side of the relationship could publish when the other wants to keep it private. This, in the current Google environment, is treated as a “possible relationship”. It makes a difference if only one side of the relationship is published. This situation may be what danah is referring to, and it does raise some concerns.

But simply publishing this API doesn’t mean that it forces publishers to use the formats without offering some level of control to their users, in fact publishers should give lots of controls around this. Now, if Six Apart and WordPress.com were to tomorrow say “We’re publishing your relationship data in these formats and you can’t opt out”, then that would be a serious problem. I hope that’s not the case, and from what we’ve seen with Facebook and their privacy issues, one would hope that other companies wouldn’t be so cavalier with people’s relationship data.

But I’m reminded again by the age-old saying: “the best way to prevent secrets from getting out is to not have any in the first place”. As technology makes it easier to share information, it becomes harder and harder to keep any of that information secret.