Intent to deprecate: insecure Geo requests

[Michelangelo De Simone]

TL;DR the Geolocation API will be restricted to secure contexts in
Firefox 55 (due in August).

Hi there,

as a follow-up to [1], we're moving forward to restrict Geolocation
API only to secure contexts.
This is due to a number of important reasons:

1. Chrome and Safari have already deprecated insecure geo requests
last year (Firefox is the only major browser still allowing them)
2. We've deprecated "Insecure HTTP" in 2015 [2]
3. It's easier than ever to get a valid SSL certificate
4. It's cheaper than ever to get a valid SSL certificate (actually it's free)

Even though we've landed all the necessary groundwork in [3], this is
gonna be a slow rollout to give everybody plenty of time to adjust.

In Firefox 54 (currently in Nightly): the insecure Geolocation API are
protected by the preference "geo.security.allowinsecure" that defaults
to true on all the channels (true = accept insecure requests = no
change).
Firefox 54 is due in june [4].

In Firefox 55 we will flip the switch and all the requests to
navigator.geolocation.getCurrentPosition() and watchPosition() will
only be fulfilled if in a secure context.
Firefox 55 is due in august.

The tracking bug is [5].

[1] http://bit.ly/2jZYXkK
[2] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[3] http://bugzil.la/1269531
[4] https://wiki.mozilla.org/RapidRelease/Calendar
[5] http://bugzil.la/1072859

-- 
Bye,
Michelangelo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Michelangelo De Simone]

On Tue, Oct 25, 2016 at 12:17 PM, Chris Peterson  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform