Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geolocation fails when not using https on Chrome #1493

Closed
xenotropic opened this issue Mar 21, 2017 · 33 comments

Comments

@xenotropic
Copy link

commented Mar 21, 2017

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.

osm-https-error

@tomhughes

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

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

This comment has been minimized.

@tomhughes

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

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

@xenotropic

This comment has been minimized.

Copy link
Author

commented Mar 21, 2017

the domoritz one?

@tomhughes

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 21, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2017

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 comment has been minimized.

Copy link
Contributor

commented Mar 21, 2017

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

@rbovard

This comment has been minimized.

Copy link

commented May 9, 2017

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

This comment has been minimized.

Copy link

commented Sep 5, 2017

The issue still persists.

image

Enabling HSTS can transparently upgrade all http communication to https.

@tomhughes

This comment has been minimized.

Copy link
Member

commented Sep 5, 2017

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

@iandees

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

@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: #833

@tomhughes

This comment has been minimized.

Copy link
Member

commented Sep 5, 2017

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

This comment has been minimized.

Copy link

commented Sep 5, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 5, 2017

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

This comment has been minimized.

Copy link

commented Sep 5, 2017

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

This comment has been minimized.

Copy link

commented Sep 5, 2017

(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

This comment has been minimized.

Copy link

commented Sep 6, 2017

@Bisaloo

This comment has been minimized.

Copy link

commented Sep 27, 2017

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

openstreetmap/operations#117 maybe?

@c960657

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2017

Related upstream ticket: domoritz/leaflet-locatecontrol#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

This comment has been minimized.

Copy link

commented Nov 23, 2017

I believe that this approach would make total sense.

@mxdanger

This comment has been minimized.

Copy link

commented Jan 12, 2018

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-

This comment has been minimized.

Copy link

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Member

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Member

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Member

commented Jul 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2018

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

@xenotropic

This comment has been minimized.

Copy link
Author

commented Aug 19, 2018

Closed per @mmd-osm comment which appears accurate

@xenotropic xenotropic closed this Aug 19, 2018

@Hb-

This comment has been minimized.

Copy link

commented Aug 19, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.