Geolocatie-API verwijderd van onbeveiligde oorsprong in Chrome 50

Paul Kinlan

Chrome is van plan om krachtige functies, zoals geolocatie op niet-beveiligde locaties, uit te faseren. We hopen dat anderen dit voorbeeld zullen volgen.

Vanaf Chrome 50 ondersteunt Chrome niet langer het verkrijgen van de locatie van de gebruiker met behulp van de HTML5 Geolocation API van pagina's die via niet-beveiligde verbindingen worden aangeroepen. Dit betekent dat de pagina die de Geolocation API aanroept, moet worden aangeroepen vanuit een beveiligde context , zoals HTTPS .

Dit is een belangrijk probleem, omdat het een directe impact heeft op elke website die de geolocatie-API nodig heeft en niet via https wordt aangeboden. Toch geloven we dat deze verandering gunstig is voor alle gebruikers op het web. Dit bericht helpt je de redenering en de te volgen procedure te begrijpen.

Wanneer verandert dit?

Deze wijziging is van kracht vanaf Chrome 50 (12:00 uur PST, 20 april 2016).

De ontwikkelaarstoolsconsole van Chrome geeft al waarschuwingen sinds versie 44 (uitgebracht op 21 juli 2015).
Er zijn een aantal openbare aankondigingen geweest die de reden (en discussie) beschrijven waarom we deze verandering doorvoeren:

Er zijn een aantal andere bronnen die dit hebben benadrukt: Mobiforge (26 januari 2016), Wired (17 maart 2016), VentureBeat (13 april 2016).

Waarom voeren we deze verandering door?

Locatiegegevens zijn gevoelige gegevens! HTTPS vereisen is vereist om de privacy van de locatiegegevens van uw gebruikers te beschermen. Als de locatie van de gebruiker beschikbaar is vanuit een niet-beveiligde context, kunnen aanvallers op het netwerk achterhalen waar die gebruiker zich bevindt. Dit brengt de privacy van de gebruiker ernstig in gevaar.

Op wie heeft dit betrekking?

Dit is van toepassing op elke pagina die momenteel de Geolocation API gebruikt vanaf pagina's die via HTTP (niet-beveiligd) worden aangeboden. Het is ook van toepassing op HTTPS-iframes die de Geolocation API gebruiken als ze in HTTP-pagina's zijn ingesloten. (U kunt geen polyfill gebruiken met een gedeeld, via HTTPS geleverd frame.)

Heeft mijn hele web-app HTTPS nodig?

Het is niet vereist dat de hele app via HTTPS wordt aangeboden om geolocatie te gebruiken. Alleen pagina's die geolocatie gebruiken, hoeven via een beveiligde context te worden aangeboden. Een beveiligde context is momenteel alles wat op het hoogste niveau op HTTPS of localhost wordt gehost. Een iframe dat bijvoorbeeld verwijst naar een beveiligde bron , maar op een onbeveiligde bron wordt gehost ( http://paul.kinlan.me/ ), mag de geolocatie-API niet aanroepen.

Wij raden u ten zeerste aan om naar HTTPS te migreren, aangezien krachtige nieuwe en bestaande browserfuncties beveiligde bronnen vereisen .

Heeft dit gevolgen voor de lokale ontwikkeling?

Dat zou niet moeten, localhost is in de specificatie aangemerkt als "potentieel veilig" en in ons geval werken geolocatieverzoeken die op het hoogste niveau via localhost worden verzonden nog steeds.

Kan ik tijdens runtime detecteren of de geolocatie is geblokkeerd omdat er geen beveiligde context was?

Ja. De geolocatiespecificatie definieert een PositionError- object dat wordt doorgegeven aan de foutcallback van de Geolocatie-API's. Het object definieert een code en message .

Fouten als gevolg van dit probleem met de beveiligde context retourneren een code 1, wat staat voor een 'Permission Denied Error' (Fout met betrekking tot toestemming geweigerd). U kunt deze foutmelding krijgen wanneer een gebruiker de toegang heeft geweigerd of wanneer het systeem de toegang tot de locatie van de gebruiker heeft geweigerd. Dit betekent dat u het bericht moet controleren om de exacte reden te achterhalen.

Dit kan erg kwetsbaar zijn, omdat het in de toekomst kan veranderen. Toch is een sterk signaal dat het om een ​​probleem met niet-beveiligde inhoud gaat, te vinden als u zoekt naar de tekst 'Alleen beveiligde oorsprongen zijn toegestaan'.

navigator.geolocation.getCurrentPosition(success => {
    /* Do some magic. */
}, failure => {
    if (failure.message.startsWith("Only secure origins are allowed")) {
    // Secure Origin issue.
    }
});

Houd er rekening mee dat u niet zomaar de oorsprong van de pagina kunt controleren. Uw pagina kan namelijk op https staan, maar zich in een iframe bevinden dat wordt gehost in een onveilige context.

Ik moet echt Geolocatie gebruiken. Wat moet ik doen?

Als u de HTML5 Geolocation API wilt gebruiken of als uw site de Geolocation API al gebruikt, migreer dan de pagina's die Geolocation API-aanroepen doen naar HTTPS . Zorg er daarbij voor dat ze in een veilige context worden gebruikt.

Er zijn verschillende terugvalopties beschikbaar om de locatie van een gebruiker te achterhalen die niet door deze wijziging worden beïnvloed, zoals de Google Maps Geolocation API , GeoIP (er zijn bijvoorbeeld andere geogebaseerde oplossingen) en een door de gebruiker ingevoerde postcode. We raden echter sterk aan om over te stappen op HTTPS om continue toegang tot geolocatie te garanderen.

,

Paul Kinlan

Chrome is van plan om krachtige functies, zoals geolocatie op niet-beveiligde locaties, uit te faseren. We hopen dat anderen dit voorbeeld zullen volgen.

Vanaf Chrome 50 ondersteunt Chrome niet langer het verkrijgen van de locatie van de gebruiker met behulp van de HTML5 Geolocation API van pagina's die via niet-beveiligde verbindingen worden aangeroepen. Dit betekent dat de pagina die de Geolocation API aanroept, moet worden aangeroepen vanuit een beveiligde context , zoals HTTPS .

Dit is een belangrijk probleem, omdat het een directe impact heeft op elke website die de geolocatie-API nodig heeft en niet via https wordt aangeboden. Toch geloven we dat deze verandering gunstig is voor alle gebruikers op het web. Dit bericht helpt je de redenering en de te volgen procedure te begrijpen.

Wanneer verandert dit?

Deze wijziging is van kracht vanaf Chrome 50 (12:00 uur PST, 20 april 2016).

De ontwikkelaarstoolsconsole van Chrome geeft al waarschuwingen sinds versie 44 (uitgebracht op 21 juli 2015).
Er zijn een aantal openbare aankondigingen geweest die de reden (en discussie) beschrijven waarom we deze verandering doorvoeren:

Er zijn een aantal andere bronnen die dit hebben benadrukt: Mobiforge (26 januari 2016), Wired (17 maart 2016), VentureBeat (13 april 2016).

Waarom voeren we deze verandering door?

Locatiegegevens zijn gevoelige gegevens! HTTPS vereisen is vereist om de privacy van de locatiegegevens van uw gebruikers te beschermen. Als de locatie van de gebruiker beschikbaar is vanuit een niet-beveiligde context, kunnen aanvallers op het netwerk achterhalen waar die gebruiker zich bevindt. Dit brengt de privacy van de gebruiker ernstig in gevaar.

Op wie heeft dit betrekking?

Dit is van toepassing op elke pagina die momenteel de Geolocation API gebruikt vanaf pagina's die via HTTP (niet-beveiligd) worden aangeboden. Het is ook van toepassing op HTTPS-iframes die de Geolocation API gebruiken als ze in HTTP-pagina's zijn ingesloten. (U kunt geen polyfill gebruiken met een gedeeld, via HTTPS geleverd frame.)

Heeft mijn hele web-app HTTPS nodig?

Het is niet vereist dat de hele app via HTTPS wordt aangeboden om geolocatie te gebruiken. Alleen pagina's die geolocatie gebruiken, hoeven via een beveiligde context te worden aangeboden. Een beveiligde context is momenteel alles wat op het hoogste niveau op HTTPS of localhost wordt gehost. Een iframe dat bijvoorbeeld verwijst naar een beveiligde bron , maar op een onbeveiligde bron wordt gehost ( http://paul.kinlan.me/ ), mag de geolocatie-API niet aanroepen.

Wij raden u ten zeerste aan om naar HTTPS te migreren, aangezien krachtige nieuwe en bestaande browserfuncties beveiligde bronnen vereisen .

Heeft dit gevolgen voor de lokale ontwikkeling?

Dat zou niet moeten, localhost is in de specificatie aangemerkt als "potentieel veilig" en in ons geval werken geolocatieverzoeken die op het hoogste niveau via localhost worden verzonden nog steeds.

Kan ik tijdens runtime detecteren of de geolocatie is geblokkeerd omdat er geen beveiligde context was?

Ja. De geolocatiespecificatie definieert een PositionError- object dat wordt doorgegeven aan de foutcallback van de Geolocatie-API's. Het object definieert een code en message .

Fouten als gevolg van dit probleem met de beveiligde context retourneren een code 1, wat staat voor een 'Permission Denied Error' (Fout met betrekking tot toestemming geweigerd). U kunt deze foutmelding krijgen wanneer een gebruiker de toegang heeft geweigerd of wanneer het systeem de toegang tot de locatie van de gebruiker heeft geweigerd. Dit betekent dat u het bericht moet controleren om de exacte reden te achterhalen.

Dit kan erg kwetsbaar zijn, omdat het in de toekomst kan veranderen. Toch is een sterk signaal dat het om een ​​probleem met niet-beveiligde inhoud gaat, te vinden als u zoekt naar de tekst 'Alleen beveiligde oorsprongen zijn toegestaan'.

navigator.geolocation.getCurrentPosition(success => {
    /* Do some magic. */
}, failure => {
    if (failure.message.startsWith("Only secure origins are allowed")) {
    // Secure Origin issue.
    }
});

Houd er rekening mee dat u niet zomaar de oorsprong van de pagina kunt controleren. Uw pagina kan namelijk op https staan, maar zich in een iframe bevinden dat wordt gehost in een onveilige context.

Ik moet echt Geolocatie gebruiken. Wat moet ik doen?

Als u de HTML5 Geolocation API wilt gebruiken of als uw site de Geolocation API al gebruikt, migreer dan de pagina's die Geolocation API-aanroepen doen naar HTTPS . Zorg er daarbij voor dat ze in een veilige context worden gebruikt.

Er zijn verschillende terugvalopties beschikbaar om de locatie van een gebruiker te achterhalen die niet door deze wijziging worden beïnvloed, zoals de Google Maps Geolocation API , GeoIP (er zijn bijvoorbeeld andere geogebaseerde oplossingen) en een door de gebruiker ingevoerde postcode. We raden echter sterk aan om over te stappen op HTTPS om continue toegang tot geolocatie te garanderen.