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 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 example
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 I
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 to.
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 an xpcshell test tha
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 --
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 ha
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 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
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
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 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 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 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 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 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 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 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
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
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 the
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%
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
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
* e
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
24 matches
Mail list logo
