Intent to Remove: Insecure origin usage of geolocation

[Joel Weinberger]

Intent to Remove: Insecure origin usage of geolocation

Primary eng (and PM) emails

Eng: j...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ

Summary

This is a continuation of applying the concepts in http://www.w3.org/TR/powerful-features/ to features that have already shipped and which do not meet the (new, not present at the time) requirements. This is an intent to remove specifically for geolocation on insecure origins.

Motivation

This is a large privacy risk to users as it allows a passive attacker to sniff any geolocation obtained from this API, and it allows an active attacker to steal geolocation information from a trusted but insecure site. Additionally, use of geolocation on insecure origins is generally low, right on the removal threshold, at 0.0319% of page loads. Given the low use and the success of removing getUserMedia() from insecure origins, the time seems right to improve our users' privacy and security here.

Compatibility Risk

This change provides a moderate amount of compatibility risk in so far as insecure origins that use this API will not be able to use it in the future. However, the API already has a "deny" state that these users must handle, and this change will just start returning "deny", so it should not cause bugs per se.

Firefox has announced their general intention to remove geolocation and similar features from insecure origins, but I do not believe they have done so yet.

Usage information from UseCounter

On insecure origins (to remove):
https://www.chromestatus.com/metrics/feature/popularity#GeolocationInsecureOrigin

On secure origins (to remain): https://www.chromestatus.com/metrics/feature/popularity#GeolocationSecureOrigin

Insecure origin use of geolocation is hovering right above the removal threshold, at 0.033% of page loads. Additionally, this has been trending downward for quite some time, and it is dominated by secure use of geolocation 0.4698% of page loads. Thus, only about 6% of geolocation uses are on insecure origins, which is close to the rate at which we removed getUserMedia() from insecure origins (about 4% of total getUserMedia() use).

OWP launch tracking bug

https://crbug.com/561641 for geolocation in particular, and https://crbug.com/520765 for broader removal of old powerful features on insecure origins.

Entry on the feature dashboard

I believe this fits under the already existing geolocation status: https://www.chromestatus.com/features/6348855016685568

[Rick Byers]

This has been generating deprecation warnings since Chrome 44, right?

This will definitely block some functionality on some sites and cause some amount of user/developer pain.  But given:

 * Sites will be no more "broken" then when users deny the feature

 * We have >10x the usage of this API on secure origins than we do on insecure

 * The overall usage on insecure origins isn't huge (though even 0.03% of page loads is still quite substantial)

 * Developers have had plenty of warning / time to adapt

 * Most importantly: the clear benefits to user privacy

I believe the cost here is worth the benefit.

LGTM1 to remove

 

[Jochen Eisinger]

do we have any data what percentage of geolocation requests on insecure origins are granted by users?

[Simon Pieters]

On Wed, 25 Nov 2015 19:19:01 +0100, Joel Weinberger <j...@chromium.org>
wrote:

> Intent to Remove: Insecure origin usage of geolocation
>
> Primary eng (and PM) emails
>
> Eng: j...@chromium.org
>
>
> Link to “Intent to Deprecate” thread
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
>
> Summary
>
> This is a continuation of applying the concepts in
> http://www.w3.org/TR/powerful-features/ to features that have already
> shipped and which do not meet the (new, not present at the time)
> requirements. This is an intent to remove specifically for geolocation on
> insecure origins.
>
> Motivation
>
> This is a large privacy risk to users as it allows a passive attacker to
> sniff any geolocation obtained from this API, and it allows an active
> attacker to steal geolocation information from a trusted but insecure
> site.
> Additionally, use of geolocation on insecure origins is generally low,
> right on the removal threshold, at 0.0319% of page loads. Given the low
> use
> and the success of removing getUserMedia() from insecure origins

> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Dsoq5xPdzyw/21znuLWVCgAJ>,

> the time seems right to improve our users' privacy and security here.

Yet it looks like that received complaints and had to be reverted.

Would it make sense to remove this in more stages? Maybe something like:

1. The URL bar is marked as insecure when geolocation is asked for. The
geolocation dialog also says that the connection is insecure.
2. The geolocation permission dialog is not popped up automatically for
insecure origins, but can still be reached by clicking the geolocation
icon.
3. Remove.

Or just 1->3 or 2->3.

--
Simon Pieters
Opera Software

[Joel Weinberger]

Jochen:

Looking at the UMA stats from the last 14 days, it appears that about about 20% of geolocation requests on insecure origins are granted. 80% are a combination of ignored and denied.

Simon:

While it was reverted initially on the M46 branch, it was only because it had landed a day before branch point, and we decided to give the removal an extra release to let developers experience it on dev channel. It was never reverted from the M47 branch.

I also disagree that the getUserMedia() decision was controversial. The main controversy has been over fullscreen, and, indeed, we have removed that deprecation warning to discuss it at a later time.

