Brandon Mechtley

Yes, I’m satisfied. (see: Choice and Consent, Proximity and Locality, and Templates. Three birds with one stone. Some users might want a white list instead of a black list, but I won’t begrudge Facebook this point.)

Almost. The news feed is still curiously noncooperative, but assuming visibility on the news feed is inherited from visibility in the profile, this shouldn’t be a problem. This ambiguity is a result of lacking proper Notice of proximity of effect. LinkedIn’s “View my profile as others see it” button could still be useful for Facebook’s news feed. There are also still a number of items, such as status updates, that are absent from the news feed configuration.

I’m sure this has all been said before and will be said again.

I’ve been making some observations about a BitTorrent community that’s having a lot of troubles getting off the ground. They have a 30:1 seeder:leecher ratio, which they wear like a badge. Everybody’s giving, no one’s taking. That’s good right?

Not really. I think the administrators are oblivious to what’s actually going on. This ratio makes it incredibly difficult for new users (i.e. poor people) to get started. On communities where the ratio is more balanced, you can usually start out by leeching popular content and seeding it back to the rest of the community. With such a high ratio of seeders, you have to compete with every other member of the community, which makes it impossible. In a given day, with the most highly active torrent, you can expect to have uploaded a total of 1MB–maybe.

A user’s best bet is to hunt down a smallish torrent that has more leechers than seeders. As I’ve said, these don’t really exist. There are a few out there, but most of them are extraordinarily large (> 12GB) which is too much of a risk. This particular service introduces ratio requirements at around 5GB. One idea would be to start leeching one of these larger torrents and then stop a smaller amount in, only seeding. I don’t know the nitty gritty details of how BitTorrent works, so I’m not sure if (besides availability) there are any biases in which chunks are chosen for uploading (such as order within the file), but assuming it’s uniformly random, if you only have a small percentage of the actual file, the probability that someone actually needs something from you is quite low. I haven’t had any success with this at all.

So occasionally the administrators will throw “free leech” torrents out there to stimulate things. Other communities have tried entire weeks of free leeching on all content. This helps a bit, because it temporarily stimulates the economy, but if the underlying model isn’t sustainable, these aren’t going to help matters much. No new member wants to wait for the next free leech, and since the rate of new users coming into the site is rather low, once everyone has the free content, no one’s going to be left to download it. You’ve just momentarily given a boost to people’s ratios. It doesn’t help much. It’s like tax rebates. No–I take that back: it’s like printing money.

The real problem that I see is hoarding. Most people in the community, in the face of rather draconian ratio requirements, will hoard their ratio as much as possible. Since the ratio of the community (ignoring free leech) is a closed system, this causes a great imbalance that can blow up over time. The net ratio of the entire community is constant at 1.0 (ignoring free leech), so your best bet is going to be evenly distributing everyone’s individual ratio to 1.0. A little socialist, I admit, but that’s what’s going to make things work best. There needs to be a motivation for hoarders to spend their ratio.

The easiest way I’ve thought of doing this is to make ratio a depleting resource for the individual. Use It or Lose It. To keep it a closed system, and to better benefit the community, hoarders’ KB uploaded will be slowly redistributed evenly to the community over time. Similar to an income tax. Different from an income tax, however, this has serious advantages both for the hoarder and everyone else. Rather than punishing hoarding, you’re actually encouraging activity. By requiring that people continually try to maintain a 1.0 ratio, you’re encouraging people to increase their total uploads and downloads, which will allow them to download larger content in the future without having to worry about changes to their ratio. Older members of the community are still valued for their past contributions in that their ratio is more or less invulnerable, but new members are still supported by a thriving community.

There are other benefits to this. By encouraging people to actively download, you’re also ensuring the wide distribution of less-than-popular content, which helps support the long tail of community interests.

As with any new media paradigm, user generated media and the social web have undergone quite a bit of public scrutiny. Blogging is fighting to distinguish itself as a valid source of news and discussion apart from traditional journalism, Wikipedia is fighting the age-old battle of the validity and trustworthiness of information on the Internet, and podcasts and videocasts are attempting to distinguish themselves as viable sources of entertainment and information apart from television, to name a few issues.

