Openstreetmap-website: Geolocation fails when not using https on Chrome

[xenotropic]

With Chrome for Windows and Android (probably macOS/linux too; I don't have one handy), if the user clicks on the geolocation button ("show my location") while not using https, then the browser throws an error as seen below -- "only secure origins are allowed". Going into the browser bar and making it https fixes the issue, but an unsophisticated user will not know to do that. Consider making https mandatory, or if overhead does not permit that, perhaps code some javascript to catch the error and provide a more useful message; or forward to https when geolocation is clicked.

[tomhughes]

I thought there was already a ticket for this but I can't find it.

As you seem to have realised this is a decision made by your browser maker and is largely outside our control.

There are technical reasons why we can't go https only at the moment and in addition we have a portion of our community that are opposed to it.

[xenotropic]

See suggested code from Google to catch this error and provide a useful error message: https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only#can_i_detect_at_runtime_if_the_geolocation_was_blocked_because_of_not_being_on_a_secure_context

[tomhughes]

@xenotropic it's not our code unfortunately, it's a third party plugin for leaflet.

[xenotropic]

the domoritz one?

[tomhughes]

Looks like it yes. I think it probably does let us access the error event but frankly I'm not really very keen on something that depends on matching what is browser (and quite likely language) specific text in the error message...

[xenotropic]

I'm just concerned that a lot of users will try it and be like "oh, I guess that feature is broken". There are certainly strong arguments that you make to say it's not OSM's responsibility from a developer perspective, but the error will nevertheless reflect poorly on OSM for users who get the error starting with "openstreetmap.org says" and are unaware of the technical issues. Chrome's obsession with forcing security even where it may not make sense is a bummer, but it's 30% of desktop browsers at the moment and 50% of mobile browsers, so this error is not exactly a niche problem.

[gravitystorm]

I've been getting frustrated by this issue when using OSM on my phone, so it's something I'd like to fix. I'm happy to explore other ideas, such as replacing the button when served over http with a similar-looking one that redirects to https before attempting geolocation.

[tomhughes]

It's not a feature I ever use which is probably why I've never been very bothered by it, well that and I use Firefox which isn't insisting on this yet.

Do many of our user's actually manage to find it? It's pretty obscure...

The problem with reloading will be making sure any state is preserved.

[gravitystorm]

I use it perhaps 10 times per month on my phone, almost never on my laptop. Since typing "osm.org" is the quickest way to get to the site, I end up on http. Each time I press the button I get the error, and then have to manually edit the url to get the https version, and inserting characters into existing urls on an iphone touchscreen is tedious to say the least.

It's one of the biggest (and most useful) elements shown on a mobile-sized view of the homepage, so I bet it gets pressed pretty often!

[pnorman]

This is often a usability issue for me when I end up on http, which is very frequent.

[rbovard]

This is often a usability issue for me when I end up on http, which is very frequent.

Maybe because all links in notification emails are without https?

[Komzpa]

The issue still persists.

Enabling HSTS can transparently upgrade all http communication to https.

[tomhughes]

Yes. Enabling HSTS can also transparently break OAuth. Next idea please?

[iandees]

@tomhughes can you give more details about that? I'm assuming you mean existing API users that have an HTTP URL hard coded? Or am I missing something else?

Also worth referring to this previous discussion on SSL: https://github.com/openstreetmap/openstreetmap-website/issues/833

[tomhughes]

Yes the problem is that an OAuth client makes an http request (and includes http in the protocol when computing the signature) but behind their back the browser sends the request over https instead which means that when the server computes the signature (using https as the protocol) it doesn't match.

It's not hypothetical - we turned on HSTS at one point and had to turn it off again because of this.

It's actually not relevant to this bug anyway - this bug could be resolved simply be redirecting everything to https by default. That simply requires that we make a decision to go "https only" which historically we have avoided because there were objections from some users to that.

[mojodna]

If OAuth is a substantial sticking point, the server implementation could be patched to accept signatures generated with both http and https as the protocol (this does require that clients follow redirects though, but the only ones that support HSTS do (browsers)).

[tomhughes]

It's only a sticking point for HSTS not for fixing this bug.

I have certainly considered patching it that way, but it's a third party component that is largely unmaintained and I don't think it would be a simple patch so I don't think it's a realistic approach.

[mojodna]

I used to maintain it (years ago when I was working in Ruby full-time), so I'll volunteer to write a patch should it get to that.

[mojodna]

(Also, I should be clear that I'm equating HSTS to adding a redirect rule for http → https, since the latter is the part that matters to match vendors' requirements for geolocation support.)

Alternate solution: modify the Leaflet plugin (which one is responsible?) to redirect to HTTPS before attempting to request geolocation. Not totally straightforward, but possible.

[dieterdreist]

2017-09-05 14:20 GMT+02:00 Tom Hughes [e-mail]:

Yes the problem is that an OAuth client makes an http request (and
includes http in the protocol when computing the signature) but behind
their back the browser sends the request over https instead which means
that when the server computes the signature (using https as the protocol)
it doesn't match.

It's not hypothetical - we turned on HSTS at one point and had to turn it
off again because of this.

It's actually not relevant to this bug anyway - this bug could be resolved
simply be redirecting everything to https by default. That simply requires
that we make a decision to go "https only" which historically we have
avoided because there were objections from some users to that.

maybe it could be turned on by default, but made overridable in the user
preferences?

[Bisaloo]

I thought there was already a ticket for this but I can't find it.

https://github.com/openstreetmap/operations/issues/117 maybe?

[c960657]

This is not specific to Chrome.

According to developer.mozilla.org, the geo-location APIs require HTTPS in Firefox 55+, Safari 10+ and Opera 39+.

The only major browsers without this restriction are Internet Explorer and Edge.

[stefanb]

Related upstream ticket: https://github.com/domoritz/leaflet-locatecontrol/issues/160

On Firefox it fails with alert "Geolocation error: user denied geolocation prompt." without ever prompting the user for such permission.

A possible workaround could be to make the button behave differently on non-https connections, namely to

• Compose a URL from current one, but
  
  
  
  • change http to https
  
  
  • add a parameter (in URL or a short-living cookie) to start geolocation immediately after the HTTPS variant loads
  
  
• Redirect to the new URL
• Start geolocation
• Clean up the previously added parameter (from URL or delete cookie)

This would make the button work seamlessly even on http (just taking a bit longer initially).

Ideally this would be implemented in the Leaflet plugin and controlled via initialisation options, but I want to discuss this approach with you first.

[nighto]

I believe that this approach would make total sense.

[mxdanger]

I've been using a workaround to this problem with the Chrome extension HTTPS Everywhere and It's obviously not the solution but it lets it work with the "the less secure" site settings.

[Hb-]

Currently in Firefox for Android 61 on the Google Maps page geolocation works fine. But on the Openstreetmap page it fails with the error prompt "Geolocation error: User denied geolocation prompt". What do?

[tomhughes]

Well as you denied it (the key is the "user denied") you can allow it again.

How to do it is a question for a firefox forum, not an openstreetmap one ;-)

[tomhughes]

Hmm or maybe that is just a bogus message because I get it as well.

What I can say is that it's nothing to with this bug, which is specifically about Chrome.

[tomhughes]

That is definitely the error coming from firefox, though it's lying because it never asked the user.

It seems this is another side effect of the privacy.resistFingerprinting configuration option in firefox. That isn't on by default but something (maybe an extension?) turned it on for me at some point and I'm guessing the same has happened to you.

[mmd-osm]

@xenotropic : https is default on osm.org now, http is gone, hence you could close this issue.

[xenotropic]

Closed per @mmd-osm comment which appears accurate

[Hb-]

On Firefox this issue can occur when the user forgot that he previously had denied location access to the site osm.org permanently.

To retreat this decision the Website data needs to be cleared from Firefox. Call the Menu, Settings, Clear private data and delete at least all Website data.

[mmd-osm]

@Hb- : the issue you describe is a general issue with Firefox, and does not only affect openstreetmap-website, so there's no follow up needed in this repository. No code change in this repository will change the way Firefox works, so there are no further actionable items left here.