Privacy violations occur when:

1. Private user information enters the program.

2. The data is written to an external location, such as the console, file system, or network.

In this case, the data is saved to the physical Android device using the SharedPreferences class.

Example 1: The following code stores user preferences using Android's SharedPreferences class. Among other values that are stored, the user supplied password is stored on the device in plain text.

SharedPreferences userPreferences = this.getSharedPreferences("userPreferences", MODE_WORLD_READABLE);
SharedPreferences.Editor editor = userPreferences.editor();
editor.putString("username", userName);
editor.putString("password", password);
...
editor.language("language", language);
...

Although by default an instance of Android's SharedPreferences is private to the application and cannot be accessed by other applications, physical access to the device could potentially allow access to these files. Furthermore, in Example 1, setting the mode to MODE_WORLD_READABLE makes the preference file available to other applications, further violating user privacy.

Many developers trust the file system as a safe storage location for data, but it should not be trusted implicitly, particularly when privacy is a concern.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Typically, in the context of the mobile environment, this private information includes (along with passwords, SSNs, and other general personal information):

- Location

- Cell phone number

- Serial numbers and device IDs

- Network Operator information

- Voicemail information

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

With autocompletion enabled, some browsers retain user input across sessions, which could allow someone using the computer after the initial user to see information previously submitted.

The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) attack is a type of side-channel attack that allows attackers to steal sensitive information contained in HTTP responses transferred over an SSL/TLS-enabled channel. All existing SSL/TLS versions and ciphers are susceptible to this attack. If the following three conditions are met, an attacker may successfully conduct a BREACH attack against the application:

1. The application transmits a secret (for example, an anti-CSRF token) in the response.
2. The application reflects a user input in the same response containing a secret.
3. The web server is configured to use HTTP compression.

The size of a response compressed using gzip is determined by the amount of repetitions observed within its content. Thus when characters are repeated more often, the smaller the response size becomes. This allows an attacker to use the HTTP compression as an oracle which can indicate whether a guess supplied by an attacker to the application through the reflected parameter value is correct or not. If the guessed character matches the corresponding character in the secret, the size of the compressed response is smaller. The attacker may use this process to obtain the entire secret character-by-character through the analysis of the compression ratio for each request.

An attacker may use this technique to extract a secret from the HTTP responses even if the application is configured to serve content over a secure channel.

To evaluate whether the application is vulnerable to the BREACH attack, first review whether the application is configured to enable HTTP compression. If so, for each response containing a secret to be protected, evaluate whether a user input is included inside it.

This issue is reported because the Django application is configured to use CSRF tokens and GZip compression:

MIDDLEWARE = (
  ...
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.middleware.gzip.GZipMiddleware',
  ...
)

Always treat the California driver's license number as private information. This information is susceptible to theft if it is transmitted, stored, or processed in an unsafe manner. Access to legitimate driver license numbers can lead identity theft.

Privacy violation occurs when:
1. A California driver's license number enters the program.

2. The California driver's license number is written to an external location, such as the console, file system or network.

Transmitting the driver license number over an unencrypted channel, hardcoding personal information inside the application code, unencrypted storage of the license details in insufficiently protected back up files are some of the potential causes that might give an attacker access to a victim's California license number.

The license information can be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging of the license information can also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you must record all important operations so that any anomalous activity can be identified later. However, when private data is involved, this practice can in fact create risk.

California law SB-1386 regulates the handling of private information such as the driver's license number.

Always treat the credit card number as private information. This information is susceptible to theft if it is transmitted, stored, or processed in an unsafe manner. Access to legitimate credit card numbers can lead to the identity theft.

Privacy violation occurs when:
1. A credit card number enters the program.

2. The credit card number is written to an external location, such as the console, file system or network.

Transmitting credit card information over an unencrypted channel, hardcoding it inside the application code, unencrypted storage of credit card details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's credit card number.

The credit card information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging practice could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

Collection and management of private information is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization might be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Database connection strings can be revealed through:
1. Detailed error messages returned by an application that fails to handle all exception conditions
2. Hardcoding connection strings inside client-side code in cleartext
3. Passing connection string information in query parameters
4. Storing connection strings in configuration files in cleartext
Attackers can use the information leaked in database connection strings to gain direct access to the target database, steal sensitive information, corrupt database entries and inject malicious scripts to infect visitors to the application or disrupt the application availability.

Disclosing personal email addresses constitutes a violation of an individual's privacy under the EU General Data Protection Regulation (GDPR).
The EU GDPR replaces the Data Protection Directive 95/46/EC, and is designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens' data privacy, and to reshape the way organizations across the region approach data privacy. The GDPR provides a framework for organizations on how to handle personal data.
According to GDPR Article 4, personal data "means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person."
Personal email addresses identify an individual and constitute personal data. Generic email addresses such as admin@somecompany.com or info@somecompany.com do not fall under GDPR as they do not identify a particular individual.

