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