Summary

  • W3C 2019 年公布的 Feature Policy 首份公开工作草案，让网页通过策略限制自身及嵌入内容使用全屏、定位、相机、麦克风等浏览器功能。
  • 2026 年 9 月的 Permissions Policy 工作草案把规则放在网页的 HTTP 响应头与单个 iframe 的 allow 属性中，再由浏览器按父页面和容器的规则计算继承结果。

一张网页可以像一座小剧院：地图在左边演，视频在右边演，结账工具在楼下演。每个节目其实住在自己的 iframe 小房间里。地图想知道访客的位置；播放器想占满屏幕；会议工具想开相机。请演员上台和把后台总钥匙交给演员，是两件不同的事。

W3C 在 2019 年 4 月发布的 Feature Policy 首份公开草案给剧院经理一张门禁表。网页可以在 HTTP 响应里写 Feature-Policy，关闭某些功能，或者只让指定来源有资格使用。草案的例子既有对全屏和定位的一刀切限制，也有把相机和麦克风留给某个嵌入来源的安排。重要的变化是：房东的决定终于跟着网页响应一起到达浏览器。

2026 年 9 月的工作草案已改名为 Permissions Policy，文本也明确说它过去叫 Feature Policy。现在的 Permissions-Policy 响应头使用结构化字典。草案给出 fullscreen=(), geolocation=() 的例子：两个空名单让整张网页及其后代都用不了这两项功能。剧院总闸已经落下，单个包厢再贴一张邀请函也开不了门。

如果房东愿意让一张嵌入式地图取得定位资格，可以在那一个 iframe 上写 allow="geolocation"。响应头负责划定允许的来源范围，allow 负责选中具体房间。2026 年草案展示了先在总名单中写入自家与指定来宾来源，再给特定 iframe 授权的组合。隔壁的视频包厢不会因为离地图近，就顺手捡到定位钥匙。

钥匙还要沿楼层往下传。每种受策略控制的功能都有默认允许名单。父页面在响应头里声明自己的政策。嵌入框架带来容器政策。子页面创建或导航时，浏览器根据父页面与容器政策算出继承状态。子页面可以在继承到的范围内再安排自己的规则；父页面已经锁死的门，它在房内喊得再响也打不开。

因此，把第三方内容装进 iframe，解决的只是它住在哪里，不会自动回答它能做什么。定位、相机、麦克风和全屏都把房间内的动作带到读者眼前。网页设计者需要精确欢迎某个组件，也要精确限制它带来的能力。策略让这种选择成为浏览器可执行的门禁，而不是页面开发者口头说一句“应该安全”。

2026 年草案还让门禁结果可以被查看。文档能通过 document.permissionsPolicy 查询某项功能是否可用，iframe 元素也有对应视角。地图若拿不到定位资格，就可以摆出地址输入框；会议工具拿不到相机资格，就别把快门按钮摆在台中央。策略决定功能资格。读者是否同意分享数据、设备是否真的存在，是后续各自的关卡。

W3C 的发布历史一路列到 2026 年 9 月的工作草案。网页里寄住的外部组件越来越多，浏览器的本领也越来越大。那只钥匙圈，终于从页面的模糊信任，变成可沿父页、嵌入框和子页逐层点验的规则。