The age of widespread participatory media is continually undergoing definition and situation into society. Many of these outlets for expression and communication are only at the tip of the iceberg in terms of user base, though. Although the number is quite significant, why is it that only one third of teens using the Internet are actively sharing content? What are the teens who are producing content but not sharing it doing with their work? What about adults? These numbers may be enough to make social web companies see financial success, but in terms of bringing about a new age of media production and consumption, there is still a long way to go.

Almost every single milestone in Facebook’s expansion of its userbase has been the result of an outcry amongst its users. Within Facebook, several user groups were organised to protest the decision of expanding its services to high school students. Similarly, but to an even greater extent, Facebook’s decision to allow anyone to create an account, regardless of affiliation, still remains a hot issue. Facebook’s business model had two other large milestones in 2007. In May, Facebook released its API that allows third-party developers to access personal details of users and create applications embedded within the Facebook site. In November, Facebook introduced a new targeted advertising model that includes Beacon, a system that shares purchases made by users at participating third party sites with their friends. Initially, Beacon was an opt-out service, requiring a confusing, explicit opt-out process for every service.

One might ask: who’s in charge of these decisions at Facebook? Why is it that every major change in Facebook is met with such tremendous backlash? In the case of Beacon, Zuckerberg himself had to issue a public apology. One guess might be that this behaviour is one of the natural growing pains of developing new modes of media distribution and communication. Another hypothesis, which I’ve attempted to confirm in my previous posts, is that there are fundamental design flaws of the current state of the social web that are preventing major, rapid innovation.

Privacy is one of many issues that is holding the social web back and preventing it from realising its true potential. At one extreme, there are still people who don’t like having any information about themselves available on the Internet. We need to cater to larger audiences.

It’s all about letting users reduce and alter the large space of what they think the product is doing. When you don’t give users immediate, clear feedback that tells them what you’re doing and when you don’t allow users to choose how they want their information distributed, you’re going to be met with an enormous, resilient possibility space that is going to not only scare users away, but frustrate them to no end.

Privacy is important. Communicating privacy is important. This isn’t an issue that we need to just let someone else figure out for us, and even if it were, we aren’t giving anyone the tools to do so. If we don’t allow people to choose how they want to be seen on the web, we’re never going to be able to have any kind of dialog about privacy.

And that’s the end of my rant.

Contact Templates.

As an example of the danger of large possibility spaces in content use by social web tools, I mentioned that Facebook has several different points of privacy configuration across multiple, predefined user groups. There exist several ways that these possibility spaces can be reduced. One method is through user-generated privacy templates.

As mentioned with respect to proximity and locality, there are some social web services that allow users to define custom user groups to whom certain settings apply. For example, in LiveJournal, a user is able to create groups from a list of all his or her friends and use these as the target of limited-access posts. In Pownce, the same is possible for defining recipients of microblog entries. In this way, users can specify, for example, that they wish certain information to be visible to their coworkers, certain information to be visible to their immediate family, and so forth. There is no need for people to explicitly define their relationships with their friends in terms that the system can understand (as in Facebook), but they are able to use these templates in the future. Templates get past the necessity of requiring explicit user consent for every action taken, as consent to publish to certain users in implicit in their previous definition of the user group, which is presumably given some unique identifier that the user can remember, e.g. “coworkers” or “family.”

Facebook recently added contact templates, but so far they see pretty limited use across the site. As opposed to privacy, they seem to be used to simplify tasks such as inviting friends to events.

The only downside to these contact templates is that they have to be constantly maintained. When a user has many publishing groups with heavy overlap, this can become problematic. However, the benefit gained from avoiding the uncertainty associated with the all-or-none decisions of predefined, high-level user groups such as those in Facebook far outweighs this. If these templates are introduced into the tool properly, they don’t need to be cumbersome for the user. Facebook already provides a great implementation of this maintenance through allowing users to specify relationship types when they add a new friend. Unfortunately, these relationship types are predefined (rather arbitrarily) and not integrated into the functionality of the system in any significant way. The list of relationship types may as well be removed now that the Facebook has added custom user groups. About the only place they see use is in the timeline view that shows when you met certain people, which I’m not sure anyone actually uses.