To your proposals, I doubt we would do #1, since the origin icon is meant to be about connection state, not what the page behavior is, and in this case, nothing about the connection state has changed. #2 is an interesting idea, although it really doesn't seem very far removed from just removing geolocation entirely (the rate at which people click on the origin bubble is extremely small, and we assume discovery doesn't happen there).

--Joel

[Chris Palmer]

FWIW, I agree with Joel and +1 this ItR.

[Joel Weinberger]

To clarify my previous numbers in response to Jochen, I believe those numbers are actually in relation to number of times a permission bubble appears. It does not include times that the API is called, but it has already been denied or accepted. I do not know if we have those numbers (that is, "deny" vs "allowed" response to calls to the API).

--Joel

[Elliott Sprehn]

I support this, in general I think we should switch one of the "powerful features" per release to be behind the guard. That's slow enough to let people react, but fast enough to force change and show we're serious. :)

[Jochen Eisinger]

ok, so the number of granted geolocation requests on insecure origins is way below our deprecation theshold.

Simon, would opera want to have a runtime enabled flag, so you can remove the feature at a slower pace?

anyway, lgtm2 to remove

[Mounir Lamouri]

I think the UseCounter might be slightly biased by google websites.
Google properties are the top requesters of the geolocation permission
(based on Rappor data) and obviously these properties are visited a lot.
Basically, every time a user do a search on mobile, the UseCounter for
secure origin geolocation usage goes up.

To take the role of the devil's advocate, hese are other numbers:
1/3 of the permission requests are coming from insecure origins.
1/2 of granted permissions are granted to insecure origins.

To be clear, I'm really not against disabling Geolocation for insecure
origins but I want to make sure the decision is made using all the
numbers we have.

Cheers,
-- Mounir

> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Rick Byers]

That's really interesting data that definitely paints a bit of a different picture - thanks Mounir!  Can it really be true that the ratio of secure vs. insecure page loads involving a geolocation request is ~10:1 but the ratio of secure vs. insecure geolocation approvals is 1:1? 

Using Rapport data could be helpful here.  Can we get a list of the top secure and insecure origins doing geolocation requests?  Perhaps there's some big insecure ones we could reach out to?  Or at least we could better understand what the user impact will be of those insecure origins no longer getting location data.  Eg. if they're mapping sites, that's probably pretty bad.  But if they're, say, weather sites then it's probably not so bad (users can know / type in their city much easier than their current street address).

Rick

[Mounir Lamouri]

On Wed, 25 Nov 2015, at 20:20, Rick Byers wrote:
> That's really interesting data that definitely paints a bit of a
> different
> picture - thanks Mounir! Can it really be true that the ratio of secure
> vs. insecure page loads involving a geolocation request is ~10:1 but the
> ratio of secure vs. insecure geolocation approvals is 1:1?
>
> Using Rapport data could be helpful here. Can we get a list of the top
> secure and insecure origins doing geolocation requests? Perhaps there's
> some big insecure ones we could reach out to? Or at least we could
> better
> understand what the user impact will be of those insecure origins no
> longer
> getting location data. Eg. if they're mapping sites, that's probably
> pretty bad. But if they're, say, weather sites then it's probably not so
> bad (users can know / type in their city much easier than their current
> street address).

Historical rappor data we have do not make a difference between secure
and insecure origins. We have a list of the top domains (not origins)
requesting the geolocation permission. It's mostly
google.{top-level-domain}. We also have a list of the top domains
getting granted geolocation permission but we can't check if they are
secure or insecure origins. We could manually check but that wouldn't
scale well.

There are some new rappor metrics that were added recently that provide
more information. For some reasons, I can't get hold of them. I'm not
sure if it's because they are of type "SAFEBROWSING_RAPPOR_TYPE" or if
the results are too small for the rappor tool. If someone wants to hunt
this down, the sample is created from here:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/permissions/permission_uma_util.cc&l=174

-- Mounir

[Joel Weinberger]

For RAPPOR data on use on insecure domains, there's only one that has enough data to pop out, but it's at a relatively low proportion. So while we can (and should) reach out to them, I don't believe that would make a dent in the insecure numbers.
-Joel

[Mounir Lamouri]

I talked to Joel off-thread: the rappor data he mentioned is about
usage, not permission requests.

-- Mounir

[Mounir Lamouri]

Some more data.

The number of geolocation permission requests from secure origins grew
100% since February. On the other hand, it only grew 50% for the
insecure origins requests. My gut feeling is that the growth is mostly
linked to google search geolocation request given that most Chrome users
will hit it which means that there is likely a strong correlation
between these requests and the Chrome Android usage.

Which led me to check numbers by platforms. If we exclude Android, the
ratio of geolocation permission requests is actually inverted: there are
1/3 of the requests coming from secure origins and 2/3 from insecure
origins. More than 80% of geolocation permission requests are coming
from Android.