The mobile application includes coordinate data representing the device's geolocation in a request to an external host. A device's geolocation data is considered private information since it can be used to accurately pinpoint the location of the device.

While location data can be transmitted to an external host legitimately as part of the core functionality of an application, one must verify that the application has obtained proper authorization from the user to do so. An application that makes external requests that include device geolocation data must clearly enumerate the reasons for doing so to the user, especially if this data is sent to third-party vendors or advertisers. Failing to do so is a clear and unacceptable violation of the user's privacy.

Leaks of private health information occur when:

1. User's health information enters the program.

2. The data is written to an external location, such as the console, file system, or network.
Example 1: The following code retrieves the user blood type from the HealthKit store and sends it to a server, while logging it to the device. Although many developers trust the log files as a safe storage location for any and all data, it should not be trusted implicitly, particularly when privacy is a concern.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    NSLog("%@", blood.BloodType);

	var urlWithParams = String.format(TOKEN_URL, block.BloodType);
	var responseString = await client.GetStringAsync(urlWithParams);
    ...

Note: The Apple Logging API, which is at a lower level than the NSLog function, allows a developer to create an app which may read all logs on the device (even when they don't own the other apps).

Other areas of concern for maintaining the privacy of user data arise when a device has been lost or stolen. Once in possession of an iOS device, an attacker may access a great deal of data by connecting the device by USB. Files such as iOS Property Lists (plists) and SQLite databases are easily accessed and can disclose personal information. As a general rule, private health details should not be stored unprotected on the file system.

Example 2: The following code adds the user's blood type to the list of user defaults, and stores them immediately to a plist file.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    // Add blood type to user defaults
	NSUserDefaults.StandardUserDefaults.SetString(blood.BloodType, "bloodType");
    ...

In response to private data being mishandled, the collection and management of private data is becoming increasingly regulated. In regards to health information, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [2]

- Gramm-Leach Bliley Act (GLBA) [3]

- Health Insurance Portability and Accountability Act (HIPAA) [4]

- California SB-1386 [5]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Sensitive data (such as passwords, social security numbers, credit card numbers, and so on) stored in memory can be leaked if memory is not cleared after use. Often, Strings are used to store sensitive data, however, becauseString objects are immutable, only the JVM garbage collector can remove the value of a String from memory can only be done by the JVM garbage collector. The garbage collector is not required to run unless the JVM is low on memory, so there is no guarantee as to when garbage collection will take place. In the event of an application crash, a memory dump of the application might reveal sensitive data.

Example 1: The following code converts a password from a character array to a String.

private JPasswordField pf;
...
final char[] password = pf.getPassword();
...
String passwordAsString = new String(password);

HTTP requests which utilize the GET method allow the URL and request parameters to be cached in the browser's URL cache, intermediary proxies, and server logs. This could expose sensitive information to individuals who do not have appropriate rights to the data.
Example 1: The following code makes an HTTP request using the GET HTTP method instead of POST.

...
	NSString * const USER_URL = @"https://www.somesvr.com/someapp/user";
...
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
	[request setHTTPMethod:@"GET"];
...

Example 2: If the application uses NSURLRequest then the default HTTP method is GET.

...
	NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.apple.com/"]
                        cachePolicy:NSURLRequestUseProtocolCachePolicy
                    timeoutInterval:60.0];
	NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self];
	if (theConnection) {
    	// Create the NSMutableData to hold the received data.
    	// receivedData is an instance variable declared elsewhere.
    		receivedData = [[NSMutableData data] retain];
	} else {
...

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning Apple ID.

The NSURLCredentialPersistenceSynchronizable attribute implies the distribution of the credential and its storage in the Apple's cloud environment. Depending upon the privacy requirements of the application, storing the credential in the Apple cloud environment may not be acceptable.

Example 1: The following snippet of code creates a synchronizable credential that will be distributed to other devices and iCloud:

    ...
    NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 
    ...

Privacy violations occur when sensitive data is persisted to disk in an unencrypted format.


Example 1: The following ASPX code instantiates a DataVisualization control that generates a graph of sensitive financial information from the XML Data Source SensitiveXMLData:

        <asp:Chart ID="Chart1" runat="server" ImageLocation="~/Temporary/Graph"
            ImageType="Jpeg" DataSourceID="SensitiveXMLData" ImageStorageMode="UseImageLocation">
            <series>
                .
                .
                .
            </series>
            <chartareas>
                <asp:ChartArea Name="ChartArea1">
                </asp:ChartArea>
            </chartareas>
        </asp:Chart>
  

The code in Example 1 instructs the Chart control to produce a JPEG image of the bar graph and write it to the temporary directory ~/Temporary/Graph. After the control writes the image to disk, the user's browser will make a subsequent request of the file and display it to the user. The image is not written securely to disk. Also, the code assumes that the underlying infrastructure will protect the file from unauthorized access by another user.

When creating an instance of NSURLCredential containing the user's credentials in the form or a username/password pair or a client certificate, a persistence attribute needs to be defined. The possible values are:

- NSURLCredentialPersistenceNone: Credential should not be stored.
- NSURLCredentialPersistenceForSession: Credential should be stored only for this session.
- NSURLCredentialPersistencePermanent: Credential should be stored in the Keychain.
- NSURLCredentialPersistenceSynchronizable: Credential should be stored permanently in the Keychain, and in addition should be distributed to other devices based on the owning AppleID.

Since NSURLCredentialPersistenceSynchronizable credentials are distributed to other devices and iCloud, failing to completely remove the credential from all places will leave instances that could be leaked.

Example 1: The following snippet of code creates a synchronizable credential, uses it and then removes it locally but fails to remove it from other devices and iCloud:

    ...
    // Create the credential
	NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 

    // Use the credential as needed
    ...

    // Removes the credential
    [shared removeCredential:credential forProtectionSpace:protectionSpace];
    ...

Users expect applications to provide meaningful and user-friendly messages when there is a failure. However, when a login failure occurs due to incorrect credentials, providing verbose errors/messages might provide an attacker with information on how the application authorizes users.
For example, consider an application that takes an email address and a password. If the application provides different error messages for a non-existent email address and an incorrect password, it enables an attacker to submit multiple email addresses and discover the email addresses that are registered to the application. Such brute force attacks can provide extra information that can enable an attacker to proceed further.

Privacy violations occur when private user information is stored in an unprotected location.
Example 1: The following XML contains a user's private information within a plist file. Among other values that are stored, the MyCreditCard key stores a user-supplied plain text credit card number associated with the account.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>password</key>
  <string>BASICSECRET</string>
  <key>credentials</key>
  <dict>
          <key>pin</key>
          <string>2345</string>
          <key>MyCreditCard</key>
          <string>1111 11 2321 1112</string>
          <key>MysSn</key>
          <string>1111-22-3333</string>
          <key>ssn</key>
          <string>2345-22-3345</string>
          <key>userid</key>
          <string>12345</string>
  </dict>
</dict>
</plist>

The code in Example 1 stores private user information from the mobile device in an unprotected plist file stored on the device. Although many developers trust plist files as a safe storage location for any and all data, it should not be trusted implicitly particularly when privacy is a concern, since plist files may be read by anyone in possession of the device.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information.

- Accessed from a database or other data store by the application.

- Indirectly from a partner or other third party.

- Retrieved from mobile data stores including: Address book, snapped photos, geolocation, configuration files (including plist), archived SMS messages, etc.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates student identification based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create additional risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, inside plists, or in other locally-controlled resources. However, even if access to certain resources is restricted it does not guarantee that individuals that have access should be trusted with that data. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

The identified field does not disable iOS' keyboard caching mechanism. As a result, any sensitive information recently entered into the field will be cached by iOS in an effort to improve its autocorrection feature.

Example 1: Input entered into a sensitive text field is stored in the system's keyboard cache:

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS caches input into text fields in order to improve the performance of its autocorrection feature, any information recently entered into such an input control may be cached within a keyboard cache file saved to the file system. Because the keyboard cache file is stored on the device, if the device is lost, it may be recovered, thereby revealing any sensitive information contained within.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information.

- Accessed from a database or other data store by the application.

- Indirectly from a partner or other third party.

- Retrieved from mobile data stores including: Address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates student identification based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create additional risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, it does not guarantee that the individuals who do have access can be trusted with certain data. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Privacy violations occur when:

1. Private information enters the program.
2. The data is written to an external location, such as the console, file system or network.

Example 1: The following code defines a password parameter without the @secure() decorator.

@description('Provide the password')
param password string

The code in Example 1 will result in the password parameter being saved to the deployment history and logs.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Disclosing national identifiers that uniquely identify an EU citizen constitutes a violation of an individual's privacy under the EU General Data Protection Regulation (GDPR).

The EU General Data Protection Regulation (GDPR) replaces the Data Protection Directive 95/46/EC, and is designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens' data privacy and to reshape the way organizations across the region approach data privacy. GDPR provides a framework for organizations on how to handle personal data.
According to GDPR Article 4 personal data "means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person."

The identified UIViewController subclass does not implement the appropriate methods used to hide screen elements before iOS caches the screen's contents. This will reveal any sensitive information that has been entered within input controls before an app is backgrounded.

Example 1: Input entered into iOS text controls may be stored in a screenshot taken when an app is backgrounded (i.e. the "Home" button is pressed while the app is active).

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS takes a screenshot of the active view of an app when it is backgrounded in order to improve animation performance, any information displayed in such input controls during the background event may be cached within an image saved to the file system. Because these screen cache screenshots are stored on the device, if the device is lost, they may be recovered, thereby revealing any sensitive information contained within.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information.

- Accessed from a database or other data store by the application.

- Indirectly from a partner or other third party.

- Retrieved from mobile data stores including: address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates student identification based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create additional risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, it does not guarantee that the individuals who do have access can be trusted with certain data. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.