Geolocation API removed from unsecured origins in Chrome 50 | Hacker News Reader

Geolocation API removed from unsecured origins in Chrome 50

developers.google.com

122 pointslaacz73 comments

The Firefox bug to restrict geolocation to secure origins is: https://bugzilla.mozilla.org/show_bug.cgi?id=1072859

Does this mean we'll have less ad-plastered sites immediately asking for geolocation the moment you visit them? Hooray!

Or, alternatively, terrifically increased HTTPS-by-default rates.

Wouldn't Let's Encrypt offset any significant benefit of this change? Is it somehow difficult or counterproductive for these sites to add a certificate?

Getting more sites to use Let's Encrypt, or Cloudflare, or to buy a certificate is the intended benefit of the change. Google is gradually restricting these APIs to encrypted origins in order to encourage sites to use encryption, not because they don't want the APIs used.

> to encourage sites to use encryption

And because having your fine location cross the wire unencrypted is a terrible idea :)

> or Cloudflare

https://www.cloudflare.com/ssl/#cloudflare-ssl-options

cloudflare's "flexible ssl" option encrypts the connection between their datacenter and the user, but not the one between the datacenter and the actual web server

i guess it's better than nothing if your host doesn't support ssl but the false sense of security could be harmful

That assumes such sites' operators care about HTTPS.

It is counterproductive, as many ad networks are not fully HTTPS-compliant yet. So you'll literally lose money by switching to HTTPS. It's why many big media sites still haven't done it yet.

It's a chicken-and-egg problem, but it's starting to improve.

Honestly if google really wanted to push this, they would do something to penalize http only ads. That would really pressure advertisers to upgrade or lose.

Chrome 51 changelog:

* Images served over unencrypted connections will have 50% of their pixels randomly scrambled.

Why don't ad networks care about HTTPS? It would increase the number of potential sites that can show their ads, make it more difficult for ISPs to block their ads, and allow browsers to load their ads over HTTP/2.

HTTPS requires additional round trips, so slows things down and tends to reduce revenue by a non-trivial amount.

Really? We added HTTPS to a number of ad-ridden sites and found no noticeable impact to end user page load times, page views or ad revenue.

If slow ads were a problem, why are ad networks so damn slow? I frequently see ads taking 10–20 seconds to load on major news sites. Serving fast ads would mean more viewing time, yet that doesn't seem to be a priority for anyone.

"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that."

https://istlsfastyet.com/

It's your privacy not theirs. And they have to pay the increased costs for HTTPS including complexity (key management, etc).

Coincidentally, I'm working on a travel app and had to spend some time automating let's encrypt on our servers because of the update. In the end, I came out as a huge fan of LE.

And here's to hoping they are able to push for the same thing for getUserMedia and the device motion/accelerometer APIs as well!

getUserMedia was killed off for insecure origins quite a while ago in Chrome.

Oh shit really? That's awesome!

I think it was Chrome 48. It also doesn't work for localhost.

Localhost is considered secure context, so it should still work for that...

It won't work with file:/// urls, but localhost is fine.

At least it was for me in 49 a couple weeks ago.

It would be pretty hard to use the API if you couldn't test your code on localhost :P

I think you're mistaken about localhost, this works fine for me on localhost:3000

    navigator.getUserMedia({
        video: true, 
        audio: true
      },
      console.log.bind(console, 'success'),
      console.log.bind(console, 'error')
    );

Chrome v50.0.2661.94 (64-bit) on OS X

I'm very glad I don't touch web dev anymore. This piecemeal removal of features from one transport mode is exactly the sort of thing that causes clients (of the human, paying sort) to flip out when they misunderstand what is going on.

Don't get me wrong - I think this is a good thing. And I don't know that the answer is a big, publicized drop of all these changes at once, although that would have certain advantages. But a trickle of dropped features that non-technical folks will never see announced is going to be a lot of fun for web developers.

I don't really think the backlash is happening as you describe. There's quite a lot of public awareness about ongoing communications and privacy issues, and implementing SSL is extremely cheap in most cases. "We need to upgrade your security to keep things working, it will take a day" is a fairly straightforward sell in most cases.

Does this move really solve ANY privacy problem? Getting geolocation already prompts the user for approval. Any sinister party wouldn't bat an eye at setting up https. Odd.

The idea is that other parties on the network won't be able to snoop on the location data.

The concern is that if the site is insecure you might send Geolocation which might be sensible information through unsecure channels allowing someone to snoop on the connection and read that data.

In other words they are trying to hide the geolocation data from proxies, Carriers, ISPs and someone possibly MitM attacks

This isn't a privacy problem, it's a security problem.

Speaking of which, whatever happened to the COWL system? I know Google & Mozilla were involved in researching the tech. Will it ever come to Chrome and other browsers?

http://cowl.ws/

https://www.ucl.ac.uk/news/news-articles/1014/061014_COWL

So now if someone who hosts/rents a small server for side projects/hosting small services like community forums or a simple game wants to make something experimenting with geolocation they'll have to buy an HTTPS cert, make an app (which requires paying for the ability to put apps on major app stores unless you want to only support Android, where the OS discourages users from installing 3rd party apps with messages about how they might harm your phone, or jailbroken iPhones), or only support non-Chrome browsers (as long as other browsers don't follow in this). Is it really a good thing to restrict web functionality even more from small players? How does it matter if someone sniffs your GPS location from an HTTP connection? Are there situations where that's feasible and your precise geographic location isn't something the attacker doesn't already know? The only major situation I'm aware of is wifi hotspots where the location is already known.

Edit: Apparently there are free certificate suppliers, but will those be sustainable if HTTP is eventually fully phased out? Browsers display errors with self-signed certificates, so it still seems problematic in the long run to have to depend on the good graces of other parties if you want to serve web content.

I have a side-project server. It took me about fifteen minutes to get a ssl cert with letsencrypt, and it was free. I even get use it on my mumble, smtp and imap servers.

Agreed. Letsencrypt has come very close to making SSL certificate generation a non-issue for small websites.

Perhaps they are interested in defending against sniffing further along the line (ISP, backbone) or are just making the change as part of the general strategy to encourage HTTPS use? While I see your concern about inconveniencing smaller players, LetsEncrypt exists now, and there are definitely mid- and large-sized players that I would like to see pushed in the direction of HTTPS exclusivity.

Convenience is not an excuse to ignore security.

And also from our experience, it seems that they're only allowing TLS 1.0 and up. https://github.com/alexreisner/geocoder/issues/1034

This comment seems to imply that you're using a transport layer security mechanism < TLS 1.0, i.e. SSLv2 or SSLv3. I strongly encourage you to upgrade to TLS 1.1 or newer.

SSLv3 is deprecated, it should not be used.

> It should not [affect development], localhost has been declared as “potentially secure”

Glad this was included. Is https even meaningful when on a local server?

  window.navigator.geolocation.getCurrentPosition(function() { console.log(arguments); })

This shows me the coordinates and no Error is thrown.

Chrome version:

    Version 50.0.2661.94 m

From localhost? Because that's treated as safe in this case.

I opened up the console of HN's page.

HN is a secure origin so it still works. Test it out on a non-https site.

That's right. I had commented on this before I had my caffeine. My apologies.

So ad-supported sites have to choose between greatly reduced ad revenue or a broken app. Thanks Google.

> So ad-supported sites have to choose between greatly reduced ad revenue or a broken app. Thanks Google.

Geolocation API is pretty powerful. It's one thing for a random website to know approximate location, but to be able to track location within 10m is something else.

Perhaps a gentler interim solution would have been to only allow accuracy to town/city level over http.

That's already mostly possible with geoip lookups.

Yeah, it's just the breaking changes thing - I like what Google are doing, and it's been alerted in the console for ages, but they're strong-arming it slightly.

I'm weird, but it always grates slightly when companies throw their weight around - even if the endgame is a positive outcome.

Plus the cynic in me assumes they have an advertising product in the works and this is facilitating it.

There is zero reason for an ad to be using the Geolocation API. IP-based geolocation is more than enough.

I'm sure advertising will find a use for it! Like "hyper-local ads" that can give you "just around the corner" deals in malls, etc.

> There is zero reason for an ad to be using the Geolocation API. IP-based geolocation is more than enough.

There was also zero reason for billboards by highways, before there were highways. :)

Location based advertising is powerful, but the issue here is privacy. We have no idea where that information is going.

Advertising could find a use for my DNA profile but that doesn't mean they should have access to it.

Obviously this is all a sliding scale and has nuance, but I'd say ads should not be using anything that is behind a permission prompt, like geolocation. Tremendously hostile to both the user and the site hosting their ad.

I hate to play Devil's Advocate but accuracy can be important. Geoip means they can serve me offers for businesses in the same city, but I'd [almost] love it if I were served offers for a taqueria down the street from my browsing location.

More than likely they'll just correlate browsing habits with location and sell that information to third parties, though. High quality advertising is just not in this reality.

We have clients that are asking us to target down to street level, which IP doesn't even come close to offering. With IP you're stuck in the arms of whatever database you're using.

So tell them no. I don't want your clients knowing my street address.

I mean, for all you know, I'm in a domestic abuse shelter. Are you going to take responsibility for my well-being if your clients' database gets leaked? And are you confident that your clients know how to competently secure a database if they can't even use HTTPS?

We don't store any PII, so I don't see what the problem is here?

Any data about the user - even simple timestamps - that is leaked is an increasingly-serious problem. Just because you don't have interesting data doesn't mean other people cannot correlate your data with other aggregated personally identifiable data.

edit: Sorry, partial post due to accidentally hitting enter.

If you have clients pressing you to use code that requires a permission prompt in an ad then you need to have a very straightforward conversation with them about the effect such prompts have on conversion rates.

I'm just engineering side so I don't have any word on that. All we agree to do is zip code as the most granular level of geo targeting.

It's no concern of mine if someone else's business model is that badly broken.

To the people replying to this comment, he's not talking about the ads not being able to use the users location. Most don't. But plenty of ad networks don't work properly or the CPM is much lower for HTTPS enabled websites. I'm guessing r1ch is using a users' locations for his site, and it's ad supported. Hope everyone who is against ads is willing to pay for their content from now on!

Yes this was meant to be my point - I didn't even consider ads using gelocation (which explains the downvotes I guess :))).

While we do use geolocation and ads on one of our sites, it's only a single page so this doesn't really affect us that much. I can see it causing big problems with ad-supported sites / services that use geolocation as a primary feature though as I've experienced first-hand the revenue drop that HTTPS causes.

> he's not talking about the ads not being able to use the users location

The reason for wanting the user's location doesn't matter. It's incredibly irresponsible to send the user's location (or any other user data) over the network unencrypted.

Just embed an iframe for a secure subdomain and use window.postMessage to communicate with it.

Edit: never mind, that is apparently also "insecure", leading me to think they are doing this because they get a kickback from the SSL cert vampires somehow.

Yes, they're probably getting massive kickbacks from those horrible vampires over Let's Encrypt, who list Chrome as a major sponsor.

If not, why should they do it? What is in it for them?

There has been a massive loss of confidence in web security since Snowden (and rightly so). Major players now have to look like they're not "helping the NSA", so to speak -- this goes double for Googlers, which try very hard to hide their relationships with the establishment.

In a way, it's good -- privacy on the web improved more in the last 3 years than in the previous 15 -- but it's also a massive charade.

HTTPS certificates are free these days: https://letsencrypt.org/

If you want to run their software. On your server. As root. And are happy with 3 month certificates.

Do they support just downloading a file from them and then uploading it my server, as proof that I control the domain? That should be enough.

You do not have to use their software.

You can use one of the alternate clients people have written, or write your own:

https://github.com/xenolf/lego

https://github.com/ericchiang/letsencrypt

Or use this web interface:

https://gethttpsforfree.com/

Also you can configure it to give you longer lasting certs.

Reply on news.ycombinator.com