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

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

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

Lazily sandily ___ 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

On Wed, Oct 26, 2016 at 4:26 PM, Jan-Ivar Bruaroey wrote: > On 10/26/16 6:28 PM, Matthew N. wrote: > >> 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?

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

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

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

At the risk of sounding pragmatic/opportunistic, why not wait until the usage numbers go down, as they're bound to? .: Jan-Ivar :. On 10/25/16 7:10 PM, Karl Dubost wrote: Interesting thread. Going back to the starting email: Le 22 oct. 2016 à 04:49, Richard Barnes a

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

> > 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 >>

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

On Tue, Oct 25, 2016 at 8:24 PM, Aryeh Gregor 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:

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

Interesting thread. Going back to the starting email: Le 22 oct. 2016 à 04:49, Richard Barnes 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

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

Aryeh Gregor writes: > On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren 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

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

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

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

On Wed, Oct 26, 2016 at 7:17 AM, Daniel Minor wrote: > > > On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla wrote: > >> On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson >> wrote: >> >> > On 10/25/2016 11:43 AM, Eric Rescorla wrote: >> > >>

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

On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla wrote: > On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson > wrote: > > > On 10/25/2016 11:43 AM, Eric Rescorla wrote: > > > >> Setting aside the policy question, the location API for mobile devices > >>

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

On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson wrote: > 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 >>

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

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

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

On Tue, Oct 25, 2016 at 9:43 PM, 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

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

On Wed, Oct 26, 2016 at 5:24 AM, Aryeh Gregor 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,

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

On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren 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.

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

On Tue, Oct 25, 2016 at 6:51 PM, Chris Peterson 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

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

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

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

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 --

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

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

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

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.

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

On Mon, Oct 24, 2016 at 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 >

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

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

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

On 2016-10-24 4:14 AM, Gervase Markham wrote: > 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,

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

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

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

On Sat, Oct 22, 2016, at 09:38 PM, Richard Barnes wrote: > On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari > wrote: > > Since the proposal in the bug is adding [SecureContext] to > > Navigator.geolocation, have we also collected telemetry around which > > properties and

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

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

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

On 10/22/2016 03:59 AM, Chris Peterson wrote: 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/

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

On 2016-10-22 9:32 AM, Richard Barnes wrote: > On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson > wrote: > >> 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

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

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

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

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

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

On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari 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

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

On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson wrote: > 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

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

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

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

On Fri, Oct 21, 2016 at 2:56 PM, Ehsan Akhgari 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.