微软提出向 Webmanifest 添加应用变更日志的标准

本文档旨在作为一个起点，让社区和标准机构参与开发适合标准化的协作解决方案。随着本文档中描述的问题的解决方案在标准轨道上取得进展，我们将保留本文档作为存档，并使用此部分使社区了解最新的标准场所和未来工作的内容位置，以及讨论。当一个本地软件的新版本推出时，用户通常会通过他们的操作系统或他们使用的应用程序商店中的通知来了解。相比之下，网络是常青树，这意味着构建在它之上的软件始终是最新的。因此，没有正式的“时刻”可以让基于 Web 的软件的开发人员通知他们的用户他们的软件从一个版本到另一个版本发生了什么变化（例如，添加了新功能，修复了哪些错误）。提供显示版本历史的标准化方法将使开发人员能够显示这些有用的——有时是关键的——信息。 Manifest.json 更改不会反映在已安装的 PWA 中，直到用户代理认为需要更新。我们打算通过相同的机制更新此功能。当 PWA 开发人员更新 manifest.json 中与版本历史相关的部分时，用户代理应该认为更新是必要的。更新完成后，用户代理可以选择发布有新的更新。用户代理应该有一些机制来指示自用户上次查看更改以来已经推送了新的更改日志版本。大多数 PWA 都会定期更新。通过为最终用户提供有关这些更新的信息的访问权限，他们对应用程序的理解将得到改善。其他好处可能包括： 用户代理可能会选择以类似于公开证书和 cookie 信息的方式公开版本历史记录。在这个动画 GIF 中，用户选择浏览器的三点 (...) 菜单，然后选择“应用信息”，最后选择“版本历史”。这会导致在新窗口中呈现应用程序的版本历史记录。本说明中提出的解决方案是向 Web App Manifest 添加一个可选成员：changelog。

更改日志成员将是一个带有两个键的字典：当前版本 (version) 和定义版本历史 (history) 的一个或多个资源 URL 序列：可选。当前版本名称的人类可读标签。此版本用于表示远程网站所提供内容的版本。如果提供，用户代理将使用它来在此数字更改时发布更新。一个或多个资源的路径。实现者应该根据提供的 MIME 类型信息选择他们可以呈现的第一个资源。注意：历史旨在显示不同格式的变更日志，而不是不同版本的不同变更日志。在大多数情况下，我们怀疑只会提供一种历史资源，但我们也认识到记录版本历史的格式有很多，我们希望尊重这一点。我们建议可接受的格式包括 HTML、RSS/Atom 和 JSONFeed。用户代理可自行决定是否支持其他格式（Markdown 等）。这个可接受的格式列表可能会随着时间的推移而增长。资源旨在作为枚举相同变更日志信息的不同格式的一种方式。当用户选择“版本历史”时应加载的 url。此 URL 必须存在于清单的范围内。如果 manifest-url 是相对 URL，则基本 URL 将是清单的 URL（例如，Twitter 的发行说明）。

提供在 url 中找到的文件的 MIME 类型。至少，可接受的 MIME 类型包括 text/html、application/rss+xml、application/atom+xml 和 application/json。此变更日志信息将定义“1.0.1”的当前版本字符串和单个 HTML 格式的历史资源，可从“https://foo.com/history”获得。版本历史的呈现应该在浏览器窗口中进行。如果版本历史资源的格式不是 HTML，则鼓励实现者将版本历史数据强制转换为语义 HTML 并使用其默认浏览器样式呈现它。如果实现者将数据提要强制转换为 HTML，则应注意对历史进行排序，以使最近的项目位于顶部。实现者可以自由地尝试逐步公开版本信息（例如，手风琴小部件、合理的截断），前提是历史记录中的最新项目被完整显示。 iOS App Store 当前显示版本名称、发布日期以及对每个版本所做更改的简要说明： Microsoft Store 当前显示最新版本随附更改的概述：

预计不会有重大的隐私问题。通过特征检测进行指纹识别的风险很低，因为网页无法判断用户代理是否不支持变更日志，或者用户根本没有触发它。如果用户确实触发了它，我们可能会透露我们是支持此更改日志功能的浏览器。主要的安全问题是用户代理需要处理来自网络的不可信数据源。抛开用户需要从网站安装 PWA 本身——用户代理需要小心他们如何处理数据馈送，以防它们是恶意的。用户代理需要注意不要尝试在特权代码中处理这些不受信任的数据集。正确完成的风险与在相对受信任的站点上运行任意 javascript 的风险相同（因为用户已经安装了 PWA）。 HTML 更改日志不是一个特别的安全问题，因为这不会比标准导航更具风险。