此类攻击属于旁路攻击，它通过自适应超文本压缩的浏览器进行勘测与渗透 (BREACH)，即使采用 SSL/TLS 通道传输，攻击者还是可以从 HTTP 响应中窃取到敏感信息。目前所有的 SSL/TLS 版本和密码都容易受到这种攻击。如果满足以下三个条件，攻击者就能成功对应用程序执行 BREACH 攻击：

1. 应用程序在响应中传输密钥（例如，反 CSRF 标记）。
2. 应用程序在包含密钥的相同响应中反映用户输入。
3. 配置 Web 服务器以使用 HTTP 压缩。

使用 gzip 压缩的响应大小取决于在其内容中观察到的重复量。因此，字符的重复频率越高，响应就越小。这使攻击者可以使用 HTTP 压缩作为攻击工具，它能指出攻击者通过返回的参数值向应用程序提供的猜测是否正确。如果猜到的字符与密钥中的对应字符一致，则压缩的响应就比较小。攻击者可使用此过程通过对每个请求的压缩率进行分析，逐字符获得整个密钥。

即使应用程序配置为通过安全渠道来提供内容，攻击者也可使用此技术从 HTTP 响应中提取密钥。

要评估应用程序是否容易受到 BREACH 攻击，首先应查看应用程序是否配置为支持 HTTP 压缩。如果是，则对于包含待保护密钥的每个响应，评估其是否包含用户输入。

由于 Django 应用程序配置为使用 CSRF 标记和 GZip 压缩，因此已报告此问题：

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

以下情况下可能会泄露私人健康状况信息：

1. 用户的健康状况信息进入了程序。

2. 数据被写到外部位置，例如控制台、文件系统或网络。
示例 1：以下代码会从 HealthKit 存储中检索用户的血型，将其发送到服务器并记录到设备中。虽然许多开发人员认为日志文件是存储所有数据的安全位置，但这不是绝对的，特别是涉及到隐私问题时。

    ...
    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);
    ...

注意： Apple Logging API 比 NSLog 函数所处的等级更低，开发人员可借助前者创建能够读取设备上所有日志的应用程序，即便他们并不拥有其他应用程序也是如此。

当设备丢失或被盗时，就会产生有关维护用户数据隐私的其他方面的忧虑。 攻击者一旦拥有 iOS 设备，即可通过对设备进行 USB 连接来访问其中的大量数据。 iOS Property Lists (plist) 及 SQLite 数据库等文件很容易访问，可能会泄露个人信息。 通常的做法是，不应将私人健康状况详细信息存储在文件系统中不受保护的位置。

示例 2： 以下代码向用户默认值列表中添加了用户的血型，并立即将其存储在一个 plist 文件中。

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

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

鉴于私人数据往往被错误处理，私人数据的收集与管理正日益规范化。 在健康状况信息方面，组织可能要遵守下列一项或若干项联邦和州的法规：

- Safe Harbor Privacy Framework [2]

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

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

- California SB-1386 [5]

尽管制定了这些规范，Privacy Violation 漏洞仍时有发生。

如果在使用敏感数据（例如密码、社会保障号码、信用卡号等）后不清除内存，则存储在内存中的这些数据可能会泄漏。然而，通常使用 String 存储敏感数据，因为 String 对象不可改变，只有 JVM 垃圾收集器才能从内存中删除 String 的值，只能由 JVM 垃圾收集器完成。由于除非 JVM 内存不足，否则不需要运行垃圾收集器，因此无法保证垃圾收集何时发生。如果应用程序崩溃，则应用程序的内存转储可能会泄露敏感数据。

例 1：下列代码可将密码从字符数组转换为 String。

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

使用 GET 方法的 HTTP 请求允许将 URL 和请求参数缓存到浏览器的 URL 缓存、中间代理和服务器日志中。这可能将敏感信息泄露给不具备相应数据权限的人。
示例 1：以下代码使用 GET HTTP 方法而非 POST 来发送 HTTP 请求。

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

