Intent to restrict to secure contexts: navigator.geolocation

[Richard Barnes]

The geolocation API allows web pages to request the user's geolocation,
drawing from things like GPS on mobile, and doing WiFi / IP based
geolocation on desktop.

Due to the privacy risks associated with this functionality, I would like
to propose that we restrict this functionality to secure contexts [1].

Our telemetry for geolocation is a little rough, but we can derive some
upper bounds. According to telemetry from Firefox 49, the geolocation
permissions prompt has been shown around 4.6M times [2], on about 3B page
loads [3]. Around 21% of these requests were (1) from "http:" origins, and
(2) granted by the user. So the average rate of permissions being granted
to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.

Access to geolocation from non-secure contexts is already disabled in
Chrome [4] and WebKit [5].

Please send any comments on this proposal by Friday, October 28.

Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1072859

[1] https://www.w3.org/TR/secure-contexts/
[2] https://mzl.la/2eeoWm9
[3] https://mzl.la/2eoiIAw
[4] https://codereview.chromium.org/1530403002/
[5] https://trac.webkit.org/changeset/200686

[Ehsan Akhgari]

On 2016-10-21 3:49 PM, Richard Barnes wrote:
> The geolocation API allows web pages to request the user's geolocation,
> drawing from things like GPS on mobile, and doing WiFi / IP based
> geolocation on desktop.
>
> Due to the privacy risks associated with this functionality, I would like
> to propose that we restrict this functionality to secure contexts [1].
>
> Our telemetry for geolocation is a little rough, but we can derive some
> upper bounds. According to telemetry from Firefox 49, the geolocation
> permissions prompt has been shown around 4.6M times [2], on about 3B page
> loads [3]. Around 21% of these requests were (1) from "http:" origins, and
> (2) granted by the user. So the average rate of permissions being granted
> to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.

Does this mean that we'd be breaking one in 5 geolocation requests as a
result of this? That seems super high. :(

Since the proposal in the bug is adding [SecureContext] to
Navigator.geolocation, have we also collected telemetry around which
properties and methods are accessed? Since another kind of breakage we
may encounter is code like |navigator.geolocation.getCurrentPosition()|
throwing an exception and breaking other parts of site scripts...

> Access to geolocation from non-secure contexts is already disabled in
> Chrome [4] and WebKit [5].
>
> Please send any comments on this proposal by Friday, October 28.
>
> Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1072859
>
> [1] https://www.w3.org/TR/secure-contexts/
> [2] https://mzl.la/2eeoWm9
> [3] https://mzl.la/2eoiIAw
> [4] https://codereview.chromium.org/1530403002/
> [5] https://trac.webkit.org/changeset/200686

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Tantek Çelik]

