SDL and the Unconcerned Pragmatic Fundamentalist

sdl — Fri, 10 Aug 2007 18:52:00 GMT

Rob Roberts here…

We often fear what we don’t know. Take my mother’s casseroles, for example. The initial view scares you, but once you take that first bite, you realize not only that it’s edible, but sometimes, it’s even tasty.

When we meet with product teams in privacy reviews for the first time, we often encounter a team that’s on the defensive. This is typically caused by their fear that we’ll tell them they can’t do something because of privacy concerns. Once they describe what their application does and we begin to give advice, they come to learn that we aren’t out to kill their ‘cool’ software capability, but in fact, have ways for them implement it while at the same time increasing customer trust and confidence.

Designing Software for Privacy

As much as possible, we design our solutions to allow customers to gain the benefits of services without having to give up personal information. An example of this is our online advertising.

For customers with a Windows Live ID (WLID), advertising utilizes a one-way hash of the WLID called an Anonymous ID (AnID), which is stored in a cookie on the customer’s computer. This allows the Microsoft site to collect information about searches and to serve up targeted, user relevant ads without tying a customer’s profile to the searches or ad profile information. Customers gain the benefit of custom advertising without having to set special preferences to protect their privacy.

Inform and Give Control

Sometimes more user information is needed in order to deliver service or capability in a piece of software. Assuming we have user consent, we have a couple of privacy levers that we can adjust to address privacy in our products:

· Disclosure – informing the customer of the privacy impacting behaviors and how to address and control them whenever possible.

· Privacy Controls – settings that allows the user to modify the privacy impacting behavior directly.

Both of these controls can be presented in such a way as to address the varying needs of the three types of people that privacy expert Dr. Alan Westin described in his research, without overwhelming the user with information or choices.

The "Unconcerned" "Pragmatic" "Fundamentalist"

In his research on public privacy concerns, Westin classified the public into three categories: "Fundamentalists", who are distrustful of a company or organization’s collection of personal information; "Pragmatics", who are more willing to share information after weighing the benefits of doing so; and the "Unconcerned", who trust the company or organization’s collection of their information. Westin’s studies (1990-2003) determined that just over half of the people fall into the middle "Pragmatic" category (58%), while smaller percentages fall into "Fundamentalist" (25%) and "Unconcerned" (18%).

Though the "Fundamentalist", we prefer to call them "Privacy Advocate", group is not the majority of the public, their number is significant enough that it cannot be ignored when designing software for privacy. By designing with this group in mind we can build out Disclosures and Privacy Controls that are scalable depending upon the needs of the users at any point on the continuum.

· Privacy "Unconcerned" –

o Disclosure – A simple prominent notice with a link to a privacy statement may be given to assure that the user is aware of how the software may impact them from a privacy standpoint.

o Privacy Controls – Default controls may be set to allow flexible use of the product, such as in the case of IE7 – which is set to medium privacy settings that block certain risky cookie types for users.

· Privacy "Pragmatic" –

o Disclosure – Prominent notices typically include a link to a more detailed privacy statement which allows users in this category to further explore what the privacy impacts are and how they can change them. Layered privacy statements, such as the one for Windows Vista, allow customers to see a summary of the privacy impacting behaviors and give the option to drill deeper into aspects customers may want to learn more about.

o Privacy Controls – Where appropriate, adding variable privacy controls to software allows a user to nuance the privacy behavior of an application. Using the IE7 privacy control example above, this user may move the privacy slider from medium to a higher or lower setting, depending upon their level of concern.

· Privacy "Fundamentalist" –

o Disclosure – Sometimes prominent notice and privacy statements aren’t enough for people that fall into this category. For complex products such as Windows, we published supplemental information such as the Windows Controlling Communication with the Internet whitepaper. This was particularly important to customers in enterprises that must maintain a high level of security in their IT deployments.

o Privacy Controls – In addition to their desire for a detailed understanding of their software’s privacy behavior, a Privacy Fundamentalist typically wants more refined control over the behavior of the application. In the case of the IE privacy settings, going to the advanced options will allow specific control over the types of cookies that may be encountered (i.e. First-party vs. Third-party and session cookies).

It’s this continuum of preferences that helps us understand how we need to build out our software from a privacy perspective. By setting a privacy standard that considers these levers, and implementing them through a consistent repeatable process like the SDL, we can drive our products to be innovative, secure and privacy aware.

Privacy is not just about data security

sdl — Thu, 10 May 2007 20:43:00 GMT

Tina Knutson here...

A few years back we integrated privacy into the SDL. Privacy and security often go hand-in-hand, but they are not the same thing. They often have the same objective, but the focus is different. When it comes to customer data, security focuses on keeping your data safe, while privacy focuses on giving you control.

At privacy conferences and trainings, I’ve run into what I believe is a disturbing trend. In a lot of the events and conversations I’ve experienced, privacy often ends up being used as a synonym for “data security.” Data security breaches are clearly a big concern and shouldn’t be taken lightly; but privacy training, policies, and processes should go much deeper than *just* safeguarding the data. Yes, data security is very important, but privacy should cover so much more.

Anytime we collect your data, we know that the experience can either increase your trust or destroy it. If you understand what’s being collected, why it’s being collected, what the benefits are (to you – not to Microsoft!), and how you can control it in the future, you are much more likely to trust us. In order to build trust when collecting data, we believe that clear and accurate communication is paramount. For example, when Windows Media Player collects information about a DVD you’re watching, it’s better to know up front that this information is used to provide you with media information such as DVD title and cover art. If you don’t know this and have to extrapolate why Microsoft might want to know the DVDs you’re watching, it could seem pretty creepy.

In addition to communication, another privacy concern is minimizing the data collected. It’s all too easy for a product or marketing team to collect data because “it could be useful” one day. My job, and the job of my colleagues in the privacy space, is to make sure that teams know that any use that hasn’t been disclosed in the initial capture of data is off limits. In integrating privacy considerations into the SDL, we’re spreading the word that all of the commitments made at the time of collection apply to that data until it is destroyed. Anyone who uses the data must understand and follow the parameters under which it can be used. When your data is collected specifically to provide a service to you, it shouldn’t be used for secondary purposes, like marketing, unless you were notified of the use and agreed to it when the data was collected. Yes, the data also needs to be kept safe, but that shouldn’t be the only focus.

Privacy is not just about protecting data once you have it; it’s also about minimizing the data collected, and making sure that you know what that data will be used for and consent to that use before your data is captured. This is one of the main reasons Privacy has been built into the SDL. Securing the data alone is not enough.

Read more about how we view privacy in our Privacy Guidelines for Developing Software Products and Services.

-Tina

The Security Development Lifecycle : Privacy

SDL and the Unconcerned Pragmatic Fundamentalist

Privacy is not just about data security