Behavioural Templates.

Another possibility for templates is a behaviour template. There are many cases when users simply don’t want to publish particular types of content to anyone at all. Similarly, there are cases when users don’t want to be informed about certain content published by others. These types of decisions can be simplified through behavioural templates. For example, some members of social networks may be more interested in forging business relationships than they are in keeping in touch with friends. Allowing for these differences in preferences to be stored in behavioural templates can help the user develop a conceptual model of the system that is more consonant with how it will actually behave. Of course, it’s necessary to develop notice into any system with templates–a user should always know exactly what effect the template is having on his or her communication preferences. Integrating template selection directly into the methods used to choose communication preferences is a safe way to ensure users will understand exactly what these present templates mean.

Then again, a theme of developing new technologies is that they will always be used in ways the developer didn’t foresee. With predefined behavioural templates, the possibilities for use cases and applications of a tool are limited. This limitation can be overcome somewhat either through close personal monitoring of trends in user activity or by learning the templates computationally (what are those aspects of users’ preferences that most discriminate between different sets of users?) Any computational solution will introduce certain threats to user trust, however, as the templates will, by definition, not be reliable. Even if the template only changes user preferences when a user updates them, one still risks confusing users with changing definitions.

OK, so I’ll wrap up this disorganised rant in my next post.

If all else fails, users need recourse for unwanted use and distribution of their information. Along with this, users always need accces to their information and how it was used.

In situations of security breaches, for example, there should be some recourse someone can take that is specific to security breaches to clean up any unwanted damages. Low level design decisions such as keeping detailed records of changes to a user’s information (analogous to version history) can help designers and support staff build these mechanisms into a tool’s framework. Although issues of notice prevent a user from knowing whether or not his recourse is actually effectual, Facebook provides the ability to selectively remove listings from the mini-feed as recourse for mistakenly publicising actions. In some cases, recourse and notice could even be implemented in such a way as to allow user to undo unwanted communications by notifying them if the recipients of their messages have received anything and allowing users to “unsend” messages if the recipients have not (a feature common to many groupware solutions.)

Although access and recourse do work well as fail-safes, they should be integrated into any design regardless of whether or not they are deemed necessary by failure in any of the other principles of privacy awareness. Simply giving users the ability to correct potential misuse of their information can be key to gaining their trust and allowing them to have a richer, more comfortable experience.

So that’s the last principle I’ll mention. Next, I’ll talk about templates, which can be a great way of abstracting away many of the scope and practicality issues involved in the last few posts.

Anonymity refers to the complete absence of any information tying collected data to its source, while pseudonymity refers to being able to retain the uniqueness of data sources without explicitly providing any information about what or whom those sources represent. With a strong implementation of one of these principles, data can be legally collected without requiring user consent. While the legal implications of social web design are certainly interesting, one could potentially argue that anonymity reduces much of the effectiveness and usefulness of the social web.

On the contrary, however, a decision about anonymity should be present as early as the initial conceptualisation of any social tool. Often, to reap the rewards of the web, disclosure of identity is not at all necessary. MySpace is able to perform as a successful social network without requiring users to identify who they truly are and anonymous blogging has been the boon of teenagers across the globe.

In fact, anonymity can often be expanded even further. In some situations, it’s not necessary to even associate information with a unique identifier for the person to whom the information belongs. Oftentimes it’s not even necessary to have a social design for a tool to work. Google News, for example, performs collaborative filtering to suggest news items to users based on the news read by other users who are most similar to them. Nowhere is there a necessity for a reader to identify a particular suggestion with a source with or without an anonymous identifier (in fact, the suggestion usually comes from a combination of a multitude of sources), but the user is still able to leverage the structure of the community to his or her benefit.