On Fri, Oct 21, 2016 at 2:56 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2016-10-21 3:49 PM, Richard Barnes wrote:
>> The geolocation API allows web pages to request the user's geolocation,
>> drawing from things like GPS on mobile, and doing WiFi / IP based
>> geolocation on desktop.
>>
>> Due to the privacy risks associated with this functionality, I would like
>> to propose that we restrict this functionality to secure contexts [1].
>>
>> Our telemetry for geolocation is a little rough, but we can derive some
>> upper bounds. According to telemetry from Firefox 49, the geolocation
>> permissions prompt has been shown around 4.6M times [2], on about 3B page
>> loads [3]. Around 21% of these requests were (1) from "http:" origins, and
>> (2) granted by the user. So the average rate of permissions being granted
>> to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.
>
> Does this mean that we'd be breaking one in 5 geolocation requests as a
> result of this? That seems super high. :(

Agreed. For example, my understanding is that this will break
http://www.nextbus.com/ (and thus http://www.nextmuni.com/ ) location
awareness (useful for us SF folks), which is kind of essential for
having it tell you transit stops near you. -t

[Chris Peterson]

On 10/21/2016 3:11 PM, Tantek Çelik wrote:
>> > Does this mean that we'd be breaking one in 5 geolocation requests as a
>> > result of this? That seems super high. :(
> Agreed. For example, my understanding is that this will break
> http://www.nextbus.com/ (and thus http://www.nextmuni.com/ ) location
> awareness (useful for us SF folks), which is kind of essential for
> having it tell you transit stops near you. -t

Indeed, the geolocation feature on nextbus.com is broken in Chrome. (The
site shows a geolocation error message on first use.)

Next Bus already has an HTTPS version of their site, but it is not the
default and has some mixed-content warnings. For a site that uses
geolocation as a core part of its service, I'm surprised they have let
it stay broken in Chrome for six months. Chrome removed insecure
geolocation in April 2016 and announced its deprecation in November 2015.

[Richard Barnes]

On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

This is actually the bigger point than the telemetry point: The sites we
would break with this change have already been broken for six months in
Chrome and for four months in WebKit. This is not something where we
should be standing on principle and bravely being different from other
browsers; in fact quite the opposite.

--Richard

[Richard Barnes]

On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari <ehsan....@gmail.com>

wrote:

> On 2016-10-21 3:49 PM, Richard Barnes wrote:
> > The geolocation API allows web pages to request the user's geolocation,
> > drawing from things like GPS on mobile, and doing WiFi / IP based
> > geolocation on desktop.
> >
> > Due to the privacy risks associated with this functionality, I would like
> > to propose that we restrict this functionality to secure contexts [1].
> >
> > Our telemetry for geolocation is a little rough, but we can derive some
> > upper bounds. According to telemetry from Firefox 49, the geolocation
> > permissions prompt has been shown around 4.6M times [2], on about 3B page
> > loads [3]. Around 21% of these requests were (1) from "http:" origins,
> and
> > (2) granted by the user. So the average rate of permissions being
> granted
> > to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.
>

> Does this mean that we'd be breaking one in 5 geolocation requests as a
> result of this? That seems super high. :(
>

That's why I included the additional context. Any feature we disable is
going to break 100% of pageloads that use that feature. You need to take
into account how many pageloads that actually is.

> Since the proposal in the bug is adding [SecureContext] to
> Navigator.geolocation, have we also collected telemetry around which
> properties and methods are accessed? Since another kind of breakage we
> may encounter is code like |navigator.geolocation.getCurrentPosition()|
> throwing an exception and breaking other parts of site scripts...
>

I'm not picky about how exactly we turn this off, as long as the
functionality goes away. Chrome and Safari both immediately call the error
handler with the same error as if the user had denied permission. We could
do that too, it would just be a little more code.

--Richard

[Boris Zbarsky]

On 10/22/16 9:38 AM, Richard Barnes wrote:
> I'm not picky about how exactly we turn this off, as long as the
> functionality goes away. Chrome and Safari both immediately call the error
> handler with the same error as if the user had denied permission. We could
> do that too, it would just be a little more code.

Uh... What does the spec say to do?

Your intent, and the whole "sites that would break are already broken"
thing sounded like we were going to match Chrome and Safari behavior; if
that was not the plan you really needed to explicitly say so!

We certainly should not be shipping anything that will change behavior
here to something _different_ from what Chrome and Safari are shipping,
assuming they are shipping compatible things. Again, what does the spec
say to do?

-Boris

[Ehsan Akhgari]

On 2016-10-22 10:16 AM, Boris Zbarsky wrote:
> On 10/22/16 9:38 AM, Richard Barnes wrote:
>> I'm not picky about how exactly we turn this off, as long as the
>> functionality goes away. Chrome and Safari both immediately call the
>> error
>> handler with the same error as if the user had denied permission. We
>> could
>> do that too, it would just be a little more code.
>
> Uh... What does the spec say to do?

It seems like the geolocation spec just says the failure callback needs
to be called when permission is defined, with the PERMISSION_DENIED
code, but doesn't mention anything about non-secure contexts. The
permissions spec explicitly says that geolocation *is* allowed in
non-secure contexts <https://w3c.github.io/permissions/#geolocation>.
The most relevant thing I can find is
<https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which
is an implementation consideration. But as far as I can tell, this is
not spec'ed.

> Your intent, and the whole "sites that would break are already broken"
> thing sounded like we were going to match Chrome and Safari behavior; if
> that was not the plan you really needed to explicitly say so!

Yes, indeed. It seems that making Navigator.geolocation [SecureContext]
is incompatible with their implementation.

> We certainly should not be shipping anything that will change behavior
> here to something _different_ from what Chrome and Safari are shipping,
> assuming they are shipping compatible things. Again, what does the spec
> say to do?
>
> -Boris

[Ehsan Akhgari]

On 2016-10-22 9:32 AM, Richard Barnes wrote:
> On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>

> This is actually the bigger point than the telemetry point: The sites we
> would break with this change have already been broken for six months in
> Chrome and for four months in WebKit. This is not something where we
> should be standing on principle and bravely being different from other
> browsers; in fact quite the opposite.

I agree with the benefits of removing this API, and I understand the
argument around compatibility with other browsers. But there is also
the aspect of user pain caused by this, especially the way that Chrome
has shipped it (by silently breaking the API.)

Have we considered doing something here to help the user when we block
this API? For example, we could check to see whether the site has a TLS
version and suggest in a doorhanger that the user should switch to it
and maybe provide a button for them to do that without them having to
edit the URL (especially since we hide "http://" in the non-secure
top-level document case.) Or if there is no TLS version, perhaps we can
put up a doorhanger explaining what happened, and link to a support
article for more details.

If we had a good way to collect this data, we could also have a UI to
submit the site to Mozilla so that our webcompat team can try to reach
out to the website and introduce them to Let's Encrypt?

Cheers,
Ehsan

[smaug]

"insecure". SecureContext is really quite high level concept and doesn't apply to all the necessary bits in the platform. So just to remind that it
doesn't exactly give too much security.
https://w3c.github.io/webappsec-secure-contexts/#isolation
(It is rather mystery to me for example why the spec does explicitly handle SharedWorkers but doesn't BroadcastChannel, when they both deal with
cross-browsing-context messaging (SharedWorker also other stuff))

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:
> Have we considered doing something here to help the user when we block
> this API? For example, we could check to see whether the site has a TLS
> version

If there were a reliable way to do this, HTTPS Everywhere would be a
whole lot easier to write and maintain :-) AIUI, it's not as simple as
adding an extra s to the protocol, doing a fetch and seeing if the
response is 2xx.

Gerv

[Kan-Ru Chen]

On Sat, Oct 22, 2016, at 09:38 PM, Richard Barnes wrote:
> On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
> > Since the proposal in the bug is adding [SecureContext] to
> > Navigator.geolocation, have we also collected telemetry around which
> > properties and methods are accessed? Since another kind of breakage we
> > may encounter is code like |navigator.geolocation.getCurrentPosition()|
> > throwing an exception and breaking other parts of site scripts...
> >
>

> I'm not picky about how exactly we turn this off, as long as the
> functionality goes away. Chrome and Safari both immediately call the
> error handler with the same error as if the user had denied permission. We
> could do that too, it would just be a little more code.

I would be OK with this change if it is implemented in a way compatible
with Chrome and Safari. Looks like they both call the error handler and
show an error in the console when the request is denied. And it should
be behind a pref so we can monitor it's usage during the release cycle.

Kanru

[Gervase Markham]

On 22/10/16 18:12, Ehsan Akhgari wrote:

> Have we considered doing something here to help the user when we block
> this API? For example, we could check to see whether the site has a TLS
> version

[Ehsan Akhgari]

I suppose we can use the HTTPS Everywhere ruleset for this purpose,
assuming it's something we can (and want to) ship?

[Adam Roach]

I'm hearing general agreement that we think turning this off is the
right thing to do; that maintaining compatibility with Chrome's behavior
is important (since that's what existing code will presumably be tested
against); and -- as bz points out -- we don't want to throw an exception
here for spec compliance purposes. I propose that we move forward with a
plan to immediately deny permission in non-secure contexts. Kan-Ru's
proposal that we put this behind a pref seems like a good one -- that
way, if we discover that something unexpected happens in deployment,
it's a very simple fix to go back to our current behavior.

I would be hesitant to over-analyze additional complications, such as
https-everywhere or user education on this topic. We are, after all,
simply coming into alignment with the rest of the web ecosystem here.

/a

On 10/22/16 12:05, Ehsan Akhgari wrote:
> On 2016-10-22 10:16 AM, Boris Zbarsky wrote:

>> On 10/22/16 9:38 AM, Richard Barnes wrote:
>>> I'm not picky about how exactly we turn this off, as long as the
>>> functionality goes away. Chrome and Safari both immediately call the
>>> error
>>> handler with the same error as if the user had denied permission. We
>>> could
>>> do that too, it would just be a little more code.
>> Uh... What does the spec say to do?

> It seems like the geolocation spec just says the failure callback needs
> to be called when permission is defined, with the PERMISSION_DENIED
> code, but doesn't mention anything about non-secure contexts. The
> permissions spec explicitly says that geolocation *is* allowed in
> non-secure contexts <https://w3c.github.io/permissions/#geolocation>.
> The most relevant thing I can find is
> <https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which
> is an implementation consideration. But as far as I can tell, this is
> not spec'ed.
>

>> Your intent, and the whole "sites that would break are already broken"
>> thing sounded like we were going to match Chrome and Safari behavior; if
>> that was not the plan you really needed to explicitly say so!

> Yes, indeed. It seems that making Navigator.geolocation [SecureContext]
> is incompatible with their implementation.
>

>> We certainly should not be shipping anything that will change behavior
>> here to something _different_ from what Chrome and Safari are shipping,
>> assuming they are shipping compatible things. Again, what does the spec
>> say to do?
>>
>> -Boris

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
Adam Roach
Principal Engineer, Mozilla

[Richard Barnes]

On Mon, Oct 24, 2016 at 6:29 PM, Adam Roach <a...@mozilla.com> wrote:

> I'm hearing general agreement that we think turning this off is the right
> thing to do; that maintaining compatibility with Chrome's behavior is
> important (since that's what existing code will presumably be tested
> against); and -- as bz points out -- we don't want to throw an exception
> here for spec compliance purposes. I propose that we move forward with a
> plan to immediately deny permission in non-secure contexts. Kan-Ru's
> proposal that we put this behind a pref seems like a good one -- that way,
> if we discover that something unexpected happens in deployment, it's a very
> simple fix to go back to our current behavior.
>

This plan sounds fine to me. Thanks for summarizing, Adam.

> I would be hesitant to over-analyze additional complications, such as
> https-everywhere or user education on this topic. We are, after all, simply
> coming into alignment with the rest of the web ecosystem here.
>

+1

--Richard

>
> /a
>
>
> On 10/22/16 12:05, Ehsan Akhgari wrote:
>
>> On 2016-10-22 10:16 AM, Boris Zbarsky wrote:
>>

>>> On 10/22/16 9:38 AM, Richard Barnes wrote:
>>>
>>>> I'm not picky about how exactly we turn this off, as long as the
>>>> functionality goes away. Chrome and Safari both immediately call the
>>>> error
>>>> handler with the same error as if the user had denied permission. We
>>>> could
>>>> do that too, it would just be a little more code.
>>>>
>>> Uh... What does the spec say to do?
>>>

>> It seems like the geolocation spec just says the failure callback needs
>> to be called when permission is defined, with the PERMISSION_DENIED
>> code, but doesn't mention anything about non-secure contexts. The
>> permissions spec explicitly says that geolocation *is* allowed in
>> non-secure contexts <https://w3c.github.io/permissions/#geolocation>.
>> The most relevant thing I can find is
>> <https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which
>> is an implementation consideration. But as far as I can tell, this is
>> not spec'ed.
>>

>> Your intent, and the whole "sites that would break are already broken"
>>> thing sounded like we were going to match Chrome and Safari behavior; if
>>> that was not the plan you really needed to explicitly say so!
>>>

>> Yes, indeed. It seems that making Navigator.geolocation [SecureContext]
>> is incompatible with their implementation.
>>

>> We certainly should not be shipping anything that will change behavior
>>> here to something _different_ from what Chrome and Safari are shipping,
>>> assuming they are shipping compatible things. Again, what does the spec
>>> say to do?
>>>
>>> -Boris

>>> _______________________________________________
>>> dev-platform mailing list
>>> dev-pl...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>

> --
> Adam Roach
> Principal Engineer, Mozilla
>

[Boris Zbarsky]

On 10/24/16 6:29 PM, Adam Roach wrote:
> and -- as bz points out -- we don't want to throw an exception
> here for spec compliance purposes.

Actually, what I wanted to say is that if we think all browsers should
implement some behavior here then we should get the spec changed to say
so. Shipping the "always deny if non-secure" behavior is technically
spec compliant, in the same way that always denying, period, is
technically spec-compliant, but all that tells us is that the spec in
its current state isn't very good at achieving interoperability.

So once we figure out what the behavior we plan to implement is, we
should ensure that we raise a spec issue to get that behavior standardized.

I do not yet have a strong opinion on whether we should change to the
Chrome behavior, nor how to message this "we're going to break some of
your sites" bit to our users.

-Boris

P.S. It's entirely possible that for the specific case of SF transit no
one is using the website to start with and everyone is using some native
app instead. :( Or at least that the Chrome users are doing that, and
that Firefox users will end up doing so too.

[Gervase Markham]

On 24/10/16 21:12, Ehsan Akhgari wrote:
> I suppose we can use the HTTPS Everywhere ruleset for this purpose,
> assuming it's something we can (and want to) ship?

Shipping this seems like a heavyweight way to deal with the deprecation
of the geolocation permission. If we want to implement HTTPS Everywhere,
that's another discussion entirely. (I think Brave ships it.)

Gerv

[Ehsan Akhgari]

On 2016-10-24 6:29 PM, Adam Roach wrote:
> I'm hearing general agreement that we think turning this off is the
> right thing to do; that maintaining compatibility with Chrome's behavior
> is important (since that's what existing code will presumably be tested
> against); and -- as bz points out -- we don't want to throw an exception
> here for spec compliance purposes. I propose that we move forward with a
> plan to immediately deny permission in non-secure contexts. Kan-Ru's
> proposal that we put this behind a pref seems like a good one -- that
> way, if we discover that something unexpected happens in deployment,
> it's a very simple fix to go back to our current behavior.
>

> I would be hesitant to over-analyze additional complications, such as
> https-everywhere or user education on this topic. We are, after all,
> simply coming into alignment with the rest of the web ecosystem here.

FWIW, and to the extent that my opinion matters on the topic, I strongly
disagree that breaking the websites that people use silently is the
right thing to do.

Let's ignore the HTTPS Everywhere part of the thread, and instead pay
more attention to what our users will see after we roll this out. It's
easy to ignore this when looking at the ratio of granted non-secure
geolocation prompts per all page loads, but we _are_ talking about
breaking a fifth of geolocations on the web for our users.

I think the user experience that Chrome has shipped sets an extremely
low bar. While it's easy for us to match that bar, we can (and I argue
we should) do better.

PS. Please note that I'm disappearing later today going on vacation,
which may mean I may not get to continue arguing this side. I'm
secretly hoping someone else will. :-)

> On 10/22/16 12:05, Ehsan Akhgari wrote:
>> On 2016-10-22 10:16 AM, Boris Zbarsky wrote:

>>> On 10/22/16 9:38 AM, Richard Barnes wrote:
>>>> I'm not picky about how exactly we turn this off, as long as the
>>>> functionality goes away. Chrome and Safari both immediately call the
>>>> error
>>>> handler with the same error as if the user had denied permission. We
>>>> could
>>>> do that too, it would just be a little more code.
>>> Uh... What does the spec say to do?

>> It seems like the geolocation spec just says the failure callback needs
>> to be called when permission is defined, with the PERMISSION_DENIED
>> code, but doesn't mention anything about non-secure contexts. The
>> permissions spec explicitly says that geolocation *is* allowed in
>> non-secure contexts <https://w3c.github.io/permissions/#geolocation>.
>> The most relevant thing I can find is
>> <https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which
>> is an implementation consideration. But as far as I can tell, this is
>> not spec'ed.
>>

>>> Your intent, and the whole "sites that would break are already broken"
>>> thing sounded like we were going to match Chrome and Safari behavior; if
>>> that was not the plan you really needed to explicitly say so!

>> Yes, indeed. It seems that making Navigator.geolocation [SecureContext]
>> is incompatible with their implementation.
>>

>>> We certainly should not be shipping anything that will change behavior
>>> here to something _different_ from what Chrome and Safari are shipping,
>>> assuming they are shipping compatible things. Again, what does the spec
>>> say to do?
>>>
>>> -Boris

>>> _______________________________________________
>>> dev-platform mailing list
>>> dev-pl...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>

[Chris Peterson]

On 10/25/2016 6:26 AM, Ehsan Akhgari wrote:
> FWIW, and to the extent that my opinion matters on the topic, I strongly
> disagree that breaking the websites that people use silently is the
> right thing to do.
>
> Let's ignore the HTTPS Everywhere part of the thread, and instead pay
> more attention to what our users will see after we roll this out. It's
> easy to ignore this when looking at the ratio of granted non-secure
> geolocation prompts per all page loads, but we _are_ talking about
> breaking a fifth of geolocations on the web for our users.

I strongly agree with Ehsan that breaking a fifth of geolocation
requests is a bad user experience.

What is the threat model for geolocation over HTTP? That a coffee shop,
ISP, or Big Brother will MITM a non-secure site so as to sniff a user's
location? To reduce location leaks without breaking non-secure
geolocation, perhaps we could always require door hanger permission for
geolocation requests on HTTP sites?

chris

[Anne van Kesteren]

On Tue, Oct 25, 2016 at 6:51 PM, Chris Peterson <cpet...@mozilla.com> wrote:
> What is the threat model for geolocation over HTTP? That a coffee shop, ISP,
> or Big Brother will MITM a non-secure site so as to sniff a user's location?
> To reduce location leaks without breaking non-secure geolocation, perhaps we
> could always require door hanger permission for geolocation requests on HTTP
> sites?

The basic problem is prompting the user at all for non-HTTPS since
that leads them to think they can make an informed decision whereas
that's very much unclear. So prompting more would just make the
problem worse.

We want to get to a place where when we prompt the user on behalf of a
website we have some certainty who is asking the question (i.e.,
HTTPS).


--
https://annevankesteren.nl/

[Aryeh Gregor]

On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> The basic problem is prompting the user at all for non-HTTPS since
> that leads them to think they can make an informed decision whereas
> that's very much unclear. So prompting more would just make the
> problem worse.
>
> We want to get to a place where when we prompt the user on behalf of a
> website we have some certainty who is asking the question (i.e.,
> HTTPS).

By that logic, we should not permit users to submit forms to non-HTTPS
either. I agree that if we were designing the web from scratch we
would absolutely require HTTPS for everything, but in reality we have
to make a cost-benefit analysis in each case. That means analyzing
the threats to our users' privacy or security and deciding whether it
outweighs the user annoyance. If the prospect of a privacy leak is
implausible or not a big privacy compromise, it doesn't necessarily
outweigh the cost of aggravating users. I don't think that privacy or
security issues are exempt from cost-benefit analysis like any other
feature or bug fix -- they're unusually important, but still do not
have infinite value.

In this specific case, it seems that the usual candidates for MITMing
(compromised Wi-Fi, malicious ISP) will already know the user's
approximate location, because they're the ones who set up the Internet
connection, and Wi-Fi has limited range. What exactly is the scenario
we're worried about here?

[Eric Rescorla]

On Wed, Oct 26, 2016 at 5:24 AM, Aryeh Gregor <a...@aryeh.name> wrote:
>
> In this specific case, it seems that the usual candidates for MITMing
> (compromised Wi-Fi, malicious ISP) will already know the user's
> approximate location, because they're the ones who set up the Internet
> connection, and Wi-Fi has limited range. What exactly is the scenario
> we're worried about here?
>

Setting aside the policy question, the location API for mobile devices
generally
gives a much more precise estimate of your location than can be obtained
from the upstream network provider. For instance, consider the case of the
ISP upstream from Mozilla's office in Mountain view: they can only localize
a user to within 50 meters or so of the office, whereas GPS is accurate to
a few meters. And of course someone who is upstream from the ISP may just
have standard geo IP data.

-Ekr

[Aryeh Gregor]

On Tue, Oct 25, 2016 at 9:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
> Setting aside the policy question, the location API for mobile devices
> generally
> gives a much more precise estimate of your location than can be obtained
> from the upstream network provider. For instance, consider the case of the
> ISP upstream from Mozilla's office in Mountain view: they can only localize
> a user to within 50 meters or so of the office, whereas GPS is accurate to
> a few meters.

Yes, but the privacy impact of such an increase in precision is much
less than if you only knew geo IP data.

> And of course someone who is upstream from the ISP may just
> have standard geo IP data.

Are there real-world MITMs who are upstream from the ISP?
(Governments presumably compromise the ISP itself by court order or
equivalent.)

[Chris Peterson]

On 10/25/2016 11:43 AM, Eric Rescorla wrote:
> Setting aside the policy question, the location API for mobile devices
> generally
> gives a much more precise estimate of your location than can be obtained
> from the upstream network provider. For instance, consider the case of the
> ISP upstream from Mozilla's office in Mountain view: they can only localize
> a user to within 50 meters or so of the office, whereas GPS is accurate to
> a few meters. And of course someone who is upstream from the ISP may just
> have standard geo IP data.

Assuming every MITM and website already has approximate geo IP location,
we could fuzz the navigator.getCurrentPosition() result for HTTP sites.
That would leak no more information than passive geo IP and would not
break HTTP websites using the geolocation API.

[Eric Rescorla]

On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson <cpet...@mozilla.com>
wrote:

This turns out to be incredibly hard.
https://tools.ietf.org/id/draft-thomson-geopriv-location-obscuring-03.html

If you want to do something like this, probably the best way to do it would
be
to report the GeoIP from some public database based on the apparent current
public IP.

[Daniel Minor]

On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla <e...@rtfm.com> wrote:

> On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>

> This turns out to be incredibly hard.
> https://tools.ietf.org/id/draft-thomson-geopriv-location-obscuring-03.html
>
> If you want to do something like this, probably the best way to do it would
> be
> to report the GeoIP from some public database based on the apparent current
> public IP.
>
> -Ekr
>
>

Rather than fuzzing we could consider limiting the precision of the
returned values for HTTP websites to something like a tenth of a degree.
That would be enough to locate you in the right part of the world without
giving much away (unless you happen to be very near a pole...).

Dan

[Eric Rescorla]

On Wed, Oct 26, 2016 at 7:17 AM, Daniel Minor <dmi...@mozilla.com> wrote:

>
>
> On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson <cpet...@mozilla.com>
>> wrote:
>>

>> This turns out to be incredibly hard.
>> https://tools.ietf.org/id/draft-thomson-geopriv-location-
>> obscuring-03.html
>>
>> If you want to do something like this, probably the best way to do it
>> would
>> be
>> to report the GeoIP from some public database based on the apparent
>> current
>> public IP.
>>
>> -Ekr
>>
>>
> Rather than fuzzing we could consider limiting the precision of the
> returned values for HTTP websites to something like a tenth of a degree.
> That would be enough to locate you in the right part of the world without
> giving much away (unless you happen to be very near a pole...).
>

This turns out not to work very well if you are near the grid lines and
moving at all.

I would strongly encourage anyone thinking of trying to design a new scheme
to first
read Martin's document, which covers the space pretty well

-Ekr


> Dan

[Michelangelo De Simone]

On Tue, Oct 25, 2016 at 12:17 PM, Chris Peterson <cpet...@mozilla.com> wrote:

> Assuming every MITM and website already has approximate geo IP location, we
> could fuzz the navigator.getCurrentPosition() result for HTTP sites. That

Please don't.

We used to have fuzzed/synthesized position in geo, and it was removed in [1].
Geolocation has a very clearly stated semantics and it's simple.

Returning anything but the actual expected position would be
equivalent to not having geolocation at all: what would be the point
to ask for a point to then get a "wrong" one?

Also, this would add unecessary complexity to the whole feature, again.

We're talking about limiting geo only to SecureContexts, thing that is
- IMHO - very reasonable and has the "only" countereffect of braking
current HTTP-only websites. And "reasonable" here is the keyword.

If a feature is not meant to work in a certain context, we should not
be bending the semantics of the feature, instead we should just break
and explain why. Braking is not necessarily always bad.

To overcome this it'd be just easier, and clearer to all the parties
involved, to have a slowly paced - and staged - rollout of the
HTTPS-only geo.
Let's just use some common sense to avoid braking things too fast and
without a clear explanation.

Perhaps we can start by limiting geo to secure contexts in
WebDev/Aurora (and Beta?), while pushing an ominous Allow/Disallow
prompt (with double confirmation?) for few stable releases.

[1] https://bugzil.la/1278410
--
Bye,
Michelangelo

[Karl Tomlinson]

Aryeh Gregor writes:

> On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> The basic problem is prompting the user at all for non-HTTPS since
>> that leads them to think they can make an informed decision whereas
>> that's very much unclear. So prompting more would just make the
>> problem worse.
>>
>> We want to get to a place where when we prompt the user on behalf of a
>> website we have some certainty who is asking the question (i.e.,
>> HTTPS).
>
> By that logic, we should not permit users to submit forms to non-HTTPS
> either.

I guess that would be ideal, but there are some situations where
it doesn't matter if the world sees the form data.

Similarly there may be some situations where the user is happy for
the world to know their location. The UA just needs to make it
clear who can see this information and for how long. This is,
however, assuming the user will make a reasonable decision based
on that info.

[Karl Dubost]

Interesting thread. Going back to the starting email:

Le 22 oct. 2016 à 04:49, Richard Barnes <rba...@mozilla.com> a écrit :
> Around 21% of these requests were (1) from "http:" origins, and
> (2) granted by the user. So the average rate of permissions being granted
> to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.

Do we have the top 100 or top 1000 sites asking for geolocation on HTTP?
If not, what would be the best way to get these data?

Means and stats are maybe hiding more subtleties and could lead to a better informed decision on fixing this.
For example, hypothetically speaking if 90% of these 21% are made by 10 Web sites, it's a different issue than if there are made by 10000 Web sites.



--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Eric Rescorla]