示例 2：如果应用程序使用 NSURLRequest，则默认的 HTTP 方法为 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 {
...

创建包含用户名/密码对或客户端证书形式的用户凭据的 NSURLCredential 实例时，需要定义持久性属性。该属性可能的值如下：

- NSURLCredentialPersistenceNone：不应保存凭据。
- NSURLCredentialPersistenceForSession：只应为此会话存储凭据。
- NSURLCredentialPersistencePermanent：应将凭据存储在密钥链中。
- NSURLCredentialPersistenceSynchronizable：应将凭据永久存储在密钥链中，此外还应根据所拥有的 Apple ID 分配给其他设备。

NSURLCredentialPersistenceSynchronizable 属性说明凭据将会分发，并且会存储到 Apple 的云环境中。将凭据存储在 Apple 的云环境中可能并不是可接受的情况，具体取决于应用程序的隐私要求。

示例 1：以下代码片段创建了一个将会分发到其他设备和 iCloud 的可同步凭据：

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

当以未加密格式将敏感数据保存在磁盘上时，则会发生 privacy violation。


例 1：下列 ASPX 代码将通过 XML 数据源 SensitiveXMLData 生成敏感财务信息图表的 DataVisualization 控件实例化：

        <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>
  

Example 1 中的代码会指示 Chart 控件生成柱状图的 JPEG 图像，并将其写入临时目录 ~/Temporary/Graph 中。在该控件将此图像写入磁盘后，用户浏览器随后会对该文件发起一次请求，并将其显示给用户。该图像未安全写入磁盘。此外，该代码会假定底层基础架构会保护该文件，使其免受其他用户未经授权的访问。

创建包含用户名/密码对或客户端证书形式的用户凭据的 NSURLCredential 实例时，需要定义持久性属性。该属性可能的值如下：

- NSURLCredentialPersistenceNone：不应保存凭据。
- NSURLCredentialPersistenceForSession：只应为此会话存储凭据。
- NSURLCredentialPersistencePermanent：应将凭据存储在密钥链中。
- NSURLCredentialPersistenceSynchronizable：应将凭据永久存储在密钥链中，此外还应根据所拥有的 Apple ID 分配给其他设备。

由于 NSURLCredentialPersistenceSynchronizable 凭据会分发到其他设备和 iCloud，如果未能从所有位置完全删除该凭据，将留下可能会泄露的实例。

示例 1：以下代码片段创建了一个可同步的凭据并使用该凭据，然后在本地删除该凭据，但未能从其他设备和 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];
    ...

当用户私人信息存储在不受保护的位置时，将会面临 Privacy Violation 漏洞。
示例 1：下列 XML 将某个用户的私人信息存储在一个 plist 文件中。除存储的其他值外，MyCreditCard 键还会存储由用户提供的、与该帐户相关的纯文本信用卡卡号。

<?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>

Example 1 中的代码会将移动设备中的私人信息存储在该设备上的一个不受支持的 plist 文件中。虽然许多开发人员认为 plist 文件是存储所有数据的安全位置，但这不是绝对的，特别是涉及到隐私问题时，因为 plist 文件可被持有该设备的任何人读取。

可以通过多种方式将私人数据输入到程序中：

- 以密码或个人信息的形式直接从用户处获取。

- 由应用程序访问数据库或者其他数据存储器。

- 从合作伙伴或其他第三方间接获取。

- 从移动数据存储中检索，包括：通讯簿、拍摄的照片、地理位置、配置文件（包括 plist）、存档的 SMS 消息等。

有时，未贴上私人标签的数据在其他上下文中也有可能成为私人信息。例如，学生的学号通常不视为私人信息，因为学号中并没有明确且公开可用的信息来反映学生的个人信息。但是，如果学校用学生的社会保障号码生成学号，那么这时学号应被视为私人信息。

安全和隐私似乎一直是一对矛盾。从安全的角度看，您应该记录所有重要的操作，以便日后可以鉴定那些非法的操作。然而，当其中牵涉到私人数据时，这种做法就存在额外风险了。

虽然不安全地处理私人数据有多种形式，但是常见的风险来自于盲目的信任。程序员通常会信任运行程序的操作环境，因此认为可以将私人信息存放在文件系统、注册表、plist 内部或其他本地控制的资源中。然而，尽管限制了对某些资源的访问权限，也仍无法保证所有可访问这些资源的个人都是可信赖的。例如，2004 年，一个不道德的 AOL 员工将大约 9200 万个私有客户电子邮件地址卖给了一个通过垃圾邮件进行营销的境外赌博网站 [1]。

为能够妥善应对此类备受瞩目的信息盗取事件，私人数据的收集与管理正日益规范化。要求各个组织应根据其经营地点、所从事的业务类型及其处理的私人数据性质，遵守下列一个或若干个联邦和州的规定：