Of course, it’s oftentimes desirable to link an explicit identity with a user. In some cases, we even want to have a user disclose his or her real identity, as this can require a certain level of commitment from the user. In the case of social networks, Facebook and LinkedIn have been forerunners in this regard. Facebook benefits from attempting to require users to give their real names in that the tool maps real world networks of friends, which helps emphasise its existence as a communication medium that can augment unmediated relationships. LinkedIn, of course, bases its entire functionality off the disclosure of professional information, as it is a site made for the formation of new business relationships. With this requirement comes a great deal of responsibility, however, as a service not only has the capability of allowing a user to sully some of the relationships about which he or she most cares, but also raises questions about how information is being used by the company collecting it. After all, the reasoning for Facebook being based around real names is convincing, but could there be ulterior motives? There are certainly many conspiracy theories hovering around both Facebook and MySpace, but users have no recourse to assuage those fears in Facebook’s case.

Finally, it should be noted that anonymous identifiers are not always an end-all-be-all solution to having a fool-proof social web design, either. While they do provide a recourse for users who make mistakes or are confused about the operation of the service, they only do so inasmuch as the user does not define himself in terms of his new identity. In cases where anonymous identities see long-term use (such as the case of internet monikers, online forums, or gaming communities and virtual worlds), it would not be intellectually honest to assume that these relationships are any less important to a user than those which are not mediated by the social web. Even though members of these communities are not necessarily at risk of injuring their relationship with the law, employers, or their basic human needs, the social bonds created between anonymous users ought still be protected, unless the users enter into the relationships with the understanding that they will not be.

I’ll talk a bit about Access and Recourse next: what do we do when these guidelines break down?

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.

Proximity refers to the distance from which information can be collected, and locality refers to the areas in which this information is used. In ubiquitous computing, these topics are typically understood in terms of the physical world. For our purposes, these two concepts have virtual analogues in social web design. Proximity often affects the acceptable locality of information use. In the case of Beacon, for example, information collected from a third party vendor was relayed to Facebook. In terms of proximity and locality, Facebook was acquiring data from a distance far too great.

A key feature behind the social web (and the web in general) is that it allows for large leaps in both proximity and locality, so we wouldn’t want to assume that these two concepts should be limiting. Rather, they should be understood in terms of other privacy aware principles, and be used clues for finding deeper problems. Going back to Beacon, Facebook faced problems with surprising all their users’ notions of the capabilities of the web. Proximity and locality are concepts that can be used to predict these surprises. Most importantly, the locality of the information should never be unknown, but should always be communicated through proper notice, preferably before any action is taken.

There are some services that implement custom locality for users, such as those that allows people to create custom friends groups (e.g. LiveJournal, Pownce). Revisiting choice, direct manipulation of locality by users is an extremely powerful way of providing them with notice of the destinations of their information.

Next will be “Adequate Security.”

Consent.

Even if you communicate to a user that you’re using his or her information in some way, it’s still necessary to acquire specific consent to do so. This principle is often only understood in terms of what information legally requires consent from a user. Often however, one’s actions have ambiguous consequences, once again increasing the possibility space.

If proper notice exists in a tool without an adequate level of consent, a situation may arise where users are perfectly comfortable with their current state of disclosure but approach interacting with the tool with a high level of anxiety. Result previews (notice), paired with consent at every step can assist in assuaging any anxieties. If it’s undesirable to have an interaction that requires constant interruptions for consent, certain commonplace features such as allowing users to set defaults (e.g. “never ask me this question again.”) can be employed, although these interventions should be minimised to avoid the setting bloat explained earlier. One way to minimise the amount of consent required is to group features with similar consequences. In extreme cases that simply do not allow for consent, a designer may fall back on Recourse, another principle which will be explored later.

A good example of consent can be found in most blogging services, where a user has the option to preview an entry before posting it, or in some cases, such as the Wordpress software, has the ability to save it as a draft as well. Drafts allow for requiring consent without breaking the flow of interaction, as a user is not forced to make a decision immediately.

