Designing Privacy-Aware Applications

Designing Privacy-Aware Applications

Whether you're creating Web services or client-side applications, privacy should play an important part of your strategy for success. It will improve your customer's confidence in your products and set you apart from the competition. When designing an application, look at your design from two perspectives. If you're building an application that collects information from a user, be sure to adhere to the seven tenets of Safe Harbor (described earlier in this chapter). If you're creating an application that enables others to collect data, have you added features to permit users of your application to store their customers' privacy preferences? The remainder of this chapter will look at how to develop software with privacy in mind and give examples of privacy features that will add value to your applications.

Including Privacy in the Development Process

As with security, you save time and money by focusing on privacy throughout the development process. The privacy advocate for the team should understand your process of developing software and be able to devise a plan to make sure that privacy fits into the process seamlessly. Figure 22-3 offers an example of a development process that includes privacy.

Figure 22-3. Including privacy during the development process.

During the design phase, the privacy section of the design template should be reviewed to ensure that the important privacy design points have been covered. During the development phase, the privacy content, such as the privacy policy and any P3P (Platform for Privacy Preferences) content for your Web sites, should be created. (I explain P3P later in the chapter.) Also, the contents of all cookies, logs, and any data sent to the Internet from your application should be documented and a statement of how they are used should be created. During the test phase, testers should validate your privacy implementation and content; this should include working with the privacy advocate to review the wording of any documents you created. The review phase should include a privacy review of each component and should be attended by the privacy advocate. During intermediate releases such an alpha, beta, or Release Candidate, you might get feedback from customers, analysts, or the media on your privacy implementation. Feed this back into the design phase, and make the appropriate changes to your products.

Privacy Specification Template

The privacy specification template should be part of the overall feature design template used by your development teams. Use the privacy specification template to outline any privacy issues that exist with a feature and the plans to mitigate them. The more thorough you are flushing out privacy problems during this phase the more smoothly the review process will go at the end of the development cycle. This area of the feature specification should be reviewed before approval of the feature. Your privacy advocate should work with your design team to create a specification template that matches your development requirements. See the sidebar The Privacy Specification Template for an example.

The Privacy Specification Template

1. Privacy

This section is used for describing privacy impacts, which are part of this feature, that might expose a user's sensitive data or browsing habits. Also, any data that is sent from the user's computer system should be documented. Privacy features should be documented as a normal feature and not described here. Does your feature store or share any sensitive information? If so, answer the following:

• How is the data used and by whom?

• How long is the data stored?

• What value does the user gain from this?

• Does the user have the ability to view and modify the data?

• Is the user's permission explicitly given before storing the data?

• What end-user settings apply to how the data is stored and used?

• Is access to the data protected?

• Is the data encrypted?

• With which third parties will the data be shared?

1.1 Client-Side Component

If this feature is part of a client-side component, answer the following: Does your feature send data to the Web for any reason? Describe in detail the contents of the data that is sent, when the data is sent, where the data is sent, and why the data is sent. Does the user have the ability to select whether they want this data sent? If so, what is the default? If the default is not off, explain why on is acceptable.

1.2 Web service component

If this feature is part of a Web service component, answer the following: Does the Web service have a privacy statement associated with it? Where is it archived? Is it registered with the corporate privacy group? Describe the contents of any cookies that you create and their purpose. Describe the contents of any logs that you keep. Include any unique IDs. Has P3P been implemented for the Web service?

Privacy Review Template

The privacy review template is used to review the privacy aspects of a component, which may consist of several features. Here is where you ensure that possible privacy risks are mitigated. All privacy content and settings should be accounted for. The privacy advocate should drive this portion of the component review. Any action items that come out of this review should be resolved before release of the product. A full sample template can be found with the book's sample files in the folder Secureco2\Chapter22.

Privacy Policy Statement

The privacy policy statement applies to Web sites and applications. Create one for each application or service you're planning to deploy. Your corporate privacy group, which should include your legal and public relations departments, should review this policy during the review process of a product. The policy should be reviewed again for each successive release, including service packs. The privacy policy should address each of the seven tenets of the Safe Harbor Principles, where appropriate.