On Wed, Oct 26, 2016 at 5:50 AM, Aryeh Gregor <a...@aryeh.name> wrote:

> On Tue, Oct 25, 2016 at 9:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > Setting aside the policy question, the location API for mobile devices
> > generally
> > gives a much more precise estimate of your location than can be obtained
> > from the upstream network provider. For instance, consider the case of
> the
> > ISP upstream from Mozilla's office in Mountain view: they can only
> localize
> > a user to within 50 meters or so of the office, whereas GPS is accurate
> to
> > a few meters.
>

> Yes, but the privacy impact of such an increase in precision is much
> less than if you only knew geo IP data.
>

> > And of course someone who is upstream from the ISP may just
> > have standard geo IP data.
>

> Are there real-world MITMs who are upstream from the ISP?
>

Who are upstream from your local ISP? Yes, all over the place.

-Ekr

[Anne van Kesteren]

On Tue, Oct 25, 2016 at 8:24 PM, Aryeh Gregor <a...@aryeh.name> wrote:
> By that logic, we should not permit users to submit forms to non-HTTPS
> either.

And we are starting to flag pages that request passwords over
non-HTTPS: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/.
Baby steps.


--
https://annevankesteren.nl/

[Peter Dolanjski]

>
> On 10/25/2016 6:26 AM, Ehsan Akhgari wrote:
>
>> FWIW, and to the extent that my opinion matters on the topic, I strongly
>> disagree that breaking the websites that people use silently is the
>> right thing to do.
>>
>> Let's ignore the HTTPS Everywhere part of the thread, and instead pay
>> more attention to what our users will see after we roll this out. It's
>> easy to ignore this when looking at the ratio of granted non-secure
>> geolocation prompts per all page loads, but we _are_ talking about
>> breaking a fifth of geolocations on the web for our users.
>>
>
> I strongly agree with Ehsan that breaking a fifth of geolocation requests
> is a bad user experience.

