浏览器工作流中的隐私设计
围绕用途、必要的最少数据、用户选择、情境边界和重复复查来规划浏览器工作流隐私。
为浏览器工作流设计隐私，意味着先决定任务需要什么，再选择设置、配置文件或数据保留方式。从用户目标出发，找出支持该目标的浏览器和网站交互，然后限制数据的收集、共享、关联和保留。这种方法能把“更注重隐私”之类的宽泛意图，转化为日常工作中可以检查的一组决定。
浏览器工作流可能包括打开页面、登录、使用嵌入式服务、授予权限、保存结果以及稍后返回。每个步骤都可能涉及不同参与者和数据。某项设置可能有助于一个步骤，却会中断另一个步骤；配置文件边界可以分隔状态，却不会改变网站在请求过程中收到的信息。应围绕完整任务进行规划，而不要把某个浏览器开关当成隐私设计本身。
W3C《隐私原则》和 RFC 6973 提供的是设计指导，并不保证某个具体工作流具有隐私性或符合法律要求。它们支持一些实用问题，涉及数据最小化、用户参与、安全、情境，以及预期任务与交换信息之间的关系。跨层面浏览器隐私指南说明了为什么应分别考虑浏览器、网站、账户和网络边界。
明确任务及其边界
把任务写成一个人需要达成的结果，而不是一份要启用的设置清单。“查看公开页面并保留结果副本”提供了可评估的用途。“打开所有隐私选项”却没有说明哪些信息是必要的、哪些网站功能必须继续运行，或之后应保留什么状态。明确的用途能为之后的每个决定提供理由和停止点。
描述从开始到结束的常规路径。包括打开的页面或服务、是否登录、使用的功能、保留的输出，以及任务何时完成。不要为了让流程说明看起来完整，就记录无关账户内容或某人的浏览历史。只保留推理该工作流所需的描述细节，并在任务改变时重新检查。
列出与任务相关的参与者：用户、浏览器、网站、账户提供方、扩展程序、嵌入式服务，以及会改变路径的受管理设备或网络。不要假设每个参与者看到的信息都相同。浏览器可以保存本地偏好，网站可以收到请求数据，账户则可以把活动关联到已登录用户。浏览器配置文件管理指南介绍了配置文件如何为浏览器状态提供独立位置，同时不抹去这些其他关系。
为每个步骤设定边界。询问用户提供什么、浏览器补充什么、网站需要返回什么，以及哪些状态应在该步骤后继续存在。权限提示、Cookie、上传的文件或已保存的偏好可能各有不同用途。把它们统称为“浏览器数据”，会让人更难发现不必要的访问或保留。
对于重复进行的工作，应区分预期结果与当前采用的具体路径。由于任务早期版本的需要，工作流可能逐渐增加了额外登录、复制的值或保留的结果。检查每个步骤是否仍支持当前用途。删除已经过时的步骤，可以在不改变结果的前提下，减少涉及的信息和用户需要理解的选项。
用日常语言记录边界，让使用该工作流的人能够理解。说明任务、发生任务的情境，以及其状态应结束还是继续的时间点。“让此配置文件在之后访问时保留该偏好”比“保护隐私”更可执行。清晰的说法也有助于团队讨论变更，而不必依赖某个人记得当初选择某项设置的原因。
明确需要的隔离方式。某个工作流可能需要为不同账户或任务设立独立情境；另一个工作流则可能需要在一个配置文件中保持连续性，让用户偏好继续可用。两种选择都不能一概而论地说更注重隐私。说明哪些情境应共享状态、哪些应保持分离，以及改变边界后用户能看到什么影响。
在整个工作流中减少数据
针对每个步骤，询问实现既定目标需要哪些信息。包括用户输入的数据、附在请求中的信息、本地状态、权限，以及网站或浏览器保存的输出。“必要”应与任务相关，而不是泛指服务可能请求或浏览器可能暴露的一切。如果更少的信息就能实现目标，较小规模的信息交换通常更容易解释和复查。
把收集与使用、披露和存储分开考虑。工作流可能在一个步骤收集某个值，将它传给另一个参与者，并在任务结束后继续保留。每项操作都应有独立理由。RFC 6973 从收集、使用、披露和存储等方面描述数据最小化，并指出减少交换的数据可降低可被滥用或泄露的数据量。这是一种设计方向，并不表示删除一个字段就会消除所有风险。
检查可以避免的重复。网站可能要求用户再次提供当前任务中已有的信息，或者工作流在生成所需输出后仍保留中间结果。确认重复操作是否支持用户目标、可靠性或必要的恢复路径。如果不支持，就删除多余步骤或缩短保留时间。不要只因为副本将来或许有用，就一直保存它。
考虑身份是否需要跨情境持续存在。已登录账户可以让操作连续起来，但也可能把用户原本希望分开的行为关联起来。W3C 指南指出，用户代理应帮助用户在每种情境中呈现所需身份，并在适当时支持或阻止识别。实际规划时，应确定哪些任务需要账户连续性，并避免默认将该身份带入无关情境。
相关情境可能由任务、账户、网站或配置文件定义，而这些边界不一定重合。两个网站可能使用同一个账户，一个网站也可能承载预期不同的多个任务。写清楚用户在意的是哪种区别，以及哪个系统实际控制该区别。不要仅仅因为使用了不同的浏览器窗口，就把两个情境描述为互相隔离，如果同一账户或服务仍会关联它们的活动。
数据最小化也适用于可观察性和故障排查。只保留理解故障所需的诊断细节，并限制可查看的人数和保留时长。实用记录可以注明任务阶段和可见错误，而无需复制页面内容、凭据或无关浏览活动。如果工作流需要长期保留记录，就写明用途和负责人，确保持续保留是有意决定。
检查完整的信息路径，而不只是第一条请求。某个值可能会被复制到表单、作为下载返回、保存在浏览器中，或加入支持记录。每次交接都可能扩大其受众或延长其留存时间。确定任务在哪里需要该值、何处可以丢弃，以及更简略的结果是否可行。这样，最小化就适用于从输入到完成的整个工作流，而不只是起始页面。
提供用户能理解的选择
人们需要在某项决定影响任务时理解它。选择应说明将共享或保留什么、涉及哪个参与者，以及用户拒绝后会发生什么。含糊的“允许访问”提示，没有解释访问权限适用于一次操作、一个网站还是之后的访问。用户确认之前，文字和控件应让范围清晰可见。
使用能够满足需求的最窄权限，并说明其持续时间。一次性操作、当前网站设置和配置文件范围的偏好是不同选择。如果较窄的选项能满足任务，就不要让宽泛或长期权限成为唯一可行途径。如果拒绝会导致某项功能无法使用，应说明这一后果，但不要暗示用户必须接受该请求才能使用工作流中无关的部分。
提供之后复查和更改重要选择的途径。用户可能需要撤销权限、移除网站例外、退出登录或清除保留状态。让控制入口容易找到，并说明会发生什么变化。如果用户无法判断选择是否生效，或无法合理地撤销它，那么表面上的选择就很有限。
让默认值符合常规任务和用户表达的偏好。默认值可以减少重复决定，但不应悄悄扩大数据收集，也不应把一次性需求变成持续访问。如果工作流有实质不同的用途，应在相应边界呈现相关选择，而不是不作说明地沿用某项设置。
确保拒绝请求是一条真实且易懂的路径。说明拒绝会阻止某个可选功能、暂停任务，还是需要改用其他途径。如果任务无法继续，就不要把选择说成可选；如果接受会改变今后的访问，也不要暗示它毫无影响。用户应能准确了解眼前后果和任何重要的持续影响，然后作出决定。
检查这些选择是否适合无障碍需求和不同熟悉程度的用户。标签应易懂，控件应能通过辅助技术操作，结果也不应只靠颜色表示。不要迫使用户在完成必要任务和理解未解释的数据请求之间二选一。浏览器权限指南将权限视为独立的浏览器层面，说明它值得单独复查。
在保持必要连续性的同时分隔情境
根据哪些内容应该关联、哪些不应关联来选择情境边界。不同配置文件可以分开某些浏览器管理的状态，例如网站数据、扩展程序和偏好。它们不能阻止网站收到请求所需的信息，不能更改账户提供方的记录，也不能替代网络控制。应说明边界能做什么、不能做什么，避免用户推断出更广泛的保证。
从用户角度检查边界。如果目的是让工作偏好与个人浏览分开，就要确认哪些浏览器管理的状态应有所不同，以及用户能否在输入信息前识别当前情境。可见标签或配置文件名称能帮助用户注意到切换，但它们本身不会改变数据流。工作流应清楚体现这种区别，并由实际保存状态的控件提供支持。
如果分隔需要跨任务或会话持续存在，就使用不同情境。为每个情境明确用途，并确定维护负责人。不要毫无理由地创建许多短期配置文件：情境越多，设置和保留数据可能越多，也越容易留下过时例外。如果单项任务只需临时区分，范围更窄的网站或会话控制可能更容易理解和维护。
如果用户目标需要连续性，就保留相应状态。已保存偏好、账户会话或未完成的结果可能是任务正常运行所必需的。清除或分区状态前，先确定依赖它的内容，以及是否能用更少状态达成同一结果。隐私变更若意外移除必要的恢复途径，也会造成实际成本。
将网站例外纳入情境设计的复查。例外可以恢复某项功能，但也可能改变网站可以访问哪些状态。让用途具体、范围狭窄，并明确复查时间。任务不再需要时就移除，然后确认常规边界已恢复。不要把例外当作尚未弄清工作流时的通用解决方案。
当网站或功能依赖跨越边界的状态时，寻找能恢复预期任务的最小变更。确认哪个网站和功能需要该变更、它是否会超出当前任务持续，以及它会开放哪些状态。随后测试常规路径，确保其他情境没有被意外改变。如果控制范围不清楚，就暂停并查阅浏览器当前帮助，不要猜测并扩大例外范围。
考虑浏览器配置文件无法控制的环境其他部分。网站可能会把活动关联到账户，扩展程序有自己的权限，受管理设备可能实施组织级政策。配置文件边界只是整体安排中的一层。涉及多个账户或情境的任务，应说明哪些边界由本地控制，哪些取决于网站或服务。
测试、复查并调整设计
测试完整的用户任务，包括常规成功路径，以及合理的拒绝或失败路径。确认用户能完成预期结果、理解相关选择，并在之后返回已知状态。评估隐私控制时每次只改变一项，以便将可见差异与相应变更关联起来。浏览器版本和任务条件有助于复现结果时，也应记录它们。
检查工作流交换的信息是否没有超过既定用途所需的范围。复查权限、账户使用、网站例外、已保存数据，以及嵌入式服务的角色。检查应与任务规模相称：简单的个人工作流可能只需简短清单，共享或重复流程则可能需要明确负责人和定期复查。文档更多并不自动意味着隐私效果更好。
采用与设计决定相符、能够观察的检查方式。确认预期任务能完成，用户能看到相关选择，并且需要的状态在合适时间保留或移除。如果设计中包含权限或例外，就检查其可见范围，并确认更改它会产生预期结果。这些检查不会揭示网站或账户采取的每项操作，因此应将它们描述为对已测试工作流的证据，而不是完整隐私的证明。
同时留意隐私问题和可用性问题。跨情境状态意外连通、权限范围不清，或没有当前用途的保留数据，都可能说明设计需要调整。反复阻断无障碍功能或丢失必要结果的工作流也一样。准确描述观察到的现象，并区分浏览器显示的内容与对网站或账户的推断。
当用途、参与者、浏览器行为或网站依赖发生变化时，重新评估设计。浏览器更新可能改变控件的位置或网站行为；新账户或共享设备也可能改变哪些边界很重要。应在实际使用的版本和情境中确认相关选择，而不要依赖旧说明。如果工作流本身发生变化，也要更新用途和数据保留决定。
保持控件数量少且易于理解。移除已不再服务于任务的权限、例外和保留数据。只在明确的期限或用途内保留必要状态，并指定负责人复查共享工作流。隐私设计是一系列持续的选择，不是一次性设置，也不能证明没有信息会被观察到。
选择与实际变化相对应的复查时机：用途改变、账户不同、浏览器更新、网站依赖变化，或工作流开始使用共享设备。复查时，核对用户实际看到的选择，而不要假设书面说明仍与界面相符。如果没有实质变化，就保留当前设计并注明下次复查时间；如果确有变化，就更新受影响的边界并重新测试任务。
设计良好的浏览器工作流会明确用途、限制不必要的数据、让用户拥有有意义的控制，并在需要时区分不同情境。同时，它也会保留完成任务所需的状态和访问能力。结果不是普遍适用的隐私保证，而是一套人们能够说明、使用并在需求改变时重新审视的设计。
