Chrome 公开有意弃用针对非安全起点的地理定位等强大功能，我们希望其他功能也能如此。
从 Chrome 50 开始，Chrome 不再支持使用 HTML5 Geolocation API 从非安全连接提供的网页中获取用户的位置信息。这意味着，必须从安全上下文（例如 HTTPS）提供调用 Geolocation API 的网页。
这是一个重要的问题，因为它将直接影响需要使用 Geolocation API 且不通过 https 提供的任何网站，但我们相信这一变化对网络上的所有用户都有益。这篇博文应该能帮助您了解原因和后续操作。
此项更改何时生效？
此项变更从 Chrome 50（2016 年 4 月 20 日中午 12 点（太平洋标准时间）起）开始生效。
自 2015 年 7 月 21 日发布的版本 44 以来，Chrome 的开发者工具控制台一直显示警告。
一些公告中说明了我们做出此项变更的理由（和讨论）：
- 计划弃用一组通过 HTTP 的强大功能（2015 年 2 月）
- 计划通过 HTTP 弃用 Geolocation API（2015 年 11 月）
- Chrome 开发者峰会（2016 年 11 月）
- Chrome Beta 版发布博客（2016 年 3 月 17 日）
- Chrome 状态网站
还有许多其他来源也着重介绍了这一信息：Mobiforge（2016 年 1 月 26 日）、Wired（2016 年 3 月 17 日）、VentureBeat（2016 年 4 月 13 日）。
为什么要进行此变更？
位置信息属于敏感数据！必须使用 HTTPS 来保护用户位置数据的隐私。如果用户的位置信息可从非安全上下文获得，则网络上的攻击者能够知道该用户所处的位置。这会严重危及用户隐私。
此更改会影响哪些人？
这会影响当前使用 Geolocation API 的所有网页以及通过 HTTP（非安全）提供的网页中。如果 HTTPS iframe 嵌入 HTTP 网页中，使用 Geolocation API 也会受到影响。（您将无法使用通过 HTTPS 传送的共享帧执行 polyfill 操作。）
我的整个 Web 应用都需要使用 HTTPS 吗？
不要求通过 HTTPS 提供整个应用以使用地理定位。只有使用地理定位的网页才需要通过安全上下文提供。安全上下文目前是在 HTTPS 或 localhost 上的顶层托管的任何内容。例如，如果 iframe 指向某个安全的来源，但托管在不安全的来源 (http ://paul.kinlan.me/) 上，则不能调用 Geolocation API。
我们强烈建议您迁移到 HTTPS，因为新的和现有的浏览器功能强大，需要安全的源。
这是否会影响本地开发？
不应使用 localhost，因为已在规范中将 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。