According to Richard's original link [1], there are significant differences
in results for different populations. Yes, around 21% of the aggregate are
over http and granted by the user. However, if you just look at OSX and
Linux users that number is 62%!

Breaking a fifth of geolocation requests that are granted/denied (not sure
if this data includes prompts that are not acted upon) doesn't sound
entirely unreasonable, but doing so likely affects certain types of users
(based on the sites they tend to visit) significantly more than the average.

Peter

[1] https://mzl.la/2eeoWm9

On Tue, Oct 25, 2016 at 12:51 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

[Jan-Ivar Bruaroey]

At the risk of sounding pragmatic/opportunistic, why not wait until the
usage numbers go down, as they're bound to?

.: Jan-Ivar :.

[Matthew N.]

On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote:
> At the risk of sounding pragmatic/opportunistic, why not wait until the
> usage numbers go down, as they're bound to?

And in the meantime we could remove the "always allow" option for
geolocation over HTTP like we do for another permission (WebRTC IIRC).

Matthew

[Matthew N.]

On Wed, Oct 26, 2016 at 4:26 PM, Jan-Ivar Bruaroey <j...@mozilla.com> wrote:

> Good point. Mind filing a bug if there isn't one already?
>

​I filed ​
https://bugzilla.mozilla.org/show_bug.cgi?id=1313242
​​

