ב-Chrome יש כוונה ציבורית להוציא משימוש תכונות חזקות כמו מיקום גיאוגרפי ממקורות לא מאובטחים, ואנחנו מקווים שאחרים ילכו בעקבותינו.
החל מ-Chrome 50, אין יותר תמיכה ב-Chrome בקבלת המיקום של המשתמש באמצעות HTML5 Geolocation API מדפים שנשלחים בחיבור לא מאובטח. כלומר, הדף שמבצע את הקריאה ל-Geolocation API חייב להופיע מהקשר מאובטח, כמו HTTPS.
זוהי בעיה חשובה כי היא תשפיע ישירות על כל אתר שדורש שימוש ב-Geolocation API ולא מוצג באמצעות https. עם זאת, אנחנו מאמינים שמדובר בשינוי שיביא תועלת לכל המשתמשים באינטרנט. הפוסט הזה אמור לעזור לך להבין את הסיבה לכך ואיך להמשיך.
מתי זה קורה?
השינוי הזה ייכנס לתוקף ב-Chrome 50 (בשעה 12:00 (שעון החוף המערבי של ארה"ב) ב-20 באפריל 2016).
מסוף הכלים למפתחים של Chrome מספק אזהרות מאז הגרסה 44 (שפורסמה ב-21 ביולי 2015).
פרסמנו כמה הודעות ציבוריות שבהן מתוארת הסיבה (והדיון) לשינוי הזה:
- כוונה להוציא משימוש קבוצה של תכונות חזקות ב-HTTP (פברואר 2015)
- כוונה להוציא משימוש את Geolocation API דרך HTTP (נובמבר 2015)
- Chrome Dev Summit (נובמבר 2016)
- ערוץ הבטא של Chrome – פוסט בבלוג על הגרסה החדשה (17 במרץ 2016)
- האתר סטטוס Chrome
מקורות נוספים שציינו זאת: Mobiforge (26 בינואר 2016), Wired (17 במרץ 2016), VentureBeat (13 באפריל 2016).
למה Google מבצעת את השינוי הזה?
המיקום הוא מידע אישי רגיש! דרישה לשימוש ב-HTTPS נדרשת כדי להגן על הפרטיות של נתוני המיקום של המשתמשים. אם המיקום של המשתמש זמין בהקשר לא מאובטח, תוקפים ברשת יוכלו לדעת איפה המשתמש נמצא. מצב כזה מסכן מאוד את פרטיות המשתמשים.
על מי השינוי הזה משפיע?
השינוי הזה משפיע על כל דף שבו נעשה כרגע שימוש ב-Geolocation API מדפים שמוצגים באמצעות HTTP (לא מאובטח). הוא משפיע גם על תגי iframe של HTTPS שמשתמשים ב-Geolocation API אם הם מוטמעים בדפי HTTP. (לא תוכלו לבצע polyfill באמצעות מסגרת משותפת שמועברת ב-HTTPS).
האם כל אפליקציית האינטרנט שלי צריכה להשתמש ב-HTTPS?
לא נדרש שהאפליקציה כולה תוצג באמצעות HTTPS כדי להשתמש במיקום גיאוגרפי. רק דפים שמשתמשים במיקום גיאוגרפי צריכים להופיע בהקשר מאובטח. בהקשר מאובטח נכלל כרגע כל מה שמתארח ברמה העליונה ב-HTTPS או ב-localhost. לדוגמה, לא תהיה אפשרות לקרוא ל-Geolocation API מ-iframe שמפנה למקור מאובטח אבל מתארח במקור לא מאובטח (http ://paul.kinlan.me/).
מומלץ מאוד לעבור ל-HTTPS, כי יש צורך במקורות מאובטחים כדי להשתמש בתכונות חדשות ועוצמתיות של הדפדפן.
האם זה משפיע על הפיתוח המקומי?
לא, localhost הוכרז כ'בטוח פוטנציאלית' במפרט, ובמקרה שלנו בקשות למיקום גיאוגרפי שמוצגות ברמה העליונה דרך localhost עדיין יפעלו.
האם אפשר לזהות בזמן הריצה אם המיקום הגיאוגרפי נחסם כי הוא לא נמצא בהקשר מאובטח
כן. במפרט של המיקום הגיאוגרפי מוגדר אובייקט PositionError שמוענק ל-callback של קריאה חוזרת במקרה של כשל בממשקי ה-API למיקום גיאוגרפי. האובייקט מגדיר את המאפיינים code ו-message.
שגיאות שנובעות מהבעיה הזו של הקשר מאובטח יחזירו ערך code של 1, שהוא 'שגיאת אישור נדחה'.
השגיאה הזו יכולה להופיע אם המשתמש דחה את הגישה או שהמערכת דחתה את הגישה למיקומים של המשתמש. לכן, תצטרכו לבדוק את ההודעה כדי לראות מה הסיבה המדויקת.
הבדיקה הזו עלולה להיות לא יציבה כי היא עשויה להשתנות בעתיד, אבל סימן חזק לכך שמדובר בבעיה של תוכן לא מאובטח הוא חיפוש המחרוזת 'Only secure origins are allowed'.
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 כדי להבטיח גישה שוטפת למיקום הגיאוגרפי.