Brandon Mechtley

Security is key in social web design. It is necessary to create a system that is impervious to intrusion. Identity theft, communication interception, exploitation of APIs, and other issues related to security are important across the full gamut of the life cycle of a social web tool. It’s not enough to simply implement the proper encryption and handshake procedures at a low level. There will always be situations where a person is able to access information he or she is not supposed to, even by logging in as another user (angry exes, clever friends, and so on).

Apart from having separate passwords for every possible activity on a site, there aren’t many options that can enforce fool-proof security. Instead, it’s necessary to design a tool in such a way that these security breaches will have minimal impart or not need to occur. One way to limit the impact and occurence of security threats is to simply make users’ data completely available and actions so benign as to eliminate the desire to access another’s account or personal information. Obviously, this isn’t much of an option, so another option might be the other extreme, which is to design a lack of security into the user experience.

In The Transparent Society, David Brin makes the bold claim that reciprocal transparency amongst individuals will create situations where both the act of maintaining privacy and the act of invading one’s privacy will be public knowledge, leveling the playing field and resulting in a more trusting society across the board. By having a social framework that enforces equal transparency, he argues, privacy can be maintained through a system of mutual trust. (I’ll talk about this a little more later in a general post about whether or not we should even care about privacy.)

Similar to Brin’s idea of reciprocal transparency, we can have reciprocal insecurity–by allowing everyone to have access to modify and have access to everyone else’s data, and by having proper notice and a detailed history of this activity, we eliminate the problem at its source. To some extent, this is the case in wikis, such as Wikipedia. By introducing accountability into the mix, Wikipedia is able to create a collaborative online community that has a natural system of checks and balances. Of course, this system is not by any means fool-proof and is heavily influenced by the amount of activity that any given page sees, but this is an assumption that readers of Wikipedia either have or should be given. However, since Wikipedia still features user accounts for accountability, there’s still motivation to gain access to someone’s account for illegitimate purposes.

There’s no perfect solution to security in design, but at least we shouldn’t ever entertain or spread the idea that our systems can be completely secure. Boasting of security may be desirable for marketing purposes, but it hurts the market at large as security breaches continue to invalidate our claims.

Different services require different types of security, as they involve the use of different kinds of data, some of which are less personal or identifying than others. I’ll talk about this spectrum of Anonymity and Pseudonymity next.