[llisamar...@gmail.com]

This is a hijacked accounts for payments from lotto for a decade lisali...@live.co.uk li...@gmail.com devises identification etc stolen from me for the past decade or mabe more ive been talking to phsicics on media web maria tara Teresa, and mary from america im scottish white 41 years old tbis devise is mu partners becasue mine sare going amissin all time or been deliberatly briken this is a js3 devises from apple that i won in 201w have been taken also its trickery if my eyes sught id advise u to talk to naria or pedre i can hear them and its in my circle of peip who are menta b friends but theres onky one person that can be doing this as hes the only 1 with information about these ive been readinf up but i do t k ow whars been done and how but emails are beenmade up in my name from phnes land property cars etc bought in my name or somein whhos pretend to be my career of some sort the email im used is lisali...@live.co.uk but theres about 4 of them as i said im finding out a little each day but i dont know what kind of trouble im in as ive said i know they can see everything i do or write inthis phone if u can hrlp id appreciate your help and support but speak to the phsicics as theyve been given me guidence

[gordon...@gmail.com]

Lazily sandily

[Bagher Sadati]

Richard Barnes در تاریخ جمعه ۲۱ اکتبر ۲۰۱۶ ساعت ۲۳:۲۰:۰۰ (UTC+3:30) نوشت:
> The geolocation API allows web pages to request the user's geolocation,
> drawing from things like GPS on mobile, and doing WiFi / IP based
> geolocation on desktop.
>
> Due to the privacy risks associated with this functionality, I would like
> to propose that we restrict this functionality to secure contexts [1].
>
> Our telemetry for geolocation is a little rough, but we can derive some
> upper bounds. According to telemetry from Firefox 49, the geolocation
> permissions prompt has been shown around 4.6M times [2], on about 3B page
> loads [3]. Around 21% of these requests were (1) from "http:" origins, and

> (2) granted by the user. So the average rate of permissions being granted
> to non-secure origins per pageload is 4.6M * 21% / 3B = 0.0319%.
>

> Access to geolocation from non-secure contexts is already disabled in
> Chrome [4] and WebKit [5].
>
> Please send any comments on this proposal by Friday, October 28.
>
> Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1072859
>
> [1] https://www.w3.org/TR/secure-contexts/
> [2] https://mzl.la/2eeoWm9
> [3] https://mzl.la/2eoiIAw
> [4] https://codereview.chromium.org/1530403002/
> [5] https://trac.webkit.org/changeset/200686