隐私中心
91次元的隐私说明以“收什么、为什么收、保留多久、用户能做什么”为基本结构。未启用的功能不应为了显得完整而虚构数据处理流程。
访问数据
网站正常运行可能产生基础访问日志，例如请求时间、页面地址、浏览器请求信息与安全排错所需的技术数据。此类信息的用途应限制在运行维护、安全防护和故障定位，不应被描述成与实际功能无关的画像系统。
如果后续接入新的统计方式，应在上线前更新隐私说明，并说明用途和影响。
应用权限
移动应用需要系统权限时，应遵循最小必要原则。与核心阅读无关的权限不应默认申请；确实需要通知、存储或其他能力时，应在请求前解释用途，并允许用户在系统设置中撤回。
撤回某项权限后，只应影响依赖该权限的功能，而不应通过无关限制强迫用户重新授权。
用户资料
本站不设置虚假账户体系，也不以充值、付费点播或会员等级诱导用户提交额外个人资料。若未来出现需要用户主动提交的信息，应明确字段用途、是否必填以及保存方式。
不应因为“可能以后用到”就提前收集。
反馈处理
用户提交资料更正、版权反馈或意见建议时，只需要提供足以定位问题的信息。对于涉及权利证明的材料，应限制访问范围，并在问题处理结束后根据实际需要决定是否继续保留。
反馈内容不得被擅自公开为宣传素材，除非用户明确同意。
用户权益
用户有权了解数据如何被使用、要求更正不准确资料，并在适用情况下提出删除或停止处理请求。站点的隐私机制应尽量用普通语言解释，不把关键限制藏在难以理解的长句中。
当隐私规则发生实质变化时，应通过清楚方式提醒，而不是悄悄替换旧说明。
隐私设计原则
隐私不是单独的一页文字，而应体现在功能设计里。搜索能够本地完成时就不必上传查询词，普通阅读无需账户时就不该强迫注册，权限不影响核心功能时就不应被设为必选。若未来增加新功能，最先要回答的是“为什么需要这项数据”，其次才是如何存储。用户也应获得容易找到的撤回、修改和反馈路径，而不是只能接受一次性的默认同意。
补充说明
技术上能收集并不等于应该收集。访问日志、搜索交互与反馈数据都应围绕明确目的设置边界，并尽量缩短保留范围。出现安全事件或数据处理异常时，优先停止不必要处理、确认影响范围，再更新说明与处置方式，而不是用模糊表述掩盖变化。