Regarding UseCounter, on Windows, the usage of geolocation on insecure
origins is double compared to the usage on secure origins. This seems to
reflect the geolocation permission requests data. On Android, the usage
on secure origins is an order of magnitude higher than the usage on
insecure origins.

So, it seems that the usage of geolocation on insecure origins is higher
on Desktop compared to its usage on secure origins but the desktop use
of geolocation is fairly small compared to mobile where the usage is
higher on secure origins compared to insecure origins. This said, mobile
usage is likely biased by Google Search. I wouldn't be surprised if the
usage on Mobile would look like Desktop if we didn't take into account
Google Search.

-- Mounir

[Ben Wells]

These are a new type of RAPPOR metric reporting multi-dimensional data. We haven't got support yet for viewing the results ....

 

-- Mounir

[Simon Pieters]

On Wed, 25 Nov 2015 21:06:02 +0100, Jochen Eisinger <joc...@chromium.org>
wrote:

> ok, so the number of granted geolocation requests on insecure origins is
> way below our deprecation theshold.
>
> Simon, would opera want to have a runtime enabled flag, so you can remove
> the feature at a slower pace?

I don't think that's necessary, personally I would like it to be removed
roughly at the same time in Opera and Chrome. That said, I haven't asked
other Opera people so it's possible that someone or some team would like a
flag.


On Wed, 25 Nov 2015 20:32:12 +0100, Joel Weinberger <j...@chromium.org>
wrote:

> Simon:
> While it was reverted initially on the M46 branch, it was only because it
> had landed a day before branch point, and we decided to give the removal
> an
> extra release to let developers experience it on dev channel. It was
> never
> reverted from the M47 branch.
>
> I also disagree that the getUserMedia() decision was controversial. The
> main controversy has been over fullscreen, and, indeed, we have removed
> that deprecation warning to discuss it at a later time.

OK.

> To your proposals, I doubt we would do #1, since the origin icon is meant
> to be about connection state, not what the page behavior is, and in this
> case, nothing about the connection state has changed.

OK. What about making #1 be the geolocation dialog saying "Your connection
to this site is not private."?

> #2 is an interesting
> idea, although it really doesn't seem very far removed from just removing
> geolocation entirely (the rate at which people click on the origin bubble
> is extremely small, and we assume discovery doesn't happen there).

Yeah, that's fair. I suppose users would only click it if sites instructed
them to do so, so my thinking was that site owners could add such an
instruction and migrate to https in parallel, instead of instructing their
users to switch to another browser that hasn't removed insecure
geolocation yet.

If the owners think that straight removal is best, I'm not going to
object. I'm just tossing out ideas to have a slightly smoother migration
story to minimize the number of curses in our general direction. :-)

[Philip Jägenstedt]

LGTM3 to remove.

I think it would quite difficult to drive down usage by changing the
wording in the UI. That is for end users, so it couldn't explicitly
talk about the removal of an API, and something more vague risks being
overlooked by web developers.

As usual, we should be prepared to revert and reconsider if it blows
up in dev or beta.

[Joel Weinberger]

So there are now the required 3 API owner LGTMs, but I would like to get final confirmation from Rick that his LGTM still stands, since he seemed to question that slightly earlier. Rick, does it still hold?

I've uploaded https://codereview.chromium.org/1485973002 for the actual removal.

--Joel

[Rick Byers]

Yes, it still holds.  There's definitely a judgement call to be made here, but the privacy benefit is substantial.  I think we should give it a shot and watch for user feedback.  We should be prepared to revert for a milestone or two if we hear of users loosing access to substantial functionality on some popular sites.

Rick

[Joel Weinberger]

Fair enough all around. I'll proceed with the CL then.
-Joel

[Takeshi Kurosawa]

Hi,

I think it would be helpful if the Chrome Platform Status has a specific entry of the removal of Geolocation from Insecure Contexts similar to the AppCache entry.
Because web developers (who check the platform status) can take actions before the stable version is released.

Chrome Platform Status - Remove AppCache from Insecure Contexts
https://www.chromestatus.com/feature/5714236168732672

AppCache removal thread:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UKF8cK0EwMI/FDoKHGpNDwAJ

best wishes,

Takeshi

2015年12月2日水曜日 1時38分04秒 UTC+9 Joel Weinberger:

[Rick Byers]

+1.  As discussed on other threads, it's important that developers have an easy place to check "what's been deprecated / removed this release".  Joel, do you mind adding this?

[Joel Weinberger]

Absolutely. I'll get on that right now, and I'll also add one for getUserMedia(). Sorry for not doing this sooner!

[Joel Weinberger]

getUserMedia(): https://www.chromestatus.com/feature/5703419427815424

geolocation: https://www.chromestatus.com/feature/5636088701911040

[Rick Byers]

Thanks Joel!

[Chris Palmer]

+jww explicitly