- Safe Harbor Privacy Framework [3]

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

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

- California SB-1386 [6]

这些规范业已存在，但侵犯隐私的情况仍时有发生。

已识别的字段未禁用 iOS 的键盘缓存机制。因此，iOS 将缓存最近输入到字段中的任何敏感信息，以便改善其自动更正功能。

示例 1：将输入到敏感文本字段中的输入存储到系统的键盘缓存中：

ViewController.h
...

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

...

Example 1 中的代码指示该应用程序使用了收集敏感信息的输入控件。由于 iOS 会将输入缓存到文本字段以改善其自动更正功能的性能，因此最近输入到此类输入控件中的任何信息可能会被缓存到保存到文件系统的键盘缓存文件中。由于键盘缓存文件存储在设备上，因此如果该设备丢失，该文件可能被恢复，从而导致泄露其中包含的任何敏感信息。

可以通过多种方式将私人数据输入到程序中：

— 以密码或个人信息的形式直接从用户处获取。

— 由应用程序访问数据库或者其他数据存储形式。

— 间接地从合作者或者第三方处获取。

- 从移动数据存储中检索如下信息：地址簿、拍摄的照片、地理位置、配置文件、存档的 SMS 消息等。

有时，某些数据并没有贴上私人数据标签，但在特定的上下文中也有可能成为私人信息。比如，通常认为学生的学号不是私人信息，因为学号中并没有明确而公开的信息用以定位特定学生的个人信息。但是，如果学校用学生的社会保障号码生成学号，那么这时学号就应被视为私人信息。

安全和隐私似乎一直是一对矛盾。从安全的角度看，您应该记录所有重要的操作，以便日后可以鉴定那些非法的操作。然而，当其中牵涉到私人数据时，这种做法就会带来额外的风险。

虽然私人数据处理不当的方式多种多样，但常见风险来自于盲目信任。程序员通常会信任运行程序的操作环境，因此认为将私人信息存放在文件系统、注册表或者其他本地控制的资源中是值得信任的。然而，尽管某些特定资源已经被限制访问，但仍无法保证所有能够访问该资源的个体都是可以信赖的。例如，2004 年，一个不道德的 AOL 员工将大约 9200 万个私有客户电子邮件地址卖给了一个通过垃圾邮件进行营销的境外赌博网站 [1]。

鉴于此类备受瞩目的信息盗取事件，私人信息的收集与管理正日益规范化。要求各个组织应根据其经营地点、所从事的业务类型及其处理的私人数据性质，遵守下列一个或若干个联邦和州的规定：

- Safe Harbor Privacy Framework [3]

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

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

- California SB-1386 [6]

尽管制定了这些规范，Privacy Violation 漏洞仍时有发生。

在 iOS 缓存屏幕上的内容之前，已识别的 UIViewController 子类不会实现用于隐藏屏幕元素的相应方法。这将泄露应用程序在后台运行之前已输入到输入控件中的敏感信息。

示例 1：输入到 iOS 文本控件中的输入可能会存储在应用程序在后台运行时捕获的屏幕截图中（即当应用程序处于活动状态时按“主页”按钮）。

ViewController.h
...

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

...

Example 1 中的代码指示该应用程序使用了收集敏感信息的输入控件。由于 iOS 会捕获应用程序在后台运行时其活动视图的屏幕截图以改善动画性能，因此在后台事件期间在此类输入控件中显示的任何信息都可能会被缓存在保存到文件系统的图像内。由于这些屏幕缓存屏幕截图存储在设备上，因此如果该设备丢失，这些屏幕截图可能被恢复，从而导致泄露其中包含的任何敏感信息。

可以通过多种方式将私人数据输入到程序中：

— 以密码或个人信息的形式直接从用户处获取。

— 由应用程序访问数据库或者其他数据存储形式。

— 间接地从合作者或者第三方处获取。

- 从移动数据存储中检索如下信息：地址簿、拍摄的照片、地理位置、配置文件、存档的 SMS 消息等。

有时，某些数据并没有贴上私人数据标签，但在特定的上下文中也有可能成为私人信息。比如，通常认为学生的学号不是私人信息，因为学号中并没有明确而公开的信息用以定位特定学生的个人信息。但是，如果学校用学生的社会保障号码生成学号，那么这时学号就应被视为私人信息。

安全和隐私似乎一直是一对矛盾。从安全的角度看，您应该记录所有重要的操作，以便日后可以鉴定那些非法的操作。然而，当其中牵涉到私人数据时，这种做法就会带来额外的风险。

虽然私人数据处理不当的方式多种多样，但常见风险来自于盲目信任。程序员通常会信任运行程序的操作环境，因此认为将私人信息存放在文件系统、注册表或者其他本地控制的资源中是值得信任的。然而，尽管某些特定资源已经被限制访问，但仍无法保证所有能够访问该资源的个体都是可以信赖的。例如，2004 年，一个不道德的 AOL 员工将大约 9200 万个私有客户电子邮件地址卖给了一个通过垃圾邮件进行营销的境外赌博网站 [1]。

鉴于此类备受瞩目的信息盗取事件，私人信息的收集与管理正日益规范化。要求各个组织应根据其经营地点、所从事的业务类型及其处理的私人数据性质，遵守下列一个或若干个联邦和州的规定：

- Safe Harbor Privacy Framework [3]

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

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

- California SB-1386 [6]

尽管制定了这些规范，Privacy Violation 漏洞仍时有发生。

Documents 目录用于存储非瞬态的应用程序数据，例如用户创建的内容或本地信息，以便使应用程序能够以离线模式运行。如果在应用程序的 Info.plist 文件中设置了 UIFileSharingEnabled，那么该目录中的文件便可以通过 iTunes 访问。如果将敏感数据写入 Documents 目录，这些数据可能会通过未加密的备份或 iTunes 接口泄露。

