What's a good variable name for ErrorResult?

[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
* errorResult
* err
* er
* erv
* result
* res

rv/aRv is used in most places, if we won't worry about conflict with 
nsresult's variable name, taking this makes sense to me.


However, I've seen some methods which have both variables for nsresult 
and ErrorResult.  In such case, what names should be used for them? (I 
usually use erv for consistency with nsresult's naming rule.)


Additionally, developers used to believe rv is a variable name for 
nsresult but currently, it cannot.  When you try to build your patch, 
you may see build error caused by |ErrorResult rv;|.



Anyway, I'd like we to add a rule to the coding style guide.

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
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

[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 pageload is 4.6M * 21% / 3B = 0.0319%.

Do we have the top 100 or top 1000 sites asking for geolocation on HTTP?
If not, what would be the best way to get these data? 

Means and stats are maybe hiding more subtleties and could lead to a better 
informed decision on fixing this.
For example, hypothetically speaking if 90% of these 21% are made by 10 Web 
sites, it's a different issue than if there are made by 1 Web sites.



-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Build System Project - Latest Update

[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 the tup
backend. This is our first steps to modernising the build. We have landed
patches for FINAL_TARGET_PP_FILES (1305157
), to produce
BUILDSTATUS messages (1306405
), XPIDL generation:
1293448 ,
GENERATED_FILES: 1304129
 , and WebIDL
generation: 1304125  .

The build peers have also helped out on a few optimizations to TaskCluster
with the most notable moving builders to use SSD on Amazon (Bug 1306167)
which halved the time that PGO builds take.

We have done some more work on artifact builds. There is now the option to
download symbols during an artifact build. This benefits both local
developers and what is happening in Automation (bug 1305502
).

The build peers have started looking into the build-backend slowness (bug
1259789 ). This is
one of the slowest parts of the configure step in builds, especially on
Windows.

Finally, the build peers have landed, or in the process of landing, build
rewrites for 3rd party libraries we use. More details are available in the
bugs for NSS Bug 1237872
, bug 1295937
 and for Libffi (bug
1262155 ).

David

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/BWuB6S7qxUc/9HzVRXg3CAAJ
___
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

[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 just make the
>> problem worse.
>>
>> We want to get to a place where when we prompt the user on behalf of a
>> website we have some certainty who is asking the question (i.e.,
>> HTTPS).
>
> By that logic, we should not permit users to submit forms to non-HTTPS
> either.

I guess that would be ideal, but there are some situations where
it doesn't matter if the world sees the form data.

Similarly there may be some situations where the user is happy for
the world to know their location.  The UA just needs to make it
clear who can see this information and for how long.  This is,
however, assuming the user will make a reasonable decision based
on that info.
___
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

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

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

[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:
>> >
>> >> 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 Mozilla's office in Mountain view: they can only
>> >> localize
>> >> a user to within 50 meters or so of the office, whereas GPS is
>> accurate to
>> >> a few meters. And of course someone who is upstream from the ISP may
>> just
>> >> have standard geo IP data.
>> >>
>> >
>> > Assuming every MITM and website already has approximate geo IP location,
>> > we could fuzz the navigator.getCurrentPosition() result for HTTP sites.
>> > That would leak no more information than passive geo IP and would not
>> break
>> > HTTP websites using the geolocation API.
>>
>>
>> This turns out to be incredibly hard.
>> https://tools.ietf.org/id/draft-thomson-geopriv-location-
>> obscuring-03.html
>>
>> If you want to do something like this, probably the best way to do it
>> would
>> be
>> to report the GeoIP from some public database based on the apparent
>> current
>> public IP.
>>
>> -Ekr
>>
>>
> Rather than fuzzing we could consider limiting the precision of the
> returned values for HTTP websites to something like a tenth of a degree.
> That would be enough to locate you in the right part of the world without
> giving much away (unless you happen to be very near a pole...).
>

This turns out not to work very well if you are near the grid lines and
moving at all.

I would strongly encourage anyone thinking of trying to design a new scheme
to first
read Martin's document, which covers the space pretty well

-Ekr


> Dan
>
>
>>
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
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

[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
> >> 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 Mozilla's office in Mountain view: they can only
> >> localize
> >> a user to within 50 meters or so of the office, whereas GPS is accurate
> to
> >> a few meters. And of course someone who is upstream from the ISP may
> just
> >> have standard geo IP data.
> >>
> >
> > Assuming every MITM and website already has approximate geo IP location,
> > we could fuzz the navigator.getCurrentPosition() result for HTTP sites.
> > That would leak no more information than passive geo IP and would not
> break
> > HTTP websites using the geolocation API.
>
>
> This turns out to be incredibly hard.
> https://tools.ietf.org/id/draft-thomson-geopriv-location-obscuring-03.html
>
> If you want to do something like this, probably the best way to do it would
> be
> to report the GeoIP from some public database based on the apparent current
> public IP.
>
> -Ekr
>
>
Rather than fuzzing we could consider limiting the precision of the
returned values for HTTP websites to something like a tenth of a degree.
That would be enough to locate you in the right part of the world without
giving much away (unless you happen to be very near a pole...).

Dan


>
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[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
>> from the upstream network provider. For instance, consider the case of the
>> ISP upstream from Mozilla's office in Mountain view: they can only
>> localize
>> a user to within 50 meters or so of the office, whereas GPS is accurate to
>> a few meters. And of course someone who is upstream from the ISP may just
>> have standard geo IP data.
>>
>
> Assuming every MITM and website already has approximate geo IP location,
> we could fuzz the navigator.getCurrentPosition() result for HTTP sites.
> That would leak no more information than passive geo IP and would not break
> HTTP websites using the geolocation API.


This turns out to be incredibly hard.
https://tools.ietf.org/id/draft-thomson-geopriv-location-obscuring-03.html

If you want to do something like this, probably the best way to do it would
be
to report the GeoIP from some public database based on the apparent current
public IP.

-Ekr


>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[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 Mozilla's office in Mountain view: they can only localize
a user to within 50 meters or so of the office, whereas GPS is accurate to
a few meters. And of course someone who is upstream from the ISP may just
have standard geo IP data.


Assuming every MITM and website already has approximate geo IP location, 
we could fuzz the navigator.getCurrentPosition() result for HTTP sites. 
That would leak no more information than passive geo IP and would not 
break HTTP websites using the geolocation API.

___
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

[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 case of the
> ISP upstream from Mozilla's office in Mountain view: they can only localize
> a user to within 50 meters or so of the office, whereas GPS is accurate to
> a few meters.

Yes, but the privacy impact of such an increase in precision is much
less than if you only knew geo IP data.

> And of course someone who is upstream from the ISP may just
> have standard geo IP data.

Are there real-world MITMs who are upstream from the ISP?
(Governments presumably compromise the ISP itself by court order or
equivalent.)
___
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

[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, and Wi-Fi has limited range.  What exactly is the scenario
> we're worried about here?
>

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 Mozilla's office in Mountain view: they can only localize
a user to within 50 meters or so of the office, whereas GPS is accurate to
a few meters. And of course someone who is upstream from the ISP may just
have standard geo IP data.

-Ekr

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[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.
>
> We want to get to a place where when we prompt the user on behalf of a
> website we have some certainty who is asking the question (i.e.,
> HTTPS).

By that logic, we should not permit users to submit forms to non-HTTPS
either.  I agree that if we were designing the web from scratch we
would absolutely require HTTPS for everything, but in reality we have
to make a cost-benefit analysis in each case.  That means analyzing
the threats to our users' privacy or security and deciding whether it
outweighs the user annoyance.  If the prospect of a privacy leak is
implausible or not a big privacy compromise, it doesn't necessarily
outweigh the cost of aggravating users.  I don't think that privacy or
security issues are exempt from cost-benefit analysis like any other
feature or bug fix -- they're unusually important, but still do not
have infinite value.

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 limited range.  What exactly is the scenario
we're worried about here?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[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 been discussed in the
> F2F meeting of the WG this year. It also create a good structure to move
> non-WebAPI discussion to CG and keep WG focusing on the API development.
> 
> [additional information on Mozilla's implementation plan]
> The current plan is to enable 1-UA implementation on Fennec on Nightly
> (release 52). No detailed engineering plan on Firefox desktop for now. We
> are cultivating some proposal to identify the usability of this API on
> desktop browser before dumping engineering resource on it.
> 
> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
> 
> On Sat, Oct 22, 2016 at 5:46 AM, Tantek Çelik 
> wrote:
> 
> > I have reviewed the charter and the current set of deliverables. The
> > work appears to be proceeding reasonably (pragmatically, with many
> > members/implementers including Apple and Google) and reasonably
> > minimally scoped. There is also the companion Second Screen Community
> > Group which appears to be used to incubate work before proceeding in
> > the working group, a pattern which we are generally supportive of.
> >
> > Support revised charter.
> >
> > I don't know of our current implementation plans on this WG's deliverables.
> >
> > The most recent discussion here of any of the deliverables of the WG
> > was on "PresentationAPI", in particular a "[PresentationAPI] Intend to
> > implement" thread here in 2014 September.
> >
> > Tantek
> >
> >
> > On Mon, Oct 17, 2016 at 12:28 PM, L. David Baron 
> > wrote:
> > > The W3C is proposing a revised charter for:
> > >
> > >   Second Screen Working Group
> > >   https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0011.html
> > >   https://www.w3.org/2014/secondscreen/charter-2016.html
> > >
> > > Mozilla has the opportunity to send comments or objections through
> > > next Tuesday, October 25.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it.
> > >
> > > Mozilla does have participants in this group:
> > > https://www.w3.org/2000/09/dbwg/details?group=74168=1=org#_
> > MozillaFoundation
> > >
> > > -David
> > >
> > > --
> > > 턞   L. David Baron http://dbaron.org/   턂
> > > 턢   Mozilla  https://www.mozilla.org/   턂
> > >  Before I built a wall I'd ask to know
> > >  What I was walling in or walling out,
> > >  And to whom I was like to give offense.
> > >- Robert Frost, Mending Wall (1914)
> > >
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
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

[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 geolocation, perhaps we
> could always require door hanger permission for geolocation requests on HTTP
> sites?

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 to a place where when we prompt the user on behalf of a
website we have some certainty who is asking the question (i.e.,
HTTPS).


-- 
https://annevankesteren.nl/
___
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

[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 what our users will see after we roll this out.  It's
easy to ignore this when looking at the ratio of granted non-secure
geolocation prompts per all page loads, but we _are_ talking about
breaking a fifth of geolocations on the web for our users.


I strongly agree with Ehsan that breaking a fifth of geolocation 
requests is a bad user experience.


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 could always require door hanger permission for 
geolocation requests on HTTP sites?


chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Personal Authentication Disabled on BMO

[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 has always supported native authentication using a password securely
stored in our database. If you have used Persona since first creating your
BMO account, you will probably not know this internal password. But you can
reset it to something you do know by first logging out, then clicking on
'Forgot Password' at the right-hand top of the page. Enter your email you
used with Persona in the text field and click 'Reset Password'.

You will receive an email with a link you can use to reset your current
password to something you can use from now on. After you reset your
password, simply enter your login and the password in the login fields at
the top of any BMO page.
Github Login

Github  is also a BMO supported method of
authentication. To use Github, logout and click 'Login' at the top of any
BMO page and then click on the 'Github' login image. You will need to have
a Github account that has an email address the same as the Persona email
you were using, otherwise a different BMO account will be created. You will
be able to choose the email address you want to use for BMO if you have
more than one configured in your Github profile. If none of the email
addresses you have configured in Github match what you were using for
Persona, native login described above may be your best choice if you want
to retain your BMO data.
Email bmo-ad...@mozilla.org or join #bmo on IRC and we can help with any
issues you may have with switching over.

Thanks
BMO Team

-- 
David Lawrence
d...@mozilla.com
bugzilla.mozilla.org
___
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

[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 -- we don't want to throw an exception
> here for spec compliance purposes. I propose that we move forward with a
> plan to immediately deny permission in non-secure contexts. Kan-Ru's
> proposal that we put this behind a pref seems like a good one -- that
> way, if we discover that something unexpected happens in deployment,
> it's a very simple fix to go back to our current behavior.
> 
> I would be hesitant to over-analyze additional complications, such as
> https-everywhere or user education on this topic. We are, after all,
> simply coming into alignment with the rest of the web ecosystem here.

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 our users will see after we roll this out.  It's
easy to ignore this when looking at the ratio of granted non-secure
geolocation prompts per all page loads, but we _are_ talking about
breaking a fifth of geolocations on the web for our users.

I think the user experience that Chrome has shipped sets an extremely
low bar.  While it's easy for us to match that bar, we can (and I argue
we should) do better.

PS. Please note that I'm disappearing later today going on vacation,
which may mean I may not get to continue arguing this side.  I'm
secretly hoping someone else will.  :-)

> On 10/22/16 12:05, Ehsan Akhgari wrote:
>> 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 permission.  We
 could
 do that too, it would just be a little more code.
>>> Uh...  What does the spec say to do?
>> It seems like the geolocation spec just says the failure callback needs
>> to be called when permission is defined, with the PERMISSION_DENIED
>> code, but doesn't mention anything about non-secure contexts.  The
>> permissions spec explicitly says that geolocation *is* allowed in
>> non-secure contexts .
>> The most relevant thing I can find is
>> , which
>> is an implementation consideration.  But as far as I can tell, this is
>> not spec'ed.
>>
>>> Your intent, and the whole "sites that would break are already broken"
>>> thing sounded like we were going to match Chrome and Safari behavior; if
>>> that was not the plan you really needed to explicitly say so!
>> Yes, indeed.  It seems that making Navigator.geolocation [SecureContext]
>> is incompatible with their implementation.
>>
>>> We certainly should not be shipping anything that will change behavior
>>> here to something _different_ from what Chrome and Safari are shipping,
>>> assuming they are shipping compatible things.  Again, what does the spec
>>> say to do?
>>>
>>> -Boris
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> 
> 
> -- 
> Adam Roach
> Principal Engineer, Mozilla

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads Up: Snappy library upgraded

[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 an xpcshell test that restores a profile created in FF 11 (the version
> when IDB introduced compression of structured clone data).
>

Note, however, this is another case where if someone upgrades their profile
by running it in nightly, and then tries to bring the profile back to an
older version like release, things will break.  The old snappy code is not
forward-compatible with the new version.

Some discussion on how to deal with these things in bug 1246615:

https://bugzilla.mozilla.org/show_bug.cgi?id=1246615
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[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 to.
> 
> I think you've misread what I said. I said that if it turns out that
> (for example) the entire web moves to require TLS 1.3 final and ESR 52
> doesn't support it, and as a result these old machines can no longer
> browse the secure web, and therefore people decide they can't use them
> for web surfing any more - that's a feature, not a bug, and it's not
> something we should worry about happening. Same goes for any other
> TLS/cert-related requirement which "breaks" their browsing experience.
> 
> Gerv

I brought up my concern about TLS and digital certificates because I was 
worried about users going to access the secure web and suddenly finding it 
inaccessible. I was concerned about users being immediately cut off. After 
looking at the Wikipedia page on TLS 
(https://en.wikipedia.org/wiki/Transport_Layer_Security), I see that TLS 1.3 is 
a draft and probably years away from completion let alone implantation. XP and 
Vista users have plenty of time to get a new computer before TLS 1.3 is in use. 
As for digital certificates, if Mozilla gives enough security updates to ESR 52 
for XP and Vista users (such as maybe an extra year of support), then that 
shouldn't be a problem.


What I would like to hear from Mozilla with regards to moving XP and Vista 
users on to ESR 52, is if Mozilla really is going to take this action this 
time? I've always thought that this was a great use of the ESR as a way to wind 
down an OS that is about to be unsupported. It's just that Mozilla has never 
done this plan specifically before.


What I think would be helpful if Mozilla does go with this plan, is that, 
first, Mozilla sets a definite end date up front for ESR 52 and, second, that 
Mozilla has puts out the message as to what and why this is happening. Setting 
an end date for support will give everyone a timeline to work with and kill any 
hope on those with older machines that they can just keep holding out one more 
month for updates that will never come. Having a clear message will be good for 
getting everyone on the same page with this policy. A solid press release to 
tech news sites to get out the message to those who provide tech support is a 
good start. A message on the startup page after every update stating how many 
updates are left with ESR 52 and maybe some helpful information about upgrading 
might be a good way to help XP and Vista users on ESR 52.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads Up: Snappy library upgraded

[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 IDB introduced compression of structured clone data).
However, if you think you see any problems related to this upgrade, 
please report in the bug [1].


​[1] https://bugzilla.mozilla.org/show_bug.cgi?id=768074

​Thanks
Jan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[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 example) the entire web moves to require TLS 1.3 final and ESR 52
doesn't support it, and as a result these old machines can no longer
browse the secure web, and therefore people decide they can't use them
for web surfing any more - that's a feature, not a bug, and it's not
something we should worry about happening. Same goes for any other
TLS/cert-related requirement which "breaks" their browsing experience.

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

[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 Everywhere,
that's another discussion entirely. (I think Brave ships it.)

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform