!20217 【轻量级 PR】：修改文档规范

Merge pull request !20217 from zengyawen/N/A

!20217 【轻量级 PR】：修改文档规范
Merge pull request !20217 from zengyawen/N/A
2b88b5c0 · openharmony_ci · Gitee · bc1bdf44 · 966d3733 · 2b88b5c0
4 changed file
--- a/zh-cn/application-dev/media/using-ohaudio-for-playback.md
+++ b/zh-cn/application-dev/media/using-ohaudio-for-playback.md
 # 使用OHAudio开发音频播放功能

-OHAudio是OpenHarmony在API10中引入的一套全新C API，此API在设计上实现归一，同时支持普通音频通路和低时延通路。
+OHAudio是OpenHarmony在API version 10中引入的一套全新Naitve API，此API在设计上实现归一，同时支持普通音频通路和低时延通路。

 ## 使用入门

@@ -85,7 +85,7 @@ OH_AudioStreamBuilder_Destroy(builder);

 6. 释放构造器

-构造器不在使用时，需要释放它。
+    构造器不再使用时，需要释放相关资源。

    ```c++
    OH_AudioStreamBuilder_Destroy(builder);

--- a/zh-cn/application-dev/media/using-ohaudio-for-recording.md
+++ b/zh-cn/application-dev/media/using-ohaudio-for-recording.md
 # 使用OHAudio开发音频录制功能

-OHAudio是OpenHarmony在API10中引入的一套全新C API，此API在设计上实现归一，同时支持普通音频通路和低时延通路。
+OHAudio是OpenHarmony在API version 10中引入的一套全新Naitve API，此API在设计上实现归一，同时支持普通音频通路和低时延通路。

 ## 使用入门

@@ -85,7 +85,7 @@ OH_AudioStreamBuilder_Destroy(builder);

 6. 释放构造器

-构造器不在使用时，需要释放它。
+    构造器不再使用时，需要释放相关资源。

    ```c++
    OH_AudioStreamBuilder_Destroy(builder);

--- a/zh-cn/device-dev/security/security-guidelines-overall.md
+++ b/zh-cn/device-dev/security/security-guidelines-overall.md
@@ -19,6 +19,7 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo
 ### 安全机制

 - 启动可信根
+
  OpenHarmony设备采用PKI（Public Key Infrastructure）体系保护软件完整性，确保设备运行来源合法、软件未被篡改。

  在设备启动流程中，逐级进行软件签名校验形成安全启动链，任何一个环节的签名校验不通过即终止设备启动；安全启动链中最初执行签名校验的软硬件实体，需确保自身的合法、未被篡改。该实体即为设备的启动可信根。启动可信根可为固化在ROM中的一段代码，这段代码在芯片制造环节固化到芯片中，芯片制造完成后软件不可更改，在设备上电初始化的过程中，最先执行这段ROM中的代码，并由这段ROM代码执行后续的软件签名校验。
@@ -26,6 +27,7 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo
  ROM中的代码在执行签名校验时，需确保用于校验的PKI公钥的合法性，OpenHarmony设备可采用eFuse/OTP等存储介质来存储公钥（如公钥哈希值），来保护公钥自身的合法性。公钥一般在设备制造环节，烧录到设备的eFuse/OTP中。

 - 硬件隔离可信环境
+
  硬件隔离的可信环境，遵循了可信计算系统的设计理念。可信环境内外形成了两个世界：可信世界与不可信世界，两者之间存在清晰而明确的隔离边界；OpenHarmony设备在可信环境中实现了核心敏感数据的保护机制，可确保即使不可信世界的操作系统存在漏洞且被利用，也依然能确保可信环境中敏感数据的安全。

  OpenHarmony设备的可信环境，基于硬件的安全隔离机制构建，在不同的OpenHarmony设备上芯片隔离机制略有差异，较为通用的方法是采用ARM的TrustZone技术。在部分Risc-V芯片平台上，也可能采用独立安全核的形式来构建可信环境。
@@ -33,6 +35,7 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo
  可信环境中，运行特定的、精简的操作系统iTrustee lite，用于管理可信环境的资源和任务调度，给OpenHarmony设备提供安全服务。密钥管理及数据安全，是可信环境中最为常见的安全服务，设备在eFuse/OTP中存有硬件唯一根密钥，可信环境可基于该密钥结合业务上下文衍生出多种密钥，给应用提供密钥管理和数据加解密相关的服务；设备核心密钥生命周期不离开可信环境。可信环境同样可提供身份认证、系统状态监控、数据安全存储等安全服务，提高设备安全性。

 - 硬件密钥引擎
+
  密码学是信息安全的基础。数据加解密对计算机设备的核心诉求是：高效、安全。硬件加解密技术利用计算机硬件辅助软件，甚至直接取代软件，来处理数据的加解密。相比由软件实现的加解密计算，硬件实现的加解密计算更高效、更安全。

  由硬件来实现加解密处理，意味着部分专用的硬件资源会用于处理加解密计算任务，当加解密引擎工作的时候CPU可以并发地继续执行其他计算任务，因此硬件加解密引擎可以带来极大的性能提升，同时降低CPU负载。此外，硬件密钥引擎可以带来更高的安全性，设计良好的硬件密钥引擎，哪怕软件被攻破也依然可保护密钥不泄露，甚至可对抗电磁、辐射等物理侧信道攻击。
@@ -45,6 +48,7 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo
 - 启动可信根可由一段固化在芯片中的代码和设备根密钥组成，前者一般在芯片制造阶段写入，设备生命周期内不可更改，负责在启动阶段校验设备软件证书；后者则是用于设备证书签名的私钥相对应的公钥，证书签名私钥不出PKI签名服务器，而公钥则需写入设备。为防止攻击者篡改公钥从而达到绕过签名认证的目的，写入OpenHarmony设备的公钥须确保不可篡改，可将公钥信息写入如熔丝等介质；考虑到熔丝空间有限，可仅存储公钥的哈希值，并由启动代码校验公钥的合法性。

 - 可信执行环境较为通用的做法是基于ARM TrustZone技术构建，也可根据设备的实际形态选择其他隔离机制，如TrustZone-M、独立安全核等；可信执行环境中须部署TEE OS，用于管理可信执行环境的资源及任务调度。OpenHarmony系统提供iTrustee作为TEE OS的解决方案，开发者及设备商可基于iTrustee开发并部署安全业务。
+
  并非所有OpenHarmony设备都强制要求支持可信执行环境，部分运行低敏感业务的瘦资源设备可不做强制要求；可根据实际业务场景选择是否支持可信执行环境，以及实现怎样的可信执行环境。

 - 硬件密钥引擎须提供真随机数、公钥、对称密钥、哈希等密钥算法能力，通过在OpenHarmony系统中部署相应的驱动程序，给应用提供统一的密钥管理及密钥算法服务。
@@ -57,13 +61,13 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo

 对于128KB~128MB内存的设备，推荐使用OpenHarmony轻内核组件，在该内核下：

-  **进程隔离** 
+- **进程隔离** 

  进程隔离是为了防止A进程读写B进程内存数据的情况发生，进程的隔离技术，一般都采用虚拟地址空间映射方式，通过MMU配置，进程A的虚拟地址和进程B的虚拟地址映射各自不同的实际的物理地址段，这样A进程通过访问虚拟地址访问的实际内存数据在非共享内存的情况下，只属于A进程，B进程无法直接访问。

  OpenHarmony由于资源有限，对于内核态和用户态的进程采用不同的方式：所有的内核态进程共享同一块VMM空间，即所有的内核态进程之间无隔离，系统启动时内核态创建两个基本进程KProcess和KIdle，KProcess进程为内核态进程的根进程，KIdle进程为KProcess进程的子进程；但是对于每一个用户态进程均拥有自己独立的VMM空间，相互之间不可见，实现进程间隔离。

-  **自主访问控制** 
+- **自主访问控制** 

  自主访问控制DAC（Discretionary Access Control）的思想是文件权限由文件拥有者来决定其他角色的访问权限。权限管控粒度分为三类：user(自身)， group(组员)，other(其他人)，即UGO。将任意用户分类为UGO中三者之一，并采取相应的管控策略，即完成了DAC权限校验流程。

@@ -73,15 +77,15 @@ OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmo

  下图描述了DAC在文件访问时的鉴权过程，首先匹配进程uid和文件uid属性，其次匹配进程gid和文件gid属性，最后都匹配失败的情况，判断文件other属性是否支持进程的读、写、执行操作。同时支持忽略DAC检测机制（读、写、执行）作为一组系统特权（Capability），支持高权限（如系统服务）对低权限（三方APP）的文件管理。

-**图2** DAC流程图
+  **图2** DAC流程图
    
-![zh-cn_image_0000001057233092](figures/zh-cn_image_0000001057233092.png)
+  ![zh-cn_image_0000001057233092](figures/zh-cn_image_0000001057233092.png)

-  **Capability机制** 
+- **Capability机制** 

  Capability机制实际上是对root权限的具体细分。在多用户计算机系统中，一般会有一个特殊的角色拥有系统的所有权限，这个角色一般是系统管理员(root)。对于OpenHarmony这种需要支持三方应用生态的内核，需要将系统中的特权访问进行管控。系统需要对用户层访问内核的特权级系统调用进行限制。仅允许部分高权限应用进行特权操作。具体实现方式是内核spawn第一个用户程序INIT，其包含全部的特权能力，此后，INIT拉起其他应用框架服务，拉起过程中，对各应用框架进行相应的降权操作，为各应用保留必需的特权能力。 当应用去调用特权接口时，内核态就会通过进程ID查看当前访问者是否有权限访问目标接口。

-  **安全启动** 
+- **安全启动** 

  安全启动是整个系统安全的基础，通过采用数字签名和完整性校验机制，从芯片内部固化的可信启动根开始，逐级校验每一层软件的完整性和合法性，确保最终启动的操作系统软件是厂家提供的正确合法的软件，防止攻击者对系统软件做恶意的篡改和植入，为整个系统提供初始安全的基础运行环境。

@@ -122,17 +126,17 @@ HUKS（OpenHarmony Universal Keystore Service），提供了密钥管理、证
 HUKS在使用中有如下约束：


-  **密钥安全存储：** 
+- **密钥安全存储：** 

-密钥要求存储于安全存储区域，数据不可以修改，恢复出厂设置时出厂预置的密钥不能被删除。
+  密钥要求存储于安全存储区域，数据不可以修改，恢复出厂设置时出厂预置的密钥不能被删除。

-  **密钥访问安全：** 
+- **密钥访问安全：** 

-OpenHarmony通过将不同应用数据保存在不同的位置，来实现应用间数据的隔离。通过参数结构体中包含UID和进程ID，来实现不同应用间的数据隔离。
+  OpenHarmony通过将不同应用数据保存在不同的位置，来实现应用间数据的隔离。通过参数结构体中包含UID和进程ID，来实现不同应用间的数据隔离。

-  **不支持并发访问：** 
+- **不支持并发访问：** 

-HUKS本身不考虑多个应用同时调用的情况，因为HUKS只是一个lib库，也不考虑资源的互斥。如果有多个应用都会用到HUKS服务，那么应该由每个应用各自链接一份HUKS库，并由业务传入持久化数据存储的路径，以实现应用间的数据存储分开。数据存储在各应用各自存储目录下。
+  HUKS本身不考虑多个应用同时调用的情况，因为HUKS只是一个lib库，也不考虑资源的互斥。如果有多个应用都会用到HUKS服务，那么应该由每个应用各自链接一份HUKS库，并由业务传入持久化数据存储的路径，以实现应用间的数据存储分开。数据存储在各应用各自存储目录下。


 ### 推荐做法
@@ -151,28 +155,28 @@ HUKS本身不考虑多个应用同时调用的情况，因为HUKS只是一个lib


 - **IoT设备互联安全**
-  设备互联支持基于OpenHarmony的IoT设备（如AI音箱、智能家居、智能穿戴等设备）与IoT主控设备间建立点对点的信任关系，并在具备信任关系的设备间，搭建安全的连接通道，实现用户数据端到端加密传输。

+  设备互联支持基于OpenHarmony的IoT设备（如AI音箱、智能家居、智能穿戴等设备）与IoT主控设备间建立点对点的信任关系，并在具备信任关系的设备间，搭建安全的连接通道，实现用户数据端到端加密传输。

 - **IoT主控设备的IoT业务身份标识**
-  IoT主控设备为不同的IoT设备管理业务生成不同的身份标识，形成不同IoT管理业务间的隔离，该标识用于IoT主控设备与IoT设备之间的认证以及通信。IoT业务身份标识为椭圆曲线公私钥对（Ed25519公私钥对）。

+  IoT主控设备为不同的IoT设备管理业务生成不同的身份标识，形成不同IoT管理业务间的隔离，该标识用于IoT主控设备与IoT设备之间的认证以及通信。IoT业务身份标识为椭圆曲线公私钥对（Ed25519公私钥对）。

 - **IoT设备身份标识**
+
  IoT设备会生成各自的设备身份标识，用来与IoT主控设备通信。该身份标识同样为椭圆曲线公私钥对（Ed25519公私钥对）；IoT设备私钥不出IoT设备，设备每次恢复出厂设置，会重置这个公私钥对。

  上述身份标识可用于IoT主控设备与IoT设备间的安全通信：当IoT主控设备与IoT设备通过信任绑定流程交换业务身份标识或设备标识后，可以进行密钥协商并建立安全通信通道。

-
 - **设备间点对点的信任绑定**
+
  IoT主控设备和IoT设备建立点对点信任关系的过程，实际上是相互交换IoT设备的身份标识的过程。

  在点对点建立信任关系的过程中，用户需要在IoT主控设备上，输入IoT设备上提供的PIN码：对于有屏幕的设备，该PIN码动态生成；对于没有屏幕的设备，该PIN码由设备生产厂家预置；PIN码的展示形式，可以是一个用户可读的数字，也可以是一个二维码。随后，IoT主控设备和IoT设备间使用PAKE协议完成认证和会话密钥协商过程，并在此基础上，通过协商出的会话密钥加密传输通道用于交换双方设备的身份标识公钥。

-
 - **IoT主控设备与IoT设备间的通信安全**
-  当建立过信任关系的IoT主控设备与IoT设备间进行通信时，双方在完成上述信任关系绑定后，基于本地存储的对端身份公钥相互进行认证；在每次通信时基于STS协议完成双向身份认证以及会话密钥协商，之后设备使用此会话密钥加密双方设备间的传输通道。

+  当建立过信任关系的IoT主控设备与IoT设备间进行通信时，双方在完成上述信任关系绑定后，基于本地存储的对端身份公钥相互进行认证；在每次通信时基于STS协议完成双向身份认证以及会话密钥协商，之后设备使用此会话密钥加密双方设备间的传输通道。

 ## 应用安全

@@ -180,15 +184,17 @@ HUKS本身不考虑多个应用同时调用的情况，因为HUKS只是一个lib
 ### 安全机制

 - 应用签名管控
+
  OpenHarmony应用的安装需要首先对包的完整性进行校验，具体策略是在开发阶段完成开发和调试后对安装包进行签名，这个签名需要使用指定的私钥，这个私钥就是跟验签用的公钥是一对的，一般的做法是OEM厂商生成一对公私钥，然后将公钥信息预置到设备中，而私钥就放在一个不联网的本地服务器上，这样可以确保私钥被泄露的风险尽量小，而应用在完成开发后就可以通过外置设备（例如USB）上传安装包到存放私钥的服务器上计算签名并下载签名结果到外置设备上。而安装应用时首先计算包的Hash值，一般采用SHA256算法，然后使用hash值和签名信息以及预置公钥进行验签，只有验签通过的应用才能安装。

  除了要证明应用来自云端认证过的，还需要证明来源，即这个应用来自合法开发者开发的，具体做法是，开发者向云端申请开发证书，开发完成后，用开发证书进行自签名，设备端存放这个证书的上一级证书，所以安装过程中，对自签名信息做校验，确保开发者的合法性。


 - 应用权限控制
+
  由于OpenHarmony系统允许安装三方应用，所以需要对三方应用的敏感权限调用进行管控，具体实现是应用在开发阶段就需要在应用配置文件中指明此应用在运行过程中可能会调用哪些敏感权限，这些权限包括静态权限和动态权限，静态权限表示只需要在安装阶段注册就可以，而动态权限一般表示获取用户的敏感信息，所以需要在运行时让用户确认才可以调用，授权方式包括系统设置应用手动授权等。除了运行时对应用调用敏感权限进行管控外，还需要利用应用签名管控手段确保应用安装包已经被设备厂商进行了确认。

-    **表1** **OpenHarmony系统权限列表**
+  **表1** **OpenHarmony系统权限列表**
  
  | **OpenHarmony系统权限** | **授权方式** | **权限说明** | 
  | -------- | -------- | -------- |

--- a/zh-cn/device-dev/security/security-privacy-protection.md
+++ b/zh-cn/device-dev/security/security-privacy-protection.md
@@ -8,26 +8,33 @@
 **基本概念**

 - **个人数据（Personal Data）**
+
  与一个身份已被识别或者身份可被识别的自然人（“数据主体”）相关的任何信息；身份可识别的自然人是指其身份可以通过诸如姓名、身份证号、位置数据等识别码或者通过一个或多个与自然人的身体、生理、精神、经济、文化或者社会身份相关的特定因素来直接或者间接的被识别。个人数据包括：自然人的email地址、电话号码、生物特征（指纹）、位置数据、IP地址、医疗信息、宗教信仰、社保号、婚姻状态等。

 - **敏感个人数据（Sensitive Personal Data）**
+
  敏感个人数据是个人数据的一个重要子集，指的是涉及数据主体的最私密领域的信息或者一旦泄露可能会给数据主体造成重大不利影响的数据。欧盟等国家和地区法律定义的敏感个人数据包括种族、政治观点、宗教和哲学信仰、工会成员资格、基因数据、生物信息、健康和性生活状况、性取向等。

  根据业界最佳实践，敏感个人数据还包括可与自然人身份相关联的银行卡号、身份证号、护照号、口令等。敏感个人数据的处理需要更多更严格的保护措施。

 - **公开个人数据（Public available Personal Data）**
+
  数据主体主动公开的个人数据，或公开网页/应用上可访问的个人数据，包括论坛公开的发帖、评论等。

 - **用户画像（User Profile）**
+
  指对个人数据采取的任何自动化处理的方式，包括评估某个自然人特定方面的情况，尤其是为了分析和预测该自然人的工作表现、经济状况、健康、个人喜好、兴趣、可信度、行为举止、所在位置或行迹。

 - **数据控制者（Data Controller）**
+
  单独或者与他人共同确定个人数据处理的目的和手段的自然人、法人、公共机构、政府部门或其他机构。

 - **数据处理者（Data Processor）**
+
  指代表数据控制者处理个人数据的自然人、法人、公共机构、政府部门或其他机构。数据处理者必须按照数据控制者的要求对个人数据进行充分的保护。

 - **明示同意（Explicit consent）**
+
  如下几种情形GDPR法律提到可以通过数据主体明示同意的方式合法的处理数据：

  - 处理敏感个人数据。
@@ -49,7 +56,7 @@

 **表1** 数据分类分级标准

-  | **数据级别** | 隐私风险 | 隐私属性 | **典型示例** | 
+| **数据级别** | 隐私风险 | 隐私属性 | **典型示例** | 
 | -------- | -------- | -------- | -------- |
 | 极高级 | 数据一旦识别或关联到特定个人或群体，其泄露或不当使用可能会给个人带来灾难性负面影响。 | 敏感个人数据 | DNA、种族、宗教信仰、性取向；生物识别信息；原始通信内容；银行卡密码、磁道数据。 | 
 | 高级别 | 数据一旦识别或关联到特定个人或群体，其泄露或不当使用可能会给个人带来严重负面影响。 | 敏感个人数据 | 权威社会标识（身份证、护照等）；网页浏览记录；轨迹信息；云空间上传的内容数据（图库/音频/视频等）。 | 
@@ -59,7 +66,6 @@

 备注：隐私保护和数据分类分级的相关定义参照GDPR法律中的相关内容。

-
 ## 通用隐私设计规则

 为了指导厂商完成产品的隐私设计工作，我们整理了以下通用的隐私设计要求，作为OpenHarmony设备厂商产品隐私设计的指南和参考。
@@ -69,30 +75,40 @@
 采集个人数据时，应清晰、明确的告知用户，并确保告知用户的个人信息将被如何使用。

 - 针对不同等级的个人数据需要制定针对性的隐私处理策略。
+
  - 敏感个人数据的采集需要获取数据主体明示同意。
  - 一般个人数据的采集需要数据主体同意或基于其他合法授权。
  - 非个人数据与中、高或极高级别个人数据关联采集，需要数据主体同意或其他合法授权，并在隐私声明中呈现。

 - 应制定并遵从适当的隐私政策。在收集、使用留存和第三方分享用户个人数据时需要符合所有适用法律、政策和规定。如在收集个人数据前，需充分告知用户处理个人数据的种类、目的、处理方式、保留期限等，满足数据主体权利相关要求。
    根据以上要求，我们设计了正确示例以供参考。隐私通知/声明的参考示例如下：
+
    **图1** 隐私通知/声明示例图
+
    ![zh-cn_image_0000001193330127](figures/zh-cn_image_0000001193330127.png)

    **图2** 应用隐私声明
+
    ![zh-cn_image_0000001147250660](figures/zh-cn_image_0000001147250660.png)

 - 个人数据应当基于具体、明确、合法的目的收集，不应与此目的不相符的方式作进一步处理。对于收集目的变更和用户撤销同意后再次重新使用的场景都需要用户重新同意。隐私声明变更和撤销的示例如下图：
+
    **图3** 隐私通知/声明变更示例图
+
    ![zh-cn_image_0000001147410700](figures/zh-cn_image_0000001147410700.png)

    **图4** 撤销同意示例图
+
    ![zh-cn_image_0000001147251830](figures/zh-cn_image_0000001147251830.png)

    **图5** 隐私声明撤销
+
    ![zh-cn_image_0000001193292069](figures/zh-cn_image_0000001193292069.png)

 - 需要提供用户查看隐私声明的入口。例如，可以在应用的“关于”界面提供查看隐私声明的入口，如示例图所示：
+
    **图6** 隐私声明查看界面示例图
+
    ![zh-cn_image_0000001193292261](figures/zh-cn_image_0000001193292261.png)

 **数据收集及使用最小化**
@@ -106,14 +122,17 @@
 - 数据使用的功能要求能够使用户受益，收集的数据不能用于一些与用户正常使用无关的功能。数据收集不能有其他与用户正常使用无关的功能存在。如不得将“生物特征”、“健康数据”等敏感个人数据用于服务改进、投放广告或营销等非业务核心功能。

 - 禁止在日志中打印敏感个人数据，如需要打印一般个人数据时，应对个人数据进行匿名化或假名化处理；
-  优先使用可以重置的标识符，如系统提供了NetworkID和DVID作为分布式场景下的设备标识符，广告业务场景下则建议使用[OAID](https://developer.huawei.com/consumer/cn/doc/development/HMSCore-Guides/oaid-0000001050783198)，基于应用的分析则建议使用[ODID](https://developer.huawei.com/consumer/cn/doc/development/HMSCore-Guides/odid-0000001051063255)和[AAID](https://developer.huawei.com/consumer/cn/doc/development/HMSCore-Guides/aaid-0000001051142988)，其他需要唯一标识符的场景可以使用UUID接口生成；可重置的标识符不能满足业务需求时，才选择序列号和MAC地址等永久性标识符。
+
+  优先使用可以重置的标识符，如系统提供了NetworkID和DVID作为分布式场景下的设备标识符，广告业务场景下则建议使用OAID，基于应用的分析则建议使用ODID和AAID，其他需要唯一标识符的场景可以使用UUID接口生成；可重置的标识符不能满足业务需求时，才选择序列号和MAC地址等永久性标识符。

 **数据处理选择和控制**

 对个人数据处理必须要征得用户的同意或遵守其他适用的法律法规，用户对其个人数据要有充分的控制权。

 - 获取用户敏感权限的授权：产品弹窗提醒，向用户呈现需要获取的权限和权限使用目的，用户可通过选择决定是否进行授权及指定授权的方式，让用户对产品权限的授予和个人数据使用做到透明、可知、可控。如下图所示：
+
    **图7** 敏感权限提示框示例图
+
    ![zh-cn_image_0000001147412742](figures/zh-cn_image_0000001147412742.png)

 - 用户可以修改、取消授予的权限：当用户不同意某一权限或者数据收集时，应当允许用户使用与这部分权限和数据收集不相关的功能。如智慧屏产品上通信社交应用，用户可以拒绝授予相机权限，不应该影响与相机无关的功能操作，如语音通话。
@@ -151,7 +170,7 @@

 **表2**  特殊品类隐私要求

-  | 产品品类 | 隐私保护特殊要求 | 
+| 产品品类 | 隐私保护特殊要求 | 
 | -------- | -------- |
 | **智能家居** | 安防类产品涉及的指纹、声纹、面部识别、虹膜等个人生物识别信息以及用户密码信息，属于敏感个人数据，应采用技术措施处理后（例如提取个人生物识别信息的摘要）再进行加密保存在产品本地。 | 
 | **智能家居** | 安防类产品涉及的音视频和图片，设备厂家作为数据控制者时，必须提供独立的隐私通知，应用界面必须有设备厂家品牌标识；音视频数据的传输和存储必须加密；非用户本人访问安防产品的音视频数据，必须获得用户授权。 |