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

2016-10-25 Thread Daniel Minor
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

2016-10-25 Thread Eric Rescorla
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

2016-10-25 Thread 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

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

2016-10-25 Thread Karl Tomlinson
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

What's a good variable name for ErrorResult?

2016-10-25 Thread Masayuki Nakano
Hi, Variable name for ErrorResult hasn't defined in our coding rules yet: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Error_Variables Do we have a consensus for it? According to m-c's code, I can see some variable names for it: * er * rv/aRv * error/aError *

Build System Project - Latest Update

2016-10-25 Thread David Burns
Below is a highlight of all work the build peers have done in the last few weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. The build peers have managed to get numerous patches landed for

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

2016-10-25 Thread Karl Dubost
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

Heads Up: Snappy library upgraded

2016-10-25 Thread Jan Varga
Since the integration of bug 768074 [1] ​in Nightly, the new version of the library is used. The library is used in IndexedDB, DOM cache, etc. We are confident that the library is fully backwards-compatible and we have an xpcshell test that restores a profile created in FF 11 (the version when

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

2016-10-25 Thread 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

Re: Windows XP and Vista Long Term Support Plan

2016-10-25 Thread keithgallistel
On Tuesday, October 25, 2016 at 3:22:10 AM UTC-5, Gervase Markham wrote: > On 24/10/16 18:44, Eric Rescorla wrote: > > This seems to assume facts not in evidence, namely that people will stop > > using those > > machines rather than just living with whatever the last version we updated > > them

Re: Windows XP and Vista Long Term Support Plan

2016-10-25 Thread Gervase Markham
On 24/10/16 18:44, Eric Rescorla wrote: > This seems to assume facts not in evidence, namely that people will stop > using those > machines rather than just living with whatever the last version we updated > them to. I think you've misread what I said. I said that if it turns out that (for

Personal Authentication Disabled on BMO

2016-10-25 Thread Dave Lawrence
As of today, Persona is no longer a valid method of authentication on bugzilla.mozilla.org (BMO). If you have used Persona primarily up to this point, the next time your session expires or you manually log out, you will need to authenticate with one of two other valid methods. Native Login BMO

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

2016-10-25 Thread 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 --

Re: Heads Up: Snappy library upgraded

2016-10-25 Thread Ben Kelly
On Tue, Oct 25, 2016 at 5:03 AM, Jan Varga wrote: > Since the integration of bug 768074 [1] ​in Nightly, the new version of > the library is used. The library is used in IndexedDB, DOM cache, etc. > We are confident that the library is fully backwards-compatible and we > have

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

2016-10-25 Thread 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

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

2016-10-25 Thread Anne van Kesteren
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

2016-10-25 Thread Eric Rescorla
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

2016-10-25 Thread Aryeh Gregor
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: Proposed W3C Charter: Second Screen Working Group

2016-10-25 Thread L. David Baron
I've submitted a response in support of the charter, without comments. -David On Monday 2016-10-24 10:47 +0800, Shih-Chiang Chien wrote: > Support revised charter. > > The revised charter creates some flexibility for us to promote Flyweb as a > new feature in Presentation API Level 2, which has

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

2016-10-25 Thread Aryeh Gregor
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

2016-10-25 Thread 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

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

2016-10-25 Thread Eric Rescorla
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 >>