Going back to the easy example, Facebook has met several problems with consent, the most obvious being the recent mistake of making its Beacon service require strange service-by-service opt-out requests. When the model of how user information was used changed and became dissonant with user assumptions, users spoke out or simply stopped using Facebook. What is particularly interesting about the Beacon incident is that users’ concepts of Facebook were not only changed in terms of how the service works, but were also changed in terms of what Facebook, and the social web in general, is capable of doing. Without explicitly creating a connection between a third-party service and one’s Facebook account, information was capable of being transferred from one to the other. This hidden interoperability and ubiquity has been as of yet unseen on the web by the vast majority of people. It came as a complete surprise.

In this case, as social web technology is a concept emergent from the services that comprise it, it’s not possible for it to require any explicit consent from users for it to change its model. Therefore, it is only natural that such development will come as a surprise and heighten anxiety for many. Altering a society’s conceptions about its own capabilities is a fundamental aspect of technological progress, which is one reason why it is so important that developers of these cutting-edge tools approach them with the utmost care. An explicit opt-in policy from the start would have saved Facebook some hassles, but it would not have completely eliminated the anxiety that comes with new potential. However, introducing such a service in a more considerate manner may have helped people realise that these new opportunities are more exciting than they are frightening.

Choice.

Even with an appropriate level of consent, you still don’t maximise the usefulness of your tool. What does someone do if he doesn’t give you consent to wantonly throw his information around the web? A lot of things requiring our consent in the world are black and white: whether or not you release your rights to something, whether or not you agree to the Terms of Service, etc. What’s a user’s recourse if he doesn’t like the ToS? He won’t use the software.

This leads us to the most important caveat when it comes to Consent: Consent must not be presented as an ultimatum. For every user that agrees to an ultimatum, you’ve probably lost a few more. There ought to be smarter ways to design software such that several user types (or Templates, as will be discussed later) are supported.

Sometimes this isn’t really a possibility, especially when it comes to legal liability centred around the theme of your application. Plus, having software that appeals to everyone might be a bit unrealistic for those developers who value pragmatism a little more than nobility. Either way, we should be cognizant of this and apply more choice where we can. Should I only be able to publish something to the entire world, or maybe just my friends? Should I have to give something to all my friends, or just some of them?

More choice allows users to personalise their experience to behave more like they would expect it to, which is pretty much a free lunch: rather than trying to get the user’s model to more closely match the system, you can simply let the system adapt to their model, without having to pull any psychological tricks or try to guess what they’re thinking. There are obvious trade-offs with the overall complexity of the system, however, and one thing you cannot control is that users change and users forget. Some people’d even say that users aren’t sure what they want. So needless to say, there’s a proper balance that has to be maintained by more choices and simply more notice of the consequences to which users must consent.

In some cases, choice can be abstracted to easily describe a large variety of choices , which can help in those cases where a user can’t be expected to remember every choice he’s made. This is a reductionist strategy that I’ll explain when I talk about Behaviour Templates.

Next on the list is Proximity and Locality.

Some of Facebook’s more controversial decisions: introduction of the news feed, opening up the service to high school students, opening up the service to everyone, third-party application development, and Beacon. These are also the major changes in Facebook’s business model. Why is it that every major change is met with such tremendous backlash? Zuckerberg had to publicly apologise for the Beacon fiasco.

It seems like there must be a better way to reflect these changes in the design such that the transition is much smoother. This is not simply a public relations problem where users need to be convinced that there is legitimate use for a particular change, but it is a problem of changing aspects of the system to meet the goals that inspired those changes while also maintaining the current level of privacy and users’ perception of it.

I’m going to use Facebook as a case study for all my suggestions (i.e. complaints). So first off is . . .

Notice.

Notice involves telling people upfront that information about them or their actions is being used in some way. I’d say this is one of the most overlooked principles in the design of social web tools, and it’s also maybe one of the most important to implement. In terms of one’s understanding of a system, there are generally a myriad of possible mental models, some which are more accurate than others. Proper notice is just a way of minimising that possibility space to more accurately represent the actual system.