示例 1：以下代码片段将用户密码以明文写入 Documents 目录中：

    ...
    NSString *docsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *passwd_path = [docsDirectory stringByAppendingPathComponent:@"passwords.txt"];

    NSString *password = [user password];
    [password writeToFile:passwd_path atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ...

某些收集敏感信息的 API 可能会错误地处理该信息，将其返回给用户。

示例 1：以下代码演示了如何实例化密码回调对象，当用户在输入提示下输入密码时，该对象不会对密码进行模糊处理：

PasswordCallback pc = new PasswordCallback("Please enter your password: ", true);

由于Example 1 中的 pc 是在其第二个参数 onEcho 设置为 true 的情况下进行实例化的，因此，当用户在“请输入您的密码:”提示下输入密码时，该密码不会进行模糊显示。

Privacy Violation 会在以下情况下发生：

1.用户私人信息进入了程序。
2.数据被写到外部位置，如控制台、文件系统或网络。

示例 1：下面易受攻击的代码包含一个配置语句，该语句允许以未屏蔽形式记录密码“admin_password”。

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

Example 1 中的代码将 admin_password 以明文（未屏蔽）形式写入日志输出，因为 secret 的值设置为 False。虽然许多开发人员认为事件日志是存储数据的安全位置，但这不是绝对的，特别是涉及到隐私问题时。

可以通过多种方式将私人数据输入到程序中：

- 以密码或个人信息的形式直接从用户处获取

- 由应用程序访问数据库或者其他数据存储器

- 从合作伙伴或其他第三方间接获取

有时，未贴上私人标签的数据在其他上下文中也有可能成为私人信息。例如，学生的学号通常不视为私人信息，因为学号中并没有明确且公开可用的信息来反映学生的个人信息。但是，如果学校用学生的社会保障号码生成学号，那么这时学号应被视为私人信息。

安全和隐私似乎一直是一对矛盾。从安全的角度看，您应该记录所有重要的操作，以便日后可以鉴定那些非法的操作。然而，当其中牵涉到私人数据时，这种做法就存在一定风险了。

虽然不安全地处理私人数据有多种形式，但是常见的风险来自于盲目的信任。程序员通常会信任运行程序的操作环境，因此认为将私人信息存放在文件系统、注册表或者其他本地控制的资源中是值得信任的。尽管已经限制了某些资源的访问权限，但仍无法保证所有访问这些资源的个体都是值得信任的。例如，2004 年，一个不道德的 AOL 员工将大约 9200 万个私有客户电子邮件地址卖给了一个通过垃圾邮件进行营销的境外赌博网站 [1]。

为能够妥善应对此类备受瞩目的信息盗取事件，私人数据的收集与管理正日益规范化。要求各个组织应根据其经营地点、所从事的业务类型及其处理的私人数据性质，遵守下列一个或若干个联邦和州的规定：

- Safe Harbor Privacy Framework [3]

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

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

- California SB-1386 [6]

这些规范业已存在，但侵犯隐私的情况仍时有发生。

攻击者可通过下列方法来利用未经检验的权限中的漏洞：

1. 数据从不可信赖的数据源进入应用程序。

2. 事先未经过任何健全性检查，此数据即用于表示用户或组标识符、权限列表或应用权限的资源。应用程序随后会使用这些未经检查的数据来编辑权限设置。

此权限具有“危险”保护级别。指定为“危险”的权限意味着用户数据隐私或设备操作的风险增加。在这种情况下，访问身体活动信息可能会对用户隐私和个人安全造成危险。需要访问用户身体活动信息的应用程序必须非常谨慎地对其进行管理。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 ACTIVITY_RECOGNITION 权限，使应用程序能够识别用户的身体活动。

 <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION"/> 

此权限具有“危险”保护级别。指定为“危险”的权限意味着用户数据隐私或设备操作的风险增加。在这种情况下，访问用户日历可能会对用户隐私和个人安全造成危险。应用程序必须将日历数据视为敏感数据，并极为谨慎地对其进行管理以维护隐私。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 READ_CALENDAR 权限，使应用程序能够读取用户的日历数据。

 <uses-permission android:name="android.permission.READ_CALENDAR"/> 

示例 2：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 WRITE_CALENDAR 权限，使应用程序能够写入用户的日历数据。

 <uses-permission android:name="android.permission.WRITE_CALENDAR"/> 

此权限具有“危险”保护级别。指定为“危险”的权限意味着用户数据隐私或设备操作的风险增加。在这种情况下，访问通话记录可能会对用户隐私和个人安全造成危险。需要访问通话记录的应用程序必须极为谨慎地对其进行管理。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 READ_CALL_LOG 权限，使应用程序能够读取用户的通话记录。

 <uses-permission android:name="android.permission.READ_CALL_LOG"/> 

示例 2：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 WRITE_CALL_LOG 权限，使应用程序能够写入用户的通话记录。

 <uses-permission android:name="android.permission.WRITE_CALL_LOG"/> 

此权限具有“危险”保护级别。指定为“危险”的权限意味着用户数据隐私或设备操作的风险增加。在这种情况下，访问摄像头可能会对用户隐私和个人安全造成危险。需要访问摄像头的应用程序必须极为谨慎地对其进行管理。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 CAMERA 权限，使应用程序能够访问设备的摄像头。

 <uses-permission android:name="android.permission.CAMERA"/> 

此权限具有“危险”保护级别。指定为“危险”的权限意味着用户数据隐私或设备操作的风险增加。在这种情况下，访问联系人信息可能会对用户隐私和个人安全造成危险。应用程序必须将联系人数据视为敏感数据，并极为谨慎地进行管理。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 READ_CONTACTS 权限，使应用程序能够读取用户的联系人数据。

 <uses-permission android:name="android.permission.READ_CONTACTS"/> 

示例 2：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 WRITE_CONTACTS 权限，使应用程序能够写入用户的联系人数据。

 <uses-permission android:name="android.permission.WRITE_CONTACTS"/> 

示例 3：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 GET_ACCOUNTS 权限，使应用程序能够访问用户的电子邮件和存储在帐户管理器中的在线帐户。使用此权限可以访问敏感数据，如帐户 ID、电子邮件地址和电话号码。

 <uses-permission android:name="android.permission.GET_ACCOUNTS"/> 

写入外部存储的文件可供任意程序和用户读取和写入。程序不得将敏感信息（例如个人身份信息）写入外部存储。当通过 USB 将 Android 设备连接到 PC 或其他设备时，Android 设备将启用 USB 大容量存储模式。任何写入外部存储的文件都可以在此模式下读取和修改。此外，即使卸载写入文件的应用程序后，外部存储中的文件将仍然保留，这进一步增加了存储在其中的任何敏感信息被泄露的风险。

示例 1：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用 WRITE_EXTERNAL_STORAGE 权限，该权限允许应用程序写入外部存储。

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

示例 2：AndroidManifest.xml 的 <uses-permission .../> 元素声明使用了 READ_EXTERNAL_STORAGE 权限，该权限允许应用程序读取外部存储。

 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>