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 fun
Lazily sandily
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
This is a hijacked accounts for payments from lotto for a decade
lisalindsa...@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 t
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?
>>>
>>
>> And in t
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
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 écrit :
Around 21% of th
>
> 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
>> m
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:
https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/.
Baby ste
On Wed, Oct 26, 2016 at 5:50 AM, Aryeh Gregor wrote:
> 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
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 pageload is 4.6M * 21%
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 just make the
>> probl
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
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:
>> >
>> >> Setting aside the policy question, the location API for
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
> >> generally
> >> gives a much more precise estima
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
>> from the upstream network p
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 Mozil
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 case of the
> ISP u
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, and Wi-Fi has limi
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.
>
> We want to get
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 geolocation, perhaps we
> coul
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
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 --
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 Ev
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
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
> against); and -- as bz po
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
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, HTT
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
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 methods are accessed? Since
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
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/
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 high. :(
>>> Agreed
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 pe
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 littl
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 desktop.
> >
> > Due to the pri
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 is that this will break
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
a
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.
>>
>> Due to the privacy r
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 pr
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 conte
40 matches
Mail list logo
