Z4.08.1Least-privilege guest access设计研究
访客权限应默认最小化并有明确的到期时间
别名: 访客最小权限 · 限时授权 · time-boxed access
概念解释
访客——来住几天的朋友、每周来的保洁、民宿住客、上门喂猫的邻居——的权限应该在创建之时就是最小化（只给需要的设备与操作）且限时（住完即失效）的，这应当是默认行为，而不是依赖主人事后记得清理。最小化限定范围，到期时间限定寿命；两个维度都要在授予的当下决定，因为那是信息最全的时刻——退房日期就写在订单上，保洁只在周二上午来。
这条针对的是普遍现实：访客授权建起来快、忘起来也快，一次性的方便变成常驻的敞口。
机制
为什么默认值必须承担这件事、而不能指望主人记得？
授予时刻是信息的峰值。 访客的目的、范围、时长在授权当下全部在场：订单上有退房时间、约定里有服务时段。这个信息随时间衰减——三天后主人已经想不起「当时给的是哪些权限」；一个月后连「给过谁」都模糊。把范围与时长的决定推迟到事后，等于把决定交给一个信息更少、动机更弱的时刻。
残留授权是不可见的风险累积。 授权完成后，它在日常生活里没有任何存在感——不产生通知、不占据界面、不影响任何功能。不可见的对象不会被清理；每次访客授权的残留概率是独立的，多次累积后家里挂着一批早已无人使用的通行权，谁也说不清有哪些。
默认的粘性。 界面默认什么，用户就接受什么——这是默认效应最经典的领域。默认「永久+全屋」，主人就得到永久+全屋；默认「限时+可选范围」，同样不加思考的点击得到的是收敛的授权。安全性质在这类系统里主要靠默认值分布，不靠用户审慎。
怎么研究
- 访问控制偏好研究：情境问卷（保洁/朋友短住/Airbnb 住客各应获得什么、多久）显示受访者在被提示时限与范围时普遍支持最小化——支持率高而实际配置率低，落差证明问题在默认设计而非意愿。
- 残留授权审计：对共享住宿平台的智能门锁授权记录做审计研究——退房后仍有效的凭据数量、存活时长分布。「退房即失效」与「永久有效直到手动清理」两种默认下的残留率对比，是限时默认价值的直接证据形态。
- 对照部署：同一批房东/住客，随机分配默认限时与默认永久的授权流程，跟踪残留授权量与误锁率（限时组因到期导致的合理进入失败）——收益与代价同测。
方法论注意点：民宿与自住家的访客语义不同（商业关系 vs 私人关系），两类场景的结论不能直接互搬；研究要标明场景，产品要分开设计默认。
边界
- 周期性访客需要常驻但受限的授权。 每周保洁走「每次限时」反而制造摩擦——对这类访客，正确的最小化是「长期有效、范围极窄」（只有门锁、只在周二上午）。最小化的是范围，不一定是寿命。
- 入口通道决定可行性。 访客装应用注册账号的流程成本高（这是另一个问题），许多场景靠门锁键盘码实现访客授权——码即凭据，限时与范围都落在码上。没有细分凭据通道的系统根本给不了「最小化」，只剩全有全无。
- 最小化的粒度受系统表达能力限制。 只能「加为家庭成员」或「不给」的系统里，这条建议无从落地——它预设系统至少支持访客级的独立凭据。
怎么落地
- 授权表单把范围与到期时间做成必填项，并从上下文预填默认值：关联到订单的自动取退房日期、选「保洁」的自动给服务时段。
- 范围选项限制在访客需要的一小集合：门锁、必要设备；摄像头回放与管理操作绝不进默认集。
- 到期前给主人预警（「张三的门锁权限明天到期」）带一键延期——访客延长停留时，延期比重建便宜。
- 验证办法：定期审计「住宿结束后 30 天仍有效的访客凭据」数量，目标趋零；同时监控「合理进入被拒」事件率（限时误伤），两个指标一起看，防止把到期时间拧得过紧。