This is an important document, and a current copy should be kept with your corporate privacy group for tracking. The TRUSTe Web site (http://www.truste.org/bus/pub_resourceguide.html) describes how to create a privacy statement and shows examples. Microsoft's privacy statement can be viewed at http://www.microsoft.com/info/privacy.htm.

P3P Content

The Platform for Privacy Preferences Project (P3P), http://www.w3.org/P3P, is a standard that was defined by the World Wide Web Consortium (W3C). It was developed to permit Web sites to define their privacy policy in a manner that can be easily consumed by individuals and applications. Why should this interest you? If you use Internet Explorer 6, you may have seen the small eye on the status bar with the do-not-enter icon, as shown in Figure 22-4. That's evidence of P3P at work.

Figure 22-4. The Internet Explorer 6.0 privacy eye.

When the icon shows up, it indicates that the Web site does not comply with your privacy settings. Either its privacy policy conflicts with the one you setup in the browser or it does not have one at all. These sites will not be permitted to place cookies on your computer. Other browsers also have P3P features that provide warnings of out-of-compliance Web sites. Your Web sites should implement P3P such that a P3P warning is not displayed with the browser privacy setting set to Medium. Defining P3P for your Web site goes hand-in-hand with creating a privacy policy and is easy to implement. See the section on implementing P3P coming up.

Exploring Privacy Features

When designing your application, you should be forever vigilant about respecting your customer's privacy. Part of that respect will consist of making it easy for your customer to indicate her preferences. The other part will be thinking of clever ways to defend her preferences. Remember that most of the time the people infringing on users' rights are people who have legitimate access to data. This section will investigate different ways to record and protect a user's privacy preferences.

Implementing P3P

Hopefully you've read about the importance of implementing P3P for your Web site. First we'll look at how P3P works, and then we'll see how easy it is to implement. To see how the P3P feature works in Internet Explorer 6, go to any Web site by using the Internet Explorer 6 browser and select Privacy Report from the View menu. For Web sites that have not implemented a privacy policy by using P3P, you'll get the display shown in Figure 22-5.

Figure 22-5. Privacy Report when P3P is not implemented.

For Web sites that do have P3P implemented, you should see a display similar to that in Figure 22-6. You have to admit that having a Web site that shows this display is going to make your customers feel more comfortable. Having the TRUSTe icon is an added bonus that will add to your site's credibility.

Figure 22-6. Privacy Report when P3P is implemented.

The first step to creating P3P content is to create the policy reference file. The reference file is used to point to the XML policy file for your site. It must be named P3P.xml and stored in the directory W3C below your Web site root. For example, Microsoft's reference file can be found at http://www.microsoft.com/w3c/p3p.xml. Here's an example of an XML reference file:

<META xmlns="http://www.w3.org/2000/12/p3pv1"> <POLICY-REFERENCES> <POLICY-REF about="Policy.xml"> <INCLUDE>\*</INCLUDE> <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/> </POLICY-REF> </POLICY-REFERENCES> </META>

When Internet Explorer 6 is attempting to display a site's privacy policy, it looks in the W3C directory of the Web site for the file P3P.xml and reads the POLICY-REF tag from the file to determine the location of the XML version of the site's privacy policy file. This is the second file that you're going to create. It represents a condensed version of your full privacy policy.

Below is a sample of an XML version of a privacy policy. The discuri attribute points to the full privacy policy for the Web site. It can be accessed from the Internet Explorer 6 display by the here link. The remainder of the fields in the file are parsed by Internet Explorer 6 and placed in the report window. The statement blocks at the bottom of the file represent the privacy statements for the Web site that describe how data is handled. This particular example has two policy statements. The first one indicates that standard Web log information along with the browser type are stored by the Web site. The data is kept for administrative and development purposes for the recipient's use only and retained for stated purposes. Visit http://www.w3.org/P3P for a full description of the other fields.

<POLICY xmlns="http://www.w3.org/2000/12/p3pv1" discuri="policy.htm"  opturi="http://msdn.microsoft.com/privacy"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">Microsoft</DATA> <DATA ref="#business.contact-info.postal.street">One Microsoft Way </DATA> <DATA ref="#business.contact-info.postal.city">Redmond</DATA> <DATA ref="#business.contact-info.postal.stateprov">WA</DATA> <DATA ref="#business.contact-info.postal.postalcode">78052</DATA> <DATA ref="#business.contact-info.postal.country">USA</DATA> <DATA ref="#business.contact-info.online.email">michael</DATA> <DATA ref="#business.contact-info.telecom.telephone.intcode">1 </DATA> <DATA ref="#business.contact-info.telecom.telephone.loccode">425 </DATA> <DATA ref="#business.contact-info.telecom.telephone.number"> 8828080</DATA> </DATA-GROUP> </ENTITY> <ACCESS><nonident/></ACCESS> <STATEMENT> <PURPOSE><admin/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.clickstream.server"/> <DATA ref="#dynamic.http.useragent"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <PURPOSE><pseudo-analysis required="opt-in"/></PURPOSE> <RECIPIENT><other-recipient/></RECIPIENT> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA ref="#user.home-info.postal.postalcode"> <CATEGORIES><demographic/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY>

This file can be placed anywhere on your Web site as long as it expressed in the reference file. Once you have these two files in place, Internet Exlorer 6 will be able to display your policy in the report screen when users select View->Privacy Report. You will still want to create a full privacy policy for your Web site that describes your company's privacy policy in detail. For assistance with creating a full privacy policy, visit the TRUSTe site at http://www.truste.org/bus/pub_resourceguide.html.

The final piece to the puzzle involves creating the compact policy. The compact policy is what Internet Explorer 6 uses to determine whether to display the privacy icon on the status bar. The compact policy is a condensed representation of the XML policy and uses codes defined in the P3P specification. You can read more about compact policy at http://www.w3.org/TR/P3P/#compact_policies. Figure 22-7 shows the compact policy for the XML page shown above. Once you have the compact policy in place, you will have fully implemented P3P. For a detailed description of how to implement and deploy P3P for your Web site, visit http://msdn.microsoft.com/workshop/security/privacy/overview/createprivacypolicy.asp.

Figure 22-7. Setting a compact policy in the Internet Information Services (IIS) admin tool.

NOTE
Internet Explorer 6 suppresses P3P verification for Intranet sites.

Privacy for Client-Side Applications

When building client-side applications that capture a user's information, you should have a privacy statement that describes how the data will be handled and you should provide the user with settings to set her preferences. For example, you might collect registration information from the user or send data to a Web site to download background information for your application. You could configure your Help menu to assist the user in accessing privacy commands. If you provide a software development kit for your application for other software developers, a Privacy Policy menu option could point to a document referenced in the registry or, better yet, to your privacy policy on your Web site. A Privacy Settings menu option could call an interface in a DLL that could be implemented by the developer.

Figure 22-8 shows the privacy options dialog in the Microsoft Windows Media Player 9 beta, which is displayed to the user when the application first runs.

Figure 22-8. An example Privacy Options dialog.

So far the examples have covered the case where your application collects personal information on behalf of your company. What if your application collects data users of your application obtain from their customers? Say you're building a Customer Relationship Management application. The users of the application will probably collect contact information from their customers. How will they determine whether these customers want to receive e-mail? You could add a privacy settings dialog box to permit them to store their customers' privacy preferences without having to create a separate database. Figure 22-9 shows a dialog box for collecting contact information. Figure 22-10 shows one for setting privacy options.

Figure 22-9. Collecting customer data with an option for setting privacy options.

Figure 22-10. An example Privacy Settings dialog box.

Cover Your Tracks

Many applications have features that keep track of files you've opened, Web pages you've visited, or media you've played. What if a user didn't want that information tracked or wanted to be able to clear it when he wanted to? Adding such a feature could help your users sleep better at night.

Let's make believe that the Detroit Lions are your favorite football team. This season the Lions are losing all their games, and after each game you go on a tirade around the house complaining about the loss. It gets so bad that your family has had enough and you are ordered to stay away from football. No TV, no Internet, and no conference calls with friends to commiserate. Later in the season you find out that the Lions are going to the Super Bowl! (I did mention that this was make-believe!) So late that night, after everyone's asleep, you sneak down to the basement, go to the Lion's Web site, download some streaming media of the last game, go to a chat room, and start celebrating with your online friends. Then you hear footsteps coming down the stairs and it's your spouse. With a cover-your-tracks feature, you could easily press a button, close down all the applications, and bring up Solitaire without anyone knowing what you were doing.

If your application does record the last used files or sites visited, make sure that it does so on a per-user basis and that this information is stored either in HKCU or within the user's profile.

Don't Phone Home

Windows Media Player 7 caused some problems by sending information about music CDs and DVDs to a server at Microsoft. The idea was to retrieve the list of songs from a central database and help ensure a nice user experience. The problem comes when someone might be viewing a movie that they may not want others to know about. One obvious example is adult-oriented material, but another you may not have considered is material of military value. Some behaviors are just fine when you're dealing with an ordinary home user, but if traffic is coming out of a military base, it could be another matter entirely. If your application is going to send any type of data back to servers controlled by your company, make sure that you notify the user, allow them to opt in or out, and allow the administrators to disable the behavior for all users on that system.

Protecting the Application from the Application Users

You are at a large conference and about to announce the latest version of your financial application. So far the industry pundits are raving about your new privacy features. Then an analyst asks one last question: How do you prevent the application administrators from running off with the customer's money? In today's climate, you better have a good answer. After putting the finishing touches on your privacy features, ask yourself again, Now how can they get to the data? When you feel the answer is, They can't, bring in an outside specialist, give him administrative privileges to the network and your application, and dare him to read a credit-card number. If this scares you, it might be because you're using only security techniques and not privacy techniques. In this section, we'll look at various ways to keep the good guys from gaining too much access.

Limiting access to your application

Many users will have legitimate access to the data stored in your application, and that's okay. When analyzing access requirements, start by making sure that only legitimate users can access your application or data. The network administrator should not necessarily be your application administrator. Then you'll want to control the level of access that each user has. Just because a person needs to send e-mails to customers doesn't mean that person should be able to see credit-card numbers. And if you do it right, credit-card numbers will never be visible to users. Think about being able to make the statement, Your credit-card numbers are never visible to our employees! We'll get to that later. Now take a look at Figure 22-11; notice how access to an application can be progressively screened. Don't give people an opportunity to betray your trust. Security should not just be about read, write, and delete access. When building an application, look at building workflows that can isolate sensitive information and transactions.

Figure 22-11. Limiting access to sensitive data.

Leaving a paper trail

When users have access to sensitive information, they will be tempted to view it. One way to curb their temptation is to add auditing. When adding auditing to your application, ensure that it also tracks read accesses. The audit logs should be backed up frequently and should not be able to be deleted. Yes, this is hard. But imagine if you were selling the only application that offered this feature! It's worthwhile notifying users that their actions are logged.

Privacy Through Obfuscation and Encryption

Damaging the reputation and trust of online commerce is the fact that hackers have been able to compromise servers and steal credit-card numbers or other valuable customer information. Rather than storing data in plaintext, you should encrypt sensitive data by using a good cryptographic algorithm, and a well-protected key.

Protecting the Transfer of Data

Now that you have the data secure, you should also look at transferring the data securely. Look at the flow of data from its origin to its final destinations. Are all paths secured against information disclosure threats? We've covered various ways to secure communication traffic in this book; here I just want to remind you to include communication security as part of your end-to-end solutions.

Putting the Pieces Together

You've got security in place: auditing is turned on, and the communications links and data storage are encrypted. What else do you need? How about encryption between partners and insurance that only the data that is necessary for the transaction is transferred? If a person's social security number and birth date aren't needed for transactions, don't send them. If possible, don't even collect the information. Work with partners that think the way that you do about privacy. Build solutions that use the minimum amount of information, and reveal it to as few people as possible.

NOTE
If your company works with untrustworthy partners, people will view your company as untrustworthy also.

In Figure 22-12, a user fills out a form to purchase something over the Internet and provides credit-card information. The client request is transferred over SSL/TLS to the Web server. The Web application encrypts the data and sends it to the database server optionally over IPSec. If the data is already encrypted, you may not need to encrypt the application-level payload. The application on the database server stores the encrypted data in the database. When the order needs to be filled, the credit-card information is sent to the processing center over EDI (Electronic Data Interchange) in encrypted form by using a key known to the company and the EDI center. The credit-card processing center is able to decrypt the packet and make the appropriate transfers. In this manner, no human being ever sees the credit-card number unencrypted. There is a small risk if you have a phone order center or if a customer needs to verify an order after placement. Strong auditing procedures can mitigate risks in these areas.

Figure 22-12. Limiting access to sensitive data on the wire.