Chrome heeft de publieke bedoeling om krachtige functies zoals geolocatie op niet-beveiligde bronnen te beëindigen, en we hopen dat anderen 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 worden geleverd via niet-beveiligde verbindingen. Dit betekent dat de pagina die de Geolocation API-aanroep doet, moet worden bediend vanuit een beveiligde context zoals HTTPS .
Het is een belangrijke kwestie omdat het een directe impact zal hebben op elke site die het gebruik van de geolocatie-API vereist en niet via https wordt aangeboden, maar het is een verandering waarvan we denken dat deze gunstig is voor alle gebruikers op internet. Dit bericht zou u moeten helpen de redenering te begrijpen en hoe verder te gaan.
Wanneer verandert dit?
Deze wijziging is van kracht vanaf Chrome 50 (20 april 2016, 12.00 uur PST).
De console voor ontwikkelaarstools van Chrome geeft 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:
- Voornemen om een reeks krachtige functies via HTTP af te schaffen (februari 2015)
- Voornemen om de Geolocatie-API via HTTP af te schaffen (november 2015)
- Chrome Dev Summit (november 2016)
- Blog over de release van het Chrome Bètakanaal (17 maart 2016)
- Chrome Status -website
Er zijn een aantal andere bronnen geweest die dit hebben benadrukt: Mobiforge (26 januari 2016), Wired (17 maart 2016), VentureBeat (13 april 2016).
Waarom voeren we deze verandering door?
Locatie is gevoelige gegevens! Het vereisen van HTTPS 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 weten waar die gebruiker zich bevindt. Dit brengt de privacy van gebruikers ernstig in gevaar.
Op wie is dit van invloed?
Dit is van invloed op elke pagina die momenteel de Geolocation API gebruikt vanaf pagina's die via HTTP worden aangeboden (niet-beveiligd). Het heeft ook invloed op HTTPS-iframes die de Geolocation API gebruiken als ze zijn ingesloten in HTTP-pagina's. (U kunt geen polyfill gebruiken met een gedeeld, via HTTPS geleverd frame.)
Heeft mijn hele web-app HTTPS nodig?
Het is geen vereiste dat de hele app via HTTPS wordt aangeboden om geolocatie te kunnen gebruiken. Alleen pagina's die geolocatie gebruiken, moeten via een beveiligde context worden weergegeven. Een veilige context is momenteel alles wat op het hoogste niveau wordt gehost op HTTPS of localhost. Een iframe dat naar een veilige oorsprong verwijst maar wordt gehost op een onbeveiligde oorsprong ( http ://paul.kinlan.me/ ), mag bijvoorbeeld de geolocatie-API niet aanroepen.
We raden u ten zeerste aan om naar HTTPS te migreren, omdat krachtige nieuwe en bestaande browserfuncties een veilige oorsprong vereisen .
Heeft dit gevolgen voor de lokale ontwikkeling?
Dat zou niet moeten, localhost is in de specificatie als "potentieel veilig" verklaard en in ons geval zullen geolocatieverzoeken die op het hoogste niveau via localhost worden aangeboden, nog steeds werken.
Kan ik tijdens runtime detecteren of de geolocatie is geblokkeerd omdat deze zich niet in een beveiligde context bevindt?
Ja. De geolocatiespecificatie definieert een PositionError- object dat wordt doorgegeven aan de fout-callback van de geolocatie-API's. Het object definieert een code
en message
.
Fouten als gevolg van dit probleem met de beveiligde context zullen een code
van 1 retourneren, wat een "Permission Denied Error" is. U kunt deze foutmelding krijgen wanneer een gebruiker de toegang heeft geweigerd of het systeem de toegang tot de locaties van de gebruiker heeft geweigerd. Dit betekent dat u het bericht moet controleren om te zien wat de exacte reden was.
Dit kan nogal broos zijn omdat het in de toekomst zou kunnen veranderen, maar een sterk signaal dat het een niet-beveiligd inhoudsprobleem was, is door te zoeken naar de string "Alleen veilige oorsprong is 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 alleen de oorsprong van de pagina kunt controleren, omdat uw pagina zich mogelijk op https bevindt, maar in een iframe dat wordt gehost vanuit een onveilige context.
Ik moet echt Geolocatie gebruiken; Wat moet ik doen?
Als u de HTML5 Geolocation API wilt gebruiken, of als uw site al de Geolocation API gebruikt, migreer dan de pagina's die Geolocation API-aanroepen maken naar HTTPS en zorg ervoor dat ze in een veilige context worden gebruikt.
Er zijn een aantal terugvalopties beschikbaar om de locatie van een gebruiker te achterhalen die niet door deze wijziging worden beïnvloed, zoals Google Maps Geolocation API , GeoIP (er zijn bijvoorbeeld andere geogebaseerde oplossingen) en een door de gebruiker ingevoerde postcode. We raden echter ten zeerste aan dat de beste manier om voortdurende toegang tot geolocatie te garanderen, is om over te stappen op HTTPS.
,Chrome heeft de publieke bedoeling om krachtige functies zoals geolocatie op niet-beveiligde bronnen te beëindigen, en we hopen dat anderen 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 worden geleverd via niet-beveiligde verbindingen. Dit betekent dat de pagina die de Geolocation API-aanroep doet, moet worden bediend vanuit een beveiligde context zoals HTTPS .
Het is een belangrijke kwestie omdat het een directe impact zal hebben op elke site die het gebruik van de geolocatie-API vereist en niet via https wordt aangeboden, maar het is een verandering waarvan we denken dat deze gunstig is voor alle gebruikers op internet. Dit bericht zou u moeten helpen de redenering te begrijpen en hoe verder te gaan.
Wanneer verandert dit?
Deze wijziging is van kracht vanaf Chrome 50 (20 april 2016, 12.00 uur PST).
De console voor ontwikkelaarstools van Chrome geeft 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:
- Voornemen om een reeks krachtige functies via HTTP af te schaffen (februari 2015)
- Voornemen om de Geolocatie-API via HTTP af te schaffen (november 2015)
- Chrome Dev Summit (november 2016)
- Blog over de release van het Chrome Bètakanaal (17 maart 2016)
- Chrome Status -website
Er zijn een aantal andere bronnen geweest die dit hebben benadrukt: Mobiforge (26 januari 2016), Wired (17 maart 2016), VentureBeat (13 april 2016).
Waarom voeren we deze verandering door?
Locatie is gevoelige gegevens! Het vereisen van HTTPS 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 weten waar die gebruiker zich bevindt. Dit brengt de privacy van gebruikers ernstig in gevaar.
Op wie is dit van invloed?
Dit is van invloed op elke pagina die momenteel de Geolocation API gebruikt vanaf pagina's die via HTTP worden aangeboden (niet-beveiligd). Het heeft ook invloed op HTTPS-iframes die de Geolocation API gebruiken als ze zijn ingesloten in HTTP-pagina's. (U kunt geen polyfill gebruiken met een gedeeld, via HTTPS geleverd frame.)
Heeft mijn hele web-app HTTPS nodig?
Het is geen vereiste dat de hele app via HTTPS wordt aangeboden om geolocatie te kunnen gebruiken. Alleen pagina's die geolocatie gebruiken, moeten via een beveiligde context worden weergegeven. Een veilige context is momenteel alles dat op het hoogste niveau wordt gehost op HTTPS of localhost. Een iframe dat naar een veilige oorsprong verwijst maar wordt gehost op een onbeveiligde oorsprong ( http ://paul.kinlan.me/ ), mag bijvoorbeeld de geolocatie-API niet aanroepen.
We raden u ten zeerste aan om naar HTTPS te migreren, omdat krachtige nieuwe en bestaande browserfuncties een veilige oorsprong vereisen .
Heeft dit gevolgen voor de lokale ontwikkeling?
Dat zou niet moeten, localhost is in de specificatie als "potentieel veilig" verklaard en in ons geval zullen geolocatieverzoeken die op het hoogste niveau via localhost worden aangeboden, nog steeds werken.
Kan ik tijdens runtime detecteren of de geolocatie is geblokkeerd omdat deze zich niet in een beveiligde context bevindt?
Ja. De geolocatiespecificatie definieert een PositionError- object dat wordt doorgegeven aan de fout-callback van de geolocatie-API's. Het object definieert een code
en message
.
Fouten als gevolg van dit probleem met de beveiligde context zullen een code
van 1 retourneren, wat een "Permission Denied Error" is. U kunt deze foutmelding krijgen wanneer een gebruiker de toegang heeft geweigerd of het systeem de toegang tot de locaties van de gebruiker heeft geweigerd. Dit betekent dat u het bericht moet controleren om te zien wat de exacte reden was.
Dit kan nogal broos zijn omdat het in de toekomst zou kunnen veranderen, maar een sterk signaal dat het een niet-beveiligd inhoudsprobleem was, is door te zoeken naar de string "Alleen veilige oorsprong is 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 alleen de oorsprong van de pagina kunt controleren, omdat uw pagina zich mogelijk op https bevindt, maar in een iframe dat wordt gehost vanuit een onveilige context.
Ik moet echt Geolocatie gebruiken; Wat moet ik doen?
Als u de HTML5 Geolocation API wilt gebruiken, of als uw site al de Geolocation API gebruikt, migreer dan de pagina's die Geolocation API-aanroepen maken naar HTTPS en zorg ervoor dat ze in een veilige context worden gebruikt.
Er zijn een aantal terugvalopties beschikbaar om de locatie van een gebruiker te achterhalen die niet door deze wijziging worden beïnvloed, zoals Google Maps Geolocation API , GeoIP (er zijn bijvoorbeeld andere geogebaseerde oplossingen) en een door de gebruiker ingevoerde postcode. We raden echter ten zeerste aan dat de beste manier om voortdurende toegang tot geolocatie te garanderen, is om over te stappen op HTTPS.
,Chrome heeft de publieke bedoeling om krachtige functies zoals geolocatie op niet-beveiligde bronnen te beëindigen, en we hopen dat anderen 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 worden geleverd via niet-beveiligde verbindingen. Dit betekent dat de pagina die de Geolocation API-aanroep doet, moet worden bediend vanuit een beveiligde context zoals HTTPS .
Het is een belangrijke kwestie omdat het een directe impact zal hebben op elke site die het gebruik van de geolocatie-API vereist en niet via https wordt aangeboden, maar het is een verandering waarvan we denken dat deze gunstig is voor alle gebruikers op internet. Dit bericht zou u moeten helpen de redenering te begrijpen en hoe verder te gaan.
Wanneer verandert dit?
Deze wijziging is van kracht vanaf Chrome 50 (20 april 2016, 12.00 uur PST).
De console voor ontwikkelaarstools van Chrome geeft 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:
- Voornemen om een reeks krachtige functies via HTTP af te schaffen (februari 2015)
- Voornemen om de Geolocatie-API via HTTP af te schaffen (november 2015)
- Chrome Dev Summit (november 2016)
- Blog over de release van het Chrome Bètakanaal (17 maart 2016)
- Chrome Status -website
Er zijn een aantal andere bronnen geweest die dit hebben benadrukt: Mobiforge (26 januari 2016), Wired (17 maart 2016), VentureBeat (13 april 2016).
Waarom voeren we deze verandering door?
Locatie is gevoelige gegevens! Het vereisen van HTTPS 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 weten waar die gebruiker zich bevindt. Dit brengt de privacy van gebruikers ernstig in gevaar.
Op wie is dit van invloed?
Dit is van invloed op elke pagina die momenteel de Geolocation API gebruikt vanaf pagina's die via HTTP worden aangeboden (niet-beveiligd). Het heeft ook invloed op HTTPS-iframes die de Geolocation API gebruiken als ze zijn ingesloten in HTTP-pagina's. (U kunt geen polyfill gebruiken met een gedeeld, via HTTPS geleverd frame.)
Heeft mijn hele web-app HTTPS nodig?
Het is geen vereiste dat de hele app via HTTPS wordt aangeboden om geolocatie te kunnen gebruiken. Alleen pagina's die geolocatie gebruiken, moeten via een beveiligde context worden weergegeven. Een veilige context is momenteel alles dat op het hoogste niveau wordt gehost op HTTPS of localhost. Een iframe dat naar een veilige oorsprong verwijst maar wordt gehost op een onbeveiligde oorsprong ( http ://paul.kinlan.me/ ), mag bijvoorbeeld de geolocatie-API niet aanroepen.
We raden u ten zeerste aan om naar HTTPS te migreren, omdat krachtige nieuwe en bestaande browserfuncties een veilige oorsprong vereisen .
Heeft dit gevolgen voor de lokale ontwikkeling?
Dat zou niet moeten, localhost is in de specificatie als "potentieel veilig" verklaard en in ons geval zullen geolocatieverzoeken die op het hoogste niveau via localhost worden aangeboden, nog steeds werken.
Kan ik tijdens runtime detecteren of de geolocatie is geblokkeerd omdat deze zich niet in een beveiligde context bevindt?
Ja. De geolocatiespecificatie definieert een PositionError- object dat wordt doorgegeven aan de fout-callback van de geolocatie-API's. Het object definieert een code
en message
.
Fouten als gevolg van dit probleem met de beveiligde context zullen de code
1 retourneren, wat een "Permission Denied Error" is. U kunt deze foutmelding krijgen wanneer een gebruiker de toegang heeft geweigerd of het systeem de toegang tot de locaties van de gebruiker heeft geweigerd. Dit betekent dat u het bericht moet controleren om te zien wat de exacte reden was.
Dit kan nogal broos zijn omdat het in de toekomst zou kunnen veranderen, maar een sterk signaal dat het een niet-beveiligd inhoudsprobleem was, is door te zoeken naar de string "Alleen veilige oorsprong is 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 alleen de oorsprong van de pagina kunt controleren, omdat uw pagina zich mogelijk op https bevindt, maar in een iframe dat wordt gehost vanuit een onveilige context.
Ik moet echt Geolocatie gebruiken; Wat moet ik doen?
Als u de HTML5 Geolocation API wilt gebruiken, of als uw site al de Geolocation API gebruikt, migreer dan de pagina's die Geolocation API-aanroepen maken naar HTTPS en zorg ervoor dat ze in een veilige context worden gebruikt.
Er zijn een aantal terugvalopties beschikbaar om de locatie van een gebruiker te achterhalen die niet door deze wijziging worden beïnvloed, zoals Google Maps Geolocation API , GeoIP (er zijn bijvoorbeeld andere geogebaseerde oplossingen) en een door de gebruiker ingevoerde postcode. We raden echter ten zeerste aan dat de beste manier om voortdurende toegang tot geolocatie te garanderen, is om over te stappen op HTTPS.