Chrome 公开意图弃用基于非安全源的地理定位等强大功能，我们希望其他组织也能效仿。
从 Chrome 50 开始，Chrome 不再支持使用 HTML5 Geolocation API 从非安全连接提供的网页中获取用户的位置信息。这意味着，发出 Geolocation API 调用的网页必须从 HTTPS 等安全上下文提供。
这是一个非常重要的问题，因为它将直接影响需要使用 Geolocation API 且不通过 https 提供的任何网站，但我们相信这是一项对网络上的所有用户都有益的更改。这篇博文应该有助于您了解原因和后续操作。
此项更改何时生效？
此项变更自 Chrome 50（太平洋标准时间 2016 年 4 月 20 日中午 12 点）起生效。
从版本 44（2015 年 7 月 21 日发布）开始，Chrome 的开发者工具控制台开始提供警告。
有许多公开声明对我们做出这一变更的理由进行了说明（以及相关讨论）：
- 打算通过 HTTP 弃用一系列强大的功能（2015 年 2 月）
- 打算通过 HTTP 弃用 Geolocation API（2015 年 11 月）
- Chrome 开发者峰会（2016 年 11 月）
- Chrome 测试版 发布博客（2016 年 3 月 17 日）
- Chrome 状态网站
还有一些其他来源也重点介绍了这一点： Mobiforge（2016 年 1 月 26 日）、《连线》（2016 年 3 月 17 日）、VentureBeat（2016 年 4 月 13 日）。
为什么要进行此变更？
位置属于敏感数据！必须使用 HTTPS，以保护用户位置数据的隐私。如果用户的位置可通过不安全的情境获得，网络上的攻击者将能够知道用户的位置。这严重损害了用户隐私。
此更改会影响哪些人？
这会影响通过 HTTP（非安全）提供的网页中目前使用 Geolocation API 的所有网页。如果 HTTPS iframe 嵌入到 HTTP 网页中，则使用 Geolocation API 的 HTTPS iframe 也会受到影响。（您无法使用 HTTPS 传送的共享帧进行 polyfill 操作）。
我的整个 Web 应用是否需要 HTTPS？
使用地理定位功能并不要求通过 HTTPS 提供整个应用。只有使用地理定位的网页才需要通过安全上下文提供内容。安全上下文目前是指托管在 HTTPS 或 localhost 上的顶层的任何内容。例如，如果 iframe 指向安全来源但托管在不安全的来源 (http ://paul.kinlan.me/)，则不允许调用 Geolocation API。
由于强大的新浏览器和现有浏览器功能需要安全的��，我们强烈建议您迁移到 HTTPS。
这是否会影响本地开发？
它不应如此，因为规范中声明了 localhost 为“潜在安全”，在本例中，通过 localhost 在顶层传送的地理定位请求仍可正常使用。
我能否在运行时检测地理定位是否因不在安全上下文中而被阻止
是。地理定位规范定义了一个 PositionError 对象，该对象会传递到 Geolocation API 的失败回调中。该对象定义了 code 和 message 属性。
此安全上下文问题所导致的错误将返回 code 1，即“权限遭拒错误”。
如果用户拒绝授予访问权限或系统拒绝访问用户的位置信息，您可能会收到此错误。也就是说，您必须查看邮件，了解确切原因。
这可能非常脆弱，因为它将来可能会发生变化，但查找“仅允许安全源”字符串是一种较明显的信号，表明这是非安全内容问题。
navigator.geolocation.getCurrentPosition(success => {
/* Do some magic. */
}, failure => {
if (failure.message.startsWith("Only secure origins are allowed")) {
// Secure Origin issue.
}
});
请注意，您不能只是检查网页的来源，因为您的网页可能位于 https 上，但却位于从不安全的上下文中托管的 iframe 内。
我真的需要使用地理定位；我该怎么办？
如果您想使用 HTML5 Geolocation API，或者您的网站已经使用 Geolocation API，请将��用 Geolocation API 的网页迁移到 HTTPS，确保在安全环境中使用它们。
有许多后备选项可用于获取不受此更改影响的用户位置，例如 Google Maps Geolocation API、GeoIP（例如，还有其他基于地理位置的解决方案）以及用户输入的邮政编码。不过，确保持续访问地理定位的最佳途径是改用 HTTPS。