Consider Facebook and MySpace. As I see it, when it comes to personal disclosure, the key difference between these two sites is that Facebook is much more private. MySpace profile pages can be accessed by people who don’t have accounts, whereas Facebook creates a complex structure for who is or who is not able to view a page. Additionally, Facebook allows users to specify how and what information is presented to others, depending on his or her relationships with them. Facebook allows configuration of privacy settings for:

1. every third-party application installed
2. personal information in the profile
3. status updates
4. videos
5. photos
6. online status
7. friend list
8. wall posts
9. seven different pieces of contact information
10. email address
11. application visibility in the profile

Multiply that by being able to set visibility to:

1. no one
2. only one’s self
3. only one’s friends
4. a specific set of networks one belongs to and his or her friends
5. all of one’s networks and friends
6. everyone

This probably makes for over 100 different possible profiles for the average user with a few applications. Needless to say, Facebook profile visibility is a complex system.

Given all the controls users have over their profiles, it’s unreasonable to expect them to remember how they have configured these settings or that they have manually configured the settings in the first place. Facebook applies defaults upon registration, but a user must visit a privacy control panel to tune these parameters. It can easily be imagined that many users will approach use of the service with great uncertainty, as at any given point, they cannot be sure who is viewing their profile and what these people will see. After all, the only way someone could know for sure what someone else can see is by logging in as the other user or pouring through their privacy settings. (Or by creating a series of dummy accounts, like I’ve done.) LinkedIn has a perfect, painfully simple approach, as seen in the image.

Not only does this uncertainty contribute to a fear of the tool, but it also significantly reduces its usefulness. The power behind a configurable social networking tool that protects your privacy, such as Facebook, is that it allows users to freely express themselves in front of private, controlled audiences and allows them to use this expression and disclosure to their benefit through discovery of new information about their local and extended networks. Unfortunately, when privacy-conscious users are confronted with uncertainty concerning the publication of their personal information, they will disclose according to what they would be comfortable sharing to the broadest audience imaginable given the notice of the system.

With MySpace, on the other hand, there’s more or less only one possibility for the information users share on their profile pages: complete disclosure to the entire world. This limits the usefulness of the tool in terms of discovery and self expression for privacy-conscious users, but the design is so limited that users are always implicitly confronted with notice of how their information is being shared with the greater audience. This notification is crucial to making users comfortable with the software, and it is most likely why the debates surrounding privacy on MySpace (issues of security, social issues of what people are willing to share) are of a much different variety from the debates surrounding privacy on Facebook (students unwittingly showing pictures of drinking parties to potential employers, changes in privacy model). MySpace users are able to have much more reliable, precise assumptions of the system, whereas Facebook users’ assumptions and desires are most likely quite varied and ambiguous.

A personal example of poor notice on Facebook is that I can never tell if items I hide from my mini-feed are also going to disappear from my friends’ news feeds (or how long that’s going to take, if they do.) In terms of communicating with my friends, I can’t even be sure that my posts and updates will show up on their feeds. Result? I give up and send them a message on Facebook or email them. My model?

Make update -> MAGIC -> Uncertain distribution of my update

In the case of the dating application, my friend probably would have thought twice had he been able to see an accurate preview of the application’s news feed entry. In general, previews are a good solution if you can’t think of anything better. As seen in the image, LinkedIn is a perfect example of how effective and painfully easy adding previews is.

Drafts, previews, reducing or combining configurable parameters, and reducing or combining viewing scenarios are all great, easy ways to give users proper notice of what you’re doing with their information. In reality, especially for complex sites like Facebook, the solution is going to be much more domain-specific, and in most cases, there will be no single Best Solution. Your best bet will be to go with your gut and try to minimise confusion as much as possible. Paying close attention to use cases is always necessary. If you have the resources, user studies may also be appropriate. Try to figure out what models people are making of your system.

Next up will be Choice and Consent.