在 Chrome 50 版中,將 Geolocation API 從不安全的來源移除

Chrome 的公開意圖會淘汰有關不安全來源的強大功能,例如我們希望其他來源也能加以使用。

從 Chrome 50 版開始,Chrome 不再支援透過不安全的連線傳送的網頁使用 HTML5 Geolocation API 取得使用者的位置資訊。這表示要進行 Geolocation API 呼叫的網頁都必須透過安全內容 (例如 HTTPS) 提供。

這個問題非常重要,因為這會直接影響所有需要使用 Geolocation API 且並非透過 https 提供的網站。這篇文章應該有助您瞭解原因和後續處理方式。

何時變更名稱?

這項異動已於 Chrome 50 (太平洋標準時間 2016 年 4 月 20 日下午 12 點) 生效。

Chrome 的開發人員工具控制台自 44 版 (2015 年 7 月 21 日推出) 以來就已出現警告。
有許多人公開公告,說明我們進行這項調整的原因 (並探討其原因):

還有許多其他來源醒目顯示了以下內容: Mobiforge (2016 年 1 月 26 日)、Wired (2016 年 3 月 17 日)、VentureBeat (2016 年 4 月 13 日)。

我們進行這項異動的原因為何?

位置資訊屬於機密資料!要求 HTTPS 機制能保護使用者位置資料的隱私。如果系統可透過不安全的情境取得使用者位置,網路的攻擊者就能知道使用者的所在位置。這會嚴重危害使用者隱私。

這項異動的影響對象?

這項異動會影響目前透過 HTTP (非安全) 提供網頁,使用 Geolocation API 的任何網頁。如果 HTTPS iframe 嵌入 HTTP 網頁, 使用 Geolocation API 的 HTTPS iframe 也會受到影響。(您無法使用共用 HTTPS 傳輸框架來建立 polyfill)。

我的整個網頁應用程式是否需要 HTTPS?

系統「不」要求整個應用程式透過 HTTPS 提供使用地理位置功能。只有使用 Geolocation 的網頁需要透過安全的情境提供。安全內容目前是由 HTTPS 或 localhost 頂層代管的任何項目。舉例來說,如果 iframe 指向安全來源,但託管於不安全的來源 (http ://paul.kinlan.me/),就無法呼叫 Geolocation API。

我們強烈建議您改用 HTTPS,因為強大的新版和現有的瀏覽器功能都需要安全來源

這會影響本機開發作業嗎?

通常,localhost 已宣告為「可能安全」,在本例中,在頂層透過 localhost 提供的地理位置要求仍可正常運作。

我可以在執行階段偵測地理位置是否因不在安全內容而遭到封鎖

可以,地理位置規格定義了 PositionError 物件,這個物件會傳入 Geolocation API 的失敗回呼。物件會定義 codemessage 屬性。

因為這個安全內容問題而發生錯誤,會傳回 1 的 code,即「權限遭拒錯誤」。 當使用者拒絕存取權,或系統拒絕存取使用者位置資訊時, 就會發生這個錯誤。這表示您必須查看郵件,瞭解實際原因。

這在日後可能會改變,雖然十分簡單,但明確表示這是不安全的內容問題,就在於尋找「僅允許安全來源」的字串。

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 APIGeoIP (例如其他地理位置解決方案) 以及使用者輸入的郵遞區號。不過,我們強烈建議確保持續存取地理位置的最佳做法,就是改用 HTTPS。