Potential privacy issues arise when summary information is shared on users’ profile pages, but it is undeniably useful to show some information about a person. You should take care that you are not disclosing more than your community might expect you to. The limits to appropriate sharing vary with each site. For example, showing who someone regularly interacts with is probably inappropriate, whereas showing a person’s favorite bands aggregated from listening habits is usually acceptable. And, of course, people are often sensitive about displaying their real-time location and information about their children, for obvious reasons. A basic rule: if you feel uncomfortable knowing a particular fact about another person, tying that data to that person’s identity for public consumption is probably not a good idea.
There are two different contexts for considering privacy. The first is aggregated or summary information. Most listened to, most visited, and most popular are all examples of this kind of aggregation. Commonly, this happens anonymously for central pages, but as noted earlier, it is also displayed on individuals’ profile pages.
The second context is the actual content the people share. Both fall under your control in terms of designing the product. Both require that you have a strong sense of what you are trying to build, and how people will interact with the service.
A piece of information can be public or it can be private. The first case is simple and tends to be what most people design for. Twitter started as a fully public service; privacy was added a few months into the initial development phase. (Private in this case means people with a private account have control over who sees their messages.) Privacy is a popular feature request. Supporting privacy is important, but it is easiest to add it early in the development process so that you do not need to revise large amounts of code to support excluding private items from aggregation pages, search capability, and plenty of other places you’ll discover in testing. Implementing privacy after initial development requires a lot more work than planning for privacy at the outset; I can speak from experience with Nature Network.
Groups and other ad hoc collections of people fall into the gray area. Is an item of content public or private? It depends on who is looking at the page. This is also true for private accounts. The followers of a person become another implicit group of people. There are other groups depending on the structure of your application.
You want to make sure that you have no gray pools of information whose privacy state is unclear. These gray pools sometimes appear because a privacy layer was applied late or because of changes in privacy levels. Different applications take different approaches to privacy. On Twitter, an account is binary: it is private or it is not, but it is possible to change the privacy state. However, if you make an account private, your previously published content will still appear in searches (as of the time of this writing). This is arguably a minor case, but it stems from the original structure of Twitter where everything was public by default, and search was added later after Twitter purchased another company.
On Flickr, privacy comes in several flavors, but it is more closely linked to the content than to the person who posted or created it. Privacy is set per item, not per account. Individuals are granted access to specific photos in an account, not an entire collection. This model is more complicated to understand, but it is substantially more flexible. It is also more appropriate for photography; you might not want to share pictures of your family with everyone, but you are happy to share pictures of a conference publicly.
Ensuring that you put the right information in front of the right person means always knowing and checking who is looking at a page, an RSS feed, or an API call. Failing to check identity in any of these methods for any feature will result in an automatic privacy breach and lots of irritated people. Building identity management into the core of your application makes this a lot easier to do.
Learn more about this topic from Building Social Web Applications.
Building a social web application that attracts and retains regular visitors, and gets them to interact, isn't easy to do. This book walks you through the tough questions you'll face if you're to create a truly effective community site -- one that makes visitors feel like they've found a new home on the Web. Whether you're creating a new site from scratch or embracing an existing audience, Building Social Web Applications helps you make difficult choices.