弃用并移除“basic-card”支持付款处理程序
此版本的 Chrome 移除了适用于 Payment Request API 的基本卡 polyfill 。因此，以下国家/地区已暂时停用 Payment Request API： iOS 版 Chrome。如需了解完整详情，请参阅重新思考 iOS 付款请求。
打算移除 | Chrome 平台状态 | Chromium bug
从 BasicCardRequest 中移除了 supportedType 字段
为 "basic-card" 付款方式指定 "supportedTypes":[type] 参数
仅显示所请求的类型的卡片，这些类型包括“credit”、“"debit"”或
"prepaid"。
卡片类型参数已从规范中移除，现已从 Chrome，因为难以准确确定卡片类型。商家 今天必须和 PSP 确认银行卡类型，因为他们无法信任该卡 在浏览器中输入过滤器：
- 只有发卡银行知道可下载的银行卡的类型 类型数据库的准确度很低，因此无法准确了解 浏览器中本地存储的银行卡类型。
- “basic-card”Chrome 中的付款方式不再显示 Google 提供的卡 Pay，它可能与发卡银行有联系。
打算移除 | Chrome 平台状态 | Chromium bug
移除 元素
Chrome 81 移除了 <discard> 元素。它只在 Chromium 中实现，
因此无法互操作。对于大多数应用场景，
替换成了 display 属性的动画和移除的组合
(JavaScript) 回调/事件处理程序。
打算移除 | Chrome 平台状态 | Chromium bug
移除 TLS 1.0 和 TLS 1.1
TLS（传输层安全协议）是保护 HTTPS 的协议。它具有 TLS 1.0 问世已近二十年， SSL。TLS 1.0 和 1.1 都存在许多弱点。
- TLS 1.0 和 1.1 在转写哈希值中使用 MD5 和 SHA-1 这两种弱哈希 显示“已完成”消息
- TLS 1.0 和 1.1 在服务器签名中使用 MD5 和 SHA-1。（注意：这不是 证书中的签名。）
- TLS 1.0 和 1.1 仅支持 RC4 和 CBC 加密方式。RC4 已损坏， 已移除。TLS 的 CBC 模式结构存在缺陷，并且容易受到 攻击。
- TLS 1.0 的 CBC 加密还构建了它们的初始化矢量 错误。
- TLS 1.0 不再符合 PCI-DSS 标准。
支持 TLS 1.2 是避免上述问题的前提条件。TLS 工作组已弃用 TLS 1.0 和 1.1。Chrome 现在也弃用了 这些协议
打算移除 | Chromestatus Tracker | Chromium bug
绕过 TLS 1.3 降级安全强化
TLS 1.3 包含向后兼容的安全强化措施，可加强降级保护。 但是，去年推出 TLS 1.3 时，我们不得不部分停用 是由于与某些不合规的 TLS 终止不兼容而采取的措施 代理。Chrome 目前对证书实施了安全强化措施 链接到已知根，但可以绕过证书链接 未知的根。我们打算为所有连接启用此功能。
降级保护可减轻各种旧版选项对安全性的影响 以保持兼容。这意味着用户的连接更加安全， 如果系统发现安全漏洞，就不那么费时 回复。（这也意味着，对 road.)这也与 RFC 8446 一致。
打算移除 | Chrome 平台状态 | Chromium bug
废弃政策
为了确保平台的健康运行，我们有时会从 Web 平台中移除运行正常的 API。我们移除内容的原因可能有很多种 API，例如：
- 它们已被较新的 API 取代。
- 为反映规范变更，我们更新了这些政策，以便与其他浏览器保持一致和一致性。
- 这些是早期实验，在其他浏览器中从未实现过，因此可能会增加网络开发者的支持负担。
其中一些更改只会影响极少数网站。为了提前缓解问题，我们会尽量提前通知开发者，以便他们做出必要更改，确保网站正常运行。
Chrome 目前有 弃用和移除 API 的流程，实质上是：
- 在 blink-dev 邮寄名单中发布公告。
- 当在网页上检测到使用情况时，您可以在 Chrome 开发者工具控制台中设置警告并指定时间刻度。
- 等待、监控，然后在使用量下降时移除该功能。
您可以在 chromestatus.com 上使用 “已弃用”过滤条件 查找所有已弃用功能的列表，也可以使用“已移除的过滤条件”应用“已移除”过滤条件查看已移除的功能。我们还将尝试总结这些博文中的一些更改、推理和迁移路径。